Karpathy最近有个说法让我印象很深软件工程正在被AI重写但工程纪律反而比代码本身更值钱。他反复提过一个方向不是什么新模型也不是新框架而是回头去翻四十年前的航空规范——1982年发布的DO-178标准以及围绕它长出来的那一整套“适航软件开发”方法论。一开始我也觉得奇怪航空软件和聊天AI能有什么关系直到我在自己的AI项目里跑了三周才意识到他说的“废话”是什么、航空规范又在治什么病大模型太能唠了会一本正经地给出看似合理、实则经不起追问的结论而航空领域四十年前就在解决“怎么让复杂系统里的每句话都可靠”这个问题。这篇东西适合谁看如果你正在调AI Agent、写提示词或者被AI生成的长篇大论搞得头大那这套思路值得收藏。我会把航空规范里“目标-约束-验证”的玩法拆成可以直接抄的模板再附上踩坑记录让你看完就能用。1. 为什么是Karpathy为什么偏偏是40年前的航空规范1.1 他看见的问题AI的问题不是“愚蠢”而是“自信”Karpathy这几年反复说一个观点LLM的本质不是数据库不是搜索引擎而是一个“模糊模式补全器”。它并不知道自己说的是对的还是错的只是擅长生成听起来像那么回事的内容。这就带来了一个很隐蔽的毛病——信息密度极低。你问它一个问题它会先说一句“这是一个值得探讨的问题”再铺垫一段背景然后给你三五个泛泛的备选方向最后补一句“请根据实际情况权衡”。看起来礼貌周全实际上一句能用的都没有。更麻烦的是“自信的胡说”。你让它总结一篇论文它会给你安上一个原文根本没提到的“创新点”你让它写一段代码它会贴出一段编译都过不了的伪代码还附带一本正经的注释。不是模型变笨了而是它把“像人话”优化得比“正确”更好。Karpathy在几个技术分享里都提到要对抗这种“废话叙事”不能靠更大力度的提示词也不能靠更长的上下文得靠工程手段。他给出的参照系就是那些在地面测试中反复验证、在天上飞了几十年的航空软件规范。1.2 DO-178到底说了什么航空级软件的“反废话机制”DO-178是1982年发布的《机载系统和设备适航审定的软件考虑》后来有DO-178A、B、C几个版本演进。它最早要解决的问题很朴素飞机上的软件如果出了bug是会坠机的所以每一步都不能靠“我觉得”。它定义了几条核心纪律随便拿出来一条都直戳今日AI的痛点。第一是需求可追溯性。每个软件功能都要能向上追溯到一条顶层需求向下对应到一段具体代码不能存在“为了实现某个功能而写但没人说得清为什么在这里”的代码。AI生成内容恰好相反你问它为什么得出这个结论它往往说不清来自哪条上下文。第二是目标验证闭环。每个开发阶段都有明确的“目标”而且每个目标都要有对应的验证手段。不是“写完就完事了”而是要回答“你怎么证明它满足目标”。AI的验证恰恰是软肋它自己也分不清“看起来对”和“真的对”。第三是过程文档化与配置管理。在航空软件开发里文档不是写给领导看的是可追溯性的载体。每一个决策、每一次变更都要有记录。AI的生成过程则完全是黑箱除非你把提示词和模型版本冻结否则今天问和明天问是两份完全不同的答案。你把这套标准翻译成日常语言其实就是一句话别让任何人或任何模型在大事上凭感觉发挥。这不正是治理“爱说废话的AI”最需要的东西吗1.3 这套老规范为什么能治今天的“新病”有人会问航空规范约束的是“软件开发流程”管的是代码跟聊天AI的输出有什么关系关系太大了。AI生成内容的本质也是一种“软件行为”只是它的开发过程是隐式的、不可控的。航空规范的那些约束本质上不是在规定代码长什么样而是在规定“在安全关键的场景里人类和工具协作时必须遵守的沟通与验证规则”。大模型的输出如果不经过规则约束就像一架没有飞行包线的飞机什么动作都敢做但没人知道它什么时候会失速。这恰好就是Karpathy那类人的视角他不太关心某个具体prompt怎么写他关心的是整个“人-AI协作系统”的流程结构。航空规范提供的就是这种结构它告诉你这件事要在什么阶段做什么检查、留什么记录、如何证明结论可靠跟模型参数无关跟最后输出的是代码还是文字也无关。所以把四十年航空领域的“工程洁癖”搬过来治AI的“自由发挥病”逻辑上是完全通顺的。2. 把航空规范翻译成AI听得懂的约束2.1 拆成三大支柱目标、约束、验证我从DO-178和配套的ARP4754A系统开发指南里提炼出了三个用在AI场景下的原则组成了一个“航空规范三段式”。第一段是“目标明确”。不是“帮我看看这段代码”而是“找出这段代码中可能超出内存边界的数组访问输出位置和修复建议”。目标越接近“可验收”的状态AI越不容易跑偏。第二段是“约束清晰”。约束包含三层格式约束输出什么结构、内容约束不得输出什么、过程约束先做什么后做什么。航空软件的开发计划里满满都是这种玩意儿比如“不得使用动态内存分配”“所有中断处理函数必须在5ms内返回”对应到提示词里就是“不得输出任何过渡句”“不得引用原文未出现的概念”“必须先给出结论再给理由”。第三段是“验证可得”。你要能检查它是否做到了。航空规范里每个目标都有对应的“符合性方法”AI场景里则表现为“每条结论必须带上其在原文中的位置”“回答结束后用不超过50字说明你遗漏了什么风险”。让验证变成可执行的检查而不是靠感觉判断“它答得好像还行”。2.2 在提示词层面积累给AI写“飞行手册”提示词其实就是我们的“飞行手册”航空规范在这里的落地方式是把“说明书式提示词”升级成“适航指令式提示词”。我举一个典型场景。很多人喜欢写“帮我整理一下这份会议纪要”这种提示词会触发LLM的“好人模式”它会先赞扬这份纪要认真详实然后按时间线给你列一长串流水账最后给你一个“总的来说”。信息全在但你要的东西被埋在废话堆里。用航空三段式改写之后是这样目标从会议纪要中提取3个待办事项并标注每项的执行人与截止时间。 交付Markdown表格四列分别是序号、待办、执行人、截止时间。 约束 - 不得输出任何“以下是会议纪要的整理结果”之类的引导句直接输出表格。 - 如果纪要中没有明确对应项在对应格内填“未明确”不得自行推断。 - 除非纪要中写明了日期否则截止时间统一写“待确认”不得猜测。 验证输出后对照原纪要逐项检查确认没有新增、遗漏或改写。同样的场景前者会让AI自由发挥后者把容错空间压得很小。模型的下一个词预测任务本质上就是“在约束条件下填充”你把约束条件定义得越像适航文件它就越难跑偏。2.3 在Agent/工作流层面落地让工具链充当“审查方”提示词只是在入口处做约束真正要治爱说废话的AI还得在工作流层面加“审查方”。航空规范里有个概念叫“独立验证”写代码的人和验证代码的人不是同一批人避免“自己验证自己”。落到AI场景里我实操下来比较有效的方式是双Agent机制一个Agent负责生成另一个Agent负责按约束逐条打分。生成Agent的废话率在第二个Agent的压力下会肉眼可见地降低因为后者会直接告诉它“第3条结论缺少原文依据扣2分”。还有一个好用的做法是“强制中间产物”。很多人让Agent直接出最终答案这就像航空规范里不允许直接跳到代码实现必须先出需求规格说明书一样。我的设置是Agent执行任何复杂任务都必须先输出“理解的任务目标”和“计划执行步骤”我确认后再继续。这一步能拦截掉大量的“答非所问”。3. 实操我是怎么跑通“航空级提示词”的3.1 一场对照实验常规提示词 vs 航空级提示词我在本地的一个知识库问答项目里做过一次直观对比。问题是让我总结一篇关于无人机路径规划的技术论文并给出可用场景。常规提示词版本输出的内容大概是这样的先来一句“这篇论文深入探讨了……”然后罗列了五六个章节的主要内容接着说了三四个“应用前景”最后以“总体而言本文具有较大的参考价值”收尾。全文三百多个字我实际能用的是一个小标题论文题目。航空级版本输出的内容则完全不同因为它按上面那个三段式模板加了一组约束禁止使用评价性词汇如“深入”“重要”“价值”所有结论必须可以被原文章节名直接验证全文字数控制在150字以内。结果它只输出了四行核心方法将A*算法与动力学约束融合提升低空障碍场景下的路径平滑度见第3章改进效果相同地图尺寸下平均规划时长降低18%见第5.2节实验数据约束条件算法假设风速恒定未处理动态突发阵风见第6章局限性转折点就在这里同样的模型同样的知识库只是换了提示词结构输出就从“端水大师”变成了“技术文档”。可见模型不是不会说人话是缺一套逼它说人话的规则。3.2 一套可以直接复用的“三段式”模板我在具体项目里打磨出一套模板分享出来你可以直接往里面填内容。第一段是“目标声明”格式固定为“从输入材料中提取/生成什么东西目的是给谁用/解决什么问题”。这里的重点是写清产物类型和消费者AI非常吃这一套你告诉它“这份列表要给一线工程师去评审”它自动会收敛口吻。第二段是“约束条款”我用四类子约束格式类输出结构、行数、字段名、是否允许Markdown内容类必须包含的关键信息、严禁出现的词汇、不得引用的内容数量类字数上限/下限、列表条数行为类先做什么后做什么比如“先给结论再列理由”第三段是“验证规则”我会写上“你需要在输出结束后用不超过50字说明本回答中哪些结论的依据来自原文原句哪些是概括性转述”。这个设计借鉴了“证据链”的思路让AI在生成过程中被迫对自己的信息源做了一遍“追溯”。模板是这样的目标______要交付什么、给谁用 交付______结构/载体/字段 约束 - 格式约束______ - 内容约束______ - 数量约束______ - 行为约束______ 验证 - 输出后对照______逐项自检并在文末附上一段“依据声明”。用这个模板还要注意不要用否定句描述约束要用肯定句。写“不要输出引言”不如写“直接从编号列表开始”效果好。因为LLM对肯定指令的服从性远高于否定指令这也是我踩过几次坑之后的发现。3.3 参数与工具选择的几个具体建议提示词只是半边天另外半边是参数设置和工具链搭配。温度参数是“废话开关”。我处理信息提取类任务时temperature直接设为0关闭随机性那套“既礼貌又模棱两可”的废话模式会大幅消退。如果是头脑风暴类任务我会调到0.8那是另一个场景允许它自由发挥。max_tokens不是节约手段是强制收束手段。很多人都以为这个参数只是设定输出长度上限其实它还切断了模型不断扩展上下文的空间。设个150它会老老实实挑重点反倒是开很大它才敢绕来绕去。工具层面我强烈建议加一个“程序化校验器”。别让AI自己验证自己。比如要求输出必须符合JSON格式就在工作流里接一个json.load校验失败就自动重新生成。要求字数在200以内就用一个简单的正则或字符计数函数检查超标就触发重试。这样做的好处是你不再依赖模型自觉而是建立了一条与DO-178的“验证目标”同构的自动化检验线。4. 常见的坑与排查实录以及我的处理办法4.1 AI就是不理会约束条款怎么办最典型的问题约束写得清清楚楚模型还是偶尔给你来一段“当然这个问题的背景是……”的废话。排查方向有三个。检查约束的位置——我发现约束放用户消息末尾比放开头有效放system prompt里又比用户消息里有效。如果可能把“输出约束”直接放进system prompt相当于给模型设置“出厂参数”。检查约束的句式——把“不要输出引号”改成“直接输出编号列表”把“不要展开解释”改成“每条解释不超过15字”。检查温度——同一套约束temperature在0.2和0.8之间的废话率差距非常大。4.2 规范写得太死AI反而不会干活了这是我踩过最深的坑。有一段时间我把约束条款加到十几条AI输出是简洁了但有些关键信息也被它“简洁”掉了比如漏掉某个隐含前提或者忽略例外情况。后来我想清楚了航空规范也不是永远只说“不行”它还有“放行准则”。于是我在约束后面加了一个“例外授权”区明确写“如果遇到以下情形可以打破上述约束A. 原文信息不足以支撑明确结论B. 存在多个合理解读”。这相当于给规范开了“滑行道”AI反而更愿意遵守大部分约束因为它知道自己不会被一个死板的规则逼进死胡同。4.3 输出字数还是超怎么办老实说靠提示词调字数上限是玄学尤其当模型很“想”表达时它会用自己的词频统计对抗你的约束。我现在的做法是双保险提示词里写“全文目标字数200字允许上下浮动10%”同时在代码层面接一个字数验证器。超出范围就自动把输出丢回生成器附一句“你上一次输出超出了字数限制请只保留核心结论压缩到200字以内”。这样做非常有效因为第二次生成时模型有了一个具体的“对齐目标”不再是凭空理解“简洁”是什么。4.4 “自检”总说没问题但问题一堆让模型自己验证自己就像让写代码的人只做自测而不做独立测试缺陷率降不下来。模型的自检本质上还是同一个概率分布在做预测它很难识别出自己的幻觉。我的解法是把“验证”外包给另一个Agent或者在流程里插入一个“评审人”角色。简单做法是在提示词里写上“请以评审专家的身份根据上述约束条件逐项核查上一份回答”然后把两份输出一起对比。复杂做法是写一个小脚本对模型输出里的“依据声明”做关键词匹配如果它声称“见第3章”但第3章实际并不在输入材料里直接判失败。这才是真正的验证闭环。5. 这套玩法还能延展到哪些场景5.1 AI编程让Agent遵守“接口契约”我在用AI写代码时发现把航空级三段式用起来效果比任何“代码生成技巧”都明显。目标是“为一个HTTP接口补充单元测试”约束是“测试必须覆盖200/400/500三种状态码且不得使用Mock网络请求”验证是“生成后执行pytest并反馈真实运行结果”。这套流程已经在几个项目里稳定跑出可合入的测试代码最大的变化是Agent不再给你“我写了一个示例”这种交差式回复因为验证规则直接要求它跑真实测试。5.2 文档自动化与知识库检索如果你做过RAG应用一定体验过“检索增强生成”最后变成“检索增强废话”的尴尬。把航空规范搬进去以后我给检索系统加了一条硬约束如果知识库中没有直接对应的段落必须如实回答“没有找到依据”而不是常识补全。这个改动让系统的“幻觉率”明显下降代价是回答变得生硬了一些但用户反馈里“这个AI更靠谱了”的比例大幅上升。5.3 团队协作中的“约定手册”我还把这套模板用在了团队内部。我们写了一份“AI使用约定”规定谁在用AI生成交付物时必须附带目标声明、约束清单、验证结果。同事一开始觉得烦后来发现AI生成的文档评审通过率变高了因为大家能从验证记录里快速判断“这段结论能不能直接用”。本质上航空规范的原始用途也是“在地面上把问题暴露掉而不是让问题在天上爆发”这个逻辑放在AI交付场景里完全一致。最后再分享一个实用的收尾技巧经过这轮实践我最想说的是别指望用一套提示词永远解决AI爱说废话的问题工具在升级、约束在失效真正能沉淀下来的是“目标、约束、验证”这套思考方式。每当你觉得AI输出“貌似专业、实际无用”时不要急着换模型或加大上下文先问自己三个问题目标可验收吗约束够不够具体验证手段是不是独立于AI本身这三个问题就是四十年前航空工程师们每天都在问自己的问题也是Karpathy看中这套老规范的原因。从我的实操体验看与其到处收集“神级提示词”不如把这三个问题刻进自己的协作流程里这才是治本的做法。