软件的瓶颈从来不是智能，而是上下文。

有一个故事被反复传播：乐天给了一个 AI 编程智能体一个任务，让它在一个大型开源项目里完成，人走开了，几个小时后回来就拿到了能跑的代码。这是个好故事，而且大体属实。可大家反复念叨的那部分，也就是那几个小时和准确率数字，恰恰是最没意思的部分。真正有意思的是，它为什么能成，以及这对今天的工程工作意味着什么。

这是工程视角，不是销售话术。我们每周都在真实的客户项目里指挥编程智能体，所以这与其说是一个热门观点，不如说是对工作究竟如何改变的一份描述。

乐天到底发生了什么？

这里把事实说清楚，因为病毒式传播的版本夸大了其中一个数字。在 2025 年 5 月 Claude Opus 4 发布时，Anthropic 表示乐天用一次高难度的开源重构验证了该模型，这次重构独立运行了约七个小时。细节稍后才出现在乐天自己的客户案例里：一位工程师让 Claude Code 对准了开源推理引擎 vLLM，要它实现一个特定的激活向量提取方法。据称，结果相对参考实现达到了 99.9% 的数值准确率。

两点诚实的更正，因为我们宁可说得准确，也不愿说得夸张：

• 它并非无人值守。那位工程师描述说，在这几个小时里他偶尔给予了指导。“独立运行了七个小时”是真实而令人印象深刻的。“完全自主、零人工参与”并不是实际情况。
• 99.9% 是一个很窄的指标。它指的是某个方法的输出相对参考实现的数值准确率，并不是说该智能体在所有事情上都有 99.9% 的正确率。这个数字有用、具体，也很容易被当成标题来误读。

而互联网最爱的那个数字，也就是 vLLM 有“1250 万行代码”，恰恰是最该怀疑的。它出现在乐天自己的文案里，所以人们出于善意去引用，但它大约偏离了二十倍。vLLM 的核心大约是 84,000 行 Python，所有语言加起来不到 60 万行。只有把没人会去推敲的东西算进来，才能凑到 1250 万：整个 git 历史、每一个相关仓库、内置和生成的内核。更正之后，真正的要点依然成立：Claude 在一个它从未见过的大型多语言代码库里游走，涉及 Python、CUDA 和 C++，并把一处改动落在了正确的位置。这才是令人印象深刻的地方。重点从来不是代码行数。

为什么真正的瓶颈是上下文，而不是智能？

把这次演示剥到本质，结论几乎平淡无奇。一位早已熟悉 vLLM 的资深工程师也能写出那个方法。一位新员工最终也能，只是要花上几周、走不少弯路。资深与新人之间的差别从来不是原始智能，而是各自能同时在脑中持有并推理多大一部分代码库。

这就是大多数软件工作的瓶颈。问题不是“一个聪明人能否搞清楚”，而是“到底有没有人能在工作记忆里持有足够多的系统，在正确的位置做出正确的改动，而不至于弄坏另外三处”。在一个大型代码库里，这确实很难，而且这种难与你有多聪明毫无关系。

“AI 不会有上下文疲劳”到底是什么意思？

人类不擅长长时间持有大量上下文，并不是因为我们笨。我们会累。我们会忘记四十个文件之前读过的东西。一休息就丢了思路。在漫长一段工作的后半程，会犯下第一个小时绝不会犯的小错误。在脑中持有一个庞大系统的心智模型很耗神，而疲惫正是 bug 的来源。

编程智能体不会以这种方式疲惫。它能把一个大型代码库的相关切片始终摆在眼前，在第七个小时和第十分钟一样稳定地推理。这才是乐天故事里真正的解锁点。不是模型比资深工程师更聪明，而是它在一项漫长、上下文沉重的任务中不会像人那样状态下滑。是持续的上下文，而非更高的智能。

但有个真实的陷阱：智能体只能在它实际拿到的上下文上做出良好推理。把它对准错误的文件，或不给它关键约束，它就会毫不疲惫、却又自信满满地把错的东西造出来。喂给它正确的上下文，如今才是真正的技能。关于这项纪律的成本面，我们在如何在 2026 年降低 LLM Token 成本里写过：管理上下文，而不仅仅是花掉 token，才是这盘棋的大头。

这会让工程师消失吗？

不会，而预言这件事的人通常是在卖东西。它真正做的是把工作挪了位置。如今在规模化的工程师，多半不是逐行手写代码的人。他们是擅长指挥智能体、带着批判眼光审查产出、并能识别出智能体即将做蠢事那一刻的人。

最后这项能力被低估了。智能体会产出自信、格式工整、看似合理却暗藏错误的代码，而一位初级审查者会因为它“看起来对”而放行。要抓住这一点，恰恰需要多年手写代码才培养出的判断力。经验并没有变得一文不值，它只是从“我敲出解法”变成了“我在错误的解法上线前就认出它”。如果你想看看这种审查具体长什么样，我们的vibe 代码生产就绪清单，就是我们用来对照智能体产出的那份清单。

当智能体写代码时，好的工程是什么样子？

委派成了新的深度工作。过去那些深度而有价值的时间，是埋头写下那个困难函数的时间。如今越来越多地，是把任务精确界定、组装正确上下文、并用锐利目光审查回传内容的时间。这是一块确实不同的肌肉，许多强工程师还没练出来，因为在他们整个职业生涯里，瓶颈一直是敲出解法，而不是把它说清楚。

这种模式下的好工程是这样的：一个收窄、定义清晰的任务；预先交给智能体的正确上下文；能自动抓住错误答案的测试与护栏；以及一个像资深者那样审查、而非橡皮图章式盖章的人。智能体快速且不知疲倦。工程师才是那个决定“正确”意味着什么、并验证它真的到达了那里的人。

"智能体把整个代码库放在脑中不会累，你会。这就是全部的转变。你的工作从写下每一行，变成了决定什么叫正确，并在智能体出错时把它抓住。"

你该如何围绕编程智能体重构工作流？

如果你想在自己的工作上复现乐天的结果，按顺序，真正重要的几步是：

1. 把任务收窄界定。“实现这个特定方法，对齐这份参考”胜过“改进推理层”。正是精确的任务，才让七个小时的无人值守成为可能。模糊的任务，只会换来七个小时自信的弯路。
2. 给它正确的上下文，而不是全部上下文。把智能体对准真正重要的文件、接口和约束。上下文不是越多越好，而是越对越好。如今大部分技能就藏在这里。
3. 用测试与护栏来把关。乐天之所以能信任产出，是因为有一份可供比对的参考。把它复制过来：一套测试、一份参考、一道在答案错误时会大声失败的护栏。
4. 像资深者一样审查，而不是盖橡皮图章。逐行读 diff，找出那些细微、看似合理的错误，那些能编译通过、也能糊弄一眼的错误。这是你投入的最高杠杆的一小时。
5. 把所有权和知识留在内部。一个交付出团队没人看得懂的代码的智能体，是一项依赖，不是一场胜利。要确保有一个人对交付的东西负责，并能讲清楚它。

这些都不稀奇。它就是好工程一直需要的那份纪律，只是重新分配了权重：用更少的时间产出代码，用多得多的时间去界定和验证它。