和智能体沟通的 6 个习惯
同一个智能体，有人用得顺手，有人天天返工，差别多半在沟通方式。这一课用「差的说法 vs 好的说法」对比，讲清六个能立刻用上的习惯。
学完这一课，你能
- 能把模糊的想法改写成带验收标准的任务描述
- 能给出恰当的约束和上下文，而不是让智能体猜
- 知道什么时候该让它先出计划，什么时候可以直接动手
- 能用「先读再改」「小步迭代」和「要求验证」减少返工
做完番茄钟你可能已经发现：智能体既不是搜索框，也不是会读心的助手。它更像一位能力很强、但刚入职、对你的项目一无所知的同事。你交代得越清楚，它交付得越准。
好消息是，这些沟通技巧不玄学，总结起来就是六个习惯。每个习惯我都配上「差的说法」和「好的说法」的对比，你可以直接模仿。
习惯 1：说目标，也说验收标准
「改好看一点」「优化一下」「修个 bug」，这些话的问题在于：它不知道怎样算做完，你也不知道。 于是它改完说「已完成」，你一看不对，来回拉扯。
差的说法：
把番茄钟优化一下好的说法：
番茄钟现在在手机上按钮太小，不好点。目标：在 375 像素宽的屏幕上，
三个按钮每个至少 44 像素高，并且一行排得下、不换行、不溢出。
改完后用浏览器的手机模拟模式检查并告诉我结果。好的说法里有三个要素：现状（哪里不好）、目标（改成什么样）、验收（怎么证明）。 当你实在不知道验收标准是什么，可以反过来问它：「你觉得怎样验证这个改动是对的？」
习惯 2：给约束和上下文
约束是「不要做什么、必须遵守什么」，上下文是「它不知道但需要知道的背景」。智能体能读你的文件，但读不到你的脑子。
差的说法：
加一个计数功能好的说法：
在 @app.js 里加一个「今日完成番茄数」的计数，显示在 @index.html 的倒计时下方。
约束：
- 继续只用原生 JS，不引入任何库；
- 数字存在浏览器的 localStorage 里，刷新页面不丢；
- 每天零点之后重新从 0 开始；
- 不要改动现有计时逻辑。几个技巧：
- 在 Claude Code 里输入
@加文件名，可以直接把那个文件放进对话，省得它去找； - 有截图（报错、设计稿）直接拖进终端窗口，一图胜千言；
- 报错信息要原文贴，不要转述成「好像是数据的问题」；
- 经常重复的约束（比如「所有注释用中文」「不要引入新依赖」），别每次都说，写进项目的说明文件 CLAUDE.md，它每次启动都会读。具体怎么写，见CLAUDE.md 与记忆一课。
习惯 3：先计划，后动手
上一课你已经试过了。这里补充什么时候该计划，什么时候别计划。
官方的最佳实践文档给了一个很实用的判断：如果你能用一句话描述这次改动的差异，就别折腾计划，直接让它做。 改错别字、重命名一个变量、加一行日志，直接说。
需要先计划的场景：
- 改动会涉及多个文件；
- 你对做法没把握（该用什么方案）；
- 你不熟悉它要动的那部分代码。
差的说法：
给我的网站加上用户登录好的说法：
我想给网站加用户登录。先不要写代码，请先：
1. 读一下现有的项目结构；
2. 列出你推荐的 2 种做法，各自的优缺点和对项目的改动范围；
3. 推荐一种，并说明需要我提供什么信息。
等我选定后再开始。实操上，按 Shift + Tab 切换到计划模式（状态栏显示 plan mode），它只读不改，直到你批准计划。
习惯 4：小步迭代
一次交给它一个大任务，出错的位置就藏在大量改动里，你很难审阅，也很难回退。把任务拆成每一步都能独立验证的小块，每块做完检查、保存，再做下一块。
差的说法：
给我做一个带用户系统、文章发布、评论和后台管理的博客好的说法：
我们分步做一个博客。第一步：只做首页，显示三篇写死在代码里的示例文章标题和摘要。
不要做登录、评论、数据库。做完我在浏览器里看一眼，没问题再说下一步。小步迭代有个附加好处：当你发现它走偏时，成本很低。官方建议尽早纠偏：看到它开始往错误方向走，立刻按 Esc 打断，保留已做的工作再改口。
还有一条经验规则：如果同一个问题你已经纠正了两次还没改对，别继续在这段对话里修补。 输入 /clear 清空对话，把你学到的教训写进一条更具体的新提示词，重新开始。对话里堆满失败的尝试，反而会干扰它。
习惯 5：让它先读，再改
智能体最危险的状态是「凭印象写代码」。它没读你的文件就动手，会重复造轮子、风格不一致，甚至覆盖你已有的东西。
差的说法：
给番茄钟加一个提示音好的说法：
给番茄钟加提示音。动手前先读 @app.js，告诉我现在的计时结束时在哪里切换阶段，
以及项目里是否已经有任何声音相关的代码。然后说明你准备把提示音加在哪个函数里，
等我确认再改。「先读再改」还有一个用法：让它参照现有的写法。 比如「看一下现有按钮是怎么写的，新加的按钮保持同样的风格」。这能让新增内容和旧代码长得一致，减少你后续整理的工作。
如果它根本不需要读文件（比如只是问概念），可以反过来用：「不要读任何文件，只凭你的知识回答」，省时间。
习惯 6：要求它验证
这是六个习惯里最重要的一个。官方最佳实践里的说法很直接：给它一个可以运行的检查，是「你得盯着看」和「你可以放手」的区别。没有检查，它判断完成的唯一依据就是「看起来差不多」，你就成了那个验证环节。
差的说法：
修复倒计时显示错误的问题好的说法：
倒计时在 1 分钟以内会显示成 0:5 而不是 00:05。请：
1. 先复现这个问题，说明是哪里导致的；
2. 修复；
3. 验证修复结果：把格式化函数在这些输入下的输出列给我看，
59 秒、60 秒、61 秒、0 秒、1500 秒，预期分别是 00:59、01:00、01:01、00:00、25:00；
4. 展示验证的证据（运行输出），不要只说「已修复」。验证的形式因任务而异：
| 任务类型 | 可以让它做的验证 |
|---|---|
| 纯逻辑（计算、格式化） | 写几个测试用例并运行，列出输入和输出 |
| 页面改动 | 说明在浏览器里点哪些地方、应该看到什么；有条件的话截图对比 |
| 修 bug | 先复现，再修，再证明不再复现 |
| 重构 | 改前改后跑同一组测试，结果一致 |
养成一个习惯：让它交出证据，而不是结论。 看测试输出比重新检查一遍快得多。如果你无法验证，那就先别发布。
六个习惯，一个万能骨架
把它们压缩成一个可复用的模板：
目标：（一句话说清要达成什么，以及现在哪里不对）
背景：（它需要知道的上下文，相关文件用 @ 引用，报错贴原文）
约束：
- （不能做什么，例如不引入新依赖、不改某个文件）
- （必须遵守什么，例如沿用现有风格）
做法：先读相关文件并告诉我你的理解；如果改动涉及多个文件，先给计划等我确认；只做这一小步，不要顺手扩展其他功能。
验收：（怎样算完成，可以检查的具体标准） 完成后请运行验证，并把验证的输出或结果展示给我。
不是每次都要把所有格子填满。小改动三四句话就够；大改动才需要把骨架填完整。判断标准是：如果这件事交给一位新同事，没有这些信息他能做对吗？
常见的沟通误区
- 道歉式提示：「不好意思麻烦你帮我看一下……」。不需要客套，直接说事；
- 一次塞三件不相干的事：对话里的上下文是有限的，互不相干的任务混在一起会互相干扰。官方建议在无关任务之间用
/clear重置； - 把「不要」说得含糊：「别搞太复杂」没有信息量，换成「不要引入新依赖，总共不超过 150 行」；
- 盲目全盘接受：它说完成了，你就默认完成了。回到习惯 6；
- 长期依赖口头约定：反复提醒同一条规则，说明它该被写进 CLAUDE.md，或做成权限设置。后面的权限管理与上下文管理两课会教你。
下面哪条提示词最符合「说目标和验收标准」？
你已经让智能体修同一个 bug 两次，每次都没有修对，对话已经很长了。最推荐的做法是？
动手试一试
拿上一课的番茄钟练习，每个习惯做一次：
动手清单
0/7参考来源
- Best practices for Claude Code（Claude Code 官方文档）
- Common workflows（Claude Code 官方文档）
- Permission modes（Claude Code 官方文档）
- Interactive mode（Claude Code 官方文档）
工具更新很快，若与官方文档不一致，以官方为准。
学完了吗？
标记完成会记录在本机浏览器，计入你的学习进度和连续天数。