双提示：为什么你的 AI 任务交接总是失败
不久前，一位同事运行了我写的一个任务，结果却出错了。不是那种微小的偏差——它重构了一个我从未提过的文件。模型本身没问题，问题出在我的提示词上：我写了一套指令，却要同时面对两个完全不同的读者。
两个读者，同一份提示
当你把一个 AI 任务交给别人——他们在自己的 Claude Code 或 Codex 订阅上运行，然后把结果发给你——你其实是在对两个对象说话。人需要知道这是什么、为什么重要、“完成”长什么样，以及发回结果之前应该检查哪些东西。而 AI 代理需要的是精确的作用范围、硬性约束、涉及哪些文件或系统，以及绝对不能碰的部分。
一份提示同时服务两者，结果往往是对代理来说太含糊，对人来说又挤满了术语。第二个失败代价更高：如果对方看不出输出是否正确，就会不检查直接转发。你的审查就成了唯一的关卡，委派任务的意义也就完全失去了。
拆分后的样子
这是我过去常写的版本：
Clean up the analytics module and make sure the tests pass.
Should be quick.
而下面是同一个任务，为两位读者分别写的版本：
## For you (the human)
We're removing the last of the legacy event names before the
rename ships Friday. There are 11 call sites.
Done looks like: `rg "track_legacy" src/` returns nothing, and
the analytics test suite is green.
Before you send it back, check the diff does not touch
src/analytics/schema.ts — another team owns that file and
changing it will block the release.
## For the agent
Scope: src/analytics/ ** , excluding src/analytics/schema.ts
Task: replace every `track_legacy(<name>)` call with `track(<name>)` , preserving arguments and ordering.
Constraints:
- Do not modify schema.ts
- Do not reformat or touch unrelated lines
- Run `npm test -- analytics` ; report failures rather than
fixing ones outside this scope
"给你的那一半"比看起来更重要。人的本能反应是跳过它——反正人也会把代理那一半粘贴进去，对吧？但"给你的那一半"能做到代理那一半做不到的事：它给执行者足够的上下文，让他们有能力拒绝一个坏结果。代理会自信地交回一个看似合理的东西。如果运行它的人根本不知道"正确"长什么样，"看似合理"和"正确"就无法区分。一句话——"检查 diff 没有触及 schema.ts"——就把被动的传声筒变成了真正的审查者。这就是写后半部分的全部回报。
底层的制约
这种模式之所以存在，是有原因的。你不可能在不交出登录凭证的情况下，把任务交给别人的 Claude 或 Codex 订阅去跑。所以工作必须以"指令"的形式传递，而不是以"访问权限"的形式——这正是写作质量如此重要的原因。有共享访问权限时，你可以在运行中途纠正方向；而在交接场景下，提示词就是全部界面。
我们一直在 Rockbite Games 围绕这种工作形态构建 Wagglet（声明：我在那里工作）。双提示是我们反复手工推导出来的模式，直到我们把它设为任务的默认结构。想了解更详细的推理过程，有关于双提示的文章；想看看它在端到端流程中的位置，有完整的"请求到交付"工作流。要直接接入代理，还有 MCP 端点。不过，使用这种模式并不需要这些——它只是 markdown 文件里的两个标题而已。
一份大致可行的检查清单
在把任务交给别人运行之前：
- 他们能否在不问你的情况下判断结果是否有误？
- 你是否至少点名了一件绝对不能改变的东西？
- 范围是否以路径和系统的形式写明，而不是用一段描述带过？
- 你是否说明了失败时该怎么办——上报，还是修复？
- 三天后他们再看这份提示，是否仍然看得懂？
如果其中任何一项是否定的，提示词就没有写完。它只会以错误的形式返回来，而你会怪罪模型。
The dual prompt: why your AI task handoffs keep failing
不知道有没有人也想出了同样的拆分思路，或者有更好的办法——尤其是那些在团队里做任务交接，而不是单打独斗的人。