不过度工程化的 Docs-as-Code
Docs-as-Code 并不意味着把所有技术写作者都塞进 IDE。更合理的做法是把版本化文本、浏览器编辑、预览、有效的自动检查、人工评审和可预测发布组合起来。
封面文章
AI 已经会写文档了，技术写作者现在该做什么？
三年间，生成式 AI 把昂贵的初稿变成了廉价操作。现在真正重要的问题不再是模型会不会写，而是谁对事实、结构、审核、更新与质量负责。
如何正确编写 REST API 文档
好的 API 文档需要把机器可读契约、人类解释、可运行示例和明确的错误行为结合起来。 REST API 文档同时面向机器和人。机器可读契约描述 path、method、parameter、schema 与 response；人类文档解释意图、约束、工作流和开发者要做的选择。
2006 年的技术写作者还留下了什么？
工具已经彻底变化，但职业核心仍然熟悉：受众、证据、结构、术语和责任。 2006 年的技术写作者更常使用桌面出版、办公格式和手工维护的帮助系统。
实践
全部文章 →- 不过度工程化的 Docs-as-CodeDocs-as-Code · Git · 工作流
- 文档债务：如何找到真正伤害用户的问题质量 · 流程 · 信息架构
- 不官僚化的文档责任地图治理 · 流程 · 工作流
- 如何组织文档评审评审 · 编辑 · 质量
- 面向持续增长文档的信息架构信息架构 · 内容模型 · 流程
工具
全部文章 →CI
如何选择文档生成器，而不是选择一种信仰
Sphinx、MkDocs、Astro 等工具针对不同内容模型和团队优化。应比较作者流程、扩展能力、本地化和维护成本，而不是只看演示页面和功能清单。
V
选择文档搜索：从失败查询开始
围绕“选择文档搜索：从失败查询开始”给出可执行、可验证并且便于长期维护的技术写作方法。 从技术写作角度解释“选择文档搜索：从失败查询开始”，重点是可执行、可验证和可维护的做法。
SG
图表即代码：什么时候有用，什么时候没有
围绕“图表即代码：什么时候有用，什么时候没有”给出可执行、可验证并且便于长期维护的技术写作方法。 从技术写作角度解释“图表即代码：什么时候有用，什么时候没有”，重点是可执行、可验证和可维护的做法。
A
CI/CD 中的文档
把文档当作构建产物：在读者看到改动之前验证结构、链接、示例和发布规则。 CI 不能判断解释是否真正有用，但可以在人工投入之前拦截大量可预测问题。
最新
TechWriters 档案 →- 技术文档中的可访问代码示例与表格2026-08-13 · 标准
- 把 AI 当编辑，而不是神谕2026-08-13 · AI 与文档
- 在流畅错误发布前，对 AI 辅助文档进行事实核查2026-08-13 · AI 与文档
- AI 已经会写文档了，技术写作者现在该做什么？2026-08-13 · AI 与文档
- API 示例应该教会流程，而不是装饰 reference2026-08-13 · API
- 减少支持工单的认证文档2026-08-13 · API
职业
AI 与文档
标准
学习
TechWriters Research · 005
Apple 文档全史
从 Woz 的工程笔记和 1982 年人工拼版到 Inside Macintosh、HIG、DocC、Markdown 与 Xcode 智能代理。
Upcoming events
All events →活动
2006
TechWriters 档案
重新审视早期技术写作中的方法、观点与争论，并放到今天的语境中理解。