Ken Thompson 这个名字在操作系统和编程语言的圈子里几乎不需要介绍。他是 Unix 的共同作者是 B 语言和 Go 语言的推动者也是早期用机器下国际象棋程序的实践者。这几年 AI 几乎接管技术讨论中心时我经常想到他。原因不是他留下过多少慷慨激昂的 AI 预测而是他的工作方式像一块压舱石面对复杂系统不信任是最安全的起点验证是唯一可靠的推进手段。他最有名的图灵奖演讲题目是 Reflections on Trusting Trust那个编译器后门实验提醒整个行业如果工具链从一开始就不可信那么即使你看到全部源码也不能推导出结果是安全的。这个思想放到今天的模型语境里几乎是为大模型量身定做的警示——权重和训练数据无法完全审查输出真实性必须靠外部校验。我们真正应该从 Ken Thompson 身上带走的不是具体算法而是一套关于“可验证、可复现、可审计”的 AI 工程方法。1. Ken Thompson 不是反 AI而是信不过看不透的东西1.1 技术选择更像价值观Ken Thompson 在公开场合很少发布关于 AI 的长篇演说。他更习惯用产品、代码和演示说明问题。但从他参与的项目看他的偏好非常稳定工具要简单行为要显式链条要可检查。Unix 把“小工具 管道”组合成宏大系统C 语言把“字节 指针”的抽象压到最薄Go 语言则把并发、依赖管理和部署体验放到语言层解决。这些选择背后共同点都是你需要能理解正在发生什么。即使是很高级的抽象只要某个环节变成黑箱他会本能地警觉。这不是保守而是一种工程价值观。AI 模型最大的特点恰恰是黑箱输入一串 token输出另一串 token内部用十几亿甚至上千亿参数共同决定结果。我们很难在第一时间指出某个回答对应哪条具体规则。对于 Thompson 这类人这样的系统不是“聪明”或“愚蠢”的问题而是“能不能被信任”的问题。1.2 “可验证”比“看起来正确”更重要1984 年的图灵奖演讲里Thompson 用一个编译器后门实验说明当编译器本身被植入恶意逻辑之后所有用这个编译器编译出来的程序都会带上同样的问题而源码审查不一定能发现。他强调的是一个递归的信任链你信任编译器编译器会放大信任而你最终得到的可执行文件可能完全不同于你审查过的源码。大模型的信任链有类似结构你看到的模型输出不是源代码直接生成的而是由训练语料、权重、采样参数和推理框架共同决定的。开发者能检查提示词能检查生成结果但很难逐层定位“为什么这条回复会有偏见、会编造事实”。这时候如果直接把 AI 结果放进生产流程等于在无意识信任训练语料里所有人的判断。所以说 Ken Thompson 会排斥 AI 是过度简化。他真正排斥的是不可验证带来的失控。当我们把大模型当作一个需要被审计的外部依赖为它设置输入输出契约建立监控和回滚机制它才真正进入到系统工程师的信任边界内。2. 从 Belle 到 Unix他早就踩过“智能系统”的坑2.1 Belle把“智能”拉回搜索与评估很多人以为 Ken Thompson 的主要贡献只有操作系统和编程语言。实际上他在国际象棋机器上也有过一段重要经历。他与同事在贝尔实验室设计的 Belle是 1980 年代非常有代表性的棋类专用计算机。它把“玩国际象棋”这个看起来很智能的任务拆解成搜索、评估、剪枝和硬件加速。Belle 的成功给当时的计算机博弈留下了很深的印象。它不是靠某种不可解释的直觉取胜而是靠一套可以被反复调试的搜索结构。你给它的每一步行为都能回溯到评估函数和搜索深度。这种“运行过程可追踪”的做法和后来神经网络的黑箱气质差别很大。这段经历形成的关键判断是高级能力并不必然来自神秘规则。一个足够深、足够窄的搜索加上精心设计的评估函数也可以产生非常强的行为。对今天的启示很明显AI 可以处理开放性问题但很多业务场景只需要一个足够好的搜索或者一个硬规则未必需要把模型推上中心位置。2.2 Unix 哲学反过来约束 AI 的边界Unix 有一句经典设计原则每个程序做好一件事通过管道组合。Ken Thompson 是这一哲学的早期执行者之一。一个复杂任务被拆成 grep、sort、sed、awk每个环节都是独立的、可替换的、可测试的。整套系统是否可靠取决于每个环节的约定是否清晰。把这个原则搬到 AI 应用开发里会产生完全不同的架构思路。AI Agent 也好RAG 流程也好AI 编程辅助也好本质上都只是流程里的一个环节。模型负责理解语义业务规则负责兜底缓存负责重复请求日志负责审计。如果模型环节不定义输入输出格式不设置超时和重试整个 Agent 就会变成不可控的循环。在真实项目里我们经常看到这样的场景模型生成的 JSON 偶尔会多一个逗号导致下游解析失败Agent 调了一次外部工具没拿到想要的结果就反复重试AI 生成的代码在单元测试里没问题集成测试却因为隐藏假设而失败。这些问题都不是模型本身不够聪明而是外围工程没跟上。Thompson 在 Unix 上的经验告诉我们智能系统不能只靠智能更要靠接口、日志和错误处理。把模型当成一个 Unix 工具来设计接口是非常有效的心智模型。模型调用的输入应该被标准化输出应该被包装成稳定的数据结构错误要分类超时要可配置。这样当有一天你想替换不同厂商的模型时只需要改动一个适配层其他系统逻辑完全不用动。3. 把他那句“when in doubt, use brute force”放进 AI 时代重读3.1 暴力不是笨而是可计算、可预测Ken Thompson 有句话流传很广有疑问时用暴力方法。在编程语境里这通常意味着先用简单的穷举、确认或重试把问题跑通而不是一上来设计复杂的抽象。这句话被很多人误解为“他反对优雅代码”其实他反对的是为了优雅而牺牲可验证性。放在 AI 时代这个原则依然成立。当模型在某个小任务上表现不稳定时我们其实有两个选择继续调整提示词期待它更稳定或者在关键的边界场景里直接用确定性规则、枚举、查表、缓存来兜底。后者看起来“不够智能”但它可预测可测试出了问题可回滚。比如一个识别的字段取值范围固定你能用正则或枚举约束就不必完全依赖模型自由输出。模型可以负责上游的语义理解下游再用规则确认结果是否合法。这种“模型做开放规则保下限”的搭配就是 brute force 思维在 AI 工程里的正面价值。3.2 模型负责联想外围逻辑负责落盘真正危险的使用方式是让模型在关键路径上直接输出最终结果不做任何校验。比如让模型直接返回订单金额、代码片段、接口参数然后原样使用。一旦模型出现幻觉错误就会进入生产链路而且很难被发现。Thompson 式的处理是给模型划一个权限边界。模型可以提议但决定权留给确定性的校验层。AI Agent 可以建议下一步行动但工具白名单和最大步数由外围系统控制。AI 编程助手可以生成代码但必须有自动化测试和人工审查。这样即使模型“天马行空”系统仍然有一个物理下限。实践中可以按风险等级划分低风险模型生成文案、摘要、初稿人审后发布。中风险模型生成结构化数据但后端用规则和校验函数做二次检查。高风险模型只提供建议最终决策由确定性流程或人工完成。再举一个非常具体的场景让模型生成 SQL 然后直接查询数据库这是高风险动作。哪怕是内部工具也应该限制表名和字段白名单再对生成的 SQL 做一轮规则校验确认它只访问了允许的库表。模型可以给出查询逻辑的建议但真正执行的动作必须受控。这个分级方式不需要复杂的框架只需要在小规模场景里先跑通再慢慢扩大模型能接触到的动作范围。4. 今天做 AI 工程最缺的不是模型而是 Thompson 式严谨4.1 AI 编程生成代码只是开始验证才是真正工作AI 编程工具眼下已经非常普及。Copilot、Cursor、ChatGPT 写代码的片段质量很多时候足以让开发者省下大量搜索时间。但这里有一个很隐蔽的坑AI 生成的代码语法正确甚至能通过你随手写的几个测试却可能在边界条件、类型约束或权限假设上出错。Thompson 的经历提醒我们不能因为代码“看起来合理”就信任它。AI 生成的代码应该当作来自不可信协作者的 PR 来处理必须有可重复的测试、必须审查差异、必须在关键路径上补充断言。如果你让 AI 生成的代码直接进入生产却没有配套测试等于把信任交给一个你看不见训练数据的概率模型。有一个简单的做法使用 AI 编码工具时先要求它生成针对该需求的测试用例再让它生成实现。或者手工写测试然后让 AI 修复不通过的代码。这样等于把模型当成一个受测试约束的代码生成器而不是一个替你做最终判断的“黑盒程序员”。4.2 Agent 和自动化工作流必须有“刹车”AI Agent 类应用比单纯调用大模型复杂得多因为它不仅生成文本还能决定调用哪些工具、执行哪些操作。如果缺少边界Agent 很容易陷入无限重试、错误工具调用或行为偏离目标的困境。工程上首先要明确几个参数最大迭代次数、工具白名单、每一步的输入输出日志、重大操作的人工确认点。不要让 Agent 在无人值守的情况下接触高风险动作至少要在早期阶段保留人工环节。这看起来效率低但恰恰是可控性的代价。其次是输出校验。Agent 调工具返回的数据要再次校验格式Agent 生成的最终回答要经过规则或关键词检查万一检测到非法内容就中断并转入人工处理。这套设计并不是给 AI 泼冷水而是让 AI 能在有限的失败范围内安全试错。重要提醒不要一上来就把模型部署到生产流程并完全自动化运行。先用一条样例把输入、输出、日志和回滚路径都跑通确认每个环节都可见再逐步放开。4.3 最小可运行验证流程从一次调用到可迭代系统如果让我们把 Thompson 式严谨落地最值得先做的不是搭一个大平台而是建立一条“最小可运行验证流程”。参考顺序如下固定环境 记录模型版本、推理框架、权重文件哈希、量化参数确保同一版本可以原样复现。单样例验证 选一条业务核心样例跑通模型调用记录输入、输出、耗时、Token 消耗。规则校验 检查输出是否是合法 JSON、字段范围是否正确、关键约束是否成立。日志快照 将每一次请求的原始输入、输出、参数、错误信息保存起来方便事后归因。人工抽检 定期对边缘样本做人工评估记录准确率和失败类型。灰度发布 将模型输出的使用范围控制在少数用户或少数请求上观察一段时间后再扩大。回滚机制 准备一个可以直接切回的稳定版本效果恶化时能一键回滚。这个流程不是把简单事情复杂化。它的价值在于当模型升级、提示词调整、训练数据变化时你可以依赖一套稳定的观测手段判断“到底是不是变好了”。类似 Spring AI 这类应用开发框架也在把“模型调用、解析、提示词模板、Agent 步骤”封装成标准化结构。这本身是好事但封装不能替代验证。无论框架帮你省掉多少样板代码你仍然需要回答同一组问题输入是什么输出是什么模型失败了怎么办结果如何被校验。框架降低的是编写成本不是风险。4.4 排查链路当 AI 输出不对劲时按顺序查AI 输出异常时新手最容易直接换模型、调温度、重写提示词。但更稳的顺序是先确定问题出在哪一层。常见排查链路包括排查层检查内容输入层上下文是否被截断、编码是否异常、格式是否规范、字段是否缺失模型层具体模型版本、权重文件、温度/采样参数、缓存命中是否异常基础设施GPU/内存是否足够、推理框架是否降级、并发是否过高工具链外部 API 是否正常、Agent 调用链是否循环、超时设置是否合理后处理解析脚本是否出错、字段映射是否正确、输出是否被错误截断验证层是否有针对输出的校验断言、失败任务是否被自动捕获按这个顺序排查可以避免大多数无效调参。如果模型返回的结果格式稳定但内容错误问题大概率在输入上下文或后处理如果偶尔宕机问题可能在基础设施如果 Agent 行为前后不一致问题可能在工具链和迭代边界。把每一个环节的记录补齐AI 系统才能像成熟的软件系统一样被观测和调优。5. 普通开发者能从他身上带走的四件事5.1 最小可验证流程先于效率很多团队在使用 AI 时第一步就是把全流程自动化。这直接违背了 Thompson 的稳妥原则。正确顺序是先小、后大先让一个客户案例跑通再扩展到相关案例最后才考虑通用化。每扩展一步都要回头看验证是否还在生效。AI 产品经理和研发在规划需求时也应该先把“验证指标”写进需求文档。不要只说“我们要接入大模型”而要说明“什么输出算成功什么输出算失败谁来负责确认”。这些边界条件越早定义后续的返工越少。5.2 结果可复现先于结果惊艳模型输出的“惊艳”很多时候来自随机性。真正有用的是复现性相同输入、固定参数下能得到相同结果。如果做不到完全复现也要保留输入输出快照确保出现事故时能回到某一个具体的版本现场。可复现性是工程化的地基。要做到这一点最简单的办法是把每次请求的模型版本、提示词版本、采样参数、原始输入和最终输出统一写入日志。不要只记录最终结果。否则当模型表现变差时你根本不知道是哪个环节变了。5.3 黑盒输出必须被外层逻辑包裹不管模型多强关键业务路径上都不能裸用。你可以在模型外围套规则校验、字段映射、异常检测、人工确认。隔离模型失败的影响范围是使用 AI 的必修课。下面的检查清单可以在上线前过一遍模型输出是否有 JSON Schema 校验。数值字段是否有范围限制。关键决策是否有人工确认点。模型调用失败后是否有降级路径。是不是每个环节都有日志。能不能在五分钟内回滚到上一个稳定版本。如果这些答案都是“是”AI 才算真正被工程化。如果只是“模型调用通了”那离生产可用还有好大一截。5.4 信任靠审计不靠感觉感觉模型“挺好用”和系统真正可靠之间差着一整套日志、监控、回滚和抽检。Ken Thompson 半个世纪前用编译器实验证明的就是信任链条的脆弱性。今天的模型更复杂我们更应该为这种脆弱性留出空间。这也是为什么我始终觉得AI 领域的“工程实践”比“参数竞赛”更值得长期投入。参数更大、能力更强当然会有帮助但只要它还是一个不可完全解释的概率系统验证和审计就不会过时。结尾建议很简单找一个真实业务场景先照着上面的最小验证流程跑通一次。不要急着上生产也不要用最贵最大的模型。先确认你能回答这几个问题模型版本是什么输入输出都是什么失败时能不能回滚输出有没有被校验如果都能回答再把 AI 变成工作流里的一环这比盲目追求更高参数的模型重要得多。Ken Thompson 未必会喜欢今天大模型的黑箱属性但他一定会赞成一种态度对一个无法完全理解的系统保持敬畏然后用工程手段把它变成可验证、可控制的部分。这正是 AI 工程实践中最稀缺的东西。