代码为什么站在第一排

如果你最近常有一种感觉：AI 在代码上进步得特别快，快到有点不讲道理，那 Karpathy 这篇几乎就是解释这件事的钥匙。

很多人直觉上会说，因为程序员多、市场大、大家愿意付费。这些当然都对，但还不够深。更底层的原因是，代码太适合被验证了。测试过没过、程序能不能跑、结果和预期是否一致，这些都给了模型一种其他领域很少有的训练环境。

说得更白一点，越容易自动判断对错的任务，越容易被机器反复练习。

一个很日常的例子

让 AI 帮你写一个接口测试，它很可能表现不错。因为结果很快就能知道对不对。测试过了还是没过、响应结构对不对、字段有没有少，这些都能立刻回馈。

但如果你让它“写一个更有洞察力的行业分析”，事情就完全不同了。什么叫更有洞察力，通常没有一个直接、低成本、自动化的打分器。

这就是 Karpathy 那个词真正厉害的地方。它一下子把“为什么代码先爆发”从市场判断，推回了任务结构判断。

这对开发者不是理论题

对开发者来说，这篇最实用的价值是它能帮你重新排序工作。

以后你想把任务交给 AI 时，可以先不问“它会不会做”，先问“我能不能很快知道它做得对不对”。

如果答案是能，那通常就值得更早交给 agent。比如补测试、清理结构化数据、跑回归、修小范围 bug、做明确规则下的改写。这些都是更容易长出稳定工作流的地方。

如果答案是不能，那就要小心。这类任务当然也能用 AI，但你不该一上来就期待它稳定替你负责。

这也是为什么“让 AI 先帮我补测试”和“让 AI 先替我想战略判断”听起来都像在用模型，实际却完全不是一类风险。

产品和测试会从这里得到什么

这篇还有一个容易被忽略的价值：它其实也在给产品和测试上课。

产品写需求时，如果能把结果写成可验证条件，AI 的可用性就会上升。测试越能把“感觉不对”翻成通过条件、失败条件和复现路径，越容易真正把 AI 纳入流程，而不只是让它当一个会说话的助手。

也就是说，可验证性不只是模型的红利，也是团队写作和协作方式的红利。

举个很现实的产品例子。如果你把需求写成“让报销体验更顺”，AI 基本无从落手；但如果你写成“上传发票后 3 秒内完成字段提取，金额错误时要高亮并允许人工修改，缺失税号时不能提交”，它突然就有了可以对齐和自测的标准。测试拿到这种需求，也更容易把 case、mock 数据和验收脚本一口气连起来。

对 Agent Engineer 最重要的一句翻译

如果把这篇对 Agent Engineer 的启发压成一句话，那就是：别只设计 prompt，要先设计反馈。

真正有成长性的 agent 系统，背后都站着一套能持续给它反馈的机制。只要反馈够清楚，系统就更容易优化、更容易评估，也更容易扩展到更大的工作流里。代码 agent 会不会自己跑测试、数据 agent 会不会自动比对样本、客服 agent 会不会回看历史工单，本质上都在做同一件事。

很多时候，难点不在模型，而在你有没有把任务改写成一个机器也能看懂成败的过程。

今天就能做的判断

拿你最近最想交给 AI 的一个任务，先别着急写 prompt。先写一张小纸条：什么叫完成，什么叫失败，什么情况必须人工复查。只要这三句开始清楚，你就已经比很多“只会问模型”的工作流更往前走了一步。

更新附注

  • 版本：v1.1
  • 更新日期：2026-03-20
  • 更新原因：为系列文章补充统一阅读序号，方便读者顺着概念与方法继续往下读。