AI 时代的软件设计

我有一阵子没在这里写东西了。当我们将多年线下教学经验压缩进自服务式的高级软件设计课程时，它解放了我们，让我们得以通过建立一家风投支持的公司，以更大规模影响软件工程。我很高兴地宣布，今天正是 Command Center 的 1.0 发布日——这是一个为关心质量的人打造的 AI 编码环境。一位校友兼用户称它“就像有一个刚从高级软件设计课程毕业的校友在为我工作，而且是新鲜出炉的。”

这正是一个反思的好时机：在 AI 编写软件的时代，软件设计技能还有什么用？

我的答案是：随着底层实现技能被自动化，高层设计技能已成为人类工程师的核心优势。

时代在变

回到 ChatGPT 和 Copilot 时代的 AI 编码，许多人哀叹“初级开发者的复仇”，认为对海量知识的平民化访问会削弱经验丰富的优势。然而事实恰恰相反，对高级工程师的需求在上升，而有才华的毕业生却在失业。未来反而更接近微软亿万富翁 Charles Simonyi 的愿景：一个思维敏捷、品味犀利的中心程序员，即“元程序员”，负责所有设计，而一群“苦力”则负责实现小块代码的脏活累活。

但 AI 难道不会连元程序员也取代吗？我一直在观察 AI 的表现：当 OpenAI o1 刚发布时，我们的软件设计测验中它几乎答不对 1/5 的问题；到去年 12 月，它已经能轻松答对 3-4 题——而且如果你让 Claude 扮演“grug 脑开发者”，它甚至能全对。我们早已过了我直接告诉 Copilot 拆分一个函数、而它根本做不到的日子。然而昨天我还在对着 Claude 吼：当我告诉你把一种数据类型替换成另一种时，你需要替换所有引用，而不是到处添加转换——拜托，看看所有调用者好吗？为什么你就是不能按指令行事？

AI 的训练广度很深，但能从你的指令中学到的东西很少。只要市面上绝大多数代码仍然是由中等设计水平的人编写的，AI 的设计就不会很好。Command Center 的重构代理极大地改进了现有水平——已发布的版本大概好 1.5-2 倍，我们内部版本则更接近 3-5 倍。而那些 1000 倍级别的干预——那些需要与发明 async/await 编程同等聪明才智才能简化整个代码库的方法——当然仍是人类的领域。

然而，“好代码”的定义也在变化。好的实践源于第一性原理和环境特质的结合。像“每个函数只能有一个出口点”和“你应该至少用调试器单步执行所有代码一次”这样的古老建议，来自语法高亮和单元测试还不普及的时代。

更重要还是更不重要？

这在 AI 时代会如何发展？拥有一个难以误用的简单 API（我们课程第 3 单元所讲）正变得不那么重要。AI 非常擅长完美地使用最危险的公共 API，因为它们已经读过无数正确用法以及因错误使用而导致修复的案例。对你自己的代码 API 来说，难以误用还重要吗？我不知道，因为我没有冒险让我的 AI 放任它们常见的设计缺陷。

另一方面，消除隐藏耦合——那些必须同步修改、但不同步时不会产生编译错误的代码片段（我们课程第 2 单元所讲）——正变得更加重要。代码相互纠缠的速度远远超过模型读取和思考大型代码库的能力，而且它们连人类那种微弱记忆去跟踪这些秘密依赖关系都做不到。尽管我和许多人都曾经历过因 AI 引发的隐藏耦合导致的严重 bug，但（敲木头）我不认为这会在模型层面有所改变。我们的重构代理在这方面改进很大——但因为隐藏耦合从根本上讲是关于理解设计意图的，所以预防它仍然需要有知识的人类掌舵，这个人更多使用 Command Center 的可理解性和走查功能，而不是重构功能。

所有这些的结论是：当我们的一位外包工程师转到一家代码质量较差的公司的后，他发现他使用 Claude Code 的效果大打折扣。我们一直在开发一套基准测试，通过 AI 进行后续工作时所需的工作量和产生的 bug 数量来衡量代码质量。

因此，我可以继续审视我们所有的教学和原则，评估哪些变得更重要、哪些变得不那么重要。避免隐藏前提条件和“隔空施法”式的要求？相对意义上更重要，即使曾经需要数百小时调试的一些后果现在可以由 AI 调查。拆分函数或合并条件直到得到最简配置？不那么重要了——你可能仍然需要看一眼那些“烂代码”，但另一个智能体在处理它。设计易于扩展的文件格式和数据库模式？不确定——也许现在可以忍受一个包含数百个针对不兼容旧格式的兼容补丁的文件夹，也可能那是通往更深层 bug 地狱的大门。

但明确的是，随着在职经验积累机会的阶梯被抬高，对诸如高级软件设计课程这样的刻意练习载体的需求正在上升。

竞争框架

当然，也有很多人说设计已死。甚至有报道称大公司指示其工程师停止阅读代码或关注设计。

Cedric Chin 在 Commoncog 上写道，对 AI 有三种态度：“永不 AI”派认为它毫无用处；“务实工程师”派认为它是实用工具，但仍需由遵循传统工程实践的人类控制；“软件黑工厂”派则鼓吹 AI 控制 AI、无需人工干预的不可言说的交付速度。每个阵营都有自己的“数据框架”，即一套解释所有证据的心智模型，这使得各阵营很难吸收其他阵营的视角和经验。

不出所料，我坚定地站在中间阵营，我们对黑工厂派人士有这样的话要说：

思考的速度

当我刚开始构建加速代码库学习的软件时，我们招募了许多软件工程师——大约占这份通讯读者的 1%——让他们在有聊天机器人或有结构化教程帮助的情况下加入一个代码库（见论文）。我们发现，人们花在聊天机器人上的时间越多，他们做得越差，并推测许多聊天机器人用户如果没有支持反而会做得更好。从思维到手指再到 AI 再返回的延迟，相比思考速度简直是天文数字。这就是为什么把自己从循环中自动化出来可能成为通往迟钝的路径。

大约 15 年来，我一直相信构建比人类更聪明的人工智能是一项危险的事业，对我们来说可能就像人类对黑猩猩和渡渡鸟的繁荣所做的那样危险——这种信念有时被贬称为“末日论”。我是暂停大型 AI 实验公开信的签署者之一。但我仍然在很多方面押注于我们将会迎来一个由人类统治、拥有惊人劳动自动化的未来。对于这个未来，过去常说“软件工程将是最后被自动化的，因为我们首先自动化其他一切。”

尽管 AI 编码器在 AI 革命中来得较早，我仍然认为那个对未来的怀旧愿景中有很多真理。虽然让一个 div 居中或许很容易被机器学习，但最后被自动化的，将是那些精通新工具、达到更高技能水平以催生持久系统的人。