强模型不需要被过期步骤牵着走提示词更该定义目标、边界、验收证据和需要确认的歧义。新模型上线后很多团队会遇到一个反直觉的问题模型更强了任务结果却没有明显变好。原因有时不在模型而在提示词。旧提示词为了照顾弱模型往往把任务拆成固定路线先查哪个模块、再改哪个函数、哪些文件不要碰、最后补什么测试。对能力不足的模型来说这是一种扶手对强模型来说它可能变成围栏。强模型已经能读代码、跑工具、验证假设也能在现场证据变化后调整判断。继续用旧提示词替它规定路径等于让一个能独立排查的人照着过期手册走。它会把错误指令执行得很漂亮但结果仍然偏离问题本身。一个库存扣减问题暴露了旧提示词的副作用假设订单服务偶发重复扣减库存。团队把任务交给 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 澄清意图、约束和设计。这些方法的共同点不是让提示词无限变长而是逼近那些会影响结果的隐藏信息。新提示词应该像任务契约回到库存扣减问题更好的提示词可以这样写定位并修复订单服务重复扣减库存的问题。保持对外接口兼容并以能够复现问题的测试和修复后的验证结果作为完成依据。先识别会改变修复方案、但当前尚不明确的关键问题能够通过代码和实验确认的事项先自行验证涉及数据模型或业务语义变更时再向我确认。这版提示词没有降低要求。它明确了目标、兼容性、完成证据和确认点。它只是没有提前认定故障在重试函数也没有在调查开始前排除消息消费和数据模型。可以把这种提示词拆成四块模块应写内容不应写成目标要解决什么问题我猜问题一定在哪里边界哪些接口、数据、权限不能越过所有可能相关模块都不许碰证据什么测试、日志或指标证明完成只要按步骤做完就算完成确认点哪些业务决策必须问人让模型猜业务方还没决定的事步骤并不是禁忌。如果审计必须保留证据链迁移必须按协议顺序执行或者某个示例定义了产品语义它就应该留下。针对已知失败模式的规则也有价值但要用评测和回归验证支撑。强模型时代的提示词不再是把任务拆给模型照做的清单而是一份任务契约目标清楚边界清楚证据清楚未知项的处理方式清楚。至于路线让模型在真实证据里走出来。推荐阅读MoE 的关键不是专家多而是路由稳*Prime Agent 把 Coding Agent 从工具调用推向可恢复工作流Agent Team 真正缺的不是更多 Agent而是同步协议DeepSeek Harness 为什么能热换模型插件依赖、事件日志与回滚机制DeepSeek HarnessAgent 自我改进之前先让 Harness 可观察、可组合、可回滚