2026年6月7日 · 阅读 —

Karpathy 用 Claude 编程几周后发现，真正改变的不是写代码速度，而是工程师的工作方式

Agent 与 Skills知识与内容工具

Karpathy 用 Claude 编程几周后发现，真正改变的不是写代码速度，而是工程师的工作方式

过去几周，Andrej Karpathy 用 Claude 写了很多代码。

然后他发现，自己的工作方式在极短时间里彻底反了过来。

2025 年 11 月，他大约 80% 的时间还在手写代码和使用自动补全，只有 20% 交给 Agent。到了 12 月，这个比例变成了 80% Agent 编程，20% 人工修改和收尾。

一个写了二十多年代码的人，现在大部分时间是在用英语编程。

不是自己敲出每一行，而是告诉 Claude 想做什么，再盯着它把代码写出来。

Karpathy 说，这多少有点伤自尊。

我觉得这句话特别真实。

程序员长期以来最容易获得成就感的瞬间，就是脑子里的想法经过双手，变成一段漂亮、简洁、能运行的代码。可当 Agent 开始接管大量实现工作以后，人突然从亲手做东西的人，变成了站在旁边描述、检查和纠偏的人。

感觉多少有点怪。

但怪归怪，能一次操作几十个文件、连续跑测试、改实现、查资料，再自己循环修复的能力，实在太有用了。

真正值得讨论的，已经不是 AI 会不会写代码。

而是当 Agent 开始承担大部分编码工作以后，工程师到底应该把自己的注意力放在哪里。

80% Agent 编程，不等于 80% 工作已经消失

很多人看到 80% Agent 编程，第一反应是生产效率提高了四倍，甚至工程师只剩下原来 20% 的工作。

其实不是这么算的。

Karpathy 自己也说，很难准确衡量 LLM 到底带来了多少速度提升。它当然让原本要做的事情更快了，但更大的变化是，他开始做以前根本不会做的事情。

一些小工具，过去觉得不值得花半天时间，现在一句需求就能先跑出原型。

一些陌生技术栈，过去因为知识门槛不会主动碰，现在可以让 Agent 先读代码、解释结构，再带着自己完成修改。

一些长期积压的重构、测试和文档，过去总排在需求后面，现在终于有了执行者。

所以 Agent 带来的不只是提速，更像能力边界的扩张。

以前一个工程师一天能认真处理三件事，现在不是把这三件事压缩到两小时以后就下班，而是会顺手再处理十件以前不值得做、不会做，或者没精力做的事。

这也是为什么很多团队用了 AI，代码产量明显增加，人却没有轻松多少。

生产瓶颈从写代码，转移到了定义问题、提供上下文、审查结果和控制系统复杂度。

代码生成越来越便宜，判断力反而越来越贵。

Agent 最危险的错误，已经不是语法写错

几年前大家担心 AI 写代码，想到的还是变量名拼错、括号没闭合、API 调不通。

这些错误其实不太可怕。

编译器、类型检查、Lint 和测试，通常很快就能发现。

现在真正麻烦的是另一种错误。

Agent 会替你做出一个错误假设，然后非常勤奋、非常自信地沿着这个假设一路跑下去。

它不太会主动承认自己困惑，不一定会停下来寻求澄清，也不擅长把需求里的矛盾摆到桌面上。该讨论取舍的时候，它可能直接选一个方案；该反对你的时候，它又经常过于配合。

最后交出来的代码能运行，测试也可能通过，甚至看起来还挺专业。

但方向错了。

这种错误很像一个动作很快、态度很好，却有点急着交差的初级工程师。语法没问题，命名也像模像样，只是在需求、边界或架构上偷偷理解歪了。

更麻烦的是，Agent 很喜欢过度设计。

明明一百行能解决的问题，它可能给你造出一千行代码，再附带几个抽象层、一套扩展接口和一些实际上没人需要的通用能力。你问它能不能简单一点，它又会非常爽快地回答可以，然后立刻删回一百行。

这件事挺离谱的。

它说明很多复杂度并不是需求真的需要，而是没有人在过程中明确阻止。

Agent 不会天然珍惜代码库的简洁。守住这件事，仍然是人的责任。

IDE 没有过时，它从施工台变成了监控台

现在有两种声音很常见。

一种说以后不需要 IDE 了，终端里开个 Claude Code 或 Codex 就够了。

另一种说应该同时拉起一大群 Agent，让它们像软件团队一样并行工作。

Karpathy 对这两件事都比较克制。

他的工作流是左边开几个 Claude Code 会话，右边放一个大 IDE，用来浏览代码和手工修改。

这个画面其实很能代表当下。

IDE 没消失，只是职责变了。

过去它主要是施工台，人坐在里面写代码、跳转定义、调试和重构。现在它越来越像监控台，用来观察 Agent 改了什么、影响了哪里、有没有碰不该碰的文件，以及整体结构是不是开始失控。

多 Agent 也一样。

同时启动十个 Agent 并不等于拥有十倍产能。如果任务边界、代码所有权、验收标准和合并机制没设计好，最后得到的可能只是十份需要人工审查的改动，以及更多上下文切换。

单个 Agent 还没管明白，就急着组建 Agent 军团，通常只是把错误并行化。

不要只告诉它怎么做，要给它一个能验证的目标

Karpathy 的整组笔记里，我觉得最值得立刻拿去用的一句话，是把工作方式从命令式改成声明式。

不要只给 Agent 一串操作步骤。

给它成功标准，让它在工具循环里不断尝试，直到结果满足标准。

例如，不要只说修改登录接口里的校验逻辑。

更好的任务描述是，先补充能复现问题的测试，修复实现，让新增测试和现有测试全部通过，保持公开接口兼容，不修改认证模块以外的文件，最后说明改动和剩余风险。

这两种提示看起来只差一点，Agent 的工作质量却可能完全不同。

前一种把 Agent 当成只会服从的打字员。后一种给了它目标、边界和反馈回路。

这也是 TDD 在 Agent 编程里突然变得更重要的原因。

测试不只是帮人检查代码，它还是 Agent 可以反复调用的确定性反馈。没有测试、编译器、Lint、浏览器自动化或其他可验证工具，Agent 只能凭语言感觉判断自己有没有完成任务。

那不是工程闭环，只是写得比较长的猜测。

比较稳的做法，是先把任务写成可验收目标，再让 Agent 循环执行：

  1. 先阅读相关代码和约束，只输出理解、假设、风险与方案。
  2. 人确认方向，修正错误假设。
  3. 先写能失败的测试或其他验收检查。
  4. 实现最小修改，让验收通过。
  5. 检查 Diff，删除多余抽象、死代码和无关改动。
  6. 运行完整相关测试，再由人完成最终评审。

计划模式能缓解一部分问题，但真正重要的不是多写一份漂亮计划，而是在写代码前，逼着 Agent 暴露它准备依赖的假设。

很多灾难，看到假设列表的那一刻就能拦住。

有人把这些教训，压缩成了四条 Claude Code 规则

Karpathy 发出这组笔记以后，andrej-karpathy-skills 项目把其中最具体的工程教训，整理成了一个可以直接放进 Claude Code 的 CLAUDE.md，也提供了 Claude Code 插件和 Cursor 规则。

它没有堆很多技巧，只留下四条原则。

第一条是编码前思考。

不要默默猜测需求。如果存在多种解释，就把它们列出来；发现更简单的方案，要主动提出；真的困惑时，先停下来澄清。

第二条是简洁优先。

只写解决当前问题需要的最少代码，不提前增加没人要求的功能、灵活性和抽象。如果两百行能收回五十行，就继续简化。

第三条是精准修改。

只碰任务必须修改的地方，不顺手改相邻代码、注释和格式，也不借着一个小需求重构整个模块。每一行 Diff，都应该能追溯到用户的请求。

第四条是目标驱动执行。

把修复 Bug 改写成先写出复现测试，再让测试通过；把重构改写成修改前后测试都通过；把模糊的做完它，改成一组可以验证的成功标准。

这四条规则挺有价值，因为它们并没有试图让 Agent 显得更聪明，而是在限制它最常见的坏习惯。

但这里也需要冷静一下。

把规则写进 CLAUDE.md，不代表 Agent 从此就一定遵守。Karpathy 自己也提到，他尝试用简单指令修复这些问题，效果仍然有限。提示词可以改变模型的倾向，却不能代替编译器、测试、权限、Git Diff、代码评审和任务隔离。

所以更稳妥的理解是，这四条规则适合做第一层护栏。

真正进入生产，还得让工程系统负责兜底。

Agent 最像 AGI 的时刻，可能只是它不会累

Karpathy 还提到一个很有意思的观察。

看着 Agent 长时间解决一个问题，会产生一种很强的智能感。它不会疲惫，不会沮丧，失败以后继续查、继续改、继续跑，半小时后真有可能把问题啃下来。

人类工作里有一个经常被忽略的瓶颈，就是耐力。

不是不知道怎么解决，而是被错误、重复操作和漫长等待磨到不想继续。

Agent 把这种耐力一下拉高了。

不过耐力也是一把双刃剑。

方向正确时，它能持续推进。方向错误时，它也能不知疲倦地制造更多错误。一个无限耐心的执行者，如果没有清晰目标和反馈工具，只会更稳定地跑偏。

所以真正产生杠杆的组合，不是聪明模型加长时间运行。

而是模型、可验证目标、受控工具和人工判断一起进入循环。

当填空题被拿走，编程可能反而更有趣

Karpathy 原本没想到，用 Agent 编程会让编程变得更有趣。

原因挺简单。

大量查 API、补样板代码、搬字段、改格式和机械重构被拿走以后，剩下的工作更接近创造本身。人可以花更多时间决定做什么、怎样设计、哪里值得尝试，而不是被各种填空题耗掉注意力。

卡住的感觉也少了。

过去遇到陌生代码库或难查的问题，很容易先搁置，等有完整时间再处理。有 Agent 在旁边读代码、检索、试错，即使它不能一次解决，也经常能先推动一点点。只要事情持续向前，人就更敢碰原来不愿碰的问题。

不过这种快乐并不适合所有工程师。

Karpathy 认为，LLM 编程可能会让工程师逐渐分成两类。一类人最享受的是写代码本身，喜欢亲手组织语句、打磨实现和获得手感。另一类人真正喜欢的是构建东西，代码只是把想法变成现实的材料。

对前一类人来说，Agent 拿走的可能正是乐趣。

对后一类人来说，Agent 拿走的是阻力。

这两种感受都是真的。团队引入 Agent 时，也不能只统计生成了多少代码，还要观察工程师是不是获得了更强的创造空间，还是正在变成被迫审查机器输出的人。

会读代码，不代表还会写代码

大量使用 Agent 以后，Karpathy 已经感觉自己的手写代码能力在慢慢退化。

他把写代码称为生成能力，把读代码和判断代码称为辨别能力。这两种能力在大脑里并不相同。一个人可能依然看得懂代码好不好，却开始记不清具体语法，离开 Agent 后写不出原来熟练的实现。

这个风险很容易被忽略。

因为日常工作并不会立刻出问题。你仍然能看 Diff，仍然能指出结构不对，仍然能让 Agent 修复。直到某天遇到线上事故、陌生环境、工具不可用，或者你必须从零推导一个关键算法，才会发现自己的手感已经变钝。

但解决办法也不是拒绝 Agent，强迫所有事情继续手写。

就像有了计算器以后，人不需要坚持手算每一笔账，但仍然要保留数量感，知道结果是不是离谱。

工程师需要刻意保留的，可能也不再是每个框架 API 的记忆，而是调试能力、系统建模、边界意识、性能直觉、安全判断，以及从空白状态写出关键逻辑的能力。

可以把低风险、重复性的实现交出去，但核心算法、关键链路和事故排查，最好仍然定期亲手做。

否则人会慢慢变成只会批准 Agent 输出的人。

一旦辨别能力也跟着退化，所谓 80% Agent 编程，就会变成 100% 碰运气。

2026 年真正稀缺的，可能不是代码，而是可信代码

Karpathy 用了一个词来描述他对 2026 年的担心，Slopacolypse，可以理解成低质量 AI 内容大爆发。

GitHub、论文、社交媒体、文章和各种数字内容，都会因为生成成本迅速下降而迎来巨大增量。代码当然也不会例外。

以后最不缺的就是实现。

一个需求可以同时生成五套方案，一个开源项目几天就能堆出几万行代码，一个过去没人愿意做的小工具很快就能拥有完整界面、文档和安装脚本。

看起来都挺像那么回事。

但它为什么这样设计，边界在哪里，测试是否覆盖真实风险，出了问题谁能接住，这些不会随着代码一起自动出现。

代码数量越多，维护债务、依赖风险和审查压力也会一起增长。

所以接下来工程团队真正要建设的，不只是更强的 Agent，而是一整套让 Agent 产出变得可信的机制，包括清晰的 Spec、自动化测试、权限边界、代码评审、可观测性、回滚能力和责任归属。

模型负责生成候选答案。

工程系统负责证明答案能用。

人负责判断，这个答案是否值得进入真实世界。

编程没有消失，只是重心往上移了一层

Karpathy 最后提出了几个没有答案的问题。

当每个工程师都拿到 Agent，普通工程师和顶尖工程师之间的生产力差距会缩小，还是进一步扩大？所谓十倍工程师，会不会借助 Agent 变成五十倍工程师？

通才会不会因为 Agent 能补齐局部知识，开始超过只熟悉单一领域的专家？

未来的编程会像玩《星际争霸》，像搭《异星工厂》，还是像演奏音乐？

还有一个更大的问题，社会里究竟有多少工作，都被数字知识劳动的生产速度卡住了？

如果写代码、查资料、整理信息、生成方案和操作软件的成本同时下降，这次变化就不会只留在程序员的 IDE 里。它会慢慢进入财务、法务、科研、设计、运营和管理，再重新塑造组织怎么分工、怎么审批、怎么对结果负责。

Karpathy 的总判断是，Claude 和 Codex 的 Agent 能力在 2025 年 12 月前后跨过了某种连贯性临界点，软件工程因此发生了阶段变化。

但模型智能突然跑到了前面，工具集成、知识接入、组织流程和普及速度还在后面追。

我觉得这个判断比任何单个编码 Demo 都重要。

接下来最忙的，不一定只是模型公司。每一家真正使用 Agent 的团队，都要重新回答任务怎样拆、权限怎样给、产出怎样验、事故由谁负责，以及人应该保留什么能力。

我自己的判断是，Agent 会大幅降低实现门槛，却不会自动降低复杂系统的判断门槛。

真正厉害的工程师，会把 Agent 当成杠杆，把更多精力放到问题定义、系统设计、验证机制和最终取舍上。缺少判断力的人，则更容易用极快速度生产一大堆看起来能跑、实际上没人真正理解的东西。

这也是这轮变化最矛盾的地方。

编程正在变得更容易，软件工程却未必。

我们确实越来越少亲手敲代码，却要比以前更清楚自己到底在构建什么、为什么这样构建，以及如何证明它没有悄悄跑偏。

用英语编程，可能会成为很多工程师的新日常。

但最后那句「这段代码可以进生产」，仍然不能只让 Agent 自己说。

参考资料

代码生成越来越便宜，真正昂贵的是定义、验证，以及为结果负责。

#ClaudeCode #Codex #AICoding #Agent #软件工程 #TDD #HarnessEngineering #Karpathy

Continue reading

继续阅读