架构火花 | AI编程时代的“代码审判”：从人工执念到 AI Native 的工程范式革命

一、背景

前两天在我们深圳同盟架构师群里炸了，起因是何老师抛出的一个问题：“大家现在AI编程输出的代码，Review是如何做的？感觉完全靠人工去100% Review不现实啊。上次看到巍巍老师说另外写一个Review的skill专家去做Review，还有无其他方法？”。瞬间引起大家的共鸣，下面老周来总结回顾下并结合自己的思考给出相应的看法。

随着 AI 编程工具（如 Claude Code, Cursor 等）的普及，程序员的日产代码量正从百行级别跃升至千行甚至万行。然而，随之而来的“代码膨胀”与质量焦虑也达到了顶峰。当 AI 十分钟就能“啃哧啃哧”写出 几千行甚至几万行代码时，传统的 100% 人工 Review 模式正面临崩塌。

二、 现状与困境：人工 Review 的“不可能三角”

大家一致认为，依靠人工 100% Review AI 代码在现实中是不成立的，这个是大家一致认可的。

• 能力鸿沟： AI 有时会产出极其复杂的逻辑，开发人员可能根本没有能力或精力去深度 Review。
• 效率打断： 追求极致编码流畅感（Flow State）的开发者，难以容忍被繁琐的 CR 流程切断反馈闭环。
• 文件爆炸： AI 降低了写代码的门槛，却导致了文件冗余、逻辑合并缺失等“工程腐败”现象。

AI 虽然让编码效率提升了 90%，将原本三年的项目周期缩短为一年，但它并未改变企业工程能力的底层逻辑。编码只是瞬时的行为，而工程则是为了保证代码在未来数年内持续可维护、易于变更。

面对 AI 产出的海量代码，100% 依赖人工 Review 虽不现实，但完全放任则意味着丧失了对系统的掌控力。如同 Linus 扮演“严父”角色一样，开发者必须以自身的“工程品味”（Engineering Taste）为准则，对 AI 提供的多种架构方案进行筛选和修正，强迫其符合工程规范。AI 的加入像是把“造大桥”的速度变快了，但它并不能直接让人具备“造太空电梯”的能力；只有坚持人工对设计方向的把控，才能避免代码沦为一次性消耗品，确保系统在交付后依然具备长久的生命力。

三、辩论焦点：人类是否应放弃对代码的“控制欲”？

针对代码质量的终极责任，群内形成了两种鲜明的观点碰撞：

观点 A：回归设计与工程品味（+AI 模式）

这种观点主张：人类依然是“严父”，AI 是高速劳动力。

• 工程品味（Engineering Taste）： AI 见过所有架构，但它不知道你要哪一种。工程师必须利用自己的“一万小时定律”积淀的直觉，要求 AI 按特定的工程规范进行修改。
• 防患于未然： 堵不如疏。与其在事后 Review 烂代码，不如在前、中阶段投入精力。通过定义接口、明确数据模型、画好时序图（虽然 UML 被认为过重，但逻辑梳理不可缺失）来约束 AI。
• 分而治之： 复杂系统必须先由人进行模块拆解，确认组件依赖，再让 AI 在受控的边界内发挥。

观点 B：拥抱 AI Native 与自动化（AI+ 模式）

这种观点主张：人类应放弃对代码细节的执着，转向“Vibe Engineering”。

• 逻辑前置： 既然 Review 代码太累，不如 Review Plan。如果 Plan 过了，代码生成就交给 AI。
• 以测代评： 靠自动化测试、质量门禁和脚本化规则来代替人眼。如果测试全过，重构成本极低，代码是否“人眼可读”在未来可能并不重要。
• AI 监督 AI： 尝试用不同的模型交叉 Review（例如 Claude 生成，Gemini 审计），通过给出的 Score 来辅助判断。

这正如何老师说的一样，聊出了存在正反观点的话题，这波老周站观点A。

杨振涛老师说：

当下是一个过渡阶段，大家默认都是拿AI来提效以前的事情；但未来AI含量超过某个阈值以后，真正的全新范式才会建立。

何明璐老师说：

我觉得还是应该朝AI原生思维发展

吴穹老师说：

我觉得，AI已经完全可以支撑AI Native组织了，科技型组织了。

林强老师说：

额，不要动不动就讨论终态嘛。我觉得终态还是：肉体苦弱，机械飞升；人类这个物种只是智慧爬升的一个阶梯而已。

老周说：

我就说一个场景，那些历史业务，前面的人离职了，也没有历史文档，你想靠AI给你重构，可能吗？你自己都理不清楚！

吴老师还是太理想化了我感觉，即便未来的代码是 AI Native 的，现在的历史代码并不会自动变成 AI Native。我就想解决历史代码的问题。

吴老师他们的系统大概做了7-8年了，总共50-60人年，100万行代码，我们大概3-4个人，预计半年重构完。

我之所以对这个重构系统很感兴趣，是因为老周前段重构一套复杂的系统。吴老师说AI Native一点点绞杀掉旧代码，说起来容易，做起来就难了。不过他们还在重构，暂时持保留意见。老周分析肯定不是核心系统，边缘系统让你们小范围这么玩一玩，不过我算每个人2w的薪资发，4个人，半年重构也得花近50万！在这个降本增效的时代，这50万花在其它地方不香吗？如果是核心系统的话，肯定是单独拉一套代码库出来重构的，即使你半年重构完了，之前的仓库这半年的业务的代码增量的你怎么办？好，你又得继续重构，往复循环，半年肯定搞不定。好，老周就假设你都重构好了，上线有问题怎么办？你不可能说这是AI搞的，不是我的锅吧？回退机制有没有？如何回滚保证生产环境正常？工程化的东西在生产环境异常复杂，一定要有敬畏之心！！！

四、其它的一些观点碰撞

4.1 行业分层：简单工具 vs. 严肃业务

讨论达成了一个重要共识：Review 的强度取决于业务的容错成本。

• 轻量级/前端/小工具： 可以完全“梭哈”AI，追求效率，不行就重写。
• 金融/支付/核心底层： 错一行代码就是灾难。在这些领域，人依然不敢全盘接受 AI 的产出，AI 必须理解复杂的业务规则，而不仅仅是逻辑。

4.2 历史债务：AI 能否拯救“屎山”？

面对没有文档、前人离职的遗留系统（Legacy Code），AI 并非万能药。

• 现状： 目前 AI 在理不清复杂历史业务逻辑时，重构效果往往不如人意。
• 策略： 采用“农村包围城市”或“哑铃模型”。新领域直接 AI Native，旧系统通过 AI 逐步绞杀，一块块替换。

4.3 组织的未来：超级个体的崛起

AI 对工程效率的提升（预计未来半年平均可提升 5-10 倍）将深度改变组织结构：

• 角色融合： 未来可能出现更多“超级个体”，一个人端到端负责产品、开发、测试全流程。
• 马太效应： 牛逼的人会更牛逼。AI 降低了技术门槛，却提高了对目标定义、架构设计和系统工程验证的要求。

五、老周的思考

很多人都在说等未来AI含量超过某个阈值，等数据量足够大，等算力足够强，等那个奇点何时到，等AI啥时候拥有意识？我们就能实现这些能力！

真等到那个时候，你就不会是讨论AI Native还是人要不要对代码有执念的问题了，到时候肯定是要不要禁止AI，至少在一些高风险威胁人类的场景禁止，你信不信？因为已经威胁到人类了，统治阶级也不允许这样的事发生，因为威胁到我的主权了。

在生命健康、重大财产等敏感领域，AI决策需人类监督或主导。例如自动驾驶事故责任需明确制造商、软件供应商等多方主体。

‌老周认为必须要有分级授权机制‌：根据风险等级划分AI自主权限。比如低风险决策（如推荐算法）可自主完成；中等风险（如医疗辅助）需人类确认；高风险（如军事AI）必须由人类掌控。

每次说来说去就那几个场景用AI效果好些，我就说一种场景，我要实现某个需求，丢给AI，AI马上给我做，必须全流程，从前端到后端到测试到运维全部链路打通，我不想写啥提示词，我也不想在什么workflow里串节点，我想要的AI是这种场景，如果还不行，那就存在泡沫。你可能会说，AI Native是趋势嘛，我也知道是趋势，区块链、元宇宙、WEB3之前不也是趋势么，怎么没听到身边的人聊了？

好了，老周就说到这里，大家都没有对错，每个人关注的点和思考的点不一样而已。