保留 vs 放弃：八个争议点
核心问题
第 08 章给了七大原则，第 09 章分析了 Java+Vue 困境。但原则落地最难的从来不是技术，是人。
在网上搜一下，关于 AI 编程的争论铺天盖地——有人说它是生产力革命，有人说它是屎山加速器。这些争论的本质不是 AI 好不好，而是你该保留什么、放弃什么。
这一章列出八个最尖锐的争议点，每个拆成"反对者在担心什么"和"本书的建议"。
争议一：古法编程——亲手写每一行代码
反对者在担心什么
"亲手写代码才叫编程。AI 生成的代码没有灵魂。古法编程代表的是对质量的追求、对每一个细节的掌控感。依赖 AI 会让自己变成只会按按钮的操作员。"
这种担忧的核心是手艺感的丧失。一个写了二十年代码的工程师，他的价值很大程度上建立在他"能写出别人写不出的代码"上。AI 一来，人人都会写了，他的手艺是不是就贬值了？
但这个担忧的前提错了
AI 写的代码不比人差，甚至更好。 AI 阅读了 GitHub 上数百万个开源项目的代码，它的"代码审美"来自海量优秀样本的平均——命名规范、代码格式、注释风格、常见模式——这些 AI 做得比大多数人都好。
真实的差距不在代码质量，在设计原则。AI 生成代码时没有全局视角，它在局部上下文里做局部最优，导致：
- 没有架构思维——不知道这个功能在整个系统中的位置，往往在错误的地方加逻辑
- 过度兼容设计——为了"以防万一"生成不必要的判断和分支，代码多了但边界没有更安全
- if-else 嵌套——AI 不擅长把复杂条件拆解为策略或多态，习惯线性堆叠
- try 地域——每一层都 try-catch，以为加了就是安全，实际上是掩埋错误
所以问题不是"AI 写的代码烂"，是"AI 写的代码缺少架构纪律"。我们的角色也从"写代码的手艺人"转变了：
我们是规范的制定者、代码的审阅者、架构的决裁者。
本书的建议
该保留：制定的权力
规范你定，不是 AI 定。用第 08 章的七大原则约束 AI，用 Skill 自动检查 AI 的产出，用架构健康评分持续监控。定规则的人才是系统的主人。
争议二：AI 不可控——AI 生成的代码是屎山加速器
反对者在担心什么
网上程序员最多的抱怨之一：AI 没有"痛感"。 人写烂代码会感到痛苦，会去重构。AI 不会——它可以在几分钟内把一个小缺陷复利放大成两万行屎山，而且连它自己都修不好。
实际数据也支持这个感受：AI 生成代码的缺陷率比人更高，而且 AI 倾向于过度工程化——生成不必要的抽象层，用更多的代码解决简单的问题。
这不是理论推演。我身边就有真实的案例——一个朋友用 Trae 的 Solo 模式，只让 AI 写代码，自己完全不看代码。结果三周下来，代码重复率超过 90%，同一个工具函数在六个文件里出现了七次不同的版本。不是 AI 写不好，是没有任何规范约束它——没有架构边界、没有模块划分、没有复用意识，AI 在每次对话中都是从头开始。
所以反对者说："用 AI 就是在加速制造屎山，而且你失去对代码库的控制力。"
这话说得没错。确实是这样。
本书的建议
这个担忧是对的。但解决方案不是不用 AI，而是用体系化的手段控制 AI 的输出质量。前面三部分其实全部在解决这个问题：
- 架构原则约束：第 08 章的七大原则（层次精简、聚合对象、自包含、数据透明、可执行、CLI 可测、模块标准化）就是 AI 的"施工规范"。AI 在原则范围内生成代码，出不了圈。
- Skill 自动检查：
audit-transaction检查事务模板，check-module-architecture检查模块结构，generate-service-test自动生成测试——Skill 是 AI 产出的质检员。 - CLI 测试体系：第 07 章的 CLI 测试体系让 AI 每次修改后都能快速验证，问题早发现早修复，不会等到两万行才意识到烂了。
- 持续重构：AI 代码需要持续治理。下一章专讲"AI 架构治理"。
该保留：审查意识 人审 + Skill 自动化检查的双重验证体系。不信任 AI 是对的，但要建立审查机制来管理不信任。
该放弃：全盘否定 因为担心屎山就不用 AI，相当于因为怕车祸就不开车。问题不是车，是没有交通规则。
争议三：代码可读性——AI 的代码没有注释
反对者在担心什么
"AI 生成的代码没有注释、没有文档、看不懂逻辑。以后维护怎么办？"
这个担忧我遇到过。我用 ChatGPT 生成的代码，确实经常没有注释——不是代码质量差，是模型默认就不写注释。
但仔细想想，这未必是模型的问题。可能是提示词没要求，可能是 Agent 的配置里没有约束，更可能是我们没有通过 Skill 告诉 AI 要写什么注释。
本书的建议
该保留：注释规范
注释还是要的。但注释的对象变了——不是写给 AI 看的（AI 读得懂代码本身），是写给人看的边界约束。
csharp
// 有用的注释：告诉维护者这里为什么不能改
// 不要在这个方法里做 IO 操作——会被高频调用
// 没用的注释：AI 看得懂的废话
// 这个方法用于获取用户信息该调整：通过 Skill 约束注释行为
AI 不写注释不是因为不想写，是没人告诉它要写。把注释要求放进 Skill：
yaml
# audit-comment-coverage.skill
检查规则:
1. 每个 public 方法必须有 /// 注释
2. 每个类必须有类级别注释说明职责
3. 复杂逻辑必须有行内注释如果用 Qoder，还可以通过 Rule 直接约束——告诉 AI"所有代码必须包含充分的注释"，它就会照做。
所以问题不是 AI 不写注释，是我们没告诉它要写。
争议四：架构思维定式——"我一直都是这样做的"
反对者在担心什么
"三层架构是经过验证的最佳实践。DDD 是企业软件的银弹。Spring 的依赖注入是 Java 生态的基础。"
这些都没错。但当你说"我一直都是这样做的"时，就需要停下来想一想：这个做法是为谁设计的？
三层架构是为团队分工设计的。DDD 是为复杂领域建模设计的。Spring 的 DI 是为解耦设计的。它们都是"为人"的设计。问题是：当 AI 成为主要读者和写作者后，这些设计假设还成立吗？
本书的建议
该保留：架构思维本身 架构思维——关注分离、模块边界、接口契约、依赖管理——这些在任何时代都是核心能力。AI 也需要这些"图"来导航代码库。
该放弃：特定的架构教条 DDD 是好的，但在 AI 时代封装过度了。三层架构是好的，但叠多了（ApplicationService + Command + RequestConverter）就不好了。不是这些模式错了，是把模式当教条死守的心态错了。
分界线：分清楚"这个架构原则是否仍然成立"和"我一直这样做"——前者是理性判断，后者是习惯惯性。
争议五：编程语言偏爱——"XXX 是最好的语言"
反对者在担心什么
"我用 Java 写了十年，你让我换 Go？""我是前端开发，学 React 还不如把 Vue 吃透。"
这些争论的核心和技术无关，和身份认同有关。你擅长的语言就是你吃饭的工具，否定它就是在否定过去十年的积累。
但这条路线走不通了
我自己就是走过来的。最早是 Java 架构师，用 Java 和 Vue 做项目。后来切到 C#。AI 时代来了，又开始用 React、Go、Python、PowerShell、TypeScript——不是因为 Java 不好，是不同场景需要不同的工具。
现在我正在做的采集+推流项目，属于音视频领域。我参考了 OBS 的设计，用 C++ 写采集框架。不是因为 C++ 比 Java 高级，是因为音视频采集这个场景只有 C++ 能提供我需要的内存控制和硬件加速能力。
回头看，这些语言切换并没有让我重新学一遍编程——架构思维和领域知识才是真正的积累，语言只是表达手段。 懂音视频的编解码流程、懂推流的协议栈、懂采集的缓冲区管理——这些知识跨语言迁移。
未来是积木式编程
AI 时代最大的变化不是语言本身，是工作方式。未来程序员不是从零写代码，而是把成熟的组件组合起来：
- 音视频采集用 C++ 框架
- 业务编排用 Go 或 C#
- 前端界面用 React
- 脚本胶水用 Python 或 PowerShell
- 测试和构建用 CLI 命令
每种语言只做它最擅长的事。程序员的价值不是"会用多少种语言"，而是知道在什么场景用什么组件，以及怎么把它们组合成一个可靠系统。
本书的建议
该保留：领域深度
领域知识比语言知识值钱。懂音视频架构的人，不管用 C++、Go 还是 Java 都能写出好代码。只懂 Java 语法的人，换个语言就废了。
该放弃：语言身份认同
不要把自己定义为"Java程序员"或"前端开发"。把自己定义为"解决 XX 领域问题的人"。语言只是工具箱里的扳手——你不会只因为用了一把新扳手就变成一个不同的工匠。
争议六：职业危机感——AI 会不会取代我
反对者在担心什么
"代码 AI 写了，架构 AI 设计了，那我还干什么？""初级开发的工作都被 AI 干了，新人怎么成长？"
这些担心的本质是同一个问题：当编程的门槛降到几乎为零，程序员的不可替代性在哪里？
未来是 Agent 工程师
我的答案是：未来的职业方向是 Agent 工程师。 不是 Java 工程师、不是前端工程师、不是 Go 工程师——是 Agent 工程师。
我现在就在帮一家公司做架构治理，要求全公司转型 Agent 工程师。什么意思？不再按编程语言划分岗位，而是按产品和业务划分。 你需要解决的问题是什么，你就选最适合这个问题的工具。
Agent 工程师要学什么？不是特定语言的 API，而是超越语言的软件设计思想：
- 设计模式——Java 生态最成熟的那套，策略、观察者、工厂，任何语言都用得上
- MVVM 设计思想——WPF 是最经典的实现，但它的本质是如何分离视图和逻辑，前端 React/Vue 都在用同一套思路
- 容器设计与依赖注入——不管是 Spring 的 DI 还是 C# 的 ServiceCollection，控制反转这个思想跨语言
- 领域知识——比如 Tailwind 不是 CSS 框架，是"原子化 CSS"这个设计思想的具体实现
- 语言特性——每种语言有自己擅长的领域，知道什么时候用 Go、什么时候用 C++、什么时候用 Python
- 操作系统原理——进程、线程、内存管理、IO 模型，这些不因语言而变
- 网络原理——TCP/IP、HTTP、WebRTC，音视频推流离不开这些
这些东西都掌握了，语言真的只是工具。在音视频采集场景用 C++，在业务编排场景用 Go 或 C#，在脚本胶水场景用 Python——不需要换脑子，只是换语法。
本书的建议
该保留：设计思想的学习
设计模式、MVVM、容器、DI、操作系统、网络——这些才是真正需要花时间学的。语言 API 三个月就能上手，设计思想需要三年。
该放弃：语言栈的执着
不要把自己锁死在一个语言栈里。"Java 程序员"这个身份在 AI 时代没有意义——因为代码已经不由人来写了。
分界线：你的不可替代性不在于你"会写什么语言"，而在于你"能用什么设计思想解决什么问题"。
争议七：AI 治理——谁来为 AI 的代码背锅
反对者在担心什么
"AI 写的代码谁负责？出 Bug 了算谁的？""审查 AI 代码比写代码还费劲。"
这不是一个人的担忧。统计显示绝大多数开发者不信任 AI 代码。AI 让"写"变快了，但"交付"并没有变快——写一分钟，审一小时，修半天。
而且 AI 生成代码有它固有的问题：没有架构思维、过度兼容、if-else 嵌套、try 地狱、代码重复率高。如果没有治理体系，AI 的确会加速制造屎山。
本书解决 AI 治理的方案
前面几章全部在回答这个问题，不是理论，是已经在用的方案：
第 07 章——CLI 驱动的测试体系
每次 AI 生成代码后，测试体系自动执行验证：
wukong-test/ ← Service 层单元测试
wukong-integration-test/ ← 集成测试
Components.Test/ ← CLI 驱动的组件测试测试不是手动点 IDE 运行的，是 CLI 命令。AI 生成的代码有没有破坏现有功能，一条命令就能验证。
第 11 章——Skill 自动化检查
把架构规范做成可执行的 Skill，AI 生成代码后自动扫描：
audit-transaction.skill → 检查事务模板
check-module-architecture.skill → 检查模块结构
audit-code-duplication.skill → 检查代码重复
check-layer-dependency.skill → 检查层次违规这些不是文档，是代码。AI 必须通过检查才能合入。
文档先行 + 架构审阅 + 人工检查
治理不靠单一手段，是多层防线：
- 文档先行：关键架构决策写成文档，AI 在生成代码前读到约束
- 架构审阅：架构师定期审查 AI 产出的架构健康度，不审每一行代码，审结构
- 人工检查：核心逻辑走人工 Code Review，模板代码和测试走自动化
本章小结
这七个争议点背后有一个共同的模式：每个人都在为自己的选择找合理性。
古法编程者找到了手艺感，AI 拥抱者找到了效率提升——都没错。但关键是分清楚哪些是该保留的，哪些是该放弃的。
| 争议点 | 该保留 | 该放弃 |
|---|---|---|
| 古法编程 | 制定的权力（规范你定） | 仪式感 |
| AI 不可控 | 审查意识 + Skill 检查体系 | 全盘否定 |
| 代码可读性 | 注释规范（AI 约束） | 不写注释的默认行为 |
| 架构思维定式 | 架构思维本身 | 特定教条 |
| 编程语言偏爱 | 领域深度 | 语言身份认同 |
| 职业危机感 | 设计思想的学习 | 语言栈的执着 |
| AI 治理 | 质量门禁 | 无为而治 |
关联：AI 是熵增过程，架构会持续腐化。下一章讨论如何通过 Skill、文档、分层、模块设计等手段持续治理。