AI 时代软件工程八荣八耻：从节省代码到扩大 AI 可操作空间
2026-06-03
- 以系统所需为荣，以团队所限为耻。
- 以局部自治为荣，以全局牵连为耻。
- 以显式逻辑为荣，以隐式规则为耻。
- 以特化实现为荣，以通用兼容为耻。
- 以闭环验证为荣，以人肉兜底为耻。
- 以可控放权为荣，以因噎废食为耻。
- 以并行迭代为荣，以单线推进为耻。
- 以重构破局为荣，以补丁苟安为耻。
AI 时代的软件工程，真正变化的不是“谁来写代码”，而是软件工程的成本结构发生了根本迁移。过去，编码成本高，跨团队协作成本高，招聘和知识迁移成本高，因此很多工程实践都围绕“少写代码、少换技术、少分叉、少沟通”展开。于是，全栈同构、统一数据库、通用框架、中台能力、最小改动、人工兜底，在当时都可能是理性的选择。
但 AI 介入之后，旧成本结构开始松动。代码生成成本下降，跨语言理解成本下降，一次性脚本、胶水代码、局部实现、特化工具的成本也下降。与此同时，真正昂贵的东西变成了：上下文理解、系统验证、运行观测、责任边界、自动化执行权，以及软件能否持续演化。因此，AI 时代的软件工程不应继续以“节省代码”为中心，而应以“扩大 AI 可操作空间”为中心。
这正是“AI 时代软件工程八荣八耻”的出发点。
一、以系统所需为荣，以团队所限为耻
传统工程中，很多技术选型并不是由系统本身决定的，而是由团队当前会什么决定的。前端团队熟悉 JavaScript，于是后端也用 JavaScript；团队只会 Postgres，于是缓存、分析、冷数据、事实数据都塞进同一个数据库；团队不熟 Rust，于是放弃更适合高性能后端的语言。
这种做法在过去有它的合理性，因为人力成本太高，跨技术栈协作太难。但 AI 降低了跨语言、跨框架、跨工具的理解成本。现在，软件系统应该重新回到“系统需要什么，就使用什么”的原则。前端可以用 TypeScript，后端可以用 Rust，数据分析可以用 Python，热数据可以用 Redis，冷数据可以用 Parquet，事务事实可以用 Postgres。技术栈不必再迁就团队库存，而应服从系统责任。
二、以局部自治为荣，以全局牵连为耻
这里的“局部自治”，不是传统意义上的模块封装，也不是简单的高内聚低耦合。传统模块即使封装良好，也往往仍然依附于一个大系统，不能独立存在。AI 时代更重要的局部自治，是业务场景级别的多 App 独立自治。
过去我们喜欢建设中台，把多个相似业务能力统一到一个公共系统里，试图减少重复和统一口径。但这种做法常常造成新的单点故障：几个本来可以独立演化的业务系统，被一个中台能力牵连在一起。一处变化影响全局，一处故障拖垮多线业务，一处规则变动迫使所有业务共同适配。
AI 时代，创建和维护多个独立 App 的成本下降了。与其让多个业务场景共享一个沉重中台，不如让它们各自自治、各自演化、各自承担边界。局部自治的价值，是让 AI 可以在小上下文、小影响半径、低牵连关系中独立行动。
三、以显式逻辑为荣，以隐式规则为耻
显式逻辑不是指代码一定要简单，而是指逻辑上下文要摆在眼前。真正被批判的，也不是配置文件、装饰器、回调函数、生命周期、依赖注入这些技术本身，而是它们制造了超脱于公共领域语言的隐式规则。
很多系统为了少写代码，把规则藏进框架、方言、黑话、潜规则、动态注入、生命周期钩子和不一目了然的术语里。人类老手可能靠经验知道这些规则，但 AI 会因此陷入信息门槛：它看到了代码，却看不到真正决定行为的上下文。
过去“约定大于配置”成立的前提，是这个约定已经足够通用，甚至改变了人的思维方式。但如果一个约定只是团队内部黑话、框架局部方言、历史遗留规则，那它就不是节省代码，而是在制造理解黑箱。AI 时代，显式配置、显式判断、显式流程的代价下降了。把信息收在一处，能直接看到，往往比把逻辑分散在多个可注入实现里动态加载更有价值。
四、以特化实现为荣，以通用兼容为耻
软件本应服务于具体问题。但过去为了少写代码、少分叉、少维护多套路径，我们经常把不同需求、不同输入、不同业务场景强行吸收到一个通用兼容层里。结果表面上统一了，实际上问题本身被扭曲了。
通用兼容层最大的危险，是它会要求所有具体问题先变形成它能接受的样子。于是，具体业务失去原形，专用能力被削弱，系统开始围绕抽象层转，而不是围绕真实问题转。
AI 时代，编写一次性代码、胶水代码、小脚本、特化实现的成本大幅降低。我们不再有必要为了少写一点代码，就把一个具体任务塞进通用框架。很多时候，一个面向当前任务的直达实现，比一个兼容各种可能性的抽象层更清晰、更便宜，也更适合 AI 操作。
五、以闭环验证为荣，以人肉兜底为耻
闭环验证不应只停留在 CI/CD。传统 CI 已经能完成构建、测试、发布检查，但这并不是 AI 时代的完整闭环。AI 真正需要的是“传感器”：它要有眼睛，要看得见线上状态，感受得到系统变化，能够基于可观测性指标判断自己的行动结果。
如果 AI 只能在代码提交前跑测试，却看不到发布后的线上指标、用户行为、延迟变化、错误率、资源消耗、业务漏斗、异常告警，那么它仍然是一个瞎子。它只能等人类告诉它哪里坏了，仍然依赖人肉兜底。
因此，闭环验证的核心不是不断增加校验规则，而是让系统能观测更多维度的信息。AI 不仅要知道“测试是否通过”，还要知道“上线之后系统是否健康”。人类负责定义正确性和风险边界，机器负责持续观测、持续验证、持续反馈。
六、以可控放权为荣，以因噎废食为耻
很多团队害怕 AI 搞破坏，于是只让 AI 写建议、写文档、写代码片段，不让它真正操作系统。但这无法规模化。AI 如果永远没有执行权，就永远只是顾问，而不是工程自动化的主体。
正确的做法不是拒绝 AI 操作真实系统，而是先假设 AI 能动所有东西：代码、数据、部署、云资源、配置、监控、回滚。然后再加上权限边界、审计、dry-run、沙箱、审批门槛、回滚机制和风险隔离。
可控放权的重点，是让 AI 真的拥有执行力，同时让每个动作处于可控范围之内。因噎废食的结果，是人类继续手工复制命令、手工点控制台、手工排查问题，整个工程自动化无法真正放大。
七、以并行迭代为荣，以单线推进为耻
AI 时代的软件演化，不应该再被理解为单人单线的工程施工，而应该被理解为 optimizer 或 solver 的求解过程。面对同一个问题，AI 可以同时提出多个候选方案：一个局部修复，一个重构模块，一个替换库，一个重写路径，一个优化性能。
传统工程受限于人力，只能一次尝试一条路。失败之后再回头，重新走下一条路。AI 改变了这一点。我们可以并行生成、并行部署、并行验证、并行比较，让软件演化从线性推进变成多路径搜索。
当然，机器评价并不总是可靠。软件好坏常常不可微、不可归因、不可即时判断。但并行迭代的价值不在于机器自动找出绝对最优解，而在于扩大探索空间，让更多候选路径变得可承担、可比较、可验证。
八、以重构破局为荣，以补丁苟安为耻
过去很多工程规训要求最小改动，因为人类编码成本高，重构成本大，验证成本高。最小改动曾经是降低风险的办法。但在 AI 时代，如果仍然要求 AI 永远采取最小改动，就会把 AI 降级成补丁机。
很多系统的问题不在某一行代码，而在结构已经落入死区：harness 越来越重，验证越来越僵硬，重构代价越来越大，稍大的改动都会被流程打回。系统表面安全，实际上已经不可迭代。软件改良失效，只能慢性死亡，或者等到团队一锅端式重写。
AI 时代，编码成本下降了，过去对人来说费力不讨好的重构动作，重新变得可能。我们不应把 AI 困在最小补丁里，而要允许它在闭环验证保护下进行结构性破局。该重划边界时就重划边界，该删除旧路径时就删除旧路径，该重构时就重构。补丁不是可耻的，但在系统已经进入死区之后仍然只打补丁，就是苟安。
结语：让软件成为 AI 可操作、可验证、可演化的对象
AI 时代的软件工程，不是让 AI 更快地写旧范式代码，而是重新设计软件本身，使它适合 AI 操作。新的软件系统应该更局部、更显式、更特化、更可观测，也应该允许 AI 获得真实执行权，进行并行探索和结构性重构。
过去很多 bad architecture，并不是工程师不懂，而是旧成本结构下的理性妥协。全栈同构、一库通吃、通用框架、中台依赖、人工兜底、最小改动，都曾经帮助团队节省人力。但当 AI 改变了编码、理解、执行和验证的成本之后，这些旧妥协就不再天然合理。
AI 时代软件工程的核心目标，是让软件从人工维护的静态资产，变成 AI 可操作、可观测、可验证、可放权、可并行探索、可重构破局的动态系统。
这就是八荣八耻背后的共同判断： 不要让 AI 只是旧软件工程的加速器，而要让软件工程本身为 AI 重新组织。
