AI 体验不关心你的组织架构图

AI 正在把内容设计、企业内容策略、知识管理和模型行为带入同一个用户体验中。我们的工作方式还没有跟上。

想象一位财务经理试图弄清楚为什么供应商还没有收到付款。

企业应用显示发票已获批准。经理询问 AI 助手供应商何时可以收到付款，助手解释说发票已完成审批流程，可以付款了。

但事实并非如此。

发票被卡住了，因为开票金额与采购订单之间存在差异。审批和付款资格是两回事，由业务流程的不同部分来管理。

助手不一定误解了审批状态。但它未能理解这个状态与其他一切事物之间的关系意味着什么。

也许它检索到了关于发票审批的文档，却没有获取到关于付款拦截的信息。也许底层的业务概念在各个系统中没有得到一致的表示。也许它无法访问当前的付款状态。又或者它拥有正确的信息，却仍然未能正确解读。

这些是不同的问题，通常由不同的团队负责。

但从用户的角度来看，这就是一个体验——而它已经坏了。

这是随着 AI 成为企业软件的一部分而出现的最重大的挑战之一。我们正在把历来分别管理的内容和知识生态系统整合到一起，但还没有发展出相应的工作方式来管理它们之间的相互依赖。

我们不仅需要更好的 AI 模型、更好的内容系统或更好的设计指南。我们需要重新思考这些东西如何协同运作。

我们谈论的不止一次 AI 转型

让这一时刻难以把握的一点在于，我们往往把 AI 和内容当作在讨论单一的 变化。

事实并非如此。

在 2026 年为 Nielsen Norman Group 撰写的文章中，Sarah Gibbons 阐明了“AI 设计”的四种不同含义：用 AI 进行设计、设计 AI 产品、为 AI 智能体进行设计，以及设计 AI 本身。

这一区分很有价值，因为对内容工作的影响会因我们谈论的是哪一种 AI 设计而截然不同。

考虑两种场景。

在第一种场景中，产品团队使用 AI 来加速其现有的设计流程。它拥有一个内容设计系统，其中包含既定的术语、语气与语调指南以及交互模式。设计师使用 AI 生成候选的 UI 文案，内容设计师在发布前对其进行审阅和打磨。

AI 改变了团队产出内容的效率，但基本模式是熟悉的。人们在发布前设计并批准一组确定的内容，产品则根据既定的规则和条件展示这些内容。

在第二种场景中，产品会为每个用户动态生成内容，依据的是关于他们的任务、所处情境、系统状态以及相关企业知识的信息。

内容设计师无法预料或批准每一个可能的句子。相反，他们帮助设计这个系统，由它来决定体验应该传达什么、在什么条件下传达、受哪些约束，以及如何评估它是否有效。

这是一个根本不同的设计挑战。

还有另一个维度：一个需要充分理解同一产品、以便代表用户采取行动的 AI 智能体。对人类有意义的信息和结构，对智能体来说可能并不足够。系统需要对概念、关系、动作、约束和权限拥有可靠的表示。

这三种情形对应 Gibbons 分类中的前三类。第四类——设计 AI 本身——就是所谓的模型设计、模型行为、上下文架构或内容工程——并且它塑造着其他所有方面。

这些场景并非相互取代，而是日益并存，有时甚至出现在同一个产品中。

我们才刚刚开始理解这对内容工作意味着什么。

专业化在加深，相互依赖也在加深。

关于内容设计是否正在分化为不同专业方向，已有相当多的讨论。

一个方向是深入内容系统：结构化内容、可复用模式、指南、标准，以及让内容设计决策得以规模化的基础设施。

另一个方向是走向模型行为设计：塑造 AI 系统如何沟通、解读意图、处理歧义、解释其决策，以及在不同情境下做出响应。

我认为认可这些专业领域是有价值的。它们涉及不同的技术知识、方法和交付物。

但内容设计师还需要在另一个领域提升专业能力：让系统能够处理意义的语义与上下文架构。

分类法、本体和知识图谱正变得与我们设计的体验越来越相关。

这些并非可以互换的技术。分类法帮助组织和分类概念；本体定义某一领域内的概念及其关系；知识图谱能以系统可查询、可使用的方式表示相互关联的信息。

这些结构结合起来，有助于在各个系统之间建立共享的意义。

更广泛的上下文架构还需要考虑用户任务的信息、产品的当前状态、相关的业务规则、权限，以及决定在特定时刻哪些信息合适的其他条件。

对内容设计师而言，把这些概念学到足以与技术团队沟通，是一个起点。

但内容设计师还应学会主动参与塑造其所设计体验的语义架构。

信息架构师、知识工程师、数据专家和企业架构师为这项工作带来不可或缺的专业知识。内容设计师则贡献我们这一学科一直以来的核心：术语、概念模型、信息组织、用户心智模型，以及语言与理解之间的关系。

语义模型中编码的决策，会直接影响用户对产品的体验。

如果系统把两个业务概念表示为等价的，而用户却理解为不同的，这种不匹配可能会在导航、生成的解释、推荐或智能体行为中显现出来。

这就是一个用户体验问题，即使其根源距离界面有好几层之遥。

这也是我对在新兴内容专业方向之间划定硬边界持谨慎态度的原因。

我们需要能够深入内容系统、模型行为和语义架构的人才。但他们的工作需要共享模式、理念和原则，体验才能保持连贯。

企业用户可能会在传统界面、动态生成的解释、AI 对话以及执行 task 的智能体之间切换。

这些交互不会使用相同的语言，也不会以相同的方式运作，本来也不应该如此。但它们需要对产品如何运作有共同的理解。

专业化是合理的。我担心的是割裂。

AI 正在将彼此独立的内容生态带入同一个体验中

当我们把目光投向 UX 内容 设计之外时，挑战会变得更大。

企业长期以来一直将内容和知识的职责划分到不同的领域。

UX 内容设计团队负责产品体验、语言、交互模式和设计系统。技术传播团队创建和维护产品文档、帮助内容和教育材料。市场、支持及其他职能部门则各自管理自己的内容生态。

内容策略和内容运营建立内容模型、工作流、治理、生命周期流程以及规模化管理内容的系统，但通常局限于单个领域，而非跨领域。

信息架构塑造了每个领域内信息的组织、标记和连接方式。知识管理的差异更大：在一些组织中它意味着维护文档和知识库，在另一些组织中它意味着捕捉、分享和应用组织的专业知识。

如今，AI 工程团队正在构建能够检索知识、组装上下文、生成响应并让智能体行动的系统，这些系统往往依赖于所有这些不同职能部门所管理的内容和信息。

这些关联并非全新。文档一直需要反映产品的实际运作方式。界面中的术语应与支持内容中的语言保持一致。但团队通常可以通过定期评审、交接和独立的发布流程来管理这些依赖关系。

AI 正在改变这种依赖关系的本质。

AI 助手可能会利用技术文档在产品内回答问题。语义架构会影响它检索哪些信息以及如何解读这些信息。内容设计模式会影响助手如何传达其响应。而业务规则和权限则决定了智能体可以代表用户执行哪些操作。

这种体验越来越多地由不同团队管理的信息和设计决策组装而成，有时甚至是实时组装的。

这带来了新的运营挑战。当出现问题时，可能没有任何一个团队拥有足够的可见性或权限来诊断和修复问题。而且在一个系统中做出的更改，可能会对另一个团队拥有的体验产生影响。

这就是为什么内容运营和设计运营需要更紧密地协作。但协调不能止于此。它还需要涉及负责企业知识、语义架构、AI 工程和评估的人员。

我们需要规模化地做出协同决策

大型企业在规模化内容 设计方面一直面临困难。

一种应对方式是投资于可复用的模式、标准、指南、设计系统和运营流程，使团队能够打造更加一致的体验，而无需内容设计师亲自审核每一个决策。

但另一种较少被承认的应对方式，是接受质量参差不齐。当人员编制缩减或需求超出产能时，某些体验确实会得到更少的关注。这种妥协从来都不理想，但组织往往能够将其影响控制在特定产品或渠道之内。

AI 让这种妥协更难维持。术语、指南或源内容中的不一致，如今会影响众多交互中生成的响应和操作。

对可复用系统的投资正变得愈发重要。AI 还能让这些系统更强大，将指南直接带入体验设计与构建的工具和工作流中。 

但扩大内容生产的规模，并不等同于扩大内容设计的规模。

AI 可以帮助我们更快地生成更多内容。但这并不能保证内容是恰当的、连贯的、准确的或有用的。

扩大内容设计的规模，意味着让良好的设计决策在整个组织中可复用。

而且，这些决策越来越多地并不局限于某个团队的工具或流程中。

试想，当一家企业更改某个重要业务概念的术语时会发生什么。

传统上，内容设计团队可能会更新设计系统，并与产品团队合作修改界面文案。文档团队可能会按照自己的发布流程更新帮助内容和已发布的材料。

现在，我们可能还需要考虑这一变更是否影响分类法或本体、AI 助手检索什么、它在生成的解释中使用哪些术语、智能体如何解读请求，以及我们的评估测试将什么视为正确响应。

谁来识别所有这些依赖关系？谁来决定哪些变更具有重要意义？这些变更如何在不同系统之间流转？我们如何知道它们何时完成？

这些都是运营层面的问题。

将所有这些职能合并到一个组织中，可能会带来与它所解决的问题一样多的新问题。

我们需要的是一种更加整合的运营模式：在重要的地方共享标准、明确的归属、相互连接的工作流，以及能够考虑到决策如何在各系统间传播的治理机制。

具体而言，这意味着：

• 对企业术语和语义标准的共享治理，从而对重要业务概念的变更进行深思熟虑的决策，并将其贯彻到所有相关之处。
• 同时指导传统界面和 AI 行为的内容设计模式，使产品作为一个整体进行沟通。
• 能够在企业知识变更时识别哪些体验需要审查的工作流，让团队先于用户发现依赖关系。
• 反向运行的反馈循环，使我们从 AI 行为和用户理解中获得的认知，能够传递给能够修复源头的团队。

最后这一点值得比通常更多的关注。

如果测试发现 AI 助手始终误解某个业务概念，这一信息如何传递给负责底层知识、语义结构或内容模型的团队？

如果文档团队发现用户误解了某个特定流程，这一洞察会如何影响产品及其 AI 交互的设计？

我们花了多年时间探索在内容职能内部扩展工作的方法。现在，我们需要更好地在各内容职能之间扩展工作。

评估正在成为内容与体验运营的一部分

评估是这种相互依赖关系变得清晰的另一个领域。

对于传统 UI 内容，我们可以在发布前审查一组相对稳定的产出物。我们可以评估语言、与用户进行测试，并做出修订。

当 AI 系统动态生成回复时，我们无法预先审查每一种可能的输出。

相反，我们需要评估系统在不同情境下的行为，并随着系统、其知识以及用户需求的变化持续进行评估。

我们仍处于学习如何做好这件事的非常早期的阶段。

初期的大部分工作必须是探索性的。人们检查输出、识别模式、就某事出错的原因形成假设，并确定需要改变什么。

与发票问题一样，原因可能存在于多个环节。有时问题出在模型的行为上；有时系统检索到了错误的信息；有时底层内容不完整、过时或自相矛盾；有时系统缺乏正确理解请求所需的上下文。

有时回复在事实上是准确的，但仍然代表着糟糕的体验。

它可能误解用户的意图、不恰当地传达不确定性、未能解释重要的限制，或在未充分了解用户需求的情况下建议采取行动。

这些是不同类型的问题，需要不同类型的专业知识。

我预计我们会更擅长将所学转化为评估（evals）：即评估 AI 系统在既定预期下表现如何的可重复测试。这些测试可以帮助我们识别反复出现的故障、评估变更的影响，并随着时间的推移改进系统。

但首先，我们需要弄清楚我们到底在评估什么。

仅仅询问回复是否准确是不够的。我们还需要询问它在特定情境下是否恰当、是否支持了用户的目标，以及作为整体体验的一部分是否合理。当系统推荐或采取行动时，我们还需要评估用户是否理解正在发生的事情，并保留了适当的控制权。

回到那位财务经理的例子。如果一项评估只检查助手是否准确描述了审批状态，那么那条回复就会通过评估。但财务经理仍然不知道供应商何时会收到付款。

面对糟糕的 AI 输出，一个诱人的应对方式是给系统提供更多上下文。但更多并不一定更好。无关、过时或相互冲突的信息实际上会让回复变得更不可靠。挑战在于确定在特定情境下需要哪些知识、规则和关于用户任务的细节，并利用评估来了解我们是否提供了正确的上下文。

这是内容设计师与策略师、设计研究员、AI 工程师，以及负责企业知识与语义架构的人员需要紧密协作的另一个领域。

随着这些实践的成熟，我们将能够自动化更多的评估工作。但人的判断仍然至关重要，不仅用于评估输出结果，也用于识别新的失败模式，并完善我们对良好 AI 行为的理解。

这一点对体验质量尤为重要，因为体验质量的成功取决于上下文、用户期望以及那些并不总能轻易简化为通过或不通过的判断。自动化评估与人工评估需要协同工作，相互提供信息并相互改进。

运营上的挑战在于，如何将我们通过评估所学到的东西转化为对相关系统的改进。

评估发现不应止步于识别一个糟糕的响应。它应帮助我们诊断需要改变什么，无论是模型的指令、它检索到的知识、语义架构、交互模式，还是底层的业务流程。而这种诊断需要传达给能够解决这些问题的人。

然后，这些改动需要被治理、测试和维护。

评估过去是设计流程末端的一个检查点。如今，它正成为我们维护体验本身的方式之一。

企业知识正在成为体验架构的一部分

这一切背后有一个更大的转变。

我们常常把内容视为通过产品和系统来生产、管理和交付的东西。

但 AI 正使内容和知识对这些产品与系统能理解、沟通和执行的事情变得日益重要。

企业知识正在成为体验架构的一部分。

这并不意味着每份文档都会变成产品组件，也不意味着每个内容专家都需要成为 AI 工程师。

它的意思是，关于信息如何被结构化、表示、治理和提供的决策，可以直接塑造一个体验的行为和质量。

这也意味着，设计体验与设计支撑它的知识之间的界限正变得越来越难以维持。

我并不是说有人已经为这项工作找到了正确的组织结构或运营模式。我肯定没有。我们才刚刚开始理解这场变革的范围，而我们需要的实践将通过实验、协作以及从真实系统中学习来逐步形成。

但我越来越确信，仅靠各自独立改进每个学科是不够的。

我们需要在内容系统、模型行为、语义架构，以及创建、组织和维护企业知识的工作方面具备更深厚的专业知识。同样重要的是，我们需要更好的方式来连接负责这些工作的人和系统。

五年后，我猜人们会觉得显而易见的是：我们不可能在把产品内容、企业知识和 AI 行为当作基本独立的问题来对待的同时，设计出智能体验。

我们仍然需要专家。这些是值得深耕的复杂领域。

但我认为，我们也会对我们在共同设计的东西形成一种更加整合的理解。

体验并不在乎我们的组织架构图。

而日益重要的是，我们的组织架构图必须在乎体验。

AI 体验并不在乎你的组织架构图最初发表于 Medium 上的 UX Collective，人们正在那里通过高亮和回应这篇文章继续讨论。