研发知识发布前的审核，通常由内容责任人、领域评审人和发布责任人分工完成：内容责任人提交内容并回应意见，领域评审人判断技术准确性与适用范围，发布责任人在意见全部闭环后放行。修改意见统一登记在知识条目的评审记录中，按“意见—提出人—处理结论—修订位置—关闭状态”逐条跟踪。本文给出一套可直接套用的角色分工、操作步骤、意见字段和发布前检查清单，适用于接口文档、架构说明、故障复盘等研发知识条目。
要点总览（TL;DR）
- 研发知识发布前建议由内容责任人、领域评审人、发布责任人三类角色分工：作者提交并回应意见，评审人判断技术准确性与适用范围，发布责任人确认意见闭环后放行。
- 评审人范围按知识类型确定：接口文档需接口使用方与维护方评审，架构说明需架构或模块技术负责人评审，故障复盘需处理参与者与模块负责人评审。
- 修改意见统一登记在评审记录中，必备字段包括编号、提出人、意见内容、类型、阻断级别、处理结论、修订位置、状态及关联版本与轮次。
- 放行条件是阻断级意见全部关闭、非阻断意见均有明确处理结论、版本号与修订记录一致、评审记录已归档；出现阻断项应暂缓发布。
- 评审记录宜与需求、缺陷等工作项关联，并随知识条目归档，使发布版本可追溯到对应评审轮次和意见清单。
审核角色怎么分工：谁提交、谁评审、谁放行
研发知识审核最容易出现的问题，是作者自己写完自己发，或者拉一群人看却没人对结论负责。可行的做法是把审核拆成三个角色，每个角色只对一件事负责：内容责任人保证内容写清楚并回应意见，领域评审人保证技术判断正确，发布责任人保证意见处理完毕、版本可以对外。
三个角色的职责边界可以按下表划分。小团队可以由同一人兼任多个角色，但兼任情况要写进评审记录，避免出现“作者兼评审兼发布”却无人知晓的情况。
| 角色 | 核心职责 | 交付物 | 不承担的事 |
|---|---|---|---|
| 内容责任人（通常是作者） | 准备正文、适用范围和关联需求或缺陷信息；发起评审；逐条回应意见并完成修订 | 待评审版本、意见回应记录、修订后版本 | 不单独判定技术结论是否正确，不自行宣布发布 |
| 领域评审人 | 判断技术准确性、适用条件和边界；指出事实错误、范围不当或缺失的关键信息 | 评审意见及处理建议 | 不负责文字润色以外的流程推进，不代替发布责任人放行 |
| 发布责任人 | 确认意见全部有处理结论、版本已定稿、记录已归档；执行发布 | 发布确认记录、定稿版本号 | 不替代领域评审人做技术判断 |
评审人范围按知识类型确定，避免每次都拉全员评审。接口文档至少需要接口使用方和接口维护方各一名评审人；架构说明需要架构负责人或该模块的技术负责人评审；故障复盘需要故障处理参与者和相关模块负责人评审，重点核对时间线、根因判断和改进项。涉及跨团队约定的内容，应增加受影响团队的评审人。
评审人与作者重合时，有两种处理方式：一是回避，由同领域另一位同事承担评审；二是双人确认，作者作为评审人之一时，必须另有至少一名独立评审人给出结论，并在记录中注明“作者参与评审”。第二种方式适合评审人资源紧张的小团队，但不能演变为只有作者一人签字。
发布责任人的放行条件应事先约定，常见口径是：阻断级意见全部关闭，非阻断意见均有明确处理结论（接受并修订、部分接受并说明、不接受并给出理由），版本号与修订记录一致，评审记录已归档。放行条件写在流程说明里，比每次临时口头判断更稳定。
从提交到发布的操作步骤与完成标志
把审核发布拆成五步，每一步都有明确的输入、动作、输出和完成标志，流程才能被检查而不是靠记忆执行。
| 步骤 | 输入 | 动作 | 输出 | 完成标志 |
|---|---|---|---|---|
| 1. 提交评审 | 正文、适用范围说明、关联需求或缺陷编号、待确认问题清单 | 内容责任人冻结当前版本，指定评审人和评审截止时间，发起评审 | 待评审版本及评审任务 | 评审人已收到通知，版本号已标注 |
| 2. 领域评审 | 待评审版本、相关设计或代码依据 | 评审人逐条阅读，按统一字段提出意见，标注意见类型和阻断级别 | 意见清单 | 所有指定评审人已提交意见或明确“无意见” |
| 3. 意见处理 | 意见清单 | 内容责任人逐条给出接受、部分接受或不接受的结论及理由，完成修订 | 意见处理记录、修订版本 | 每条意见都有处理结论，修订位置可定位 |
| 4. 复核确认 | 修订版本、意见处理记录 | 提出阻断级意见的评审人确认修订是否解决其问题；必要时开启下一轮评审 | 复核结论 | 阻断级意见全部关闭，无新增阻断意见 |
| 5. 发布与记录 | 定稿版本、完整评审记录 | 发布责任人核对放行条件，登记发布版本号、发布时间和发布范围，归档记录 | 已发布版本、归档的评审记录 | 发布记录可追溯到对应评审轮次和意见清单 |
评审轮次和时限需要事先设定。常见做法是首轮评审给2至3个工作日，修订后复核给1个工作日；超过时限未反馈的评审人，由内容责任人提醒一次，仍无反馈的记为“未反馈”，由发布责任人判断是否影响放行。轮次编号与版本号绑定，例如“V1.2 第2轮”，避免多轮意见混在一起。
意见处理是一个循环：提出意见、给出结论、修订、复核。循环在两种情况下结束：阻断级意见全部关闭，或剩余意见经发布责任人确认不影响本次发布并转为后续改进项。转为后续改进项的意见同样要保留记录，写明计划处理的时间和责任人，不能直接删除。
修改意见怎么记录：字段设计与登记规则
意见记录的价值在于可追溯：任何人拿到记录，都能看出谁提了什么、怎么处理的、改在哪里、是否关闭。建议用一张表承载全部意见，字段如下。
| 字段 | 填写规则 |
|---|---|
| 意见编号 | 按“条目版本-轮次-序号”编号，如 V1.2-R1-03，保证全局唯一 |
| 提出人 | 填写评审人姓名及所属团队，便于复核时找回原评审人 |
| 意见内容 | 写具体问题，指明章节或段落，避免“再完善一下”这类无法关闭的表述 |
| 意见类型 | 从事实错误、表述不清、范围不当、需补充示例四类中选择，便于统计和分派 |
| 阻断级别 | 标注阻断或非阻断，阻断级意见未关闭不得发布 |
| 处理结论 | 填写接受、部分接受或不接受，并写明理由 |
| 修订位置 | 填写修订后的章节号或段落标识，必要时附修改前后对照 |
| 状态 | 待处理、已修订待复核、已关闭、转后续改进，四选一 |
| 关联版本与轮次 | 记录意见针对的版本号和评审轮次，修订后版本号同步更新 |
意见类型影响处理方式。事实错误必须修订或以权威依据说明原表述正确；表述不清通常由内容责任人直接改写；范围不当需要评审人和作者共同确认适用边界，可能涉及拆分条目；需补充示例则由作者补充后请原评审人复核。把类型写清楚，处理时就不容易把技术争议当成文字问题糊弄过去。
接受、部分接受、不接受都要留理由。接受的意见写明修订位置；部分接受要说明采纳了哪部分、未采纳部分的原因；不接受要给出依据，例如引用了对应的设计文档或接口定义。理由不是形式要求，它是下一轮复核和后续争议处理的依据。
意见必须与版本和轮次关联。每轮评审开始时冻结一个版本号，本轮所有意见挂在该版本下；修订产生新版本后，未关闭意见带入下一轮并保留原编号。这样发布时能清楚说明：当前定稿版本关闭了哪些轮次的哪些意见。
示例：一份接口说明文档的评审记录
以下为演示情景，用于说明角色分工与记录方式如何配合，不代表任何真实团队的实际记录。
某团队要发布一份“订单查询接口说明 V1.2”，内容责任人为接口维护工程师小陈，领域评审人为调用方前端工程师小周和订单服务技术负责人老李，发布责任人为该研发小组的知识管理员小王。提交材料包括接口说明正文、适用范围（仅覆盖查询类接口，不含下单和退款）、关联需求编号和两个已知待确认问题。
首轮评审在2个工作日内完成，共收到三条意见，登记如下。
| 编号 | 提出人 | 意见内容 | 类型 | 级别 | 处理结论 | 修订位置 | 状态 |
|---|---|---|---|---|---|---|---|
| V1.2-R1-01 | 小周 | 第3节错误码表中“超时”场景返回码与联调实际不一致 | 事实错误 | 阻断 | 接受，按联调记录更正返回码并补充触发条件 | 第3.2节错误码表 | 已关闭 |
| V1.2-R1-02 | 老李 | 适用范围未说明分页上限，调用方可能按无上限设计 | 范围不当 | 阻断 | 接受，补充单页最大条数和超限处理方式 | 第1节适用范围、第4.1节分页参数 | 已关闭 |
| V1.2-R1-03 | 小周 | 建议增加一个完整请求响应示例 | 需补充示例 | 非阻断 | 部分接受，本次补充查询成功示例，异常示例转后续改进 | 第5节示例，异常示例登记为改进项 | 已关闭（含转改进项） |
小陈完成修订后生成 V1.3，将前两条意见标记为“已修订待复核”，请小周和老李分别确认。两人复核通过后，三条意见状态更新为已关闭，其中第三条注明“异常示例转后续改进，责任人小陈，计划下个迭代补充”。小王核对放行条件：阻断级意见全部关闭，非阻断意见有明确结论，版本号与修订记录一致，评审记录已随条目归档，随后发布 V1.3 并登记发布时间和发布范围。
这个示例体现的规律可以迁移到其他知识类型：意见要指到具体位置才可关闭；阻断与非阻断分开管理，避免个别建议拖住发布；部分接受的意见要留下后续安排；发布确认由与作者分离的人完成。
发布前完成检查：审核闭环的核对项
发布前用一张清单逐项核对，比凭印象判断更可靠。以下清单可直接复制使用。
| 核对项 | 通过标准 |
|---|---|
| 角色到位 | 内容责任人、领域评审人、发布责任人均已明确；评审人与作者重合时已注明并另有独立评审人 |
| 评审人范围 | 按知识类型应参与的评审人均已提交意见或明确无意见，无遗漏的关键团队 |
| 阻断意见关闭率 | 阻断级意见关闭率为100%，无“待处理”或“已修订待复核”状态的阻断意见 |
| 非阻断意见处理 | 每条非阻断意见均有接受、部分接受或不接受的结论及理由；转改进项已登记责任人和计划时间 |
| 版本一致性 | 定稿版本号与修订记录、意见记录中的版本号一致，修订位置可定位 |
| 记录归档 | 评审记录已随知识条目归档，包含全部轮次意见、处理结论和发布确认 |
| 发布信息登记 | 发布时间、发布范围、发布责任人已登记，可追溯到对应评审轮次 |
阻断项通常包括：存在未关闭的阻断级意见、关键评审人未参与、定稿版本与评审版本不一致、评审记录缺失。出现任一阻断项即暂缓发布，待补齐后重新核对。非阻断项如个别改进项未排期，可由发布责任人确认后放行，但要在记录中写明。
把审核记录放进研发协作流程
审核记录如果只存在个人文档里，过一段时间就难以追溯。更稳妥的做法是让知识条目与研发过程对象建立关联：接口说明关联对应的需求或接口定义，故障复盘关联故障工单和改进项任务，架构说明关联设计评审记录。这样评审时可以对照上游依据，发布后也能从工作项反查知识条目。
评审意见状态与文档状态应保持同步。文档处于“评审中”时，意见表允许新增和修改；文档进入“待发布”时，意见表只允许关闭和补充结论；发布后意见表随版本冻结。状态不同步会造成“文档已发布但意见还挂着待处理”的情况，发布前检查清单中的版本一致性核对就是针对这一点。
评审记录作为知识条目的关联文档或附件归档，命名建议包含条目名称、版本号和轮次，例如“订单查询接口说明_V1.3_评审记录”。归档位置在团队内统一，便于后续审计和新成员查阅。
在工具承载上，ONES 提供文档协作与工作项管理能力，可以把知识条目与需求、缺陷等工作项关联，将评审意见的处理状态与文档状态放在同一流程中跟踪，并保留版本和评审记录。团队可以据此把上述角色分工、意见字段和检查清单落到具体的文档与工作项上，减少在多个工具之间搬运记录的成本。具体配置方式需结合团队现有的项目结构确定。
常见问题
小团队人手有限，作者能否同时担任评审人和发布责任人？
可以兼任，但要在评审记录中写明兼任情况，并保证至少有一名独立评审人给出技术结论。作者参与评审时，不能只由作者一人签字放行；发布责任人与作者重合时，放行核对仍要按清单逐项执行，并在发布确认中注明“作者兼任发布”。团队规模扩大或知识条目涉及跨团队约定后，应尽早把评审与发布职责分开。
评审人一直不反馈意见，流程卡住了怎么办？
先按事先约定的时限处理：首轮评审给2至3个工作日，超时由内容责任人提醒一次；仍无反馈的，在记录中标记为“未反馈”，由发布责任人判断该评审人是否属于关键评审方。关键评审人未参与通常列为阻断项，需更换评审人或补齐意见后再发布；非关键评审人未反馈且不影响技术结论的，可在记录中说明后放行，并在后续评审中补上。
评审意见和文档修订之间如何避免版本对不上？
每轮评审开始时冻结一个版本号，本轮意见全部挂在该版本下，编号中包含版本和轮次，例如 V1.2-R1-03。修订产生新版本后，未关闭意见带入下一轮并保留原编号，同时更新关联版本字段。发布前核对定稿版本号、修订记录和意见记录三者是否一致，不一致即视为阻断项，暂缓发布。
非阻断意见没有改完，能不能先发布？
可以，前提是每条非阻断意见都有明确处理结论：接受并已修订、部分接受并说明未采纳部分的原因、不接受并给出依据，或者转为后续改进项并登记责任人和计划处理时间。发布责任人确认这些结论后放行，并在发布记录中写明转改进项的安排。直接删除未处理意见或让意见长期停留在“待处理”状态，会使后续追溯失去依据。
评审记录应该保存在哪里，保存多久？
评审记录应作为知识条目的关联文档或附件归档，与条目本身放在一起，命名包含条目名称、版本号和轮次，例如“订单查询接口说明_V1.3_评审记录”。归档位置在团队内统一，便于审计和新成员查阅。保存期限可参照团队对研发过程记录的留存要求确定；知识条目后续修订时，历史轮次的记录保留，不覆盖旧版本。
