背景与动机
和 Claude Code 协作时，真正影响质量的往往不是模型能力，而是任务控制方式。一个模糊任务会让 Agent 自己补齐大量假设；一个边界清楚的任务能让它把能力用在执行和验证上。
任务控制的核心是：让 Agent 先用证据建立判断，再修改文件。
好任务的基本格式
可以用这个结构：
目标：要完成什么。范围：允许改哪些文件或模块。禁止：哪些事情不要做。流程：先搜索/读取/验证，再实现。验收：运行哪些命令，输出什么结果。汇报：说明修改点、测试结果和剩余风险。示例：
目标：修复文章详情页目录高亮异常。范围：只看 src/layouts 和 src/utils/toc 相关文件。禁止：不要重写页面布局，不要改文章内容。流程：先定位当前高亮逻辑和复现路径，再提出最小修复。验收：运行 pnpm check。汇报：说明根因、修改文件和验证结果。纠偏要尽早
如果发现 Claude Code 开始偏离目标，不要等它做完。直接指出：
停一下，这不是我要的方向。当前任务只处理目录高亮，不要改页面布局。请回到刚才读取到的高亮逻辑，重新给出最小修复。纠偏时要说明三件事：
- 错在哪里。
- 当前边界是什么。
- 现在应该回到哪个证据点。
搜索和读取代码的顺序
比较稳的顺序：
先读项目规则再搜关键词再看相邻实现再看调用链最后修改常见提示：
请使用快速搜索工具定位相关文件。不要凭文件名猜测实现。读完相邻模块后再决定修改方式。这样可以避免 Agent 直接创建一套新实现，而忽略仓库里已经存在的工具函数或组件。
验证不是可选项
修改后至少要有一种验证：
- 单元测试。
- 类型检查。
- 构建。
- 页面预览。
- 手动复现步骤。
如果确实无法运行，也要要求它说明原因：
如果无法运行测试，请说明具体阻塞原因，而不是只写“未测试”。常见陷阱
- 没有明确“不要做什么”，导致任务扩大。
- 只看当前文件，不看调用方和相邻实现。
- 修改后不验证，问题留到下一轮。
- 纠偏时只说“不是这个”，没有给新的边界。
可复用任务模板
请按以下流程执行：1. 先读取项目规则和相关文件，不要修改。2. 用 3-5 条说明你理解到的现状和修改点。3. 只实现最小必要改动。4. 修改后运行指定验证命令。5. 如果验证失败，先说明失败原因，再继续修复。6. 最后输出修改文件、验证结果、剩余风险。这类模板适合放在当前对话里；如果它已经成为长期团队规则，再沉淀进项目规则文件。
一句话总结
控制 Claude Code 的关键是把“目标、边界、证据、验证”说清楚，让它少猜、多查、做完能自证。