黑纹白斑马-马特波科克软件基础能力比以往任何时候都更重要


核心观点

代码不是廉价资产,软件基础能力比以往任何时候都更重要。 AI 是优秀的一线执行者,但需要人类从战略层做系统设计。掌握旧书里的经典实践(设计概念、通用语言、深度模块、TDD),就能避免 AI 编程的常见失败。

1. 为什么”代码很廉价”是错的

观点反驳
”代码很廉价,可以随意生成”坏代码的成本比以往更高
”需求转代码:改需求就行”不看代码反复生成 → 代码越来越差(软件伤)
“AI 会自己管理代码”换了说法的盲干

关键逻辑: 如果代码库难以修改 → 你无法享受 AI 带来的好处 → AI 在好的代码库里表现出色 → 好代码库比以往更重要


2. 五个常见失败场景与解法

失败 1:AI 输出不符合预期

问题根因解法
脑子里有清晰想法,AI 做出来完全不一样没有和 AI 达成共同的「设计概念」“拷问我”技巧

“拷问我”技巧: 在 prompt 中加入 "grill me",让 AI 反复向你提问(40-100 个问题),直到达成共同认知。对话内容可直接整理为产品需求文档。

来源

概念来自《The Design of Design》(Fred Brooks)—— 多人协作时需要「设计概念」:关于产品的无形共识性底层逻辑。


失败 2:AI 输出太冗长,各说各话

问题根因解法
和 AI 沟通像鸡同鸭讲缺乏共享语言通用语言(Domain-Driven Design)

通用语言做法:

  • 用 Markdown 文件列出你和 AI 都认可的数据列表
  • 保证定义和实际含义完全一致
  • 写代码、讨论、沟通全程使用这些术语
工具

他做了一个「通用语言生成工具」:扫描代码库 → 找出数据 → 生成 Markdown 表格文件 → 传给 AI + 自己随时查看。


失败 3:代码就是跑不起来

问题根因解法
功能对了但跑不起来缺乏反馈循环测试驱动开发(TDD)

反馈循环三件套:

  1. 类型系统(TypeScript)
  2. 浏览器访问权限(前端开发时让 AI 能查看页面状态)
  3. 自动化测试
AI 的弱点

AI 默认不擅长「边开发边测试」——它会一次性产出过多代码,然后才想起来该跑测试。TDD 迫使 AI 小步迭代。


失败 4:AI 产出大量浅度模块

模块类型特征AI 适配度
浅度模块功能少、接口复杂、凌散小代码块差——AI 难以查找和理解
深度模块功能多、接口简单、封装复杂度好——AI 只需关注接口

深度模块优势:

  • 顶层只暴露对外接口 → 人把控接口设计
  • 内部实现交给 AI → 只要测试通过即可
  • 把模块当「黑盒」→ 大幅降低认知负担

失败 5:大脑跟不上代码产出速度

问题根因解法
代码越写越多,脑子不够用凌散结构需要记住所有信息深度模块 = 黑盒
核心理念

只要理解模块用途 + 设计好外部接口 → 内部实现交给 AI → 外部测试验证功能即可。金融等核心模块例外。


3. 角色重新定义

角色职责
AI优秀的一线执行程序员(基层执行者)
战略层思考者(系统设计、接口设计、模块布局)
核心信息

这需要的是我们已经用了 20 年甚至更久的软件基础能力——而不是什么新技能。


4. 引用的经典著作

书名核心概念
《Software Design Philosophy》(John Ousterhout)坏代码 = 复杂代码 = 难以修改;深度模块 vs 浅度模块
《程序员修炼之道》软件伤(熵增)、没人能完全清楚自己想要什么
《The Design of Design》(Fred Brooks)设计概念(共享共识)、依赖关系
Kent Beck每天都要为系统设计投入精力;规范定义代码

5. 行动清单

场景建议
开始新功能用 “grill me” 让 AI 先问清楚再动手
与 AI 沟通建立通用语言 Markdown 文件,全程使用
写代码TDD:先写测试 → 通过测试 → 重构
代码结构深度模块(少而深)> 浅度模块(多而浅)
日常习惯每天投入精力思考系统设计(Kent Beck)

局限性
  • 演讲基于 Cursor/Claude Code 等工具的经验,其他 AI 编程工具可能有差异
  • “通用语言生成工具”为演讲者自制,尚未广泛验证
  • 深度模块策略对金融等核心模块不适用,需谨慎判断

GitHub - mattpocock/skills: Skills for Real Engineers. Straight from my .claude directory. · GitHub