核心总结
这篇新闻围绕AI生成代码是否需要人工阅读展开，两位顶级开发者（Mitchell Hashimoto和Uncle Bob）的相反观点引发了开发者圈的大讨论。本质上，这是AI时代代码生产方式的变革：过去靠人工逐行审查保证质量，现在有人主张用严密的自动化测试体系替代，同时要根据代码的重要程度调整策略——核心代码必须严控，而大量“不重要”的代码可以靠AI生成和验证，用“廉价代码堆”保护“珍贵代码”。
一、两位大佬的对立：读代码是底线还是旧习惯？
- “我读代码”派：Mitchell认为，只要你要对代码负责（提交、部署、维护），就必须读AI写的代码，这是职业底线。分布式系统专家Cindy更直接：“不知道代码怎么工作，就调试不了它，没资格说掌控它——客户不会信任连自己代码都搞不定的供应商。”
- “我不读代码”派：Uncle Bob（写了60年代码的老炮）说，他完全不读AI生成的代码，而是给AI设“紧箍咒”：单元测试、自然语言场景测试（Gherkin）、变异测试（故意改代码看测试能不能发现）等。只要代码通过这些层层验证，他就相信结果。
两派的矛盾点：人工审查速度赶不上AI生成速度，到底是牺牲效率保审查，还是用体系化验证替代人工？
二、“Vibe滑坡”：为什么不读代码可能会失控？
开源工程师Christine提出“Vibe滑坡”现象：
一开始，大家用AI写代码时还会认真审查；但AI生成太快，慢慢就放松了检查，最后变成“凭感觉写代码”（Vibe Coding）——不是主动想偷懒，而是惯性推着走，停不下来。
更麻烦的是：AI一次能生成几百行代码，人类根本审不过来；就算是老手，也未必能找出100行代码里的所有bug。长此以往，代码质量会越来越差，出了问题根本没法修。
三、Uncle Bob的聪明办法：用“铁笼子”代替“盯梢”
Uncle Bob的策略不是“不管”，而是用“体系化约束”替代“逐行盯梢”：
1. 让AI写测试：AI生成代码的同时，必须生成对应的测试用例（比如“输入1+1，输出2”）；
2. 用AI写检查工具：甚至让AI写工具来检查测试是否可靠（比如有没有漏掉边缘情况）；
3. 多层验证：用变异测试（故意改代码里的数字或逻辑，看测试能不能发现）、QA流程等，让AI很难蒙混过关——要篡改测试，得改一堆相互关联的测试，成本太高；
4. 关键环节抽查：他会亲自检查最核心的自然语言测试场景（比如“用户支付成功后要收到通知”），确保大方向没错。
这套思路还被做成了开源工具old-coder，直接给开发者用。
四、代码也分三六九等：不是所有代码都值得逐行读
t3.gg创始人Theo把代码分成四层：
1. 垃圾级：一次性用的脚本（比如整理文件），看都不用看；
2. 烦人类：出问题会麻烦但不严重（比如个人博客插件）；
3. 解雇级：出错会丢工作（比如公司核心系统）；
4. 致命级：出错会死人（比如医疗设备、飞机控制系统）。
过去代码成本高，大家只能盯着后两层；现在AI让前两层代码几乎免费，所以可以用大量前两层代码来测试后两层：比如为一行核心代码生成1000行测试代码，做压力测试、边缘情况模拟——这在以前根本不敢想，现在成本为零。
五、AI时代的新玩法：用廉价代码保护珍贵代码
AI改变了代码的成本结构，所以质量保障的逻辑也变了：
- 过去：代码贵，每一行都要仔细读，为一行核心代码写1000行测试太浪费；
- 现在：AI生成代码免费，所以可以用“廉价代码堆”建一个“测试金字塔”——底部是大量一次性测试代码，顶部是少量核心代码。用底部的垃圾代码去暴露顶部核心代码的问题，既高效又安全。
比如：为心脏起搏器的代码生成10万行测试代码，模拟各种极端情况（低温、高压、信号干扰），确保核心代码万无一失——这在AI时代完全可行，而且比人工逐行审查更可靠。
最后想说
这场争论的本质不是“读不读代码”，而是AI时代如何重新定义“代码质量”：核心代码必须严控（无论是读还是用严密测试），而大量非核心代码可以交给AI，用更高效的方式验证。毕竟，AI的价值不是让我们偷懒，而是让我们把精力放在真正重要的事情上。