最近圈子里有个说法特别扎心：AI什么都会，就是不会少说。你让它总结三句话，它能给你铺垫三段背景；你让它查个报错，它先共情你加班辛苦，最后才把错误码夹在中间。Andrej Karpathy最近反复在提“software is changing”——AI正在从聊天框挤进代码库、运维管线、业务系统里当Agent，但大家很快就发现，让一个爱说废话的大模型去干严谨的活儿，风险系数堪比新手飞行员贸然起飞。他自己在聊Agent工程化的时候，也经常点出同一个问题：模型行不行另说，工程纪律极度缺失，代码里全是“看起来合理但经不起推敲”的中间产物。
这阵子我看了不少技术讨论帖，很多工程师不约而同提到了一个老古董：40年前航空界定下来的那套规范——检查单、标准通话、冗余降级。把它翻译成今天的AI工程语言，恰好能治好“AI废话病”：让LLM和Agent在关键任务上输出更短、更准、更抗故障。这篇文章就按这个思路，把航空规范和AI实践对齐，从原理到代码到踩坑，完整捋一遍。适合正在做Agent、接大模型API、搞AI应用部署的工程师参考，也欢迎纯好奇的新手看个热闹。
1. 这一波“AI废话病”，到底是从哪儿来的
1.1 废话不是态度问题，是统计问题
大模型的本质是自回归生成：一个token一个token往外蹦，每一步都在概率分布里挑下一个字。它优化的目标是“像不像人话”，从来不是“信息密度高不高”。训练数据里人类的海量客套话、铺垫语、重复式总结，早就被模型学得明明白白，所以它宁可多说十句废话，也不冒险少说一句让人误解。
这就造成了一个典型的工程场景尴尬。你给一个接口发请求，报错了，你把错误信息贴给AI，问“这个HTTP 422怎么处理”。正常工程师期待的回答是：哪个字段不合法、怎么改、要不要重试。但大模型常给你的是：先解释超文本传输协议，再安慰你说这个问题很多人遇到，最后补一句“如果您需要更多帮助，请随时告诉我”。这条回答看起来没错，但在自动化流程里，它就是纯噪音——没法直接喂给下一个系统，还得再做一轮信息抽取。
说白了，这不是模型“性格不好”，而是它的训练目标根本没有惩罚“废话”。你平时聊天觉得它礼貌、健谈、有温度，放到生产环境里就成了灾难。很多AI应用上线后响应时间暴涨、解析失败率飙升，根因之一就是模型压根不明白：有些场合，说话越少越好。
1.2 Karpathy在急什么：软件在被重写，工程方法没跟上
Karpathy的观点向来直接，他说software is changing，实际意思是：软件开发正在从“人写代码、机器执行”变成“人定目标、AI执行、人来验收”。他自己是vibe coding这个词的推广者之一，体验过那种“躺着看你AI噼里啪啦写代码”的快感，但他更清楚，快乐和可靠之间隔着一条巨大的鸿沟。
他在讨论里反复强调过：AI生成的内容，尤其是代码和配置，存在着大量“不确定但看起来合理”的东西——代码编译能过，行为却跟需求背道而驰；配置项写得到处都是，删掉一个就炸。这本质上就是结构化的废话：占用空间、消耗算力、增加审查负担，却没能提高任何确定性。当AI从回复一句话变成操作整套系统时，这种废话就不再是“话多话少”的问题，而是故障放大器。
所以很多人在拆解Karpathy最近的Agent实践时，都指向了一个共同结论：与其指望模型自己变靠谱，不如把工程规范硬性嵌入AI工作流。也正是在这时候，有人翻出了40年前的航空规范——那套在极度依赖“人机协作”和“高可靠性”的环境里打磨了几十年的老规矩，本质上就是一套现成的AI工程红宝书。
1.3 为什么偏偏是航空规范：因为它早就治过“废话”
你可能会问：那么多行业规范，为什么单挑航空？关键在于，航空业在几十年前就遇到过一模一样的困境，而且是被迫解决的。
想象一下1980年代的航空通信场景：多个航班共用一条无线电频率，飞行员和管制员每一句话都得在几秒内完成。这条频率里没人听你寒暄，没人听你复述问题背景，多说一个废话词都是在占用他人的救命通道。于是航空界在那一时期把两项东西正式化：一是标准陆空通话术语（ICAO Phraseology），规定每句话的固定结构；二是飞行检查单文化，人被允许不信任自己的记忆，但必须信任流程。
这套规范的核心可以压缩成三个词：最小化、标准化、可降级。最小化是去掉一切不承载信息的字词；标准化是让所有参与者用同一套句式，消除歧义；可降级是当系统出现异常时，有明确的退让路径，不至于直接崩溃。这三个词放到今天的AI工程里，恰好一字不差：最小化对应精简输出，标准化对应结构化Schema，可降级对应容错降级设计。所以不是航空规范高级，而是它要解决的老问题，和我们现在面对的一模一样。
2. 拆解40年前的航空规范：三件被验证过无数次的“老古董”
2.1 飞行检查单：从B-17坠机事故到Agent入口校验
飞行检查单的起源本身就是一个关于“复杂系统如何击穿人类记忆”的经典案例。1935年，波音B-17原型机试飞，机上飞行员个个是精英，飞机却在起飞后不久坠毁，原因是飞行员忘了松开升降舵锁定装置。新飞机太复杂了，操作步骤超过了一个人靠脑子能记住的极限。行业后来给出的解决方案不是“换更聪明的人”，而是发明检查单：把复杂的起飞流程拆成逐项确认，每项就发生在物理按钮旁边，照做就行。
这件事放到今天，同一个剧本在AI Agent身上重演。Agent要调多个工具、访问多个数据库、按顺序执行多个步骤，还要在中间做各种if/else判断。模型能力再强，本质上也还是那个忘松升降舵锁的飞行员——它可能在第五步突然漏掉权限校验，可能在拿到上次缓存后忘了刷新，可能在调用外部接口前没检查必填参数。这些都不是“笨”，是复杂流程天然会击穿记忆和注意力。
所以，航空检查和AI工程的对照其实非常直接：Agent入口处必须有一份机务检查单。这份检查单不是一份给人类看的文档，而应该是一套可执行的校验逻辑，在Agent真正行动之前逐项确认：任务描述是否包含足够字段？模型输出是否命中预期Schema？允许调用的工具白名单有没有配好？最大循环次数、超时时间、降级路径是否都设置了？我做过不少Agent项目，最深的体会就是：跑起来之后再补救，远不如开跑之前多设几道闸。
2.2 标准通话术语：把“说人话”变成“说官方话”
航空通话里有一条铁律：禁止废话。管制员不会说“先生您好，这边建议您可以把高度稍微调整一下哦”，而是直接说“Cessna 5AB, climb to 3000 feet”。飞行员回复也不是“收到，好的，我们这就执行”，而是复述关键指令“5AB, climbing 3000”。这套标准术语的作用是双向的：对发送方来说，固定句式降低了漏说关键信息的概率；对接收方来说，固定句式让耳朵在噪音里也能第一时间抓到重点。
映射到AI工程里，这就是Prompt模板和结构化输出的雏形。你如果只是告诉模型“请简洁点”，模型大概率还是话痨，因为“简洁”是一个模糊的审美标准，不是约束。真正的约束是把输出格式焊死：必须是一个JSON，字段名固定，枚举值固定，并且任何多余的话都放不进这个JSON里。让模型像一个遵守陆空通话规则的飞行员那样回答问题，它就没机会说废话。这也解释了为什么现在各家大模型API纷纷推结构化输出、JSON Mode、Function Calling——这些功能的本质，就是把“航空标准术语”做成了软件层面的强制约束，而不是靠模型自觉。
2.3 冗余与降级：多AI协作的底层逻辑不是“人多”，是“能退”
飞机上有句话叫“关键系统不止一套”。液压系统有双冗余，飞行控制计算机有两到三套，供电系统分了多个独立源。比冗余更重要的是降级逻辑：当第一套系统失效时，系统不是卡死，而是自动切到第二套；第二套也不行了，再切到更基础的手动模式。航空工程里从来没人指望某个组件永远不坏，大家默认的是“一定会出问题，关键是出了问题之后还剩什么”。
这套思路放到多AI协作上，就是我强烈建议的一种Agent架构：Plan / Execute / Verify 三位一体，而不是让一个模型从头干到尾。主模型负责规划任务，第二个模型或者基于规则的代码负责执行和检查，再加上第三个模型交叉验证结果。这种设计常被误解成“多个AI聊天开会”，其实它对应的是航空的传感器冗余和交叉校验：两个独立的信号来源互相印证，能大幅降低单一信号源发生系统性错误的风险。
实际搭建时，我通常还会配一条明确的降级链：主模型正常跑的时候用大参数模型；主模型超时、断连或输出校验失败，自动切到一个小模型；小模型还不行，就把任务交给模板规则或人工介入，而不是硬着头皮让故障状态继续跑。这条降级链是“可降级”这三个字在AI工程里的直接体现，也是很多生产事故的止损线。
3. 把航空规范翻译成工程实践：三个立竿见影的改造
3.1 用Schema代替“请简洁一点”：先断掉废话的退路
在提示词里写“回答必须简洁”基本属于心理学安慰，约束力为零。真正有效的做法，是让结构本身不允许废话存在。最省事的方案，是用大模型厂商提供的Structured Output或者JSON Mode，把输出限制在一个严格的Schema里。
以OpenAI系的接口为例，定义一个输出Schema，相当于告诉模型：你说的话必须落在这张表里，多余字段不允许。下面这段代码是我常用的做法，用一个Pydantic模型声明返回结构，再把这个Schema传给接口，让模型直接产出JSON对象，而不是泛泛而谈的散文。
from pydantic import BaseModel, Field class ErrorFixResult(BaseModel): error_code: str root_cause: str = Field(description="一句话原因，不超过20字") suggestion: str = Field(description="可执行修复动作，必须是一个明确的命令") retry_after_seconds: int | None = None # 假设调用大模型接口，传入结构化输出配置 response = client.chat.completions.create( model="gpt-4o-mini", response_format={"type": "json_object"}, messages=[ {"role": "system", "content": "你是故障排查助手。只输出JSON，不要解释你的输出。"}, {"role": "user", "content": "用户报错：422 Unprocessable Entity，请求体里缺少email字段"} ], )跑一次你就会发现，所谓“爱说废话”瞬间收敛了很多，因为模型知道，一旦输出夹带了“好的，我来帮您分析一下”这种废话，整个JSON就解析不了。想多说都没地方放，这就是飞机器务检查单里“物理上防止错误”的思路。如果用的模型本身不支持这类结构化输出，也有偏方：在Prompt里给一个严格的JSON模板加两个正反例，同时把max_tokens压到只够写一次有效回答的量——留给废话说的地方少了，它自然就闭嘴了。
3.2 把Agent流程改成“起飞前检查单”：每一步都要有确认点
再往上走一步，就是Agent流程本身的设计。大多数AI Agent的失控事故，不是模型能力不够，而是流程里少了检查单。我每次搭Agent，都会写一个简化版的“起飞检查”函数，在真正执行任务前把所有风险项逐条确认一遍。
def run_agent(task, allowed_tools, max_steps=5): # 起飞前检查单：条件不满足，直接不飞 checks = { "task_valid": bool(task.get("goal")), "schema_ready": task.get("output_schema") is not None, "tools_ok": set(task.get("tools", [])) <= set(allowed_tools), "fallback_ok": task.get("fallback") is not None, } for name, ok in checks.items(): if not ok: return {"status": "aborted", "reason": f"check_failed:{name}"} # 执行阶段：每一步都验证，验证不过就降级重试 result = None for step in range(max_steps): output = run_single_step(task, step) if validate_step(output): result = output break else: # 降级：换更简单的模型/更严格的Prompt再试 output = run_single_step(task, step, strategy="fallback") if validate_step(output): result = output break return result or {"status": "failed", "reason": "exhausted_steps"}这段伪代码的精髓不是技术复杂度，而是它把航空检查单的三个特征做进去了：起飞前校验不过就abort，绝不带病运行；执行中出现问题不是原地死循环，而是走降级分支；最后一趟跑完没结果就明确返回失败，而不是把半成品硬当成功输出。很多Agent出事的典型症状正好是反向的：没校验就开跑、跑错了一直重试同一路径、失败了还返回一个看起来像结果的东西。这三条，正好对治三类事故。
3.3 用指标考核“废话率”：没有度量就没有改善
航空规范高效管用的另一个原因是它可度量：一句话多少个词、复述是否缺项、应答延迟几秒，全是可记录的指标。AI工程的废话治理同样需要指标，不能光靠“感觉回答变短了”。我自己的实践里会盯四个数据，形成一个“废话率”观察。
第一是单任务平均输出token数。同样一个任务类型，Token消耗明显下降，就说明约束在起作用。第二是“客套语命中率”。我在评估集里准备了一些典型句子开头，比如“好的”“当然”“首先”“如果您需要”，统计模型回答里出现这些词的概率，理想情况是趋近于零。第三是Schema一次通过率，也就是模型输出第一次就能通过校验的比例，这个指标比“输出内容好不好”更硬核。第四是无效重试次数，指因为解析失败、字段缺失、类型不对导致的重复请求次数，它直接反映你的Prompt约束和模型行为是否适配。
这四个指标凑齐，你就能把“AI废话”从一个玄学问题变成一个可以周会汇报的数字。以后每次改Prompt、换模型、调温度参数，都拿这四个数做前后对比。改着改着你会发现，很多之前靠感觉解决的问题，其实只要稍微调整输出约束，指标立刻就会往好的方向动。
4. 实操复盘：一套“航空级提示词”的完整落地过程
4.1 直接复制的Prompt模板：把规则焊死在系统层
以下是一套我调过很多次、目前在内部项目里跑得挺稳的“航空级提示词”模板。核心思路是给模型设三个角色：它不是客服，是机务；它不写散文，只输出对讲机式的报文；它不必友好，但不能撒谎。模板里的语气你可以按自己的业务调整，但结构建议保留，每一段都对应一个约束点。
你是航空级AI助手，负责处理工程任务。你的所有回复必须遵守以下规则： # 输出规则 1. 直接给结论，不做铺垫、不复述用户请求、不询问用户意图。 2. 禁止使用“好的”“当然”“首先”“如果您有任何问题”等客套语。 3. 每条回答不得超过80字，如果必须给出详细方案，先给出结论再附结构化明细。 4. 如果信息不足，直接回复“UNKNOWN”，并列出所缺字段，禁止猜测。 # 格式规则 1. 必须按给定Schema输出JSON。 2. JSON中的每个字段都要有实际值，无法确定时填null，并标注confidence=0。 3. 输出必须一次性可解析，禁止在后文解释JSON含义。 # 任务声明 用户任务：{task_text}这个模板看起来有点不近人情，但它在工程场景里的效果就是比“人味”模板好。为什么？因为它把航空标准通话的几大原则——固定结构、禁止废话、敢于说不知道——全部从要求变成了规则。模型接受这些规则之后，再配合JSON Mode，跑出来的东西几乎可以直接进下游流程，不再需要人工清洗。
4.2 加一层起飞校验：解析、检错、降级三连
Prompt只是第一步，真正处理生产级问题还需要在代码里兜底。我习惯在拿到模型输出后，先做一轮“报文解析”，再走“校验逻辑”，全部通过才视为有效回答。解析阶段处理的是JSON包在Markdown代码块里、末尾多了一个逗号这类小问题；校验阶段则是检查必填字段、枚举值、长度限制。
import json import re def parse_model_output(raw_text: str, schema_fields: set[str]): # 先把可能的代码块剥掉 text = re.sub(r"^```(json)?|```$", "", raw_text.strip(), flags=re.MULTILINE) try: data = json.loads(text) except json.JSONDecodeError: return None # 起飞前检查单：字段缺失直接判失败 if schema_fields - set(data.keys()): return None return data这个函数虽然简单，但实际项目里能挡住不少问题。判定失败之后，流程会自动进入降级分支：最轻的降级是重新请求一次，但Prompt末尾追加一句“上次输出不符合规范，请只输出JSON”；再不行就换一个参数更保守的模型；最后一步是把任务标记为需要人工介入。每次降级都记录原因，方便后续统计哪类问题最常见。这套“解析→校验→降级”链路，其实就是把航空里的复飞流程搬到了代码里。
4.3 效果对比：优化前的“散文体”和优化后的“电报体”
我拿同一个任务分别用普通Prompt和航空级Prompt跑过一组对比，任务内容是：根据一条报错信息，分析根因并给出修复建议。优化前的回答长这样：
“好的，我看到你遇到了一个HTTP 422错误。这个问题通常表示服务器理解你的请求，但是请求中的某些字段不能满足验证要求。在大多数情况下，这可能是因为缺少必填字段或者字段格式不正确导致的。为了避免这个问题，建议你检查一下请求体，确保所有必需的字段都已包含，并且格式正确。如果还有问题，随时联系我……”
这段话信息没错，但放在自动化链路里就是灾难：有客套、有背景、有重复、有开放式结尾。优化后，同一任务只有一行JSON：
{ "error_code": "422", "root_cause": "请求体缺少email字段", "suggestion": "补充email字段后重新请求", "retry_after_seconds": 0, "confidence": 0.95 }区别不只是字数。前者是给人看的，后者是人机系统都能直接消费的。前端可以用JSON校验error_code然后决定是否重试，后端可以直接把suggestion写进日志，整个链路不再需要一个额外的自然语言解析模型。这一套跑下来，我那个项目的Token消耗降了大概40%，解析失败率几乎归零——航空规范不是让模型变聪明了，而是让它把聪明用在能被验证的地方。
5. 常见问题与排查技巧实录
5.1 模型死活不遵守格式约束，怎么办
这是实践里出现频率最高的问题，尤其当你在用开源小模型时，JSON Mode经常名存实亡。我踩过坑之后的经验是分三层去堵。第一层，Prompt里加“格式惩罚句”，明确说“如果输出不是合法JSON，系统将拒绝你的回答”；第二层，提供正反两个示例，好模型通常看一遍反例就会改变行为；第三层，在代码里对parse失败的输出做截断和修剪，比如把模型输出切成最后一个“}”的位置，再尝试解析。这三层做完还不行，就不是调Prompt能解决的，我的建议是直接换一个对结构化输出支持更好的模型，别跟它耗。
另外有个很多人没注意的细节：max_tokens设太紧会导致JSON被截断，设太松又给模型留了说废话的空间。我一般先按预期有效内容长度的两倍设定，然后检查“JSON完整率”这个指标，慢慢压下来。这不是玄学，是调参手感。
5.2 JSON解析失败、字段缺失、死循环，怎么定位快
生产环境里，模型输出解析失败不要第一时间怪模型，先看是“格式坏”还是“内容缺”。格式坏，比如缺括号、多逗号、被包在Markdown里，通常加一层解析清洗就能解决。内容缺，则是模型压根没生成某个字段，这种问题光靠解析救不回来，必须回到Prompt层检修。我的习惯是给模型输出之前追一句“请确保包含：a, b, c三个字段”，或者在Schema里给每个字段都加上必填标记。
Agent死循环是另一个高频故障，症状是同一动作反复执行、API请求量异常飙升、日志里出现重复的相同输出。排查顺序我已经固定下来了：先看退出条件有没有设。很多Agent框架默认没有最大迭代数，模型掉进“重试失败→再次重试”的环里就永远出不来。其次是看失败分支有没有新的策略，如果失败后还是用同样Prompt重试，那循环只是时间问题。最后再看降级链是否完整，主路径断了有没有备胎。这三条排查完，大部分Agent失控问题都能在半小时内定位。
5.3 三个让你的AI更“守规矩”的落地细节
第一个细节，是把“STOP词组”写进Prompt，比如“输出结束后只输出一个特殊标记 ”。这个标记一方面给模型一个明确的句号，降低它画蛇添足的欲望，另一方面也让你的解析逻辑有了精准的截断点，不用再去猜哪个“}”是真正的结尾。
第二个细节，是保存“好答案”和“坏答案”各一二十条，做成评估集。每次改Prompt都要跑一遍全集，统计Schema通过率和废话率。很多时候你以为新Prompt变好了，其实只是它对单条任务友好，在全集上反而崩了。有了这个评估集，改动才有依据，出问题也能快速回滚。
第三个细节，是给模型“允许承认不知道”的合法出口。我这边的做法是让模型在不确定时返回UNKNOWN字段，而不是强行编一个答案。你可以先设置一个“confidence阈值”，低于阈值的回答不允许进入下游业务逻辑。这个设计不是让模型变得更能干，而是让系统的“不知道”变成受控状态，就像飞行员遇到恶劣天气时有权复飞，而不是硬着头皮落下去。
我自己做完这一整套改造之后的最大体会是：AI工程的可靠性和模型的聪明程度关系没那么大，更多是纪律和流程的事。40年前的航空规范为什么到今天还能救命？因为复杂系统里的那些坑——流程太复杂记不住、信息冗余会掩盖关键信号、单点故障会放大成整体事故——本质上从来没变过，变的只是执行者的载体从飞行员换成了大模型。把检查单、标准通话、冗余降级这三样东西老老实实套到AI工作流里，你得到的不是一个更会聊天的模型，而是一个上线了你敢半夜不看手机的系统。
