很多团队用 LLM 的方式还停留在搜索引擎模式：输入一个问题，拿到一个回答，结束。模型本身的能力没有被充分释放，瓶颈不在模型，在交互架构。
Andrej Karpathy 的做法提供了一个不同的思路：不要在单条 prompt 上反复打磨，而是围绕模型搭一套工程结构。这套结构由三层组成——规格说明、草稿本、反馈闭环。核心判断是，prompt 质量在有了架构之后会变得几乎无关紧要。
第一层：规格说明（Spec）
多数人打开对话窗口就开始打字，结果是一轮又一轮的来回修正：上一条消息纠正下一条输出，消耗时间和 token 才慢慢收敛到本可以一次做对的结果。
规格说明改变了这个动态。你不是让模型通过迭代猜你要什么，而是在开始之前就把意图讲清楚：在做什么、为什么做、最终用户是谁、需要什么、成功的标准是什么、有哪些约束、什么不要碰。
这听起来比直接写 prompt 更费事，第一次确实如此。但 spec 是可复用的。每次会话开始时加载它，后续所有请求都在完整上下文中运行。花五分钟写 spec，能省掉项目过程中三十分钟的来回纠偏。
Karpathy 把 spec 当作活文档：模型产出内容、你调整方向后，同步更新 spec，让后续会话从改进后的版本开始。随着时间推移，spec 会积累成一份对意图的完整描述，这是任何单条 prompt 都做不到的。
第二层：草稿本（Scratchpad）
没有草稿本，模型的推理只存在于上下文窗口里。一旦开启新会话，或者上下文过长触发压缩，推理过程就丢了。模型会重新做出已经做过的决策，输出和早期选择矛盾的结果。
草稿本解决这个问题。模型持续写入：已完成什么、当前在决定什么、不确定什么、下一步是什么。会话结束后，草稿本把工作上下文带到下一次会话。
实现方式很简单：一个叫 scratchpad.md 的文件，在 spec 或上下文文件中加一行指令——"维护 scratchpad.md 作为推理和进度的运行日志。"
你得到的是透明度。你能看到模型为什么做了某个决策，这让纠偏更快更精准。不再是"这不是我要的，重试"，而是"我在草稿本里看到你假设了 X，正确假设应该是 Y"。修复是外科手术式的，不是猜测式的。
第三层：反馈闭环（Feedback Loop）
这是最重要也最被忽视的一层：一个结构化的反馈机制，让模型在特定任务上随时间变好。
多数人把每次会话当作独立事件。从头开始，拿到输出，用或不用，结束。会话结束，什么都不保留。下次需要同类输出时，重新来过。
Karpathy 的方法把会话视为持续改进循环的一部分。当输出不够好时，不要只在聊天里纠正。让模型识别输出为什么偏离目标，更新 spec 使该失败模式被描述并在未来会话中规避，同时更新相关技能文件，把纠正固化下来。
机制简单，效果显著。每次失败都变成一次永久性改进。到第五次做同类任务时，模型产出的质量已经接近第一次会话中需要数小时手工打磨才能达到的水平——不是因为模型变了，而是因为围绕模型的架构改进了。
三层如何协同
三层是一个系统，不是三个独立技巧。Spec 确保模型在动手前理解意图。草稿本跨会话保留推理，不丢失工作成果。反馈闭环把每次纠正转化为永久改进。
一个同时使用三层的会话大致是这样：加载 spec，模型带着完整上下文开始工作；工作过程中持续写入草稿本；你审查输出，识别需要调整的地方；模型更新 spec 和相关文件，把纠正固化进去；下一次会话从第一个回答开始就产出更好的结果。
初始投入——写 spec、搭草稿本、建立反馈纪律——在两三次会话内就能收回成本，之后持续产生回报。
如果只做一件事
如果只实现一层，做 spec。拿到好结果和拿到平庸结果之间最大的区别，在于你是否在让模型做任何事之前，就给了它关于你目标的完整图景。
多数 prompt 本质上是在让模型猜。Spec 消除了猜测。仅此一项就能显著改善结果——在此基础上，草稿本和反馈闭环会随时间复利放大这些收益。
转变不在于成为更好的 prompt 作者，而在于成为更好的系统设计者。模型不是你查询的搜索引擎，是你需要充分简报的协作者。简报做好了，结果会超出预期。
基于 Austin Marchese 对 Andrej Karpathy 的 Claude 方法论的拆解。
