AI时代编码新范式：为什么你应该生成更多代码而非逐行阅读

在AI编程工具日益普及的今天，开发者们对"是否应该逐行阅读AI生成的代码"争论不休。知名科技内容创作者Theo在一期视频中提出了一个颇具争议的观点：绝大多数工程师阅读的代码太多，而生成的代码太少。

这个论点乍看之下容易激怒两派人——既得罪了坚持"每行代码都必须审查"的严谨派，也让"随手糊代码"的激进派感到不满。但如果深入理解其背后的逻辑，你会发现这可能是关于如何最大化利用AI生成代码价值的一次深刻思考。

代码重要性的光谱：你的代码真有那么关键吗

Theo首先提出了一个"代码重要性光谱"的概念。光谱的一端是"只有一个访客的垃圾网站"，另一端则是"心脏起搏器的固件"——后者一旦出错，真的会致人死亡。

所有软件都落在这条光谱的某个位置上。而围绕AI代码的争论之所以陷入僵局，正是因为每个人都高估了自己在光谱上的位置。

这个光谱概念实际上源自软件工程中长期存在的风险分级思想。在传统软件开发中，不同行业对代码质量有完全不同的标准体系：航空航天领域遵循DO-178C标准（一套定义机载软件开发保障等级的国际规范），医疗设备受IEC 62304约束，而金融系统则需符合SOX合规要求。这些标准本质上就是在定义代码在"重要性光谱"上的位置。普通Web应用的一个CSS bug可能只是视觉瑕疵，但心脏起搏器固件中的同类错误可能导致设备失效。理解这个光谱，有助于开发者合理分配有限的审查资源，而不是对所有代码一视同仁。

Theo敏锐地指出了一个心理现象：当有人对AI生成代码发表看法时，听者会本能地把自己代入光谱的某个位置。如果他认同这个观点，就会假设说话者和自己处于同等或更高的位置；如果他反对，则会假设对方地位更低。这种自我定位的偏差，使得理性对话几乎不可能。

更关键的是，很多人认为自己写的代码比实际上重要得多。这种自我膨胀让讨论变得困难重重。

假设每行代码都很重要：用更多代码验证关键代码

为了推进论证，Theo做了一个让步：假设那些声称"每行代码都关乎生死"的人说的都是真的。

即便如此，他抛出了一个被很多人忽视的事实——代码的用途远不止于交付上线。

如果你的代码重要到需要保证每一行都绝对正确，那么你完全可以用大量"不那么重要"的代码去验证那些"至关重要"的代码。他甚至断言："没有任何一个人，写的代码是100%关键任务级别的。因为如果真是那样，说明你不是个好工程师——你需要在其他事情上磨练技能、持续学习和成长。"

这一观点呼应了软件工程中"测试金字塔"的经典理念：底层有大量单元测试，中间是集成测试，顶层是少量端到端测试。每一行生产代码背后，理想状态下都应有数倍甚至数十倍的测试代码在保驾护航。AI的出现让这个比例可以被推到前所未有的极端。

从传统开发到AI编程：代码生成比例的巨变

Theo用自己的经历做了一组对比。在Twitch工作时期，他一天大约阅读1000行代码，编写200行，其中约100行足够好可以合并。在写代码昂贵、且合并的代码都很重要的年代，这个比例合情合理——每行进入生产环境的代码，至少应有两个人审查。

而如今情况变了。他坦言："如果对你来说还没变，那说明你现在的工作做得不够好。"

现在的比例变成了：阅读量大致相同（约1000行），但生成量激增至2000行以上，合并量也上升到约500行。乍看之下这很危险——大量生成的代码没被阅读。但关键在于，这些生成的代码大部分并不会被提交审查、不会被合并、不会用于生产，它们只是用来测试想法。

当前主流AI编程工具（如GitHub Copilot、Cursor、Claude等）基于大语言模型（LLM），通过海量代码语料训练来生成代码。这些模型本质上是概率预测系统，根据上下文预测最可能的下一段代码。这意味着它们擅长生成符合常见模式的代码，但在边界情况处理、业务逻辑精确性和安全性方面存在固有局限。正因如此，AI生成的代码需要验证——但它同时也能大量、快速地产出用于验证的代码，这正是Theo论点的技术基础。

AI让代码变便宜了：为什么要生成更多代码

这是Theo论证的核心：人们正确地认识到AI代码质量差、可能出错，却错误地认为代码依然昂贵。

他举了一个生动的例子：为了在Windows电脑上整理文件，他写了大约10000行JavaScript代码，而实际上只移动了约100个资源文件。"用10000行代码去整理100个文件，在过去简直是精神病。但当代码可以随手免费生成时，这一切就变得完全合理了。"

这里的"代码成本"涉及经济学中的边际成本概念。传统开发中，每一行代码都需要工程师的时间和脑力，边际成本几乎恒定。而AI将代码生成的边际成本降到了接近零——一个prompt可能产出数百行代码，开发者付出的仅是描述需求的几秒钟。这种成本结构的根本性变化，意味着过去"不值得写"的一次性脚本、探索性代码、冗余验证代码，现在都变得经济可行。

针对那位在金融ERP系统工作、担心代码错误会造成巨额损失的开发者Nev，Theo的回应是："如果你的代码重要到每行都必须验证，那你更应该写大量的'垃圾代码'——不是放进产品里，而是用来验证你的产品。"

他给出了具体的AI编程实践建议：

• 每一行进入生产的代码，都应该有一百行、甚至一万行"垃圾代码"来验证它
• 构建自定义调试器
• 构建自定义运行时来验证系统
• 编写自定义lint规则

Lint工具是静态代码分析器，能在代码运行前发现潜在问题。ESLint（JavaScript）、Pylint（Python）、Clippy（Rust）等是常见实现。自定义lint规则允许团队将特定业务逻辑约束编码为自动化检查——例如禁止在特定模块中使用某些API、强制函数参数验证模式、确保敏感操作必须包含日志记录等。在AI大量生成代码的时代，自定义lint规则成为一道重要的自动化质量关卡，能在人工审查之前拦截大量常见问题，让人类审查者专注于更高层次的架构和逻辑判断。

"如果你还没有为你的软件构建自定义调试器，说明你糊代码糊得还不够。"

重新划定代码审查的边界

需要澄清的是，Theo并不是主张少读代码或把垃圾代码合并进项目。他明确表示："我不是说你要减少审查生产代码的量，我是说你应该比以前写更多的代码，多到其中很多根本不值得人类去看。"

他引用了另一位开发者Dax的做法：面对大规模diff变更，Dax不再逐行阅读，而是让agent总结每个文件做了什么，异常之处会立即凸显，一两个prompt之后就能调整到位。他关注文件和函数签名，但对函数体的具体实现关注较少。

文中多次提到的"agent"是指具备自主规划和执行能力的AI编程代理。与简单的代码补全不同，编程agent能够理解高层任务描述，自主决定执行步骤，编写代码、运行测试、修复错误，形成完整的开发循环。典型代表包括Devin、Claude Code、Cursor Agent等。这些agent可以并行工作，同时探索多种技术方案，大幅降低了"试错"的时间成本。当Theo提到"启动10个使用更笨模型的agent"时，他描述的正是这种并行验证策略。

Theo自己在开发T3和Lakebed项目时，会逐行阅读所有函数签名和API定义，因为API和SDK的稳固性直接影响项目的长期维护。函数签名（包括函数名、参数类型、返回类型）定义了代码的"契约"——即模块之间如何交互的接口规范。在软件架构中，接口稳定性远比内部实现重要，这是"面向接口编程"（Programming to an Interface）原则的体现。函数体的实现可以随时重构或替换，但接口一旦发布，修改成本极高，因为所有依赖方都需要同步调整。这解释了为什么Theo选择重点审查签名而非实现细节——这是投入产出比最高的审查策略。

而他验证这些接口的方式，正是"写一堆垃圾代码来测试"——比如把新定义的API放进一个包里，然后启动10个使用更笨模型的agent在其上构建东西。如果这些笨agent都能用好这些API，他就放心发布；如果不能，那正好发现了问题。

代码重要性漏斗模型：分层管理你的代码

Theo提出了一个"重要性漏斗"模型：顶部是海量的垃圾代码（A层），底部是极少量关乎生死的代码（D层），中间的B、C层才是大多数人真正工作的地方。

他强调：没有人的时间只花在漏斗的某一层上。 过去D层代码太昂贵，以至于在其他层花时间显得没有价值——因为手写坏代码和好代码一样费力。但现在，我们都应该在各个层级写更多代码。

这个漏斗模型可以类比为军事领域的"纵深防御"策略——不是把所有防线都设在最前方，而是在多个层级部署防御力量。A层的大量探索性代码就像外围侦察，帮助你理解地形；B、C层是主要作战区域；D层则是最后的核心阵地。AI的出现相当于让外围侦察的成本接近于零，使得工程师可以在真正交付之前，对解决方案空间进行更充分的探索。

对于那些编写起搏器固件的工程师，Theo的建议是：不要写更少的D层代码，而是在关键代码和其他代码之间划清界限。当遇到不确定的PR时，可以让agent尝试三种不同的方案并测试；可以让agent编写全新的测试；甚至可以让agent把整个系统"糊"成Rust版本，跑一遍测试套件来回答"用Rust会不会更快"这样的疑问。

用AI审查代码：让机器先把关

Theo还顺带提到一个观点：你应该让AI来阅读你的代码。"我一般不会拿代码去烦我的团队，除非多个agent已经深度验证过它。用AI来审查代码，效果其实非常好。"

这不是替代人工代码审查，而是在人工审查之前增加一道AI过滤层，让团队成员的注意力集中在真正需要人类判断的地方。这种做法类似于传统软件开发流水线中CI/CD（持续集成/持续部署）的理念——在代码到达人工审查环节之前，先经过自动化测试、静态分析、安全扫描等多道关卡。AI审查可以视为这条流水线上的新一环，它能发现逻辑不一致、潜在的性能问题、遗漏的错误处理等，而人类审查者则专注于架构合理性、业务逻辑正确性和长期可维护性等AI目前难以独立判断的维度。

结语：做一个更有创造力的工程师

Theo的核心诉求可以概括为一句话："我不是让你把代码写得更便宜，而是让你生成更多便宜的代码，这是巨大的区别。"

他承认AI编程运动中确实存在大量令人厌恶的现象——那些在社交媒体上最吵闹、为无人使用的服务疯狂产出代码的人，正是这场运动最糟糕的代表。但这并不意味着AI生成代码没有价值。

"如果你的代码很重要，那你应该写一些不重要的代码来验证那些重要的代码。当你开始把代码当作可抛弃的、一次性的——为一个想法、一个理论、一个问题、一件事服务——你会惊讶于自己能创造出什么。"

无限生成代码的能力是一次千载难逢的机遇。如果你还在逐行阅读所有代码，那说明你生成得还不够多。做一个更有创造力的工程师，才能真正驾驭这个时代。