企业官网建设流程全解析

1. 128 个 PR，先别急着喊“AI 取代程序员”

1.1 这串数字真正在说什么

我是在一个技术社群里看到这个 GitHub 官方分享的：三周时间，128 个 PR，83 万行代码，让 AI 大规模重写自己的代码库。刚看到标题的时候，说实话我第一反应也是“AI 这么能打了”。但盯着“128 个 PR”这几个字琢磨了一会儿，我的兴奋点反而变了——这不是一次 AI 炫技，而是一套非常标准的工程化流程。

先说个基本判断：83 万行代码，相当于一个中大型仓库的体量，如果让一个资深工程师手动去改，恐怕一年都排不出足够的档期。三周完成，意味着每天要合并大约 6 个 PR，每个 PR 平均涉及 6500 行左右的变更。这个节奏放在真实团队里，不是“AI 写代码有多快”的问题，而是“组织能不能接住这么快的变更流量”的问题。代码写得快只是起点，代码审得稳、合得准、回滚得掉，才是这套方案真正的含金量。

认真讲，这个事件对普通开发者的参考价值不在“我也让 AI 给我重写一遍”，而在“当 AI 能制造大量变更时，人的工作重心应该往哪儿移”。你搞懂了后者，哪怕手头没有 83 万行的仓库，也一样能受益。

1.2 代码行数是最容易误读的指标

还有一个很常见的心态是拿“行数”衡量 AI 有多强，比如“AI 三周写了 30 万行代码”，听起来特别提气。但只要你真实做过大型重构，就会知道行数在重构场景里具有极大的迷惑性。删掉一段废弃代码，行数是负数，可对系统的健康度可能是巨大加分；把一段逻辑从内联拆成多个函数，行数涨了，可复杂度反而降低了；反过来，有些“注水代码”一行顶十行的价值，单看数字完全看不出来。

所以我在看这组数据时，真正关心的是另外几件事：这些 PR 有没有集中改某些高危模块？Review 过程是怎么保证质量不滑坡的？开发和合入的流水线有没有因为 AI 的高速产出而阻塞？团队是直接把 AI 生成的代码合进去，还是中间加了一道“语义等价性验证”的关卡？这几件事，才是 83 万行背后的密码。

说白了，AI 大规模重写代码库，本质上是把“写代码”这个动作的边际成本压到了极低，但“确认代码改对了一百种边界情况”的成本并不低。与此同时，团队协同、需求理解、系统约束、代码所有权、可观测性这些老问题一个都没消失，反而被放大了。这个话题值得细拆的东西，基本上全藏在这些“流程缝隙”里。

我在接下来的内容里会先把大规模代码重写的难点讲清楚，再拆解 AI 在这个场景里到底承担了什么角色，最后给你一份可以直接拿去复用的实操框架和避坑清单。希望你读完以后，再看类似的新闻，第一反应不是“好家伙”，而是“他们这个流程设计得很聪明”。

2. 大规模代码重写的难点：为什么 83 万行这么难搞

2.1 你以为问题在“代码”，其实问题在“依赖”

凡是接手过古老大型仓库的人，多少都体会过那种无力感：你想改一个看起来人畜无害的工具函数，结果 IDE 里跳出一大片调用方，build 报错一条接着一条，测试挂掉一片。这不是你不够细心，而是现代软件系统的核心约束从来不是“某一处代码好不好写”，而是“改动一处代码，会影响多少未知的地方”。

依赖关系是分层的。最直观的是函数调用链，改一个函数签名，所有调用方都得跟着变；再往上是模块边界，改了一个数据结构的形态，整个模块的对外协议就变了；更隐蔽的是运行时依赖，比如序列化格式变了，旧数据读不进来，内存模型变了，并发安全就出问题。大型代码库里的每一次重构，本质上都是在这些显性和隐性的依赖网里走钢丝。

83 万行代码的体量意味着这种依赖网是极其密集的。你在一个角落改三行代码，可能隔了十二个层级以后，某个服务的数据格式就悄悄变了。所以专业的重构，第一步一定不是急着动手改代码，而是先“摸清楚哪些地方在依赖当前实现”。社区里常讲的 dependency graph、impact analysis、调用链追踪，都是干这个用的。AI 真正能帮忙的第一站，也在这里：它不会凭感觉乱闯，而是基于索引和分析告诉你“这张网长什么样”。

2.2 为什么“大爆炸式重写”是大多数团队踩过的坑

我曾经见过不止一个团队，在面临老系统难以维护时，决策是“咱们重写一遍吧”。这个想法听起来很解气，但历史上成功率其实低得吓人。因为业务逻辑经过多年迭代，许多隐藏规则只存在于生产环境的数据和用户的异常反馈里，根本不在文档中。你重写三个月，终于把表面功能对齐了，然后线上爆出一个“老系统能处理、新系统处理不了”的边界情况，团队马上陷入两难：是继续补？还是回滚？补要时间，回滚要推翻重来。

这就是为什么如今业界的共识是“绞杀者模式”或“切分改造”，而不是“推倒重来”。绞杀者模式的意思是：新系统不急着取代旧系统，而是像藤蔓一样，在一个个模块边界上慢慢生长，逐个替换，最终让旧系统自然消亡。这样每个阶段都有可运行的系统兜底，风险被限制在一个小范围里。

回到 GitHub 这个案例，128 个 PR 分布在 3 周内，平均每天几个 PR，这个粒度摆明了就是在用小步快跑的方式推进重写。每个 PR 都可能独立编译、独立测试、独立回滚。如果某一个改动引入了非常隐蔽的问题，团队不需要在 83 万行代码里大海捞针，只需要盯住最近那一个 PR 的合入影响面就可以了。这种“把大工程切成小切片”的思路，是成功完成大规模代码重写的第一原则。

2.3 合并冲突和回归测试：压垮重构的最后两根稻草

很多人以为代码重写最难的是写新代码，其实真正劝退大部分人的是两个更无聊的环节：合并冲突和回归测试。

在一个多人协作的仓库里，主干分支上永远有别人在提交。你今天基于一个老版本的分支改了三个月，等你想合入的时候会发现，冲突多到让人怀疑人生。所以现代工程实践要求你频繁地、小批量地把改动同步到主干分支上，让每一次同步的冲突面尽可能小。三周 128 个 PR，平均每个 PR 存活时间极短，这正是把冲突成本压到最低的黄金密度。

回归测试则是另一道安全网。重构最怕的并不是“代码写得慢”，而是“改完以后，线上悄悄出现了一个和老行为不一致的地方”。一个好的重构流程，必须在每次合入之前，让自动化测试跑完所有关键路径。而且这些测试不该只测“输出对不对”，还应该测性能、测边界、测异常分支。没有这套网，AI 生成代码的速度越快，你心里的慌就越深。

我在自己的项目里用过一条很朴素的经验：重构期间，宁可让 CI 跑得慢一点，也要把测试集补到“任何一步改动，都能在半小时内发现功能回退”的程度。因为如果回归发现得太晚，成本会随着代码量的增加而爆炸式增长。这比任何花哨的工具都重要。

3. AI 在这里到底干了什么：拆解重写背后的工程工具链

3.1 不是“让 AI 自己写”，而是“人和 AI 在流水线上协作”

我在很多讨论里看到一种误解，以为 GitHub 是扔给 AI 一句“你把这个仓库重写一下”，然后 AI 唰唰唰写完了事。但凡对 AI 编程工具有实际使用经验的人都知道，这完全是异想天开。今天的 LLM 确实能生成大段代码，但让它在没有明确边界、没有验证闭环、没有任务切片的情况下，对整个代码库做一次系统性重构，它会在关键细节上滑倒。

真正可行的方式，是把一次大型重构拆解成成百上千个“足够小的任务”，每个任务都有清晰的输入、输出和验收标准。AI 在这些小任务里扮演的是“高速执行者”——它根据你给出的指令和上下文，生成一段改动，然后人负责审查、验证、调整。这种模式下，AI 干的是“重复劳动里最耗体力的那部分”，而人负责的是“每一段改动是否真正符合系统约束”的判断。你在新闻里看到的那种夸张效率，背后往往是一套已经打磨得很顺的人机协作流水线，不是 AI 单兵作战。

所以我会建议你，在考虑“让 AI 改我的代码库”之前，先问自己一个问题：我的代码库里有多少任务是“边界清晰、可以流水线化”的？比如统一代码风格、迁移某个 API 的调用方式、把某一种模式替换为另一种模式。这些任务恰恰是 AI 最擅长、也最不容易出大错的。

3.2 一个大型重构项目会用到的几类 AI 能力

如果真要复制 GitHub 这波操作的底层工具链，你会碰到四个相互配合的 AI 能力方向。

第一个是代码生成与补全。Copilot 这类工具会根据当前文件、相关代码和注释，生成符合上下文的代码片段。它在“机械性替换”场景里特别好用，比如把一个函数从同步改成异步，给几十个类加上同一种日志逻辑，或者把旧的 HTTP 调用统一替换成新的 SDK 方法。

第二个是语义理解与总结。LLM 很擅长读一大段代码后总结它“在做什么”，这种能力在准备重构说明、梳理模块职责、生成迁移文档时非常有用。你不用自己一行行读遍 50 个文件，再费劲组织语言，AI 可以先帮你把“这个模块的行为边界”理出来，再由人去确认它理解得对不对。

第三个是测试生成。重构最缺的往往不是新代码，而是覆盖旧行为的安全网。AI 可以根据现有函数的输入输出样例，自动生成一批单元测试。这些测试不见得能覆盖所有分支，但作为重构前的基线，价值极大。

第四个是代码审查辅助。AI 可以站在“第二位审查者”的角度，帮你看这次改动有没有遗漏的调用方、有没有潜在的边界条件问题、有没有和现有代码风格不一致的地方。它不能替代人工审查，但能帮你把低级的遗漏扫掉。

这四种能力合在一起，才构成了一套“AI 辅助重写”的完整工具链。缺了其中任何一环，效率都会打折。

3.3 人机协作的正确姿势：让 AI 生成方案，让人确认边界

在我自己用 AI 做过几次代码重写之后，逐渐形成了一个习惯：我会在提示词里明确写出“不要改变对外行为”“不要动接口签名”“只改实现内部逻辑”之类的约束。因为 LLM 有时候会自作主张，把你没让它改的注释改掉，把你没让它动的空格调整掉，甚至把你没让它升级的依赖升级掉。这些“自作主张”一旦悄悄进入 PR，轻则造成 review 噪音，重则在某个隐蔽角落引入行为漂移。

这就是“人机协作”里人的核心职责：界定边界。AI 的能力边界在“给定明确范围内执行得特别快”，人的价值在“确保范围本身是对的”。你可以在每一轮提示词里把边界写得尽可能死，把评审清单写得尽可能明确，然后再把 AI 当成一个“不睡觉的写码工”来用。

4. 如何复刻这套做法：一份 5 步走的 AI 辅助重构实操指南

4.1 第一步：先定终点，再动第一行代码

很多重构失败，不是因为代码写得差，而是因为“终点没定清楚”。比如说，你想把老的 REST API 迁移到新的 GraphQL 接口，那最终结果应该是“所有旧接口调用方都切到新数据源，旧接口下线”。这就是终点。如果没有这个终点，AI 很容易在中途给你生成一堆“看着像在迁移，实际上只是复制粘贴”的代码。

我在实际操作里，会把终点写成一份一页纸的验收清单，里面列清楚：要替换的文件路径范围、不能变化的行为有哪些、性能指标不能低于多少、哪些模块必须保持对外兼容。然后我会把这份清单塞进项目文档里，每次提交 AI 生成代码时，都拿它来校准。这套方法简单，但特别有效。

接下来就是拆分任务。终点定了，就要把它切成粒度足够小的任务。我的标准是：每个任务尽可能只碰一个模块、只改一种模式、能在几小时内完成人工审查。这样可以保证每个任务的失败成本都很低，不会被一个大 PR 拖垮整个迭代节奏。

4.2 第二步：构建“行为安全网”，测试先行

我在前面已经反复强调了回归测试的重要性，这里再讲一个具体的操作手法：在 AI 动手重构之前，先用原有代码生成一批“行为基线测试”。做法不复杂，就是让 AI 给你重构目标里的关键函数写测试用例，输入覆盖典型值、边界值、异常值，输出则锁定为当前代码的实际行为。

有了这层基线之后，AI 改动过的代码如果导致行为漂移，测试会第一时间报警。很多团队在引入 AI 编程工具后完全跳过这一层，结果代码生成速度越快，测试崩溃率就越高，最后还得靠人手把几百个错误修回来，效率反而更差。我特别建议所有想用 AI 做大改动的团队，把“测试先行”当成不可妥协的铁律，哪怕这意味着前期要多花半天时间去让 AI 生成测试。

4.3 第三步：用小步 PR 控制冲突和回滚面

任务切好、测试补好之后，就到了执行阶段。此时最要紧的就是保持每个 PR 的小粒度。你不用学 GitHub 那样三天搞 128 个 PR，但我建议你维持一个节奏：每个 PR 尽量在 1 到 2 天内合入或关闭，不要让它孤零零地在分支上躺太久。躺久了，合并冲突就会重新找上你。

这条经验是我踩过坑才得到的。我早年喜欢搞“大分支”，一口气改五个文件、三个模块，觉得自己执行力很强。结果合入时因为主干分支已经发生了天翻地覆的变化，光解决冲突就消耗了我一个下午，还埋下了几个隐蔽的功能回退。后来我强迫自己把任务再切碎一点，每个 PR 只改一个模块、只解决一个问题，合并效率反而高了很多，回滚也轻松多了，因为我知道出问题时刚合入的是哪一个改动。

4.4 第四步：把代码审查质量提上去，别让 CI 变成摆设

代码审查是重构里最不能省的一环，尤其是在 AI 参与的场合。你要意识到，AI 生成代码的质量其实相当稳定，它不会因为深夜加班而脑抽写错，也不会因为心情不好摆烂。但它有两个致命问题：一是可能“自信地犯错”，生成一段看似有理、实际不符合系统约束的代码；二是可能“过度执行”，在你只让它改 A 的时候顺手改了 B。

所以人工审查必须从“通读一遍觉得没问题”升级为“对照任务边界确认改动面”。我的做法是，在审查清单里准备几个固定问题：这次改动是否严格控制在任务范围内？是否新增了计划外的行为？是否存在对旧接口的隐式依赖？是否有异常分支被忽略？这几个问题看起来简单，但能把大量 AI 生成的“表面合格品”筛出来。顺便说一句，审查者本身也最好理解这次重构的目标，否则很难发现问题。

另外，CI 一定不能只跑编译和现有测试。如果条件允许，把静态分析也加进来，让它检查 API 兼容性、废弃用法和潜在的性能问题。这样可以把 AI 代码里最容易犯的低级错误提前拦住。

4.5 第五步：用特性开关和灰度发布给线上兜底

最后一步，是给所有不确定的重构加一个安全逃生通道。在大型系统里，即使测试全绿，线上行为仍然可能因为运行时环境差异而出现意外。所以在涉及关键模块的重构中，我会倾向于把功能藏在配置开关后面，或者通过灰度发布先把新逻辑放给一小部分流量。

特性开关的威力在于，你可以在不发布新版本的情况下，瞬间把系统切回旧逻辑。这个“瞬间回滚”能力，能让你在 AI 驱动的快速迭代里有底气继续前进。一旦线上出了问题，你不需要在十几个 PR 里找是谁埋的雷，只需要把开关关掉，然后从容排查。这就是最后一层兜底，也是很多团队最容易忽略的一层。

5. 实战中容易踩的坑：这些问题我几乎每次都遇到

5.1 AI 在重构中“自信地犯错”，比你想的更常见

我举一个非常典型的例子。我曾经让 AI 把一个 Python 模块里的同步函数封装成异步版本。它做得很快，但它在重写过程中，把原本在函数内部创建的临时对象提升到了类层级，理由是“这样更高效”。听起来很有道理，对不对？但这个临时对象是有状态的，多个线程同时调用时就会出现共享状态污染，测试在低并发下根本看不出来。直到线上出现了偶发的数据串线问题，我们花了整整一个下午才定位到 AI 的这次“自作主张”。

这类问题的根源在于，LLM 本质上是在“预测最合理的下一个 token”，它并不知道你的系统约束。它觉得“提升作用域”是个常见优化，就做了，但它理解不了你的并发模型。所以我现在的习惯是，每次让 AI 改写一大段代码后，必须有人工审阅者专门盯一个维度：这次改动是不是严格等价。一旦发现任何不是完全等价的地方，宁可让 AI 重新改，也不要手痒写个补丁打上去，因为后续的维护负担会成倍增长。

5.2 上下文窗口再大，也不是整个代码库

你可能觉得，现在 AI 工具的上下文窗口都很大，几十万 token 随便塞，那让它“看看整个项目”应该没问题吧？实际效果并非如此。上下文窗口大，只代表你能塞进去更多内容，但不代表 AI 能从中准确抓住最关键的那几条约束。当代码量大到一定程度，它的注意力会分散，容易忽视一些离目标比较远、但恰恰是硬约束的边界情况。

解决办法有两个。一是靠代码索引和检索工具，让 AI 在需要时主动去“查”相关定义；二是在任务描述里直接显式写清楚“这个模块的关键约束是什么”，而不是指望 AI 自己从十几万行代码里总结出来。我强烈建议采用第二种，因为你写进去的约束越清楚，AI 犯浑的概率就越低。有些团队的提示词写得跟论文似的，把模块的前世今生、边界条件、历史 bug 全讲清楚，这看起来费时间，但省下来的返工时间要多得多。

5.3 行数涨了不少，代码质量却可能原地踏步

还有一个特别值得警惕的坑：AI 帮你快速产出了大量代码后，行数很唬人，但系统整体复杂度并没有下降，甚至可能因为“生成得太多”而变得更难维护。因为 LLM 很容易把原本三五行的逻辑展开成七八行的“防御式写法”，虽然更稳健，但也制造了大量冗余分支。如果没有人控制质量，重构后的代码可能会变成一个“看起来更现代，但读起来更费劲”的新怪物。

控制方法说起来简单：重构的验收标准里，明确加入“复杂度要求”，比如圈复杂度不能比原来高、CC（Cognitive Complexity）不能超过 X、重复代码率不能上升。AI 生成完代码后，跑一遍复杂度分析工具，把它当成测试用例来对待，超了就重新生成或人工修正。不加上这一道坎，AI 加速重构反而可能把技术债越堆越高。

5.4 审查变成“走过场”，比代码问题本身更可怕

当 PR 数量很多、AI 生成的代码质量又普遍不错时，一个非常自然的危险是，审查者开始“滑水”：打开 PR，扫一遍，看到绿勾就点合入。这个行为一旦养成，系统里的质量防线就会全线崩溃。因为 AI 代码的 bug 通常不是低级的语法错误，而是隐藏很深的行为偏移，你不逐行看，它就会在某个后续迭代里冷不丁给你来一下。

我有一个很实用的建议：强制每个 PR 里，审查者必须留一句“我对这次改动的风险评估”评论，不能只点个“批准”。哪怕只是简单说一句“风险较低，改动范围受控”，也能强迫审查者真正动脑过一遍。这招看着有点形式主义，但实际效果比开一百次代码规范大会好得多。

6. 从这组数据里，我更愿意带走什么

6.1 AI 真正改变的是“变更成本”曲线

过去我们做大型重构，最大的恐惧是“改错了怎么办”，因为改错的成本太高，所以大家宁可让老代码烂在那里，也不愿意动它。但 AI 辅助重构把每一次改动的边际成本大幅拉低，再加上测试、灰度、小步 PR 这些工程手段把失败的代价控制住，团队的“重构意愿”会变得强很多。这种“敢频繁做技术债清理”的能力，价值远超那 83 万行代码本身。

我在自己的团队里明显感受到这种变化：以前提一个“把这段老代码重构一下”的建议，往往会收到“现在没时间”或“风险太大”的回复。现在有了 AI 辅助，如果有区域性改动，我可以先让 AI 生成一个初版，再快速评估它的影响面，风险被直观地摆出来，大家反而愿意坐下来讨论到底要不要做、怎么做。这个心理门槛的降低，我认为才是 AI 勾引大家去重构的深层价值。

6.2 工程师的职责正在从“写代码”转向“设计约束”

如果要给这篇文章做个总结，我想说的是：AI 重写自己的代码库这件事，折射的正是未来开发者角色的变化。写代码本身的难度在降低，但定义“什么可以改、改到什么程度、怎么验证没改错”的难度在上升。未来的技术骨干，不只是代码写得利索的人，更是“能设计一套流程，让 AI 在限定范围内安全产出的人”。

我无意夸大这套方法的普适性，如果你的代码库连基础测试都没有，或者代码依赖关系混乱得没人能说清楚，那么 AI 辅助重构并不会自动化地帮你理顺一切。工具永远只能放大你已有的工程能力，而不会凭空创造它。先把测试补齐、把模块边界划清、把任务切小，再让 AI 上场，你才会真正体会到三周交付 83 万行代码背后的那份从容。

最后分享一个我自己的小习惯：每次让 AI 做代码重写之前，我都会先手写一份“改前快照”，把当前行为和未来行为的差异点列成一段话。等 AI 改完，拿这段话来对照，再决定是否接收。这个习惯帮我省下了无数返工时间，也让我在项目复盘的时候，能清清楚楚地说出“AI 到底帮我解决了什么”。