第 8 章 · 把需求说清楚
用好 Coding Agent，最重要的技能不是编程，而是把需求说清楚。这一章的四节分别讲：怎么提需求、怎么安排工作流程、怎么控制上下文和费用、怎么保证安全。
把 Agent 当成一个新同事
想象 Agent 是一个能力很强、但第一天来上班的新同事：
- 它会写代码，速度很快；
- 但它不知道你的背景：项目是给谁用的、你喜欢什么风格、之前讨论过什么；
- 它不会读心：你没说的，它只能猜；
- 它很少主动拒绝：需求有歧义时，它往往会按自己的理解直接做下去。
所以，你跟新同事交代任务时会说清楚的事情，也要跟 Agent 说清楚。
好需求的六个要素
| 要素 | 问自己 | 例子 |
|---|---|---|
| 目标 | 要做成什么样？ | 在明细列表里加一个"只看支出"的筛选按钮 |
| 背景 | 为什么要做？给谁用？ | 支出记录太多时，我想快速看看钱花在哪 |
| 具体要求 | 细节是怎样的？ | 三个按钮：全部 / 只看收入 / 只看支出，默认"全部" |
| 验收标准 | 怎么算做完？ | 切换后汇总数字不变，只有列表变化；刷新后恢复"全部" |
| 限制 | 有什么不能做？ | 不要改动数据的保存格式 |
| 输出形式 | 希望它怎么回复？ | 先说打算怎么改，我确认后再动手 |
不是每次都要六样齐全。小改动说清目标就够了；越大、越重要的任务，要素越要写全。
对比：模糊的需求 vs 清楚的需求
| ❌ 模糊 | ✅ 清楚 |
|---|---|
| 优化一下这个页面 | 页面在手机上字太小、按钮太挤。把正文字号调到 15px 以上，按钮高度至少 40px，其他不要动 |
| 修一下 bug | 点"删除"没反应，控制台报错 Cannot read properties of null，在 app.js 第 142 行。帮我找原因并修复，修完告诉我原因 |
| 改好看点 | 整体配色换成浅绿色系，卡片加一点圆角和阴影，参考苹果"备忘录"的简洁风格 |
| 加个导出功能 | 加一个"导出 CSV"按钮，导出当前月份的记录，列依次为：日期、类型、分类、金额、备注。文件名用"小账本-2026年9月.csv" |
| 帮我看看这个项目 | 我刚接手这个项目，先不要改任何东西。告诉我：它是做什么的、主要有哪些文件、每个文件负责什么、怎么运行它 |
几个实用技巧
用 @ 指明文件
与其说"那个样式文件"，不如直接 @style.css。Agent 不用去猜、去搜，又快又省 token。
让它先问你
text
……（你的需求）……
有任何不清楚的地方，先问我，不要自己猜。这一句能避免很多"做出来才发现理解错了"的情况。
告诉它你的水平
text
我是编程新手，请用简单的话解释你做了什么，专业名词第一次出现时解释一下。写进 CLAUDE.md / AGENTS.md 里，就不用每次都说了。
给例子
"日期格式要好看一点"不如"日期显示成：9 月 29 日 星期二"。一个具体的例子，胜过一段描述。
一次只说一件事
"加筛选按钮、改配色、修删除的 bug、再加个导出"——四件事混在一起，Agent 容易顾此失彼，出了问题也分不清是哪一步造成的。拆开，一件一件来，每件做完提交一次。
想学东西时，让它"教"而不是"做"
text
先不要改代码。告诉我要实现这个功能需要改哪些地方、为什么，
我想自己试着改，改完你帮我检查。一个万能模板
拿不准怎么写时，套用这个模板：
text
【目标】我想……
【背景】因为……
【要求】
1. ……
2. ……
【验收】做完后应该能……
【限制】不要……
先告诉我你打算怎么做，我确认后再开始。有不清楚的地方先问我。把常用的需求写成 Skill
如果某类需求你经常提（比如"帮我审查代码""帮我写测试"），而且每次都要交代一堆要求，就把它写成 Skill（见 第 6 章）。
下一节：靠谱的工作流程