把话说清楚：让它第一次就理解你

3.1 “它没听懂”多半是”我没说清”

先看一组真实对照。左边是新手常写的提示，右边是官方文档里给出的改写方向：

常见写法	更好的写法
给 foo.py 加测试	给 foo.py 写一个测试，覆盖用户已登出这个边界情况，不要用 mock
修一下登录的 bug	用户切换账号后仍看到上一个账号的订单。怀疑在 session 中间件。先写一个能复现的失败测试，再修
优化这段代码	这个函数在 10 万条数据时要跑 8 秒。目标降到 1 秒以内，不改变对外签名，改完跑 benchmark 给我看数字
重构一下项目	（拆成具体任务，或先进入计划模式讨论）

三条改写里都藏着同样的三个成分：具体的现象、范围的限制、可验证的完成标准。

多位独立实践者的复盘里反复出现同一条建议：不要一次要一个完整功能。

原因和第 1 章的循环有关。一次要五步，它会把五步的猜测全部塞进同一段输出，其中第二步的错误会污染后面三步；而你要纠正，就得把整段推翻。一次只要一步，错误在发生的那一轮就被拦住。

对比一下：

❌ 实现完整的用户通知系统：数据模型、API、前端组件、邮件模板、测试

✅ 第一步：只设计数据模型。给我 schema 和迁移脚本，先不要写 API。
   我确认后再往下走。

一个实用的判断标准：如果你无法在它做完后的两分钟内判断对错，那这一步就太大了。

会话里有几种”直接投喂上下文”的方式，比你用文字转述高效得多：

引用文件和目录——用 @：

@src/auth/session.ts @src/middleware/ 这两处的 session 生命周期是怎么衔接的？

贴报错——直接粘贴完整的堆栈，不要手工摘要。你摘掉的那几行往往正是关键。

管道喂数据——在终端里把命令输出直接送进去：

npm test 2>&1 | claude -p "这些测试失败的共同根因是什么？先不要改代码"

git diff | claude -p "review 这些改动，只指出正确性问题，不要提风格建议"

贴图——设计稿、报错截图、监控仪表盘都可以直接粘贴进会话（macOS 用 Ctrl+V，Windows/WSL 上通常是 Alt+V）。Anthropic 内部团队公开过一个案例：数据基础设施团队排查一次 Kubernetes 故障时，直接把仪表盘截图丢给它来定位问题。

临时跑命令——在输入框以 ! 开头，可以直接执行 shell 命令而不打断对话节奏。

看到它跑偏时，新手的本能是等它说完再解释哪里错了。这是最贵的做法：错误的输出已经进了上下文，你的纠正又追加一段，会话变长，而错误示范还留在里面。

正确的顺序是：

/rewind 可以把对话状态、代码状态或两者一起回退。但有一条必须记住：它只追踪 Claude 通过文件编辑工具做的改动，不包括 Bash 命令造成的改动。它不是 git 的替代品。这就是为什么下一条建议是：动手之前先提交一次干净的状态。

把前面几节合起来，日常任务可以套这个结构：

【现象】用户在未登录状态访问 /orders 时页面白屏，控制台报 TypeError。
【范围】只改 src/middleware/ 下的文件，不要动路由配置。
【要求】先写一个能复现的失败测试，再修，最后跑 npm test。
【交付】把测试输出贴给我，并用两句话说明根因。

四行分别对应：它要解决什么、它不能碰什么、它按什么顺序做、它怎么证明做完了。

你现在的成果：你有了一个提示模板和一个打断习惯。这两样加起来，能消掉新手期一多半的返工。