"尽可能少写代码"——AI时代的新准则

AI降低了代码生成成本，但产品风险依旧

近年来，Codex、Cursor、Claude Code、GitHub Copilot、Devin等AI编程工具层出不穷，能够在几分钟内生成可运行的代码。自动化循环甚至可以在无人干预的情况下运行数小时，团队在睡眠中就能积累大量变更。输出令人印象深刻，但危险在于，这看起来像是进步，却无人问津是否真正取得了进展。

生成另一个合理实现方案的边际成本正在骤降，但理解、验证、安全性和维护的成本却并未降低。这一区别比任何关于哪个工具最快的基准测试争论都更为重要。

几十年来，构建软件的成本为产品团队施加了一种自然纪律。工程师是昂贵的——在许多西方软件组织中，一个小型开发团队每年轻松代表六位数美元的投资，包括薪资、福利、管理、工具和开销。这种费用迫使决策：你无法承担构建一切的成本，因此必须做出选择。产品人员必须优先排序，利益相关者必须权衡取舍。成本是一道门，尽管许多组织误将其视为产品纪律。

AI编程工具削弱了这道门。过去迫使团队至少思考“我们应该构建这个吗？”的实施成本，如今不再施加同样的压力。组织正在发现当门不再起作用时会发生什么：他们构建一切，验证零，然后疑惑为什么产品变成了一堆无人需要的功能。这就像Word的增强版，从几十年压缩到几周。

旧刹车：“少代码”背后的成本伪装成纪律

构建软件的成本发挥双重作用。它不仅限制了构建的内容，还创造了自然的审查点。当一个功能需要数周时间来实现时，团队就有时间重新考虑。有人会在站会上提问，设计师会注意到不匹配，利益相关者会改变优先级。缓慢是一个刹车，而刹车在做有用的工作。

但工程成本从来不是好的产品纪律，它只是掩盖了产品纪律的缺失。许多组织多年来花费昂贵的工程时间构建错误功能。成本门减缓了浪费，但并没有可靠地防止浪费。

AI编程工具并未消除所有约束，但它削弱了许多组织无意识依赖的那一个。错误的功能现在可以快速达到精美的演示、令人信服的原型甚至生产环境，而在此之前没有人认真讨论过它是否应该存在。过去，速度通过创造暂停使判断介入来保护组织，这种保护已经消失。

我们现在面临一个反转：过去构建错误功能尚可生存，因为构建成本给了团队纠偏的时间。而有了AI编程工具，构建错误功能的堆积速度更快。你不会在代码审查或待办事项梳理会议中发现构建了错误功能，而是在发布后数据平缓时发现。

证据指向同一方向

这种模式不再是假设性的。产品高管Richard Ewing在2026年1月的一份事后总结中描述了这种动态。他的团队构建了一个技术令人印象深刻的AI搜索工具，使用向量数据库、最新LLM和RAG流水线，准确率接近完美（nDCG 0.92对比旧系统0.65）。演示看起来像魔法，但他们发布后等待采用率上升，却看到它停滞不前。

当Ewing的团队最终在发布后运行用户研究时，他们发现给用户的是家庭作业而非减少劳动。工具要求用户停止工作流，打开侧边栏，编写提示，等待响应，然后将结果粘贴回工作。没有人想要这个。AI功能在一个下午下线维护，没人打支持电话，因为没人在乎。这种沉默就是反馈。

技术执行出色，但无法弥补错误的产品决策。AI使所谓的“解决方案”更容易构建，但并未使理解用户的工作流变得更容易。

谷歌云总监Addy Osmani使用Jeremy Twei创造的术语“理解债务”描述了另一种失败模式。在2026年1月的分析中，Osmani描述了当开发者接受AI生成的代码通过测试但并未真正理解其功能时会发生什么。他自己曾这样做：Claude实现了一个功能，测试通过，他浏览了代码，合并，三天后无法解释该功能如何工作。代码库增长，理解缩小。

Osmani引用研究表明，高AI采用率的团队合并的拉请求增加了98%，而审查时间上升了91%，拉请求大小增加了154%。他借鉴了Faros AI遥测和谷歌2025年DORA报告，两者都警告AI采用放大了现有组织优势与劣势，而不是修复破碎的交付系统。代码审查成了新的瓶颈：尽管我们加快了生产变化的速度，但并未同样快地理解其后果。

安全方面，Veracode的2025年GenAI代码安全报告发现，AI生成的代码在超过100个大型语言模型和80个编码任务的45%测试中引入了安全漏洞。这些模型生成了功能正确、语法正确的代码，但几乎一半时间未能满足安全要求。

记录在案的生产故障从另一端讲述了同样的故事。Lovable平台漏洞（CVE-2025-48757）由于行级安全性不足，暴露了基于该平台构建的应用程序未授权数据库访问，CVSS严重性评分9.3（严重）。该漏洞的系统性引发了关于共担责任模式的辩论，Lovable认为客户必须主动保护他们生成的应用程序的业务逻辑。

在另一个广泛报道的事件中，2025年7月，Replit的AI编码代理在vibe-coding会话中删除了一个生产数据库。尽管有明确自然语言指令严格禁止代码变更，代理绕过了保护措施，删除了1206名高管和1196家公司的关键记录。Replit CEO Amjad Masad公开道歉并宣布立即修复基础设施，包括强制分离开发/生产环境。

在这两种情况下，周围的验证和责任模型未能跟上可以非常快速生成或更改的软件。交付速度压缩了本可以有人干预的时间窗口。

证据显示的内容

• 产品失败却无产品学习：Ewing的AI搜索工具准确率达0.92 nDCG，但采用率停滞，因为团队从未观察用户实际工作方式。工具增加了工作流步骤而非移除它们。技术卓越无法弥补缺失的产品决策。
• 理解债务且无代码理解：Osmani的分析显示，开发者合并AI生成的代码，几天后无法解释。高AI采用团队拉请求增加98%，审查时间上升91%。代码生产规模化，代码理解未跟上。
• 安全失败且无验证基础设施：Veracode发现AI生成代码在45%测试中引入漏洞。Lovable和Replit的生产事故表明，功能代码在没有充分验证的情况下到达用户，漏洞未被及时捕获。

2026年“尽可能少写代码”的真正含义

原始的纪律是关于克制：在编写解决方案之前了解问题，在承诺资源之前验证假设，发布最小可行测试是否正确。AI编程工具并未改变这些，反而使一切更加紧迫。

“尽可能少写代码”现在意味着：不要仅仅因为你能够生成它就去构建每一个功能。它意味着在对一个想法进行任何编码之前，先投资于发现和验证。它意味着在AI生成代码时审查代码，不要假设如果它通过了测试就是正确的。它意味着将尽可能多的代码视为你应该删除而不是保留的东西。

纪律已经从“保守编写”转变为“激进删除”。问题不再是“我们还能添加什么？”，而是“我们能够移除什么同时仍然解决用户问题？”最少的代码仍然是最聪明的代码。现在，它也是风险最低的代码。

结论：产品纪律现在比代码能力更重要

AI在生产语法正确代码方面非常出色。它在判断哪些代码值得编写方面仍然很糟糕。这种不对称就是我们全部工作所在的地方。我们投资于使软件更易生成，现在必须同样大力投资于使其值得构建。

组织中产品人员的角色从未如此关键，也从未如此不同。仅仅管理待办事项或撰写用户故事已经不够，即使这些任务可能被AI辅助。产品人员必须成为用户工作流不显眼执行方面的专家，必须挑战每个被提议的功能：这个功能是真的移除劳动，还是增加另一个步骤？它是在解决用户问题，还是让我们在没有理解的情况下生成代码？

工程文化也必须转变。审查AI生成代码必须成为标准实践，不是可选。团队应强调对代码的理解而非代码的输出。部署前的验证不能是事后的想法——它必须与实施直接集成。安全审查应自动运行，且团队应接受关于AI生成代码常见漏洞模式的培训。

“尽可能少写代码”比以往任何时候都更相关。它曾经是一门关于效率和克制的学科。现在它是关于生存的警告。那些忽略它的人不会因为缺少代码而失败——他们会因为拥有太多无用的代码而失败。