2026 年 10 月 2 日，安德烈 · 卡帕西（Andrej Karpathy）提出了几种让语言模型输出更容易理解的办法。其中一条是要求模型用ASD-STE100来解释——这是为航空航天维护文档开发的控制语言。他还谈到了图表、交互式 HTML 页面和定制讲解视频。

这个建议指向一个值得追问的问题：当一段解释难以跟上时，换一种结构，能不能让重要的部分更容易被检查？

同一场讨论里，格雷迪 · 布奇（Grady Booch）提到了 UML。既有的建模方法早就提供了描述系统与行为的方式。这套工具箱比当下的 AI 智能体要早得多。

卡帕西的帖子关心的是人如何理解 AI 输出。这个问题可以往反方向延伸：智能体在动手之前要读的文档，应该怎么组织？

两个读者，需求有重叠

人打开一份文档，可能是想弄懂系统为什么这样运作。智能体读它，可能是为了实现一个功能或执行一套流程。两者都需要一致的命名、明确的条件、示例，以及区分 " 要求 " 和 " 建议 " 的办法。

但需求并不完全相同。一张图能帮人快速抓住边界，智能体可能更需要可编辑的图源，或者对同一组关系的文字描述。教程带人走一遍学习过程，参考页则为某个具体任务提供事实。

目标是选一种能暴露读者所需信息的表达方式。指令、架构视图、决策表，各自让不同的东西变得可见。

一段漂亮的文字，仍可能藏住规则

设想一条虚构的工作坊报名政策：有名额时登记人员；要求提供邮箱地址；工作坊满员时把人放进候补名单；对已经报名的人返回确认信息。

听起来合理。但如果工作坊满员时，一份已存在的报名被再次提交呢？系统该返回原有确认，还是把人加进候补？如果这次重复请求没有邮箱地址呢？

这段话包含了政策的要素，但优先级不清楚。把句子改短并不能解决这个问题。

为便于演示，这里明确选定几条规则：先检查是否已有确认的报名；只有新报名才要求邮箱；然后检查容量。返回已有确认不会多占一个名额，加入候补同样不占名额。这些是为示例设定的业务规则，不是把段落重新排版就能发现的事实。

工具箱早就在那里

这些方法解决的是不同问题，有的是标准，有的是框架、模型或文档实践。

ASD-STE100：让技术指令更精确。简化技术英语把写作规则和受控词汇结合起来。它源自航空航天维护，这个出身很重要——含糊的指令可能带来严重后果。一致的术语、清晰分离的动作，这些思路可以迁移到别处。但要求模型写 "STE 风格 " 的文字，并不等于符合完整规范。

Di á taxis：区分不同的文档需求。它把文档分为教程、操作指南、参考和解释四类。当一页内容既想教新人、又想列全选项、还想讲设计历史时，就该用它。对报名服务来说，操作指南讲组织者如何开启报名，参考页规定请求字段，解释页讨论容量政策。

C4：选择架构层级。西蒙 · 布朗（Simon Brown）的 C4 模型提供系统上下文、容器、组件和代码四种视图。用它说明报名服务处在什么位置、各部分如何关联。从问题所需的层级开始，上下文图可以只画参与者、报名系统和邮件服务商，不必包含每个函数或数据库字段。

UML：选择结构或行为的视图。UML 是一种带多种图型的标准化建模语言。时序图能暴露客户端、报名服务和数据库之间的交互，状态机图能描述合法转换。问题决定哪种视图有用；笼统地要一张 UML 图，等于没做选择。

决策表：暴露条件与结果的组合。当多个条件相互作用时，表格能显示哪条规则适用。还要定义行与行重叠时怎么办。一张小型教学表不会自动成为完整的可执行决策模型。

架构决策记录：保留推理过程。ADR 记录一项有后果的架构选择、它的背景和影响。用它记下服务为何选择某种持久化或集成方式，能帮后来的读者判断这些理由是否仍然成立。

一个例子，三种表达

回到工作坊政策。同一组选定的规则，可以用三种方式表达。

第一种，指令暴露顺序：检查是否已有确认的报名；若有，返回其确认，不额外占位，停止；若是新报名，检查邮箱；缺失则请求邮箱，停止；检查是否有空位；有空位则确认报名并占用一个名额；否则加入候补，不占名额。这个视图把顺序摆明，审查者可以在读容量分支之前先追踪一次重复请求。这些只是受清晰原则启发的普通指令，不构成对 ASD-STE100 完整合规的声明。

第二种，流程视图暴露分支：先判断是否已有确认报名，是则返回确认并停止，否则判断是否提供邮箱，否则请求邮箱并停止，是则判断是否有空位，有空位则确认并占一个名额，没有则加入候补、不占名额。分支结构在这里更易扫读，而且前面的指令已提供文字等价物，读者不必只依赖视觉排布。这是一张轻量流程草图，不展示架构，也不展示服务之间交换的消息。

第三种，决策表暴露各种情况：从上往下读，应用第一条匹配的行。把 " 占用的名额 " 作为跟踪对象，审查者就有了一个可检查的不变量——只有新确认的报名才会消耗一个名额。开发者可以把这些行变成测试用例；也可以让智能体针对表格提出用例，再由人复核结果。这两件事都不能证明真实系统遵循了这些规则。

按问题选结构

对这套报名系统，选择大致如下：组织者如何开启报名，写操作指南，附上前置条件和检查项；请求接受哪些字段，给参考页，列出必填字段、类型和示例；服务处在什么位置，从 C4 上下文或容器视图开始；哪个组件在何时调用哪个，考虑 UML 时序图；每种条件组合下发生什么，用决策表并写明匹配行为；为什么选这个架构，用 ADR 保留推理。

几种方法可以配合。Di á taxis 负责组织文档，操作指南可以使用一致术语，其解释可以链接到 C4 视图和决策记录，参考页可以附上规则表。

向 AI 助手提要求时，点名问题和约束会更有用，比如：把这条报名政策改写成有序指令和一张决策表，保留每个条件和例外，说明行的匹配规则，把歧义单独列出而不是悄悄解决。这样的提示给了审查者具体的检查对象，但它仍然需要一份源政策和关于未决歧义的判断。

结构有用，验证仍不可少

一张清晰的表可能编码了错误的政策。一张时序图可能漏掉授权检查。一次简洁的改写可能删掉某个重要的限定条件。

至少独立审查三件事：内容是否正确，重要情况是否覆盖，目标读者能否用得上。然后确认文档仍与它所描述的实现或流程一致。

这个示例有意把生产层面的问题留在边界之外：已有报名如何识别、地址是否校验、取消如何处理、两个人同时抢最后一个名额会怎样。一份有用的文档会点名这些缺口，真实实现则需要更多规则和检查。

不妨做个小判断。假设同事提出一条捷径：工作坊满员时，把所有报名请求都加进候补。它保住了示例政策吗？没有。它改变了已有确认报名的结果——即使工作坊现在满了，那个人也该收到原有确认。这条捷径丢掉了优先级规则。

第二个练习是问并发该放在哪里。决策表表达的是预期结果，但系统设计必须说明容量检查与名额占用如何保持一致。这可能需要一张交互视图、一条事务规则，以及表格之外的测试。

有一套 AI 输出实地指南把 30 种方法汇集在一个交互式学习资源里。每个条目讲清历史与原始用途、优点与局限、适用场景、示例和主要参考。读者可以比较不同方法，在工作案例的不同表达之间切换，做 90 道带解析的短练习，并把可下载模板带回自己的工作。该指南以静态网站运行，不做运行时的大模型或模型 API 调用，书签和练习记录留在浏览器里。

从一份反复引发提问的文档开始。弄清读者想做什么，选一种能暴露难点部分的表达，再检查转换之后什么被保留了下来。有用的结果是：一份人能理解、能质疑、能据此行动的文档。

AI 披露：本文在 AI 协助下起草，并对照所链接的来源和实地指南中已实现的示例做了复核。报名场景仅作示例，未声称在人类理解度或智能体可靠性上有任何可测量的提升。