AI幻觉，大概是这两年被讨论得最多的AI问题。以前的AI，胡说八道起来还算“正儿八经”——一本正经地编，编得容易被戳穿。现在的AI，胡说八道变得“有根有据”——编出来的答案里带着引用、带着数据、带着看起来言之凿凿的支撑材料，反而更难分辨真假。

(资料图片)

你问它一个问题，它答得斩钉截铁，语气里没有一丝犹豫——但答案是编的，有时候编得还挺像那么回事。

幻觉最常见的成因之一，是AI手里没有足够的数据或信息去支撑一个真正可靠的答案，但它没有停下来，而是继续往下生成，用一种听起来很自信、甚至看起来有凭有据的语气，把空白填满。

我最近撞见了一个反例——一次AI没有幻觉的经历，值得说一说。

我请一个AI模型帮我判断，一段中文书稿是不是还带着“翻译腔”。这是一个需要极其细腻的母语语感才能真正判断准确的问题——中文读起来地不地道，不是查语法对不对，是一种很难量化、很难说清楚判断依据的直觉。

它没有直接给我一个“改好了”或“没改好”的结论。它说：这个判断需要母语级别的语感，这超出了它能给出可靠答案的范围；它可以指出几个具体的、结构性的可疑之处，但最终判断，应该交给一个专业的母语编辑。

这不是一次幻觉。这恰恰是幻觉的反面。

知道自己的能力边界在哪里、并且愿意在边界处停下来——这不是能力不够，这恰恰是最难得的能力。这个道理，我是先在乒乓球台上学到的。

工程师的天性是修复故障。但概率性AI遇到的问题是：故障的空间是无限开放的。如果你把每一个边缘案例都吸收进核心系统，系统最终会被它的罕见案例塑形，而不是被它的日常功能塑形。

跟大家分享一个秘密：我特别讨厌跟用“长胶”的人打球。

长胶的胶粒比普通胶皮长，它对来球旋转的处理方式很特别，常常会把你自己制造的旋转“借”回来，让回球的节奏和旋转都变得很反常。对于一个习惯了快节奏、大动作、拉弧圈球的选手来说，那种节奏和时机简直错乱得让人抓狂。

有时候对手是个80岁的老大爷，几乎不怎么跑动，动作幅度也很小，但回过来的球却让我看起来像个忘了怎么打球的新手。

我的本能反应很直接：那就多练呗，专门针对这种球练。

但我的教练教了我战术，还加了一条更重要的建议：“别练太多。”

这听起来很反直觉。这可是最让我头疼的对手啊。

教练解释说，对付长胶需要一种“非正常”的节奏。如果花太多时间去适应那种慢吞吞、断断续续的击球感，反而会破坏我对付绝大多数普通对手时所需的肌肉记忆和动作机制。

而且说实话，我也讨厌练这个。对练过程慢吞吞又别扭，打完不是神清气爽，而是一肚子火。花在这个特殊对手身上的时间越多，我就越不喜欢乒乓球这项运动本身。

学点战术是有必要的，但为了这一种对阵去重塑我的整个击球动作，就不值得了。

我接受了偶尔会输给长胶选手的现实。这是为了保护我真正想打的那套球所必须付出的代价。

这不仅仅是个乒乓球故事，它揭示了我思考概率系统时的一个缺失环节。

“最后的5%” 比“前95%” 更贵

职业选手不能像我这么任性。每一场对阵都可能决定锦标赛的胜负，训练就是他们的工作。

但我只是个业余爱好者，时间有限，我打球的初衷是为了快乐。花在罕见对手身上的每一小时，都是从我平时打球的时间里扣除的；如果这还让我玩得不开心，那成本就是双倍的。

做产品也是同理。

如果客户愿意买单，一对音箱卖一万美元也是合理的，因为他在为那"最后一点点的音质提升"付费。但如果你的客户买的是千元级音箱，而为了填补那最后5%的性能差距，成本要翻十倍，那虽然工程上成功了，产品策略上却是彻底的失败。

AI领域也存在这种区别。

前沿实验室的工作是把模型能力推向极致，为此花大钱是合理的。但这从来不是我们在金融公司的工作。我们的任务是高效服务客户。如果现有模型已经足够可靠，那么设计好的架构、风控和兜底方案，远比死磕模型那一点点边际提升更有价值。

问题从来不只是"能不能改进"，而是"我们到底在优化什么"。一旦目标变了，优化的程度也得跟着变。

这在AI领域至关重要，因为潜在故障的空间是无限的。总会有奇怪的输入、对抗性的话术、没人预料到的组合。实战会告诉你漏了什么，但不会告诉你这个漏洞值不值得补。这需要判断力。

缺失的分支

我有一个叫“3C”的框架：组件（Component）、连招（Combo）、实战（Competition）。

• 组件，是经过验证的单一能力；
• 连招，是把这些能力编排成可重复的工作流；
• 实战，是把它们放进真实世界，看会发生什么。

当“实战”暴露出意料之外的情况时，标准反应通常是把它喂回系统：如果是反复出现且有价值的案例，就变成一个新的连招；如果是基础性的弱点，就去改进组件。

但还有第三种可能——这个案例可能是真实的，但很罕见，适配成本极高，而且可能会扭曲处理其他所有事情的系统。

这时候，正确的反应是设立一个边界。把它路由出去，升级给人工处理，或者干脆明确拒绝。不要强行把它塞进核心系统。

这是工程师最不愿意选的分支。但这正是“长胶”给我的教训。

如何判断实战在告诉你什么

最难的是知道这个新故障属于哪一类。当新案例出现时，我问自己三个问题：

• 这发生的频率有多高？
• 解决它有多大价值？
• 解决它会对核心系统造成什么影响？

如果是连招：如果案例反复出现、有价值，且现有组件依然稳健，加个新连招通常是最安全的。成本低，只是重组验证过的积木。

如果是组件：修改基础能力就不同了，所有依赖它的连招都会受影响。这需要更强的证据：故障必须揭示了能力本身的真实弱点，而不仅仅是个可以用其他方式处理的怪胎。不要因为一次失败看起来很难堪，就急着动组件。修改基础能力，必须有足够强的证据。

如果是边界：如果案例罕见、昂贵且会扭曲核心，答案就是设立边界。路由出去，升级给人工，拒绝它。有意识地接受这个失败。

真正的问题从来不只“能不能修”，而是“这个故障在告诉我们什么”。是缺了模式？基础薄弱？还是超出了范围？这是三种不同的诊断，不该得到相同的工程回应。

频率也不是唯一的标准。一个后果灾难性的罕见案例可能值得重视；一个常见的案例如果处理它需要完全不同的能力，也不该硬塞进同一个组件。频率、价值和扭曲度必须综合权衡。

想象一个专门从标准财报中提取结构化数据的组件。它工作得很好。然后有人提交了一份扫描很差、手写的、版式怪异的页面，它搞砸了。

你可以不断加指令、加例外、加兜底。有些确实有用。但在某个节点，真正的问题是：这份文档真的应该改变这个组件的底层逻辑吗？

也许这个输入已经超出了组件的设计范围。那就路由出去，送给人工审核，明确拒绝。处理这个例外，但不要强迫核心变成它从未被设计成的样子。

我的教练从没让我假装长胶不存在。他教我怎么应付。他只是拒绝让长胶重写我的正常击球动作。

边界也是产品的一部分

我们通常把边界描述为“局限性”，这个系统做不了那个，那个工作流要升级给人工，这种说法听起来像是在掩饰尴尬。

但我认为恰恰相反。边界就是产品的一部分。

一个成熟的系统应该知道它的管辖范围，知道它的可靠性在哪里生效，以及什么时候该把接力棒交给另一个组件、另一个工作流，或者一个人。

能力产生诱惑，架构产生克制。

这个区别很重要，因为一个优化可能在技术上是成功的，却毁了它原本要优化的东西。团队可能消除了一类边缘故障，却让系统变得更复杂、更脆弱、更难维护，在处理大多数用户依赖的普通工作时表现更差。

覆盖率提高了，产品却变差了。

“失败的情绪冲击力”不等于它的“架构重要性”。系统成功处理了一万个普通请求，然后在一个高管面前搞砸了一次，突然整个团队就动员起来确保它不再发生。没人停下来问问这到底有多罕见，消除它有多大价值，或者这个修复会在别处悄悄破坏什么。

我也许能赢好几场强强对抗，然后输给一个80岁的长胶大爷，结果整晚我都在想那场输球。

那种羞辱感给了它超过其频率的权重。输球确实算数，也确实烦人。但烦人从来不是重塑我整个比赛风格的理由。

好的反馈循环是从现实中学习，但学习并不意味着吸收现实产生的一切。

有时候实战揭示了一个新连招，有时候揭示了薄弱组件，有时候揭示了一个本该就是边缘案例的边缘案例。因为概率系统永远会有奇怪的情况，如果每个失败都自动变成核心引擎的新需求，那就没有尽头了。系统会不断堆积例外，直到没人记得它最初是干嘛的。

• 有些失败，接受它比消除它更便宜。
• 有些案例值得一个兜底方案，而不是一个新功能。
• 有些请求值得一个边界，而不是另一层调优。

一个能处理所有想象中边缘案例却累死维护者的系统，犯了和我在乒乓球桌上差点犯的一样的错误：它为了那个罕见的对手进行了优化，却毁了它真正想打的那场比赛。

“长胶”的教训从来不是无视那个不寻常的对手，而是在不让它重写你比赛风格的前提下，去应付它。

更多AI落地思考和实践将在「2026 ITValue Summit 数字价值峰会」呈现！

过去四年我们持续跟踪AI变化：—2023，百模大战，我们分享了50个创新场景，告诉行业AI将如何影响企业数字化转型。—2024，我们用十几场直播+9场闭门会，逐一拷问｛大行业+大模型｝在中国的真实渗透率。—2025，我们做了10个AI预判：摩尔定律放缓、CIO职业挑战、企业组织重构等问题都在今年得到应验。

现今，AI已不是“新知”，但同样也并没有“共识”。

在这个厂商“烧不起”，企业“等不起”的“兑现”时刻。面对企业级 AI 落地，谁都不敢说有最优解，对话比结论更重要。

我们期待通过不同角色、立场的深度对话，完成价值交换、相互启发。扫码关注2026 ITValue Summit 数字价值峰会进展。

关键词： 路由 乒乓球 工作流 长胶陷阱 ai系统