环境 AI 一致性问题：当每个功能都由 AI 驱动，整个产品却失去了统一感

大多数 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 和对话助手都能访问同一份契约，该契约规定"定价声明必须以被标记为权威的当前定价文档为依据"，那么当该文档过时时，两者都会以相同的方式优雅失败——而不是各自以独特的方式失败。

响应契约还让一致性测试问题变得可处理。你可以编写自动化检查，探测每个功能的输出是否遵守其契约，以及各功能间的契约是否相互兼容。这仍然很难，但这是一个有明确定义的问题。没有契约，测试跨功能一致性就是在测试一个只存在于分散工程师脑海中的隐性规范。

共享风格治理不只是关于语气

当团队谈论 AI 风格治理时，通常指的是语气和声音：正式还是随意，第一人称还是第三人称，谨慎还是肯定。这很重要，但只是容易的一半。

更难的是语义风格：你的产品如何引用自身的概念？如果搜索结果称某功能为"智能路由"，摘要称其为"智能路由系统"，对话助手称其为"路由系统"，用户会注意到，即使他们说不清楚为什么。跨功能的术语漂移会给人一种产品由零散部件拼凑而成的印象。

真正的语义治理需要：

• 规范实体词典：所有产品功能、套餐、角色和概念的权威名称。
• 禁用表达：已知会造成混淆或相互矛盾的变体说法。
• 声明权威映射：哪个功能是哪类声明的权威来源。计费功能拥有定价声明的所有权；文档功能拥有功能可用性声明的所有权；对话助手向两者推让，而不是从检索到的片段中综合自己的答案。

这种治理需要存放在所有功能提示都可以引用的地方——理想情况下是一个共享的系统提示组件或配置层，为每个功能的提示构建提供输入。只存在于某个 Notion 文档、靠某人记得去查看的治理，不是真正的治理。

大多数团队从未构建的一致性测试框架

一个常见模式：团队针对固定评估集测试 AI 功能的正确性，获得不错的分数，然后发布。没有人测试各功能之间是否彼此一致。

构建跨功能一致性测试框架，需要定义一组规范问题——你产品中多个功能都应该能够回答或至少不相互矛盾的问题——然后同时针对每个功能运行这些问题。框架随后标记出对同一主题做出不兼容声明的输出对。

这听起来很昂贵。实际上，一组涵盖你最敏感领域（定价、可用性、关键工作流）的 50–100 个规范问题，针对你的 API 运行只需几分钟，就能在用户截图之前捕获最具破坏性的矛盾。

相关工具仍在成熟中。自动检测任意 LLM 输出之间的矛盾很难，当前模型对隐性矛盾的检测能力较差。实际可行的方法是混合方案：使用语义相似度标记在同一问题上表现出可疑分歧的输出，再使用 LLM 裁判评估分歧是否代表真实矛盾。这能捕获高置信度的案例——那些出现在支持工单中的案例——而不需要完美的自动化推理。

一个附带好处：一致性框架还可作为回归测试套件。当你在某个功能中更新提示或升级模型时，你可以立即检查该变更是否破坏了与其他功能的一致性。这个反馈循环足够快，可以集成进 CI 流水线，并能捕获一类功能级评估所看不到的回归。

导致这一问题的组织模式

环境 AI 一致性问题部分是架构问题，部分是组织问题。它可靠地出现在以功能小队构建 AI 功能、却没有共享 AI 基础设施团队的团队中。

每个小队拥有一个界面：搜索小队、推荐小队、对话小队。每个小队有自己的 ML 工程师、自己的评估框架、自己的模型配置。小队之间在数据模式和 API 契约上协调，但不在 AI 行为契约上协调。随着时间推移，各功能逐渐分歧——不是因为有人做了错误的决定，而是因为没有人有权做出跨切割的决定。

组织上的修复不一定是集中式 AI 团队（尽管这有帮助）。而是一个指定的职能——通常称为 AI 平台或 AI 系统角色——拥有共享基础设施：响应契约、实体词典、一致性框架。各功能小队仍然拥有自己的功能。平台职能拥有使这些功能感觉像一个产品的连接组织。

这与十年前解决 API 一致性问题的组织模式相同。各团队拥有自己的服务，但平台职能拥有 API 网关、模式注册表和契约测试基础设施。没有这个职能，API 就会漂移；有了它，API 就会收敛。

没有一致性职能的 AI 功能，正处于 API 网关成为标准实践之前 API 所处的位置。工具不同，组织上的教训相同。

什么样的状态算是好的

一个解决了环境 AI 一致性问题的产品具有几个可识别的特征：

• 当同一个事实发生变化时，引用它的所有功能都更新到同一个新值，或者所有功能都优雅地承认不确定性，直到更新传播完成。
• 词汇足够一致，使得阅读不同功能输出的用户不会怀疑它们来自不同系统。
• 当用户通过不同界面提问相同问题时，答案不完全相同（它们不应该相同——搜索和对话是不同的模态），但不相互矛盾。
• 当功能出现分歧时，有一个明确的升级路径，并且经过了测试，而不只是有文档记录。

对于大多数团队来说，达到这一状态需要多个季度的努力。但第一步是认识到跨功能一致性是一个一等的工程关注点，而不是将每个功能单独做好就能自然涌现的副产品。在生产环境中感觉最值得信赖的功能，不是那些单个评估分数最高的功能，而是那些被设计为彼此一致的功能。