我们只使用官方公开来源，对 Microsoft Learn、Google for Developers、IBM Documentation 与 Apple Developer Documentation 进行比较。
研究使用同一方法比较四套大型文档系统，覆盖门户结构、编辑规范、工具、无障碍、版本管理与 AI 访问。
方法
仅检查官方公开的一手来源，并在结论前固定0–2评分规则。
公开能力指数
四家公司使用同一组九项指标，每项按 0–2 分评价，满分 18 分。
评价维度
0 = 在所检查的官方材料中未发现 · 1 = 部分实现或仅限特定产品 · 2 = 明确且完整的能力
| 指标 | Microsoft | IBM | Apple | |
|---|---|---|---|---|
| 统一门户与导航 | 2 | 1 | 2 | 2 |
| 公开写作指南 | 2 | 2 | 2 | 1 |
| 规则更新可见性 | 2 | 2 | 1 | 1 |
| 教程 / how-to / reference | 2 | 2 | 2 | 2 |
| 版本与归档 | 2 | 1 | 2 | 2 |
| 反馈与参与 | 1 | 1 | 1 | 1 |
| 创作工具链集成 | 2 | 1 | 2 | 2 |
| 无障碍、包容与本地化 | 2 | 2 | 2 | 2 |
| AI/Agent 文档访问 | 2 | 2 | 1 | 0 |
规模：只使用可核验数字
本研究使用四项官方发布的文档规模指标。
门户与工具如何演进
时间线覆盖从 1990 年代到 2026 年的关键文档门户与工具变化。
Microsoft Developer Network 作为面向开发者的专业技术信息服务启动。 [M5]
MSDN Online 超过 25 万页，文档发布开始成为大规模基础设施问题。 [M5]
docs.microsoft.com 在对数百名开发者和 IT 专业人员调研后上线，Markdown、GitHub 贡献、按用户意图导航和更短的文章进入新模型。 [M6]
4 月 1 日，IBM Knowledge Center 被 IBM Documentation 取代，产品文档门户采用新的名称和用户体验。 [I5]
DocC 随 Xcode 13 发布并随后开源，源代码注释、Markdown、tutorials 与文档构建进入同一 toolchain。 [A4]
Google Style Guide 加强无障碍、语义表格、全球化写作、段落结构、ARIA 与任务导向写作。 [G2]
The Swift Programming Language 迁移到 DocC；转换期间接受了 50 多个 pull requests，翻译也使用同一发布 pipeline。 [A5]
生成式 AI、prompts、无障碍、包容性语言、代码格式与 UI wording 成为常规编辑主题。 [G2]
Microsoft Learn 发布 MCP 服务器，让 AI 工具与 Agent 搜索和获取官方文档。 [M4]
Google Developer Knowledge MCP 开放官方开发者文档的机器搜索，并列出 18 个覆盖的产品/领域组。 [G5]
官方 CICS 文档为三个或更多单词的查询加入 AI 生成的搜索结果。 [I7]
Style guides 如何变化
Google 与 Microsoft 的 changelog 展示了 task design、无障碍、全球化写作、代码规范与 AI 规则如何进入日常写作。
| 年份 | 公司 | 作者工作发生的变化 | 来源 |
|---|---|---|---|
| 2021 | 任务上下文、命令式步骤、全球受众与长期有效文档。 | [G2] | |
| 2021 | Microsoft | 包容性语言成为 style guide 的明确主题。 | [M1] |
| 2022 | 无障碍规则扩展到表格、UI、标点、认知负担与 Markdown authoring。 | [G2] | |
| 2022 | Microsoft | UI wording 与代词规则扩展到 AI-generated content。 | [M1] |
| 2023 | 段落结构、ARIA、全球化语言以及不依赖图片表达含义得到强化。 | [G2] | |
| 2023 | Microsoft | 残障相关用语与 screen-reader-friendly tables 更加具体。 | [M1] |
| 2024 | Generative AI 进入术语表，同时加强 alt text、captions 与 timeless docs。 | [G2] | |
| 2024 | Microsoft | 新增 prompt 与 prompting 的专门规则。 | [M1] |
| 2025 | 加入 prescriptive documentation，task design、links、code 与 accessibility 更紧密结合。 | [G2] | |
| 2025 | Microsoft | 更新 code formatting、可访问符号、identity language 与语气。 | [M1] |
| 2026 | 重组 global-audience guidance，并更新 UI context、code formatting 与 AI terminology。 | [G2] | |
| 2026 | Microsoft | Screen reader、alt text、AI prompts、emoji accessibility、tooltips 与 UI wording 成为常规维护内容。 | [M1] |
技术写作者的工作发生了什么变化
工作对象从单页/手册变成同时服务 Web、IDE、搜索和 Agent 的知识系统。
| 时期 | 主要对象 | 典型工具 | 编辑重点 | 交付方式 | 技术写作者角色 |
|---|---|---|---|---|---|
| 1990–2015 | 手册 / HTML 页面 | Word、CMS、XML、专业发布工具 | 完整性、一致性、reference | Web + PDF | 专业作者 |
| 2016–2020 | 任务导向门户 | CMS + Git/Markdown | 搜索、task success、精简 Web 文本、IA | 中央门户 | 产品流程中的内容负责人 |
| 2021–2024 | 靠近代码的结构化知识 | Git、Markdown、DITA、DocC、CI | 语义、复用、无障碍、本地化 | 门户 + IDE + generated reference | 信息架构师 + 自动化协作者 |
| 2025–2026 | 面向人和 AI 的知识源 | Source + metadata + schemas + retrieval interfaces | Grounding、可检索性、事实质量、机器消费 | 门户 + IDE + 搜索 + MCP/AI | 编辑、系统设计者、验证者 |
最重要的变化是开始对知识系统负责：结构、验证、维护、检索，以及与开发流程的集成。
值得借鉴的规则
比较呈现出四种强项：Google 的编辑规范、Microsoft 的基础设施、IBM 的质量模型以及 Apple 的代码集成。
| 先写条件，再写操作 | 读者在行动前先知道该步骤是否适用。 |
|---|---|
| 不要只用颜色或位置表达含义 | 无障碍也会改善页面扫描与本地化。 |
| 为全球受众写作 | 减少习语和本地文化表达可提高翻译质量。 |
| 清晰度高于机械执行 guide | 当偏离规则能让读者更清楚时，Google 允许这样做。 |
Microsoft
[M2]| 用更少文字表达更多信息 | 简洁被视为体验设计的一部分。 |
|---|---|
| 删除多余的 `you can` | 直接指令更容易快速阅读。 |
| 把 guide 当作持续维护的产品 | Changelog 持续更新 AI prompts、无障碍、术语与 UI wording。 |
| 区分反馈与直接编辑 | 当源内容公开时，Learn 同时支持反馈与 GitHub 编辑。 |
IBM
[I2]| 按具体质量特征审查 | Task orientation、accuracy、completeness、clarity、style、organization 与 retrievability 让审查针对具体属性。 |
|---|---|
| 明确建模内容类型 | How-to、API reference、troubleshooting 与 release notes 属于正式 content model。 |
| 进行语义复用 | DITA/Markdown references 可让重复内容保持同步。 |
| 维护用户任务 | 质量从用户需要完成的事情开始。 |
Apple
[A3]| 让文档靠近代码 | DocC 组合 source comments、Markdown、assets 与 API reference。 |
|---|---|
| 把 tutorials 当作一等内容 | 引导式学习与 reference 使用同一 toolchain。 |
| 在 developer workflow 内构建文档 | Xcode 与 DocC 缩短实现和解释之间的距离。 |
| 把文字视为界面的一部分 | Tone 与 wording 属于用户体验质量。 |
官方来源
证据全部来自 Google、Microsoft、IBM 与 Apple 的官方一手材料。
结论：不同任务有不同赢家
| 公司 | 最强领域 | 研究结论 |
|---|---|---|
| Microsoft | 基础设施 | 文档、学习、版本、反馈与 AI 访问组成了最完整的一体化系统。 |
| 编辑规范 | 公开 style guide 最透明，持续维护 changelog，并覆盖无障碍与全球化写作。 | |
| IBM | 质量模型 | 对质量、内容类型、可检索性与复用的形式化最系统。 |
| Apple | 代码集成 | DocC 将 API reference、文章、tutorials 与源代码结合得最紧密。 |
综合来看，我们把第一名给 Microsoft：它把文档、学习、版本、反馈和机器访问真正组织成了一套平台。
Google 更适合作为技术写作者每天打开的编辑参考。它把清晰度、无障碍、全球化写作、procedure 和 UI 文案变成可直接执行的规则。
IBM 是最容易被低估的一家。它把质量、内容类型、可检索性、指标、反馈和维护都正式化，适合成熟文档团队建立稳定的运营模型。
Apple 对 developer documentation 的方向最有启发：API reference、概念文章和 tutorials 与代码放在一起，并通过同一套 toolchain 构建和交付。
最强的组合是 Microsoft 的平台思维、Google 的编辑纪律、IBM 的质量体系，以及 Apple 与代码集成的工作流。