文档的灵魂:教导,而非告知
你是否曾因为阅读一份技术文档而豁然开朗,仿佛作者预见了你的所有困惑?或者,你是否曾面对一个开源库,README 却只冷冷地写着“阅读源码”?技术文档的质量,直接决定了开发者体验的好坏。 今天,我们深入解读 Steve Losh 的经典文章《Teach, Don‘t Tell》,为你揭示编写优秀技术文档的核心哲学与实战方法。 技术文档的终极目标是什么?Steve 给出了一个精炼的定义:带领一个从未见过你项目的人,教导他们成为其专家用户,并在他们成为专家后支持他们。 关键在于“教导”二字。就像教人开车、弹吉他或编程一样,文档的本质是教学。它需要模拟一位耐心的老师,设身处地,一步步引导学生从零到精通。 遗憾的是,许多项目用以下方式敷衍了事,它们都是“教学”的反面教材: 这些并非全无价值,但它们必须在系统的教学文档建立之后,才能作为补充材料发挥效用。在此之前,它们只是逃避编写真正文档的借口。 一份能真正“教导”用户的完整文档,通常由四个有机部分组成: 这是用户邂逅你项目的第一站。它必须清晰回答三个根本问题: 目标: 在几分钟内让潜在用户明白项目是否契合其需求,并决定是否深入。 名称源于图形编程中“让一个三角形显示在屏幕上”的初始成就。这部分是一个极简的快速上手指南,核心是“Just get something on the screen”。 带领用户完成安装、配置,并运行一个最简单的示例。就像吉他老师第一节课先教三个和弦弹首歌一样,目的是让用户立即获得正反馈,亲身体验项目的“手感”,点燃继续学习的兴趣。 这是将新手塑造成专家的主战场。它是一个结构化的教程或指南体系,像“毛线团”一样纵横交错,而非线性罗列。 核心方法: 参考《如何解题》中的教导心法——理解学生已知什么,想让他们学会什么,然后找到一个能将他们向前推进一小步的微小想法,轻轻推动他们。 当用户已成为熟练使用者,这部分便是他们高效的查阅工具。包含: 注意: API 文档与代码中的“文档字符串”目的不同。前者适合深度阅读和关联浏览,后者则针对编码时 REPL 环境的快速查询。 Steve 用一则温暖的比喻收尾:好的文档,如同父母在空停车场耐心教孩子开车,从基础操作到复杂路况,逐步引导,及时答疑。最终,孩子不仅能独立驾驶,还能在遇到故障时查阅手册自行修理,甚至理解车辆设计背后的安全考量。 技术文档不仅是项目的说明书,更是社区的门户和传承的载体。“教导,而非告知”——这不仅是一个写作原则,更是一种对使用者同理心的体现。 行动起来: 审视你当前项目的文档,它是在“告知”一堆特性,还是在“教导”一个未来的专家?从补充一个真正的“黑色三角形”快速上手教程开始,让你的项目变得友好而富有吸引力吧。导言
优秀的文档不是信息的堆砌,而是思维的引导。
文档的根本目的:是“教导”,而非“告知”
优秀技术文档的四重奏
1. 初次接触:第一印象决定去留
2. 黑色三角形:最快的“啊哈!”时刻
3. 毛线团:系统的教学核心
4. 参考手册:专家的后盾
成为好“老师”的两个修炼
结语:让文档成为桥梁,而非壁垒