Karpathy 说他几乎不写代码了
Andrej Karpathy 最近接受了一次播客采访，说了一句让很多工程师不舒服的话：自去年 12 月起，他已经几乎不亲手写一行代码了。
不是偶尔用 Copilot 补个函数，而是真的把编程工作「外包」给了 AI Agent。他形容自己处于一种「AI 精神病」（AI psychosis）的状态——持续痴迷于探索智能体的能力边界，不断思考如何并行调度多个 Agent，最大化自己的「token 吞吐量」。
他给出的那个判断很有意思：以前工程师的瓶颈是算力（flops），现在变成了你自己的 token 吞吐量。
这句话值得停下来想一想。它不是在说「AI 会取代程序员」，而是在说工程师的生产力模型已经发生了结构性变化——你能产出多少，取决于你能多高效地「指挥」AI、消化 AI 的输出、做出判断，而不是你自己打多少行字。
这个变化对大多数工程师的日常意味着什么？
「写代码」不再是核心技能，但也没消失
先说清楚一件事：断言「写代码不重要了」是另一个极端，同样错。
准确的说法是：**写代码从工程师的核心输出，变成了工程师的核心认知基础。**这两件事是不同的。
类比一下：一个优秀的架构师未必每天写代码，但如果他从没系统地写过代码、没有真实踩过坑，他大概率做不出好的架构判断。同样，一个能高效指挥 AI 完成复杂工程任务的工程师，需要对代码的「应该是什么样」有极强的感知，才能判断 AI 交付的东西对不对、好不好、够不够。
Karpathy 本人就是最好的反例证明——他之所以能「不写代码」却依然高效产出，正是因为他有超强的系统级编程认知，能在 AI 犯错时秒识别，能把复杂任务拆成 AI 可以可靠执行的子任务。
所以如果你现在是初级工程师，别被「AI 可以写代码」这个结论带偏，跳过扎实写代码的阶段。真正的风险是：没有代码认知打底，你对 AI 输出的判断力会很弱，变成一个只能在 AI 产出「看起来对」时无法辨别的人。
工作流正在被重构：三个真实的变化
1. 从「写代码」到「设计任务」
给 AI 写一个好的 prompt，和给初级工程师写一份好的任务说明，需要的能力高度重叠：你需要把问题拆解清楚，把约束条件说明白，把验收标准定义出来。
以前这个能力叫「软技能」，现在直接影响你的生产效率。一个能把任务描述清晰的工程师，交给 AI 的任务成功率远高于那种「你懂的，帮我写一下那个功能」的描述方式。
举个具体例子，同样是让 AI 实现一个接口：
// ❌ 低效描述
帮我写一个用户登录接口
// ✅ 高效描述
实现 POST /api/auth/login 接口：
- 参数：username(string, 非空), password(string, 非空)
- 用 bcrypt 校验密码，失败返回 401 + { code: "INVALID_CREDENTIALS" }
- 成功返回 JWT，过期时间 7 天，payload 包含 userId 和 role
- 接口需要限流：同一 IP 1 分钟内最多 5 次，超出返回 429
- 使用项目已有的 Express + Prisma 技术栈，不引入新依赖
第二种描述不是更复杂，而是更清晰。它能让 AI 第一次就输出接近预期的代码，省去反复沟通的成本。这个能力，本质上是工程能力的一部分——知道一个功能完整实现需要考虑哪些维度。
2. 「演示」取代「文档」，「评估」取代「规划」
Claude Code 的产品负责人 Cat Wu 分享了一个观察：在 AI 工具极大降低原型成本之后，她们团队已经不再写传统的立项文档了——直接做一个可运行的原型给大家看。
这个变化有内在逻辑。以前写文档是因为「做出来成本高」，你必须先论证清楚再动手。现在一个原型可能几小时就能跑起来，文档反而成了多余的中间层。
但随之而来的挑战是：如何评估 AI 交付的东西是否真的好用？
这就是「评估」（Evals）变成核心工程能力的原因。特别是对于那些没有明确对错的任务——比如 AI 生成的文本质量、多智能体协作的行为是否符合预期——你必须自己定义「好」的标准，并把它变成可量化的评估集。
写 Evals 是个很具体的技能，不是「开发完了测一下」，而是在开发前就把验收标准设计好：
// 一个简单的 LLM Eval 框架示例（Python）
import json
from dataclasses import dataclass
from typing import Callable, List
@dataclass
class EvalCase:
input: str
expected: str # 期望输出（可以是关键词/结构）
passing_criteria: str # 判断标准描述
def run_eval(
model_fn: Callable[[str], str],
cases: List[EvalCase],
judge_fn: Callable[[str, str, str], bool] # 裁判函数
) -> dict:
results = []
for case in cases:
actual = model_fn(case.input)
passed = judge_fn(actual, case.expected, case.passing_criteria)
results.append({
"input": case.input,
"actual": actual,
"passed": passed
})
pass_rate = sum(r["passed"] for r in results) / len(results)
return {"pass_rate": pass_rate, "details": results}
# 裁判函数可以是规则，也可以是另一个 LLM
def llm_judge(actual: str, expected: str, criteria: str) -> bool:
prompt = f"""
判断以下输出是否满足标准（只回答 yes 或 no）：
标准：{criteria}
期望参考：{expected}
实际输出：{actual}
"""
# 调用你的 LLM API
return call_llm(prompt).strip().lower() == "yes"
这不是什么新概念，ML 工程师早就在做这件事。但现在，做应用层开发的工程师也必须具备这个思维：对 AI 行为的验收，需要和功能开发同等优先级，而不是事后补的测试用例。
3. 「保持简单」变成了一条工程原则
Cat Wu 提到了一个很有意思的现象：早期为了让 AI 可靠地维护一个待办列表，她们需要写很长的系统提示词来做各种边界处理。但随着模型升级到 Opus 4.6，这些复杂的 prompt 工程直接变成了冗余——新模型原生就能理解意图，系统提示词减少了 20%。
这背后有一条反直觉的工程原则：针对当前模型局限性所做的复杂 hack，很快会变成负债。
模型能力在以你意想不到的速度提升。16 个月，41 倍的性能跨越。如果你今天花了大量工程精力去绕过 AI 的某个弱点，六个月后模型更新把这个弱点修掉了，你的绕路代码就成了「技术债」。
📌 这不是说不要做工程优化，而是说：优先解决那些跟模型能力无关的工程问题（延迟、成本、稳定性、安全），把那些「因为模型还不够聪明」而加的复杂逻辑控制在最小范围，并打好标记，方便以后清理。
「Token 吞吐量」是个好的思维框架
重新回到 Karpathy 的那个比喻。他说工程师的瓶颈从「算力」变成了「自身 token 吞吐量」。
这个框架值得认真对待。展开来说：
• 输入端：你每天能有效处理多少来自 AI 的输出？ 很多人和 AI 协作效率低，不是因为 AI 生成得慢，而是因为他们审查、判断、整合 AI 输出的速度跟不上。
• 吞吐端：你能同时跑多少并行任务？ 如果你擅长把大任务拆成互相独立的子任务，就可以同时开多个 AI 会话并行推进；如果你的任务设计是串行依赖的，AI 的速度优势就发挥不出来。
• 质量端：你对 AI 输出的判断准确吗？ 低质量的接受（把错误的输出当正确）和过度拒绝（对正确的输出也要从头重写）都是在浪费「吞吐量」。
具体来说，以下几种工作习惯可以直接提升「token 吞吐量」：
**把任务拆成可验证的单元。**每个给 AI 的任务，结果要可以快速验证：能跑通、有测试、输出格式固定。不要把「写整个模块」丢给 AI，而是「写这个函数，满足这个测试用例」。
**建立个人的 prompt 库。**类似代码库里的工具函数，常用的任务模板沉淀下来，下次复用。一个好的 code review prompt、一个好的 debug 分析 prompt、一个好的文档撰写 prompt，分别能节省大量重复描述的时间。
**培养「快速 pass/fail 判断」能力。**AI 的输出不需要每行都看，你需要的是快速定位：关键逻辑对不对，边界处理有没有遗漏，结构是否符合项目约定。这是一种需要刻意练习的阅读代码的能力，和写代码不完全一样。
那些「不会被替代」的能力，正在被重新定义
每隔一段时间就会有人问：哪些工程师能力是 AI 替代不了的？
这个问题本身没问题，但容易把答案引向「找一个 AI 永远做不到的事情，然后去学」——这是一个防御性思维，效果往往不好，因为 AI 的能力边界在快速变动。
更有用的框架是：哪些能力在 AI 时代的价值被放大了？
从观察来看，有几类能力的「乘数效应」正在变大：
系统思维
AI 很擅长局部最优，不擅长全局一致性。一个有系统思维的工程师，能把一个复杂系统分解成清晰的模块边界，定义好接口契约，让 AI 在每个模块内部发挥；而一个没有系统思维的人，让 AI 写出来的东西往往是「各自为战」，合并起来一团乱麻。
系统设计能力的价值，在 AI 时代不是降低了，而是提高了。因为现在执行成本极低，设计的质量直接决定整体产出的质量。
领域判断力
Karpathy 有个比喻：跟 AI 协作就像「同时和两个人对话：一个是经验极其丰富的系统程序员，另一个是个十岁的孩子」。AI 在可验证、有明确指标的任务上表现超凡，但在需要领域经验判断的地方频繁失足——它不知道某个设计决策在你们团队的历史背景下意味着什么，不知道这个库虽然在 GitHub 上有很多 star 但在生产环境里有个坑，不知道你们的用户群体对延迟的容忍度比通常情况低很多。
这种领域判断力，只能从真实的工程实践中积累，没有捷径。
沟通与对齐
这件事有点反直觉。AI 帮你写了代码、写了文档，但跨团队对齐、拉通需求、解决分歧这些事情，仍然需要人来做，而且重要性在上升——因为 AI 让每个人的执行速度都变快了，如果方向不一致，偏差也会被快速放大。
一个能把复杂技术问题讲清楚、能高效推动跨团队决策的工程师，在 AI 时代的价值被进一步放大了。
一个我还没想清楚的问题
说实话，有一件事我还没有判断清楚：
当 AI 可以帮你快速做出原型和验证，工程师还需要对某个技术栈「精通」吗？
一方面，「懂得刚好够用」+「会使用 AI 补全细节」的组合，似乎已经能应对大多数日常开发场景。那种「某某语言专家」的价值是不是在稀释？
另一方面，当你真的遇到一个深坑——某个奇怪的性能问题、某个只有在特定并发下才复现的 bug、某个框架的限制在架构层面需要绕开——这时候精通某一个技术栈的人，和只会「差不多懂」的人，产出的差距依然巨大。AI 能给你方向，但你得有能力辨别哪个方向是对的。
也许答案是：不再需要「广而深」，而是需要「选一个领域真的深，其他的用 AI 补宽」。T 型能力的那个竖杠，仍然需要，但横杠的获取方式变了。
这只是我现在的暂定判断，可能半年后会被证伪。
真正值得做的事情
扯了这么多，落地到个人层面，有几件真实有用的事情：
• **把 AI 协作纳入日常工作流，而不是「需要的时候才用」。**就像 Git 已经是工程师的默认工具一样，AI 辅助开发也应该是默认状态，而不是偶尔拿出来用的「新奇工具」。
• **主动积累「指挥 AI」的肌肉记忆。**花时间总结哪类任务给 AI 效果好、哪类容易翻车、哪类描述方式返回结果更准——这是可以积累和复用的经验。
• **不要停止真实的工程实践。**不是说要「拒绝 AI 帮助」，而是确保自己仍然在有实质深度的工程问题上动脑筋，而不是全程让 AI 代劳。判断力需要真实的摩擦才能打磨出来。
• **持续关注 AI 工具本身的演进，但不要被新工具的噪音淹没。**选一两个主力工具（比如 Claude Code、Cursor）用深用透，比每周试一个新工具更有价值。
Karpathy 说过一件事，他把自己的 AutoResearch 系统跑了一晚上，发现它找到了他手动优化很久的代码库里从未发现的改进点。他不是在炫耀 AI 有多强，而是在说：把 AI 放进你的工作流，你能到达的地方比单打独斗要远得多。
这个判断，我是认同的。
如果这篇文章对你有用，欢迎转发给同行。下一个方向可能值得探索：当工程师的瓶颈从代码变成「任务设计能力」，工程师的晋升标准会怎么变？这个问题在很多团队还没有答案。
