让 LLM 输出
成为可理解的技术工具

01推文主张：输出也是理解工具

当模型承担越来越多的执行工作，工程师需要花更多时间理解它做了什么、结果说明了什么，以及哪些地方需要核对。Karpathy 提出的四种输出形式，是围绕这个工作变化展开的。[1]

他对定制视频最有信心，并举了 3Blue1Brown 风格讲解和音频旁白的例子。他也指出，随着代码生成成本下降，可以制作过去不值得专门开发的一次性软件讲解工具。[1]

以下工程方案、指标、示例代码和学习任务，是基于推文主题设计的实践扩展。它们不是 Karpathy 发布的系统架构，也不是经过实验验证的效果排名。

02ASD-STE100：约束语言表达

ASD-STE100 Simplified Technical English 是技术文档使用的受控自然语言标准。它由写作规则和受控词典两部分组成。官方资料列出 9 个规则章节、53 条规则，以及约 900 个获准的一般词汇。Issue 9 发布于 2025 年 1 月。[2]

先区分“正式 STE”与“借鉴 STE 的中文表达”

ASD-STE100 约束英语文档。中文学习材料可以借鉴其表达原则，但不能把“20 个英文词”直接换算成“20 个汉字”，也不能把中文文档宣称为严格符合 ASD-STE100。

03配图核对：清晰版式仍需事实校验

附件把标准整理为工程图纸风格，展示结构、句型、词典、长度限制和历史。它适合作为阅读入口。下列内容需要修正或按正式资料重新确认。

查看你提供的配图

核对范围：已核实表中 test、about 与 2004 年三项；未对配图每个词条完成严格合规检查。正式写作仍应逐条查规则与词典。

04理解成本：三个层面分别处理

下面的划分是一个工程设计方法。它用来发现“读不懂”的具体原因，便于选择相应的输出形式。

一个句子拆成四个可核对单元

例如：“系统发现价格异常，因此建议核查。”这句话缺少输入、比较口径、计算结果和证据位置。可以拆成：① 输入为 A 项目的报价；② 比较对象为同规格、同币种的参考报价；③ 当前差异为计算得到的百分比；④ 提供两份报价的文件和页码。没有比较对象时，输出“缺少参考数据”。

这也解释了为什么更复杂的输出不一定更好。检查一个字段用短句即可；确认执行顺序用状态图；理解参数变化用交互页面；观察随时间变化的过程才需要动画或视频。

05提示词：把格式要求写成验收条件

“按 ASD-STE100 解释”是一种风格提示。Karpathy 提到的“80% of the way”是对严格规则的适度放宽，不是可测量的合规分数。实际工作应把需要的行为写清楚。[1]

模板一：中文技术解释

请用中文解释：{技术主题}。
读者已经会 Java，但第一次接触该机制。
借鉴 ASD-STE100 的表达原则：短句、明确动作、稳定术语。
保留专业名称，并在第一次出现时给出定义。
每一步说明：输入、执行者、动作、输出、失败条件。
区分资料中的事实、推断和示例。不得为了简短删掉前提。
最后给出一个正常路径和一个失败路径。
引用具体来源；缺少证据时说明未知。

模板二：精确图示

根据下面的执行记录绘制状态图：{记录}。
节点只表示运行状态；箭头标明触发条件。
覆盖正常结束、工具失败、取消、达到模型轮数上限。
给出节点与记录字段的对应表。
使用可编辑的 Mermaid 或 SVG。每条连线都必须有依据。
不要加入资料没有描述的自动重试或回滚。

模板三：交互式 HTML

把 {技术机制} 解释为一个单文件 HTML 页面。
页面使用中文，离线可打开，不依赖 CDN。
读者可以修改 {参数}，并观察 {可观察状态}。
公开计算规则；示例数据明确标注为模拟数据。
每次变化展示输入、计算结果和适用条件。
提供键盘操作、可读标签和减少动态效果支持。
检查目录、溢出、边界参数和错误路径。
按附带 UI 规范实现，不生成额外的页头工具栏。

模板四：讲解视频分镜

为 {技术主题} 写一个约 90 秒的视频分镜。
读者是 {人群}，要理解 {目标}。
每个镜头列出时间、画面、旁白、对应证据。
先审查脚本中的事实与单位，再生成动画和音频。
动画只展示已确认的状态变化，不补出未知的内部过程。
保留字幕，并提供可跳转的章节。
标明比喻的边界。

严格英语文档还需要指定标准版本、完整规则来源、术语表和检查方法。模型说“符合标准”不能代替词典核对。官方也指出，检查工具不能替代标准本身。[5]

06图示：用 Agent 循环解释结构

下面展示的是最小 Agent 循环的教学设计：模型提出工具调用，运行时执行工具，并将结果交回模型。它没有假定某个仓库已经实现这些行为。

画图时最容易遗漏的两件事

工具失败后谁做决策：可以把失败作为工具结果交给模型，让它选择下一步。运行时也可以按明确策略停止。两种策略都需要写出来，图中不能隐含重试。

取消与超时在哪里生效：循环入口检查不能中断正在等待的模型或工具。实际实现还需要传递取消信号，并给正在进行的操作设定截止时间。图示用于理解控制关系，执行细节应由代码验证。

07交互演示：观察轮数上限与失败路径

这个演示采用合成事件，不调用模型或工具。修改“模型轮数上限”和“工具情境”，再逐步推进，可以观察工具结果如何影响后续轮次。

建议尝试的三组条件

演示不包含真实网络延迟、并发工具、流式响应和资源释放。接入真实系统时，应直接展示运行时事件，而不是根据最终回答猜测执行过程。

08视频：先验证脚本，再安排时间

定制视频适合展示一个过程怎样随时间展开。Karpathy 提到，可以让模型制作 3b1b 风格讲解，配合音频旁白，或寻找使用本地计算的替代方式。[1]

下面是一个 75 秒的 Agent 工具失败讲解分镜。它是课程练习，不是已生成的视频，也不意味着任何服务具备固定的生成能力。

生成顺序

先写可核对的脚本，再做分镜与镜头时长；随后制作画面、旁白和字幕；最后逐帧检查对象、数值与状态是否同步。旁白说“已经完成”时，画面不能仍显示工具错误。

同一数据源应驱动文本、图表和动画。不要分别让三个生成步骤自由改写数字。涉及重试、取消和返回值的内容，应通过同一份事件记录保持一致。

09工程方案：事实、解释、渲染分开

如果每次都让模型直接生成整个页面，事实、语言和排版会混在一起。一个更容易核对的设计，是先建立包含证据的结构化结果，再生成解释，最后由模板渲染。

最小中间结构

{
  "documentId": "lesson-001",
  "claims": [{
    "id": "claim-01",
    "kind": "observation",
    "text": "工具返回错误，任务尚未完成。",
    "evidenceIds": ["event-003"],
    "status": "supported"
  }],
  "unknowns": ["未获得成功的工具结果。"],
  "trace": [{
    "id": "event-003",
    "type": "tool_result",
    "callId": "call-01",
    "isError": true,
    "errorCode": "SIMULATED_ERROR"
  }],
  "termination": {"reason": "max_model_turns"}
}

supported 应由检查逻辑赋值，不能只相信生成模型填写的字段。对事实的引用至少需要检查“证据存在、定位正确、内容支持该结论”；只有第一个检查通过，还不能认定事实成立。

验证可以分成三类

确定性验证：结构、必填字段、事件 ID、原始数字和单位适合由代码检查。语义验证：结论是否由证据支持，需要结合资料和上下文判断。可用性验证：读者能否找到证据、理解失败路径，需要使用任务测试。

模型可以辅助标出待核对内容；对关键结论，验证仍应使用原始资料和可复算逻辑。模型生成的“高置信度”不是证据。

10Java 示例：证据支持后再渲染

这个 JDK 8 兼容示例演示两条边界：证据不存在时拒绝输出；事件状态不支持失败时，也拒绝输出。工具名称按普通文本转义，避免被当作 HTML 解释。

import java.util.*;

public final class EvidenceExample {
    static final class Event {
        final String id, toolName;
        final boolean isError;
        Event(String id, String toolName, boolean isError) {
            this.id = id; this.toolName = toolName; this.isError = isError;
        }
    }

    // 只支持“某工具事件失败”这一种明确的教学结论。
    static String renderFailure(String evidenceId, Map<String, Event> events) {
        Event event = events.get(evidenceId);
        if (event == null) {
            throw new IllegalArgumentException("Unknown evidence: " + evidenceId);
        }
        if (!event.isError) {
            throw new IllegalArgumentException("Evidence does not support failure");
        }
        // 结论由事件状态构造，不接受模型任意填写的事实文本。
        return "<p>工具 " + escape(event.toolName) + " 返回错误。"
            + "<span>证据：" + escape(event.id) + "</span></p>";
    }

    static String escape(String value) {
        return value.replace("&", "&amp;").replace("<", "&lt;")
            .replace(">", "&gt;").replace("\"", "&quot;")
            .replace("'", "&#39;");
    }

    public static void main(String[] args) {
        Map<String, Event> events = new HashMap<String, Event>();
        events.put("e1", new Event("e1", "search <demo>", true));
        String output = renderFailure("e1", events);
        if (!output.contains("&lt;demo&gt;")) throw new AssertionError();
        events.put("e2", new Event("e2", "search", false));
        try {
            renderFailure("e2", events);
            throw new AssertionError("Unsupported claim was accepted");
        } catch (IllegalArgumentException expected) { }
        System.out.println(output);
    }
}

javac -encoding UTF-8 EvidenceExample.java
java EvidenceExample

这里验证了什么

它验证了一个受限结论与事件状态之间的一致性，以及文本插入 HTML 前的转义。模型只能选择允许的结论类型和证据 ID；最终事实由确定性代码构造。

这里还没有解决什么

示例不验证任意自然语言结论，也不证明工具返回的业务数据真实。完整工程还需要事件来源可信、字段校验、正确的文件版本与单位，以及面向具体业务的规则。页面如果允许链接、样式或富文本，单纯的文本转义也不能替代对应的 URL 校验与内容策略。

接入 Agent Runtime 时，可以订阅已有的工具执行事件，构造报告结构并渲染。最小 Think → Action → Tool → Observation 循环无需为了生成学习页面而引入会话、记忆或工作流组件。

11应用示例：采购审阅与技术学习

以下案例使用虚构数据，展示如何把结果变得便于核查。它不描述现有项目已经具备的功能，也不定义采购合规规则。

案例 A：两个同规格报价的比较

用柱形图可以显示两个价格的关系；用表格更方便核对规格与单位。如果比较口径不同，页面应显示“暂不可比”，不能只输出醒目的差异百分比。

案例 B：解释 Agent 取消

先写一句可执行的描述：“收到取消信号后，运行时停止发起下一次模型调用，并向正在进行的操作传递取消信号。”再画出取消路径。最后展示真实事件：何时收到取消、哪个任务已经开始、哪个资源已关闭。将“请求取消”与“确认结束”分开显示。

案例 C：学习一个源码模块

选择一个明确入口；给出调用关系；用一条正常轨迹和一条错误轨迹解释机制；把关键节点映射到类或函数；最后让读者修改一个条件并预测结果。这样能检查是否掌握了行为，而不仅是记住几个术语。

12效果评估：测理解，而非只测字数

推文提供的是实践建议。要确认某种输出对自己的团队更有效，可以把同一任务、同一事实集渲染为不同形式，再比较读者的任务表现。下面是建议的评估设计，没有提供虚构的实验分数。

一个可执行的对照过程

1. 整理 6 个有明确答案的学习任务，冻结参考资料。
2. 准备文字、图示和 HTML 三种版本；事实内容保持一致。
3. 随机安排版本与任务，减少先看某一版本带来的记忆影响。
4. 记录回答正确率、用时与证据定位情况。
5. 汇报样本量、任务差异和失败案例，再决定默认输出形式。

如果同一个人反复阅读同一个题目，应换用等难度任务并打乱顺序。小样本结果适合指导下一次迭代，不应宣称普遍的效率提升百分比。

13常见失败：形式通过，内容未通过

“一次性解释工具”可以临时生成，但应保留足以还原重要结论的输入与规则。对于长期维护的业务报告，应使用稳定模板、版本记录和回归样本。

14五次练习：从表达走向验证

建议围绕同一个小型 Agent 循环完成以下五次练习。每次约 45–90 分钟；这是练习安排，耗时取决于已有代码和熟悉程度。

15自测：检查是否能解释边界

先自己回答，再逐项展开。重点是能解释行为与前提，而不是背诵术语。

16资料来源与内容边界

1. Andrej Karpathy：理解语言模型输出的文字、图示、网页与视频建议

   依据：你在对话中提供的推文全文。配图使用你提供的 PNG。这里没有把推文中的实践意见当作比较实验结论。

2. ASD 官方：About ASD-STE100

   用于核对标准结构、53 条规则、约 900 个一般词汇及 Issue 9 信息。

3. ASD 官方：Frequently Asked Questions

   用于核对词义与词性、专业术语、about 的含义、2004 年名称变更，以及适用边界。

4. ASD-STE100 Issue 9 · 2025-01-15

   用于核对 Rule 1.2 中 test 的词性与 Rule 8.4 的句长计数说明。规则内容通过官方 PDF 的公开检索摘录核对，未完成整部标准的逐页检查。

5. ASD 官方：Tools for STE

   用于核对语言检查工具的能力与限制。严格标准写作仍需完整规则、词典与语境检查。