AI写代码总返工?换种派活方式

上周让 Claude Code 做一个登录页。

我说了一句”做个登录页，前后端都要”，然后就出门吃饭了。回来一看，前端改了，路由改了，状态管理也改了，连数据库 schema 都被动了。测试没有，鉴权逻辑里还埋着一个 bug。

我花了两个小时审代码，又花了一个小时改回来。比自己写还慢。

那天之后我想明白一件事：问题不在 AI，在我把活派错了。

我现在不”让 AI 帮我写代码”。我让它替我交付功能。这两件事完全不一样。

下面是我现在的做法。

一、别给一句话，给一份能直接上手的活

派活之前,我会花时间写一份 Issue。里面至少包含三件事：

哪些文件能动，哪些不能动。这一句最关键。AI 不知道你的代码库哪里是雷区。你不写，它就会顺着改。

给它看哪几个参考。比如”参考 src/api/user.ts 的写法”，”接口规范看 docs/api.md”。AI 不会自己读完整个仓库，它需要你指。

怎么算完成。不是”做完登录”，是”跑通这三个测试用例：正确密码登录成功、错误密码返回 401、未输入用户名提示校验”。

写这份 Issue 的时间，差不多等于我自己写代码的时间。一开始我觉得亏。后来发现这是个杠杆——一份好 Issue，AI 可以自己跑两三轮，我只是在审结果。

二、别让它一次干一整个模块，切薄一点

不要一次给 AI 一个”用户中心”。要把它切成一片一片：

第一片：前端按钮、后端接口、数据库存一行记录，从上到下打通。哪怕功能很简单，比如就是登录返回一个成功。

第二片：加密码校验。

第三片：加错误提示。

第四片：加记住登录状态。

每一片都是从前端走到数据库的一条完整路径。AI 拿到一片，自己就能闭环。

我以前的习惯是横着切——前端任务、后端任务、数据库任务，分开派。这套是给人用的，方便人分工合作。给 AI 不行。AI 没办法跨任务保持上下文，它写前端的时候，不知道后端那个接口是什么形状。

竖着切，每一片都小且完整。这是 AI 能消化的最小单位。

三、让它先写测试，再写代码

这一步是我现在最依赖的。

流程是这样：

AI 接到一片任务

先根据需求写测试。这些测试一开始全是红的

然后写代码，目标就一个：让测试变绿

绿了，自动提交

为什么有效？因为 AI 没有”我觉得差不多了”这个状态。它会脑补自己干完了。测试就是它的红绿灯，绿了才算完成。

我自己定了一条规矩：没有测试的代码，AI 不能 commit。

一开始觉得这条规矩很麻烦，写测试也要时间。后来发现返工率降了一大截。原来一晚上能交付的活，现在能交付两三倍。因为不用反复回头改。

四、从你盯着，到它自己跑

不要一上来就追求”放手跑”。

第一阶段，你在旁边看着。关键是：当你看到它卡住的时候，不要伸手改代码。改提示词，改 Issue 的描述，改你给它的规则。

我自己有个习惯——每次 AI 卡住的地方，我都问一句：下次同样的问题，怎么让它自己绕过去？答案大部分时候是：上一次的 Issue 写得不够清楚，或者代码库里的某条规则没写下来。

我把这些规则攒到一个文件里，每个新项目都带着。它会越来越厚，AI 也会越来越少踩坑。

第二阶段，让它在你睡觉的时候跑。当你的 Issue 模板和规则文件稳定下来，就可以批量派任务，自己睡觉去。早上起来审 PR。

我现在大概在第二阶段的早期。一晚上能跑完三四个小切片。不多，但是是复利——每多一条规则，下一晚跑得就更顺一点。

五、代码库要让 AI 能照葫芦画瓢

这一条最反直觉。

我们以前写代码追求”巧”。一个问题一个写法，看谁的方案更聪明。

给 AI 用，要反过来——你要的是一致。

如果 A 模块这么写，B 模块也这么写，C 模块还是这么写，那 AI 看了 A 和 B，就能猜到 C 该怎么写。它的成功率会高得吓人。

我现在写代码会刻意保持一致：

文件目录结构一样

命名习惯一样

错误处理方式一样

接口返回格式一样

不是为了好看，是为了让 AI 抄作业更容易。

这一条还有一个隐含的意思——你自己的基本功不能丢。AI 抄作业的前提，是你先写出一份好的 A 文件给它抄。架构怎么搭、模块怎么分、抽象在哪一层，这些事 AI 还干不了，你得自己来。

最后

写到这里我自己梳理了一下，这套打法其实就是把”写代码的我”换成了”管生产线的我”。

以前我是写每一行代码的人。现在我写的是规则、边界、测试标准。代码 AI 来写。

不会一夜之间切过去。我自己花了三个月，才让一个项目真的跑起来。中间放弃过两次，觉得还不如自己写。撑过去之后才有复利——你睡觉的时候，活在做。

下一篇想写一下，一份让 AI 一次跑通的 Issue 长什么样。我会把自己的模板贴出来。

如果你也在试这条路，欢迎交流。