AI 正在改写文档工作的边界。它改变了内容的生产方式，也改变了知识被使用的方式：文档既要服务阅读和操作的人，也开始成为 AI 与系统理解产品、提供服务的知识来源。

文档行业的转型由此从写作延伸到系统设计。如何深入企业业务场景组织和复用知识，如何让信息出现在用户需要的环节，如何持续维护内容的准确性，成为越来越重要的专业课题。信息架构、内容模型和用户体验，正与写作能力一起，塑造文档团队的新角色。

面对这场变化，ZStack 文档团队主动推进 AI Native 工作流改革：借助 AI，把内容经验转化为支撑生产与服务的系统；让产研与文档围绕共享上下文协作；将 AI 辅助检查与专业审核融入生产流程；再通过文档中心前端门户，把适配产品、版本和使用场景的知识交到用户手中。这场改革贯穿从生产到交付的全流程，落点是让用户更容易找到答案、理解产品、完成任务。

图 1 AI 推动文档工作向知识组织、协作机制和实际使用延伸

用户翻开文档，手头往往正有事要办

同一位用户，在不同阶段需要的答案并不相同。选型时关心产品能否适配，部署时关心条件与配置；进入使用、升级和运维阶段，又要判断操作是否适用、变更会影响什么、结果是否符合预期。

ZStack 按照用户旅程组织产品知识：《产品简介》帮助了解能力组成，《安装部署》说明环境准备与部署后检查；《用户手册》串起功能主线与操作指导，《升级教程》交代升级方式与验证要求，《可观测性》提供状态和日志的查看方法。文档让用户知道查哪篇，也帮助判断下一步该做什么。

图 2 按照用户旅程组织产品知识

这场“革命”，发生在文档开发全流程

1 写文档的人，也开始造系统

文档团队熟悉产品知识，也熟悉用户如何找信息、哪些条件容易遗漏、内容怎样组织才好维护。现在，这些经验进一步进入了信息架构、系统设计与功能验证。

在 AI 的帮助下，团队主导内容生产与服务系统的开发和迭代，把内容组织、协作和质量管理中的实际需求，转化为可使用的功能。写作之外，内容模型、数据组织和用户体验也成为专业能力的一部分。团队各有专长，通过协作连接这些能力，让专业积累既体现在文档里，也体现在支撑文档工作的系统中。

图 3　以内容专业能力为根基，向系统、协作与用户体验延伸

2 产研与文档共用工作流，上下文直接接上

一条操作步骤背后，往往连着环境前提、版本条件和配置依赖。这些就是文档需要带齐的“上下文”。协作越早接上，内容就越有机会随着产品变化一起更新。

从传统瀑布式阶段交接，到敏捷式迭代内同步，再到 AI Native 围绕共享上下文开展人机协作，变化体现在信息如何流动。ZStack 产研与文档团队已在统一工作流中协作，由 AI Agent 辅助记录、整理和追踪会议、讨论及资料。文档人员据此查找依据、衔接产品进展，专业人员确认事实与操作边界。用户看到的简洁说明，背后有一条可以回查的依据链。

图 4　协作方式对照：从传递阶段结果，逐步走向共享依据与持续协同

3 生产提速，AI 质量门禁同步上岗

写得更快，也要检查得跟上。ZStack 产研侧已有 AI 质量门禁，文档侧也建立了配套检查，关注产品事实、版本适用性和操作完整性。AI 帮助定位依据、提出疑点，专业人员结合目标环境判断和处理，并把检查结论留在工作流中。

检查需要落到具体内容。以 ZCF《安装部署》为例，启动 Installer 时设置的安装包目录，需要与后续配置中的本地目录一致；安装介质还要匹配 CPU 架构。当这些内容被修改或复用时，命令、参数说明与适用条件能否一起保持正确，就是值得核对的问题。

图 5 AI 质检辅助专业复核的工作流程示意

4 一路接到用户手里，交付才有了落点

面向用户的文档中心前端门户已上线，产品知识也有了更直接的交互方式。以 API Explorer 为例，用户阅读接口说明时，可以通过“询问这个 API”调起 AI Assistant，围绕当前接口的参数、调用方式和错误响应继续提问。

例如，查看“获取插件”接口时，用户可以问“这个接口需要哪些参数？”，再结合问答与原文，核对 pluginId 的填写位置、必填要求和认证方式。接口说明与 AI 问答相互衔接，帮助用户把知识用到具体任务中。从内容开发到阅读与提问，交付的价值由此落在用户的下一步行动上。

关联阅读：基于 AI Agent 的 ZCF API 文档全链路自动化

图 6 API Explorer 将接口说明与 AI 问答衔接起来，帮助用户理解调用要求

在企业级复杂度中，把变化落到实处

1 产品会组队，文档得分清角色

一个产品组合，可能涉及虚拟化、迁移、统一管理等多种能力。用户带着任务来，需要先找到相关组件，再进入对应的操作说明。

以 ZVF 文档为例，产品总览帮助读者了解整体能力，组件文档承接具体任务。准备做迁移的用户，可以进入 ZStack ZMigrate 用户手册，沿着安装部署、资源管理、迁移任务等章节继续阅读。产品定位、组件职责与操作路径，在同一套文档体系里各有位置。

这类内容组织需要分阶段验证：先梳理结构与组件边界，再逐步核对目录、引用、图片和内容归属；中英文沿用一致的组织思路。每完成一部分，就多一份可检查、可继续维护的结果。

图 7　从 ZVF 产品组合进入 ZMigrate 组件手册，再找到前提条件与操作步骤

2 文档要跟上版本，也要经得起使用

同一组件进入不同产品组合，共用内容可以复用，产品差异和版本条件仍需保留。团队持续以真实版本交付检验内容依据、适用关系和交付一致性，并在实际阅读与交付场景中验证不同形态的文档产物。

这些实践提供了一种实用的检查思路：信息能否找到依据，产品、版本与条件是否清楚，操作是否有可判断的结果；实际执行后的检查结论与专业确认，也要留下记录。

打开 ZCF《安装部署》的“部署后检查”，就能看到这种思路在内容中的落点：Installer 与应用市场安装有各自的检查标准，还要核对日志和页面是否可达。资源数据是否可见，则需要结合基础设施组件是否已接入判断。对用户来说，步骤后面有明确的结果与条件，才知道工作是否完成、下一步该查什么。

图 8 ZCF“部署后检查”把安装方式与结果标准对应起来

此外，产品文档还与知识库中的故障排查、技术方案、补丁与更新、产品已知问题相互补充。系统的产品说明与具体问题的处理经验，共同服务用户从理解产品到解决问题的过程。

关联阅读：ZStack 企业级知识工程实践：如何“造”出可信知识？

工作方式的革新，走向长期的竞争力

少一次重复查找，少一些来回确认，一份说明就有了具体价值。专业知识被持续维护和复用，团队的经验也就能更长久地服务用户。

ZStack 将继续深化 AI Native 内容管理与运营，把专业经验带进系统，把检查与责任落实到过程，让产品知识更好地服务人，也为 AI 提供可靠的内容基础。

欢迎访问 ZStack 文档中心，中文站：ZStack 资源中心，英文站：ZStack Resource Center。