AI 编程中的软件基本功
创建时间： 2026-05-09
来源： [[sources/Software Fundamentals Matter More Than Ever — Matt Pocock - 逐字稿]]
相关： Deep-Module-Architecture、Harness-Engineering、Vibe-Coding-in-Prod、Vibe-Coding-to-Agentic-Engineering
Matt Pocock 在《Software Fundamentals Matter More Than Ever》中提出一个反直觉判断：AI 让写代码变快，但这不意味着代码变便宜；相反，坏代码在 AI 时代比以往更昂贵。因为 AI 的产出质量高度依赖代码库是否可理解、可测试、可修改。一个结构混乱的代码库会让 AI 更快地制造软件熵，而一个设计良好的代码库会让 AI 的速度成为杠杆。
这页是对 Deep-Module-Architecture 的上位补充：深模块是其中一个关键结构解法，但整场演讲的主题更大，是把 AI 编程重新拉回软件工程基本功。
反对 specs-to-code 幻觉
Matt 批评的对象是 specs-to-code 路线：人只维护规格说明，不看代码；一旦应用出错，就修改 spec，再让 AI 重新生成代码。
他的实际体验是：每次“重新运行编译器”都会得到更差的代码。表面上这是 specification-driven development，实质上只是 vibe coding 的另一种名字：它试图把代码库自身的设计责任交给模型自动处理。
核心问题不是 AI 不会写代码，而是软件系统天然有熵增趋势。每一次局部修改如果不考虑整体设计，都会让系统更难理解和修改。AI 只是把这种熵增加速了。
Code is not cheap
“代码很便宜”是 AI 编程时代常见口号，但 Matt 的反驳是：
坏代码不是便宜，而是前所未有地昂贵。
原因是：AI 在好代码库中表现很好，在坏代码库中表现很差。坏代码库会破坏 AI 可用的全部放大器：
| 放大器 | 坏代码如何破坏它 |
|---|---|
| 可理解性 | AI 找不到正确模块，或误解依赖关系 |
| 可修改性 | 每次修改牵动散落逻辑，回归风险升高 |
| 可测试性 | 没有清晰边界，只能写脆弱、笨重、昂贵的测试 |
| 反馈循环 | 类型、测试、浏览器检查给不出足够精确的信号 |
| 人类审查 | 人的脑力被实现细节淹没，无法保持战略判断 |
因此 AI 时代的核心不是“少关心代码”，而是更关心代码库的结构质量。
五个失败模式与基本功解法
1. AI 没做出我想要的东西
根因不是 prompt 不够长，而是人和 AI 没有共享同一个 design concept。Frederick P. Brooks 在《The Design of Design》中把 design concept 描述为多人共同设计时围绕作品形成的隐性理论。它不是一个 Markdown 文件，而是“我们到底在造什么”的共同理解。
Matt 的对应 skill 是 Grill Me：让 AI 持续追问计划的每个分支，逐项解析设计树上的依赖决策，直到双方形成共享理解。它比急着产出 plan 更重要，因为 plan 是资产，design concept 是资产背后的理解。
2. AI 太啰嗦，双方语言不一致
这类似开发者和领域专家之间的语言鸿沟。Matt 借用 DDD 的 ubiquitous language：让对话、代码表达和领域模型使用同一套术语。
在 AI 编程中，通用语言可以做成一个术语表，记录代码库中的关键名词、含义、使用位置和边界。它让 AI 的思考更短、更准，也让实现更贴近计划。
3. AI 写了正确方向，但东西不工作
解法是反馈循环：静态类型、浏览器访问、自动化测试，以及 TDD。问题在于 AI 默认会 outrun its headlights，也就是一次写太多代码，然后很晚才检查。
《The Pragmatic Programmer》的原则是：反馈速度就是速度上限。TDD 强迫 AI 小步前进：先写测试，让测试通过，再重构设计。它不是为了仪式感，而是为了让模型每一步都有可验证信号。
4. 测试很难写
测试困难常常不是测试工具问题，而是代码结构问题。John Ousterhout 的深模块理论提供了解法：用少量、深、接口简单的模块隐藏复杂性。
深模块让测试落在接口上，而不是落在一堆散落实现上。浅模块则会制造大量微小依赖，AI 和人都必须在脑中追踪这些依赖，测试自然变脆。
5. 人的脑子跟不上 AI 速度
当 AI 交付速度大幅提升，人类的瓶颈不再是“写得慢”，而是“理解和审查跟不上”。深模块给出一种认知解法：设计接口，委托实现。
人类仍然要掌握模块地图，决定边界、接口和测试策略。但在低风险模块中，只要外部接口可理解、可测试，就不必逐行审查所有实现。AI 是战术程序员，人类是战略程序员。
人机分工
Matt 的最终框架与 Vibe-Coding-to-Agentic-Engineering 一致：AI 可以作为地面上的战术程序员，快速完成局部代码变更；但必须有人在更高层级思考系统设计。
人类不可外包的部分包括：
- 共享 design concept：知道到底在构建什么
- 通用语言：确定领域术语和模块命名
- 模块地图：知道系统由哪些深模块构成
- 接口设计：决定哪些复杂性应被隐藏
- 反馈循环：为 AI 提供类型、测试、浏览器和验收信号
- 每日设计投资：持续维护系统，而不是只堆功能
Kent Beck 的原则可以概括这场演讲的结论：每天都要投资系统设计。specs-to-code 的危险在于它让人从设计责任中撤退；AI 编程真正需要的是把设计责任提到更高层。
与现有 wiki 的关系
- Deep-Module-Architecture：本页的结构性解法，解释为什么深模块能提升 AI 和人类的可理解性。
- Harness-Engineering：本页的环境性解法，把反馈循环、约束、交接工件和评估机制机械化。
- Vibe-Coding-in-Prod：本页补充其生产级边界：可以放手实现，但不能放手设计、语言和测试。
- Vibe-Coding-to-Agentic-Engineering：本页进一步说明“理解不能外包”的软件工程版本。
参考资料
- 来源：Software Fundamentals Matter More Than Ever — Matt Pocock - 逐字稿
- 视频：Software Fundamentals Matter More Than Ever — Matt Pocock
- 理论根基：John Ousterhout《A Philosophy of Software Design》、Andrew Hunt & David Thomas《The Pragmatic Programmer》、Frederick P. Brooks《The Design of Design》、Eric Evans《Domain-Driven Design》、Kent Beck 的系统设计原则