神译局是36氪旗下编译团队，关注科技、商业、职场、生活等领域，重点介绍国外的新技术、新观点、新风向。
编者按：当编程变成“保姆活”：Karpathy 称 80% 代码已由 AI 接管，但代价是你正在背负“理解债”。文章来自编译。
Andrej Karpathy 本周说了一些让我陷入沉思的话：
我很快从约 80% 的手动+自动补全代码加上 20% 的 智能体 协作，变成了 80% 的 智能体 编程加上 20% 的修改与润色。现在，我真的主要是在用英语编程了。
这种逆转发生在 2025 年末的短短几周内。虽然相对于现有或遗留应用，这对全新（绿地）项目或个人项目可能会更适用，但我认为 AI 能带你走出的距离依然比一年前远得多。这要归功于模型、规范（specs）、技能、MCP（模型上下文协议）以及我们工作流的不断改进。
Claude Code 的创造者 Boris Cherney 最近也表达了类似的观点：
我们几乎 100% 的代码都是由 Claude Code + Opus 4.5 编写的。对我个人而言，这种状态已经持续两个多月了，我甚至连微小的改动都不会亲自动手。我昨天提交了 22 个 PR，前天提交了 27 个，每一个都是 100% 由 Claude 编写。我认为行业内的大多数人在未来几个月内都会看到类似的统计数据——只是每个人的进度快慢不同而已。
前段时间我写过“70% 问题”——即 AI 编程能帮你完成 70%，剩下的 30% “最后一公里”留给人类。现在的局面可能正在演变。对于某些类型的项目，这个比例可能会上升到 80% 甚至更高，但问题本质的变化比数字本身要剧烈得多。
Armin Ronacher 对 5,000 名开发者进行的调查印证了这个故事：44% 的人现在手动编写的代码不到 10%。另有 26% 的人处在 10-50% 的区间。我们已经跨越了一个门槛。但这种“胜利者叙事”忽略了一点：问题并没有消失，只是转移了。有些问题甚至变得更糟了。
我想先做个说明：在新的业余项目中，我确实感受到了 80% 以上用智能体编程的趋势转变，但对于大型或现有应用，尤其是涉及到团队协作时，情况则大不相同。预期各异，但这让我们提前窥见了未来的走向。
AI错误的形式发生了变化。AI 的错误已经从语法 Bug 演变为概念性失败——就像是一个粗心、急躁的初级开发者在时间压力下可能会犯的那种错误。
Karpathy 归纳了目前仍然会出问题的地方：
模型会替你做出错误的假设，并且在不检查的情况下直接执行。它们不会管理混乱，不会寻求澄清，不会指出不一致之处，不会权衡利弊，也不会在应该回绝的时候说不。它们还是有点太‘顺从’了。
假设传播（Assumption propagation）：模型在早期误解了某些内容，并在此基础上构建了整个功能。直到你提交了五个 PR、架构已经定型时，你才会发现。这是一种典型的进一步退两步模式。
抽象膨胀（Abstraction bloat）：如果任其发挥，智能体 会无休止地把问题复杂化。原本 100 行代码就能解决的问题，它们会搭建 1000 行的脚手架，在函数就能胜任的地方创建复杂的类继承体系。你必须主动回击：“你就不能直接……？”它们的反应永远是“当然可以！”，然后立即简化。它们优化的是“看起来很全面”，而不是“可维护性”。
死代码堆积（Dead code accumulation）：它们通常不会自己清理门户。旧的实现依然残留在代码中。注释会因为副作用而被删除。即使是它们并不完全理解的代码，也会因为靠近任务区域而被改动。
顺从性附和（Sycophantic agreement）：它们并不总是会提出质疑。没有“你确定吗？”或者“你考虑过……吗？”。它们只会满腔热情地执行你描述的任何内容，哪怕你的描述不完整或自相矛盾。
如果你知道该关注什么，可以通过“技能（Skills）”来缓解其中一些问题。
尽管有系统提示词、有 CLAUDE.md 的指令、有计划模式，这些问题依然存在。它们不是待修复的 Bug，有时候甚至是这些系统运行方式的固有产物。
智能体优化的是输出的连贯性，而不是对你的前提进行质疑。
我在自己的团队中也见过这种情况——代码在评审时看起来没问题，但三个提交之后，当有人改动相邻系统时，它就崩溃了。
如果你关注数据，最近的调查显示出现了一个“验证瓶颈”：只有 48% 的开发者在提交代码前会一如既往地检查 AI 辅助生成的代码，尽管有 38% 的人发现评审 AI 生成的逻辑实际上比评审人类编写的代码更费劲。我们生成正确代码的速度变快了，但积累技术债的速度可能更快。
生成（写代码）和鉴别（读代码）是不同的认知能力。即使在你从头编写代码的能力萎缩之后，你依然可以胜任代码评审。但存在一个临界点，过了这个点，“评审”就变成了“橡皮图章”。
Jeremy Twei 为此创造了一个完美的词：理解债。当 LLM 一次性生成了某些看起来可行的东西时，直接跳过确实很有诱惑力。这就是最险恶的地方。智能体不会疲倦，它会带着坚定不移的自信，在一次又一次的实现中冲刺。代码看起来像那么回事，测试也通过了（或者看起来通过了）。你在交付压力之下，选择了继续。
随着时间的推移，你对自己代码库的理解可能会越来越少。
上周我就发现自己就陷入了这种状况。Claude 实现了一个我拖了好几天的功能。测试通过了。我扫了一眼，点点头，合并了。三天后，我没法解释它是如何工作的。
Yoko Li 完美地捕捉到了这种成瘾循环：
智能体实现了一个很棒的功能，但可能有 10% 的地方错了，然后你会想：‘嗨，小事，只需再提示它 5 分钟，我就能搞定这个。’结果那是 5 小时前的事了。
你总觉得“快成功了”。最后那 10% 感觉近在咫尺。再来一个提示词，再来一次迭代。这种心理钩子是真实存在的。
另一个人有不同的说法：
我大部分时间都在给智能体当保姆。那种 AGI 的氛围是真实的，但微观管理税也是真实的。你不再是在编程了，而是在监督、观察、重定向。这是另一种形式的精疲力竭。
最危险的部分在于：评审你已经无法从头编写的代码是极其容易的。如果你的“阅读”能力没有随着智能体 的“产出”能力同步提升，你就不再是在做工程，而是在祈祷。
在采用率高的团队里，个人产出飙升了 98%，但 PR 评审时间增加了高达 91%。
来自 Faros AI 和谷歌 DORA 报告的数据非常耐人寻味：
高 AI 采用率的团队合并的 PR 数量增加了 98%。
同样是这些团队，评审时间激增了 91%。
PR 的平均规模增加了 154%。
代码评审成了新的瓶颈。
Atlassian 2025 年的调查以鲜明的措辞揭示了这个悖论：99% 使用 AI 的开发者报告每周节省了 10 个小时以上，然而大多数人报告整体工作量并没有减少。编写代码节省的时间被组织摩擦消耗掉了——更多的上下文切换、更多的协调开销，以及处理更大量的变更。
我们换了更快的车，但路变得更堵了。
我们产出了更多的代码，但也花费了更多的时间去评审。只是发生瓶颈的地方变了。当你让一种资源变得更廉价（在这种情况下是代码生成）时，消费的增长速度会超过效率提升的速度，总资源消耗反而会上升。
我们并没有少写代码。我们写了远比以前更多的代码，而且仍然需要有人去理解其中的大部分。当然，也有一群开发者认为，如果 AI 能搞定，就不必如此了。
80% 的门槛在绿地项目中最为容易达到，因为在这些场景下，你可以控制整个技术栈，且通过小规模团队能让理解债保持在可控范围内。
这在以下几种场景中确实有效：
你掌控一切的个人项目。
“足够好”就真的已经足够好的 MVP（最小可行性产品）。
处于绿地开发领域、没有遗留负担的初创公司。
规模小到足以让理解债保持在可控范围内的团队。
在这些环境里，智能体的弱点就没那么重要了。你可以快速搭建脚手架，激进地重构，毫无政治阻力地抛弃代码。迭代的速度超过了偶尔的误导。
在具有复杂不变量的成熟代码库中，计算逻辑就反过来了。智能体不知道它不知道什么。它无法感知那些未成文的规则。它的自信心与它对上下文的理解成反比。
有人指出了我一直回避的显而易见的事实：前 90% 可能很容易，但最后 10% 可能要花很长时间。90% 的准确率对于非关键任务来说是可以接受的。但对于真正重要的部分，这还差得远。自动驾驶汽车在不出事时表现完美，这就是为什么 L2 随处可见，而 L4 大多仍是虚无缥缈的幻影。
对于非工程师来说，这堵墙虽然矮一些，但依然存在。AI Studio、v0 和 Bolt 等工具可以瞬间将草图变成可运行的原型。但要将原型强化为生产环境级别——处理大规模的真实用户数据、确保安全性和合规性——仍然需要工程基础。AI 能带你完成 MVP 的 80%；最后的 20% 需要耐心、深度学习或聘请工程师。
我们看到的不是一条平滑的采用曲线，而是已经跨越门槛的人与其他人之间的鸿沟。早期采用者与其余人之间的差距正在扩大，而非缩小。
Armin 的调查揭示了被原始采用数字掩盖的事实：44% 的开发者手动编写的代码比例仍超过 90%。我们面对的是双峰分布（bimodal distribution），而不是正态分布（bell curve）。一边是像 Karpathy 和 Claude Code 团队这样的人，每天提交数十个 PR，代码 100% 由 AI 编写，迭代速度空前；另一边则是绝大多数人，虽然在逐步采用 Copilot 类工具，但并未从根本上改变工作流。
这种年龄造成的分歧在讨论中也显而易见。年轻开发者似乎更愿意彻底改变工作流。年长的开发者则更持怀疑态度——不是因为他们不会用，而是因为他们见过足够多的周期，知道什么是暂时的生产力爆发，什么是可持续的实践。两者可能都是对的。
Stack Overflow 2025 年的调查显示，只有 16% 的人报告有“显著”的生产力提升。半数人认为提升有限。最主要的挫折感来自：“AI 方案看起来快对了，但又不全对”（66%）以及“调试 AI 代码比我自己写还要费时”（45%）。
那些在 2026 年风生水起的工程师，并不仅仅是在使用更好的工具。他们重新界定了自己的角色：从执行者转变为编排者。他们学会了以声明式（declarative）而非命令式（imperative）的方式思考。他们接受了现在的职责是架构监督和质量控制，而不是逐行编写代码。
而那些举步维艰的人则试图把 AI 当作更快的打字机。他们没有调整工作流。他们是在对抗智能体的逻辑，而不是重定向它的目标。他们没有投入精力学习如何有效地撰写提示词，而这一点现在与编写优秀的文档或设计规范一样关键。
这里有一个令人不安的事实：编排智能体的感觉非常像是在做管理。委派任务、评审产出、在走偏时重新引导。如果你是因为不想当经理才去当工程师，这种转变可能会让你感到背叛。你的角色已经在脚下发生了改变。
差距似乎正在扩大。那些摸清了如何与这些工具协作的人，交付的速度快到让我几乎跟不上。而其他所有人……仍在摸索。
这种分裂可能会让某些人感到不适。我一直说我是一个开发者，但我也很享受编程。认为这是两条分道扬镳的路——你必须二选一——这种想法感觉有点武断。就像我们在一个复杂的问题上强加了一个二元结论。评论区有人说得很完美：两种观点都是合理的，只是脑回路不同，谁都没错。
真正的杠杆。不要告诉 AI 该做什么——给它成功标准，然后看它不断循环。神奇之处不在于 智能体 写代码，而在于 智能体 不断迭代直到满足你指定的条件。
Karpathy 对“杠杆”的观察直戳核心：
LLM 极其擅长循环执行，直到达成特定目标，而这正是大多数‘感受到 AGI’的神奇时刻所在。
从命令式开发到声明式开发的转变：
旧模式（命令式）：“写一个函数，输入 X 返回 Y。使用这个库。处理这些边缘情况。确保……”
新模式（声明式）：“这是需求。这是必须通过的测试。这是成功标准。想办法解决它。”
这之所以有效，是因为 智能体 永远不会垂头丧气。它们会尝试那些你根本没耐心尝试的方法。它们会不知疲倦地迭代。如果你清晰地指明终点，它们就会设法到达那里——即便需要 30 次失败的尝试。
有效的模式：
先写测试，让 智能体 迭代直到通过。
通过 MCP 将其连接到浏览器，让它可视化地验证行为。
实现一个简单的正确版本，然后在保持正确性的前提下进行优化。
定义 API 契约，让它按规范实现。
但这只有在你的成功标准本身正确时才有效。“垃圾进，垃圾出”的效应会随着能力的提升而放大。
采用这种方法获得成功的开发者，将 70% 的时间花在定义问题和验证策略上，30% 花在执行上。这个比例与传统开发相比完全倒置了，但总耗时却大幅下降。
当任何人都能在几分钟内生成数千行代码时，能够说“我们不需要这个”的能力变得更有价值。
Karpathy 警告说：
我正在为 2026 年做准备，那将是 GitHub、Substack、Arxiv、X/Instagram 以及几乎所有数字媒体出现‘垃圾潮’的一年。
担忧很简单：当任何人都能生成海量的、看起来像那么回事的代码、内容、论文或博文时，我们该如何维持信噪比？
Boris Cherney 提出了反方观点：“我打赌不会出现‘垃圾潮’，因为模型会变得更擅长编写不那么平庸的代码，也更擅长修复现有的代码问题。与此同时，让模型在全新的上下文窗口中对其代码进行评审也会有所帮助。”
两者可能同时成立。产生“垃圾”的能力正以前所未有的规模存在，而防止它的工具也在不断涌现。问题在于哪一方的发展速度更快。
推动这股“垃圾潮”的，是那些误把速度当成生产力的人。智能体是没有方向感的马拉松选手，除非你给它们指明方向。如果你不在必要时审计它们的“代码行为”，它们会对着一堵砖墙猛冲十英里。
我见过的处理得比较好的团队通常会做这几件事：
全新上下文下的代码评审很有帮助，尽管让同一个模型去挑自己代码的刺感觉有点奇怪。但它确实管用——给它一个干净的起点，它能发现自己的错误。
每一步都进行自动化验证（CI/CD、linter、类型检查器、作为护栏的测试）。
刻意限制智能体的自主权（明确任务边界，制定清晰的成功标准）。
在架构决策点高度强调人工干预。
Karpathy 描述的代码质量问题——过度复杂、抽象膨胀、死代码——这些会随着模型的进步而改善，但不会消失。它们是这些系统处理问题方式的副产物。
未来属于那些能够在大局上保持一致的心智模式，同时让 智能体 处理微观战术繁琐工作的人。
在观察了团队过去一年的适应过程后，一些有效的模式已经成型：
不要只把 AI 用于零星的建议。直接生成完整的初稿，然后进行微调。Claude Code 团队的做法是：让模型在全新的上下文窗口中评审自己的代码。这能在人工评审前就发现问题。
将 70% 的精力花在问题定义上，30% 花在执行上。编写全面的规范，定义成功标准，预先提供测试用例。引导 智能体 的目标，而不是它的方法。
如果你反复修正同一类错误，请预先编写测试或 Lint 规则。在评审前，让 智能体 解释其代码并标出潜在问题。
把 AI 当作学习工具，而不是拐杖（这话你已经听过好几次了）。当智能体写出你不理解的东西时，这就是深入探究的信号。像对待导师的代码一样对待 AI 生成的代码——通过评审来学习，而不只是为了交付。
更多的模块化，更清晰的 API 边界。在提示词中加入文档完备的风格指南。在编码开始前提供高层级的架构描述。拉长规划阶段，压缩编码阶段，评审阶段则专注于设计而非语法。
那些发展得好的开发者不会是生成代码最多的人。他们将是那些知道该生成哪些代码、何时质疑输出，以及在双手离开键盘时仍能保持理解力的人。
如果你的“阅读”能力不能与 智能体 的“产出”能力同步增长，你就不再是在做工程了。你只是在盖章。
对我来说，这就像温水煮青蛙。一开始只是往 ChatGPT 里多粘贴了一点东西，然后是在 IDE 内进行提示，接着是智能体工具。突然之间，我几乎不再亲自动手写代码了。这种过渡如此缓慢，以至于我还没意识到，就已经身处其中了。
在重度使用 AI 的用户中，已经出现了早期技能萎缩的迹象。凡事依赖 AI 的初级开发者报告说，随着时间的推移，他们对解决问题能力的自信心正在下降。这就是应用在编程上的“谷歌效应”——当你不断外包时，你的大脑就不再记忆了。
我不知道解决方案是什么，但我一直在尝试几件事：
使用 TDD：在让 AI 实现之前，先写测试（或思考测试用例）。
与资深开发者结对：实时讨论 AI 的建议，学习决策过程。
要求解释：让 AI 证明其方法的合理性，而不仅仅是生成方案。
交替进行：手动编写一些功能以保持肌肉记忆。
风险是真实的：评审你已经无法从头编写的代码极其容易。一旦发生这种情况，你对工具的依赖就会限制你的成长。
那些能够长期发展的工程师，是那些利用 AI 加速获取经验、而不是完全绕过经验的人。他们在利用 AI 更快探索更多领域的同时，保持了自己的基本功。
从 70% 到 80% 的跨越不在于百分比，而在于原型与生产就绪软件之间的差距。这个差距正在缩小，但尚未闭合。
Karpathy 提出了正确的问题：
‘10 倍工程师’——即平均水平与最高水平工程师之间的生产力差距——会发生什么变化？这种差距极有可能大幅增加。在 LLM 的武装下，全才是否会日益胜过专才？
这些问题将定义接下来的几年。
有一件事是肯定的：在 2025 年底，早期采用者 80% 的代码是由 AI 编写的。即使你的比例低得多，也可能比一年前要高。这使得人类的角色被放大了：掌控结果、维持质量标杆、确保测试真正验证了行为。
危险不在于智能体失效。我认为危险在于它如此自信地在错误的方向上成功了，以至于你不再看指南针。
DORA 2025 年的报告定格了这一现实：AI 是你开发实践的放大器。好的流程会变得更好（高效团队的交付速度提升了 55-70%）。坏的流程会变得更糟（以空前的速度积累债务）。这里没有银弹。
Karpathy 最后的观察最能引起共鸣：
我没预料到，有了智能体之后，编程变得更有趣了，因为许多‘填空式’的苦差事被移除了，剩下的则是极具创意性的部分。我也觉得不再那么容易受阻或卡壳，我感受到了更多的勇气，因为几乎总有办法与它携手并进，取得一些积极的进展。
他还指出：“LLM 编程将根据工程师主要是喜欢写代码还是喜欢开发产品，而将他们一分为二。”
这大概是关于未来走向最深刻的预测了。
如果你喜欢编写代码本身的行为——它的工艺感、它的冥想感——那么这种转变可能会让你感到失落。如果你喜欢构建事物，而代码只是必要的手段，那么这感觉就像是解放。
两种反应都没有错。但工具正在针对后者进行优化。
生产力方面的宣传往往言过其实。AI 依然会犯下资深初级开发者都不会犯的错误。理解债是真实的，且尚未被充分理解。“垃圾潮”的风险不容小觑。
但这种转变是真实的。当 Karpathy 承认他几乎不再直接写代码，当 Claude Code 团队每天提交 20 多个 100% 由 AI 编写的 PR 时，我们已经过了可以将其斥为炒作的阶段了。
作为软件工程师，我们的身份从来都不是“那个会写代码的人”，而是“那个能用软件解决问题的人”。
AI 并非在取代工程师。它在放大工程师——无论好坏。
我的建议是：拥抱工具，但对结果负责。利用 AI 加速学习，而不是跳过学习。专注于那些比以往任何时候都更重要的基础：健壮的架构、整洁的代码、完善的测试、深思熟虑的 UX。这些依然和以前一样重要，甚至更重要，因为实现本身已不再是瓶颈。
我不知道这会走向何方。Karpathy 可能是对的，它会将人们区分为喜欢写代码的人和喜欢开发产品的人。
我们都在公开场合探索这一切，一次提交一个 PR。
译者：boxi。
发布时间：2026-03-04 08:03
立即订购
在线咨询
返回顶部