👆 上下滑动阅读 · 左右滑动翻页 · 键盘方向键同理

🧠

Karpathy 的 AI 工作流革命
从写代码到调度代理 📖 注释版

自 2024 年 12 月起不再亲手写代码 · 20 年直觉被一夜推翻
—— OpenAI 联合创始人 Andrej Karpathy 的 Agentic Engineering 方法论

80%

代码委托给代理

20年

直觉被一夜推翻

16h

每天调度代理

5项

核心方法论原则

来源：The AI Corner · 2026年3月24日

📖 含 50 个术语注释

🔵 蓝色虚线 = 技术工具（点击查看解释）

🟢 绿色虚线 = 产品/人物/平台

🟠 橙色虚线 = 概念/方法论

🟣 紫色虚线 = AI模型

点击或触摸带虚线下划线的术语查看注释 👇

Karpathy 不再写代码了

THE END OF HAND-CODING

本页要点从 OpenAI 联合创始人到 Tesla AI 总监，再到独立教育者—— Karpathy 自 2024 年 12 月起就几乎停止了亲手写代码。大多数工程师认为 AI 让他们效率更高，但 Karpathy 的判断截然不同：AI 让他在自己的工作流中变得多余。

Karpathy

大部分人觉得 AI 让自己变快了——写代码效率提高了两倍、三倍。但我的感受完全不同。AI 不是让我更快，而是让我在自己的工作流里变得不再必要。AI agent 现在可以完成整个任务，从头到尾。我要做的只是描述目标、审查产出。

2015 参与创办 OpenAI，参与早期 GPT 方向探索

2017-2022 领导 Tesla Autopilot 视觉团队，将深度学习应用于自动驾驶感知系统

2023 创办 Eureka Labs，专注 AI 原生教育；在 YouTube 发布深度教程，影响数百万开发者

2024年12月公开宣布停止亲手编码，转向全面的 Agentic Engineering 工作方式

2024 年 12 月：拐点时刻

THE DECEMBER 2024 INFLECTION POINT

本页要点 Karpathy 的编码方式发生了根本性翻转：从自己写 80% 代码，变成把 80% 委托给代理。如果你的工作方式自 2024 年底以来没有任何变化，你已经落后了整整一个职业代际。

以前

80%

自己写代码
20% 交给工具辅助

现在

20%

自己写代码
80% 委托给 AI 代理

Karpathy

80/20 Flip 不仅仅是「让 AI 帮写代码」。它是整个工作流的重构。代理不是在你旁边帮忙的助手，而是独立完成整个任务的执行者。你的角色从生产者变成了调度者和审查者。如果你的工作流自 2024 年底以来没有发生根本性变化，那么你已经落后了一整个职业代际。

这不是渐进式改进，而是范式转换。代理完成的不是代码片段，而是完整的任务。

—— Andrej Karpathy

关键区分：完成任务 vs 完成代码行

以前的 AI 编程辅助（如早期 GitHub Copilot）帮你补全代码行。现在的代理完成的是整个任务——从理解需求、设计方案、写代码、写测试到调试。这就是为什么 Karpathy 说「如果你的默认工作流自 2024 年底以来没有变化，你已经落后了整整一个职业代际」。差距不是效率上的百分之几，而是工作模式的代际差异。

「显化意图」取代「写代码」

MANIFEST REPLACES CODING

本页要点 Karpathy 提出一个新动词来描述当下的工作——Manifest Intent（显化意图）。工程师每天 16 小时都在做的事不再是敲代码，而是向代理表达目标、分解任务、审查产出、迭代指令。核心技能变成了判断力。

Code isn't even the right verb anymore. 代码这个词本身就已经过时了。新的动词不是「编码」，而是「显化意图」。你不再编写指令，你表达意图，代理去实现。

—— Andrej Karpathy

这个转变远比「用自然语言写程序」深刻。以前你 80% 的时间花在「如何实现」——语法、API 调用、边界处理。现在你 80% 的时间花在「要实现什么」和「为什么实现」。日常工作变成了：把大目标拆成可分配的任务，分发给不同的 AI agent，审查宏观产出，然后迭代你的指令——而不是迭代代码。

目标分解：把大愿景拆解成代理能独立完成的子任务
分配代理：每个子任务分配给最合适的 AI agent
审查产出：不纠结单行代码，关注整体方向与架构
迭代指令：优化提示词和描述，而非手动改代码
核心能力 = 判断力：知道什么该委托、什么该亲手做、什么该放弃

正在被培养的技能是判断力

Karpathy 强调：你每天 16 小时都在做的事——分解目标、分配任务、审查宏观产出、迭代指令——本质上都是判断力的训练。写代码训练的是实现能力，而「显化意图」训练的是决策能力。后者的价值随着 AI 能力提升而增加，前者的价值随之递减。

锯齿性：博士和十岁孩子并存

JAGGEDNESS OF AI MODELS

本页要点前沿模型的能力曲线不是平滑的，而是锯齿状的——某些任务达到博士水平，另一些犯 10 岁小孩的错误。RL 只能优化可验证的指标（编译通过、测试通过），而更柔软的信号（比如知道什么时候该求助）处于优化范围之外。应对策略：在锯齿低谷处设置 Checkpoints。

Karpathy

模型可以写出博士水平的系统代码，然后在简单的字符串拼接上犯一个 10 岁小孩都不会犯的低级错误。这不是 bug，这就是 Jaggedness 的本质。RL 训练只在可以自动验证的维度上起作用——代码能否编译、测试能否通过。但那些更微妙的能力，比如知道什么时候应该停下来问人类，恰恰不在优化目标之内。

模型能力的锯齿分布

应对策略：在已知的「锯齿低谷」设置 Checkpoints，提前拦截
RL 能优化编译和测试，但无法优化「何时该求助」
在 Compounding Errors 扩散之前捕获它们
不要盲目信任 AI 产出——建立针对性的检查机制

AutoResearch：20 年直觉被一夜推翻

WHEN AI SURPASSES HUMAN INTUITION

本页要点 AutoResearch 一夜之间发现了两个问题：NanoGPT 中 value embedding 上的 Weight Decay 设置有误，以及 Adam 优化器的 beta 参数并非最优。这些参数之间相互耦合，需要同时调整才能得到最佳结果。Karpathy 20 年的深度学习经验——就这样被超越了。

Karpathy

AutoResearch 发现我一直用的 Weight Decay 在 value embedding 上是错误的——这个参数不应该被衰减。同时，Adam 的 beta 参数也有更好的选择。最关键的是，这两组参数之间是耦合的，你必须同时重新调整它们才能看到效果。这种多维度的联合搜索恰恰是人类直觉做不到的。

发现一：value embedding 上不应该施加 Weight Decay——标准做法其实有误
发现二：Adam 的 beta1=0.9, beta2=0.999 并非最优，存在更好的替代组合
关键：这些参数是耦合的——必须同时重新调参才能生效
人类直觉只能发现单变量偏差，AI 的暴力搜索能找到多维联合最优解

人类不应该再做 Hyperparameter Search 了。配方很简单：定义目标、建立可验证指标、划定搜索边界、然后把自己从流程中移除。

—— Andrej Karpathy

AutoResearch 四步配方

01 定义目标函数——你要优化什么？（如验证集 loss）

02 建立可自动验证的指标——结果能被程序化评估

03 划定搜索空间边界——合理约束参数范围

04 把自己从流程中彻底移除——不要干预

Token 吞吐量：你才是瓶颈

TOKEN THROUGHPUT & PARALLELIZATION

本页要点 Karpathy 用 GPU 饱和率的思维来看待 AI 订阅——闲置的 token 就是未被利用的算力。瓶颈从基础设施转移到了人类的判断力并行化能力。在可以并行的时代串行工作，本身就是错误。

I feel anxious when I have subscription left. That just means I'm not maximizing my token throughput. 当我的订阅额度还有剩余时，我会感到焦虑——这意味着我没有最大化我的 Token Throughput。闲置的 token 就是你没有用到的算力。

—— Andrej Karpathy

类比很直接：如果你管理一个 GPU 集群，你绝不会让显卡空闲。同样的逻辑——如果你订阅了 AI 服务，每一个闲置的 token 都是浪费。传统程序员一次只做一件事：写一个函数、调一个 bug。在 Agentic Engineering 时代，你应该同时运行多个代理，每个处理不同的任务流。你要 Parallelization 的不是代码执行，而是判断力。

用 GPU 利用率的思维审视你的 AI 使用效率
同时运行多个 AI agent——一个重构、一个写测试、一个做代码审查
瓶颈不在 AI 速度，而在你分配任务和审查结果的速度
在可以并行的世界里串行工作——这本身就是一种战略性错误
赢家法则：学会并行化你的判断力，而不仅仅是并行化你的代码

API-first 架构：代理的世界没有 App

API-FIRST DESIGN + DOBBY EXAMPLE

本页要点 Karpathy 有一个名叫「Dobby」的代理，通过单一的 WhatsApp API 对话控制家里的灯光、暖通、窗帘、泳池和安防——取代了六个独立的 App。他的结论是：API-first Architecture 应该是默认选择。App 不应该存在，应该是被代理消费的 API。

Every app in the app store probably shouldn't exist. App Store 里的每一个 App 大概都不应该存在。它们不应该是 App——它们应该是被代理直接消费的 API。

—— Andrej Karpathy

Karpathy

我家有六个不同的智能家居 App——灯光一个、空调一个、窗帘一个、泳池一个、安防一个。现在我有一个叫 Dobby 的 AI agent，通过 WhatsApp API 跟它聊天就能控制所有设备。App 根本就不应该存在——它们应该是 API，被代理消费。先构建 API，UI 是其次。

API 优先构建：每个功能首先是 API 端点，GUI 是后面再加的
Markdown 文档：用 Markdown 写文档，不用 HTML——机器可读性更强
默认假设程序化消费：你的系统首要用户是代理，其次才是人类
错误信息结构化：让代理能自动解析和处理错误，而不是给人看的模糊提示

未来的软件有两层用户：人类通过 GUI 交互，AI 代理通过 API 交互。如果你只为其中一层设计，你就丢失了一半的价值。

—— Andrej Karpathy

代理人格：反馈风格决定协作质量

AGENT PERSONA MATTERS

本页要点 Claude 提供校准过的热情反馈，而 Codex 的输出冷淡平淡。校准过的反馈能建立信任、激发思考；平淡的态度会扼杀思维伙伴关系。Karpathy 的结论：人格是一个产品决策。

Karpathy

你和代理的关系不只是「给任务、拿结果」。当 Claude 给反馈时，它会解释为什么这么做、指出潜在风险、建议替代方案。这种 Calibrated Feedback 让你真正开始思考。而 Codex 更像是给你代码但不引导你思考。人格是一个产品决策——它直接影响人类的思维质量。

Claude 风格

校准过的热情反馈
解释决策原因
指出潜在风险
建议替代方案
→ 思考伙伴

Codex 风格

平淡冷漠的输出
直接给代码
少有解释
机械式执行
→ 代码生成器

校准反馈建立信任——你会更愿意委托复杂任务
冷漠态度扼杀思维伙伴关系——你会降级成「写提示词的人」
选择 AI 工具时，交互风格和代码质量同等重要

Calibrated feedback builds trust. Flat affect kills it. 校准过的反馈能建立信任，平淡的态度会扼杀它。选择你的 AI 伙伴时，人格不是附加功能——它是核心产品决策。

—— Andrej Karpathy

先为代理写文档，再让代理给人解释

AGENT-CENTRIC DOCUMENTATION

本页要点文档的首要读者不再是人类，而是代理。先为代理写文档，代理再向人类解释。决策框架：代理做不了的 = 你的工作；代理做得还行的 = 委托出去；代理比你做得好的 = 彻底放手。

You shouldn't write docs for humans anymore. You should have Markdown docs for agents, not HTML docs for humans. 你不应该再为人类写文档了。你应该为代理写 Markdown 文档，而不是为人类写 HTML 文档。

—— Andrej Karpathy

我们一直为人类写文档——教程、FAQ、操作指南。现在应该反过来：先写让代理能理解的文档（结构化、Markdown、明确的输入输出定义），然后让代理根据用户的具体情境去解释。如果代理能理解你的库，它就能向任何人类解释。这比写一份面面俱到的人类文档高效得多。

Karpathy 三层决策框架

Agent 做不了的

锯齿低谷区 · 需要人类判断的边界情况

这是你的工作——亲自做

Agent 做得还行

需要审查但可委托

委托出去，设好 Checkpoints

Agent 比你做得好

锯齿高峰区 · 如超参搜索

彻底放手——别再自己做了

文档用 Markdown 而非 HTML——AI 对 Markdown 的解析能力远强于 HTML
明确输入/输出/异常——让代理可以自动处理边界情况
Decision Framework 的核心：诚实评估代理在每项任务上的实际能力水平

杰文斯悖论：更便宜 = 需求更多

JEVONS PARADOX IN SOFTWARE

本页要点 Jevons Paradox 的核心洞察：当代码生产成本暴跌时，需求会爆发式增长。就像 ATM 机没有减少银行柜员——降低了分行运营成本后，银行反而开了更多分行，结果柜员总数上升了。以前「不值得写」的定制内部工具，现在可以轻松实现。赢家是那些能调度自动化产能的人。

Karpathy

所有人都在问「AI 会不会取代程序员」。但 Jevons Paradox 告诉我们历史上从来都不是这样运作的。ATM 机 1970 年代问世，人人以为柜员要失业了。结果呢？分行运营成本降低了，银行开了更多分行，柜员总数反而上升。以前公司内部那些「不值得专门开发的小工具」，现在因为成本极低，全部值得做了。软件正在渗透到以前从未被软件化的角落。

ATM 类比：1970s ATM 问世 → 降低分行成本 → 更多分行 → 柜员总数反升
代码类比：AI 降低代码成本 → 更多软件需求 → 更多软件相关工作
以前「不值得做」的定制内部工具，现在因为成本极低而值得做了
赢家画像：能调度自动化产能的导演，而非亲手写代码的演员

更便宜的代码不是零和游戏。它扩大的是整个蛋糕，而非重新切分现有蛋糕。

—— Andrej Karpathy

开源模型：基础设施层

OPEN SOURCE AS INFRASTRUCTURE

本页要点开源模型扮演的角色类似于 Linux——它是基础设施层。与前沿模型之间存在约 6-8 个月的能力滞后。两者都不可或缺：前沿模型用于攻克最难的问题，开源模型提供基础设施级别的可靠性。

开源模型之于 AI，就像 Linux 之于操作系统——不是最前沿，但是最可靠的基础设施。前沿模型像 GPT-5 和 Claude 在能力边界上领先 6-8 个月，但开源模型可以本地部署、完全可控、无 API 成本。两者不是替代关系，而是互补关系：前沿模型推动创新边界，开源模型把已验证的能力变成基础设施。

前沿模型

能力最前沿
攻克最难的问题
API 付费使用
如 GPT-5、Claude

开源模型

滞后 6-8 个月
基础设施级可靠
本地部署、零 API 费用
如 LLaMA、Mistral

闭源前沿模型 = Windows / macOS：能力最强、体验最好，但受制于平台
开源模型 = Linux：滞后 6-8 个月，但差距在快速缩小
前沿模型用于推动创新边界，开源模型用于规模化部署已验证场景
对隐私敏感或延迟敏感的场景，开源模型是唯一选择
行业需要两者：像 Linux 最终无处不在一样，开源模型将赢得基础设施层

Open source will win like Linux won. Everywhere. 开源会像 Linux 一样赢——无处不在。

—— Andrej Karpathy

Karpathy 方法论总结

THE KARPATHY PLAYBOOK

本页要点分三类受众给出具体行动建议：创始人、投资人、工程师。加上 5 条核心原则。核心信息：新的动词是「显化」，从现在就开始。

给创始人

代理会在人类之前消费你的软件——为代理而设计
先构建 API，再考虑 GUI——API-first Architecture
文档用 Markdown 写，为机器消费而设计，而非 HTML 给人看

给投资人

更便宜的代码生产扩大了整个市场——Jevons Paradox 在起作用
Token Throughput 基础设施值得重点关注——帮人最大化吞吐的工具
代理编排平台——管理多代理并行工作流
可验证评估体系——为 Hyperparameter Search 类场景提供基准

给工程师

找一个有可验证输出的手动任务，交给代理，然后把自己从循环中移除
别等完美工具——现在就用 Cursor、Claude Code、Codex CLI 开始

5 条核心原则

Manifest Intent——表达意图，而非编写指令
在 Jaggedness 处设 Checkpoints——信任但要验证
最大化 Token Throughput——Parallelization 你的判断力
API-first Architecture——为代理设计接口
用 Decision Framework 分类任务——什么该自己做、什么该委托、什么该放弃

Karpathy 的核心信息

瓶颈是你自己。最大化 Token Throughput。以宏观动作行动——不要在单行代码上纠结。先为代理写文档，再让代理给人解释。

The bottleneck is you. 瓶颈是你自己。新的动词是「显化」。从现在就开始。

—— Andrej Karpathy

原理注释 (1/5)：代理工程与意图显化

DEEP NOTES: AGENTIC ENGINEERING & MANIFEST

01 · Agentic Engineering 与 Vibe Coding 的关系

Vibe Coding 是 Karpathy 在 2025 年初提出的概念，强调凭感觉调度 AI，靠直觉迭代。但它很容易被误解为「不负责任地让 AI 写代码」。Agentic Engineering 是它的进阶和系统化版本：同样放弃对每行代码的精确控制，但增加了任务分解、并行调度、检查点设置、结果审查等工程化流程。前者是理念，后者是方法论。

02 · 为什么「显化意图」比「写代码」更难

Manifest Intent 听上去像是降低了门槛——只要说出你想要什么就行。但精确地描述意图实际上比写代码更难。写代码时，编译器和测试会告诉你哪里错了。但描述意图时，模糊和遗漏不会立即报错——它们会在代理执行的过程中静默地放大，变成最终产出中难以追溯的偏差。精确的意图表达要求你真正理解问题本身，而非仅仅掌握实现方法。

03 · 80/20 Flip 的隐含前提

80/20 Flip 并不意味着「你可以不懂代码」。恰恰相反——你必须有足够深的技术理解才能有效审查代理的产出。如果你不理解代理生成的代码在做什么，你就无法判断它是否正确、安全、高效。80% 委托的前提恰恰是你有能力做好那关键的 20% 审查。这类似于管理者悖论：你越是能亲手做好一件事，你就越能有效地委托它。

04 · 工具选择：Cursor vs Claude Code vs Codex CLI

Cursor 适合低延迟、单文件的交互式编辑，是日常开发的主力。Claude Code 适合需要跨文件理解和复杂推理的任务——它能读懂整个项目结构。Codex CLI 更适合终端环境和自动化脚本集成。Karpathy 的关键提醒是：Claude Code 不要开 YOLO 模式（完全自主），随时准备按 ESC——这是锯齿性理论的实战应用。不同复杂度的任务需要匹配不同层级的工具。

原理注释 (2/5)：锯齿性与强化学习

DEEP NOTES: JAGGEDNESS & REINFORCEMENT LEARNING

05 · 锯齿性的根本原因

Jaggedness 不是简单的「模型还不够强」，而是当前训练方法的结构性限制。RL（强化学习）只能优化有明确验证信号的维度——代码能否编译通过、测试能否跑过。但更柔软的能力维度，比如「知道什么时候该停下来问人类」「知道某段代码虽然能跑但设计有问题」，这些没有清晰的奖励信号，RL 根本优化不了。这导致模型在可验证维度上突飞猛进，在不可验证维度上停滞不前——形成了锯齿状的能力曲线。

06 · Compounding Errors 的危险性

Compounding Errors（复合误差）是代理工程中最危险的陷阱。当代理在锯齿低谷处犯了一个小错，如果没有被及时捕获，这个错误会在后续步骤中被放大——后续代码建立在错误的基础上，测试可能恰好绕过了这个问题，最终形成一个表面上看起来正常但内部逻辑有致命缺陷的系统。设置 Checkpoints 的核心目的就是在复合误差扩散之前拦截它。

07 · 前沿模型的锯齿与开源模型的平滑

有趣的是，前沿模型的锯齿性往往比开源模型更明显。前沿模型在能力高峰上远超开源模型，但在低谷处有时也更离谱。这可能与 RL 训练的激进程度有关——更多的强化学习在可验证维度上推得更高，但也可能在不可验证维度上引入更大的扭曲。开源模型因为 RL 训练相对保守，能力曲线反而更平滑——虽然天花板较低，但地板也更高。

08 · Checkpoint 的最佳实践

设置 Checkpoints 不是每一步都检查（太慢），也不是完全不检查（太危险）。好的检查点策略是：在已知的锯齿低谷精准插入。具体来说，在安全相关代码、并发逻辑、边界条件处理、数据持久化操作这些领域，模型出错的概率显著高于平均水平，必须设置人工审查。而在模板代码生成、API 调用封装、测试用例编写这些模型擅长的领域，可以放手让代理自主完成。

原理注释 (3/5)：自动研究与超参搜索

DEEP NOTES: AUTORESEARCH & HYPERPARAMETERS

09 · Weight Decay 为什么在 Value Embedding 上是错误的

Weight Decay（权重衰减）的标准做法是对所有可训练参数施加 L2 正则化，防止过拟合。但 AutoResearch 发现，value embedding 的参数不应该被衰减——对它施加正则化实际上抑制了模型对注意力值的表达能力。这类似于给钢琴家的手指戴上手套——看似保护，实则限制了精细控制。这种细微差异恰恰是人类直觉难以发现的，因为默认设置「通常够好」的惯性太强了。

10 · Adam beta 参数的耦合效应

Adam 优化器的 beta1 控制一阶动量的衰减率，beta2 控制二阶动量的衰减率。几乎所有从业者使用默认值 beta1=0.9, beta2=0.999，这已经成了行业惯例。但 AutoResearch 发现更优的组合——而且关键在于，beta 参数和 Weight Decay 之间存在耦合关系，必须同时调整才能看到效果。单独调任何一个参数都不会显著改善。这种多维联合搜索正是人类直觉的盲区——我们习惯于一次只调一个旋钮。

11 · Hyperparameter Search 的终结

Karpathy 的判断非常明确：人类不应该再做 Hyperparameter Search 了。他给出的配方是四步法——定义目标函数、建立可自动验证的指标、划定搜索空间的边界、然后把自己从流程中彻底移除。这本质上是 Agentic Engineering 思想在深度学习研究中的直接应用：只要任务有可验证的输出指标，就应该交给代理。

12 · NanoGPT 作为试验场

NanoGPT 是 Karpathy 开发的极简 GPT 实现，代码量极小但功能完整。它是 AutoResearch 实验的理想试验场——足够小以便快速迭代，又足够真实以产生有意义的结论。AutoResearch 在 NanoGPT 上发现的参数问题后来被验证在更大规模模型上同样成立，说明这些发现具有普适性而非特定于小模型的巧合。

原理注释 (4/5)：吞吐量与并行化

DEEP NOTES: THROUGHPUT & PARALLELIZATION

13 · GPU 饱和率思维的类比

Token Throughput 的概念直接来源于 GPU 集群管理。在 GPU 集群中，空闲的显卡是浪费——每分钟的闲置都是真金白银的损失。Karpathy 把同样的思维模式应用到 AI 订阅上：你每月付费的 token 额度如果没用完，等于算力在空转。但这不是说要无意义地消耗 token，而是说你应该把判断力并行化——同时调度多个代理处理不同任务，让你的 token 持续产生价值。

14 · 从串行执行者到并行审查者

Parallelization 在 Karpathy 的语境中指的不是技术层面的并行计算，而是人类角色的转变。传统程序员的工作流是线性的：写函数 → 测试 → 调试 → 下一个函数。但在代理工程时代，你应该同时启动多条工作流：一个代理重构模块 A，一个代理给模块 B 写测试，一个代理做代码审查。你的角色变成了在多条流之间快速切换、做出宏观判断的调度者。人类的独特价值在于能对多条并行线同时保持全局视野。

15 · 人类判断力的带宽限制

并行化有一个天然上限——人类的判断力带宽。你不可能同时深入审查 20 个代理的产出。关键在于找到最佳并行度：足够多以最大化 Token Throughput，又不至于多到审查质量下降。Karpathy 没有给出具体数字，但隐含的建议是：从 2-3 个并行代理开始，逐步找到自己的舒适区。瓶颈从「代理的速度」转移到了「你切换上下文和做判断的速度」。

16 · Tailscale 在代理工作流中的角色

Tailscale 是零配置 VPN 方案，让多个开发环境可以安全互联。在多代理并行工作流中，不同代理可能需要访问不同的内部服务和开发环境。Tailscale 的零配置特性让网络连接不再成为并行化的障碍——不需要复杂的网络设置，代理就能安全访问所需的资源。这是「减少阻力以最大化吞吐」思想的基础设施层体现。

原理注释 (5/5)：悖论、架构与人格

DEEP NOTES: JEVONS, API-FIRST & PERSONA

17 · Jevons Paradox 的经济学机制

Jevons Paradox 的底层机制是：效率提升降低了边际成本，低于阈值的需求因此被激活。在软件领域，大量潜在需求一直存在但因开发成本过高而被搁置——每家公司都有想做但不值得做的内部工具、每个团队都有想自动化但成本不合算的流程。当 AI 把代码生产成本压低一个数量级，这些「冰面以下」的需求全部浮出水面。这就是为什么更便宜的代码不会减少程序员——它创造了更多的需求。

18 · API-first 的深层含义

API-first Architecture 在代理时代有了新的维度。传统的 API-first 是为了前后端分离和移动端适配。但现在 API-first 的首要用户是 AI agent——代理通过 API 消费你的服务，自动处理错误，自动编排多步骤流程。Karpathy 用 Dobby 的例子说明：6 个独立 App 被一个通过 WhatsApp API 对话的代理取代。这暗示了一个方向——GUI 可能会逐渐让位于代理驱动的接口层。

19 · 人格作为产品决策

Calibrated Feedback 不只是「礼貌」——它是一种信息传递机制。当代理说「我对这个方案有高置信度，但存在 X 风险」时，它在传递不确定性信息，帮你做更好的决策。Claude 的这种风格让你更愿意委托复杂任务，因为你相信代理会在不确定的地方主动告知。Codex 的平淡输出缺少这层信息，你只能通过自己审查代码来判断质量——这增加了审查成本，降低了 Token Throughput。

20 · 前沿模型生态的竞合格局

GPT-5、Claude、Codex Mini 等不同模型在 Karpathy 的工具栈中各有定位。The AI Corner 的分析指出，模型选择不应基于「哪个最强」，而应基于任务匹配：小而快的模型用于行内补全，大而深的模型用于复杂推理和多文件操作。这进一步呼应了分级工具栈的理念——没有万能模型，只有最适合当前任务的模型。

读者讨论精选

READER DISCUSSION HIGHLIGHTS

本页要点原文评论区的三个核心话题：对「显化」这个新动词的认同、锯齿性被认为是「最被低估的观点」、以及对 Jevons Paradox 的质疑——AI 生成的大量软件可能是一次性的。

关于「Manifest」

多位读者表示「显化意图」这个说法精准地描述了他们已经在经历但无法命名的变化。一位资深工程师评论说，他现在每天 80% 的时间确实在「表达意图」——写 prompt、分解任务、审查产出——而不是在写代码。这个命名帮助他向团队解释了为什么他的 Git 提交量下降了但产出反而增加了。

锯齿性：最被低估的观点

不少评论者认为 Jaggedness 是整篇文章中最被低估的洞察。大多数 AI 讨论要么是「AI 无所不能」，要么是「AI 还很蠢」。Karpathy 的锯齿理论指出了一个更精确的现实：AI 在同一次对话中可以是天才也可以是白痴——关键是你能否预测它会在哪些地方失误。

对 Jevons Paradox 的质疑

部分读者对 Jevons Paradox 的适用性提出质疑：新增的软件需求可能大部分是一次性的——用完就扔的脚本、临时的内部工具、短命的原型。这些「一次性代码」确实增加了代码总量，但未必创造持续的维护和迭代工作。也就是说，Jevons Paradox 在量上成立，但在质上可能需要更细致的区分。

关键洞察回顾

80/20 Flip：从写 80% 代码到委托 80% 给代理——工作流根本性翻转
Manifest Intent：新动词不是「编码」，而是「显化意图」
Jaggedness：博士与 10 岁并存——RL 只优化可验证指标
AutoResearch：发现 Weight Decay + Adam beta 的耦合错误，超越 20 年直觉
Token Throughput：空闲 token = 你才是瓶颈
API-first Architecture：Dobby 代理替代 6 个 App，API 先于 GUI
代理人格：Calibrated Feedback 让代理从工具变成思考伙伴
Decision Framework：做不了/做得行/做得比你好——三层分类
Jevons Paradox：更便宜 → 更多需求 → 更多工作
开源模型：类比 Linux，滞后 6-8 月但提供基础设施级可靠性

本文涵盖 50 个术语注释 + 20 条原理过程解析。点击任何虚线术语查看详细解释。

来源：The AI Corner 分析 + Karpathy 博客 · 2026.03

下期再见 👋

Karpathy 的 AI 工作流革命从写代码到调度代理 📖 注释版

关键洞察回顾

Karpathy 的 AI 工作流革命
从写代码到调度代理 📖 注释版