AI时代更加需要软件工程的规范-夜雨聆风

AI时代更加需要软件工程的规范

AI 让代码变得廉价且可丢弃，但这不意味着软件工程变得更容易——恰恰相反，它要求我们比以往任何时候都更严格地对待工程纪律。

引言

Charity Majors（Honeycomb CTO 兼联合创始人）最近写了一篇深刻而坦诚的文章，回应了 AI 时代下软件工程界的焦虑和争议。她的核心判断是：2025 年 AI 代码生成能力的爆发，并没有降低工程的门槛，反而把长期被忽视的工程纪律问题推到了聚光灯下。

这篇文章是对她之前引发广泛讨论的《AI 热衷者在与时间赛跑，AI 怀疑论者在与熵增赛跑》的后续回应。她收到了来自两派的反馈——技术派和伦理派。本文聚焦技术层面。

2025 年发生的根本性变化是：代码生产的成本结构被彻底逆转了。

曾经，写代码是一件艰难、耗时、昂贵的事情。每一行代码都被珍惜、复用、精心维护。但在 Opus 4.5 发布后（2025 年 11 月），AI 生成的代码质量已经接近中等软件工程师的水平，而且速度快得多、成本低得多。

一夜之间，代码从”珍贵资产”变成了”可丢弃的消耗品”。

这是 Chad Fowler（”不可变基础设施”概念的提出者）的核心洞察，也是让 Charity 彻底”顿悟”的那句话：

当重写变得廉价时，原地修改就变成了风险。突变积累熵增，而替换重置熵增。

她把代码比作”对理解的物化视图“——有用时就保持新鲜，过时就丢弃。

她引用 Chad 的”删除测试”来说明问题所在：如果你能删掉整个实现然后重构，说明你真的理解这个系统。大多数工程师之所以恐惧删除代码，是因为：

这些都不是代码问题，而是评估问题。

Charity 有着从系统管理员到 SRE 的完整职业轨迹，亲历了从手工运维服务器到不可变基础设施的转变。她写道：

可变性是理解的头号敌人。原地修改的任何产物都会产生漂移，而漂移使系统无法维护。

Honeycomb 每周二定时杀掉最旧的 Kafka 节点，通过 cron 任务自动完成。为什么他们敢这么做？因为一切可重复，数据可重新生成，没有太多风险。

但代码不行。我们对代码的理解远不够深入，以至于不敢随意重写。

这恰恰说明：代码的不可再生性，是我们对其缺乏理解的症状。

如果 2025 年是”vibe coding”的狂欢——AI 生成了和中等工程师同样质量的代码，未来充满了不确定——那 2026 年正在成为回归纪律的一年。

为什么？因为 AI 无法获取你脑子里那些没有写入系统的知识。 只有当你把隐性的理解编码到系统中，AI 才能利用它。

这意味着：

Charity 一针见血地指出：

人类大脑不擅长验证。吹毛求疵、重复劳动——这是你们最不该固守的东西。在验证方面我们永远赢不了机器，我们就是最弱的一环！

她的信心在哪里呢？在于创造力、灵感、逻辑跳跃，这些属于人类的优势。所以我们不要要去和最不适合人类的领域死磕。

拜托，千万不要把”人类是最佳质量把关者”当作你支持人类参与软件的核心论点。

目前，真正采用短周期快速反馈循环的团队少得惊人——可能只有 5%，绝对不到 10%。

AI 工具第一次让这种工作方式变得触手可及。工程纪律规范投资的回报将是巨大的、非线性的。没有纪律支撑的直接 AI 式开发也会有很多（想想就知道有多混乱了）。

但最终，价值由持久性支撑，而非可丢弃性。没有人想每天起床发现 Slack 的按钮和菜单全变了位置。

Charity 最后引用 Adam Jacob 的话收尾：

“这依然是技术，而技术需要技术人员。”

她期待着学习新的工程问题，审查不同类型的制品。而且——再也不用做又臭又长、磨人的两年期 API 重写或绞杀者迁移了。

AI 对工程提出了更高的要求：更严谨的纪律、更好的可观测性、更彻底的理解。但回报也是巨大的——把我们从那些最痛苦的重复劳动中解放出来，去做真正有价值的事情。

如果这篇文章对你有启发，欢迎 点赞、在看、转发 给你身边的工程师朋友。你也在经历 AI 带来的工程变革吗？评论区聊聊你的感受。

关于作者： Charity Majors 是 Honeycomb 的 CTO 和联合创始人，SRE 和可观测性领域的权威，合著了《可观测性工程》一书。

#AI #软件工程 #工程师 #SRE #可观测性 #工程纪律