封面

知识文档管理现状报告 2026

我们每年审视文档与知识基础设施正在如何变化——从团队如何创建和维护文档，到 AI 代理如今如何阅读这些文档。

阅读报告

文档已成为知识基础设施

AI 助手、编码代理和 MCP 服务器正在改变人们查找和使用产品信息的方式。2026 年《文档现状》研究考察的是：这一转变，对负责创建、治理并维护这些系统所依赖知识的团队意味着什么。

2026 年《文档现状报告》的关键发现

贡献者洞察

《文档现状报告》覆盖哪些内容？

2026 年的研究考察文档与产品知识的完整生命周期——从谁拥有知识、团队如何创建知识，到用户如何通过搜索、AI 助手、MCP 服务器及其他渠道发现这些知识。

章节导航

• 引言与受访者构成
• 购买决策与业务影响
• 文档团队结构与流程
• 文档与产品
• 文档工具
• 衡量文档成效
• AI 与文档创建
• AI 与文档消费
• 文档与职业发展
• 结语

购买决策与业务影响

购买决策与业务影响

选择产品时，文档有多重要

数字很明确：80% 的决策者总会或经常在购买前审阅文档，88% 认为它极其重要或比较重要。超过一半的人说「极其重要」。只有 5% 说文档不怎么重要。

文档在何处产生影响——以及团队还想要更多影响的地方

入职与功能发现同时主导当前影响和期望影响。72% 表示文档目前影响入职，68% 表示文档影响功能发现。这些是文档已经交付价值的基本盘。

新兴领域排在更后面：

• LLM/AI 表征：当前影响 32%——团队认为这里有大量尚未释放的潜力
• 线索获取/SEO：当前影响 24%——这是期望与当前现实最接近的领域

持续存在的缺口在信念与衡量之间。51% 的受访者表示文档对成交重要或必不可少，但 57% 不追踪来自文档的线索（另有 17% 表示不知道）。团队知道文档驱动收入，却没有把这条连接仪器化——这一主题在衡量文档成效中有深入探讨。

同比

文档在购买决策中的角色，已经固化为基准预期，而不再是一个增长中的趋势。80% 的审阅率和 88% 的重要性评分自 2025 年以来变化不大。

这种稳定值得注意：文档的商业重要性已经确立。机会不在于证明文档重要（那个论据已经成立），而在于衡量并优化已经存在的影响。

战略含义

文档是已被证明的销售资产——请按销售资产来对待。当 80% 的决策者会在购买前审阅文档、88% 认为它重要时，文档就是销售流程的一部分。把文档连接到转化指标的团队，能用领导层理解的语言证明这一点。

LLM/AI 表征是正在浮现的前沿。32% 的受访者表示文档目前用于「为 LLM/AI 提供表征」——这个类别在 2025 年还不存在。它也是当前影响与期望影响之间缺口最小的一项（-8 个百分点，入职则为 -28 个百分点），意味着团队已经把它看成高潜力领域。文档正在悄然成为喂养 AI 产品的数据层，现在就投入的团队，是在为发现正在去往的方向卡位。

转化缺口真实且可衡量。与去年类似，半数受访者表示文档对成交很重要，但大多数人不追踪这条连接。能把这项衡量做出来——把文档链接到注册、试用和收入——的团队，将获得显著的战略优势。

上一章：引言与受访者构成

下一章：文档团队结构

文档团队结构

文档团队结构

多少技术写作者才算够？

Usha Mandya 带领四名写作者，负责 Docker 的全部文档工作。团队挂在产品增长之下，采用文档即代码（docs-as-code）工作流，公开 GitHub 仓库配 Hugo，并与支持团队每两周同步一次，从工单模式里找出文档缺口。

“很多时候，文档团队很难获得认可。幸运的是，在 Docker，领导层理解文档能带来的价值。”

即便有领导层的有力支持，团队仍承担着很宽的职责范围——前端样式、部署和平台维护，却没有专职工程支持。

她的团队已开始试验由 AI agent 根据 GitHub issue 创建 pull request；她认为 AI 会接手更多常规工作，例如按风格指南做第一轮评审。

“分诊 issue、失效链接和修复……这些你传统上会指望写作者亲自过一眼的地方——正是 AI 正在接管的地方。”

Docker 最近上线了三个 agent，把这一点做实：新鲜度 agent 扫描现有内容，并在文档需要更新处开出 GitHub issue；PR 创建 agent 把这些 issue 变成 pull request；评审 agent 在变更发出前对照风格指南检查质量。

杠杆来自把 AI 用在重复性任务上，好让写作者聚焦更难的问题——理解新功能、与工程师协作，以及就用户真正需要什么做出判断。

Aleksandra Zolushkina 在 JetBrains 带一支更大的团队，面对的是同一挑战的另一个版本：规模下的一致性。 JetBrains 在其 IDE 产品家族中共有 17 名技术写作者。所有写作者共用一个仓库，并跨产品协调。

“我们不会把自己关在单独的房间里。我认为，确保技术写作者与产品团队充分融合非常重要。”

每位写作者嵌入一个产品团队，同时也是更大的技术写作群体的一员。结果是：写作者离产品足够近，能发现别人错过的东西。

“我们能非常贴近自己开发并描述的产品。有时我们会发现别人注意不到的 bug，因为我们使用 IDE 的方式非常特定。”

规模挑战无处不在。New Relic 的 Vinay Payyapilly 描述了 1:11 的写作者与产品经理配比：“说到产品，每位写作者都覆盖非常大的表面积。我的团队让这一切看起来不过是办公室里平常的一天。”

Booking.com 的 Marco Spinello 则抓住了 嵌入式模式在规模下的现实：“我们人很少，还分散在全公司。通常会有一个主团队要服务，然后再加上一堆协作的其他团队。”

无论是四名写作者还是 17 名，真正奏效的团队并不是编制最大的那些，而是：嵌入产品的机制最清晰、最能落实一致性、并在事事都像紧急时最能决定优先顺序的那些。

27%

文档团队向产品汇报——最常见的汇报线

55%

表示由技术写作者主导文档责任

文档团队几乎能以任何配置出现——从初创公司的一名独立写作者，到遍布全球企业的 250 多名从业者。本节表明：单凭人数，几乎说明不了什么。四人团队可以胜过规模大得多的团队；一名写作者也能搭建起覆盖全公司的体系。

真正驱动质量与可持续性的，是团队如何嵌入：写作者是否离产品足够近，能抓住别人错过的东西；组织是否想清楚了谁对什么负责；以及他们是否还有其他写作者可以协作、分享最佳实践。

所有权这个问题，在 2026 年比以往任何时候都更紧迫。AI 在压缩产品周期，文档时间线也随之压缩。没有清晰结构的团队，对这种压力感受最深，数据也反映了这一点。本节考察：谁对文档负责、团队如何组织、他们在组织架构中处于何处，以及这些结构选择对团队跟上节奏的能力意味着什么。

“我们不会把自己关在单独的房间里。我认为，确保技术写作者与产品团队充分融合非常重要。”

JetBrains

“我嵌入在工程团队里，也在他们的 Slack 频道中。这就是让文档保持同步的办法——你必须待在信息所在的地方。”

Gravitee

“我们是集中式团队，但写作者本人会嵌入 Docker 内部的多个团队。他们参加站会和规划会，但我们仍作为一个技术写作团队聚在一起。”

Docker

“我们有一支非常庞大的技术写作者团队——现在全球已超过 250 人。”

ServiceNow

谁对文档负责

技术写作者以 55% 领先，但产品（44%）和工程（39%）紧随其后。客户支持（29%）是 2026 年新增的显式选项，近三分之一受访者选择了它，确认文档是一项跨职能责任。

文档团队如何组织

集中式团队仍是最常见的结构，占 35.6%，但 22% 的组织完全没有正式文档团队。混合模式——中央团队加上部分分散支持——占 16%，且在增长。

组织架构对 AI 就绪很重要——我们测试过的每个维度都呈现同一模式。没有正式文档团队的组织，在 AI 驱动功能采用上落后（60% 对 79-81%），在 AI 创作使用上落后（经常使用 70% 对 79-80%），在治理上更是大幅落后（有 AI 指南的占 26%，对比 47-49%）。数据很清楚——在面向未来和 AI 方面领先的团队，都有正式组织起来的文档团队。

文档在组织架构中的位置

文档团队最常向 产品（27%）或 CEO/领导层直接（20%）汇报——较少向工程（13%）、支持（9%）或市场（5%）汇报。

同比变化

团队结构数据从 2025 年到 2026 年相当稳定。

文档责任的跨职能性质保持一致，技术写作者、产品和工程在两年中都扮演重要角色。

2026 年调查新增了 「不知道」 选项，这可能解释了 「没有正式文档团队」 的下降。

战略启示

有专职文档团队的组织会交付更多 AI 功能。 拥有集中式或混合式文档团队的公司，在 AI 功能采用上领先；即便是分散式团队的公司，也比没有专职文档团队的公司表现更好。规划文档组织的公司，应考虑把团队结构设计成：文档从业者能够互相学习、互相教授。

小团队在扛大负荷。 在 New Relic 这类公司，写作者与产品经理配比达到 1:11，行业正在要求很小的团队覆盖很大的产品表面积。这些团队可以凭借良好的体系和 AI 辅助工作流发挥超出身量的作用，但组织应诚实面对自己在向文档团队要求什么。

工程速度提升会冲击文档团队。 AI 编程助手正帮助一些工程团队以前所未有的速度交付功能，这意味着文档团队需要跟上。加速工程的同一批 AI 工具也可以加速文档——但前提是团队投入去采用它们。

“我的第一衡量标准是：我给开发者还回了多少小时。”

lizargall.github.io/

上一章：购买决策

下一章：文档与产品

文档与产品

文档与产品

你写的不只是文档，你在建立信任。

Manny Silva 负责隐私即 API 公司 Skyflow 的文档。他也是开源文档测试工具 Doc Detective 的创建者，以及《Docs as Tests》的作者。他的方法是：如果文档告诉用户某件事如何工作，它就应当可测试——而且这些测试应当自动运行。

“文档是在与用户订立一份契约，告诉他们正在使用的东西应当如何工作。如果其中任何陈述无效，就会削弱他们对你产品的信任。”

Doc Detective 对着生产环境、使用真实凭证运行，执行每一条可测试的操作步骤，并把实际行为与文档所述加以比对。

“文档在发出去之前需要通过测试。我有一个作为团队一部分由我持有的 Skyflow 生产账号，我们在环境里用这些凭证测试每一道能测的流程。”

与验证孤立行为的合成行为驱动开发测试不同，基于文档的测试映射的是真实用户体验。工程团队对此表示欢迎，因为端到端测试是最脆弱、也最难从工程视角设计的。

这种方法捕获了其他测试层不会捕获的问题——包括第三方集成在未通知的情况下发生变化。

“我听说过有人发现第三方直接改了集成。他们的工程师不可能告诉他们，因为这不是内部的事，但他们发现了，因为测试开始失败。”

Adyen 的 Sean Huck 从组织侧切入同一问题。 他管理九名写作者，并致力于把文档在产品开发生命周期中的角色正式化。

“我们的一个大目标，是被写进每个产品团队的完成定义（definition of done）。如果能做成，我会特别兴奋。因为那样它就成了正典，他们必须遵守。”

Silva 通过测试把文档与产品的连接自动化，Huck 则通过关系和流程来建立它。他的团队跨产品的可见性，变成了一项战略资产。

“我们希望在整段旅程中成为那种思想伙伴——这让我们能够帮助引导产品方向。”

“产品团队只对其中一片负责。文档团队必须考虑所有因素，这给了我们宽得多的视野，而这实际上变得相当有价值。”

dbt Labs 的 Mirna Wong 抓住了这一演变。她的团队已建立自动化，以检测代码变更、通知文档团队，并更利落地接入产品开发生命周期：“我们在使用 agent 工作流，这样工程师就不必记得在需要文档时告诉我们。” 他们也已从「文档即产品」（docs as product）——文档作为产品开发周期的一部分——迭代到「文档作为一款产品」（docs as a product），文档拥有自己的用户画像、用户旅程和专职 UX 研究。

无论是通过自动化测试、正式的流程整合，还是嵌入式团队结构，最有效的团队都找到了办法去检测、验证，有时甚至塑造产品会变成什么样。

30%

将保持文档同步列为单一最大的工作流挑战

35%

现在通过 AI 驱动的搜索发现文档

文档向读者做出承诺。当某道步骤写错、功能上线却没有文档、或产品变了却没人更新页面——这份承诺就破裂了。这些从业者把整套方法建立在缩小「产品实际做什么」与「文档说了什么」之间的差距上，因为他们见过这条差距不受约束地扩大时会发生什么。

30% 的受访者将保持文档同步列为单一最大的工作流挑战，几乎是第二名的两倍。但同步问题只是文档与产品关系正在变化的一部分。

用户找到文档的来源正在变化。AI 驱动的搜索现已占发现途径的 35%，与传统搜索引擎的差距正在收窄。他们在何处访问文档也在变化，MCP 服务器和编程 AI 助手几乎在一夜之间成为主要渠道。本节覆盖这三方面：保持最新的挑战、超越文档站点的扩展，以及团队正在穿越的新发现格局。

头号挑战：保持文档同步

三分之二（67%）依据产品变更更新文档，39% 使用客户反馈闭环。但 21% 完全没有正式流程。

这一挑战因角色而显著不同。工程师感受最深，达 43%，技术写作者为 26%。这说得通——工程师看着产品在变，也知道文档正在落后，而写作者同时在应付多项优先事项。

文档正在越出文档站点

40% 提供产品内帮助（嵌入式帮助、工具提示）。与 AI 相邻的渠道正在快速出现：18% 的用户已经通过编程 AI 助手（Copilot、Cursor）访问文档，16% 通过 MCP 服务器。对于两年前几乎还不存在的渠道，这些数字值得注意。

这些也是团队计划最积极投入的渠道。AI 助手（当前与计划之间相差 +9 个百分点）和 MCP 服务器（+8 个百分点）显示出最大的计划扩张——远超传统渠道。

用户如何发现文档

发现格局正在转移。直接导航（66%）和产品内链接（54%）仍领先，但 AI 驱动的搜索（ChatGPT、Perplexity、Google AI Overviews）已占文档发现的 35%——距传统搜索引擎的 45% 并不远。

这随公司规模放大：AI 驱动的发现从微型公司的 25% 升至企业的 46%。较大的公司更可能看到自己的文档经由 AI 渠道被消费。

本节是 2026 年调查新增内容，反映文档与产品开发日益缠绕。这里的大多数问题——工作流挑战、文档发现、文档站点之外的访问渠道，以及计划中的功能投入——都是全新的。不过，有一个关键问题从 2025 年沿用下来，并在下方比较。

2026 同比变化

「你如何确保文档随产品一起演进？」这个问题出现在两次调查中，变化不大。

尽管技术和文档领域还有其他重大发展，保持文档与产品对齐的流程仍然稳定。

战略启示

保持文档同步是普遍问题——需要系统性解决方案。 那 21% 没有正式流程的组织正在堆积文档债务。dbt Labs 这类团队展示了用 AI 辅助变更检测可以做到什么，但大多数组织尚未把这件事自动化。

AI 驱动渠道是增长最快的投入领域。 AI 助手和 MCP 服务器在当前使用与计划扩张之间的差距最大。不规划基于 AI 的文档交付的团队会发现：内容反正会经由 AI 被消费——只是不在他们的控制之下。

文档发现不再只关乎 Google。 有 35% 的用户通过 AI 驱动的搜索找到文档，只优化传统 SEO 已不够。文档需要为 AI 消费而结构化——自包含的页面、显式的上下文、结构化的元数据。

“就好像，我们是产品开发生命周期的一部分，百分之百深度参与其中。”

dbt Labs

上一章：文档团队结构

下一章：文档工具

文档工具

文档工具

「不必只是写很多字」

Chris Ward 负责开源 Firebase 替代方案 Supabase 的文档。他的团队拿公司自己的产品做内部试用——搜索跑在 Supabase 向量上，反馈组件也接入 Supabase。他还管理三层贡献者模型：内部员工、付费外部贡献者计划，以及开源社区贡献者。

“我们有工作流和工具——流程是为了帮助与公司和项目有不同程度参与的人，都能尽可能容易地做贡献。”

工具决策从未停过。Supabase 使用 MDX——Markdown 里一个非标准的角落——团队因此自建了 lint 工具，因为现有选项不支持它。他们现在正在迁到 Vale。

“〔自建 lint 方案〕用起来相当不错，但现在再用它就不那么说得通了，因为我们可以改用 Vale，不必再维护自己的东西。我们可以借助那个社区。”

但一个更大的架构挑战正在出现：

“我们的不同产品是分开的项目，所以重要的是围绕每一个把文档模块化，同时又确保它能聚合成一个连贯的整体。”

Ward 也看到文档人正在从写作扩展到更广的开发者体验——入职流程、CLI 工具、交互式体验。

“我非常相信交互式体验，或好的入职、或 CLI 工具。作为文档人，我们可以影响所有这些——不必总是只写很多字。”

Delfina Hoxha 从另一个角度看待工具——不是平台，而是它们底下的结构。 作为信息架构顾问，她多年来与这样的公司共事：工具没问题，内容组织却是坏的。

“没有 IA（信息架构），就没有 AI。”

每一项 AI 驱动的文档功能——聊天机器人、搜索、MCP 服务器、内容 API——都依赖底下结构良好的内容。

“说『先扔到文档站点上，AI 以后会搞明白』的人是错的。如果你一开始就有像样的信息架构，AI 也会更容易搞明白。”

她主张基于受众的路径区分，以及 「每一页都是第一页」 原则——用户从搜索、AI 工具和深层链接抵达，所以文档不能假定一条线性阅读路径。她也看到公司在内容和 AI 的交汇处设立新角色：专注于提示词创建指南和 AI 交互设计政策的岗位。

Booking.com 的 Marco Spinello 用一则轶事抓住了这一转变：在安装了 Vale MCP 服务器并接到 Claude Code 之后，他「从『我为什么会想要一个 Vale 的 MCP 服务器』变成了『现在没有别的办法了』。」

工具变得很快，但教训是一致的：工具只有在结构健全时才管用。或者如 Hoxha 所说——没有 IA，就没有 AI。

70%

在某种程度上把 AI 纳入信息架构决策

53%

使用自创的信息架构指南（最主要的做法）

文档领域的工具决策，过去大多关乎发布：哪个平台、哪种格式、哪套工作流。这仍是图景的一部分，但团队在问的问题已经扩大。

Chris Ward 在 Supabase 的团队正在搭建模块化文档架构，把不断增长的产品和项目家族拢在一起。Delfina Hoxha 的咨询工作从信息架构——工具底下的结构——开始，因为她见过太多团队撞上同一堵墙：平台没问题，内容组织是坏的；如果输入本身不连贯，再多的 AI 也修不好输出。

最后这一点正在数据里显现。近 70% 的团队现在会在某种程度上把 AI 纳入信息架构决策，比去年跳升 11 个百分点。正在构建最有效 AI 功能的团队已经明白：文档质量决定 AI 输出质量——这意味着工具决策和结构决策正日益变成同一个决策。本节覆盖团队如何发布、如何组织，以及 AI 如何同时改变这两者。

团队如何发布文档

专用文档工具以 45% 领先，其次是 开源平台/Git 仓库 21%，以及 网站发布平台 9%。

团队如何组织信息

说到组织信息，自创指南是最主要的做法，占 53%，其次是 Diataxis 和 DITA 这类 既有框架，占 28%。凭直觉的做法占 32%。文档团队正在让信息架构专业化。

AI 对信息架构的影响

近 70% 的团队现在会在某种程度上把 AI 纳入 IA 决策（「考虑」或「主要焦点」）。只有 20% 说他们在做信息架构选择时没有想 AI——46% 正在积极考虑，即便它还不是主要焦点。

正在构建最有效 AI 功能的团队明白：文档质量是决定 AI 输出质量的输入。

本节是 2026 年调查新增内容。2025 年调查问过发布工具，2026 年版显著扩大了覆盖范围，纳入信息架构做法，以及——关键的是——AI 如何影响 IA 决策。我们加入这些问题，是因为访谈显示工具选择日益由 AI 就绪驱动：团队不再只是选工具来发布文档，他们在搭建为 AI 功能提供动力的信息架构。部分问题从 2025 年沿用下来，并在下方比较。

2026 同比变化

在从 2025 年沿用下来的问题上，有些变化是有意义的。

信息架构上的变化并不剧烈，但在数据里看得见：自创指南上升 4 个百分点至 53%，既有框架（Diataxis、DITA）从 24% 上升 4 个百分点至 28%，而 凭直觉的做法从 37% 下降 4 个百分点至 32%。

最剧烈的转变：「做 IA 时不考虑 AI」这一组从 31% 缩至 20%（-11 个百分点），而「在考虑 AI 但还不是主要焦点」从 36% 猛增至 46%（+10 个百分点）。仅仅一年，AI 就从大多数团队在 IA 决策中不考虑的东西，变成了近 70% 会在某种程度上纳入的东西。

战略启示

信息架构是 AI 功能的基础——也是 AI 上下文的基础。 如 Delfina Hoxha 所说：「没有 IA，就没有 AI。」每一项 AI 驱动的文档功能——聊天机器人、搜索、MCP 服务器——都依赖底下结构良好的内容。随着 AI 工具日益把文档当作产品上下文的来源，你的信息架构质量直接决定 AI 输出质量。现在投入 IA 的团队，是在为接下来的一切打地基。

IA 的专业化正在加速。 文档团队在更系统地思考如何组织信息，既有框架在推进，凭直觉的做法在下降。

风格指南可以用 AI 落地运转。 Booking.com 的 Marco Spinello 把 Vale MCP 服务器接到 Claude Code，从怀疑者变成皈依者：「现在没有别的办法了。」当风格执行变成工具，而不是一份人们理应去读的文档时，一致性就能扩展到文档团队之外。

“如果我真想，我可以拉起一千个 agent，但接下来我会被埋在堆积如山的 PR 里。那更糟，因为我只会把自己耗在评审上。”

Skyflow | DocDetective

上一章：文档与产品

下一章：衡量文档成效

衡量成效

衡量文档成效

文档数据只有组合起来才说得通

CT Smith 是支付创业公司 Payabli 的技术作者。每个月，她都会产出一份内部「文档状态」报告，把来自 PostHog、Google Analytics、聊天日志、git 统计和 Linear 工单的数据组合在一起，并用一个 Claude skill 做半自动化。

「几乎没有任何指标需要单独说明什么。意义在于关联。」

这套理念决定了她如何解读每一项指标。参考页上的高跳出率，意味着有人很快找到了需要的内容；入门指南上同样的跳出率，则意味着他们放弃了。

「我提醒大家，不要想着设好就不管。文档指标必须放在具体情境里理解。它不只是收入。」

一项早期发现彻底改变了她的做法：68% 的用户直接去搜索，而不是浏览目录，这推动了一次大规模的信息架构（IA）重组。她还追踪从文档指向注册页和销售页的外链点击——这是文档到转化的一条直接路径。

Smith 会阅读文档站点上的每一段 AI 聊天会话，并为糟糕的回答建工单。她监测各项目的「每个故事点成本」，并追踪组件使用情况，以便为资源分配提供依据。出乎意料的是，反馈组件用处不大：没有任何外部用户点过赞/踩按钮。

Sandeep Medikonda 在 ServiceNow 把测量做到了完全不同的规模。 他在一家拥有 250 到 350 名技术作者、12 个网站、超过 60 种内容类型的公司，从零搭建了内容分析职能。即便是页面浏览量这类更简单的指标，他也在其上做出了精细分析。

「走进急诊室时，护士最先做的事情之一就是检查你的基本生命体征。对数字内容来说，页面浏览量就是这样的生命体征之一。」

但浏览量低的页面，可能只是在记录一个用户群很小却很忠实的功能——这种情况下，互动率其实可能非常好。

「这些指标单独拿出来都说不通。你必须把它们叠到产品情境之上。」

他最有力的指标之一是「未被查看的内容」。当数据显示某个产品领域 30% 的文档完全没有被消费时，就不得不进行艰难的对话。

「未被查看的内容是个非常敏感的话题。作者花时间围绕一些很棒的功能写出了很酷的文档，然后报告回来说：嘿，你写的东西有 30% 甚至没人看过。」

他对刚起步团队的建议很简单：不要等完美的分析技术栈。

「先看看你手里有什么数据。先拿到一些基础信息：进来多少人、他们在消费什么、你的重点领域是什么。只要从这些数据起步，就会开始激发同事们的思路。」

即便还没有分析体系，仅仅把工作的体量变得可见，也有价值。大多数工程和产品同事根本不知道你管理着多少内容。

「你能做的最好的事情之一，就是整理一份仓库体量快照。很多时候，开发同事或产品经理并不理解你所处理的上下文有多大。这会让他们更尊重你正在做的工作。」

回报来自持续性。定期分享数据，组织就会自己提出问题。

「你连续几个季度稳定地把它摆出来，更深的问题才会被问出来。这是一场数据素养之旅——随着所有相关的人习惯了自己看到的数字，他们会从各自的视角开始提问。」

Medusa 的 Shahed Nasser 补上了另一层：通过 AI 助手本身来测量。当她的文档助手答不上一个问题时，这个缺口就会被记为内容问题。Sigma Computing 的 Sarah Moir 提醒不要过度依赖数字：「你无法可靠地从定量数据中直接推导出意图。」

New Relic 的 Vinay Payyapilly 正在试验让 AI 智能体对文档提出标准问题并给回答打分。Liz Argall 则一针见血：「我的第一衡量标准是：我还给开发者多少小时？」

无论是两人小团队，还是专职的分析职能，真正取得进展的从业者都有一个共同点：他们从一开始就把测量写进工作流，并在情境中解读数据。

25%

完全不追踪任何文档指标

74%

认为文档对自助排障比较有效或非常有效

文档测量很普遍，但很浅。大多数团队会追踪点什么，但他们最依赖的那些指标，正在失去解释力。

*最清楚的例证，是 Ian Alton（Airbyte）讲述的 Tailwind CSS 故事：他们的文档变得太好，以至于 AI 智能体可以替用户写 Tailwind 代码。页面浏览量崩塌——不是因为文档失败了，而是因为它以指标看不见的方式成功了。Tailwind 依赖人类浏览量来提供线索，它的收入模型没有准备好应对这场突然、大规模转向智能体用户的变化。*

*这预示着整个行业正在走向的问题：随着 AI 越来越多地中介用户消费文档的方式，团队一直用来证明价值、并为业务结果做贡献的信号，将越来越指向错误的方向。*

这一节反复回到的悖论并不新鲜：团队相信文档能驱动业务价值，却很难证明。2026 年的新变化是，证明问题正在变难；而真正找到答案的团队，并不是在寻找一个万能指标。他们在建立测量体系：在情境中解读数据，把文档连接到领导层已经关心的结果，并诚实面对数字能说什么、不能说什么。

团队追踪哪些指标——以及不追踪哪些

排名靠前的指标是使用类信号，而不是业务结果：

四分之一的受访者不追踪*任何*指标，35% 不追踪内部流程指标。业务结果类指标（收入、转化、线索获取）徘徊在 11–12%——只是一小部分团队。

测量缺口随公司规模变化

测量缺口随公司规模变化。中型公司（51–300 名员工）测量最差——32% 什么都不追踪，而追踪的团队平均只看 1.7 项指标。企业级公司（301+）最好，只有 18% 的团队什么都不追踪。但即便这一段，平均也只为自己的文档测量 2.7 项指标。

文档在销售周期中的角色

正如购买决策与业务影响一章所探讨的，一半受访者说文档对成交很重要或必不可少——但 57% 不追踪来自文档的线索，39% 认为文档带来的线索比营销少。这种错位，正是本节所描述的更广泛测量缺口的症状。

排障：一项被低估的优势

74% 认为自己的文档对自助排障比较有效或非常有效。 这说得通，因为支持工单拦截是文档更常被提到、也更能被测量的价值主张之一。但和文档在销售周期中的角色类似，超过三分之一的受访者不以任何方式衡量这项成效。

人人都想要的那些指标——用户成功了吗？他们理解这个概念了吗？——需要知道他们离开文档页之后发生了什么。大多数团队没有这种可见性，而且可能永远也得不到。

同比比较

随着 2026 年调查引入了 2025 年没有的新选项（转化率、价值实现时间、「我不知道」），单项指标的采用率发生了变化，逐项直接比较变得不那么直截了当。

但在外部成功指标上，不追踪或不确定的团队比例仍然相近。

对内部测量而言，类别的增加让同口径比较变得困难。不过测量率仍有一定改善，不追踪任何指标的团队减少了 7 个百分点。

战略启示

测量缺口是文档领域最大的错失机会。 近一半受访者（49%）仍不追踪内部文档指标——低于 2025 年的 55%，说明有进展，但这仍是最常见的答案。那些搞清楚如何测量——把文档连接到转化、留存和支持工单拦截——的团队，将在论证投入和编制时拥有显著的战略优势。

从生命体征开始，而不是从完整的分析技术栈开始。 正如 ServiceNow 的 Sandeep Medikonda 所说，页面浏览量就像把脉——基础，但必不可少。团队起步并不需要复杂工具。盘点你的内容，追踪人们在消费什么，并持续分享数据。真正的洞察往往不来自任何一个单独数字，而来自看见数字如何变化——上线后页面浏览量飙升、重组后下降、搜索驱动流量稳步爬升。这种语感需要时间培养，而且只有你开始追踪才会出现。

但不要停在页面浏览量。 随着 LLM 消费文档内容、用户经由 AI 驱动的工具到来，页面浏览量单独能捕捉到的画面越来越少。团队应当叠入新的测量方法——转化追踪、AI 引荐指标、互动深度，以及产品行为信号（比如 Docker 追踪来自教程的仓库克隆）——以便更完整地理解文档实际如何被使用。

「如果我们没有拿到领导层能看见、工程师能理解、用户也能实际感知到的价值——文档就没有在做它该做的工作。」

Engineering Leader in Finance | Nivenly Foundation Fellow

上一章 文档工具

下一章 AI 与文档创作

AI 与创作

AI 与文档创作

「我们不是用代码建起来的。我们是用上下文建起来的。」

Sarah Sanders 在 PostHog 做文档工作。那里的四人文档团队运作起来更像产品工程团队，而不是传统写作小组。他们构建自定义 React 组件，管理基于 Gatsby 的平台，并运行正在重塑文档工作面貌的 AI 智能体。

她标志性的贡献是上下文工程（context engineering）——核心理念是：文档的未来不在于写得更快，而在于给 AI 系统提供足够的产品知识、风格规范和结构范例，让其产出值得精修，而不是推倒重写。

「我多次听到这个词……类似‘上下文工程师’。成为一个为用户、为机器人、或为两者精心打造上下文的高手。我认为这就是技术写作的未来。」

最具体的例子是 PostHog 的 AI 入门向导：一条 CLI 命令就能安装 PostHog、识别用户代码库中的事件并创建仪表盘——把几天的设置压缩到大约八分钟。

「那个入门向导的实现，90% 其实是我们写过的示例应用、从我们 MCP 服务器拉取的文档，再加上非常扎实的提示词测试。」

「工程师常常想用代码解决 AI 工作流，但你几乎只用文档、再加极少的代码，就能做出一整套 AI 工作流。」

Sanders 的团队还构建智能体，根据工程变更生成文档初稿 PR。目标不是完美——而是一个有用的起点。

「我们希望（该智能体）能让 PostHog 工程师从头到尾自主负责文档，理想情况下第一次就能完成 60%。」

但上下文质量就是一切。没有它，AI 产出制造的是更多工作，而不是更少。

「当我们没给它足够好的上下文时，它就完全乱跑。而且在我看来，这实际上会制造一个更难评审、更难跟上的积压。」

Ian Alton 在 Airbyte 也建了一套同样精密的系统，但重心在校验，而不是创作。 作为唯一的专职技术作者，他花了一年时间开发一个两阶段的智能体 QA 循环：发布前，AI 智能体评审未合并的 PR 并提出文档更新建议；合并后，QA 智能体对照源代码校验文档并标出不准确之处。

「相当早的时候，我就开始做一个智能体循环——平台里有一次提交之后，后台进程会拉起一个 AI 去评审那份文档，并就我们想做的任何改动提出建议。」

这套系统抓到过真实问题：

「严重的时候，可能是我们对接的第三方 API，权限模型的 scope 完全搞错了。任何人按文档去用，那天都不会好过。」

但若没有关于用户需求和产品情境的人类指引，AI 会产出技术上正确、实践上无用的内容。

「如果我让它看一个 PR 然后直接写成文档，它会产出一些非常漂亮、大概技术上也准确、但对任何人都没有用的信息。」

正如文档与产品一章提到的，dbt Labs 的 Mirna Wong 把流水线的另一块自动化了——一个智能体分析代码变更、检测面向客户的更新，并自动创建文档工单。Booking.com 的 Marco Spinello 则把 AI 用在批量操作上：把文档模板套用到 30 到 50 篇文章。「80% 是好的。我迭代了几次去微调提示词，并拆成多个步骤，好让 Claude 能增量推进。但一旦我把流程做出来，它完成了大量原本会非常、非常繁琐且容易出错的工作。」

这些从业者都没有把 AI 仅仅用来「把文档写得更快」。他们在解决具体瓶颈——信息收集、变更检测、QA 校验——并把人类判断留在最要紧的地方。

76%

经常将 AI 用于文档创作——比 2025 年的 60% 高出 16 个百分点

64%

认为 AI 将「极具影响力」——高于去年的 49%

用于文档创作的 AI 采用率已经跨过主流门槛。四分之三的从业者现在经常使用它，这个行业也比以往任何时候都更确信它会重塑工作。但标题数字掩盖了一点：真正从 AI 拿到价值的团队，并不是用得最广的那些。他们是用在正确地方的那些。

文档的瓶颈从来不是写作本身。它一直是信息收集、变更检测、校验——草稿存在之前和之后必须发生的一切。

从业者在这一节找到的杠杆正在这里：在作者还没开口之前就摊开他们需要的信息的智能体，在上线前抓住不准确之处的 QA 循环，否则要花上几天的批量操作。写作本身，结果往往是 AI 帮得最少的部分。技术作者报告的时间节省在所有角色中最小，因为有经验的作者本来写得就快。

没有跟上的是治理。大多数团队在没有指南的情况下使用 AI，而文档的准确性门槛几乎高于任何其他内容类型。一条错误的指令不仅会让人困惑，还会弄坏别人的实现，并侵蚀对产品的信任。本节覆盖谁在使用 AI、他们用它做什么、时间节省在哪里真实存在、在哪里并不存在，以及为何采用与治理之间的缺口是眼下这个领域最紧迫的问题。

AI 采用率：数字

76% 的受访者经常使用 AI（总是、经常或偶尔）进行文档创作。只有 11% 从不使用。转向 AI 的变化剧烈，而且全面一致。

四分之三的人预计明年会进一步增加 AI 使用，64% 认为 AI 将对文档「极具影响力」。

AI 用在哪些地方

排名最前的任务是起草（62%）、头脑风暴（58%）和校对（58%）。风格指南匹配（50%）也很可观。只有 25% 用 AI 整篇写完。通用 LLM 在工具使用中以 73% 占绝对主导，远远领先于代码助手（39%）和文档专用 AI 工具（26%）。

「我使用 AI 的主要方式是编辑辅助。我把 linter Vale 和大语言模型结合起来，执行我们的风格指南，并建议把内容改到符合这些标准的写法。」

Supermicro

「AI 给我的最大价值不是写得更快——而是信息综合更快。我可以把一份规格、一条 Slack 线程和一张 Jira 工单扔给它，几秒钟就得到一份连贯摘要。」

New Relic

「对我们来说，这看起来像是：当不是技术作者的人用智能体打开初稿时，我们做编辑和评审。就像‘上下文工程师’——成为一个为用户、为机器人、或为两者精心打造上下文的高手。」

PostHog

「我们正在受一点 AI slop（AI 灌水）之苦。我发了一些 issue，然后有太多人提交 PR——我想同一个 issue 大概收到了八个重复 PR。」

Supabase

时间节省：真实存在，但因角色而异

78% 报告 AI 让文档工作更快，其中 35% 声称节省了 50% 以上的时间。但这些收益分配并不均匀：

技术作者——最重的文档生产者——报告的收益属于最小的一批。离写作最近的人，报告的时间节省最小——正如 Sigma Computing 的 Sarah Moir 所说：「对我来说，自己把事情做完，往往比试着让 AI 替我做更快。」

「你刚试的时候，看起来应该能拿到 500% 的效率提升，真正落到实处，大概只有 20%。校验仍然非常难。」

Ritza

「通常，如果我能让 AI 帮我走到 80%，我就可以做最后的修改。但这只有在我们从一开始就真正把想要什么表达清楚时才可能。」

Airbyte

「人们对技术作者的预期已经变了——‘因为有 AI，这应该更快，那你为什么没有更快？让我再给你加更多活。’他们没有意识到，好内容确实需要人在回路里。」

KnowledgeOwl | The Not-Boring Tech Writer

「我昨天用 Claude Code 在我的信息架构里重命名了 600 个文件。我把六天的工作压缩成了一个下午。这大概就是我使用 AI 的方式——不是用来写内容，因为我发现必须改得太多。」

Payabli

治理落后于采用

只有 44% 拥有正式或非正式的 AI 指南，22% 没有制定计划。梯度很清楚：「总是」使用 AI 的人中有 55% 有指南，而「很少」使用的人中只有 30%。但即便在使用最重的人群中，也有 15% 没有指南、也没有计划。

「因为有 AI，我们比以往任何时候都更需要技术作者。现在正是公司加码文档的时候。」

Medusa

「当我们说一个智能体在幻觉时，我们真正在说的是一个正在饿死、缺少上下文的智能体。」

Airbyte

「我做了一些半自动化——我说‘半自动’，是因为我加了人在回路，这样 AI 不会自动改写任何东西。作者拥有最终决定权。」

Supermicro

「我们正在准备自己的指南，讲如何为 AI 写内容，但我们还没有任何基准。我不确定是否已经有人拥有通用基准。」

JetBrains

担忧：幻觉居首——且因角色而异

说到对 AI 文档的担忧，幻觉以总体 62% 居首——但这种担忧高度依赖角色。不同角色的担忧画像差异显著：

作者最担心准确性和技能退化。工程师更担心成本、法律问题和用户信任。这两个与文档协作最紧密的群体，看到的是根本不同的风险画像。

2026 年新增

2025 年调查包含关于将 AI 用于文档的基本问题。到 2026 年，我们大幅扩展了 AI 创作部分，覆盖治理、分角色担忧、高管与从业者的优先级差距，以及 AI 采用强度与团队实践之间的关系。AI 采用的快速推进——以及随之出现的治理缺口——让这种更深入的覆盖变得必要。从 2025 年沿用下来的问题，比较见下文。

同比比较

AI 采用数字呈现出整份调查中最剧烈的同比变化。

常规 AI 使用（总是、经常或偶尔）从 60% 跳到 76%——一年之内增加 16 个百分点。「从不」使用者减半，从 25% 降到 11%。用于文档创作的 AI 已经跨过主流门槛。

认为 AI 将「极具影响力」的比例从 49% 升至 64%（+15 个百分点）。这个行业不只是用得更多——它比以往任何时候都更确信 AI 会重塑工作。

战略启示

AI 正在正确的地方交付真实价值。 78% 报告 AI 让文档工作更快，而排名最前的用例——起草（62%）、头脑风暴（58%）、校对（58%）和风格执行（50%）——反映出从业者找到了真正的杠杆。从 AI 拿到最多的团队，是那些识别出 AI 擅长的具体、可重复任务的团队，而不是试图把它用到所有事情上。

上下文把有用的 AI 产出和噪声分开。 正如 PostHog 的 Sarah Sanders 发现的，没有好上下文的 AI「完全乱跑」，制造的是更多工作，而不是更少。或者如 Airbyte 的 Ian Alton 所说：「当我们说一个智能体在幻觉时，我们真正在说的是一个正在饿死、缺少上下文的智能体。」真正见到结果的团队不只是在提示——他们在建设上下文系统：产品知识、风格范例和结构模式，让 AI 产出值得精修，而不是推倒重写。

治理需要赶上采用——因为准确性和信任不可妥协。 AI 使用率是 76%，但只有 44% 的受访者拥有指南。文档的准确性门槛高于大多数内容：一条错误的指令就能弄坏用户的实现，并侵蚀对整个产品的信任。AI 工具对创作确实有用，但组织需要把质量检查放到位——不是为了拖慢采用，而是为了保护让文档首先变得有价值的那种信任。

最大的 AI 赢面不在写作——而在工作流的其余部分。 文档中最显而易见的 AI 用例是起草，它也是最常见的（62%）。但从业者发现，更深的杠杆在别处：从工程工具收集信息、检测产品变更、对照源代码做 QA、规模化执行风格。技术作者——最重的文档生产者——报告的 AI 时间节省最小（31% 达到 50%+），部分原因是有经验的作者本来就擅长写作本身。瓶颈从来不是那些词。

上一章 衡量文档成效

下一章 AI 与文档消费

AI 与消费

AI 与文档消费

「对人好，并不等于对智能体好」

Dachary Carey 是 MongoDB 的「程序员作者」（programmer writer）。她在做一件文档从业者很少尝试的事：系统、实证地测试 AI 智能体究竟如何消费文档。不是理论——而是在多种智能体与模型组合上动手实验，追踪智能体撞上真实文档页面时会做什么。

她的发现挑战了若干被广泛接受的假设。第一条：llms.txt 文件能可靠地把智能体引导到结构化内容。

「结果是，很多智能体根本不知道 llms.txt。这是非确定性的。它有时会从模型训练数据里带出这么一个念头：某处有这么一个文件可以用。有时则完全没有。」

第二条：智能体会消费完整的文档页面。

「一页可能有 20,000 个字符。但有些智能体对能看到多少内容有机械上限。有时智能体知道发生了截断。有时它完全不知道，只是默默地没把你页面里 15,000 个字符端给你。」

第三条——也最有争议：为人写得好，就自动等于为智能体写得好。

「我不认为对人好的东西对智能体也好。Token 很贵，上下文是一种公共品。智能体需要的是能帮它完成任务的、尽可能小的文档单元。而这大概不是我们心目中对人好的写法。」

她发现，具体的智能体—模型组合影响极大；有些智能体还会在幕后把任务委派给更小的模型，问题因此叠加。MongoDB 已经在用跨职能方式应对——教育 AI 团队做行为评估，与信息架构师一起改文档，再监测是否改善。文档上的改动，能在数周而非数月内改善模型回答。

「智能体是一种新用户。」

她还做了开源工具 afdocs，用来按她的《面向智能体的文档规范》（Agent-Friendly Documentation Spec）审计文档页面。

Bekah Hawrot Weigel 在测另一面：你能不能主动为 AI 消费优化文档，并看到可量化的结果。 目标是在三周内把「cloud agents」的排名从第 26 位推到第 10 位。她从审计现有内容、再按 LLM 消费方式更新入手。

「当时我想，就我一个人，这也太离谱了——不可能做到。但有一阵我们冲到了第八。」

文档在这类优化上有结构优势。

「博客差不多被当成转瞬即逝的内容。但文档多了一点可信度，因为它本意是长期资源。」

但 Weigel 同样清楚哪些 AI 功能划不来。她关掉了昂贵的 AI 搜索，因为用户只是把它当普通搜索用。

「如果我把工作做好了，把信息呈现成一眼就能扫到的样子，他们五秒内就能得到答案。」

成本图景也令人清醒。一位同事每月为 AI 订阅付 100 美元，却消耗了超过 3,000 美元的算力。

Christopher Gales 观察到，这场转变把关于内容形态的常规智慧颠倒了：「FAQ 本来快要退出舞台。文档社区里没人喜欢它们。结果发现它们几乎是给机器用的完美格式——问题清楚、答案清楚、容易解析。」

文档团队究竟是在为两类读者写作，还是为其中一类写好就能服务另一类——这个问题仍是核心张力。真正在测试、而不是在猜测的从业者，才找得到切实答案。

38%

已上线对话式 AI 界面——目前部署最多的 AI 功能

67%

认为 AI 让文档变得更好；仅 7% 认为变差了

上一节讲的是 AI 如何做文档。这一节讲的是 AI 如何把文档交出去。这个差别比看上去更要紧。

人读文档时，可以弥补含糊指令、跳过一段、或另找更好的解释。AI 智能体消费文档时，会按字面执行所写内容，可能只看到页面的一小部分，也没有办法示意「这里感觉不对」。当 AI 成为中介，文档质量的赌注更高；而大多数团队才刚刚开始认真面对这一点。

这一节呈现的，是一个处在转型中的职业。大多数团队至少上线过一项 AI 功能，多数人认为 AI 让文档更好了，对聊天机器人、AI 搜索和 MCP 服务器的投入正在加速。但 Dachary Carey 一直在问的那个问题——为人写得好，是否自动等于为智能体写得好——目前还没有定论。真正找到答案的团队，是那些做实证测试的团队，而不是假定两类读者想要同一件事的团队。

目前已部署的 AI 功能

部署最多的功能是对话式 AI 界面（38%）和 AI 增强搜索（36%），但仍有 26% 尚未上线任何 AI 功能。

有正式文档团队的组织，上线的 AI 功能明显更多。没有正式文档团队的组织中，41% 一项 AI 功能都没上过；集中式或混合式团队这一比例为 19–21%。

「正在发生一种转变：很多产品公司落后了。你的用户只是让智能体给他们做点东西，根本不提你的产品。如果你不在智能体的参照系里，你就永远不会出现。」

MongoDB

「对人来说，信任破裂会带来挫败、会带来流失。对 AI 来说，信任破裂可能带来相当难看的结果——一次失败的实现，或客户环境做出它本不该做的事。」

Airbyte

「llms.txt 到这一步基本上已经是入场券了，而且大多数平台都会自动给你生成。」

HackMamba | Technical Writing Uncensored

「如果我把工作做好了，把信息呈现成一眼就能扫到的样子，他们五秒内就能得到答案。」

Virtual Coffee

AI 让文档变好了还是变差了？

结论偏正面：67% 认为 AI 让文档变得更好（40% 略好，27% 好很多），只有 7% 认为变差了。在已经落地 AI 功能的人当中，感知最强的影响是可发现性——47% 同意或非常同意用户能更快找到信息。但对业务指标（文档使用量、注册）的影响没那么清楚，「中立」和「不跟踪」的比例都很大。

「对 AI 智能体更有价值的是概念理解。人在使用之前并不想先搞懂系统怎么运转——他们想更快到达解决方案。AI 智能体可能更愿意先理解系统，再去配置一切。」

GitBook

「你得确保所有上下文都烘焙进这一页，因为如果一次只消费一页，而你假设用户已经先读过别的东西——AI 并不会先去读那另一样。」

Little Language Models

「我不认为对人好的东西对智能体也好。Token 很贵，上下文窗口是一种公共品。智能体需要的是能帮它完成任务的、尽可能小的文档单元。而这大概不是我们心目中的好文章。」

MongoDB

「归根结底，人们解释事情、写东西，还是写给其他人的，哪怕中间隔着一层 AI。」

JetBrains

当 AI 成为中介，文档准确性的赌注更高。人也许能认出含糊指令并绕过去。AI 智能体会按字面执行。

团队如何看待面向 AI 的优化

这个职业处在转型中：

最常用的优化手法——补充显式上下文（30%）、让页面更自洽（30%）、投入结构化数据（26%）——其实是让文档对所有人都更好的做法。多位受访者的说法是：最好的 AI 优化，也许就是更好的写作。

「我们真的需要持续把高质量的知识和信息喂给语言模型。否则它们帮我们的能力会退化。」

Booking.com

「如果你想让文档对 LLM 可及，就必须直接回答『这份文档的目的是什么？』这类问题。人会自动抓住的潜台词和文学分析——你得写得超级直白。」

金融领域工程负责人 | Nivenly Foundation Fellow

「如果你把整个文档团队都裁掉、用 AI 来写全部内容，你实际付出的代价可能高得多。要是他们不再补贴这件事了，又会怎样？」

Virtual Coffee

「基本功还是得做对。Google 眼里的高质量网站，在一个人与 AI 同时写作的世界里，依然至关重要。」

ServiceNow

这个刻意反直觉的观察点出了张力：有时，为 AI 消费做优化，确实需要与以人为中心的文档设计不同的结构选择。

明年计划做什么

AI 聊天机器人（32%）和 AI 搜索（29%）领跑计划投入。MCP 服务器（25%）是快速兴起的类别。只有 15% 没有增加 AI 功能的计划。

安全：中等程度的顾虑，但不是拦路虎

56% 对外接 AI 集成感到安心（26% 非常安心，30% 还算安心）。16% 被卡住或非常谨慎。最主要的顾虑：数据隐私（51%）、合规要求（36%）、以及 AI 提供商的数据留存（35%）。

2026 年新增

这一节是 2026 年调查新设的。2025 年，「AI 与文档」被当成一个主题，主要聚焦创作。AI 驱动的交付渠道——聊天机器人、增强搜索、MCP 服务器、AI 引导入门——增长很快，值得单独成章。这里的大多数问题（AI 功能部署、感知到的质量影响、优化策略、安全顾虑）都是全新的。有两道题从 2025 年沿用下来，对照见下。

同比对照

被问到哪些情境化形态会在文档的未来中扮演更大角色时，每一类都在增长——但与 AI 相邻的那些涨得最快。情境感知辅助从 51% 跳到 62%（+11 个百分点），基于聊天的辅助从 51% 升到 59%（+8 个百分点）。交互式教程基本持平（51% → 53%），用户自定义、按需生成的文档从 39% 增至 45%（+6 个百分点），语音辅助从 19% 增至 26%（+7 个百分点）。这个职业的预期，正在汇聚到 AI 驱动、情境感知的交付，作为文档的未来。

认为 AI 将成为创建和维护文档的主要工具的比例几乎翻倍，从 19% 到 35%（+16 个百分点）。2026 年调查还增加了 2025 年没有的新选项：现在有 59% 表示团队在排版文档时应考虑 AI/LLM，41% 认为文档应按用户需求实时适配。只有 14% 认为 AI 不会有重大影响。

战略启示

文档正在变成 AI 基础设施。 每一项 AI 功能——聊天机器人、搜索、AI 入门向导——都依赖底下文档的质量。好文档驱动好 AI；差文档驱动差 AI。

为人写得好，大体上就是为 AI 写得好——但并非完全如此。 最常用的优化手法（显式上下文、自洽页面、结构化数据）无论读者是谁，都是好的文档实践。但像 MongoDB 的 Dachary Carey 这样的从业者，在边缘处发现了真实张力：智能体有硬性的 token 上限，会默默截断长页面，可能需要比人类读者更小、更原子的内容单元。这个问题没有定论——它是正在进行的实验领域，做实证测试的团队学到的最多。

AI 消费的格局变得比团队适应的速度更快。 从业者今天投入的工具和标准，明天行为可能就不同——智能体能力、模型上下文窗口、发现机制，全都是移动靶。这不是等待的理由，却是建设灵活文档架构、并衡量真正有效的东西、而不是想当然的理由。

要在 AI 功能上创新，就把文档当成一项职能——而不是一次性项目。 有专职文档职能的团队在 AI 功能采用上领先；没有正式文档团队的组织中，41% 一项 AI 功能都没有。优势不只是人数——而是专职团队能互相学习、建立项目、分享有效做法、并迭代。AI 驱动的文档创新，需要那种只有把文档当作持续学科才会有的制度知识和交叉授粉。

「城里来了新读者，你也得确保为他们服务。」

Airbyte

上一节：AI 与文档创作

下一节：职业与专业发展

职业发展

文档与职业发展

AI 在改变工作，而不是取代工作者

Vinay Payyapilly 在 New Relic 带领文档团队，从事技术写作已超过 25 年。AI 时代给他带来了职业生涯里最有意思的管理挑战之一：同时从两个方向驾驭对 AI 的预期。

「一边管理领导层的预期，一边管理团队的恐惧。让所有人冷静下来，告诉他们我们还没到那一步。这对干系人和领导层如此，对我的团队也是——让他们安心，让他们知道我们在做的这些实验，并不只是为了取代他们这些作者。」

Payyapilly 的团队没有坐等 AI 以威胁的姿态到来，而是先找出真正的瓶颈：不是写作，而是等待信息。他做了一个智能体，监控 Jira、Confluence、Figma 和 Slack，在作者开口要之前就把他们需要的东西浮出来。

「现在我不用再等人回我了，这才真正改变了局面。比写作本身更重要，因为东西我们可以写得很快。」

他对作者的建议很直接：拥抱技术，但要明白真正的 AI 熟练意味着什么。

「对 AI 感到自在，意味着让它从特定资源里综合内容，并写出将由别人消费的内容。你还得知道坑在哪里。」

「拥抱技术。你不需要证书，但绝对应该去玩 AI。你应该知道它能做什么、不能做什么。其余的事情没变——保持好奇，使用你正在写的软件，清楚风格指南是什么。」

他也目睹了招聘标准在职业生涯里翻转。

「早些年我们找的是语言强、并对技术感兴趣的人。现在正好反过来。我们实际在找的，是懂技术、对技术感到自在、语言也还过得去的人。」

他还看到一种新角色正在出现——有点像内容审计员，有人要为公司 AI 系统可能拿来训练的一切内容，负起准确性和新鲜度的责任。这个角色需要团队里最深的制度知识：「通常会落到团队里资历最深的人身上，那个见过最多变迁的人，所以他们知道骨架埋在哪里。」

JetBrains 的 Aleksandra Zolushkina 从一家大型科技公司内部看到了这种不确定。 JetBrains 的技术作者并没有大量用 AI 做内容创作，管理层也没有在推他们这么做。

「每个人现在都在试 AI，但没人知道未来会怎样。我觉得整个 IT 领域现在都处在某种恐慌状态。」

她没有把这种不确定当成抽身的理由，而是把注意力放在仍然耐久的东西上。

「你现在可以用 AI 生成一大堆文字，但 AI 没法给这些词赋予意义。那得你来。你还得确保这个意义尽可能精确。」

「能带着对用户的共情写出高质量内容的人，才是现在仍然相关的人。」

在湾区组织 Write the Docs 聚会的 Doug Purcell，正在围绕这场转型建设社区：「AI 不会消失。我们得想清楚怎么和它共存。」Diana Payton 说得很简单：「别害怕。这个行业一直在变动。而沟通、好的沟通，始终有价值，以后也会如此。」

dbt Labs 的 Mirna Wong 给出一种重新框定：「相信直觉，相信自己。靠向你的长处。你越快学会用 AI，就越快找到自己的位置。」KnowledgeOwl 的 Kate Mueller 补上重要的制衡：「如果你抄近路跳过写作过程，你就抄近路跳过了思考。而思考才是真正的价值。」

这个职业正在经历真实变化——招聘标准、日常工作流、乃至这份工作长什么样。但站稳脚跟的从业者有一种共同做法：他们在试验工具，对什么有效、什么无效保持诚实，并守护没有模型能取代的判断力和好奇心。

50%

表示 AI/提示工程 是他们最需要的新技能

56%

重度 AI 用户表示角色转向了「少写、多编」（从不使用的人里这一比例为 10%）

文档职业正经历一代人里最显著的角色转型，数据对方向毫无含糊。作者花在起草上的时间更少，花在校验上的时间更多。招聘标准在反转。两年前还不存在的新角色正在出现。

调查无法完全捕捉的，是这场转变的人的质地：焦虑与机会并排坐着，有时就在同一个人身上。这一节同时握住两端：一位 25 年老将同时应对来自领导层的压力和来自团队的恐惧；一位大型科技公司的高级管理者把不确定看得很清楚，并选择把注意力放在无论 AI 下一步做什么都仍然耐久的东西上。

这种张力——真实的颠覆与真实的机会之间——贯穿本节所覆盖的一切：角色如何改形、现在哪些技能要紧、时间在哪里被释放、又在哪里被吞掉，以及把这件事走得好的人，这个职业看起来是什么样。

角色没有缩小——它改了形状

三分之一的受访者表示，自己做的文档工作比以前更多。28% 说 AI 显著改变了日常工作，26% 说角色没什么变化。这个职业正在分裂成 AI 改造轨道和传统轨道。

「也许未来职位描述会变——更像信息架构师、内容策略师——并推向更专门的角色。我们会被给到一套工具去编排用户体验，而不是每天坐在那里把步骤一个个打出来。」

Gravitee

「我不觉得 technical writing 是个很好的词。写作和文字并不总是人们学习的最佳方式。作为文档人，我们可以影响整个开发者体验，而这并不总是等于写很多字。」

Supabase

「作为 2027 年的招聘经理，我希望候选人进来告诉我的是：『过去一年我做了这些实验，我发现 AI 工具在这两件事上真的有帮助，而这是我如何把它纳入实践的。』」

技术文档负责人

「作者产出的工件已经变了——我们现在除了文档，还写提示、claude.md 文件和共享技能，产出和读者都在变。」

Booking.com

新的技能画像

AI/提示工程 以 50% 成为第一新技能，但战略技能几乎同样重要——信息架构（38%）、内容策略（36%）和开发者工具（35%）都排得很高：

只有 9% 表示不需要新技能。正在成形的文档专业人士，看起来不太像作者，更像把 AI 当生产工具用的技术内容策略师。

值得注意的是，AI 治理正在成为技能组合的一部分：正如我们在 AI 创作一节看到的，尽管 76% 经常使用 AI，只有 44% 的团队有 AI 指南。那些能建立并维护治理框架的专业人士——不只是使用 AI，还为组织如何使用它定规则——正在填补一个关键缺口。

「人们对我们做什么的认知很窄。他们会说『我们不需要作者，逗号和大写 AI 就能搞定』，却没意识到那只是我们工作里最小的一块。」

lizargall.github.io/

「如果你不懂技术写作，你就做不成技术写作，有没有 AI 都一样。」

New Relic

「我整个职业生涯里，写作其实只占少数时间。我花更多时间做研究。」

Airbyte

「你得学会为自己的价值发声。信息架构、为用户代言、做决策——有了 AI，我们更像编辑，但我们也更像信息架构师。」

Stellar Docs | 前 Stripe

时间的再平衡

这种分化是对称的，也惊人：

被释放的时间（耗时变少的任务）：

• 写初稿：44%
• 格式/样式：35%
• 基础编辑：33%
• 写大纲：29%

被吞掉的时间（耗时变多的任务）：

• 事实核查与校验：43%
• 编辑 AI 生成内容：43%
• 设置提示 / 训练 AI：33%
• 与更大范围的团队沟通：27%

人类差异化价值最低的任务，恰好是 AI 节省时间的地方。人类判断必不可少的任务，则是时间被吸收的地方。这不是自动化在取代工作者——而是自动化在重塑工作者做什么。

「相信直觉，相信自己。靠向你的长处。你越快学会用 AI，就越快找到自己的位置。」

dbt Labs

「Jessica Talisman 有一个说法：在每一个企业组织里，都有你的人类专家才掌握的知识，那是你没法只靠自动吞文本就拿到的。」

前 Cribl、Cisco、Google

「我认为人类最独特的东西之一是直觉。那是一种非常独特的视角，只有你、作为所在组织里的技术作者，才会有。」

ServiceNow

「用 AI，我能为呈现数据和展示我们的价值找到新颖方案。听 AI 在心理上比听人更容易，因为它感觉更不偏不倚、更少情绪。可惜我们确实有风险：功劳全算到 AI 头上，而很多时候它只是在帮人听见我们一直在说的话！」

lizargall.github.io/

调查捕捉到的时间再平衡，也许反映的是文档工作一直以来的真实构成——研究、理解用户、判断——只是写作那一块现在被 AI 压缩了。

焦虑是真的——机会也是

许多技术作者感到脚下的地面在动，有些人正在承受真实冲击——团队被缩减、初级岗位不再补员、要证明 AI 取代不了他们的压力。这种焦虑可以理解，淡化它是不诚实的。

但数据并不是一个简单的「这个职业在缩小」的故事。三分之一的受访者表示，自己做的文档工作比以前更多。更广的科技行业也在经历类似颠覆——工程师、设计师和产品经理，都在面对关于 AI 在其工作中扮演何种角色的同一类问题。

与此同时，一类新角色正在出现。AI 公司自己也在招聘人类作者、叙事者和文档专家，承认能生成文字的技术，仍然需要懂如何与其他人沟通的人。Chris Ward 在 Supabase 招聘「文档工程师」（Docs Engineers）。Sarah Sanders 在 PostHog 的团队运作起来更像工程师而非传统作者；访谈之后，团队成员的头衔已从「Technical Writer」改为「Context Engineer」（上下文工程师）。

让一个人成为出色文档专业人士的技能——用户共情、清晰沟通、把复杂翻译成理解的能力——正在变得更有价值，而不是更少。改变的是工具箱，以及这些技能被应用的语境。

我们访谈到的、把这场转变走得好的从业者，有共同画像：他们好奇、技术上可适应，并用 AI 处理例行工作——起草、lint、测试、风格执行——好把更多时间花在需要人类判断的部分上。他们既不是 AI 布道者，也不是 AI 怀疑论者。他们是实用主义者，搞清楚了 AI 适合自己工作流的哪里、不适合哪里。

2026 年新增

这一节对 2026 年调查来说是全新的。我们加进来，是因为 AI 转型重塑的不只是文档工作流，还有职业本身——哪些技能被看重、时间怎么花、角色长什么样、从业者如何看待自己的未来。访谈里浮现出深切的焦虑，也有真实的机会；调查数据确认了两端：从创作到校验的转移、新的技能画像，以及这个职业曾经是什么与正在变成什么之间越来越宽的缝。这些问题在 2025 年没有对应项。

战略启示

从文档创作转向文档审校，是本报告最清楚的发现。 重度 AI 用户中，56% 报告「少写、多编」——从不使用 AI 的人里只有 10%。这条梯度在全部五个使用水平上一致。文档团队应为一份「亲手敲字写作占比更小，质量保障、内容策略和信息架构占比更大」的未来做规划。

把自己定位为组织语境的中心，并为此发声。 技术作者处在一个独特交汇点——他们理解产品、用户和组织图景的方式，在大多数组织里并不常见。在一个 AI 能生成文字的世界里，知道*文字该说什么*的人，价值上升而不是下降。作者应主动把自己定位为产品语境、用户共情和跨职能知识的守护者——并确保领导层看见这份价值。

AI 让技术作者更有能力，而不是更不相关。 就业市场的担忧是真的——有经验的作者发现岗位变少，初级职位不再补员，这个职业正在穿越真实的不确定。但上行空间也是真的。AI 工具让作者能做以前够不着的工作——跨仓库监控代码变更、从工程工具综合信息、大规模执行风格、审计内容新鲜度。眼下走得好的从业者是那些好奇的人：试验工具、保持技术技能，用 AI 扩展自己能做的事，而不是坐等它拿走什么。

投资那些能与 AI 复利的技能。 AI/提示工程是第一新技能（50%），但信息架构（40%）、内容策略（38%）和开发者工具（35%）紧随其后。模式很清楚：这个职业正在向上游走，从生产走向定方向。编码（24%）和 API 知识（25%）这类技术技能不是工作本身——它们让你把工作做得更好，尤其是与放大技术流利度的 AI 工具配对时。

「因为有 AI，我们比以往任何时候都更需要技术作者。现在正是公司加码文档的时候。」

Medusa

上一节：AI 与文档消费

下一节：结语

结语

结语

给文档负责人的建议

把文档连到业务结果

仅有页面浏览量讲不出这个故事。跟踪从文档到注册的转化、支持工单分流、入门完成、以及产品激活。即便小团队也能建立有意义的衡量项目——从你能跟踪的开始，并持续分享数据。洞察来自看着数字随时间变化。

在 AI 功能之前，先投入信息架构

每一项 AI 驱动的文档功能，都依赖底下结构良好的内容。采用一套 IA 框架，让页面自洽，投入结构化元数据。跳过这一步的团队，最后会得到端出糟糕答案的 AI 功能——而糟糕答案侵蚀信任，比没有答案更快。

现在就建立 AI 治理

76% 的团队在用 AI，只有 44% 有指南，治理缺口是一项每个季度都在变大的负债。定义质量标准、审校流程和工具指南——不是为了拖慢采用，而是为了保护让文档有价值的准确性和信任。文档的准确性门槛高于大多数内容，而 AI 让人更容易按规模产出听起来像样的错误。

帮助团队建设能与 AI 复利的技能

新的技能画像很清楚：AI 与提示工程、信息架构、内容策略、开发者工具。它们不是写作能力的替代——它们让作者能用 AI 做出比 AI 独自能做的更多的事。投入团队的技术流利度，鼓励实验，并为 AI 正在腾出来的战略工作留出空间。

为经 AI 中介的消费做规划

文档越来越多地通过 AI 中介被消费——编程助手、聊天机器人、AI 搜索、MCP 服务器。不为这件事做规划的团队，会发现自己的内容反正也会经 AI 被消费，只是不在自己的控制之下。为人类读者和机器读者同时组织内容，明确跟踪 AI 驱动的发现，并有意识地建设 AI 交付渠道。

认真对待这个职业的焦虑——并用数据回应

担忧是真的：团队被缩减、初级岗位不再补员、对未来的不确定。但数据并不支持「这个职业在缩小」的叙事。需求在增长。角色正在向上游演化。定义出色文档专业人士的那些技能正在变得更有价值。把这些数据分享给团队。帮助他们把这场转变看成工作的升级，而不是贬损——并用对他们发展的投入来撑住这句话。

向前的路

2026 年的文档处在拐点——不是因为基本面变了，而是因为围绕它们的环境变了。AI 正在重塑文档如何被创建、交付和消费。现在就投入的团队、从业者和负责人——投入衡量、信息架构、AI 治理，以及没有模型能取代的人类技能——将是定义文档下一步长什么样的人。

接下来几个月，我们将发布支撑本报告的完整深度访谈——与行业从业者关于他们如何实时穿越这场转型的对话。随着图景演化，我们也会继续与新的声音对话。在未来几版 State of Docs 报告中，我们将跟踪行业如何回应今年数据所浮现的挑战与机会。

上一节：文档与职业发展

「我们仍然要为制造意义负责。那是我们的本业。」

技术文档负责人

关于报告

文档即产品

人们靠它了解、信任并从你所构建的东西中获得价值——往往不必和你的团队交谈。好的时候，它退到背景里。不好的时候，一切都比应有的更费劲。

但经过多年创建和维护文档，我们意识到：无论我们多么确信文档正在起作用，我们都没有扎实的数据来证明。

这就是我们创建《文档现状报告》的原因。

文档的影响是真实的，但很少干净利落。好文档会预防你永远看不到的问题，减少从未被问出的问题，并以无法整齐装进单一指标的方式改善产品体验。于是团队一遍又一遍解释同样的事情：「好」是什么样、文档给谁看，以及如何衡量成功而不去追逐虚荣数字。

我们想要一个比意见更大的答案。

绘制文档版图

AI 正在改变文档的创建与消费方式。文档工作也在变——谁来贡献、如何制作，以及团队期望它为更广泛的业务做什么。但我们常常缺少共同基准：成功看起来是什么样、哪些指标有意义、其他团队如何应对同样的问题。

《文档现状》是我们用行业内更具体的答案填补这一缺口的尝试。

这份年度报告汇集各种形态的文档贡献者的洞察。它不是排名，也不是规则手册。它是一份快照：文档团队如何工作、他们在交付什么、什么在变、什么很难，以及此刻「成功」看起来是什么样——并由从业者视角和更深入的故事支撑。

我们在 2025 年发布了第一份报告。我们在一年一年地把这幅图画出来。

2025 年报告请见此处。

如果你今天就在做文档——正在和指标、协作、质量或 AI 的影响较劲——请参与 2026 年调查。加入你的声音，帮助把共同的直觉变成我们都能指向的东西。

阅读报告

贡献者

致谢贡献者

非常感谢我们的贡献者

贡献者

2026 年 State of Docs 报告由 Tal Gluck 制作，David Hughes 设计，并得到 Steve Ashby、Addison Schultz、Suzy Everist 以及 GitBook 其余团队的支持。若没有更广文档社区以访谈、建议和反馈给出的支持，我们做不到这件事。

以下按「姓名 / 公司或身份」列出受访与贡献者。

• Ian Alton / Airbyte / 技术写作负责人
• Tina Amirtha-Ingold / ChannelEngine / 高级技术作者
• Liz Argall / lizargall.github.io
• Utsav Banerjee / New Relic / 高级经理，产品文档
• Daniel Beck / ddbeck.com / 技术作者与开发者
• Jared Bhatti / Waymo / 高级主任技术作者
• Sarah Biddle / Backbase / 经理，技术作者
• Gareth Brinn / Gravitee / 文档经理
• Dachary Carey / MongoDB / 高级程序员作者
• Chris Chinchilla / Supabase / 文档团队负责人
• Alison Combes / 自由技术作者
• Sarah Deaton / Anthropic / 技术团队成员
• Gareth Dwyer / Ritza / 创始人
• Fabrizio Ferri-Benedetti / Elastic / 首席技术作者
• Christopher Gales / 技术文档负责人
• Bekah Hawrot Weigel / Virtual Coffee / 开发者体验顾问
• Richard Howard / parcelLab / 高级技术作者
• Delfina Hoxha / Little Language Models / 创始人
• Sean Huck / Adyen / 团队负责人，技术写作，平台与金融服务
• Lisa Hultman / ServiceNow / 副总裁，产品内容
• Amarachi Iheanacho / Sidero Labs / 高级技术作者
• Tom Johnson / Google / 高级技术作者
• Usha Mandya / Docker / 高级经理，技术写作
• Sasha Maximova / JetBrains / 产品营销经理
• Sandeep Medikonda / ServiceNow / 高级经理，分析与搜索
• Sarah Moir / Sigma Computing / 首席技术作者
• Kate Mueller / KnowledgeOwl | The Not-Boring Tech Writer
• Shahed Nasser / Medusa / 开发者体验负责人
• Funke Olasupo / Rocket.Chat / 技术作者
• Diana Payton / HackMamba | Technical Writing Uncensored / 技术文档经理
• Vinay Payyapilly / New Relic / 文档总监
• Samy Pessé / GitBook / CTO
• Doug Purcell / Supermicro / 技术作者
• Abe Raher / 前 Cribl、Cisco、Google / 高级技术作者
• Louis van Roessel / Adyen / 开发者体验负责人
• Sarah Sanders / PostHog / 上下文工程师
• Manny Silva / Skyflow | Doc Detective / 文档负责人
• CT Smith / Payabli / 首席技术作者
• Marco Spinello / Booking.com / 高级技术作者
• Sara Tandowsky / GitBook / CEO
• Larry Ullman / Stellar Docs | 前 Stripe / 负责人
• Hazel Weakly / 金融领域工程负责人 | Nivenly Foundation Fellow
• Mirna Wong / dbt Labs / 高级技术作者
• Aleksandra Zolushkina / JetBrains / 首席技术作者

我们如何使用 AI

我们在撰写和制作本报告的许多阶段使用了 AI/LLM：

Loom 和 Granola，用于 AI 辅助的访谈转写。

Claude，帮助编写用于数据分析的 Python 脚本，并生成图表。

Claude Code，用于综合并识别访谈中的宽主题、报告的早期起草，以及找出部分高亮引文。

GitBook Agent，用于校对和风格检查。

Framer Workshop，用于小型网站组件，包括动画统计数字、图表灯箱和社交分享。

这些工具让一个小团队写报告的过程更快、更丰富。它们也需要大量人工审阅和干预，以确保创作过程每一阶段的准确性：

使用 AI 帮我们在转写里找到了一些若没有它可能会错过的、丰富而有价值的引文。

但它也完全捏造过一些引文。

这些 AI 工具让分析调查数据的过程更快、更容易。

但也更容易漏掉更广的语境，并需要对数据做仔细核验。

简而言之，我们自己用 AI 做这份报告的经历，印证了「AI 与文档创作」一节的发现。像这样一份报告由许多活动部件组成，AI 让管理它们更容易。但它不可能单靠 AI 写成。

（这一节——和报告的许多其他部分一样——完全由人创建和编辑。）

洞见

「我们怎样才能确保用户就在他们所在的地方拿到需要的信息，而不是让他们离开当前语境去别处找？」

Docker

「功能在我们写出来、并在产品里发布之前，并不存在。」

Sigma Computing

「没有放之四海而皆准的文档指标——你必须把工作映射到领导层已经在乎的那些指标上。那才是你证明价值的方式。」

Skyflow | Doc Detective

「你得学会为自己的价值发声。信息架构、为用户代言、做决策——有了 AI，我们更像编辑，但我们也更像信息架构师。」

Stellar Docs | 前 Stripe

「因为有 AI，我们比以往任何时候都更需要技术作者。现在正是公司加码文档的时候。」

Medusa

「我和作者们谈过太多次：『我怎么证明我做的事有意义？我怎样能用上级会觉得有说服力的方式展示 ROI？』」

KnowledgeOwl | The Not-Boring Tech Writer

「正在发生一种转变：很多产品公司落后了。你的用户只是让智能体给他们做点东西，根本不提你的产品。如果你不在智能体的参照系里，你就永远不会出现。」

MongoDB

「我不知道你怎么买软件，但如果我在找一个方案，我不想看营销站点。我想看文档。」

Payabli

「作者的工作当然是创建文档。但当作者看出这其实不是文档问题——而是设计问题——时，工作也包括抵制文档。」

New Relic

「归根结底，人们解释事情、写东西，还是写给其他人的，哪怕中间隔着一层 AI。」

JetBrains

延伸阅读

采购决策与业务影响

Save a horse, use a content strategy — Sarah Moir

即便文档写得再好，如果没人找得到也会失败——那时用户就会转向支持工单、第三方培训或聊天机器人。

Beyond documentation: tech writers as strategic enablers — Ian Cowley

主张技术作者作为战略性产品贡献者——想的是用户激活率和第一次 API 调用的时间，而不只是页面质量。

AI is the new marketing funnel — and your docs decide who wins — Steve Ashby

文档如何悄悄变成新的漏斗顶端——眼下赢的公司不只是在做更好的产品，他们还在互联网上建设最可被 AI 阅读的产品知识。

文档团队结构

DOCS LIKE STRIPE and the documentation cargo cult — CT Smith

出色的文档不只是写得好——它们需要真实的组织投入，「做成 Stripe 那样」会把真正让那件事成为可能的一切都糊过去。

Documentation as a shared responsibility — Damilola Oladele

实务上看，文档所有权如何在产品经理、设计师、工程师和法律之间真正摊开——以及为什么这对大多数团队承认的程度更要紧。

Thinking Strategically About Documentation — Kevin R. Kuhl

文档团队可以如何定位自己的三种模型——有助于想清楚团队现在坐在哪里、可能想去哪里。

文档与产品

Kate sounds off on docs symbiosis — Kate Mueller

维护工作与战略项目之间的张力其实不是冲突——这一集主张它们其实是共生的，对小团队决定优先做什么是一种有用的重新框定。

The intractable challenges of technical writing — Kayce Basques

完整性、正确性、可发现性——三个从未真正被解决的问题。直接对应报告里「让文档保持同步仍是第一挑战」的发现。

Putting documentation at the core of your product’s user experience — Steve Ashby

主张把文档直接织进产品设计，而不是事后补上——与本节主题自然相配。

The Product is Docs — Christopher Gales 与 Splunk 文档团队

一组关于在快速移动的产品组织里真正如何运转文档团队的随笔——写自直接经验，不是理论。

Docs for Developers — Jared Bhatti、Sarah Corleissen、Jen Lambourne、David Nuñez、Heidi Waterhouse

开发者文档的实战指南，跟随一支虚构产品团队走完整条文档生命周期——从理解用户到发布并衡量影响。

文档工具

Testing docs IA with AI agents — Sarah Deaton

做了一个 AI 智能体，用真实人物角色模拟用户导航——一种同时适用于人类和 AI 消费者的信息架构测试巧办法。

Build your own CLI and become unstoppable — CT Smith

主张技术作者用脚本和自定义 CLI 工具自动化自己的重复工作——做了一个 20 多条命令的 CLI，真正改变了他们的工作流。

Docs as code is a broken promise — Sarah Moir

Docs-as-code 常常最后只是工具采用，没有任何真实的流程投入——工程团队有整支团队支撑工作流，文档团队能摊上一个工程师就算走运。

衡量文档成功

Docs metrics and the stories we tell ourselves — Sarah Deaton

对文档指标为何如此难解释的诚实看法——主张逐步少错一点，而不是去追一个完美的统一指标。

Where to start with analytics for documentation — Sarah Moir

文档团队需要与营销不同的分析方法——没有行为、产品和业务语境叠上去，原始数据会误导。

Simulating readers cause I’m not a user researcher — CT Smith

用 Claude API 和 Playwright 做了一个 AI 工具，模拟用户人物角色在文档里导航以发现可用性问题——在没有正式用户研究时衡量有效性的一种有创意的办法。

AI docs readership increased over 500% in 2025. What does it mean for you? — Rémi Gonnu

关于文档 AI 流量暴增的数据——与「页面浏览量正变得不可靠、团队需要新指标」的发现直接相关。

AI 与文档创作

The writing was always the cheap part — Fabrizio Ferri-Benedetti

对「AI 让文档快 10 倍」叙事的有用纠正——好文档的真正成本从来不是写作本身，而是必须先发生的全部思考。

How AI is changing collaboration between docs and support — Ian Cowley

AI 驱动的工单分流正在实时浮出文档缺口——而随着 LLM 成为文档的主要消费者，内容本身也需要改变。

Why editing matters more than ever with AI-assisted writing — Damilola Oladele

AI 写得像文案，而不像技术作者——这对现在真正要紧的编辑技能意味着什么。

How onboarding a human made my AI smarter — Sarah Deaton

给新同事写入职文档的同时，也让 AI 工具更好用了——原来风格指南和 Vale lint 正是人类和 AI 都需要的那种上下文工程。

AI 与文档消费

The Most Actionable Docs Around: Agent Configs — Manny Silva

CLAUDE.md、AGENTS.md 和类似文件就是文档——研究显示，人写的配置在任务完成上比自动生成的高出 29%。值得在文档扩展到文档站点之外时想一想。

Why I Hate the Term “Context Engineering” (and Why Everyone Is Doing It Wrong) — Miriah Peterson

缺的那一块不是更好的提示——而是有意识地工程化什么数据进入系统上下文、何时进入、停留多久。

AI must RTFM: Why technical writers are becoming context curators — Fabrizio Ferri-Benedetti

覆盖 CLAUDE.md 文件、llms.txt 标准和面向 AI 的文档格式——关于「为 AI 读者写作」在实践中究竟长什么样的一份好入门。

How to optimize your documentation for AI (without breaking it for humans) — Steve Ashby

直接关于在保持人类可读的同时为 AI 读者组织文档——本节的核心张力。

LLMs vs. Agents as Docs Consumers — Dachary Carey

模型训练与实时智能体检索是两种完全不同的访问模式——而大多数「面向 AI 的文档」指南只处理了其中一种。

文档与职业发展

New habits for tech writers in the age of LLMs — Fabrizio Ferri-Benedetti

现在昂贵的工作是信息架构、分类法和上下文策展——靠向自动化和工具的作者才会走得好。

10 principles of the cyborg technical writer — Tom Johnson

一套与 AI 并肩工作、而不是被它取代的框架——发展领域专长、自动化重复任务、为机器消费设计文档。

Self-Advocacy for Technical Writers — Kevin R. Kuhl

建设可见度、为文档价值发声的实务策略——与「技术作者需要更大声地讲自己实际贡献了什么」的想法很合拍。

Growing as a technical writer in the AI era with Fabrizio Ferri-Benedetti — Kate Mueller

把自己定位为战略伙伴而不是内容生产者的策略——拥抱 AI 工具，同时把批判性思维放在最前面。