这场架在编程圈吵了一个多月，到现在还没打完。
7月3日，HashiCorp 联合创始人、Ghostty 作者 Mitchell Hashimoto 在 X 上发了三个词：“I read the code”（我读代码）。这条推文获得近83万次浏览，被解读成对 Vibe Coding 的公开反驳。36氪
20天后，《代码整洁之道》作者、写了六十多年代码的 Robert C. Martin——大家熟悉的 Uncle Bob——给出了截然相反的答案——他的策略，是完全不去读 Agent 写出来的任何代码。36氪这条推文获得超480万次浏览，接近前者的六倍。这不是两位大佬的八卦，它问的是每个每天开着 Claude Code、Cursor 干活的人都绕不开的问题：AI 写的代码，我到底要读多少？
读派守的是什么：出了事，我能接手调试
读派的逻辑不是勤奋美德。分布式系统工程师、《分布式系统可观测性》作者 Cindy Sridharan 给出了最狠的版本：每当听见有人说"代码全是 Claude 写的，我不知道它是怎么工作的"，她就直接判定——这个人没有能力调试这些代码，也就不配说拥有它。36氪任何真正看重可靠性和稳定性的人，都不会信任这样的供应商。
开源工程师 Christine Lemmer-Webber 还给这个过程起了个名字，叫"Vibe 滑坡"：没有人一开始就打算彻底放手。常见的路径是——先谨慎地用 AI 写代码，认真做审查；然后速度越来越快，审查一点点放松，不知不觉一路滑向完全凭感觉的 Vibe Coding。她的判断是，人们对这段旅程的掌控力，远不如自己认为的那样强大。36氪
这里还有一笔现实的账：就算是经验丰富的程序员，也没法保证找出一个100行程序里的所有 Bug，而现在的大模型一次生成的代码远超100行。人读代码的速度，本身就是瓶颈。
不读派赌的是什么：用约束替代眼睛
Uncle Bob 的"不读"不是摆烂。他的做法是给 Agent 设一道道严格的关卡：单元测试、Gherkin 测试、QA 流程、质量指标、变异测试、覆盖率。代码把这些关卡全闯过去，他才对结果抱有"很高的信心"。36氪这套思路有它的自洽：读是抽查，测是校验。AI 生成代码的速度早就超过人读代码的速度，与其用人眼做最后一道防线，不如让可执行的检查做防线。
但他招来的追问同样尖锐：如果保障质量的是测试，那谁来保障测试是对的？——测试本身，往往也是 AI 写的。36氪
争的本质不是读不读，是拿什么换信任
把两派的论点摆在一起，分歧的本质其实很清楚：读派拿理解换信任——我读了、我懂了、出了事我能接手，信任建立在"我能调试"上；不读派拿可校验的约束换信任——我不读，但任何错误必须先过机器关卡，信任建立在"错误出不了门"上。
两条路没有绝对的高下，关键看事故成本落在谁头上。出了事是你自己熬夜填坑，理解和约束都行；出了事是生产事故、是别人为你的代码买单，"我没看"就不是一个能被接受的解释。
Rust 官方把第三条路写进了规则
两派吵着吵着，Rust 项目在8月5日拿出了一份少见的官方答案：Jynn Nelson 在 Inside Rust 博客发布了一套 AI 编程准则，编译器、标准库、类型系统、rustdoc、bootstrap 五个团队已经批准，用来规范向 rust-lang/rust 主仓库提交代码时该怎么用大模型。36氪
一句话总结：可以让 LLM 回答问题、分析、提炼、完善、检查、提出建议和审查，但不能用它来创造。36氪
具体分成三档。完全放开的，是私人用途：问代码库问题、总结讨论串、私下让 AI 审自己的代码，只要输出只有你自己看，没人管。可以使用但必须披露的，包括机器翻译、修拼写这类微小修改、借助 AI 找 Bug，以及 AI 审查机器人——机器人必须用独立且明确标记的账号跑，不想看的人可以直接屏蔽。明确禁止的，是 LLM 直接生成评论、文档、编译器诊断信息，任何离了 AI 就跑不通的流程，以及仅凭 AI 的审查结论就决定合并还是拒绝。
这套规则真正有约束力的地方在执行：准则自己承认，很多条款技术上根本没法强制执行，但隐瞒或虚假陈述 AI 使用情况，会被视为违反项目《行为准则》，和骚扰行为处于同一级别，第一次警告，反复违规可能被封禁。36氪原文写得很直白：目标不是抓住每一次违规，而是消除任何可以推脱的空间。
还有两条操作细节对新手特别重要：LLM 创建的 PR 必须提前找好一位明确愿意负责的审阅者；如果你改的那部分代码原本没有测试套件，你得先自己补一套，否则这个 PR 只能关闭。隔壁的 Zig 则是另一个极端：全面禁用——不许 AI 生成代码，不许转述 AI 内容，连翻译和头脑风暴都不行。Zig 的方案执行成本低、遵守成本高；Rust 的方案反过来，审阅成本高，但保住了贡献者使用工具的权利。一刀切和精细划分，两个最硬核的系统级语言社区各探了一头。
普通开发者的真实样本
知乎上这两天的高赞回答，正好构成三种路线的样本。
一种是彻底放手派。有开发者从2月开始用 AI 写代码，前两个月还看一眼，后面几乎不看，编码全部交给 AI，预期一两周的活半天干完。知乎注意他的前提：他负责的产品只有他一个开发，事故成本和效率收益都内化在自己身上。
一种是规则派。有人攒过一份越滚越长的提示词规则清单——“不要动配置文件”“改完记得跑测试”——后来全删了。原因很简单：机器能检查的规则，写进提示词，聊几轮就被 AI 忘了。知乎这本质上就是 Uncle Bob 思路的落地：别靠嘴叮嘱，靠检查。
还有一种是流程派，把 AI 编程拆成规划、对抗评审、执行、验收四步，先动脑再动手，不把两者都甩给 AI。知乎
三个样本，三条路线，恰好落在 Hashimoto 和 Uncle Bob 之间的光谱上：读懂它、不读但约束住它、把"读"和"审"做成流程。
所以，到底该读多少？
与其站队，不如按场景切分。判断标准就一句话：事故成本落在谁头上，决定你该读多少。
一次性脚本、演示 Demo、探索性原型：能跑就是验收标准，不读或扫一眼即可。这里留债，债也不值钱。
长期维护的业务代码：不必逐行，但两处不能跳——边界（输入输出、异常分支）和数据流向。测试是"不逐行读"的前提，没有测试就老实读。
基础设施、资金、安全相关：约束全套加上重点逐行。Uncle Bob 的方案只在测试充分时成立，这里不能省。
开源贡献：先看项目的 AI 政策。Rust 系项目开始成文，该披露不披露，可能直接吃封禁。
再附一条自检标准，来自 Cindy Sridharan：如果同一个 Bug 被 AI 反复修都修不过，说明你对这段代码其实没有掌控力——该停下来读了。
接下来值得盯什么
这场争论短期内不会结束，有两件事值得跟进：一是看会不会有更多开源项目跟上 Rust 的"准则+披露"路线，大型项目如何执行是下一个观察点；二是"测试由谁来管"的问题——AI 写的代码有人立规矩了，AI 写的测试谁来立规矩？
你站哪一派：逐行读、坚决不读，还是中间路线？评论区聊聊。
