你是不是也这样：让 AI 开始写代码前，想了一大堆功能细节，也和 AI 讨论清楚了。
这时候你以为方向定了，AI 能顺着你的想法一步步往下做。
直到做出一个惊艳所有人的项目。
可是结果呢，AI 要么做了一堆没意义的功能，要么就是你想要的功能又没做到位。
你又看不懂代码，没法自己核对，只能一遍遍让它改。
改完它说“差不多了”，你跑起来一试，还是对不上。
来回好几轮，代码眼看越来越乱，心里越来越没底。
最后耐心和精力耗光，要么重构，要么就放弃这个项目。
一天一个 vibe coding 小技巧，今天讲：AI 开始写代码之后，怎么一个阶段一个阶段往前推，还不让它中途跑偏。
本小节属于开发流程总结篇的内容，我拆成上下两篇，这是下篇，还没有看过上篇内容的建议回头先去看看（《全流程总结（上）》）。
在上小节中，我主要讲的是动手写代码之前，怎么先把地基和规矩立好。
今天讲后半段——真正开始写功能之后，怎么驾驭好 AI。
对于很多没有技术背景的人来说，AI 可以说是一把尖刀了，但同时它又像是一匹极难驾驭的野马。
所以，很多人在让 AI 写功能代码的时候，基本都像在开盲盒。
但实际上，要想驾驭好 AI 做项目，就两件事：
第一，把当前要做的大阶段，拆成一份足够细的实施文档。
第二，让 AI 照着这份文档一阶段一阶段往前推，每个阶段都验收，防止它跑偏。
第一步：把大阶段，拆成详细的实施真源文档
在之前的立项精讲小节中我已经讲过，项目需求要先拆成大阶段来开发。
但只停留在大阶段还不够，真正开写之前，还要把当前这个大阶段，继续拆成能落地的子阶段。
先说为什么还要再拆一层。
大阶段通常都很粗。
不管你是在阶段计划里排过，还是脑子里定过“先做哪一块”，都一样。
比如“阶段一，做一个买家能下单付款的最小可用版本”。
这一句话，你直接丢给 AI，它会怎么做？
它会自己脑补：先做什么、后做什么、做到什么程度。
脑补出来的，往往不是你要的。
而且，就我个人真实体验下来，AI 是真的会偷懒的，你就这么一句话甩给它，它会觉得你可能就是想测试一下，然后给你快速写一堆东西出来，但实际上毫无意义。
所以，在真正写代码之前，要给每个大阶段，配一份足够细的实施文档。
细到什么程度？
一个大阶段，可以先拆成几个子阶段。
每个子阶段，再往下拆成一个个步骤，比如第一步、第二步、第三步。
但注意，不是越细越好，而是细到 AI 知道三件事：
这一段到底要做什么。
做到什么才算完成。
哪些东西现在先不要碰。
验收标准和验证方式，也要一起写进去。
说白了，每一步都要能执行、能验收、有边界。
前提是，每次开工前，你都明确要求 AI 对照这份文档执行。
这样它知道这一阶段只该做什么、做到什么程度，就不容易自由发挥。
这份文档，我把它叫做这个阶段的“实施真源文档”。
说专业一点，它就是这个阶段的“单一可信来源”。
意思是，这一阶段的开发和验收，都以这份文档为准。
聊天里临时冒出来的想法，不是不能改。
但要先回写到真源文档里，才算正式变更。
agent 宪法管的是 AI 怎么做事。
这份文档管的是，这个大阶段具体做什么。
两份分工不同，别混为一谈。
AI 照着它来写，你照着它来验收。
这里有一个很重要的提醒：
你不用一次性，把所有大阶段都拆成实施真源文档。
后面的阶段，可以先保留大方向，不要现在就抠详细步骤。
只拆你当前马上要做的这个大阶段就够了。
为什么？
因为项目做着做着，需求很可能会变。
你要是一上来，就把后面每个阶段都抠得特别细，到时候需求一改，那些细活大半白做。
所以做完第一个大阶段，再拆下一个大阶段，一个一个来。
不过，需求可以微调，有一条底线不能破：
走到这一步，开始动手写代码了，就别顺手去动大的底层架构了。
业务细节可以调，但地基不能随手翻。
这里要分清楚：你能改的，只是和底层架构无关的需求。
如果你判断不了，就直接问 AI：
这个改动会不会影响技术栈、目录结构、数据库表怎么设计、核心字段怎么存、登录权限、支付流程这些地基？
如果会，先不要实现，先给影响评估和调整方案。
万一你发现，这个改动非得动到底层架构，那就别急着让 AI 去实现。
先停下来，和它好好讨论，让它评估影响范围，再给出一个稳妥的调整方案。
千万别图省事，一句“先满足需求再说”就丢给 AI 让它改。
因为你一旦只顾着满足需求，AI 很可能为了照办，转头就把你的架构给破坏了。
到那时候，前面立项、技术栈、项目架构这些工作，很可能就全白做了。
这也是为什么，立项我反复强调，甚至用了两期视频来讲。
想把一个大阶段拆成实施真源文档，你可以这样要求 AI：
“请根据功能清单和阶段计划，把当前这个大阶段细化成一份详细的实施真源文档。先把这个阶段拆成几个子阶段，每个子阶段再拆成更小的步骤，逐条说明每一步要做什么、做到什么程度、涉及哪些功能、验收标准是什么、用什么方式验证、暂时不做什么。先不要写代码。”
拆完之后你一定要看。
这份文档不光是给 AI 执行的时候看的。
它也是你开写代码前，最后一次和 AI 对需求的机会。
你要确认 AI 写出来的实施文档，和你的需求有没有偏差。
有偏差，就先找出来和它讨论，讨论完让它改。
如果你看不懂，就让它用大白话给你一条条解释。
一定不要怕麻烦。
甚至你还可以把自己的原始需求重新贴给 AI。
让它对照实施真源文档检查：
有没有和你需求冲突的地方？
有没有需要先讨论的问题？
如果有，就列出来，先别写代码。
第二步：让 AI 照着真源文档，一阶段一阶段推
实施真源文档拆好了，终于可以让 AI 写代码了。
但这里有个最大的坑，得先防住。
这个坑就是漂移。
AI 写着写着，很容易脱离你定的计划：
要么自由发挥，加一堆你没要的东西。
要么该做的漏了，不该做的多做了一截。
这种偏离计划、自己乱跑的情况，本系列里就叫漂移。
怎么防漂移？
办法是：每个子阶段开工之前，都先给 AI 一句明确的指令，把它框住。
你可以这样说：
“严格遵守 agent 宪法和实施真源文档。 只实施当前子阶段，不要超出范围。 做完后停下来汇报，不要自动进入下一个子阶段。”
同时，最好把这个阶段对应的实施真源文档路径，一起发给 AI。
这句话其实是在给它划两条边界：
它怎么做事。
以及这次具体做什么。
两边都有据可依，就不容易乱跑。
接着说一个细节。
假设你这份真源文档里，分了好几个子阶段。
理想情况是，AI 做完一个子阶段就停下来，等你确认。
现实里，有些 agent 工具如果开了自动执行模式，或者任务边界写得太大，就会一路做到它认为完成为止。
不管哪种，你都别急着催它继续。
每推进完一块，都先验收，再往下走。
不管是 AI 自己停的，还是你做了一段让它汇报，都一样。
你不用看代码，也可以先让 AI 汇报三件事。
第一，对照实施真源文档，这个子阶段哪些做完了，哪些还没做完。
第二，它到底改了哪些地方，有没有漏做，有没有多做。
第三，它怎么验证的，验证结果是什么，下一个该做哪个子阶段，为什么。
这三组问题问完，你基本就能看出来，它是在按文档往前走，还是已经开始凭感觉乱跑。
如果它说的下一步，和你文档里写的对不上，那就说明它对当前计划的理解已经偏了。
先把它拉回来，再继续往下做。
它的回答你要是看不懂，别装懂。
直接让它对照实施真源文档，用大白话一条条讲清楚：这个子阶段做了什么、还差什么。
验证结果你要是看不懂，也一样，让它翻译成大白话。
每个子阶段这样验收没问题之后，再进入下一个子阶段。
最后
到这里，开发流程的上下两篇就串起来了。
上篇负责立地基和规矩。
这篇负责开写之后控执行。
实施真源文档负责对齐方向，分阶段验收负责防漂移。
核心就是一句话：别让 AI 凭感觉写，要让它始终有文档可对、有边界可守。
你不懂代码，也能用文档、边界和验收证据，把方向尽量抓在自己手里，而不是任由它自由发挥。
最后多说一句。
上面这些，都是我自己开发时，会严格遵守的步骤和方法论。
也许很多人会觉得麻烦。
但就我个人实践下来，它真的很有效。
你要知道，对于 vibe coding 来说，最难、最慢的，已经不是敲代码了。
因为 AI 干什么都很快，解决问题的能力也很强。
所以现在很多人说，未来取决于你的想象力！
但同时，就目前来看：你能不能利用 AI 做好一个项目，往往就取决于这些你觉得麻烦的事。
相比于专业技术人员来说，很多人少了数年的经验沉淀和知识积累。
如果只是一味焦虑的同时又怕麻烦。
那凭什么越过这数年的差距，做出原来要专业程序员才能做出来的东西呢？
与君共勉！
