工程师职业瓶颈已非代码能力

Karpathy 说他几乎不写代码了

Andrej Karpathy 最近在一次播客采访里扔出了一枚“冲击波”——从去年 12 月起，他几乎就没亲手写过一行代码了。

注意，不是偶尔用 Copilot 补个函数，而是真的把编程这件事“外包”给了 AI Agent。他自己形容这是一种“AI 精神病”状态——持续痴迷于探索智能体的能力边界，脑子里想的全是如何并行调度多个 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 jsonfrom dataclasses import dataclassfrom typing import Callable, List@dataclassclass EvalCase:input: strexpected: 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}# 裁判函数可以是规则，也可以是另一个 LLMdef llm_judge(actual: str, expected: str, criteria: str) -> bool:prompt = f"""判断以下输出是否满足标准（只回答 yes 或 no）：标准：{criteria}期望参考：{expected}实际输出：{actual}"""# 调用你的 LLM APIreturn 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 上星星很多但在生产环境里有个坑，不知道你们的用户群体对延迟的容忍度比通常情况低很多。

这种领域判断力，只能从真实的工程实践中慢慢积累，没有捷径可走。

沟通与对齐

这事儿有点反直觉。AI 帮你写了代码、写了文档，但跨团队对齐、拉通需求、解决分歧这些事，仍然需要人来做，而且重要性在上升——因为 AI 让每个人的执行速度都变快了，如果方向不一致，偏差也会被快速放大。

一个能把复杂技术问题讲清楚、能高效推动跨团队决策的工程师，在 AI 时代的价值被进一步放大了。

一个尚未定论的问题

说实话，有一件事还没有完全想清楚：

当 AI 可以帮你快速做出原型和验证，工程师还需要对某个技术栈“精通”吗？

一方面，“懂得刚好够用”加上“会使用 AI 补全细节”的组合，似乎已经能应对大多数日常开发场景。那种“某某语言专家”的价值是不是在稀释？

但另一方面，当你真的遇到一个深坑——某个奇怪的性能问题、某个只有在特定并发下才复现的 bug、某个框架的限制需要在架构层面绕开——这时候精通某一技术栈的人和只会“差不多懂”的人，产出的差距依然巨大。AI 能给你方向，但你得有辨别哪个方向是对的能力。

这只是当前的一个暂定判断，可能半年后就会被证伪。

真正值得做的事情

说了这么多，落到个人层面，有几件真实有用的事：

• 把 AI 协作融入日常工作流，而不是“需要的时候才用”。就像 Git 已经是工程师的默认工具一样，AI 辅助开发也应该是默认状态，而不是偶尔拿出来的“新奇玩具”。

• 主动积累“指挥 AI”的肌肉记忆。花时间总结哪些任务给 AI 效果好、哪些容易翻车、哪种描述方式返回结果更准——这些都是可以积累和复用的实战经验。

• 不要停止真实的工程实践。不是说“拒绝 AI 帮助”，而是确保自己仍然在有实质深度的工程问题上动脑筋，而不是全程让 AI 代劳。判断力需要真实的摩擦才能打磨出来。

• 持续关注 AI 工具本身的演进，但别被新工具的噪音淹没。选一两个主力工具（比如 Claude Code、Cursor）用深用透，比每周试一个新工具更有价值。

Karpathy 还说过一件事，他把自己的 AutoResearch 系统跑了一晚上，发现它找到了他自己手动优化很久的代码库里从未发现过的改进点。他不是在炫耀 AI 有多强，而是在表达一个更深刻的观点：把 AI 放进你的工作流，你能到达的地方比单打独斗要远得多。

于我而言，这是个值得深信的判断。