原文：https://mp.weixin.qq.com/s/_XE1U9_XsmWjA8eSiZw64A
一、转变不是工具替换，是工作模型的替换
很多人理解"用 Agent 工作"的方式是这样的：
以前我用 IDE 写代码，现在我用 Cursor 或者 Claude 写代码，工具换了，工作方式没变。
Karpathy 的经验告诉我们，这个理解是错的。
他在 2025 年描述自己工作状态转变的时候，说的不是"我换了一个更好的编辑器"。他说的是他整个工作模型变了——他思考一个任务时的第一个问题，从"我怎么实现这个"变成了"我怎么让 Agent 可靠地完成这个"。
这两个问题，需要完全不同的技能。
第一个问题需要的是：编程能力、算法知识、对框架的熟悉度。
第二个问题需要的是：任务分解能力、上下文设计能力、对 Agent 失败模式的判断、对结果的评估能力。
后者不是前者的升级版，是一套不同的技能。
Karpathy 的转变之所以值得研究，不是因为他"变懒了"，是因为他在这个转变里形成了一套可以被描述的工作方法。这篇文章试图把这套方法还原成普通工程师可以操作的步骤。
二、先丢掉三个旧习惯
转变首先不是建立新习惯，而是识别并丢掉三个在 Agent 工作模式里会造成麻烦的旧习惯。
旧习惯一：拿到任务就开始写（或者让 Agent 开始写）
传统编程的工作流是：理解需求 → 开始写代码 → 遇到问题再回头调整。
这个流程在 Agent 工作模式里是有代价的：Agent 一旦开始执行，它会基于初始的理解一路往前走。如果初始理解有偏差，Agent 不会自己停下来重新想，它会在错误的方向上越走越远，用你一路花出去的 Token 和时间，给你一个需要从头来过的结果。
Karpathy 的替代习惯：在 Agent 开始执行之前，先把任务想清楚。不是想"我怎么实现"，是想"Agent 做这件事，最关键的判断点在哪里，在那个点上它可能需要哪些信息"。
旧习惯二：出了问题就改 Prompt
Agent 给出了一个不对的结果，第一反应是"我的 Prompt 哪里没写好"，然后反复调整 Prompt，期待找到那个"魔法公式"。
正如上一篇讲的，Prompt 是表层，上下文是根本。反复调 Prompt 而不检查上下文，是在用错误的工具解决问题——有时候碰巧有效，但不可靠，也不可复现。
Karpathy 的替代习惯：Agent 出错，第一步不是改 Prompt，是问"它在出错的那个步骤，上下文里有什么，缺少什么"。找到信息缺口，解决信息问题，而不是解决 Prompt 措辞问题。
旧习惯三：相信 Agent 的输出，除非明显出错
代码运行不报错、格式看起来对、内容读起来通顺——所以就直接用了。
这个习惯在传统代码里勉强说得过去（代码运行正确通常意味着逻辑正确），但在 Agent 输出里是危险的。
Agent 非常擅长生成"看起来对"的东西——格式正确、语气合适、逻辑流畅，但内容在关键细节上是错的。这种错误不报警，不抛异常，安静地存在于输出里，等着你或者你的用户踩到它。
Karpathy 的替代习惯：建立验证流程。不是"除非明显出错就相信"，是"在关键节点主动验证"。验证不是把所有输出都读一遍，是设计检查点：哪些步骤的输出是高风险的，哪些是低风险的，对高风险的步骤用什么方式验证。
三、建立四个新判断
丢掉旧习惯之后，需要建立四个在 Agent 工作模式里最关键的新判断能力。
判断一：这个任务适合交给 Agent 吗
不是所有任务都适合 Agent。Karpathy 自己的经验是，他会在把任务交给 Agent 之前，先做一个快速判断：
适合 Agent 的任务特征：
步骤清晰，可以分解，每一步有明确的完成标准
结果可以验证，你知道"对"是什么样子
即使出错，代价是可控的（可以回滚，可以重做，不会造成不可逆的影响）
任务重复度高，你以前做过类似的，知道坑在哪里
不适合 Agent 的任务特征：
需要大量隐性判断，很难显式描述"什么是好的结果"
出错代价高，一旦 Agent 做错，修复成本远超重做成本
高度依赖当前状态和实时信息，而这些信息你没有办法系统性地放进上下文
任务的边界不清楚，你自己也不确定最终要什么
这个判断不需要精确，但需要成为一个反射动作。拿到任务，第一步先做这个评估。
判断二：任务的关键节点在哪里
一个复杂任务里，不是所有步骤同等重要。有些步骤出错，Agent 可以自己恢复；有些步骤出错，整个任务就跑偏了。
Karpathy 的做法是在任务开始前，识别出 2-3 个关键节点——那些如果判断错误会导致后续所有步骤都错的地方。
然后在这些节点上：要么提前在上下文里提供更充分的信息，要么设置人工确认点（Agent 执行到这里，先暂停，等你确认再继续）。
判断三：验证点应该设在哪里
不是"输出来了之后全部检查"，是"在任务执行过程中，在哪些点上插入验证"。
对于一个十步的 Agent 任务，如果你在第十步才看结果，发现第三步就跑偏了，你浪费了七步的 Token 和时间，还得从头来过。
更有效的方式：在第三步之后设一个检查点，确认 Agent 的理解和你的预期是对的，然后再继续。
这个检查点不需要很多——通常一个复杂任务里有 2-3 个就够了。关键是把它设在"如果这里错了，后面全白做"的位置上。
判断四：这个输出，我需要验证什么
不是把所有输出都精读一遍，是知道"在这个输出里，什么地方最可能出错，我需要重点检查什么"。
对于代码输出：不只看代码能不能跑，还要看逻辑是否覆盖了边缘情况，是否处理了错误，是否和你的系统其他部分兼容。
对于文本输出：不只看格式和语气，还要核对关键数据和判断，特别是那些 Agent 只能从上下文里"推断"而不是直接拿到的信息。
对于决策输出（Agent 给出了一个建议或者方案）：检查它的推理链，不只是结论，还要看它是怎么得出这个结论的，推理链里有没有你知道是错的前提。
四、一个具体的工作流
把上面的判断整合成一个可以操作的工作流。
这不是 Karpathy 公开说过的某个固定流程——是基于他描述的工作方式，整合出来的一个实践框架。
Step 0：任务评估（2 分钟）└── 这个任务适合 Agent 吗？└── 如果适合，关键节点在哪里？Step 1：上下文准备（5-15 分钟，取决于任务复杂度）└── Agent 做出正确判断，最少需要知道什么？└── 目前的上下文里有多少？└── 缺少的部分，怎么补充？└── 我的指令里有没有潜在矛盾？Step 2：设置检查点（1 分钟）└── 在哪 2-3 个步骤上需要人工确认？└── 在这些步骤上，我期待看到什么样的中间结果？Step 3：让 Agent 执行└── 在检查点上暂停，确认方向└── 确认后继续Step 4：验证输出└── 这个输出里，什么地方最可能出错？└── 针对性地检查这些地方└── 不是精读，是有重点地核查Step 5：记录失败模式（长期积累）└── 这次 Agent 在哪里出了问题？└── 是信息缺口、信息过载、还是指令矛盾？└── 下次同类任务，上下文怎么改？
Step 5 是最容易被跳过、但长期价值最大的一步。
Karpathy 有一个习惯：他会记录 Agent 出错的模式，而不只是修复单次的错误。因为同一类任务里，Agent 的失败模式往往是重复的——如果你理解了失败的原因，你可以在上下文设计层面修复它，让同类任务的成功率系统性地提升。
五、关于"什么时候该自己动手"
这是最容易被忽略、但 Karpathy 讲得最清楚的一点：
编排 Agent 不是把所有事情都交出去。
他自己的工作方式里，有一些事情他始终自己做：
定义问题：任务的真正目标是什么，成功的标准是什么。这是 Agent 无法替代你做的——因为它不知道你的上下文、你的约束、你的优先级。
最终判断：特别是那些涉及方向性选择的决策。Agent 可以给你选项和分析，但"选哪个"通常应该是你来做。
异常处理：当 Agent 遇到它显然处理不了的情况，或者它的输出你有明确的直觉"感觉不对但说不清楚哪里不对"——这时候不要强行让 Agent 继续，换成自己处理或者重新设计任务。
这三件事，不是因为 Agent 能力不够才自己做，是因为这三件事本来就是"判断者"的工作，不是"执行者"的工作。
而你在 Agent 工作模式里，扮演的角色是判断者。
六、第一周怎么开始
如果你现在想开始这个转变，不需要一次性改变所有工作习惯。Karpathy 自己的转变也是渐进的。
一个相对稳妥的第一周方案：
第一天：用 Agent 做一件你以前自己做的重复性任务
不是最重要的任务，是你做过很多次、知道"对"是什么样子的任务。这样你能快速判断 Agent 的输出是否可信。
第二天：有意识地在任务开始前准备上下文
不是想"我的 Prompt 怎么写"，是想"Agent 需要知道什么才能做对这件事"。把缺少的信息主动补充进去。
第三天：在一个任务里设置一个检查点
让 Agent 执行到某个中间步骤，停下来，你确认方向对了再继续。感受一下这个"暂停确认"的节奏。
第四天：认真做一次验证
不是扫一眼，是针对"最可能出错的地方"做有重点的核查。记录下你发现了什么。
第五天：回顾这一周
Agent 在哪里出了问题？是信息缺口，信息过载，还是指令矛盾？下周同类任务，你会改什么？
五天之后，你不会完成转变，但你会对"编排 Agent 和写代码有什么不同"有一个具身的感受——这个感受，比读任何文章都更有价值。
