北京
财务经理盯着屏幕，想弄明白一笔供应商款项为什么迟迟没付。企业应用里清清楚楚写着：发票已审批通过。他转头问AI助手，供应商什么时候能收到钱。助手回答得很干脆——审批流程已完成，随时可以付款。
但事实并非如此。这笔发票被卡住了，原因是发票金额和采购订单之间存在差异。审批通过和具备付款资格是两回事，由业务流程中不同的环节分别管辖。
助手未必搞错了审批状态。它只是没能理解，这个状态和其他所有信息放在一起意味着什么。
一个体验，背后是好几支团队的活
问题可能出在好几个地方。也许它检索到的发票审批文档里，压根没有付款拦截的相关信息。也许底层业务概念在不同系统里的表示方式并不一致。也许它拿不到当前的付款状态。又或者，它拿到了正确的信息，却依然没能正确解读。
这些是不同的问题，往往归属不同的团队。但从用户的角度看，这就是一个体验——而且它坏了。
这是AI进入企业软件后浮现出的最具后果性的挑战之一。我们正在把历史上分开管理的内容生态和知识生态捏合到一起，却还没发展出管理它们相互依赖关系的工作方式。光有更好的AI模型、更好的内容系统、更好的设计指南还不够，得重新思考这些东西怎么协同运转。
“AI设计”其实是四件事
这个时刻之所以难把握，是因为我们习惯把AI和内容当成单一的变化来讨论。并不是。
在2026年一篇为尼尔森诺曼集团撰写的文章中，Sarah Gibbons 阐述了“AI设计”的四种不同含义：用AI做设计、设计AI产品、为AI智能体做设计，以及设计AI本身。这个区分很有用，因为针对内容工作的影响，取决于我们说的是哪一种AI设计，差别巨大。
设想两种场景。第一种，产品团队用AI加速现有的设计流程。团队有内容设计系统，术语、语气语调指南、交互模式都已确立。设计师用AI生成候选界面文案，内容设计师在发布前审核打磨。AI改变了团队产出内容的效率，但基本模式还是熟悉的：人在内容发布前设计并批准一组确定的内容，产品按照既定规则和条件展示这些内容。
第二种场景，产品为每个用户动态生成内容，依据的是用户的任务、所处情境、系统状态以及相关的企业知识。内容设计师无法预判或批准每一个可能出现的句子。他们要做的，是帮助设计那个决定体验该传达什么、在什么条件下传达、受哪些约束、以及如何评估是否有效的系统。
这是根本不同的设计挑战。还有另一个维度：AI智能体需要足够理解同一个产品，才能代表用户采取行动。对人类来说合理的信息和结构，对智能体可能不够用。系统需要关于概念、关系、动作、约束和权限的可靠表示。
专业化在加深，相互依赖也在加深
这三种情况对应 Gibbons 分类中的前三类。第四类，设计AI本身，现在被叫做模型设计、模型行为、上下文架构或内容工程之类的东西——它塑造着其他所有类别。
这些场景不是互相取代的关系。它们日益共存，有时就在同一个产品里。我们对这对内容工作意味着什么，才刚刚开始理解。
关于内容设计是否正在分裂成不同专业方向，已有不少讨论。一个方向深入内容系统：结构化内容、可复用模式、指南、标准，以及让内容设计决策得以规模化的基础设施。另一个方向走向模型行为设计：塑造AI系统如何沟通、解读意图、处理歧义、解释决策，以及在不同情境下如何回应。
承认这些专业领域的价值是有意义的。它们涉及不同的技术知识、方法和交付物。但还有一块领域，内容设计师需要发展出更强的专业能力：让系统能够处理意义的语义与上下文架构。
分类法、本体论和知识图谱，与我们正在设计的体验越来越相关。它们不是可以互换的技术。分类法帮助组织和归类概念。本体论定义某个领域内的概念和关系。知识图谱能以系统可查询、可使用的方式表示相互关联的信息。这些结构合在一起，能帮助跨系统建立共享的意义。
更广泛的上下文架构还需要考虑用户任务的信息、产品的当前状态、相关业务规则、权限，以及其他决定某一时刻什么信息才合适的条件。对内容设计师来说，把这些概念学到能和技术团队沟通，只是起点。他们还应该学会主动帮助塑造所设计体验的语义架构。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
