--- layout: post.njk source: https://yage.ai/share/gpt56-prompt-guidance-result-certainty-20260724.html speaker: yage.ai title: GPT-5.6 的新提示指南：prompt 该少写什么，多写什么 date: '2026-07-24' summary: 本文探讨了在利用 GPT 模型（如 GPT-5.6）时，提示词工程的演变。核心思想是从过去习惯于细致编写每一步操作指令的模式，转向关注最终交付成果、关键验证证据和人类审批边界。文章强调通过消融测试和评估优先（Evaluation-First）的方法来精简提示词，并定义清晰的完成条件与权限边界，以实现从过程确定性到结果确定性的控制。 area: tech-engineering category: ai-application tags: - prompt-engineering - evaluation-first - lean-prompt - agentic-workflow people: [] companies_orgs: - OpenAI products_models: - GPT-5.6 media_books: [] draft: true status: evergreen --- OpenAI 在 2026 年 7 月 22 日更新了 Model guidance。在这份针对 GPT-5.6 的最新提示指南里，出现了一个和许多人习惯相反的工程动作：当 Agent 拿到充足的上下文时，开发者不需要在提示词里逐行手写具体的中间执行步骤。 一直以来，大家习惯把步骤写得越细越好，希望用一串操作指令把 Agent 扣在预设好的轨迹上。最新指南没有让人放弃控制，而是挪动了约束的位置：把从前花在规定路线上的精力，转去明确最终的交付成果、必须留下的验证证据，以及哪些关键操作必须有人类审批。 只看这页更新，容易以为这只是个随手改掉的 prompt 技巧。但如果把 OpenAI 此前公开过的 GPT-4.1、GPT-5 与 GPT-5.6 提示文档拉到一起，会看到一条连续的工程线索。 ## GPT-5.6：少写步骤，写清交付 在具体的项目里清理提示词冗余，并不是靠直觉把指令缩短。GPT-5.6 建议的做法很干脆：在代表性的测试集上，一组一组删除提示词里的路线描述，重新运行任务，观察质量读数和凭证有没有下滑。 只有删除后测试指标依然稳定，这段指令才算可以被安全精简；一旦读数下跌，再把丢掉的约束加回来。OpenAI 在内部编码 Agent 上试过这种消融测试，删掉非必要步骤带来了方向上的优化，效果取决于具体的业务负载。这种拿测试指标决定指令去留的思路，正是 Evaluation-First：Cursor 这篇 Agent Harness 文章真正值得读的地方 讨论的关键：不能凭感觉猜哪段提示词有用，每次精简都要靠 eval 数据来验证是否维持了输出质量。这里被用来做消融验证的方法，在指南里被称为 lean-prompt。 省略中间步骤之后，提示词里留下的部分反而变得更加明确。指南整理了一份围绕交付结果构建的清单：任务目标、领域上下文、硬性约束、审批边界、成功标准、遇到歧义时的提问规则、所需的验证证据以及输出格式。这些要素组合在一起，构成了约束 Agent 交付质量的具体要求。 既然在测试集上删掉步骤指令依然能保持指标稳定，这就引出了一个令人疑惑的问题：为什么在早期的官方提示指南里，开发者需要花大量篇幅，把每一个中间步骤手把手写进系统提示词？ ## GPT-4.1：把路线写进 prompt 时间退回 2025 年 4 月 14 日发布的 GPT-4.1 Prompting Guide，里面的 SWE-bench 样例提示词展现了当时的处理方式：开发者把一个包含八个步骤的完整工作流，直接硬编码进了系统提示词。 提示词里明确要求模型在每次调用工具前先写规划、用完工具后做反思、改完代码后必须运行测试，还写了多段提醒来防止 Agent 在长任务中途放弃或跑偏。当时这么做很自然。代码提交后有没有通过自动化测试，能检查最终产物对不对；但在执行过程中，模型自带的不确定性会让 Agent 随时漏掉上下文、偏离主线或提前结束。八个步骤的详细路线，本质上是在用确定性的工作流程去约束执行过程中的行为偏离，帮 Agent 稳稳走完全程。 当模型开始能看懂更长的上下文、自己做出合理的工具选择时，把所有路径死死写进提示词就显得太笨重了。开发者需要知道，在什么场景下可以给 Agent 更多自主空间，在什么地方又必须设卡。 ## GPT-5：路线开始松开 2025 年 8 月 7 日发布的 GPT-5 prompting guide 给出的答案不是把路线指令一删了之，而是展现了一条连续的授权光谱。 开发者不再假设所有任务都要死板规定路线，而是顺着场景来决定授权范围：从完全由上下文引导模型自主决策，到由程序代码严格控制分支。指南开始关注如何调控模型的主动性（agentic eagerness），引导开发者定义探索边界、早停条件与终止标准，并把常规的安全操作与需要确认的高风险动作划分开来。提示词的核心诉求发生了变化：不再是机械指挥每一步怎么走，而是决定任务何时能继续、何时必须停下、何时需要找人类确认。 模型理解上下文和规划路线的能力在提升，开发者也逐渐摸清了如何用完成条件、验证证据与权限边界来做约束。GPT-5.6 把这套做法收拢为围绕交付成果来写 prompt。但在真实的项目里，文档上的这种控制转向究竟对应着什么样具体的代码变化？ ## 翻译系统里的同一件事 把这套控制思路放进 Superlinear Academy 处理长篇中文文章的英文翻译系统里，我也踩过同样的坑。 早期处理长文章翻译时，模型生成的不确定性经常破坏流程：中途缩写文本、译文夹杂中文字符、Markdown 格式丢失，或者长文本生成超时。为了让系统稳定运行，我在外层代码里搭了一套很重的防御机制，试图预判每一条可能的恢复路径。我写了分段拆分、异常重试、术语上下文拼接和断点续传逻辑，正如我在 Wide Research 中做过的尝试。这套设计虽然能跑通，但也把大量精力耗在了维护繁琐的格式校验代码上。 后来 Claude Code 与 Codex 展示了更轻便的组织方式：把状态保存在本地文件系统里，建立标准的 agentic loop 闭环。磁盘文件记录着持久状态，Agent 可以分章写入并自行读取上下文，中断后再启动也能读文件继续。面对一篇长文章翻译，Agent 可以自主决定是先通读全文、自己写 Python 正则检查脚本、重新翻译某个段落，还是先核对领域术语。我不再干预具体的翻译路线，而是改为提供一份由三部分构成的交付要求： 完成条件：定义任务何时达到合格的终止状态。对于长文翻译，重点在于全篇是否有中文字符残留、Markdown 格式是否完整保留、特定英文术语全篇是否保持一致。在代码修复场景中，则是所有单元测试通过且无新增 lint 报错。 验证证据：证明完成条件已被满足的客观凭证。例如 Agent 自行编写并运行的 Python 正则检查脚本输出、自动化测试日志或 eval 评分。在受监管或事故复盘场景中，过程记录本身也是必不可少的验证证据，不能被视作可有可无的辅助材料。 权限边界：明确 Agent 自主选择路径时的活动空间与禁区。例如通过 --allowedTools 参数严格限定工具调用范围，对涉及文件系统覆盖写入、外部 API 发布或采购等高风险动作，强制设立 Guardrails and human review 机制。只有当翻译产物满足格式完整、无中文残留、术语一致，且经过人工审批后，才允许向外部发布。 从过程确定性到结果确定性：Agent 自主选择执行路线，系统用完成条件、验证证据与权限边界定义可靠交付 ## 结尾：把成功标准留在手里 用完成条件与权限边界守住出口，并不意味着系统会自动拿到百分之百的可靠。 在实际开发中，依然需要建立基于 evaluation-first 的测试体系，配合受控的消融测试，逐步精简提示词中非必要的步骤干预，同时把权限边界与副作用拦截固化在工具层配置中。 随着推理成本持续降低，正如 《一次性软件与被压缩的现实》 中讨论的，用 token 消耗与闭环自检来换取最终交付的可靠性，变得越来越划算。但如果引入 Agent 框架时缺乏清晰的边界与约束，盲目让模型自由发挥，反而会 带来更大的技术债。开发者如果希望在具体的应用场景中建立起这种新的工程平衡与控制边界，可以参考我们整理的这份 操作指南。 可靠的 Agent 系统不是靠微观管束每一步建造出来的，也不是靠完全放手获得的。开发者需要做的是把路线放给具备足够上下文的模型，同时把完成标准、验证证据与权限边界牢牢握在自己手里。