有一次我参加一个技术手册的评审会翻到目录的最后一页第31章的标题是“配置与调优”紧接着就是“第32章 其他”。当时所有人都盯着这四个字看了几秒一个同事开玩笑说“这一章的容量可能比前面三十一章都大。”大家笑了但说真的我翻到那一章的时候里面确实包罗万象有三条读者来信问过的基础问题有一份遗留的术语对照表有两个没人记得什么时候加进去的第三方工具链接甚至还有一条“本手册不再维护的接口说明”的旧通知。这就是大部分长篇文档里“其他”章节的真实状态。它像一个抽屉所有暂时不知道往哪儿放的东西都被塞进去然后被目录表记住了。这篇内容我想围绕这个特殊的“第32章”展开聊聊这种章节是怎么产生的、应该放什么、不应该放什么以及怎么把它从一个“杂物间”变成一个真正有用的收尾章节。无论你是开源项目的文档维护者、技术手册编写人还是某本书的作者只要你的产出物里出现过“其他”这两个字这篇文章都值得你花十分钟看一看。1. 被目录表记住的最后一章为什么长篇内容总躲不开“其他”1.1 一个章节目录里的“垃圾桶”是怎么来的几乎所有写过长内容的人都经历过这种过程你一开始有一个理想化的大纲结构清晰每一个章节都有明确的功能定位。但真正开始填充之后情况就不受控制了。有些内容是你在写作过程中才意识到需要补充的比如一个读者问“这里说的超时时间到底默认是多少秒”你觉得这是一个好问题但又不值得为它单开一章于是备注一句“详见第32章其他”。有些内容是历史遗留产物比如某个功能在第三版里已经废弃了但是配套的说明不能立刻删除至少要留一个“兼容性说明”的落点。还有一类内容是跨章节的比如全手册通用的一批缩略词放在第一章太长放进某一章的附录又会让那章特别臃肿。这些内容有一个共同点它们不是没有价值只是找不到一个完美归属。当这样的内容积累到一定量你自然会想到在结构末尾放一个“其他”章节把所有落单的内容收拢起来。我在维护一个名叫“Atlas”的开源配置工具手册时就是这么干的。那份手册最初规划了三十一章分别讲安装、配置、API、插件、集群等模块一切看起来都很完美。结果三个月后“其他”这个章节从零长到了洋洋洒洒六十多页成了整本手册里仅次于API参考的大章节。1.2 从大纲设计看“其他”产生的三种路径我后来复盘过“其他”章节的产生路径基本有三种不同路径对应的内容质量完全不一样。第一种是自上而下的漏项。大纲阶段没有把所有读者场景考虑完整比如忘了写常见报错处理或者漏了术语解释。这种漏项产生的“其他”内容通常是比较重要的因为它补全了读者真实的阅读需求只是位置放错了。第二种是自下而上的溢出。写作过程中产生了大量“周边知识”它们和正文有关系但又不是核心链路。比如正文讲了“如何配置高可用”但读者可能还需要知道“高可用方案的局限性”或者“历史版本中高可用配置的差异”这些就是典型的溢出内容。把它们放在正文里会打断主流程单独拿出来又没有足够篇幅形成一章最终只能流落到“其他”。第三种是外部反馈催生。文档上线后用户会在社区提问、写邮件、提Issue。你会逐渐发现某些问题被问了十几次甚至几十次这些问题值得整理成FAQ。但当时手册已经定稿按章节编号不好插入于是FAQ就被追加到了“其他”章节。说实话这种内容往往是最有价值的因为它完全来自真实的使用障碍。2. 第32章里该放什么不该放什么一份可复用的判定清单2.1 适合放进去的六类内容如果你现在面临“第32章其他”该怎么填的困扰可以先对号入座看手头这些内容是否属于下面六类。我根据多年维护手册的经验把适合放进“其他”章节的内容总结成了一个清单。第一类是常见问题解答FAQ。这类内容的特点是问句格式、短小精悍而且往往对应真实使用场景。FAQ放在正文里会显得不伦不类但放在“其他”章节作为附属内容读者遇到问题时能按图索骥体验很好。第二类是术语与缩写表。技术文档最容易被读者吐槽的一点就是“名词太多看一会儿就忘了”。如果你在正文中不得不使用大量缩写那么一份统一的术语对照表就是刚需。它适合出现在整个文档的偏后位置恰好是“其他”章节能提供的空间。第三类是版本兼容性说明。比如某个API在2.0版本后返回值的类型变了或者某个功能的配置项被重命名了这类信息对老用户迁移至关重要但又不适合塞进新功能教程中。放在“其他”章节里作为一个独立的兼容性参考是常见且合适的做法。第四类是常见错误码或错误场景。正文讲的是“怎么做”但用户真正卡住的时候需要的是“这个报错是什么意思”。错误码清单往往很长且枯燥和正文风格差异大所以放进“其他”章节非常合理。第五类是第三方工具、资源与扩展生态。一本手册的主题是固定的但用户可能还需要一些周边工具来提高效率比如社区维护的命令行插件、可视化面板、监控脚本等。这类信息时效性强、外部性强不适合写进核心章节但放在“其他”里作为资源聚合非常实用。第六类是致谢、贡献指南、社区链接。文档的最后一章承载一些“人和流程”的内容是很多开源项目的默认做法。致谢名单不适合放在开头放在最后更有仪式感而贡献指南则需要靠近文档末尾方便读者在看完内容后产生参与意愿。2.2 会毁掉“其他”章节的四类内容有该放的自然就有不该放的。我见过不少项目的“其他”章节失控绝大多数是因为混入了下面四类内容。第一类是还没想清楚的半成品。有些人把“其他”当草稿箱写到一半的思路舍不得删先丢进去占个位置。“这部分还没写完后续会补充”——如果你在自己的文档里看到了这句话这就是危险信号。读者看到半成品内容对文档的信任度会直线下降。第二类是与前文重复的详细教程。注意我这里说的是“详细教程”不是“简要交叉引用”。如果“其他”章节里出现了一段完整的操作步骤而这个步骤在第10章已经讲过了那么本质上就是内容冗余。冗余不仅浪费读者时间还会让维护成本加倍因为两处内容一旦不一致你很难判断哪个才是正确版本。第三类是过期废弃信息。手册会随版本迭代但“其他”章节往往会被人遗忘。我见过一份手册的“其他”章节里还写着“当前最新版本为1.43.0版本将于明年发布”而实际上项目已经迭代到4.2了。这样的信息放在正文里一定会被及时发现放在“其他”里却可能被长期忽略直到某个细心的读者发邮件来问。第四类是关键的隐藏逻辑。这一点最容易踩雷。有时候你会觉得某个参数的核心计算逻辑太细不适合放在主章节里于是把它挪进“其他”。但这样做的结果是读者如果只看主章节是根本无法理解和复现这个功能的。当你需要读者完成某个关键操作而必须依赖“其他”章节时就说明这个内容的位置设计已经出问题了。2.3 一条核心判断标准删掉第32章全文是否依然成立说了这么多最后其实可以归结成一条判断标准做完“其他”章节之后请你做一个思想实验——把这一整章从目录里删掉再看一次全文目录问自己读者是否依然能获得一个完整的知识图谱如果删掉之后核心内容的完整性不受影响只是少了一些扩展信息和周边资料说明你的“其他”章节定位是正确的。如果删掉之后读者会错过重要的兼容性说明、找不到术语解释、不知道怎么处理报错那么这些内容就不该待在“其他”里而应该被安排到正文主流程中。拿我一直维护的Atlas手册举例早期“其他”章节里有一篇“节点间通信超时配置说明”内容是键功能的一部分。后来一个用户在社区里反馈他们照着配置文档部署后发现集群总是提示超时查了两天才发现答案被“埋”在第32章里。那次之后我做的第一件事就是把那篇说明拆回了配置主章节。3. 把“第32章 其他”写出价值从杂项堆到导航中枢3.1 第一件事先做一次性清理盘点如果你接手了一份旧的、已经带有“其他”章节的文档第一件事不是优化写法而是先做一次彻底的清理盘点。这个过程有些像搬家前先打开所有抽屉把东西全倒在地板上再决定每样东西的去向。不做这一步后续任何优化都是在堆满杂物的房间里装修。我的做法是先在全局搜索一些关键词比如“详见其他”“见第32章”“待补充”“TODO”“FIXME”“不再推荐使用”“历史遗留”等。这些标记背后通常藏着被随手丢进“其他”的内容。然后把“其他”章节里所有条目列成一张清单逐条询问内容所属模块的负责人弄清楚三个问题这个条目是给谁看的它的信息源在哪里它还有什么用这次盘点会很耗时但它能帮你建立一张完整的“内容地图”。我当时花了两天时间清理Atlas手册的“其他”章节列出来整整83个条目其中大概三分之一已经过时三分之一和正文重复只有剩下三分之一是真正有价值且值得保留的。如果没有这次盘点后面的重构根本无从谈起。3.2 用“三分类法”决定每个条目的归属所有条目盘点完之后我会用一个“三分类法”来决定它们的去向。这个分类法非常简单任何文档维护者都能直接搬去用。A类内容属于正文主线。判断标准是读者不看到这条内容就无法完成核心操作或者会对核心功能产生严重误解。这种内容必须回到正文里它应该在的位置哪怕是打乱现有章节编号也要回去。不要因为嫌麻烦就留着它继续待在“其他”里因为它现在的位置是一个陷阱。B类内容属于参考性资料可以留在“其他”章节。判断标准是它们确实有读者但不是所有人的必经之路。比如术语表、错误码清单、第三方工具列表。对这类内容光保留还不够你要做的是把它们从泛泛的“若干杂项”重新组织成有明确二级标题的结构。C类内容属于过时无用内容。判断标准是文中所描述的功能已经不存在或者已经被新方案完全替代且不会有读者回到旧方案中。这类内容的原则是三选一删除、移除到项目内部的废弃归档目录或者移动到一份独立的“历史版本变更档案”中。绝对不要留在读者会看到的“其他”章节里碍眼。三分类法看着简单但真正执行起来容易犹豫。我自己有一个辅助判断技巧假装自己是一个完全的新手第一次打开这份文档按目录顺序往下读。读到某个条目时如果我会停下来想“这是什么东西、和我上面的操作有什么关系”那它大概率不是B类。3.3 给“其他”章节一个专业骨架清理完成之后你应该给“其他”章节设计一套骨架而不是让它继续是一个流水账式的大杂烩。以Atlas手册为例处理完杂项后“第32章 其他”最终被重构为六个固定的小节这个骨架我后来也沿用在好几个项目里效果都不错你可以参考后按自己项目的实际情况调整。32.1 常见问题排查FAQ 这里应该以“问题原因解决办法”三要素组织每一条都要能独立阅读不需要依赖上下文。写FAQ最忌讳的一句话是“详见上文”因为用户是通过搜索引擎进来的他可能根本不知道“上文”在哪里。32.2 术语与缩写表 维护一份按首字母排序的表格至少包含“缩写/术语全称/简单解释”三列后面还可以加一个“首次出现的章节号”用于交叉引用。有了首次出现位置读者在正文里遇到生词时能反向找到这块汇总表。32.3 兼容性说明与历史版本 按版本号倒序排列变更记录每条记录写明影响范围例如“影响哪个接口/配置项/行为”。注意这里只需要说明差异不要重新写一遍完整教程。32.4 第三方工具与扩展生态 列出所有经过验证、仍在维护的第三方工具每个工具给一两句话的功能描述、适用场景和仓库地址。不要列未经验证的链接链接失效是读者体验最大的杀手。32.5 社区与贡献指南 说明怎么提Issue、怎么提交代码、文档仓库在哪里、沟通渠道是什么。这部分对开源项目尤其重要它决定了用户遇到问题后是否能自己动手解决。32.6 版本记录与更新日志 如果项目没有单独维护更新日志那么这里至少要有近几个版本的变更摘要。如果已经有独立的Changelog文件这里只需要放一个链接和简介不必重复全部内容。3.4 让读者更容易找到第32章“其他”章节最尴尬的地方在于读者往往不知道这里还有他们需要的内容。你可以在文档层面做四个方面的引导。目录设计上把“其他”章节里的6个小节名称全部列出来。一个合格的目录应该让读者不点进正文就能知道这一章覆盖了哪些主题。页面表现上给每个小节设置清晰的页眉或面包屑导航。交叉引用上在正文中遇到易错点时主动加一句“常见问题与排错方法见32.1节”而不是等读者自己翻到最后。搜索关键词方面确保“FAQ”“排错”“术语”“更新日志”“兼容性”这些词能在文档内搜索时命中对应的小节标题或首段内容。经过这一番调整Atlas手册的“其他”章节才算真正做到了“值得被保留”。后来有用户在问卷里反馈说“第32章的FAQ是我最喜欢看的部分”这句话让我既高兴又警觉——高兴的是重构有效警觉的是如果FAQ太受欢迎会不会说明正文写得太难懂了4. 从写作态度看“其他”它暴露了你的文档管理方式4.1 “其他”是内容分类体系的压力测试持续维护过大型文档的人都有一个体会一个章节的设计是否合理看它随时间的变化就知道。如果“其他”章节的内容在持续膨胀这不是“内容太多”的问题而是整本手册的内容分类体系出了问题。你可以把整个文档想象成一个城市的交通系统。“其他”章节就像城市边缘的货运中转站。正常状态下中转站里流动的是临时周转的物资数量应该保持在一个稳定水平。但如果所有进出城市的货物都优先堆在中转站而不是分派到各自的商店和仓库那就说明城市本身的物流规划出了故障。放到文档里“其他”章节不断膨胀通常有三种可能性内容团队对章节归属没有共识新产生的信息没有明确归属地产品迭代太快文档更新追不上节奏于是把还没消化完的新功能说明临时放进“其他”文档负责人长期缺位没人对整体结构做定期审查。所以你可以把“其他”章节的大小当作一个健康指标。每次版本发布前如果“其他”章节的条目数量相比上次有大幅增长就要停下来分析增量来自哪里而不是简单地把新内容追加进去。这个习惯能倒逼你不断优化正文的分类结构让文档永远保持“主线清晰、杂项可控”的状态。4.2 版本迭代中的“其他”章节维护节奏“其他”章节不是写完就完事的内容它的维护节奏和正文同步甚至可以比正文更频繁。因为杂项内容有一个特点过时速度比主线内容更快。一个接口的废弃通知一个工具的仓库迁移一条FAQ背后的版本背景这些信息都有极强的时效性。我在项目里定了一个节奏小版本迭代时做轻量巡检只看“其他”里有没有失效链接和废弃信息大版本迭代时必须做一次全面审查重新跑一遍三分类法把过时内容清出去。这个过程不需要专门安排一个“文档日”可以在特性开发任务排期的时候顺便加上。维护文档和写业务代码本质上是一样的它需要节奏感和持续投入而不是等到发布前一个晚上突击完成。4.3 多人协作时如何防止“其他”变成无主之地在所有文档风险中我认为“无主之地”是最危险的。多人在同一个文档仓库里协作时“其他”章节的归属感天然弱于其他正式章节。每个人都觉得“这是公共区域我不改也没关系”结果就是整个章节长期无人负责。我管理Atlas手册时给“其他”章节单独指定了一个Owner。这个人的主要职责不是亲自改写所有杂项内容而是负责接收、分类Decision和闭环。具体有三个工作机制可以落地。第一个是Owner制明确“其他”章节的维护人所有往这个章节加内容的需求都要经过这个人的确认。第二个是多作者提交模板要求提交者在模板里写清楚三个字段内容来源、目标读者、有效期估计。只要有人解释不清这三点内容就不允许直接加进“其他”。第三个是定期评审每季度把“其他”章节的清单过一遍用三分类法重新判决。这个机制坚持下来之后“其他”章节基本没有再出现失控的迹象。5. 我在维护大型手册时犯过的错与养成的习惯5.1 一次“其他”章节被当成全文入口的教训写到这里我想分享一次让我印象很深的反面经历。有一段时间Atlas手册的“其他”章节写得非常好好到什么程度它把散落在正文各处的接口注意事项都汇总了一份用户遇到问题后甚至会绕过正文直接跑到第32章里找答案。听起来像是好事但其实酿成了一个隐患。由于大家知道“反正第32章有汇总”正文各章中补充注意事项的频率就变低了。一些新接口发布后细节只被写进了“其他”的FAQ条目里而对应的功能章节反而没有同步更新。结果就是正文章节变得越来越“骨架化”大量关键提示都堆在最后一章。直到一次社区运维事故中用户按照正文步骤操作完全不知道还有后续注意事项才暴露了这个问题。那次之后我明白了一个反直觉的教训“其他”章节写得太好用会掩盖正文结构的缺陷。正确的关系应该是“其他”是导航和补充“正文”才是主路和根基。如果你发现自己和团队越来越依赖“其他”章节来传递核心信息那就说明正文需要重构了而不是继续给“其他”加内容。5.2 我最后留下的三条工作习惯在这个领域摸爬滚打多年我最后沉淀出了三条工作习惯一直沿用到现在。第一条每次内容评审都检查“其他”章节的条目数量。我给自己设了一个阈值如果“其他”章节的清单项超过总章节数的1.5倍比如正文30章那“其他”里不超过45个条目就会触发一次集中整理动作。这个数字不一定适合所有人但它帮我建立了一个客观的触发机制避免每次都要凭感觉判断。第二条所有放进“其他”的条目必须带创建日期和责任人。哪怕这个条目只有三行字也必须写清“由谁在什么时间因为什么场景添加”。没有这个信息的条目在三个月后就会变成“身份不明的内容”到时候没人敢删也没人敢改。第三条在发布前做一次“读者路径测试”。找一个完全不了解这个项目的人不告诉他目录结构只给他一个真实的任务目标比如“在十分钟内找到配置高可用的推荐参数”。观察他是否能完成、路径是什么。大多数情况下他会先翻到FAQ或者先搜索关键词然后绕回来。这个过程能非常直观地暴露出“其他”章节的导航是否有效以及正文是否存在信息缺失。如果你正在面对一份带着“第32章 其他”的手册或书籍我建议你做的第一件事不是急着重写内容而是先问自己一个问题删掉这一章我的读者会不会迷路如果不会那说明这一章的定位正确如果能那你要做的不是删掉它而是想办法把它真正写好让每一个不小心落入“其他”的信息都能被安排好它应去的方向。