AI编程提速，没有看起来的那么美！

安德烈·卡帕西（Andrej Karpathy）是业内极少数无需过滤、值得直接倾听的人物之一。作为 OpenAI 的创始成员和特斯拉前人工智能总监，他站在 AI 及其可能性的巅峰。他在最近的一篇帖子中提出了一个既鼓舞人心又令人不安的观点：“如果我能恰当地整合过去一年左右涌现的工具，我的能力本可以提升十倍，”卡帕西写道，“而未能抓住这种提升，显然是一种技能问题。”

他的潜台词很明确：如果你今天的开发效率没有比 2023 年高出十倍，问题不在工具，而在你自己。这听起来似乎有道理……但又明显不对。毕竟，当前这一代大语言模型（LLM）工具所蕴含的杠杆潜力确实惊人。然而，他的整个论点都依赖于一个承担了巨大分量的副词：“恰当地”（properly）。

在企业环境中，代码往往要运行数十年而非数天，“恰当地”这三个字说起来容易，做起来却极其困难。越来越多的数据表明，对大多数开发者而言，“技能问题”并非不会写提示词（prompt），而是缺乏严格的验证能力。AI 带来的速度看似免费，但信任却代价高昂。

基于“感觉”的生产力陷阱

事实上，AI 的速度只是“看似”免费。今年早些时候，模型评估与威胁研究团队（METR）开展了一项随机对照试验：他们让经验丰富的开源开发者完成特定任务，其中一半使用 AI 工具，另一半则不用。使用 AI 的开发者坚信 LLM 让他们的开发速度提升了 20%。但现实却很残酷：使用 AI 的那组平均反而慢了 19%。

感知与现实之间竟有将近 40 个百分点的差距——这可真够疼的。

为什么会这样？因为我们越来越依赖“基于感觉的评估”（vibes-based evaluation，这一说法由 Simon Willison 首创）。生成的代码看起来没问题，而且瞬间就出现了。但当你进入“最后一公里”时，问题就暴露了：代码用了已弃用的库、凭空捏造了一个参数，或引入了微妙的竞态条件。

卡帕西这类言论很容易引发严重的“错失恐惧症”（FOMO）：“就连过去 30 天都没跟上的人，对这个话题的认知已经过时了。”也许如此。但尽管 AI 日新月异，有些东西却顽固地保持不变——比如质量控制。AI 编程助手本质上不是生产力工具，而是你必须用验证成本来买单的“责任制造机”。你可以提前支付这笔“信任税”（通过严格的代码审查、测试和威胁建模），也可以推迟支付（以事故、数据泄露和重构为代价）。但迟早，你都得付。

目前，太多团队以为自己能逃过这笔税，其实根本逃不掉。Veracode 发布的《生成式 AI 代码安全报告》指出，45% 的 AI 生成代码样本引入了 OWASP Top 10 列出的安全问题。仔细想想这意味着什么：

几乎每两次你未经严格审计就接受 AI 建议，就有一次可能将严重漏洞（如 SQL 注入、跨站脚本 XSS、访问控制失效）注入你的代码库。报告一针见血地讽刺道：“恭喜你提速成功，祝你享受数据泄露。”正如微软开发者倡导者 Marlene Mhangami 所言：“瓶颈仍然是交付那些你能维护、且有信心的代码。”

换句话说，我们正在以人工安全审查完全无法跟上的速度，积累着充满漏洞的代码。这印证了 SonarSource 一直在警示的“生产力悖论”：除非大力投资于质量门禁，否则更快的代码生成必然导致更快地积累 bug、复杂性和技术债。正如 SonarSource 报告所指出的，我们正在构建“只写型”（write-only）代码库——这些系统由非确定性代理生成，体量庞大、结构复杂，以至于没有任何人类能完全理解它们。

我们正越来越多地用长期可维护性，换取短期产出。这就像软件界的“糖分高潮”。

重新定义“技能”

那么，卡帕西错了吗？没有。当他声称自己能强大十倍时，他是对的——或许未必正好十倍，但精通 AI 的开发者确实能获得真实（或潜在）的性能提升。然而，他拥有的技能并不仅仅是“串联工具”的能力。

卡帕西内心深处对“好软件”有着深刻的理解，这使他能有效过滤噪声。他知道 AI 在什么时候很可能正确，什么时候又可能在胡说八道。但他是个极端例外，这也让我们再次回到那个棘手的词：“恰当地”。

因此，2026 年真正的技能问题不是提示工程（prompt engineering），而是验证工程（verification engineering）。如果你想获得卡帕西所说的那种提升，就必须把重心从“写代码”转向“批判代码”：

• 验证即新编程：你的价值不再由写出多少行代码定义，而取决于你验证机器输出的有效程度。
• “黄金路径”必不可少：如我此前所述，不能放任 AI 自由发挥。你需要“黄金路径”——标准化、安全加固的模板。不要让 LLM 从头写数据库连接器，而是让它实现你安全平台库中已定义好的接口。
• 亲自设计安全架构：你不能简单告诉 LLM “把它弄安全”。你在威胁建模中嵌入的高层级思考，恰恰是 AI 目前仍无法可靠完成的部分。

所谓“恰当地串联可用工具”，绝不只是把 IDE 连上聊天机器人那么简单。它意味着要系统性地（而非盲目乐观地）思考 AI。这意味着要用一套完整的工具链来约束 LLM：包括代码规范检查（linting）、静态应用安全测试（SAST）、动态应用安全测试（DAST）以及自动化回归测试。

明年真正能强大十倍的开发者，绝不是那些盲目信任 AI 的人，而是那些把 AI 当作“聪明但极其初级的实习生”的人——他们知道 AI 能迸发天才火花，但也需要持续监督，以防它一不小心删了生产数据库。

技能问题确实存在，但关键技能不是速度，而是控制力。