纯靠 Vibe Coding 做项目，项目一旦出现一个很久都解决不了的问题，你是不是马上就想：
这套代码不行了，干脆让 AI 全部重写。
对于一个没有技术背景的人来说，这个想法很正常，因为你看不懂问题到底有多大。
旧项目越改越乱，重新来一遍，看上去反而更干净、更省事。
AI 也肯定敢接，很快就能重新生成一大堆页面和文件，让你重新看见希望。
可你要是没搞清问题到底出在哪儿就重来，新项目做到一半，很可能还是那些老问题。
时间和精力就这么耗在重来上，推到第三次，多半就不想做了。
一天一个 vibe coding 小技巧。
今天就讲清楚，什么时候应该先把项目掰正，什么时候才真的值得重写。
一共四步，每一步该对 AI 说的原话，我都直接给你。
一、第一步：先审计，弄清问题到底在哪一层
没搞清就重来，老问题为什么会跟过去？
因为重写一次，一起消失的是这些：已经跑通的业务规则、数据之间的对应关系、谁能看到什么的权限判断、出错时的兜底处理、已经接好的第三方服务，还有前面好不容易修掉的那些小毛病。
它们藏在代码和一次次修改里，你看不见，也很难一次全部重新描述给 AI。
所以新项目表面上干净了，麻烦一样都没少，还会多长出一批新的。
重写不是不能做，但它必须是审计以后得出的结论。
准备重写以前，先让 AI 停手，把项目完整复盘一次。
「项目出现问题，我准备整体重写。本轮停止一切修改，不新建项目，不生成新代码。读取当前需求文档、阶段实施文档、架构设计、相关代码、测试和 Git 状态，对现有项目做一次完整复盘。」
这次复盘只回答一个问题：现有项目到底还有没有办法掰正。
答案分三层。
拿房子打个比方，这三层的差别一下就出来了。
第一层，是局部问题。
一个页面、一条接口或者一段数据处理出了错，其他地方都还好好的。
这就像一个灯泡不亮、一扇窗关不严，换掉那一个零件就完事了。
这种情况应该修真正出错的位置，没有任何理由重写整个项目。
第二层，是某一个模块已经走歪。
模块就是一块相对独立的功能，比如登录，比如订单。
走歪的意思是：这一块该干的活儿全混在一起，改一处就牵动周围一片，再往下改只会更难。
这就像一整间屋子的水电全缠成一团，修哪一根都得刨墙。
真要动，是把这一间拆了重装，房子本身不用推。
这时可以比较一下，继续在这块上修，和把这一块删掉重做，哪个成本更低。
但注意，就算决定重做，动的也只有这一块。
项目不新建，其他功能一个都不碰。
前两层说的都是在现有项目里接着干，也就是掰正。
第三层，才是整个项目的地基错了。
需求的边界、数据怎么存、整体怎么搭，这几件里有一件建在错的前提上。
继续修补只会让问题越来越多，而且修正的成本已经高过重新做一遍。
地基歪了，你把每一间屋子都翻新一遍，楼还是斜的。
只有证据走到这一层，才轮得到你一开始想的那件事：自己新建一个项目，从头再做一遍。
所以要让它把定级说清楚，并且拿证据说话：
「判定问题层级：局部实现错误、单个模块职责失序，还是项目基础结构本身错误。每层判定均需给出具体文件、调用关系、运行结果和历史变更作为证据；“代码太乱”“架构不好”不构成重写依据。」
提示词最后那半句，是专门堵它的嘴。
“代码太乱”“架构不好”这种话，AI 说得又快又顺，你也没法反驳。
但它证明不了任何事。
成本这一项，它也很容易糊弄你。
你问重写要多久，它给你报个大概几天，听起来比继续修划算多了。
可它算的往往只是重新生成代码的时间。
所以要逼它把账算全：
「先给出在现有项目内修正的方案，再与模块级重写、整体重写逐项对比。对比维度包含变更范围、预计工作量、需重新验证的功能、数据迁移、第三方服务重新接入、失败后的回退难度，以及已验证成果的损失量。本轮只交付审计结论与方案对比，不修改代码。」
把重新验证多少功能、数据要不要迁移、第三方服务要不要重接、失败了能不能退回来都算进去，“重写更省事”这个结论往往就不成立了。
二、有两种项目，不用在掰正和重写之间纠结
第一种，项目还在很早的阶段。
规模不大，没有真实用户，没有重要数据，也没有外部系统正在调用它。
这时候审计如果确认地基确实错了，重写往往就是成本更低的那条路。
继续坚持“能修就绝不重写”，反而是在一套已经证明不合适的结构上耗时间。
注意，这里说的地基错了，不是代码写得不够漂亮，也不是文件看起来不够整齐。
而是现有结构已经撑不住需求，继续开发只会让同一类问题反复出现。
第二种，恰恰相反。
你做的不是商业项目，只是自己用或者练手，重写的念头也不是审计得出来的。
就是做着做着，觉得代码不够规范、文件不够整齐，越看越想推倒重来。
这种情况我个人的建议是：别重写，憋着这口气把它做完。
现有结构虽然不漂亮，但还能继续开发，功能也能一项项跑通。
以前还没有 AI 的时候，新手程序员也是这么过来的。
没谁一开始就能写出又规范又干净的代码。
很多东西只有真正做完一次、亲手用起来，你才知道前面为什么会走弯路。
否则每次刚觉得结构不漂亮就重新开始，你永远都只在练习怎么开项目。
一次完整的开发和使用都没走完，信心却在一次次推倒重来里耗光了。
当然，一条路走到黑，不等于同一个 Bug 闭着眼睛打补丁。
同一个问题连续三轮还没解决，那是该停下来查原因，不是该把整个项目推倒。
停下来之后怎么查，大概是这么个顺序：先让它别再改代码，回去找最先出错的那个位置，拿证据说明为什么是这儿，再动手改。
这套流程我专门讲过一篇「一个 Bug 反复修不好怎么办」，没看过的可以翻回去补。
这种自用项目，你可以先给 AI 定个调：
「本项目为非商业的自用或练手项目。除非有证据证明现有结构已无法承载需求，否则不执行整体重写，也不以代码整洁为由扩大变更范围。
盘点距离核心功能全部可用还缺哪些任务，按依赖关系排序。一次只完成一个任务，每完成一项即验证既有功能未被破坏，并保存一个稳定版本。
同一问题经三轮完整处理仍未解决时，停止追加补丁，转入原因审计；取得证据后继续完成现有项目，不转为整体重写。
本阶段目标是把现有项目可靠地完成并投入使用，不是重建一套更整洁的代码。」
先把核心功能跑通，再按项目真实的使用范围做一次该做的安全检查，然后就部署、就用起来。
用的过程中，你自然会发现哪些设计确实难用，哪些代码真的挡路，哪些只是看着不够完美。
这些真实感受，才是下一个项目能做得更好的经验。
那如果审计的结论确实是要重写呢？
后面三步，一步都不能省。
三、第二步：趁还在旧项目里，把要带走的东西整理成一份文档
审计做完，先别急着建新项目。
你现在还在旧项目里，AI 能读到全部代码、文档和改动记录。
这是最后一次。
等你换到新项目，它就只剩你转述的那点信息了。
所以这一步只干一件事：把值得带走的东西盘出来，落成一份文档。
已经确认的需求，已经跑通的页面和流程，不能丢的数据设计，已经接好的接口和第三方服务，还能继续用的测试。
稳定可用的代码当然也能复用。
但复用不等于把旧代码原封不动搬一遍。
已经证明有问题的那部分，不能为了省事继续带过去——那就白重写了。
反过来也一样。
决定重写，不等于连前面已经跑通的成果都重新猜一遍。
这份文档的作用，是防止新项目再犯一遍同样的错。
「盘点当前项目中已确认的需求、已跑通的流程、不可丢失的数据设计、接口约定、测试和稳定代码，逐项标注继续复用、需要调整或明确放弃，并给出依据。
输出为一份独立文档，写明每一项在项目中的位置，以及它是仅作参考，还是代码可以直接复制到新项目。本轮不修改任何代码。」
注意是逐项标注，还要给依据。
不然它很容易含糊过去，最后要么全搬，要么全扔。
这份文档你自己收好，下一步全靠它。
四、第三步：新项目你自己建，旧项目原地别动
到这一步才轮到建项目，而且这件事你自己动手。
新建一个文件夹，用你平时那个 AI 编程工具打开它，从这一刻起它就是一个全新的项目。
新目录，新会话，AI 那边的上下文也是干净的。
别留在旧项目的对话里，让 AI“帮你建个新目录、在里面重写”。
那样它一只脚还踩在旧项目上，顺手删几个文件、就地改造起来，你未必看得见。
新项目走的还是开新项目那一套：先有立项文档、功能清单、技术栈和开发规则，再动第一行代码。
开工前该准备哪些文档、每一份分别写什么，我在讲项目文档的那几集里拆得很细，这里不重复。
唯一的差别是，这一次你不用从零开始想。
上一步那份文档直接放进新项目，它就是这一轮的起点。
那老代码怎么办？
旧项目原封不动留在原地，一个文件都不删。
它现在有三个用处。
文档里标着“可以复用”的东西，要从它身上取。
新项目做到一半，你随时得回去看某个功能当初到底是怎么实现的。
万一新项目又做砸了，旧的还能顶着用。
所以最危险的一句话是“把旧的清了，重新开始”。
这句话说出去，参照物和退路一起没了。
需要 AI 看老代码的时候，在新项目的会话里，把旧项目那个文件夹加进来，或者直接把它的路径告诉 AI。
同时把只读这条说死：
「旧项目位于〈路径〉，本轮仅作参考。
你可以读取其中任何文件，但不得修改、删除、移动旧项目的任何内容，也不得在旧目录下执行任何命令。
按〈复用清单文档〉逐项确认可复用的部分，需要的代码复制进新项目后再改，不得把整套旧代码直接搬过来。」
最后一件事顺手做掉：如果旧项目只存在你这台电脑上，往别处再备一份，私有远程仓库或者另一块存储设备都行。
它和新项目在同一块硬盘上，硬盘一坏，两个一起没。
往外传之前先排掉真实密钥、配置文件、生产数据和用户信息。
这些东西不该进任何仓库，备份也不行。
五、第四步：按方案分阶段重写，别一口气生成完
新项目开起来之后，第一件事不是写代码。
先让 AI 出一份独立的重写实施方案。
为什么现有项目掰不回来，重写到什么范围，哪些继续复用，哪些必须放弃，都要写清楚。
整个过程还要拆成能逐步验证的阶段：每一步做什么、什么结果算完成、出现什么情况必须停、失败了怎么退回上一个阶段。
「依据审计结论和复用清单文档，编写一份独立的重写实施方案，本轮不修改代码。写明重写范围、分阶段顺序、每一阶段的验收标准、停止条件和回退方法；每完成一个阶段，在新项目里保存一个可以随时退回去的存档点。」
如果项目已经有真实用户、真实数据，或者有外部系统正在调用，还要单独设计数据迁移和新旧切换。
但如果根本没有东西要迁移，就别为了“保险”让新旧两套逻辑长期并存。
「存在真实用户、真实数据或正在使用的外部接口时，单独编写数据迁移与新旧切换方案；不存在真实迁移对象时，不新增兼容层，不让新旧两套逻辑长期并存。本轮只交付实施方案，经我确认后再启动第一个阶段。」
方案确认了，也不能一口气把整个项目重新生成完。
一次只做一个阶段。
每做完一段，就拿旧项目已经确认的功能和验收标准重新对一遍。
该保住的东西真的保住了，在新项目里存一个能退回来的存档点，才进入下一段。
六、最后
项目出问题以后想重新来过，不代表你冲动，也不代表重写一定错。
你真正缺的，只是判断问题大小的证据。
没有证据时，重写看起来像一次干净的重新开始。
有了证据以后，你才知道该修一个点、把某一块删掉重做，还是真得新建一个项目从头来。
顺序你记住就行：
第一步，让它停手，先审计，把问题定到局部、某一块功能还是整个项目这三层里的哪一层，而且要证据。
第二步，趁还在旧项目里，把已确认的需求、数据设计、接口和测试盘成一份复用清单文档。
第三步，新项目你自己建，照常走一遍开项目那套流程；旧项目原地留着、一个文件都不删，只当只读参考。
第四步，按方案分阶段做，每做完一段拿旧项目的验收标准对一次。
地基没歪，就别推倒重盖。
真要重写，也是带着上一轮已经确认的成果换条路走，不是回到原点。
“代码太乱”不是证据，是感觉。
没有证据就重写，多半只是换个地方，重新犯一遍同一个错。
如果 AI 给出的审计结论你看不懂，就让它用大白话说明：哪里坏了、影响多大、为什么必须重写，以及现有项目为什么掰不回来。
