强模型时代，提示词要从步骤清单改成任务契约

强模型不需要被过期步骤牵着走，提示词更该定义目标、边界、验收证据和需要确认的歧义。

新模型上线后，很多团队会遇到一个反直觉的问题：模型更强了，任务结果却没有明显变好。

原因有时不在模型，而在提示词。旧提示词为了照顾弱模型，往往把任务拆成固定路线：先查哪个模块、再改哪个函数、哪些文件不要碰、最后补什么测试。对能力不足的模型来说，这是一种扶手；对强模型来说，它可能变成围栏。

强模型已经能读代码、跑工具、验证假设，也能在现场证据变化后调整判断。继续用旧提示词替它规定路径，等于让一个能独立排查的人照着过期手册走。它会把错误指令执行得很漂亮，但结果仍然偏离问题本身。

一个库存扣减问题，暴露了旧提示词的副作用

假设订单服务偶发重复扣减库存。团队把任务交给 Coding Agent，同时沿用过去的提示词：

先检查订单模块中的重试函数，确认重复请求没有被正确拦截；然后在该函数中增加幂等判断，补充单元测试，不要修改数据库结构，也不要调整消息消费逻辑。

模型读完代码后发现，重试函数已经有幂等处理。真正的线索在消息消费端：消费者完成库存写入后，提交消费位点前偶发退出；恢复后会再次收到同一条消息，而库存表没有保存业务幂等键。

如果提示词只交代目标和边界，模型应该继续检查消费语义和数据模型。但旧提示词已经把人的初步猜测写成了事实：故障位置被指定，修复路径被指定，消息消费和数据库结构又被提前排除。模型最后在重试函数里再加一层去重，测试也通过了，线上问题仍然存在。

图：预设路径会让强模型在错误位置继续补丁

这个例子里，模型并没有偷懒。它的问题是太听话。强模型协作最容易被忽略的风险，正是把“我怀疑哪里有问题”写成“问题就在这里”。

图：任务契约把目标、边界、证据和确认点放在同一张工作图上。

提示词的控制点要换位置

与强模型协作，不是把提示词写短，也不是把所有约束删掉。变化在于控制点。

弱模型需要人把任务拆成动作，因为它不擅长自己规划和验证。强模型更需要任务契约：目标是什么、边界在哪里、什么证据算完成、哪些歧义必须停下来确认。

控制点	弱模型协作	强模型协作
人负责什么	拆步骤、缩小搜索空间	定义目标、边界和验收证据
模型负责什么	按步骤执行	根据现场事实规划和修正路径
约束怎么写	尽量限制可选动作	明确权限、风险边界和确认点
不确定性怎么处理	执行前尽量一次消除	执行中发现、记录、校准
结果怎么验收	是否遵循步骤	是否解决问题并提供证据

分步指令、示例和角色设定仍然有用，但它们必须传递模型无法自行获得的信息，或者修复评测中已经出现的缺口。如果只是替模型选择一条未经验证的路线，就应该删掉或降级为假设。

Anthropic 的提醒：地图不等于领土

Anthropic 在介绍 Fable 的文章里，把提示词、技能和上下文比作地图，把真实任务比作领土。地图总会缺东西。文章把这些缺失称为 unknowns，也就是未知项。

未知项有几类：

未知项类型	例子	应对方式
用户知道但没说	是否允许改数据模型、是否必须兼容旧接口	提示词里直接说明，或让模型先问
需要看到方案才清楚	交互细节、取舍偏好、文案风格	用原型、对比方案或小样本收敛
动手后才暴露	历史兼容逻辑、边界条件、隐藏依赖	允许模型记录新事实并调整计划
双方都未意识到	库存案例里的消费位点和幂等键关系	先查证，再把关键发现带回决策

这解释了为什么单纯扩写初始提示词不能解决问题。任务还没展开时，人也不知道所有答案。更好的方式是让模型先做盲点检查：哪些问题会改变方案，但现在还没有答案；哪些可以通过代码和实验自行确认；哪些必须由人拍板。

提示词不需要一次画完地图。它要给出方向、边界和纠偏机制。模型进入真实环境后，再把新发现补回地图。

OpenAI 的建议：少写过程，多写成功标准

OpenAI 在 GPT-5.6 提示词指南里给了相近建议：写清目标、上下文、约束、证据、成功标准和输出格式；不要反复要求模型更努力思考，也不必为每个任务生成多套候选路径。当前模型通常能从上下文判断用户要完成什么，需要明确的是领域信息、硬约束、授权边界，以及什么歧义需要停下来问。

OpenAI 还建议精简提示词：一条指令只写一次，只提供当前任务需要的工具。示例只有在定义产品要求或修正已测缺口时才保留。在一组内部 coding-agent 评测中，更精简的 system prompt 让分数提高约 10% 到 15%，总 token 用量下降 41% 到 66%，成本下降 33% 到 67%。这些数字来自特定样本，不能直接外推，但方向很清楚：旧规则要回到代表性任务里重新验证。

结论不是越短越好，而是每条过程性规则都要有存在理由。模型变了，任务形态变了，提示词也要重新审。

长期信息不该全塞进 system prompt

任务一旦变长，另一个问题会出现：目标、项目约束、团队偏好、常用流程，到底放在哪里？

OpenAI 的 Derrick Choi 记录过一次持续约 25 小时的 Codex 实验。他把目标与非目标、硬约束、交付物和 done when 固化成项目记忆，让 Agent 在计划、实现、验证和修复的循环里反复读取。稳定流程、模板和示例，则可以放进按需加载的 Skill。这样可以减少 prompt spaghetti：过程知识仍然存在，但不必全部常驻在 system prompt 里。

更合理的分层是：

图：长期信息应分层放入记忆、Skill 和现场上下文

目标和边界保持可见，专用流程按需加载，模型再根据现场证据调整路径。这不是放弃工程控制，而是把控制放到更合适的层级。

业务信息要主动说，但不要替模型破案

强模型能从代码、日志和历史提交里推断出很多东西，但推断不是事实。模型猜得更准，也仍然是在猜。

最值得主动告诉 Agent 的，是它无法可靠取得、且一旦猜错会改变方案的信息：

业务语义：库存扣减是否允许最终一致，退款是否必须实时释放额度。
组织约束：哪些系统由其他团队维护，哪些接口不能变。
合规边界：哪些数据不能导出，哪些日志不能进入外部工具。
未决事项：产品还没定的交互、策略或成本取舍。
验收规则：问题修复需要什么测试、灰度指标或回滚条件。

能够通过代码、日志或实验验证的事实，不必提前写死。比如先查哪个函数、是否可能是消费者问题、是否需要加索引，这些应该让模型去调查。人要补充的是不可见事实，不是未经验证的路径猜测。

这也是一些澄清型 Skill 的价值所在。Matt Pocock 的 grill-me 通过连续访谈让用户和 Agent 形成共同理解；obra 的 Superpowers 在实现前用 brainstorming 澄清意图、约束和设计。这些方法的共同点，不是让提示词无限变长，而是逼近那些会影响结果的隐藏信息。

新提示词应该像任务契约

回到库存扣减问题，更好的提示词可以这样写：

定位并修复订单服务重复扣减库存的问题。保持对外接口兼容，并以能够复现问题的测试和修复后的验证结果作为完成依据。先识别会改变修复方案、但当前尚不明确的关键问题；能够通过代码和实验确认的事项先自行验证，涉及数据模型或业务语义变更时再向我确认。

这版提示词没有降低要求。它明确了目标、兼容性、完成证据和确认点。它只是没有提前认定故障在重试函数，也没有在调查开始前排除消息消费和数据模型。

可以把这种提示词拆成四块：

模块	应写内容	不应写成
目标	要解决什么问题	我猜问题一定在哪里
边界	哪些接口、数据、权限不能越过	所有可能相关模块都不许碰
证据	什么测试、日志或指标证明完成	只要按步骤做完就算完成
确认点	哪些业务决策必须问人	让模型猜业务方还没决定的事

步骤并不是禁忌。如果审计必须保留证据链，迁移必须按协议顺序执行，或者某个示例定义了产品语义，它就应该留下。针对已知失败模式的规则也有价值，但要用评测和回归验证支撑。

强模型时代的提示词，不再是把任务拆给模型照做的清单，而是一份任务契约：目标清楚，边界清楚，证据清楚，未知项的处理方式清楚。至于路线，让模型在真实证据里走出来。

AI小老六