大多数 AI 产品把单个功能做对了，却把产品整体做错了。搜索返回了合理的结果，摘要表述连贯，对话助手给出了合理建议。但当用户搜索"小团队最佳方案"、在侧边栏看到推荐、向助手追问后续问题，再阅读自动生成的选项摘要——而这四者相互矛盾时——没有一个功能还能让人信任。这就是环境 AI 一致性问题：不是孤立的幻觉，而是产品层面的矛盾。
这种失败模式足够隐蔽，以至于团队往往完全忽视它。单个功能的评估指标看起来还不错。搜索团队衡量召回率和精确率，摘要团队衡量忠实度，对话团队衡量任务完成率。但没有人衡量产品各 AI 功能之间是否在讲述同一个事实的同一个故事。
为什么跨功能矛盾与单功能幻觉性质不同
单功能幻觉已有大量研究。模型生成了虚假或与上下文不一致的内容。修复方法——更好的检索、护栏、模型升级——即使不完美，也已广为人知。
跨功能矛盾则更难处理。即使每个单独的功能在其自身约束范围内运行正常，矛盾也可能发生。设想一款产品从共享文档库中提取数据，但各功能采用不同的检索策略、不同的上下文窗口和不同的提示设计。文档 A 说企业版支持 50 个席位；文档 B（较新的更新）说 100 个席位。语义搜索功能检索了文档 B，显示 100。AI 摘要功能检索了两份文档，由于上下文冲突，含糊地显示"最多 100"。对话助手因查询措辞与其分块权重匹配而检索了文档 A，回答 50。每个功能单独来看都表现合理，用户却看到了对同一隐含问题的三种不同答案。
RAG 系统矛盾检测研究证实了这一点：即使是最先进的模型，在单个检索上下文内也只有 5–45% 的概率检测到自我矛盾。跨文档的成对矛盾检测率较高，可达 80–89%，但仅在比较是显式的情况下——而非当矛盾隐藏在从不相互对照的独立功能调用中时。
这种不对称性至关重要：用户不会在功能层面进行质疑，而是在产品层面建立信任。一个明显可见的矛盾，往往就足以让他们对整个产品的评价大打折扣。
时间错位：最常见的根本原因
跨功能矛盾最常见的结构性根因是时间错位：不同功能在不同年龄的数据上运行。
功能 A 使用每 24 小时更新一次的缓存嵌入索引，功能 B 调用实时 API，功能 C 使用 7 天刷新周期的 RAG 管道。产品将这三者都打上了"AI 驱动"的标签。当底层数据发生变化——价格更新、政策调整、产品改名——各功能在不同时间完成更新。在可能长达数小时乃至数天的窗口内，产品的不同部分描述的是不同版本的世界。
这不是数据工程的失败，而是架构的失败。各功能是独立设计的，各自对缓存和数据新鲜度做出了在局部看来合理的选择，却没有关于任何时刻数据状态的共同契约。
解决方案不一定是同步所有更新频率（那会带来真实的成本影响）。解决方案是让差异变得显式且可问责。每个功能不仅需要知道它在操作什么数据，还需要知道该数据在何时有效——系统需要检测不同功能是否在相距甚远的快照上运行，以至于可能产生矛盾。
响应契约：缺失的架构层
大多数构建多功能 AI 产品的团队会编写提示模板，但几乎没有团队会编写响应契约。
响应契约是一份规范，定义了某个功能被允许表达什么——不是指格式（长度、结构、语气），而是指语义领域。它回答：
- 这个功能可以做出哪些事实性声明？
- 哪些声明应该推给其他功能或拒绝表达？
- 如何处理不确定性？
- 关键领域概念的规范词汇是什么？
没有响应契约，你就有一个伪装成产品问题的提示工程问题。每个功能工程师各自优化自己的功能，关于功能"负责什么"的隐性假设随时间不断分歧。
有了响应契约，你就有了协调机制。当定价页面 AI 和对话助手都能访问同一份契约，该契约规定"定价声明必须以被标记为权威的当前定价文档为依据"，那么当该文档过时时，两者都会以相同的方式优雅失败——而不是各自以独特的方式失败。
响应契约还让一致性测试问题变得可处理。你可以编写自动化检查，探测每个功能的输出是否遵守其契约，以及各功能间的契约是否相互兼容。这仍然很难，但这是一个有明确定义的问题。没有契约，测试跨功能一致性就是在测试一个只存在于分散工程师脑海中的隐性规范。
共享风格治理不只是关于语气
余下内容仅对会员开放。
会员可读完整内容 —— 每一个公开发布的观点背后，那些框架、决策与推理的全貌。
- 完整文章，包含未公开存档的部分
- 可落地的工作框架，附带权衡与决策依据
- 新文章抢先看，先于公开发布
随时取消 · 一次订阅，畅读全部