协作文档的编写，关键是把“一个人写完再发出去”改成“多人按同一结构分工、在同一份文档里留下可追溯的修改与结论”。具体做法是：先定文档类型与读者，再搭固定骨架，为每块指定负责人和截止时间，用评论收集意见，评审后把结论回写正文并记录版本。下文按编写前决定、章节分工、同文档协作、评审定稿、完整示例和交付检查六步展开，ONES 可在分工、评论与版本留痕环节承接这些动作。
要点总览（TL;DR）
- 编写前先定三件事：文档类型、读者与使用场景、通用骨架（背景与目标、正文分块、待决事项、变更记录），后续分工才有依据。
- 按章节拆分任务，区分章节负责人、评审人与定稿人，每章写清输入、产出和可判断的完成标志，并用前置章节标出并行编写的依赖。
- 讨论留在评论里，结论回写正文；涉及结论、范围、责任人的修改先讨论再改，纯文字优化可直接建议修改，每次发布登记版本与变更摘要。
- 评审只收敛事实错误与决策分歧，待决事项当场定或明确责任人与时限，定稿后回写结论、登记版本、通知相关方并指定维护责任人。
- 交付前按结构完整性、读者适配、分工与评审留痕、版本归档、后续维护五类逐项核对，全部通过再发布。
协作文档先定什么：类型、读者与骨架
多人协作最容易出问题的地方，往往在动笔之前：没人说清这份文档是给谁看的、要解决什么问题，结果每个人按自己的理解写，拼在一起像几份文档的合集。编写前先完成三项决定，后续分工才有依据。
第一项：确定文档类型。类型决定骨架和评审方式。方案文档重在论证与取舍，会议纪要重在结论与待办，设计决策记录重在背景、选项与最终决定。类型不同，正文分块和评审人都不一样。常见类型可以这样区分：
| 文档类型 | 核心内容 | 主要读者 | 评审重点 |
|---|---|---|---|
| 方案文档 | 问题、可选方案、推荐方案与理由 | 决策者、执行团队 | 论证是否充分、取舍是否清楚 |
| 会议纪要 | 议题、结论、待办与责任人 | 参会人、相关方 | 结论是否准确、待办是否落实到人 |
| 设计决策记录 | 背景、约束、备选方案、决定与影响 | 研发团队、后续维护者 | 决策依据是否可追溯 |
第二项：明确读者与使用场景。读者决定详略和术语深度。给决策者看的文档，结论和影响放前面，技术细节收进附录；给执行团队看的文档，步骤、输入输出和边界条件要写细。同一份文档面向多类读者时，用分块结构区分层次，避免把背景知识反复解释给所有人。
第三项：搭通用骨架。骨架的作用是让每个参与者在同一位置写同类内容，减少合并时的结构冲突。一份可复用的骨架通常包含：
- 背景与目标：为什么写这份文档，要达成什么结果；
- 正文分块：按主题拆成若干章节，每章一个明确问题；
- 待决事项：尚未有结论的问题、候选方案和责任人；
- 变更记录：版本、日期、修改人、修改内容摘要。
三项决定完成后，产出一份简短的确认清单：文档类型是什么、读者是谁、骨架包含哪些章节。这份清单就是后续分工的输入。
按章节分工：谁写、谁审、谁定稿
骨架搭好后，把文档拆成可分配的任务。多人协作中通常有三类角色，职责要分开：章节负责人对内容质量负责，评审人从读者视角提出问题和修改意见，定稿人对全文一致性、结论准确性负责并做最终发布决定。一个人可以在不同章节担任不同角色，但同一章节的负责人和定稿人建议分开，避免自写自定。
每个章节在分配时要说清三件事：输入是什么（已有资料、上游结论、相关文档）、产出是什么（该章节的完整初稿）、完成标志是什么（例如“包含至少两个备选方案及取舍理由，评审人无未回复意见”）。完成标志写得越具体，进度判断越少扯皮。
| 章节 | 负责人 | 评审人 | 截止时间 | 完成标志 |
|---|---|---|---|---|
| 背景与目标 | 文档发起人 | 项目负责人 | 第 1 天 | 目标可衡量，读者能一句话说出文档要解决什么 |
| 方案对比 | 方案提出人 | 技术负责人 | 第 3 天 | 至少两个备选方案，各有优缺点与适用条件 |
| 实施步骤 | 执行负责人 | 方案提出人 | 第 4 天 | 每步有输入、动作、输出和责任人 |
| 待决事项 | 文档发起人汇总 | 全体评审人 | 评审前 | 每项有候选方案、责任人和决策时限 |
| 变更记录 | 定稿人 | — | 每次发布 | 版本号、日期、修改摘要齐全 |
并行编写时要处理顺序与依赖。背景与目标章节通常最先完成，因为其他章节的取舍都依赖它；方案对比完成后再写实施步骤，避免步骤建立在未确认的方案上。依赖关系可以在分工表里用“前置章节”一列标出，负责人看到前置章节未完成时先做资料准备，不空等。
在 ONES Wiki 中，页面模板库可以一键创建制式化文档模板，把上述骨架固化为模板，新文档从同一结构起步；权限可以按角色配置读写范围，让章节负责人、评审人和读者各看到自己需要的内容。
在同一份文档里协作：评论、建议与版本
多人同时修改一份文档，需要约定协同机制，否则讨论散落在聊天记录里，正文被反复覆盖。核心原则是：讨论留在评论里，结论回写正文，版本记录变化。
评论与建议修改的使用时机。评论适合提出疑问、补充信息、指出风险，不直接改动正文；建议修改适合措辞调整、局部重写这类可以直接采纳的改动。约定一条规则：涉及结论、范围、责任人的修改，先评论讨论，达成一致后再改正文；纯文字优化可以直接建议修改。这样正文始终代表已确认的内容，讨论过程可追溯。
正文与讨论分离。评论解决后，把结论写回正文对应位置，并在评论中标注“已回写至某章节”，然后关闭讨论。待决事项统一收进“待决事项”章节，不在正文各处零散留问号。评审结束后，正文里不应残留未处理的讨论。
版本与变更记录的维护。每次对外发布或评审通过，记录一条变更：版本号、日期、修改人、修改摘要、影响范围。变更记录模板可以这样用：
- 版本号：按 v0.1、v0.2、v1.0 递增，v1.0 表示评审通过；
- 日期与修改人：谁在什么时候改的；
- 修改摘要：一句话说明改了什么，例如“补充方案 B 的成本对比”；
- 影响范围：涉及哪些章节、哪些相关方需要重新阅读。
ONES Wiki 支持成员在线添加注释、评论并快速反馈，文档实时同步并记录所有页面版本，可随时查看与回滚，适合把上述讨论与版本规则落在同一页面里。
评审与定稿：把意见收敛成结论
评审的目标是把分散意见收敛成可执行的结论，而不是再开一场讨论会。评审前，定稿人需要准备：完整初稿、待决事项清单、上一版变更记录，以及一份检查项——结构是否完整、每个待决事项是否有候选方案、关键结论是否有依据。材料不齐时先补齐再评审，避免会上现找资料。
评审中按章节推进，每章先由负责人用一两句话说明结论和依据，评审人只提两类意见：事实错误和决策分歧。其他表达优化类意见会后用评论处理。会议记录人同步维护待决事项表，每项写清问题、候选方案、责任人和决策时限，当场能定的当场定，不能定的明确何时由谁定。
定稿后做三件事：把评审结论回写正文并更新待决事项状态；在变更记录中登记新版本；通知相关方并说明变更影响范围。归档时保留定稿版本和评审记录，后续维护责任指定到人，约定触发更新的条件，例如方案变更、季度复盘。
ONES 的协同编辑与页面共享能力让评审前后的正文、评论和版本留在同一页面，相关方按权限访问，减少文件来回传递造成的版本分叉。
示例：一份设计决策记录怎么协作完成
以下为演示场景：某团队要决定消息通知服务的选型，需要产出一份设计决策记录，供后续维护者理解决策依据。
第一步，搭骨架并分工。发起人从模板创建页面，骨架为背景与约束、备选方案、决定、影响与后续动作、变更记录。背景章节由发起人写，备选方案由两位工程师各负责一个候选方案，决定章节由技术负责人汇总，评审人为产品负责人和运维负责人，定稿人为技术负责人。
第二步，并行填写。两位工程师按同一格式写各自方案：适用场景、优点、缺点、迁移成本。完成标志是“包含至少三项对比维度且有数据或事实依据”。发起人先完成背景与约束，明确日均消息量和延迟要求，作为方案对比的共同基准。
第三步，评论与收敛。评审人在备选方案下评论，指出某方案在高并发下的风险，工程师补充压测数据后回写正文。技术负责人在决定章节写明选择哪个方案、理由和放弃其他方案的原因，并把未解决的风险转入“影响与后续动作”，指定责任人和跟进时间。
第四步，定稿与版本演进。变更记录体现演进：v0.1 完成背景与两个备选方案；v0.2 补充压测数据并修正成本估算；v1.0 评审通过，记录决定和后续动作。每次变更注明修改人和影响范围，通知相关方阅读。
完成检查：协作文档交付前的核对项
发布前逐项核对，以下清单可直接用于交付检查：
| 检查类别 | 核对项 | 通过标准 |
|---|---|---|
| 结构完整性 | 背景与目标、正文分块、待决事项、变更记录是否齐全 | 四部分均有内容，无空章节 |
| 读者适配 | 结论是否在读者需要的位置，术语深度是否匹配 | 目标读者能独立读懂结论和依据 |
| 分工留痕 | 各章节负责人、评审人是否可查 | 分工表或页面记录可追溯 |
| 评审留痕 | 评审意见是否处理，结论是否回写正文 | 无未关闭的讨论，待决事项均有状态 |
| 版本与归档 | 变更记录是否完整，定稿版本是否归档 | 版本号、日期、修改摘要齐全 |
| 后续维护 | 维护责任人、更新触发条件是否明确 | 指定到人，条件可判断 |
清单全部通过后再对外发布。发布后如需修改，按变更记录规则登记新版本，并通知受影响的读者，保持文档与讨论、版本三者一致。
常见问题
团队人少、文档也不长，还需要做章节分工和评审吗？
可以简化，但不宜全省。两人以内、篇幅一页的文档，章节负责人和定稿人可由同一人承担，评审改为一次口头确认加评论留痕即可。需要保留的是两件事：动笔前说清文档类型和读者，发布前把结论回写正文并登记一条变更记录。文档一旦涉及跨团队决策或后续要被人引用，就应恢复评审人角色，避免结论只有作者自己清楚。
评论里讨论出的结论，怎么保证不会随讨论关闭而丢失？
约定一条动作：每条评论关闭前，先判断它是否改变了正文内容。改变了，就把结论写进对应章节，并在评论中注明回写到哪一节；没有改变，直接关闭并说明原因。尚未形成结论的问题统一收进“待决事项”章节，写清候选方案、责任人和决策时限。这样正文始终代表已确认内容，讨论记录作为过程留痕，两者不混在一起。
评审会上意见分歧较大、当场定不下来，怎么处理？
把分歧转成待决事项，而不是在会上反复争论。记录问题本身、各方候选方案及理由、需要补充的信息，指定一名责任人和一个明确的决策时限，并说明决策结果回写到哪一章节。评审可以带着待决事项结束，但定稿前必须逐项确认状态：已决定、已放弃或延期并注明原因。延期项要写清触发重新讨论的条件，避免长期悬空。
文档发布后业务发生变化，原文档怎么维护？
发布时就在文档中指定维护责任人和更新触发条件，例如方案变更、季度复盘或相关系统上线。触发条件出现时，由维护责任人发起修订，按变更记录规则登记新版本，写明修改摘要和影响范围，并通知需要重新阅读的相关方。旧版本保留归档，便于追溯当时的决策依据。维护责任没有指定到人的文档，通常在几个月后就会与实际做法脱节。
用 ONES Wiki 承载协作文档时，哪些环节能直接对应上述做法？
ONES Wiki 提供页面模板库，可一键创建制式化文档模板，适合把通用骨架固化为模板；成员可以在线添加注释、评论并快速反馈；文档实时同步并记录所有页面版本，可随时查看与回滚；还支持为多种角色配置不同的读写权限。章节负责人与定稿人的角色划分、完成标志的判定仍属于团队约定，需要在模板和分工表中写清楚，工具负责承载和留痕。
