实践

工作流、评审、信息架构，以及如何持续产出可靠的技术文档。

实践

不过度工程化的 Docs-as-Code

Docs-as-Code 并不意味着把所有技术写作者都塞进 IDE。更合理的做法是把版本化文本、浏览器编辑、预览、有效的自动检查、人工评审和可预测发布组合起来。

3 分钟阅读

实践

围绕“文档债务：如何找到真正伤害用户的问题”给出可执行、可验证并且便于长期维护的技术写作方法。从技术写作角度解释“文档债务：如何找到真正伤害用户的问题”，重点是可执行、可验证和可维护的做法。

3 分钟阅读

实践

围绕“不官僚化的文档责任地图”给出可执行、可验证并且便于长期维护的技术写作方法。从技术写作角度解释“不官僚化的文档责任地图”，重点是可执行、可验证和可维护的做法。

3 分钟阅读

实践

好的评审流程应明确责任、减少等待，并区分事实、编辑与产品审批。

2 分钟阅读

实践

五十页时好用的结构，到了五百页可能彻底失效。应围绕用户任务、内容类型和长期稳定的概念设计导航，而不是照搬组织架构。小型文档集几乎可以容忍任何导航方式。只有二十页时，读者能快速扫完菜单，作者也记得内容放在哪里，重复内容仍然容易发现。

3 分钟阅读

实践

围绕“让用户知道该做什么的发布说明”给出可执行、可验证并且便于长期维护的技术写作方法。从技术写作角度解释“让用户知道该做什么的发布说明”，重点是可执行、可验证和可维护的做法。

3 分钟阅读