GPT 最佳实践

很多团队把大语言模型用不好，不是因为模型不够强，而是因为使用方式还停留在“提个问题，等一个万能答案”。

这套东西本质上不是搜索框，也不是顾问，更不是靠谱到可以直接签字承担责任的专家。它更像一个能力很强、速度很快、但会一本正经犯错的概率型助手。你给它的任务边界、输入材料、检查机制，决定了结果上限。

这篇文章不聊某一家产品的最新按钮，也不追模型名词更新。只谈一件更稳的事：在真实工作里，怎么把 GPT 这类模型用得可控、可复查、可落地。

先定性：模型不是 Oracle，是有误差分布的系统

如果你把模型当成“知道答案的人”，你会频繁失望；如果你把它当成“会根据上下文生成最像答案的候选内容的系统”，很多实践反而会顺起来。

这会直接导出几个工作原则：

• 不要只问“能不能答”，要问“答错了我怎么发现”
• 不要只追求一次答对，要设计可以迭代修正的流程
• 不要把模型放在需要确定性的环节上单独决策
• 能交给规则、程序、检索、数据库做的事，就别硬让模型猜

更具体地说，模型适合加速认知劳动，不适合替你承担责任。

一、先把工作定义清楚，别把“写点东西”当任务

多数失败不是因为 prompt 太短，而是任务定义太糊。

“帮我写个方案”这种话，对模型来说几乎没有可执行性。方案写给谁看？为了解决什么问题？约束是什么？不能做什么？最后要产出邮件、PRD、SQL 迁移计划，还是会上能讲的 5 个决策点？这些不说，模型只能凭语料习惯往“看起来像方案”的方向滑。

一个能做的任务，至少要包含四件事：

1. 目标：这次输出要解决什么问题
2. 读者：是给老板、客户、工程师，还是给自己做底稿
3. 约束：时间、篇幅、语气、合规、技术栈、不能碰的边界
4. 完成标准：什么样算完成，什么样不算

比如下面这类写法，比“写个需求文档”强得多：

你要帮我写一份给前端和后端对齐用的接口变更说明。

目标：
- 说明用户资料编辑接口从整包更新改为字段级 patch 的原因
- 列出兼容影响和迁移步骤

读者：
- 前端工程师、后端工程师、测试

约束：
- 不写背景故事，不写宣传性措辞
- 以现有 REST API 为前提
- 必须标明 breaking change 与非 breaking change
- 总长度控制在 800 字以内

完成标准：
- 读完后，前后端可以直接开始改代码
- 测试可以据此列回归点
- 如果信息不足，请先列缺失项，不要编造

任务定义越接近“可执行工单”，输出越像工作结果；越接近“泛泛聊天”，输出越像废话。

二、上下文不是配菜，是主料

模型最常见的问题不是不会写，而是不知道你所在的具体世界。

你脑子里默认存在的上下文，模型并不知道。比如：

• 你们公司的术语
• 当前项目阶段
• 历史决策
• 现有技术栈
• 组织里的利益关系
• 用户是谁、不能影响谁
• 哪些结论早就定了，哪些仍可讨论

所以很多人觉得模型“理解力不行”，其实是你让它在上下文空洞里缺乏依据地推进。

上下文至少要交代三层

1. 业务上下文

这是在什么场景里发生的？你们在优化什么指标？约束来自哪里？

比如“做一个登录页”与“给金融后台重做登录流，必须兼容短信二次验证、企业 SSO 和审计记录”根本不是一个任务。

2. 资料上下文

给它看原始材料，而不是只给你的二手总结。常见材料包括：

• 现有文档
• 代码片段
• 会议纪要
• 用户反馈
• 日志样本
• 数据表结构
• API 返回
• 竞品截图
• 错误栈

原始材料越贴近任务现场，模型越不容易飘。

3. 输出上下文

你准备拿这份内容去干嘛？是发 Slack、写 commit message、做汇报、起草合同条款、补测试用例，还是给客服做回复模板？用途不同，结构必须不同。

三、能提供源材料，就不要让模型靠记忆编

现代模型在“根据你给的材料组织表达”这件事上通常比“凭自己知识库存一套完整事实”可靠得多。

如果任务涉及以下内容，尽量做 grounding，也就是用可信材料把它钉住：

• 公司内部知识
• 最新制度、价格、流程
• 技术实现细节
• 合规要求
• 数据口径
• 需要引用原文的内容

一个简单但有效的规则：

只要答案里任何一句话需要你承担事实责任，就尽量给源材料。

好的做法

• 给会议纪要，让它整理决策与待办
• 给 API 文档和实际响应样本，让它写接入说明
• 给 20 条用户反馈，让它归类问题
• 给合同条文，让它标风险点
• 给错误日志，让它先提假设再排序排查路径

差的做法

• “你知道我们公司那个会员规则吧？”
• “按最新监管要求帮我改一下”
• “根据这个系统的代码风格写个模块”，但不提供代码
• “总结一下最近行业变化”，但不给时间范围和来源要求

一个实用模板

请仅根据我提供的材料回答。
如果材料不足以支持某个结论，明确写“材料不足”。
不要补充你自己的常识性猜测。
如果引用具体依据，请在句尾标注出处编号。

材料：
[1] ...
[2] ...
[3] ...

这不是形式主义。很多“幻觉”不是模型凭空乱来，而是你默认它应该知道，但又没给证据。

四、Prompt 要有结构，不要把要求搅成一锅粥

最差的 prompt 往往是几十行字塞成一段，目标、约束、背景、例外和格式混在一起。人看着都累，模型更容易漏条件。

一个好用的基本结构如下：

任务：
背景：
输入材料：
约束：
输出格式：
验收标准：

复杂一点的任务，可以加上：

• 不要做什么
• 遇到信息不足时怎么办
• 先做分析还是直接产出
• 是否需要列风险与假设
• 是否要区分事实、推断、建议

举个例子：让它写分析，不要写空泛抒情

任务：
分析这 12 条用户投诉，提炼出前三个最影响续费的问题。

背景：
这是一个面向中小团队的项目管理 SaaS。目标不是做品牌总结，而是找出优先修复项。

输入材料：
下面是 12 条原始投诉文本：...

约束：
- 按问题而不是按情绪分类
- 区分“高频”与“高损失”
- 不要复述所有投诉
- 不要输出空泛建议，如“重视用户体验”

输出格式：
1. 问题名称
2. 典型表现
3. 影响范围
4. 为什么会影响续费
5. 建议优先级
6. 需要补充验证的数据

验收标准：
结论要能直接进入下周评审会。

你会发现，模型并不怕要求多，它怕的是要求不成体系。

五、尽量要求“可检查”的输出，而不是“看起来不错”的输出

很多内容之所以难用，不是因为写得差，而是因为无法检查。

“写一版更专业的内容”这种指令，最终得到的往往只是语气更像样，但事实更难审。相反，要求模型输出可以核对、可以 diff、可以转交下游的格式，价值会高很多。

优先考虑这些格式

• 表格
• JSON / YAML
• Checklist
• 分步骤计划
• 风险列表
• 假设列表
• 决策记录
• 测试用例
• “结论 / 依据 / 不确定项”三栏结构

比如，不要只让它“总结文档”

可以要求：

请输出一个三列表格：
- 结论
- 来自原文的依据
- 仍然不确定的点

如果某个结论没有明确依据，不要写结论。

或者：

请输出 JSON，字段固定为：
{
  "problem": "",
  "root_causes": [],
  "constraints": [],
  "proposed_actions": [],
  "open_questions": []
}

格式化的本质不是美观，而是便于后续程序处理、人审和复用。

六、复杂任务一律拆，不要幻想一次生成到位

模型在单步任务上通常不错，一旦把“理解问题、查资料、做判断、权衡方案、组织表达、生成最终稿”全塞到一轮里，质量就会明显波动。

实操上更稳的方式是拆成流水线。

一个常见拆法

第一步：理解任务

先让它复述目标、列出缺失信息、识别风险点。

第二步：处理材料

让它做摘要、抽取结构、提炼事实，而不是直接下结论。

第三步：生成候选方案

让它给出 2 到 3 个不同方向，并说明取舍，不急着出终稿。

第四步：收敛

你来补充约束、删掉不合适方向，再让它继续。

第五步：产出最终格式

最后再写成文档、邮件、PR、脚本或页面文案。

为什么拆分有效

因为每一步都变得更容易检查。你不用等到最后才发现整篇文章建立在错误理解上。

一个简化示例：

第一轮：先不要给方案。只根据材料回答：
1. 我这次真正要解决的问题是什么
2. 目前已知事实有哪些
3. 还缺哪些信息
4. 哪些点最容易误判

第二轮：基于上一步，给我三个可行方案。
每个方案只写：
- 核心思路
- 成本
- 风险
- 适用前提
不要写成完整汇报稿。

第三轮：采用方案 B。
请输出面向工程团队的执行计划，分为本周、下周、风险项、回滚方案。

这比一上来“帮我写完整方案”稳得多。

七、工具能解决的事，交给工具；模型负责编排，不负责硬算

一个成熟用法，不是让模型单打独斗，而是让它和工具协作。

模型擅长的，是解释、归纳、生成候选、组织流程；不擅长的，是需要强确定性的执行。

典型分工

检索系统

用来找资料、召回相关文档，而不是靠模型记忆公司知识库。

数据库 / 查询工具

用来拿真实数据、做筛选、做聚合，不要把 SQL 结果靠想象写出来。

代码执行环境

用来算数、跑脚本、验证正则、处理 CSV、执行测试。

Linter / Type Checker / Test Runner

用来做最终裁决。模型可以写代码修复，但是否正确，应该由工具说了算。

浏览器 / 爬虫 / API 客户端

用来获取最新页面、接口响应、真实 DOM 结构。

一个好原则

模型负责提出“怎么做”，工具负责回答“做没做对”。

比如让模型生成 SQL，可以；但执行结果、影响行数、边界数据是否正确，必须回到数据库验证。让模型写代码，可以；但 pass 不 pass test，应该看测试，不是看它自信解释。

八、迭代 refinement 才是常态，首稿只配叫草稿

很多人对模型的错误预期来自于：希望第一轮直接出最终版。

现实里，模型首稿通常只值 60 分到 80 分。真正高效的用法，是把它当成一个迭代对象：你给反馈，它快速重写。

反馈要具体，不要情绪化

差反馈：

• 不太对，再来一版
• 太 AI 了
• 不够专业

好反馈：

• 删掉开场铺垫，直接从问题定义开始
• 第二部分太像产品宣传，改成工程决策口吻
• 把“建议”改成“可执行步骤”，每步都要标责任方
• 只保留和成本相关的比较，不要谈品牌价值
• 例子太泛，换成 B2B SaaS 场景

模型对明确的、局部的、结构化反馈响应很好；对模糊情绪，通常只会表面迎合。

一个很实用的重写方式

保留文章结构，但按下面要求重写：
1. 删掉所有泛泛而谈的句子
2. 每节开头先给判断，再展开
3. 所有建议必须落到具体动作
4. 不要出现“提升效率”“赋能”“最佳选择”这类空词
5. 语气更像内部方法论，不像宣传稿

如果你追求风格稳定，这种“基于已有稿件做定向修订”通常比从零生成更稳。

九、要允许模型承认不知道，而不是逼它装懂

很多错误，是被使用方式诱导出来的。

如果你的 prompt 默认每个问题都必须回答完整、必须像专家、必须给出明确结论，模型就更容易在证据不足时硬补。

所以要主动给它“说不知道”的合法路径。

你可以明确要求它这样做

如果材料无法支持确定结论：
- 明确指出不确定
- 解释缺的是什么信息
- 给出下一步最小验证动作
不要把猜测写成事实。

这条规则在下面这些场景尤其重要：

• 技术排障
• 法务与合规
• 医疗、金融等高风险判断
• 商业预测
• 根因分析
• 需要引用事实的行业分析

真正成熟的输出，不是每句都很肯定，而是能把事实、推断、假设、建议分开。

一个推荐格式

事实：
推断：
不确定项：
建议的验证动作：

这比“给一个完整答案”更适合真实工作。

十、建立小型评测集，别靠“感觉这次挺准”

如果你要把模型用于重复场景——例如客服回复、需求整理、代码审查辅助、文章摘要、销售线索分类——就别再靠临场感觉判断质量。

你需要一个小型 evaluation set，哪怕只有 20 条样本，也比没有强。

评测集至少包含三类样本

1. 常规样本

最常见、最标准的问题。看基本稳定性。

2. 边界样本

信息不全、表述混乱、输入过长、多意图混杂。看鲁棒性。

3. 反例样本

故意带误导、冲突信息、无解条件。看它会不会编造。

评什么

视任务而定，但通常可以看：

• 准确性
• 完整性
• 格式遵循
• 引用依据是否正确
• 是否捏造
• 是否漏掉关键约束
• 是否能正确拒答或标不确定

一个很实用的做法

把同一套样本固定下来，每次你改 prompt、换模型、换工具链，都跑一遍。你很快就会发现，很多“感觉更聪明”的改动，在线下样本上未必更稳。

工作流一旦规模化，没有评测，所有优化都只是主观猜测。

十一、常见失败模式，要提前防，不要事后骂模型笨

1. 任务太宽，输出必然发散

“分析一下我们产品怎么增长”这种任务，本质上没有边界。模型只好从通用商业语料里拼一篇正确的废话。

解法：缩窄到具体目标、对象、周期、约束和产出。

2. 材料不够，却要求下结论

材料只有几条用户评论，却要“总结核心用户画像”；没有日志和复现路径，却要“定位根因”。这不是模型的问题，这是输入不配结论。

解法：允许它先列缺口，别强行一步到位。

3. 想让模型替你做最终判断

模型可以帮你整理候选项、补充视角、归纳 trade-off，但不能替你拍板那些需要责任承担的决定。

解法：把模型放在“辅助决策”而不是“自动决策”的位置。

4. 追求文采，牺牲信息密度

很多人一看输出“不够像人”，就不断要求它更自然、更生动、更高级。结果往往是腔调上去了，信息反而稀释了。

解法：先保真，再谈风格。工作文档先求清楚，别先求漂亮。

5. 把长上下文当万灵药

给模型塞一大坨材料，不等于它就自动抓住重点。信息太多、层级太乱，照样会漏。

解法：先做材料整理，或者明确告诉它要优先依据哪些部分。

6. 用模型处理本该程序化的流程

比如格式转换、规则校验、字段映射、批量重命名、固定模板填充。这些如果规则足够清晰，通常脚本比模型更稳、更便宜。

解法：优先自动化，模型只补足规则难覆盖的部分。

十二、什么时候不该用模型

这部分往往比“怎么用”更重要。

不要在这些场景里让模型单独上场

1. 高确定性计算

金额、税率、配额、统计口径、复杂逻辑判断。能用程序算就用程序算。

2. 高风险专业判断

法律结论、医学建议、投资决策、合规裁定。模型可以帮你整理材料，不能替专家签字。

3. 规则明确的重复工作

如果已经能写成脚本、SQL、模板引擎，就别引入一个概率系统增加波动。

4. 数据不可出域的场景

涉及敏感数据、客户隐私、核心代码、未公开商业信息时，先确认边界、权限和脱敏策略。很多风险不是输出错，而是输入就不该给。

5. 组织尚未准备好承担误差成本

如果下游默认“模型说了就算”，那现在就不适合把它接入关键流程。

一句话：模型最适合做可复查、可回退、可纠偏的工作；最不适合做不可逆、不可审、不可追责的决定。

十三、几个实用 Prompt 模板

下面这些不是标准答案，但都比“你帮我搞一下”强得多。

1. 写作类：先出结构再出正文

你是我的写作助手，但不要替我发明事实。

任务：
基于我提供的材料，写一篇面向内部团队的分析稿。

要求：
- 先给文章结构，不要直接写全文
- 每个小节写一句核心判断
- 标出哪些判断有材料支持，哪些还需要补证据
- 如果结构合理，我再让你展开正文

2. 资料整理类：强制依据

请仅根据以下材料整理结论。

输出格式：
- 结论
- 依据原文摘录
- 风险或例外
- 不确定项

规则：
- 没有依据的结论不要写
- 原文冲突时，把冲突列出来，不要替我强行统一

3. 需求澄清类：先问缺口

我要做一个新功能，请你先不要给方案。
先完成两件事：
1. 复述你理解的目标
2. 列出为了给出靠谱方案还缺哪些信息

要求：
- 按“用户、场景、约束、数据、技术、上线风险”六类来列
- 不要给泛泛建议

4. 代码协作类：先计划，后改动

你将协助我修改一个已有项目，但请不要直接大改。

先输出：
1. 你对需求的理解
2. 可能影响的模块
3. 最小改动方案
4. 风险点
5. 需要我确认的问题

确认后，再给出具体修改建议。

5. 排障类：区分事实和假设

下面是错误日志和复现步骤。
请不要直接断言根因。

输出格式：
- 已知事实
- 最可能的三个假设
- 每个假设对应的验证方法
- 建议先执行的排查顺序

十四、一个更接近现实的工作流

如果你真想把 GPT 用进日常工作，可以试试这个顺序：

1. 定义任务：明确目标、读者、约束、验收标准
2. 准备材料：原文、代码、数据、样本、截图
3. 首轮澄清：让模型复述任务并列缺口
4. 结构化处理：先抽取事实，再生成候选
5. 工具验证：检索、执行、测试、查询
6. 二轮修订：根据问题定向重写
7. 人工拍板：由人完成最终判断与责任确认
8. 沉淀评测集：把典型样本留作后续基准

这套流程看起来比“直接问一句”麻烦，但只要任务稍微重要一点，它反而更省时间。因为你不再反复和一份表面华丽、实则不可靠的输出纠缠。

结语

GPT 这类模型真正有价值的地方，不是“替你思考”，而是把很多原本低速、低频、难启动的认知工作，变成可以快速试错、快速成形、快速比较的流程。

但前提是，你得接受一件不那么性感的事实：它不是魔法，是系统；不是专家，是工具；不是答案本身，而是答案生产线上的一个环节。

用得好的人，往往不是最会写 prompt 的人，而是最清楚任务边界、最懂得提供材料、最愿意建立验证机制的人。

别问模型“你能不能代替我”。

更有用的问题是：

这项工作里，哪些部分适合交给一个会犯错但速度极快的助手，哪些部分必须由我亲自把关？

想明白这件事，模型才开始真正好用。