Karpathy:AI 越能干,输出越要看得懂

Agent 能交出越来越多结果，人的难题却没有自动消失：我怎么知道它理解了什么、改了什么，哪些地方还需要核验？

Karpathy 推文^[1]：

我们会花更多时间理解语言模型的输出。

他认为，语言模型承担更多具体工作后，人的工作会更多转向抽象、监督与理解。他分享了文字、图解、交互网页和讲解视频四种输出形式。

这四种形式解决不同的理解问题：文字减少歧义，图解显露关系，网页支持交互探索，视频呈现时间过程。按问题选载体，才能让人更容易读、查和接手。

Karpathy 建议让模型借鉴 ASD-STE100^[2] 来解释问题。这是一套受控技术英语规范；中文写作可以借鉴其清晰原则。

用到 Instructions 或 Skills 时，可以把动作和条件拆开。这是面向开发者的应用延伸：

1. 修改代码后，运行受影响模块的本地测试。
2. 测试失败时，修复本次改动引入的问题。
3. 修复后，重跑受影响模块的本地测试。

动作、条件和验证范围保持不变，读者更容易检查每一步。

当任务里有依赖、分支或检查点，图能让人一眼看见它们如何相连。比如把一条示意路径画成“需求 → 变更 → 本地测试 → 人工核验”，再标出哪里会分支、每一步留下什么证据。

图能解释测试路径；是否通过，仍看实际测试记录。

有些问题适合临时做一个 HTML 界面来浏览：把架构、Diff、测试、风险和待决策项分成可切换的区域，再连到实际代码和测试记录。它服务于眼前的问题，用完可丢弃。

界面让人按问题寻找证据；尚未检查的部分，应明确标出“未检查”。

如果问题本身是一个过程，视频可以展示状态怎样随时间变化。例如，用请求队列的示意动画呈现请求进入、等待、处理、完成的先后关系。这里要看的是状态与时间，不必把解释变成技术细节堆砌。

Karpathy^[1] 对定制讲解视频尤其看好，也提到 3Blue1Brown 风格和 ElevenLabs 配音作为个人试验例子。原帖把网页应用和讲解视频都视作服务特定问题的一次性制品；动画与配音可以解释过程，正确性仍需实际验证。

四种形式并列：文字解释事实与比较，图解呈现关系，网页支持交互探索，视频表现时间过程。选择标准不是哪种形式最先进，而是哪一种能让当前读者更容易理解。

我把它理解成一个双向接口：开发者把目标、动作、条件和验证标准交给 Agent；Agent 再把结果整理成适合人理解的形式。前一段降低 Agent 理解指令的成本，后一段降低人理解输出的成本。理解与核验之后，人的反馈还会成为下一次输入。Human → Agent → Human 是本文的解读，不是 Karpathy 原帖提出的术语。

在真实工程里，这个接口还要由 harness 中的工具、权限、测试与接管边界承接；这里先聚焦信息怎么表达。

请在当前项目内审查与改进 Agent 指令及其输出形式。先只读取本任务必需的信息：项目根目录和目标文件适用的 AGENTS.md、CLAUDE.md、SKILL.md，它们明确引用且与本任务相关的 reference，以及我明确提供并且当前可读取的命令、system 配置和必需参考。不要假定你能读取宿主隐藏的 system/developer 指令，也不要无目的扫描整个仓库。保留原文件语言、项目原意、授权、安全和验收边界。检查指令是否含糊、重复、冲突或术语不一致；动作、条件、失败后的验证是否明确；低频 reference 是否被不必要地常驻加载。不要为了缩短而机械改写，不要机械套用 ASD-STE100，也不要新增未经授权的规则。同时按实际问题选择输出形式：事实用文字，比较用表格，关系或路径用图，需要操作和探索时考虑 HTML，随时间变化的过程考虑视频。它们是并列选项，按实际理解收益选择，不要求全部制作。可核对的来源包括 Karpathy 原帖：https://x.com/karpathy/status/2105819303471976479；若描述 ASD-STE100 背景，核对官方 FAQ：https://www.asd-ste100.org/STE_faq.html。明确区分来源事实、推断和未核实项。先给出问题位置及证据、修改理由和 Proposed Diff，并明确尚未检查的部分。先 review；等我确认后，才在必要范围内修改，再运行受影响的验证，并报告实际结果与未覆盖项。

让 Agent 更容易理解指令，也让人更容易理解它交回的结果，才算把“能做更多”变成可核验、可接手的协作。