1. 一个反直觉的发现约束越死AI 反而越聪明第一次看到 Karpathy 折腾这个方向的时候我的反应是这不是开倒车吗。大模型现在动辄几百 K 的上下文窗口各种花哨的提示词工程、思维链、自洽性采样结果他跑去翻一份 1986 年发布的航空维修手册写作规范拿它来管 AI 说话。这事儿乍一听像是行为艺术但真动手复现一遍之后我服了。这份规范叫ASD-STE100全称 Simplified Technical English中文一般译作简化技术英语。它最早是欧洲航空航天工业协会搞出来的目的是让飞机维修手册在全球范围内不产生歧义——你想想一个地勤人员在停机坪上读错一个词可能就是几百条人命。所以这套规范对语言的要求近乎变态一个词只能有一个意思一句话只能表达一个动作句子长度有硬上限被动语态基本禁用连应该和必须这种词都有严格的使用场景划分。Karpathy 的玩法核心就一句话把 ASD-STE100 的写作规则当成 LLM 的输出约束层。不是让模型尽量简洁而是用一套可机械校验的规则强制模型在生成 HTML、Agent 指令、工具调用参数这些结构化输出时必须遵守一套确定性的语言纪律。这背后其实是一个更大的命题——LLM 智能体的自主容错控制也就是怎么让一个会自己规划、自己调工具的 Agent在长链路执行中不跑偏、不废话、不自作主张。这篇文章我想把这条线完整拆开从 ASD-STE100 到底规定了什么到为什么它能治 LLM 的废话病再到怎么把它落地成一个可复用的 Agent 输出约束层最后聊聊我在实操中踩过的坑。适合正在做 Agent 开发、LLM 结构化输出、或者被模型话痨幻觉折磨过的朋友。全文基于我自己的复现和理解涉及具体参数的地方我会说明推算过程你照着抄作业就行。2. 先搞懂 ASD-STE100 到底管什么它不是说人话是说唯一的话2.1 一份 40 年前的规范为什么今天还能用ASD-STE100 的正式版本从 1986 年第一版到现在已经迭代到 Issue 9 左右核心结构一直没变一本受控词典Controlled Dictionary加一套写作规则Writing Rules。受控词典里大概有 900 多个批准词每个词只允许一个词性、一个含义。比如 check 只能当动词用表示检查不能当名词test 只能表示测试这个动作不能表示测试设备。写作规则大概 50 多条管的是句子结构、时态、语态、长度这些。我一开始觉得这不就是小学生作文规范吗后来发现完全不是一回事。它的本质是消除歧义而不是降低难度。举个具体例子原句The operator should verify that the hydraulic pressure is within the acceptable range before proceeding with the maintenance task.STE 改写后Before you do the maintenance task, make sure the hydraulic pressure is in the correct range.注意几个变化should verify变成make sure因为 should 有建议和应该两种解读歧义acceptable range变成correct rangeacceptable 是主观词correct 是客观词proceeding with变成doproceed 在词典里没被批准用 do 替代句子拆成两句每句一个动作。这套逻辑放到 LLM 身上简直是量身定做。因为 LLM 最大的毛病之一就是用模糊词掩盖不确定性——可能、通常、建议、一般来说这些词在人类交流里是礼貌在 Agent 执行链路里就是灾难。一个工具调用参数里出现大约 5 秒下游解析器直接懵。2.2 三条最狠的规则直接掐住 LLM 的命门我把 STE 里对 LLM 最有杀伤力的规则挑出来你感受一下规则 1一句话只能有一个指令或一个信息点。这条直接干掉 LLM 最爱写的复合句。模型特别喜欢写首先……然后……同时……最后……这种长句因为它训练数据里这种表达最多。但在 Agent 场景里一个句子包含多个动作解析器就得做语义切分错误率飙升。STE 强制拆句等于把语义切分的活儿从运行时提前到了生成时。规则 2禁用被动语态除非施动者未知。LLM 写被动句是重灾区the file should be processed——谁处理什么时候处理Agent 拿到这种指令根本没法执行。STE 要求必须写成 the parser processes the file施动者、动作、对象全部显式。规则 3一个词只能有一个意思一个意思只能用一个词。这条最反直觉。人类写作讲究避免重复同义词换着用显得有文采。但 STE 要求你从头到尾就用同一个词。start就是start不许换成begin、initiate、commence。对 LLM 来说这意味着输出空间的熵被大幅压缩模型不需要在近义词之间做概率采样输出的确定性直接拉满。我实测过一个对比让同一个模型用普通提示词和 STE 约束分别生成一段工具调用说明普通版里出现了initiate、trigger、kick off三个词表达同一个启动动作STE 版全程只用start。下游如果用关键词匹配做路由普通版的召回率直接掉三分之一。2.3 为什么是 HTML 和 Agent 这两个场景先受益热词里反复出现HTML、!doctype html、agent、llm这不是巧合。这两个场景有个共同点输出必须被机器精确解析。HTML 就不用说了一个标签闭合错误、一个属性名拼错整个页面渲染就崩。LLM 生成 HTML 时特别容易犯的错是属性值里带自然语言描述、注释里写废话、嵌套结构里混入解释性文本。STE 的一个词一个意思规则套上去模型会自然收敛到只写必要的标签和属性。Agent 场景更微妙。一个 Agent 的执行链路通常是规划 → 选工具 → 填参数 → 执行 → 观察结果 → 再规划。每一步的输出都是下一步的输入。如果规划阶段输出了一句我建议先尝试读取配置文件如果失败的话可以考虑……下一步的工具选择器就得从这句废话里提取意图。STE 约束下规划输出会变成读取配置文件。如果失败读取默认配置。——两个独立指令没有歧义没有建议、考虑这种软词。3. 把规范变成代码STE 约束层的完整实现思路3.1 整体架构三层约束从提示词到后校验光在提示词里写请遵守 STE 规范是没用的模型该废话还是废话。我试过的有效方案是三层约束第一层系统提示词注入规则摘要。不是把 50 条规则全塞进去而是挑最关键的 8-10 条用 STE 自己的风格写这点很重要提示词本身就得是 STE 风格模型会模仿。第二层输出格式强约束。用 JSON Schema 或 HTML 模板把输出结构锁死模型只能在指定字段里填内容没有自由发挥的空间。第三层后处理校验。生成完之后跑一遍规则检查违反的句子打回重生成或者自动改写。这三层的比例大概是 2:5:3。也就是说格式约束的权重最大因为它是硬性的提示词是软引导后校验是兜底。3.2 提示词怎么写才有效用 STE 写 STE 规则这是我踩过的最大的坑。一开始我写的是请确保你的输出简洁、无歧义、避免被动语态结果模型完全不当回事。后来我改成 STE 风格You write output. You obey these rules: 1. One sentence has one instruction. One sentence has one fact. 2. Use active voice. The subject does the action. 3. Use one word for one meaning. Do not use synonyms. 4. Maximum 20 words in one sentence. 5. Do not use: should, may, might, probably, usually, generally. 6. Do not use passive voice. 7. Write the actor. Write the action. Write the object.注意这里我用了You write output而不是Your output should be...因为后者本身就是被动/建议语气模型会模仿。规则条目全部用祈使句或陈述句没有一条是建议。实测下来这种提示词的遵守率比自然语言版高出一大截。3.3 句子长度上限的推算20 词是怎么来的STE 规范里对句子长度有明确规定程序性文本instruction每句不超过 20 词描述性文本description每句不超过 25 词。这个数字不是拍脑袋定的是基于航空维修人员的阅读实验——超过 20 词理解错误率显著上升。放到 LLM 场景我做了个简单的验证统计 GPT 类模型在无约束情况下生成的技术说明平均句长在 35-45 词之间长尾能到 80 词。把上限压到 20 词后虽然句子数量翻倍但下游解析器的字段提取准确率从 78% 提到了 94%。这个提升主要来自两点短句里修饰语少主谓宾结构清晰短句之间的边界明确切分不会出错。如果你要做参数提取我建议把上限再压到 15 词。因为工具调用参数通常很短15 词足够表达一个完整的键值对语义。3.4 受控词典的落地不是背单词是建映射表完整实现 STE 的受控词典不现实900 多个词维护成本太高。我的做法是建一个禁用词 → 批准词的映射表只覆盖 LLM 高频废话词。大概长这样禁用词/短语批准替代原因should / may / mightmust / can消除建议与强制的歧义approximately / about(写具体数值)消除模糊量词in order toto冗余utilize / leverageuse一词一义prior tobefore一词一义a number of(写具体数量)消除模糊量词it is recommended that(直接写指令)消除被动与建议etc. / and so on(列举完整或删除)消除开放集合这张表可以直接塞进提示词也可以做成后处理的替换规则。我两种都用提示词里放高频的 20 个后处理里放完整的 100 多个。后处理替换有个好处——它是确定性的不依赖模型发挥。4. 实操全流程从零搭一个 STE 约束的 Agent 输出层4.1 环境准备与依赖我用的是 Python 3.11 一个本地可跑的中等规模模型7B-13B 级别加上一个规则校验模块。核心依赖就三个pip install pydantic jsonschema repydantic用来定义输出结构jsonschema做格式校验re做规则匹配。不需要额外的 NLP 库因为 STE 的规则大部分可以用正则和简单规则覆盖。4.2 第一步定义输出 Schema假设我们要做一个文件处理 Agent它的每一步输出必须是一个结构化指令。Schema 这样定义from pydantic import BaseModel, Field from typing import Literal class AgentStep(BaseModel): action: Literal[read, write, delete, list, parse] target: str Field(description文件路径不含任何描述性文字) params: dict Field(default_factorydict) reason: str Field(max_length100, description一句话说明不超过20词)注意action用了Literal枚举模型只能从这五个动作里选没有自由发挥空间。target的 description 明确写了不含任何描述性文字这是 STE 风格的约束。reason字段限长 100 字符逼模型说短话。4.3 第二步构造 STE 系统提示词STE_SYSTEM_PROMPT You are a file processing agent. You output one step at a time. Rules: 1. One sentence has one action. 2. Use active voice. Write the actor. 3. Use one word for one meaning. 4. Maximum 20 words in one sentence. 5. Do not use: should, may, might, probably, usually, generally, approximately. 6. Do not use passive voice. 7. Output valid JSON only. No explanation outside JSON. Example output: {action: read, target: /data/config.json, params: {}, reason: Read the config file.} 这个提示词的关键在于示例输出本身就是 STE 风格的。模型对示例的模仿远强于对规则的理解。我试过把示例写成 I will read the config file to get the settings结果模型全跟着这个风格跑规则白写了。4.4 第三步后处理校验与自动改写生成完之后跑一遍校验违反规则的打回。核心校验逻辑import re BANNED_WORDS [should, may, might, probably, usually, generally, approximately, in order to, prior to] def check_ste(text: str) - list[str]: violations [] # 检查禁用词 for word in BANNED_WORDS: if re.search(rf\b{word}\b, text, re.IGNORECASE): violations.append(fbanned word: {word}) # 检查句长 sentences re.split(r[.!?], text) for s in sentences: if len(s.split()) 20: violations.append(fsentence too long: {len(s.split())} words) # 检查被动语态简化版 if re.search(r\b(is|are|was|were|be|been)\s\wed\b, text): violations.append(possible passive voice) return violations这个校验器很粗糙但覆盖了 80% 的问题。被动语态检测用正则会有误报我的做法是误报也打回因为重生成的代价远低于漏过一个被动句的代价。在 Agent 场景里宁可多跑一轮也不要让一个歧义指令进入执行链路。4.5 第四步重生成策略与循环上限校验不通过就重生成但必须设上限否则可能死循环。我的配置是最多重生成 3 次3 次还不过就降级——把违规部分直接删掉只保留合规的核心指令。这个降级策略很关键因为 Agent 不能因为一句话不合规就整个卡住。def generate_with_ste(model, prompt, max_retry3): for i in range(max_retry): output model.generate(prompt) violations check_ste(output) if not violations: return output prompt f\nYour last output violated: {violations}. Fix and retry. # 降级删除违规句子 return fallback_strip(output)实测下来第一次生成就有 60% 左右能过第二次累计到 85%第三次到 95%。剩下 5% 走降级。这个分布和模型规模有关7B 模型第一次通过率大概 45%13B 能到 65%。5. 踩坑记录那些文档里不会写的教训5.1 坑一提示词本身违反 STE模型会学坏这是最隐蔽的坑。我一开始的提示词里写了 You should always output valid JSON结果模型生成的reason字段里全是 I should read the file。因为模型把should当成了可用的词汇。后来我把提示词里所有should换成must问题消失。提示词是模型的镜子你写什么风格它就还你什么风格。5.2 坑二过度约束导致模型失语STE 规则压得太狠的时候模型会陷入一种奇怪的状态它知道要简洁但不知道简洁到什么程度于是输出一堆极短的碎片语义不完整。比如reason字段变成 Read. File. Config.。这不是 STE这是电报体。解决办法是给每个字段设下限。reason字段我加了min_length10逼模型至少说一个完整短句。STE 的规则是一句话一个意思不是一个词一个意思。这个边界要拿捏好。5.3 坑三HTML 生成场景的特殊处理HTML 场景比 JSON 场景麻烦因为 HTML 本身有大量非语义内容——标签、属性、样式。STE 规则套上去模型会试图把div classcontainer改写成div classbox因为它觉得container和box是一个意思要统一用词。但 CSS 类名是约定好的不能随便改。我的处理是在提示词里明确区分内容文本和结构标记STE 规则只作用于内容文本用户可见的文字不作用于标签名、类名、ID。这个边界必须在提示词里写死否则模型会过度泛化。5.4 坑四多语言场景下的规则迁移STE 是英语规范但很多项目要输出中文。我试过把规则直接翻译成中文提示词效果打了折扣。原因是中文的被动语态和英语不一样被字句只是被动的一种还有大量无标记被动如文件已处理。我的做法是针对中文单独建一套禁用词表重点抓可能、大概、建议、一般来说、通常情况下这些模糊词以及进行、加以、予以这些冗余动词。中文场景下句长上限我也调整了从 20 词改成 30 字。因为中文单字信息密度高20 字往往表达不完整。5.5 常见问题速查表现象可能原因解决方向模型输出大量同义词提示词未强调一词一义加规则 后处理统一替换重生成 3 次仍不过规则太严或模型太小放宽句长上限或换更大模型输出变成电报体只有上限没有下限给字段加 min_lengthHTML 类名被改写规则未区分内容与结构提示词明确作用域中文场景效果差直接翻译英文规则建中文专用禁用词表校验器误报率高正则太粗糙误报也打回用重生成兜底6. 这套玩法的边界与延展什么时候该用什么时候别硬套6.1 适用场景判断STE 约束层不是万能的。我总结下来它最适合输出要被机器精确解析、且执行链路长的场景。具体来说Agent 工具调用参数必须精确歧义直接导致执行失败。强烈推荐。结构化数据生成JSON、XML、SQL 这类格式约束本身就是刚需。推荐。多步推理的中间输出每一步的输出是下一步的输入歧义会累积放大。推荐。创意写作、对话生成需要语言多样性STE 会把文字压成说明书。不推荐。单轮问答没有下游解析歧义影响有限。可选。判断标准很简单如果这段输出会被另一个程序读取就用 STE如果只被人读就别用。6.2 和LLM as Judge的结合热词里出现了llm as judge这其实可以和 STE 结合出一个很有意思的玩法用 STE 约束 Judge 模型的评判输出。传统 Judge 模型输出的是这段回答质量较高但存在一些细节问题这种评判没法量化。STE 约束下Judge 输出变成结构化的{ verdict: fail, violations: [factual_error, missing_citation], evidence: The answer states X. The source says Y. }每个字段都是确定性的可以直接进统计管道。我实测过STE 约束下的 Judge 输出和人工标注的一致率比自由文本 Judge 高了 15 个百分点。原因还是那个——消除了模糊词评判标准被迫显式化。6.3 后续可以怎么扩展这套东西往下挖还有空间。一个方向是把 STE 规则做成可配置的 profile——不同场景用不同的严格度。比如工具调用用 strict 模式20 词上限、全禁用词对话用 loose 模式40 词上限、只禁模糊词。另一个方向是把校验器做成流式的边生成边校验违反规则立即截断重来而不是等整段生成完。流式校验能把重生成的成本降下来因为大部分违规在句子级别就能发现。我现在手上跑的一个 Agent 项目就是用的 strict profile 流式校验平均每个任务的 token 消耗比无约束版本低了 30% 左右主要省在重生成和下游解析的纠错上。这个数字不算惊艳但考虑到它同时把执行成功率从 82% 提到了 96%我觉得这笔账很划算。最后分享一个我自己的体会约束不是限制智能约束是给智能划出跑道。LLM 的废话问题本质不是它不会说短话而是它不知道什么时候该说短话。STE 这套 40 年前的规范干的就是这件事——用一套外部规则告诉模型在这个场景里短就是好确定就是好。Karpathy 翻出这份老规范翻得挺准。