系列：“我们构建了一条数万行代码的流水线。智能体为何做不到。”

上一篇：第5A篇——研究到底说了什么：数据篇。

Read the English version.

数据展示了可靠性断崖和“增强优于自动化”。现在来看看解释这些数据的框架，以及它们对工程意味着什么。

上篇讲了 METR 的可靠性断崖：Demo 与生产之间的差距接近一个数量级。Anthropic 的劳动力研究则显示，现实中的主导模式仍然是增强，而不是自动化，而且尚未观察到系统性失业。

数据已经呈上。现在来理解它意味着什么。

30 秒速览

1. AI 最适合处理你能快速检查结果的任务，比如分类；架构决策反馈太慢，不适合直接交给 AI。
2. Demo 能跑通不等于产品能用。早期自动驾驶演示十多年前就令人印象深刻，但跨越长尾和可靠性门槛至今仍在进行中。
3. AI 的能力是锯齿状的：这道题答得比专家还好，下一道题却犯小学生都不会犯的错，而且你很难提前预测是哪一道。
4. 最强模型在长期代码维护中持续保持零回归的能力也只在一半量级：修好一个功能，可能搞崩另一个。
5. 基准测试衡量的是“能不能写代码”，但工程真正难的是知道该写什么、不该写什么。

确定性逻辑还是 AI 判断？三种软件范式

Andrej Karpathy 在过去几年里持续发展一套理解 AI 在软件中角色的框架。

Software 1.0 是显式代码：你写下规则，计算机像照菜谱一样一步步执行。

Software 2.0 是学习到的权重：你整理数据、定义目标，优化器自己摸索出规则。

Software 3.0 是 Karpathy 在 2025 年 YC AI Startup School 演讲中使用的说法：用自然语言给 LLM 下指令——提示词、系统指令、工具定义——本身成为一种编程方式。

这个框架并不要求 3.0 替代 1.0 和 2.0。三种范式会并存，工程师要判断每一部分该用哪一种。换成工程语言，最终落到一个判断：哪些部分需要确定性保证，哪些更适合交给 AI 的语义判断力。

我们的流水线就是这种组合：

Software 1.0（代码）：批处理、重试、升级、追踪       → 确保行为
Software 2.0（权重）：LLM 的预训练语义理解能力       → 藏在引擎盖下
Software 3.0（提示）：“这个 URL 与 ESG 相关吗？”    → 用自然语言指挥模型

严格来说，我们没有自己训练模型。我们使用别人训练好的 2.0 模型，通过 3.0 的提示词来指挥它。所以流水线在应用层面本质上是一个 1.0 + 3.0 系统。

LLM 不可替代。再多正则表达式也比不上它判断一个可持续发展报告链接是真的披露还是洗绿页面。但绝大部分系统价值来自 1.0 的控制、恢复、去重、预算与可追踪性。

怎么决定交给 AI 还是留给代码？可验证性

有了三种范式，下一个问题是：具体到每个任务，怎么判断该用哪一种？

Karpathy 在“Verifiability”一文中提出了一个极实用的判断标准：验证输出有多容易。

Software 1.0 自动化的是可规定的：你能写下精确规则。

Software 2.0 和 3.0 更擅长自动化可验证的：你也许写不出完整规则，但能迅速检查结果，例如“这张图是猫吗？”或者“这个翻译听起来对吗？”

剩下的空白，是输出既不容易规定，也不容易验证的任务。而很多真正困难的工程工作，就生活在那里。

用这个标准看我们的系统：

这个 URL 分类正确吗？可验证。人花几秒钟就能检查，所以 LLM 用在分类上行得通。

这条流水线的架构正确吗？不容易验证。你得跑完 5000 家公司，比较几周内的成本、完整性和失败率之后才知道。所以架构决策不能因为 LLM 给了一个听起来合理的答案就算完成。

浏览器级联策略是最优的吗？反馈循环可能要几周。LLM 等不了几周——它的耐心大概和超市收银台排队的三岁小孩差不多。

一句话带走： 能快速验证结果的任务交给 AI；反馈慢、错误会长期传播的任务留在确定性系统和人类判断中。

决定用 AI 之后怎么做？上下文工程

确定了哪些任务交给 LLM 之后，下一个问题是：怎么把任务交好？

Software 3.0 听起来像“写个提示词”就行，但公开讨论很快转向了更广义的上下文工程。2025 年，Tobi Lütke 帮助推广了这个说法，Karpathy 随后把它描述为：为模型的下一步，把恰到好处的信息装入有限上下文窗口的工程艺术与科学。

换句话说，3.0 是范式；上下文工程是范式落地时的一门核心手艺。

在我们的流水线里，上下文工程是具体的工程活。我们有三种不同的 LLM 调用，每种服务于不同目的，因此喂进去的东西也完全不同：

• 评估路径时，LLM 看到 URL 路径，以及从页面上下文聚合来的信号。
• 评估跨路径链接时，LLM 看到链接本身，以及它来自哪个高置信度 ESG 父页面。
• 评估深层子页面时，LLM 拿到一整批 URL，以及面向批量模式识别的指令。

三次调用，三套上下文，三种工程约束，因为它们回答的是三个不同的问题。

这不是提示词技巧。这是系统设计。

一句话带走： 提示词只是入口。真正的 3.0 技能是上下文工程——为每次 LLM 调用精确组装它需要的信号，不多也不少。

即便如此，AI 的边界在哪？Demo 鸿沟与锯齿状智能

框架有了，判断标准有了，实践方法也有了。但 AI 的现实表现还有两个坑。

从 Demo 到产品的鸿沟

智能体热潮的鼓吹者们经常默认 3.0 能一路走到底。自动驾驶是最好的前车之鉴：早期演示十多年前就令人印象深刻，但产品化要跨过长尾与可靠性门槛，至今仍在进行中。

为 Instagram 拍一道完美的菜是 Demo。连续一年每晚经营一家餐厅厨房才是产品。

Karpathy 在谈 Autopilot、部分自主和人机协作时，核心提醒一直很一致：能做出 Demo，不等于已经跨过产品化的长尾与可靠性门槛。他对智能体时间线也很谨慎，称之为“智能体的十年”，而不是“智能体之年”。

锯齿状智能

即使在 AI 擅长的领域，它的表现也不是均匀可靠的。能力边界是锯齿状的：某些任务远超普通人，邻近任务却突然失败。

Harvard Business School 与 BCG 的研究在 758 名顾问身上量化了同样的现象。对位于 AI 能力前沿内的任务，使用 AI 的参与者平均多完成 12.2% 的任务，速度提高 25.1%，质量也更高。但在一项被设计为前沿外的复杂业务任务上，使用 AI 的参与者正确率反而低了 19 个百分点。

实际表现可能是：它写出完美的数据处理逻辑，却把一个司法辖区的法规当成另一个司法辖区的来引用，语气自信到你不熟悉就不会起疑。

它也可能给出一个架构建议，在 10 家公司的测试里完美运行，到 5000 家时悄悄崩溃，因为某些反爬机制只会在请求积累到一定程度后触发。

智能分布是锯齿状的：尖刺状、不可预测。

这就是为什么不能简单地“给它更多自主权”。我们的流水线把 LLM 限制在一个狭窄区域：它的语义判断力在这里稳定地超越规则。其他部分则放进确定性代码，让锯齿状波动伤不到系统。

一句话带走： Demo 到产品的距离以年计。AI 的能力边界不是平滑的，而是锯齿状、不可预测的。

长期维护有多难？SWE-CI 基准测试

这些框架解释了 AI 在哪些地方会碰壁。但还有两个问题没有回答：系统的长期演化有多难，以及工程判断为什么难以自动化。

SWE-CI 证明的不是“模型不会写代码”，而是“长期演化稳定性远比单次补丁难”。

2026 年 3 月发布的 SWE-CI 基准测试试图衡量多数编码基准忽略的事情：长期代码维护。

简单说，它测的不是模型能不能一次把代码写出来，而是能不能在长期迭代里把系统“越改越好”，而不是“越改越坏”。智能体能不能像开发者一样做持续集成，在一个活的代码库上反复迭代而不把已有功能搞崩？

• 100 个长期演化任务。
• 平均约 233 天的历史演化跨度。
• 每个任务最多 20 轮迭代。
• 评估总计消耗约 100 亿 token。

结果是：在官方实验中，12 个前沿模型里有 10 个的零回归率低于 0.25；只有 Claude Opus 4.5 和 Claude Opus 4.6 超过 0.50。

即使是表现最强的模型，在这种强调长期演化稳定性的评估里，持续保持零回归的能力也只在一半量级，离可无监督托付还很远。

它说明了什么？长期维护和持续集成式演化，比一次性写出一个函数困难得多。方向上很有说服力：智能体不仅在单个任务上吃力，在系统随时间演化时也会出现回归。而生产代码必须演化，每周都要。

它没有说明什么？这个基准以真实仓库的历史任务、参考提交和测试为锚点，优先衡量沿既有演化轨迹维持正确性的能力。一个找到不同但同样有效架构的智能体，可能仍然无法满足参考测试。它不等于模型永远不可能维护代码，也不等于所有偏离参考路径的重构都更差。

我们的流水线经历了几十轮演化：PDF 处理重新设计了三次，分数继承是几个月后才加上的，查询参数规范化来自一个具体生产故障。每次改动都需要理解完整系统状态，而且演化顺序不是预先设计的，而是从生产反馈中涌现出来。

SWE-CI 试图衡量的正是这种演化稳定性，而即便最强模型也远未达到可完全托付的程度。

一句话带走： 写一次代码和维护一个活系统是两件事。最强模型持续零回归的能力也只在一半量级——“能写”不等于“能养”。

知道该写什么比会写更难：工程判断不等于编码能力

工程判断之所以难自动化，不是因为代码难写，而是因为反馈太慢、上下文太厚、错误会跨时间传播。

这是多数基准测试忽略的关键点。编码基准衡量能不能写一个函数，SWE-bench 衡量能不能修一个 bug，METR 衡量能不能完成一个任务。它们都不直接衡量你是否知道该写哪个函数、哪些 bug 最重要、该优先做哪个任务。

这就像测一个人会不会挥锤子，然后得出结论说他能盖房子。或者看到机器人把一段编排好的舞跳得很流畅，就认为它明天能进厨房洗碗、去工厂处理所有意外情况。舞是编排好的，厨房和工厂不是。

我们的流水线之所以难以构建，不是因为每个函数都很复杂。任何资深 Python 开发者都能写出其中大多数单独函数。难的是知道：

• 浏览器处理需要多个不同路径，而不是一个通用方案，因为生产网站的反自动化策略远比预想的多。
• 通过域名树进行分数继承会消除约 60% 的 LLM 调用，因为 ESG 内容会沿高置信度路径聚集。
• PDF 处理需要推迟而不是与页面发现混在一起，因为边爬边下载会占满连接，并干扰发现循环。
• 查询参数规范化可以把数百个看似不同的 URL 压缩成真正独立的页面，因为某些企业网站会给每个链接附加临时会话参数。

还有那些只为最后 5% 边缘情况存在的“无聊”代码：年龄门检测器、Cookie 墙处理器、PDF 文件名评分器、查询参数规范化器。

前 80% 的情况很容易；接下来的 15% 很难；最后那 5% 才决定生产系统能不能被信任。

Stack Overflow 2025 开发者调查印证了同一趋势：84% 的受访者正在使用或计划使用 AI 工具，但 46% 不信任其输出准确性，高于信任者的 33%。工具在普及，但信任缺口仍然存在。

这些都是工程判断。对于这类高度场景化、反馈周期漫长的权衡，通用模型并没有在与你的目标函数完全对齐的数据上被训练或评估。它可能见过相关模式的碎片，但从未针对“在机构级规模收集 5000 家公司 ESG 披露”这一整套具体权衡被优化。

这正是 METR 数字揭示的鸿沟：模型可以用约一半的成功率完成一个 12 小时量级的基准任务。但工程判断不是完成一个任务，而是在几个月里做出数百个互相叠加的架构决策。一个错误判断可能沿整个系统传播。

你需要对不在任何训练集中的决策保持近乎完美的判断准确率。

一句话带走： 基准测试衡量“能不能挥锤子”，但盖房子靠的是知道哪面墙该先砌。工程判断的反馈周期以月计，这是当前 AI 最大的盲区之一。

研究的汇聚点

八条证据线，方向收敛，指向同一个结论。

来源	关键发现	流水线启示
METR	50% 到 80% 的可靠性差距接近一个数量级	把 LLM 限制在局部失败可以被发现和吸收的步骤
Anthropic	专业 AI 使用的主导模式是增强，而非自动化	围绕 LLM 构建系统，而不是让 LLM 充当整个系统
Karpathy 1.0/2.0/3.0	不是替代，而是组合：确定性代码、学习权重、自然语言指令	那 90% 的确定性代码不是累赘，它就是产品
Karpathy 可验证性	能快速验证输出的任务最适合 AI	分类交给 LLM，架构决策留给长期反馈和人类判断
Demo 鸿沟	从 Demo 到可靠产品需要跨越长尾	智能体是组件，不是完整系统
Harvard/BCG	前沿内显著增益，前沿外正确率下降 19 个百分点	把 LLM 限制在它的能力尖刺对你有利的地方
SWE-CI	最强模型的零回归率约在一半量级	生产系统的长期演化仍需要人类判断
生产系统经验	工程判断的反馈循环以月计	最后那 5% 才决定系统是否真正可用

这些研究都没有说智能体没用。它们共同暗示的是：智能体是组件，还不是系统。

而且它们是强大的组件。流水线中的 LLM 分类真正不可替代，再多工程也比不上它的语义判断力。

但一个没有系统包裹的组件是 Demo。一个缺少正确组件的系统是不完整的。研究说的是两个都要建，而且要知道哪个是哪个。

把引擎装进车里不等于造了一辆车。但没有引擎的车也哪里都去不了。

到这里，框架和数据都指向同一个结论：AI 和工程必须共存。用确定性的结构约束 AI 的概率判断，让“随机”变得可靠。这正好是这个系列的主题，也是“Deterministic Random Walk”在工程上的实践含义。

但这个名字还有更深一层：生活里看似随机的转折，也许仍被某些更稳定的东西支配着——至少我愿意这么相信。

能把 AI 和工程结合起来的人，和只会其中一半的人，差距不是在缩小，而是在加速拉开。这也不只是技术问题。研究指向一个更大的问题：在工具快速变化的时代，什么该拥抱，什么该坚守？

这才是真正的杠杆差距。

下一篇：第6篇——杠杆差距：谁真正从 AI 中受益。

系列目录

篇目	核心观点
00 — 引言	这个系列为什么存在
01 — 不可能的任务	一切的起点
02 — 7400+ 行代码是怎么来的	流水线是怎样滚雪球的
03A — 大脑与身体	LLM = 10% 大脑，代码 = 90% 身体
03B — 六个看起来简单的问题	让智能体翻车的边缘情况
04 — 诚实的对比	流水线 vs. 智能体，用数字说话
05A — 研究到底说了什么：数据篇	METR 的可靠性断崖，Anthropic 的劳动力研究
05B — 研究到底说了什么：框架篇	你在这里
06 — 杠杆差距	谁从 AI 中受益，谁没有
07 — 上下文积累	智能体永远学不会的东西
08A — 委托问题	为什么你不能直接丢给它
08B — 自主性光谱	找到合适的级别
09 — 另一个极端	当怀疑变成瘫痪
10 — 两个房间	Demo 狂热者 vs. 领域怀疑论者
11 — 证据	流水线作为证据
番外 — 反方论点	AI 反驳整个系列
番外 — 站在中间地带	半夜醒来的那个念头

参考文献

1. Karpathy, A. “Software 2.0.” 2017。
2. Karpathy, A. “Verifiability.” 2025。
3. Karpathy, A. “Software Is Changing (Again).” YC AI Startup School，2025。
4. Zan, D. 等. “SWE-CI: A Benchmark for Long-Term Code Maintenance in Real-World Software Repositories.” 2026。
5. Dell’Acqua, F. 等. “Navigating the Jagged Technological Frontier.” Harvard Business School，2023。
6. Willison, S. “Context Engineering.” 2025。
7. Stack Overflow. “2025 Developer Survey.” 2025。