我最近看了 Austin Marchese 解读 Karpathy 在 AISN 2026 上的发言，被里面一个反常识的小例子卡住了：你问 AI “我去 50 米外的洗车店该开车还是走路”，Claude、Gemini、Grok、ChatGPT 全都回答”走路”。四个顶级模型答得整整齐齐：它们都没意识到，去洗车这件事本身要求车必须在场。Marchese 把 Karpathy 的工作方式拆成三层 —— spec、verifier、environment，每一层都在补这种”看似有智力却没上下文”的缺口。框架本身短，但放大了我用 Claude Code 一年多攒下的不少踩坑。
原视频：Stop Prompting Claude. Use Karpathy’s Method Instead.
洗车这道题，AI 卡在哪里
Karpathy 在演讲里给的那个洗车场景，可以当全文的锚点。模型在做数学、写代码这类有标准答案的事情上很猛，因为它们能反复试错、试错近乎零成本，机器能自动判分。但”去洗车”这种场景里它瞬间露馅，因为里面有一个对人类不言自明、模型从输入里读不出来的前提：你得把车开过去。AI 不是缺智力，是缺这种由你的目标、你的上下文反推出来的隐含意图。
Marchese 把整个三层方法的合法性建立在这道题上：你想让 AI 真正干活，得先把这些隐含意图喂进去；然后让它能自己看出对不对；最后让它身处一个本身就装着你所有上下文的环境。spec 干第一件事，verifier 干第二件，environment 干第三件。
第一层 spec：把你脑子里的东西落到 AI 能用的格式
Karpathy 的原话很值得抄一遍：他甚至不太喜欢 Claude 的 plan mode，理由是”too high-level”，他要的是和 agent 一起设计一份非常具体的 spec。Marchese 把这一层拆成了三个动作。
第一个动作是挖出真正的目标。”做一份月底报告”只是任务的外壳；真正的目标在更下一层——这份报告要支撑哪个决策、要让谁得到哪个结论。决策这一层 AI 没法替你定，所以 Marchese 给的提示词把顺序倒过来了——让 AI 先反过来采访你：Interview me to identify the goal of this project. 把信息从你脑子里挖出来，再灌进 spec。
第二个动作是 agile specking。Marchese 直接对比 waterfall 和 agile：waterfall 是你把整个大任务交给 agent 一次性做完再看结果，agile 是把同一个任务切成小块，每块过一遍。绝大多数人用 AI agent 时不自觉地走 waterfall，”反正它能跑就让它一路跑”。但只要中间走偏一步，后面全废。所以他给 Claude 加的指令是”bias towards smaller and more compartmentalized specs”，让 spec 本身就长成易于检查的小颗粒。
第三个动作是动你自己的脑子。Marchese 的说法是”the more precise you are, the less AI has to assume”。每一处 AI 自己脑补的假设都是漂移点。所以让 AI 写 spec 时不能丢给它一个人就走开，要让它显式地把关键决策抛回来确认：Make me verify key decisions explicitly to ensure nothing is missed。这条指令的含义是把 AI 强行变成 spec 的执行者，把判断权留在你这里。
三个动作合起来产出一份很细的 spec，然后才让 AI 按 spec 干活。这一层的核心思想其实只有一句话：把你自己对项目的理解，编码成 AI 能读懂的格式。
第二层 verifier：让 AI 自己看出它做错了没
第二层是这套方法里我个人觉得最值钱的一层。Karpathy 在视频里说得很直接：”Validation is what fundamentally scales AI.”——能不能 scale，看的不是 generation 速度，是 validation 速度。换种说法，瓶颈从来不在 AI 生不生得出来代码，而在你能不能足够快地知道它对不对。
Marchese 把 verifier 拆成了三种具体形态。
第一种是 automated tests。最简单的玩法是写一个 build_passing.sh，让 Claude 跑测试、自己看输出、改代码、再跑，直到全绿才停。这一步把”判分”这件事完全交给确定性的工具，避免让 AI 自己评估自己。
第二种是 assertions。在代码里硬塞 invariant 检查，比如”输入金额不能为负”、”返回字段必须包含 X”。让程序自己在运行时崩出来，而不是等到 review 才发现。
第三种是 LLM as judge。当你要验证的东西没法写成确定性测试（比如生成内容质量、自然语言一致性），就让另一个 AI 当评委。Marchese 强调这种验证方式适合 fuzzy 的场景，不能滥用——能用确定性测试解决的就别拿 LLM 来打分。
这三种形态合起来是一个梯度。能用确定性测试解决的就别拿 LLM 来打分，因为成本和稳定性差一个数量级。assertion 是中间地带，LLM judge 是最贵也最不稳的兜底。
Karpathy 在视频里还顺手把”tight leash”这件事讲了：他对那些放飞的 agent 玩法相当保守，更喜欢小步增量改动，每步都验证。这个姿态背后是个朴素的道理——你只敢放出多长的绳子，取决于你的验证回路有多快。
第三层 environment：spec 是单次的，环境是长期的
前两层都是单次任务的优化，第三层处理的是跨任务的、长期资产层面的。这层是 Karpathy 真正在意的工程化部分，Marchese 把它拆成四块。
第一块是 claude.md。这是项目根目录的一份文档，Claude Code 每次启动都会自动加载。Marchese 把它形容成”AI 进入项目时读的开篇宣言”。里面写什么？他给的清单是：项目是关于什么的（这样 AI 一开始就不会跑偏）、它能用的工具和文件、训练数据/知识架构在哪、必须遵守的关键工作规则。要点是把这里当成 AI 的世界，不是反过来把它塞进你的世界。
第二块是 LLM knowledge base。Karpathy 在推特上火过一阵的概念，做法非常朴素：在你机器上建一个文件夹结构，把你自己的训练数据、笔记、上下文喂进去，让 Claude 在需要时知道去哪查。Marchese 这里有句话我很认同：你的数据是你的护城河。这是建立你自己的知识资产的起点。
第三块是 skills。Marchese 给的判断准则极简：任何你打算重复做超过一次的事，写成 skill。skill 是完成某个任务的”使用手册”，越用越准。他用了个挺好的比喻——”找出水管漏点的最好办法，就是让水流过它”。skill 也是一样，用得多了你才知道哪里要补哪里已经够好。这种说法跟我用 Claude Code 半年多的实感完全对得上：我的 skills 目录是一点点用出来的，从没有哪个是预先想清楚一次写完的。
第四块是 guardrails。这一块 Marchese 讲得最细。claude.md 里写”别瞎编信息”只是一条 guide，Claude 仍然能违反它。如果有些事情绝对不能错，就得在工具层加 hook。他举了个具体例子：你有一个叫 Important, Don't Edit 的文件夹，光在 claude.md 里写”别动这个文件夹”只能拿到 80% 效果，因为这种写法本质是请求。真正可靠的做法是加一个 pre-tool-use hook，在 Claude 调用 write/edit 工具前先看目标路径，命中黑名单直接拦下。约束在工具层就锁死，Claude 想违反也违反不了。
Marchese 顺着这个思路给了一个分桶法：把所有动作分成 always do（autopilot）、ask first（双重确认）、never do（红线）。always do 是你信得过让 AI 一路跑的事，ask first 是有风险要你点头的事，never do 是工具层就得卡死的事。这个分桶法的好处是你只需要决定每个动作落在哪个桶，剩下的由 claude.md + hook 自动落地。
“The one thing”：理解不可外包
视频结尾抛了个问题：智能变得很便宜的时代，还有什么是值得深学的？
Karpathy 的回答只有一句：You can outsource your thinking, but you can’t outsource your understanding.
Marchese 把这句话和前面三层串起来：spec、verifier、environment 全都在围绕你对全局的理解打转。AI 可以替你思考，但目标由你定，验证标准由你设，规则边界由你画。这些底层的理解抽掉，三层就成了空壳。
这层意思在 Karpathy 几年前提过的另一个判断里其实也出现过：AI 时代真正的护城河从手写 if/else 迁移到了定义系统——设计赛道、设定成功标准、画约束条件。代码本身正在变成耗材，能不能定义清楚问题，才是没法被模型替代的那部分能力。
我的补充：三层不等权，verifier 最不会贬值
视频把三层讲得像是等权的并列结构，但我自己的判断是：三层的重要性会随模型变强而漂移，verifier 是其中唯一不贬值的一层。
spec 和 environment 里有相当一部分内容，本质上是在补当下模型的短板：模型记不住长上下文，所以你需要在 claude.md 里写一遍背景；模型不会自己挑工具，所以你要在 environment 里铺好路径；模型容易脑补，所以你要在 spec 里抠掉每一处假设。下一代模型如果在这些方面变强，这些补丁就会变成多余的脚手架。Anthropic 自己在大型代码库实践里给过同样的提醒：harness 配置每 3-6 个月要审一次，旧版本里防御性的 hook 在缺陷消失后是负担。
verifier 完全不一样。模型越强、生成越快，验证只会越重要，而不是越不重要。原因很直白：你怎么知道一个比你聪明的东西做对了？除了可执行、可观测的验证回路没别的办法。任何一代模型升级都抹不掉这一层，反而每一次模型变强都让它更值钱。
换个角度说，三层框架里我会优先投资的顺序是 verifier > spec > environment，恰好和视频呈现的视觉权重相反。spec 和 environment 是”让今天这一代模型好用”，verifier 是”让任何一代模型都好用”。
怎么落到日常
视频里 Marchese 给的每一条都能直接搬到 Claude Code 的日常工作流里，三层各对应一个我会立刻动手的事情。
spec 层：给一个新需求时，别一上来就让 Claude 写代码，第一句让它反过来采访我，把目标、约束、验收标准全部问出来落进一份 spec，再让它分块实现。
verifier 层：每个项目根目录放一个最小的 build_passing.sh，能跑测试就跑测试，能跑 lint 就跑 lint，让 Claude 自己看 exit code，红了就改，不要让我成为它的判分器。
environment 层：claude.md 写薄一些，重点放在”这个项目是什么 / 文件结构 / 哪些路径绝对别动”；重复 ≥3 次的流程立刻 sink 成 skill；红线规则一定走 hook，不要只写在 markdown 里指望模型自觉。
这是这套方法对我最直接的产出：把”和 AI 协作”这件事从靠经验调 prompt，变成了一个能审计、能迭代、能版本化的系统。
剩下的就是让水流过去。
评论前必须登录！
立即登录 注册