五个核心习惯

习惯一

让它先问你，别急着让它做

症状

你说"帮我做一个记账的小工具"。十分钟后它交给你一个东西—— 有分类、有图表、有导出、还能多人共享。做得很漂亮。 但你其实只想要一个能记下"今天花了多少钱"的输入框。

你想说"不是这样的"，但又觉得"都做出来了，凑合用吧"。或者更糟：你说"不是这样的"， 它又猜了一个方向，还是不对。

为什么会这样

因为你自己也没想清楚。这不怪你——人本来就是看到具体东西才知道自己要什么。 有句话说得很好：在亲眼看到之前，没有人真正知道自己想要什么。

所以问题不在"你没说清楚"，而在顺序错了： 你说 → 它做 → 你判断，这条路注定要返工。 正确的顺序是：你先被问 → 你想清楚了 → 它再做。

怎么做：把问题倒过来

不要让 AI 直接干活。开场就要求它反过来问你问题—— 一次问一个，你答完它再问下一个，直到它觉得没有歧义了才动手。

这听着简单，但效果非常夸张。它逼着你在动手之前把脑子里模糊的地方一个个想清楚， 而这些地方，正是你后面会返工的地方。

它该问出什么来

如果它问得好，你会听到这类问题——这些问题本身就是价值：

• "这个东西是给谁用的？只有你自己，还是别人也要用？"
• "数据要存在哪？关掉再打开，之前记的东西要还在吗？"
• "如果用户填了一个空的数字，你希望怎么处理？"
• "你说的『分类』，是固定的几个选项，还是可以自己加？"

每个问题都在替你消掉一个模糊地带。这一轮问完，你脑子里那个东西才第一次真正成形。

习惯二

一次只做一小片，做完立刻验证

症状

你说"帮我加一个登录功能"。然后它一口气写了十几个文件：界面、后端接口、数据库表、 密码加密、错误提示、记住登录状态……写完之后你点了一下，崩了。

先把这句话翻译成人话：登录看起来只是两个输入框，背后却要查数据库 （去存用户资料的表里找这个人）、核对密码（而且密码不能原样保存， 要先加密成别人看不懂的样子），还要记住你登录过。任何一环没接好，整个功能都会崩。

然后就是长达数小时的折磨：它改一个地方，另一个地方又崩。你越来越怀疑自己是不是太笨。

为什么会这样

因为 AI 有一个很强的本能：想一次给你一个"完成的方案"。 它脑子里有一个"已经写好的登录功能"的样子，于是一跃把全部写出来， 中间从没验证过任何一个假设。

结果就是：十几个文件里可能有五处假设是错的（你的数据库字段名不一样、你的 项目用的是另一种写法……）。五处错误同时存在， 它们还会互相影响，你根本不知道该从哪查起。

这个毛病有个很形象的说法——开出了车灯照射范围。车灯只能照到前面五十米，它却按一百五十米的速度往前冲。

怎么做：切一小条纵贯线

不要"横向地一层层建"，要"纵向地切一小条"。

"一小片"的标准是：窄到可以一次做完，但完整到能亲手跑一遍看见结果。

还是用登录举例，一个好切法是这样的：

1. 先做一个假的输入框

   只有两个框和一个按钮。点按钮，屏幕上弹一句"你输入了 xxx"。跑一遍，对了。

2. 再把"点按钮"接到一个固定的判断上

   写死一个用户名密码，输对了就跳转。跑一遍，对了。

3. 再把判断接到真实的数据库

   现在真的去查了。跑一遍，对了。

4. 最后才加加密、错误提示、记住登录

   一次加一个，每加一个跑一遍。

看出区别了吗？每一步都是完整的（能点、有反应）， 但每一步都很小（出错范围一目了然）。 而且从第 1 步开始，你就已经能看到东西了——不用等到最后。

习惯三

一个会话只干一件事，到点就重开

症状

你在同一个对话里，连着干了三件事：先修了个小 bug，然后加了个新功能，接着想让它美化一下界面。 第三件事的时候，它开始不对劲了——改这儿坏那儿，你说过的要求它当没听见。

为什么会这样

回到第 4 章那张图：上下文是张工作台，只会越来越满。 你做的前两件事并没有"结束"，它们还堆在桌上。 到第三件事时，它要在两千字的混乱里找你的要求——找不到很正常。

怎么做：把「开新对话」当成一个正常动作

判断标准很简单：一件事做完、要开始另一件事了，就开新会话。

而上一件事的结论不会丢——你要做的只是交接：

1. 让它写一份交接说明

   在旧会话结束前，让它总结：我们做了什么、改过哪些文件、还有什么没做、下一步该干嘛。

2. 把这份说明存成文件

   比如叫 进度.md。存在项目里，新会话能直接读到。

3. 开新会话，先让它读这份说明

   新会话是张干净的桌子，然后你把这一份必要的东西放上去。不多不少。

三种「清桌子」的力度

如果你用 Claude Code：三个命令分别对应哪一种可选

压缩是 /compact，清空是 /clear， 重开那一步可以借助 /handoff——它把你手上还没落地的工作打包成一份能带走的文件。

容易搞反的地方：/handoff 不是“会话总结”。 只有工作要出门时才需要写文件——换工具、换目录、交给同事。 同一个工具里接着干，/compact 就够了。

三者更细的分工见技能档案 · 会话管理。 不用 Claude Code 的读者可以跳过这一框，上面的三种动作照样适用。

习惯四

把「完成」定义清楚，然后亲手跑一遍

症状

AI 说"已经完成，现在登录功能可以正常工作了"。你打开一看，好像是有个登录框。 但你不确定它到底做完了没有——万一点下去报错呢？万一密码根本没验证呢？

为什么会这样

两个原因叠在一起：

• 它说的"完成"是个模糊概念。它写的代码确实写完了，但不等于你要的功能实现了。
• "验证"这一步被默认交给了读代码。而你不读代码——于是验证这一环直接消失了。

怎么做：开工前先定标准

在让它动手之前，先让它说清楚"怎么样算做完了"。 这个标准要具体到你能亲手试。

做完之后，就照这份清单一条条点一遍。你是用户，用户验收的就是行为。

还要加一步：存档

每次你确认"现在是对的"，立刻存个档（第 3 章讲的 Git 提交）。 这样接下来无论 AI 怎么改，你都有一个确定的退路。

习惯五

让 AI 审 AI

症状

你隐约觉得不太对：这个项目里好像存了密码、有些地方一改就崩、 代码文件越来越多你完全不知道哪个是干嘛的。 但你既看不懂代码，也不知道该问谁。

为什么会这样

回到第 1 章那张图：代码质量是你不该亲自判断的事。 但"不该你判断"不等于"没人判断"——否则问题就会一直积压，直到某天爆发。

解决办法很巧妙：换一个 AI 来审。

怎么做：开一个干净的会话专门挑错

审查出来的问题，不要就地修——把它当成新的小任务， 回到习惯二，一片一片来。