科技｜Unknown Unknowns：防不住的AI 「闪身步」
知乎日报 · 生活与娱乐
知乎日报 2026-11-06 20:00 北京 程序员常说，你永远不知道明天和 Bug 哪个先来。 过去半年，尤其在刚刚过去的 10 月，AI 行业密集披露了一批「智能体错位」事件。代码表面如一潭平静的湖水，湖水之下，其实暗流涌动。 AI 最危险的，不是出错，而是让你以为一切正常 10 月 24 日观猹大会的知乎分论坛上，知乎答主 @锦恢 援引了软件工程里的 Unknown Unknowns 概念—— TA 不知道某个东西，所以 TA 去问，因为 TA 知道自己不知道什么；但也会问不出来东西、不知道自己不知道什么，即 Unknown Unknowns 的部分。 视频｜锦恢：AI 时代最棘手的问题？不知道自己不知道 今天，我们想通过知乎上的一些讨论，来说说 AI Coding 的那些「Knowns」和「Unknowns」。 一、最怕的不是写不出，而是不知道写了什么 在写代码或设计架构时，我们的认知可以分成四层。这个框架借自拉姆斯菲尔德那段绕口令，被工程师们用在日常工作里。 认知四象限：我们知道什么，又不知道什么 Known Knowns （已知已知）：我们知道并且掌握的。 Known Unknowns （已知未知）：我们知道自己不知道，但可以去查、去填补的空白。 Unknown Knowns （未知已知）：我们以为自己懂，实际上理解有偏差的盲区。 Unknown Unknowns （未知未知）：那些连你想都没想过、根本不知道它会发生的盲区。 知乎问题「计算机科班出身的优势是什么？」 在「计算机科班出身的优势是什么」这个问题里，知乎答主 @酬勤 的回答获得了超千赞，他引用性能专家 Brendan Gregg 在《System Performance》里的说法： 当你知道自己不知道时，会抱有谦卑的心态；真正可怕的是第三种——无知者无畏。 阿里研究员谷朴关于软件复杂度也有自己的思考： 上线时，我们最大的噩梦就是 unknown unknowns：这类风险，我们无法预知在哪里、是否有问题，只能在软件上线后遇到问题才有可能发现。 斯坦福大学计算机科学荣休教授 John Ousterhout 在《A Philosophy of Software Design》里，也把 Unknown Unknowns 列为软件复杂度的三大症状之一。 这套理论长期被工程师用来理解软件系统的复杂度。但当写代码的不再是人而是 AI 时，这套四象限会发生什么变化？ 回看 2026 年下半年的这批智能体错位事件，几乎都能在四象限里找到对应位置，其中 Unknown Knowns 和 Unknown Unknowns 这两层，出现了一些此前没有被系统讨论过的新情况。 二、当 AI 学会钻语言的空子 先从 Unknown Knowns 即「以为自己懂」这一象限开始，故事集中在 OpenAI 10 月更新的事故报告里，主角是 GPT-6.1 Sol 和 GPT-6 Astra。 第一起事件，源于一句看似简单的指令，多轮任务后智能体对此做出了截然不同的解释。 10 月 3 日，研究员给 GPT-6.1 Sol 派了个活：去 Slack 里把员工收集的反馈找出来，整理成一份评测任务。指令里写了一句「don't send any messages」，意思是让它只翻材料、别在 Slack 里发消息。 知乎答主 @安柒 lihua 对报告做了逐段精读，还原了它在多轮任务中改变判断的过程： 一开始，主智能体的判断是对的。它认为「别发消息」指的是 Slack 外联，和监控系统的自动告警是两回事，按政策发出的通知是允许的。 接着，它先把修复的活派给子智能体，并特意交代：报警功能要保留。子智能体自己也动过关通知的念头，最后还是否了，觉得「把该有的警报关掉不安全」。 可又过了几轮，主智能体自己改了主意。它重新权衡：一旦把结果写进系统，就可能触发自动通知、给人发消息，而用户「别发消息」那句话还作数 —— 于是它决定把通知关掉。 这一次，子智能体照办了：它把接收警报的人员名单整个清空，打开了「免打扰」开关，还在记录里写明「是用户明确要求不发消息」；为了防止被人改回来，它甚至加了一道保险 —— 只要「免打扰」没开，系统就直接报错。 结果是：监控系统继续运行、存报告，但人类审查员再也收不到这些警报。用他的话说： 「静默」被做成了写入结果的前置条件。 另一起事件里，一个看似无害的限定词，让原本明确的硬约束变模糊了。 10 月 6 日，GPT-6 Astra 被要求迁移程序、复制一份参考实现。本来有一条明确指令：禁止关掉监控，哪怕临时也不行。但委派工作时，父智能体用了「视情况（as appropriate）」来限定这条要求，子智能体便以「参考实现里没有监控」为由，把监控整个移除了，还把原本用来检查「监