协作文档示例要展示一份文档从建立、分工、撰写、评审到定稿的完整填写样子，让读者能照着搭建自己团队的协作文档。下面这份“产品上线复盘”示例为演示情景，头部字段、章节分工、评论记录与版本状态均为示意填写，不代表真实客户案例。示例聚焦文档协同机制，需求规格的具体内容不在本篇展开。
要点总览（TL;DR）
- 示例以“产品上线复盘”为演示情景，头部写清标题、目标、负责人、参与角色、截止时间和当前状态，正文按章节标注责任人。
- 协作过程落在文档里：分歧在对应段落旁评论并@相关人，结论回写正文，版本记录保留每次修改的内容与修改人。
- 状态字段与评审节点对应，草稿、评审中、已定稿三个阶段分别对应撰写、意见关闭和负责人确认。
- 迁移到周报、方案说明、会议纪要时保留“责任人+时间+状态”三要素，章节和字段按文档类型增减。
- 小团队可合并参与角色与章节责任人，多轮评审的团队可细化状态，状态越多维护成本越高。
这份协作文档示例要解决什么问题
这份示例面向多人共同撰写、评审并定稿的团队文档场景，典型如上线复盘、项目周报、方案说明、会议纪要汇总。目标很直接：读者看完后能照着填出一份可协作的文档，知道头部写什么、正文怎么分工、分歧在哪里处理、定稿依据是什么。
协作文档与需求规格、设计决策记录有明确边界。需求规格关注需求条目、验收标准与变更控制，设计决策记录关注单个技术决策的背景与取舍；协作文档关注的是“多人如何把一份文档写出来”：谁负责哪一章、意见在哪里讨论、改了几版、何时可以定稿。三者可以互相引用，但本篇只讲协作机制这一层。
判断一份文档是否达到“可协作”状态，可以看三个标志：打开文档就能知道找谁、什么时候要；每一章都有明确责任人；修改和分歧有记录可查，而不是散落在聊天窗口里。
完整示例：一份产品上线复盘协作文档
以下是一份填写完整的示例。文档主题为某产品版本上线后的团队复盘，参与角色包括产品负责人、研发负责人、测试负责人、运营负责人和文档执笔人。
文档头部
| 字段 | 填写内容（示例） |
|---|---|
| 文档标题 | V2.3 版本上线复盘（示例） |
| 文档目标 | 梳理本次上线的时间线、问题与改进项，形成可跟踪的行动清单 |
| 负责人 | 产品负责人（对全文质量与定稿负责） |
| 参与角色 | 研发负责人、测试负责人、运营负责人、文档执笔人 |
| 截止时间 | 初稿：上线后第 3 个工作日；评审：第 5 个工作日；定稿：第 7 个工作日 |
| 当前状态 | 评审中 |
正文分章与责任人
| 章节 | 内容要点 | 责任人 | 状态 |
|---|---|---|---|
| 1. 上线时间线 | 关键节点、发布时间、回滚与恢复时间 | 文档执笔人 | 已完成 |
| 2. 目标达成情况 | 上线前设定的目标与实际上线结果对照 | 产品负责人 | 已完成 |
| 3. 问题与根因 | 上线期间出现的问题、影响范围、初步根因 | 研发负责人、测试负责人 | 评审中 |
| 4. 用户与运营反馈 | 上线后反馈汇总与典型问题 | 运营负责人 | 已完成 |
| 5. 改进项清单 | 改进动作、责任人、期望完成时间 | 产品负责人汇总 | 待补充 |
评论与@提及处理分歧的示例记录
- 第 3 章“问题与根因”中，研发负责人填写“问题由配置遗漏导致”，测试负责人评论：“同一问题在预发环境已出现一次，建议补充环境差异说明。”并@研发负责人与文档执笔人。
- 研发负责人回复评论，补充预发与生产环境的配置差异段落，并将该条评论标记为已解决。
- 第 5 章“改进项清单”中，运营负责人对一条改进项的完成时间提出异议，@产品负责人确认优先级，产品负责人回复后更新清单并注明调整原因。
版本记录与状态流转
| 版本 | 时间 | 修改内容 | 修改人 | 文档状态 |
|---|---|---|---|---|
| v0.1 | 上线后第 1 个工作日 | 建立文档，填写头部信息与章节框架 | 文档执笔人 | 草稿 |
| v0.5 | 第 3 个工作日 | 各章责任人完成初稿，第 5 章留空 | 各章责任人 | 草稿 |
| v0.9 | 第 5 个工作日 | 按评论补充环境差异说明，补齐改进项 | 研发负责人、产品负责人 | 评审中 |
| v1.0 | 第 7 个工作日 | 评审意见全部关闭，负责人确认定稿 | 产品负责人 | 已定稿 |
这份示例前后自洽：头部写明的截止时间与版本记录中的日期对应，章节状态与文档整体状态一致，评论中提出的问题在后续版本中都有落点。
逐项解释：每个字段为什么这样填
头部字段的作用是把责任和时间约束前置。标题让人一眼知道文档主题；目标说明这份文档要产出什么，避免写成流水账；负责人是对全文质量负责的单一角色，防止“大家都管、没人定稿”；参与角色列出需要动手或评审的人；截止时间拆到初稿、评审、定稿三个节点，比只写一个日期更能约束节奏；当前状态让打开文档的人立刻判断能否引用。
章节责任人的划分依据是“谁掌握这一章的事实”。时间线由执笔人整理，目标达成由产品负责人判断，问题根因由研发和测试共同填写，用户反馈由运营提供。每章只设一到两名责任人，避免责任稀释；跨角色的章节明确主责与协作者，汇总类章节由负责人收口。
评论与@提及的作用是把分歧固定在文档里。口头沟通的问题在于结论容易丢失、上下文无法回溯；在对应段落旁评论并@相关人，讨论就附着在具体内容上，后来者能看到“为什么这样改”。示例中测试负责人对根因提出补充要求，就是通过评论完成，而不是另开一次会。
版本记录与状态字段支撑评审与定稿。版本记录回答“改了什么、谁改的、什么时候改的”，状态字段回答“现在能不能用”。两者配合，评审时只需对照版本差异和未关闭评论，定稿时以评论全部关闭、负责人确认为标志，而不是凭印象宣布完成。
在工具承载上，这类协作动作可以落到文档平台里完成。ONES Wiki 支持成员在线添加注释、评论并快速反馈，文档实时同步并记录所有页面版本，可随时查看与回滚；页面模板库能一键创建制式化文档模板，便于把上述头部字段和章节框架固化成团队通用格式。示例中的“评审中”“已定稿”等状态标记属于通用写法，具体以团队实际使用的状态管理方式为准。
从这份示例能迁移出哪些写法
这份示例的写法可以迁移到周报、方案说明、会议纪要、项目复盘等多种团队文档。迁移时抓住以下几条规律，替换具体字段和章节即可。
- 先定头部信息再写正文。动笔前先填标题、目标、负责人、参与角色、截止时间和状态，头部空缺的文档往往写到一半就失去方向。
- 按章节分派责任人。把正文拆成若干章，每章标注责任人和状态，汇总类章节由文档负责人收口，避免出现无人认领的段落。
- 用评论与版本记录承载协作过程。分歧在对应段落旁讨论并@相关人，结论回写正文；每次较大修改留下版本记录，说明改了什么、为什么改。
- 让状态字段与评审节点对应。草稿对应撰写阶段，评审中对应意见收集与关闭阶段，已定稿对应负责人确认阶段；状态变化与截止时间节点对齐。
- 用模板固化结构。把验证过的头部字段和章节框架做成模板，新文档从模板创建，减少每次重新设计结构的时间。
迁移时保留“责任人+时间+状态”三要素即可，章节数量和字段名称按文档类型调整。例如会议纪要可以去掉“改进项清单”，增加“待办事项与责任人”；方案说明可以增加“备选方案对比”章节。
示例的适用边界与调整方式
这份示例是演示情景，用于说明协作机制，不是真实客户案例，也不附带量化成效。照搬前需要根据团队情况做调整。
团队规模不同，字段可以增减。三到五人的小团队可以合并“参与角色”和“章节责任人”，只保留负责人和截止时间；跨部门协作的文档则需要补充审批人、知会范围和文档密级等字段。文档类型不同，章节结构随之变化：复盘类文档保留时间线和根因分析，方案类文档增加背景与备选方案，周报类文档压缩为进展、风险、下周计划三段。
评审流程的复杂度决定状态字段的粒度。评审环节简单的团队用“草稿—评审中—已定稿”三态即可；需要多轮评审或跨部门会签的团队，可以细化为“草稿—内部评审—跨部门评审—待批准—已定稿”，并在版本记录中标注每轮评审的意见关闭情况。状态越多，维护成本越高，按实际评审节点设置即可。
评论与版本记录的使用强度也需匹配团队习惯。讨论频繁的文档要求评论及时关闭并回写正文；改动较少的文档保留关键版本记录即可。无论哪种调整，判断标准不变：打开文档的人能否快速知道找谁、进度如何、结论在哪里。
常见问题
团队只有三五个人，这份示例里的字段可以删掉哪些？
可以合并“参与角色”和“章节责任人”，只保留负责人和截止时间两个核心字段。文档目标建议保留，它决定正文写什么；当前状态也建议保留，哪怕只有草稿和已定稿两态。删减的原则是：打开文档的人仍能判断找谁、什么时候要、现在能不能引用。
评论里讨论出的结论，怎么保证不回丢？
把结论回写到对应章节的正文里，再把评论标记为已解决。示例中测试负责人提出补充环境差异说明，研发负责人补充段落后才关闭评论。评论承担讨论过程，正文承担最终结论，两者分开记录，后来者读正文即可，需要追溯时再翻评论。
文档状态需要设几档才够用？
按实际评审节点设置。评审环节简单的团队用“草稿—评审中—已定稿”三态即可；需要多轮评审或跨部门会签的团队，可以细化为“草稿—内部评审—跨部门评审—待批准—已定稿”。状态越多，维护成本越高，每增加一档都应有明确的进入和退出条件。
用 ONES Wiki 承载这类协作文档，评论和版本记录能对应上吗？
ONES Wiki 支持成员在线添加注释、评论并快速反馈，文档实时同步并记录所有页面版本，可随时查看与回滚；页面模板库能一键创建制式化文档模板，便于把头部字段和章节框架固化成团队通用格式。示例中的“评审中”“已定稿”等状态标记属于通用写法，具体以团队实际使用的状态管理方式为准。
会议纪要用这套写法，章节怎么改？
去掉“改进项清单”这类复盘专属章节，换成“待办事项与责任人”，并把每条待办标注完成时间。头部字段保留标题、主持人或负责人、参与人、截止时间和状态。纪要的截止时间通常更短，状态可以从“草稿”直接到“已定稿”，评审环节可省略。
