【AI 开发·第二集】老系统怎么交给 AI 重做一遍

一、这一集和第一集不一样

第一集讲的是从零开始：一个不会写代码的人，怎么把一个系统从想法做到上线。

这一集讲的是另一件更常见的事：你手上已经有一套跑了多年的系统，想用 AI 把它改造一遍，该怎么下手。

这两件事的难点完全不同。

事情是这样的。我有一套自己摸索着做出来的电商管理系统，公司自用。因为是多项目并行，功能上有问题就改，改完接着用，一直没人从头理过它到底长什么样。后来负责跟我对接的同事提了个需求：帮忙备份一份出来，挂个网站。

就是从这一句开始的。

他后面一路走到「让 AI 把整个系统重写一遍」，中间经过了三个明显的阶段。每一个阶段本身都是成功的，但每一个阶段都会撞到自己的天花板。这篇文章就是把这三段路和它们的撞墙点讲清楚。

顺便说一句，同事用的是腾讯云的 WorkBuddy（这是个 AI 智能体平台，智能编码在它同系列的 CodeBuddy 里）。但下面讲的流程，换成任何一家的 AI 编程工具都成立——关键不在工具，在你把它放在流程的哪个位置。

二、第一步：先备份，再挂出一台能打开的网站

这一步看着最没技术含量，但它决定了后面所有事能不能做。

同事一开始要的只是「备份一份，挂个网站」。而这件事的意义比听起来大得多：

最后这条最容易被忽略。如果 AI 只能读到源码、看不到页面，它就只能凭想象判断「这个改完应该没问题」。能打开页面，它才有办法自己发现问题。

给 AI 干活之前，先给它一个能亲眼看到成果的地方。这一条后面还会出现一次——它就是最后那个 FTP 账号的前身。

三、第二步：从一个外挂开始，别一上来就动核心

同事的第一个真实需求是做一个小程序接进来。

这是最聪明的一个起点，因为它符合一个原则：先做加法，不做减法。

结果也印证了这个选择——很快就做好了。

为什么快？因为外挂这件事对 AI 特别友好：它只需要知道「数据从哪个接口拿、页面长什么样」，完全不用理解老系统内部那团历史欠账。这是 AI 最容易发挥的位置。

但也正因为如此，它很快就到头了：小程序只是把数据换个样子展示，碰不到任何真正的业务逻辑。想让业务本身变好，就绕不开那套老系统。

四、第三步：让它改具体问题——见效最快，也最快到头

下一步很自然：既然 AI 这么能干，把系统里的问题一个个交给它改。

这一步的见效速度是三个阶段里最快的。改一个表单、调一处计算、补一个查询条件——这类问题边界清楚、改动有限，AI 做得又快又好。用过一次的人通常会觉得「这也太强了」。

问题出在后面。改得越多，越会发现一件事：

每一次修改，AI 都得先花大量精力去「看明白这段代码在干什么」。

不是因为它笨，是因为这套代码本身就是摸索着攒出来的——同一个功能可能写在三个地方，命名前后不统一，没有文档，当年的判断只有做的人还记得。AI 每次进来都要从零重建这份理解，而且重建完还未必对。

更麻烦的是：改完 A 处，B 处悄悄坏了。它不知道 B 和 A 有关系，你也不知道。等到用户报上来，往往已经是几天以后。

五、第四步：认出该停手的信号

到某个时候，同事的判断变了。他发现「二开」这件事，让 AI 直接改原来的代码，有点费劲。

这个「费劲」不是一个模糊的感觉，它其实是几个很具体的信号。如果你正在犹豫要不要继续改下去，对照这张表：

只要中了两条以上，就该考虑停手了。继续修下去不是不行，只是每修一处，下一次修起来会更贵。

这里有个反直觉的地方：修不动的根本原因，不是 AI 能力不够，而是它的对手是一套没有结构的老代码。AI 最擅长的事情，是在一个干净的地基上把楼盖起来；它最不擅长的，是在一栋结构已经乱了的房子上继续加盖，还得保证原来住里面的人不受影响。

所以真正的解法不是「换个更强的模型」，而是——给它一个干净的地基。

六、第五步：重构之前，先让它把功能整理一遍

同事接下来做的这个动作，是整条路径里最容易被跳过、但最不能跳过的一步：

他没有直接说「你把这个系统重写一遍」，而是先让 AI 把整个项目做一个功能整理。

这个先后顺序决定了重构的成败。

关键在于最后一行。功能整理这份东西，是你唯一能真正参与进来的环节。

因为老系统的真实功能，散落在三个地方：代码里、当年的口头约定里、以及你自己和同事的记忆里。AI 只能看到第一个。让它先列清单，等于给了一个机会，让你把后面两个补进去——「这个功能我们其实早就不用了」「这里还有个隐藏的规则，只有老客户才走」。

这份清单补得越全，重构出来漏东西的概率越低。而一旦开始写代码，你能插手的余地就很小了。

同事在这个过程中还做了另一件事：他把很多细节也提了出来，一并完善了。这些细节平时藏在「反正一直这么用」的习惯里，不改的时候没人想起，趁着重写提出来，正好一起解决。

七、第六步：给它一个 FTP 账号，把最后一公里打通

这是整篇文章里最值得抄走的一招。

因为这个 PHP 项目部署很简单，同事直接给 AI 开了一个 FTP 账号。

听起来是个小改动，实际上它把整条流程闭合了。

在没有这个账号之前，AI 编程卡在一个很低效的地方：AI 改完代码，把文件交给你；你打开 FTP 软件，一条条拖上去；打开浏览器，一页页点；发现问题，再回头描述给 AI。中间这几步全是人工，而且每一步都会丢信息——「刚才那个报错长什么样」这种事，人转述给 AI 的时候常常已经走样了。

给了账号之后，这个循环变成：AI 改代码 → 自己传上去 → 自己打开页面看 → 看到报错原文 → 自己再改。

报错原文直接进它的上下文，不需要经过任何人转述。这一点比省下的手工操作重要得多。

而人做的事情变成了：最后验收。从搬运工变成验收员。

先说清楚风险，再说怎么做得安全：

如果这套系统撑着在跑的业务，别直接给正式环境的写权限。先搭一个副本环境，让它在副本上跑通，人看过再上正式。这一步多花的半天，比事后回滚便宜得多。

八、第七步：照清单验收，别凭「看着像」

重构最容易出的问题，不是新系统打不开——而是功能看着都在，但少了某个细节。

这种问题特别难发现，因为它往往是很久才触发一次的业务路径：「上次那个老客户的对账单怎么导不出来了？」这时候距离上线可能已经过去两周。

所以验收不能靠「打开看看像不像」，要照着第六步那份功能清单逐条过。

第二行尤其要留意。重构做得好不好，不是看主干功能有多顺，而是看边角功能有没有被落下。

九、这条路径为什么能复用

回头看整个过程，同事其实没有做什么高深的规划，他只是每一步都选了对 AI 最友好的那个动作：

注意第三行和第五行的对比。同样是改系统，「逐个修」是 AI 的弱项，「整体重写」是它的强项。

很多人卡在第三步就走不下去了，结论是「AI 改我们这老系统不好使」。其实不是不好使，是选错了让它干的活。老系统真正的价值不在代码本身，而在你已经知道它该长什么样——那份知识在你脑子里，不在代码里。把那份知识交给 AI，让它重写，比让它去猜老代码更快，也更准。

所以这套路径能复用到：

• 任何一套「自己摸索着做、跑了好几年、没人敢动」的内部系统
• 任何一次「改起来牵一发动全身」的改造需求
• 任何你被交接了一套没有文档的老代码、想重新掌握它的时候

十、最容易踩的坑

写在最后

这条路上最关键的一次判断，不是「用了什么工具」，而是那句：二开有点费劲了。

费劲不是失败的信号，是该换一个动作的信号。它在告诉你：继续在旧结构上加东西，成本只会越来越高；而换到一张干净的画布上，AI 的能力才真正放得开。

第一集讲的是怎么让它从无到有做出来。这一集讲的是——当你有一套跑了很多年、连自己都说不清的老系统时，别让它去猜你当年想了什么，直接告诉它你现在想要什么。

那份「你现在想要什么」，就是那份功能清单。