给 Claude Code 派活别许愿，五件套写一张能验收的任务单

同一句提示词，昨天 Claude Code 干得漂漂亮亮，今天跑偏到你怀疑人生。这种事我经历过太多次，复盘下来发现，问题多半不在它，在我给的那句话。那句话太像在聊天框里许愿，不像在给同事派活。

算一笔体感账。「帮我修一下登录」这种话发出去，它只有两条路，要么反问你一堆，要么自己满仓库翻，猜一个改了，改错地方还得重来。而「把登录页这个报错修掉，只改这个文件，改完跑一遍测试给我看」发出去，它立刻知道该干嘛。差距不在模型，在任务单。

Anthropic 给 Claude Code 的定位是代理式编程环境，它会自己读文件、跑命令、改代码，一路把问题解决掉。你敲下去的那段话，决定它读哪些文件、要不要先做计划、能不能动文件、改完怎么验证。这不是聊天，是派活。这篇给一张我天天在用的任务单模板，五件套，加三组逐字改写。

五件套，把模糊翻译成工程

先说这张任务单的五样东西。

目标，回答我要达成什么结果，缺了它就随便交付一个像样的东西。背景，回答这是什么项目、现在什么问题、为什么改，缺了它只能从文件名瞎猜你的意图。输入，回答该读哪些文件，缺了它满仓库搜索，慢、费 Token、还可能找错。限制，回答不能碰哪里，缺了它越界改你不想动的地方。验收，回答怎么算干完，缺了它交回来一堆你没法判断对错的东西。

五件套不是让你填表，它的作用是提醒你别漏，落笔照样写大白话。官方文档里的优秀示例全是自然句，用户反馈会话超时后登录失败，查一下 src/auth 里的认证流程，先写一个能复现问题的失败测试再修。一句话里五件事全齐，读起来就是句正常的人话。心里过一遍清单，落笔说人话，这是正确姿势。新手最大的毛病，是只写一句「优化一下」，剩下四件全靠它猜。长短不用纠结，看任务大小，但五件都要齐，三百字写齐五件，好过一千字只写目标。

三组改写，照着抄就能用

修 bug、加功能、重构，三个最高频场景，每组给你模糊版和工程版。

修 bug，新手写法是「我的登录有问题，帮我修一下」。改写成工程任务，大概长这样。

用户反馈会话超时后再点登录没反应，刷新页面才恢复。

这是线上 Next.js 站点，Chrome 正常，主要出现在 Safari。

相关逻辑在 @src/lib/auth.ts 和 @src/app/login/page.tsx。

不要改 signIn 的函数签名，不要引入新依赖。

先写一个能复现问题的失败测试，再修到测试通过，

改完告诉我动了哪些文件、跑了哪些验证。

这一组里最值钱的是最后那句，先写失败测试再修。

给它一个能自己验证对错的标准，是提示词里投入回报最高的一件事。

有了「红变绿」的目标，它就不会拿一个看起来对、其实没修好的版本糊弄你。

加功能，新手写法是「给我加一个头像上传」。它要替你做一连串决定，存哪、限不限大小、要不要裁剪。改写的关键有两句，一句是「风格、错误提示都参考 @src/components/FileUpload.tsx，不要另起一套」，官方管这叫指向已有模式，跟装修师傅说新柜子照客厅那个做是一个道理。另一句是「只接受 jpg 和 png、单张不超过两兆、超限给中文错误提示」，把每个决定提前钉死。

重构，风险最高，因为要动在跑的代码。新手写法是「这段代码太乱，帮我重构写好看点」，乱和好看都不可验证。工程版要钉死三件事，把两百行的 calculateOrder 拆成职责单一的小函数，这是目标。对外入参、返回值、函数名都不许改，其他文件不碰，这是限制。现有测试先跑通当基线，重构后必须依然全过，这是验收，也是「行为没变」唯一的证明。

动重要代码之前先 git commit 留个还原点。Claude Code 自带的检查点只跟踪它自己的改动，管不住你手动跑的脚本和装的依赖，护身符永远是 git。

上下文别硬塞，限制别写虚

五件套里新手最常给错的，是背景和输入这两件，要么不给，要么一股脑全倒。

Claude Code 的上下文窗口会被填满，越满表现越差，塞一堆无关材料等于把它的工作记忆挤爆。给法用 @ 引用，@ 一个文件是当场把全文塞进上下文，@ 一个目录只给文件清单，@ 的时候它还会顺带把项目的 CLAUDE.md 拉进来。我的用法很固定，@ 上 README 和 package.json 给它全局视角，再 @ 这次要动的那一两个文件，千万别 @ 整个 src 目录。又长又不一定用的设计文档别用 @ 钉进去，写一句「需要时去 docs 里查」，让它要用的时候自己读。

任务大就先让它复述。先只读这几个文件，告诉我你理解的目标、现状的问题、打算怎么改，先别动任何文件。它复述的过程就是暴露误解的过程。

任务大到你自己都没想清楚，反过来让它访谈你。我想做一个会员后台，请你用提问的方式访谈我，把技术、交互、边界、取舍都问清楚，专挑我没想到的难点问，问完整理成一份 SPEC.md。聊完开一个干净的新会话照着执行，实现会话的上下文就全用在干活上。你越说不清要什么，越要让它先问、别让它先做。

限制这边，一句「注意安全」等于没说，要翻译成这次任务里具体不能碰什么。改代码就是不改数据库迁移文件、不新增依赖、改动别超出指定文件。限制还要可验证，「保持整洁」它听得懂但落不了地，「每个函数不超过三十行」它就能照做。真正不能破的红线，用 IMPORTANT、YOU MUST 这类强调词点一下，遵守度会高一些。

验收是回报最高的一件

五件套里只能写好一件的话，写验收。

验收要能客观检查。「改好看点」不行，「移动端按钮不换行、桌面端布局不变、相关测试通过」，行。「优化性能」不行，「首屏接口从八百毫秒降到三百毫秒以内、附前后对比」，行。还有个动作很值钱，让它出示证据而不是报喜，改完把测试输出和你跑过的命令贴给我看，你审证据比自己重跑一遍快得多。

放手让它干大点的活，可以再进一步，把写和审拆开。让它开一个子任务，只看这次的 diff，对照验收标准逐条检查，缺哪条指出来。审查的分身看不到「为什么这么写」的自我辩护，挑得比本人狠。但要记住，审查者被要求找毛病，就一定会找出毛病，指令里要写死只报真影响正确性的，风格偏好不用提，不然它会把你的代码越改越复杂。

写不出验收标准，说明任务还没想清楚，先让它帮你把目标拆成一张可验收的清单再开工。唯一的例外是纯探索，你就想摸摸底看看思路，那故意说开放一点反而好。

跑偏了怎么救，练一周就上手

先答一个高频纠结，先计划还是直接干。拇指法则一句话，这个改动你能不能用一句话把 diff 描述出来。能，直接干。不能，比如重构整个结算模块、给老项目迁框架，先按 Shift+Tab 进计划模式，或者单条指令前加 /plan，让它只读不改先出路线图，你批准了再动手。

跑偏之后，官方的提醒是第一反应不该是换模型，是回看任务里漏了什么。症状对得上药方。它反复问你到底要 X 还是 Y，是目标背景不清。改了你没让改的文件，是限制不清。满仓库乱翻，是输入不清，用 @ 点文件。产出一堆没法判断对错，是验收缺失。纠偏要趁早，按 Esc 当场叫停重新指方向。纠偏的时候别只说「你理解错了」，要指出错在哪个具体现象，你把参考文章当成要改的文件了，你动了 frontmatter 我只让你改正文。反馈越具体，下一轮越好。同一个问题纠正超过两次还不对，别再纠了，上下文已经被失败的尝试污染了，跑 /clear 清空，换一条更具体的新提示词重开。干净会话加好提示词，几乎总是赢过长会话加反复纠正。

最后给一条一周练习路径。第一天只练只读任务，让它读目录、复述结构、列风险，不许改文件。第二天小范围改，只动一个文件，改完说明变化和验证方式。第三天故意丢一条写得很烂的任务，让它指出缺哪几件信息再帮你改清楚。周末把每次都要重复讲的背景挪进 CLAUDE.md，之后提示词自然就瘦了。老雷的建议是再养一个小习惯，每次跑通一条任务，把真正管用的那条提示词存下来，下次复用微调，你的提示词能力就从临场发挥变成了可复用的资产。

说到底就一句话，不要让它猜你的目标。五件套变成肌肉记忆，你和 Claude Code 的协作就稳了。老雷见过不少团队把 AI 编程用不起来，回头看，多半不是模型不行，是派活的人从来没把话说明白过。