用AI做项目，先学编程？Uncle Bob：不用读代码，要会定标准

从「收藏课」到「不动手」：一个常见的困境

很多人想用 AI 做点东西，第一反应是收藏一整套编程课，打算学完框架、学完部署再动手。结果收藏越来越多，项目却一直没开头。这种路径依赖背后是一个默认假设：必须先把编程学一遍，才能指挥 AI 干活。

但这个假设正在被打破。Robert Martin（大家叫他 Uncle Bob）写了几十年代码，还写过《代码整洁之道》。他现在的做法是：Agent 写的代码他不去读，靠的是一圈严格的自动检查——什么算通过，事先定死。这做法争议不小，但他换掉的东西值得看一眼。

Uncle Bob 的「不读代码」实验：把信任交给证据

Uncle Bob 敢不读代码，前提不是「学得少」，而是「把要学的换了」——从读懂每一行，换成了定标准、看证据。这听起来像偷懒，实际上是把认知负荷从「过程监控」转移到了「结果验收」。

争议点在于：不读代码怎么保证质量？他的答案是自动检查圈。这套检查不是随便跑跑测试，而是把「什么算对」事先写成可执行的判据。Agent 的产出必须穿过这层筛子，穿不过就重来。

对不写代码的人来说，这个转向反而是好消息。你不需要先学会读每一行，要学的是「怎样算对」「拿什么证明」。而「什么算对」这件事，你在自己那一行本来就有一把尺子。

**自动检查圈（Automated Verification Loop）**指的是把「什么算对」写成机器可执行的判据，例如单元测试、类型检查、静态分析、集成测试等，任何代码在合并前都必须全部通过。它与「随便跑跑测试」的区别在于：判据是事先、穷尽式定义的，而不是事后挑几个用例验证。对不读代码的人来说，这套机制的价值在于把质量保证从「人的阅读理解」转化为「可重复、可审计的通过/失败信号」——你不需要看懂实现，只需要确认证据链完整。

两笔成本：努力成本与认知成本

不读代码不等于什么都不懂。交出去的活，进什么、出什么、怎样算对，你得心里有数；不然证据摆在面前，你也看不懂。这里有两笔成本要压到最低：

• 努力成本：不用每一步都自己做，只在关键的地方出手。就像那圈检查搭好一次之后，每次都替他把关。
• 认知成本：不用样样都学，但接口的输入输出、验收标准必须清楚。这是「看得懂证据」的底线。

「不用样样都学」和「什么都不懂」之间有一条清晰的线：前者是放弃过程性技能，后者是放弃判断力。Uncle Bob 的做法之所以成立，是因为他把判断力外化成了可执行的检查。

过程性技能 vs. 判断力是这里的关键区分。过程性技能指亲手完成实现所需的操作能力，如写语法、调 API、配置部署；判断力指评估产出是否满足目标的能力，如定义输入输出契约、识别失败模式、判断「跑通」与「跑对」的差异。AI 压低的是前者的边际价值，抬高的是后者的稀缺性。放弃过程性技能不等于放弃判断力，恰恰相反，它要求你把判断力显式化、可执行化，否则证据摆在面前也无从解读。

不写代码的人怎么「看证据」

对非程序员来说，这套逻辑可以落到具体动作上。你不需要懂 API 怎么调，但需要知道：这个功能输入什么、输出什么、什么情况下算失败。你不需要会部署，但需要能判断「跑通了」和「跑对了」的区别。

证据的形式可以很朴素：一组测试用例、一份对照输出、一个可复现的检查清单。关键是这些证据要在你动手之前就定好，而不是事后找补。

**可复现的检查清单（Reproducible Checklist）**是让非程序员参与验收的实用工具：把功能拆成若干条「给定输入 X，应得到输出 Y；若出现 Z 则判失败」的条目，每条都可独立执行、结果可对照。它的作用是把模糊的「感觉对了」转成二值判断，让不读代码的人也能凭证据做出接受或打回的决策。关键是清单必须在动手前定好，事后补的清单容易迁就已有结果，失去验收意义。

学什么，不学什么

传统路径要求先学语法、框架、部署，再动手。新路径要求先定标准、再搭检查、然后让 Agent 干活，人只在验收环节出手。两条路的分叉点在于：你把时间花在「自己能做」上，还是花在「能判断做得对不对」上。

Uncle Bob 的选择不是所有人都适用，但它揭示了一个可迁移的原则：当执行成本被 AI 压低之后，判断力的稀缺性就上来了。对想用 AI 做项目的人来说，先学编程不再是唯一入口，先学会定标准、看证据，可能是更短的路径。