【AI编程】AI时代更需软件设计基本功|dtsola

配套视频：https://www.bilibili.com/video/BV1F8GR6sEWQ/

大家好。我有一个消息想告诉你们，希望能让你们安心——对那些认为自身技能在 AI 新时代已毫无价值的人：我坚信，软件基础比以往任何时候都更加重要。

我是一名教师，最近正在讲授一门课程：《面向实战工程师的 Claude 编程课》。在开发这门课程的过程中，我不得不重新审视 AI 编程的本质，而这一过程让我回到了那些经典的软件工程书籍中，找到了意想不到的答案。

一切从「规格到代码」运动说起

最近，软件开发圈兴起了一股「规格到代码（Specs to Code）」的浪潮。它的理念听起来非常诱人：

用自然语言写下应用的规格说明
用 AI 将其转化为代码
遇到问题？回到规格文档修改，重新编译即可

听起来很美好，对吧？我也这么想过。我亲自尝试了这套流程，结果却出乎意料——我运行了一次，得到了还算可以的代码；再运行一次，代码变差了；又运行一次，更糟了。反复编译，最终只剩一堆垃圾。

这种体验相信很多人都有过。问题出在哪里？

根本原因在于：这不过是「氛围编程（Vibe Coding）」换了个名字。 当你选择忽视代码、任由 AI 自我管理时，代码质量只会螺旋式下降。

正如《程序员修炼之道》中所描述的「软件熵」：每次修改代码时，如果只考虑当前改动而忽视整体系统设计，代码库就会越来越混乱，直至崩溃。

这让我意识到一个被很多人忽视的事实：

代码并不廉价。事实上，糟糕的代码是有史以来代价最高的。

一个难以修改的代码库，会让你无法充分释放 AI 的全部潜能。而 AI 在优质代码库中，表现会极为出色。这意味着——优质代码库比以往任何时候都更重要，软件基础也比以往任何时候都更重要。

这正是本文的核心论点。

五大 AI 编程故障模式与解决之道

下面，我将分享在实践中遇到的五类典型故障，以及从经典软件书籍中找到的应对方法。

故障一：AI 没有按我的意图行事

你脑中有一个清晰的想法，AI 却做出了完全不同的东西。这种情况几乎每个人都遇到过。

为什么会这样？

Frederick P. Brooks 在《设计原本》中提出了一个概念——设计概念（Design Concept）。当多人协同设计时，彼此之间会浮现出一个稍纵即逝的共同构想，这个隐性的「构建理论」就是设计概念。它不是一份文档，也不能写进 Markdown 文件，它存在于协作者的共同理解之中。

问题在于：你和 AI 之间根本没有共同的设计概念。 你以为说清楚了，AI 却有自己的理解。

解决方案 — 技巧①：Grill Me（面试式追问）

我开发了一个极其简单却非常有效的技能，叫做「Grill Me」。使用方式如下：

"Interview me relentlessly about every aspect of this plan until we reach a shared understanding. Walk down each branch of the design tree, resolving dependencies between decisions one by one."

（对这个计划的每个细节无情地追问我，直到我们达成共同理解。逐一梳理设计树的每个分支，逐步厘清决策间的依赖关系。）

就这几行提示词，AI 会向你提出 40 个、60 个，甚至 100 个问题，直到双方真正达成共识。这个技能在 GitHub 上迅速走红，获得了约 13,000 颗星。

通过这个过程生成的对话，可以直接转化为产品需求文档（PRD），或拆解为具体的开发 Issue，交由 AI 代理执行。

故障二：AI 表达冗长，鸡同鸭讲

你和 AI 说的似乎不是同一种语言。AI 的回复啰嗦、绕弯，实现结果总是偏离你的预期。

为什么会这样？

这让我想起了一个经典的开发场景：当你为一个陌生领域（比如微芯片）开发应用时，领域专家用你听不懂的术语描述需求，你再把它翻译成代码——这种翻译过程中，信息损耗极大。

领域驱动设计（DDD）为此提出了「通用语言（Ubiquitous Language）」的概念：开发者之间的对话、代码的表达、与领域专家的沟通，都应源于同一套共享的领域模型和术语体系。

解决方案 — 技巧②：与 AI 共建共享语言

我开发了一个「通用语言技能」：自动扫描代码库，提取核心术语，生成一份通用语言 Markdown 文件，其中包含多张术语对照表。

在规划和编码时，我始终打开这份文件，并将其传递给 AI。效果显著：AI 的思考变得更加简洁，实现结果也更贴近规划意图。 通过阅读 AI 的思考轨迹，我发现共享语言不仅提升了规划质量，还大幅减少了沟通中的歧义。

故障三：AI 构建了正确的东西，但它就是不能运行

方向对了，代码也写了，但就是跑不起来。

解决方案 — 技巧③：建立有效的反馈循环

解决这个问题的思路很直接——给 AI 更多、更及时的反馈：

使用静态类型：如果你还没用 TypeScript，现在就该用了
给 LLM 访问浏览器的能力：开发前端应用时，让 AI 能够实时查看运行结果
引入自动化测试：让 AI 能够即时验证自己的输出

然而，即便有了这些反馈循环，AI 也往往不能充分利用它们。它习惯于一次性生成大量代码，然后才想起来做类型检查或跑测试。

《程序员修炼之道》将这种行为称为「车速超过车灯照射范围（Outrunning Your Headlights）」——开得太快，反馈跟不上。反馈速率就是你的速度上限。

故障四：AI 一次做太多，代码质量失控

AI 倾向于一口气生成大量代码，而不是小步迭代、边做边验证。

解决方案 — 技巧④：使用 TDD（测试驱动开发）

TDD 能够强制 AI 真正采取小步迭代的方式：

先写测试（定义期望行为）
让测试通过（最小化实现）
重构代码（优化设计）

这个循环让 AI 每一步都有明确的反馈，不会「超速」。

但测试本身也很难写——你需要决定测试单元的粒度、需要 mock 哪些依赖、优先测试哪些行为。这些决策彼此关联，而优质的代码库天然更容易测试。这又把我们带回到了代码质量的核心问题。

故障五：代码库结构混乱，AI 无从下手

随着代码库膨胀，AI 开始无法理解你的代码逻辑，改动频繁引入 Bug，整个系统越来越难以维护。

为什么会这样？

John Ousterhout 在《软件设计哲学》中区分了两种模块：

类型	特征
深模块（Deep Module）	接口简洁，内部封装大量功能，隐藏复杂性
浅模块（Shallow Module）	接口复杂，功能单薄，大量细节暴露在外

AI 非常擅长创建浅模块——大量细小的代码块散落各处。但这样的代码库对 AI 自身来说也是噩梦：它需要在数十个微小模块之间来回导航，很快就会迷失，无法理解整体逻辑。

解决方案 — 技巧⑤：设计接口，委托实现

将相关代码封装进深模块，形成清晰的边界：

接口由你精心设计：这是系统的骨架，需要人类的战略思维
实现委托给 AI：在清晰的接口约束下，AI 可以自由发挥
在接口处进行测试：边界清晰，测试自然简单

这样做还有一个额外的好处：它能拯救你的大脑。 你可以把深模块当作「灰盒」来处理——只需理解接口，不必深入每一行实现细节。这在 AI 大幅提升代码产出速度的今天，对于防止认知过载至关重要。

每天投资于系统设计

Kent Beck 说过：每天投资于系统设计（Invest in the design of the system every day）。

这正是「规格到代码」运动最大的问题所在——它让我们逐渐放弃了对系统设计的投入。当你只是不断地修改规格、重新编译，你实际上是在把系统设计的责任完全交给 AI，而 AI 并不具备这种战略视角。

在 AI 时代，人与 AI 的分工应该是这样的：

角色	定位	职责
AI	战术程序员（一线士官）	具体代码实现、执行修改
你	战略思考者（指挥官）	系统设计、接口规划、方向把控