复盘做完，结论往往留在会议纪要里，换一个项目就没人记得。要把复盘结论变成别人能检索、能照着用的知识，记录模板需要围绕“复用”来组织：一句话写清结论，再补齐触发条件、适用与不适用场景、关联项目、验证结果和复用动作。下面给出一张可直接复制的空白表、逐字段填写口径、必填与选填的取舍、一条完整示例，以及模板的调整维护方法。
要点总览（TL;DR）
- 模板按“结论—触发条件—适用与不适用场景—关联项目与验证结果—复用动作”组织，让未参会的人也能检索并照着用。
- 必填字段建议为知识标题、可复用结论、触发信号、适用场景、来源项目、首次验证情况；其余字段按团队成熟度逐步补齐。
- 与会议纪要的分工是：纪要按时间留档过程，知识记录按复用要素提炼结论，两者通过链接互相引用。
- 模板落地后按团队规模和场景裁剪字段，并设定复核日期，条件变化的结论及时修订，不再成立的标注过期。
- ONES Wiki 可用页面模板库一键创建制式化文档，页面组关联项目，文档记录版本并支持查看与回滚。
可复制空白模板：复盘结论知识记录表
这张表按“结论—边界—证据—复用”的顺序排列字段，填写时从上往下推进：先写清结论，再界定它在什么条件下成立，最后说明谁来用、怎么用。表格保持空白，可直接复制到文档或知识库页面中填写。
| 分组 | 字段 | 填写内容 |
|---|---|---|
| 结论 | 知识标题 | |
| 可复用结论 | ||
| 触发条件 | 触发信号 | |
| 适用角色 | ||
| 适用与不适用场景 | 适用场景 | |
| 不适用场景 | ||
| 关联项目与证据 | 来源项目 | |
| 关键证据 | ||
| 关联文档链接 | ||
| 验证结果 | 首次验证情况 | |
| 复用验证情况 | ||
| 置信度 | ||
| 复用动作 | 复用动作 | |
| 责任人 | ||
| 复核日期 | ||
| 知识状态 |
如果团队使用 ONES Wiki 承载知识库，可以把这张表做成页面模板，借助页面模板库一键创建制式化文档，让每次复盘产出结构一致的记录；页面组可关联项目，使知识记录与来源项目互相对应，便于后续检索。
字段说明：每个字段记录什么、怎么填
字段之间是递进关系：结论回答“做什么”，触发条件回答“什么时候用”，场景回答“用到哪为止”，关联项目与验证结果回答“凭什么信”，复用动作回答“谁来用、怎么用”。任何一个环节空缺，未参会的人都难以直接套用。
| 字段 | 记录什么 | 填写口径与常见写法 |
|---|---|---|
| 知识标题 | 这条知识的一句话索引 | 用“场景+做法”命名，例如“大促前压测窗口不足时的分批上线做法”，避免“XX项目复盘”这类无法检索的标题 |
| 可复用结论 | 从复盘中提炼出的可执行做法 | 一句话写清动作和对象，例如“需求变更超过三次时，先冻结范围再重排期”；避免“加强沟通”“提前评估”这类无法执行的口号 |
| 触发信号 | 什么情况下应调用这条知识 | 写可观察的信号，例如“同类需求一周内变更三次以上”“同类接口错误率连续两天超过阈值” |
| 适用角色 | 谁会用到这条知识 | 写岗位或角色，例如项目经理、测试负责人、值班工程师 |
| 适用场景 | 结论成立的条件范围 | 写清项目类型、阶段、团队规模等前提，例如“适用于迭代周期两周以内的中小型项目” |
| 不适用场景 | 结论不应套用的边界 | 与适用场景成对填写，例如“不适用于跨部门强依赖的联合项目”，防止知识被过度泛化 |
| 来源项目 | 结论来自哪次实践 | 写项目名称与复盘时间，便于追溯原始上下文 |
| 关键证据 | 支撑结论的数据或事实 | 写可核对的指标或事件，例如“变更冻结后平均交付周期从9天降至6天” |
| 关联文档链接 | 原始复盘纪要、数据报表等 | 链接到会议纪要或数据页面，让读者能回到过程记录 |
| 首次验证情况 | 结论在来源项目中的效果 | 写结果与观察周期，例如“上线后两个迭代内未再出现范围蔓延” |
| 复用验证情况 | 其他项目套用后的效果 | 每次复用后补充一条，注明项目与结果；尚无复用记录时写“待验证” |
| 置信度 | 结论的可信程度 | 可用“高/中/低”三档，依据验证次数与证据强度判断，并简述理由 |
| 复用动作 | 读者拿到这条知识后做什么 | 写具体动作，例如“在下一次范围评审会上引用本结论并冻结变更” |
| 责任人 | 谁负责维护这条记录 | 写具体人名或角色，负责后续补充验证结果与复核 |
| 复核日期 | 下次检查结论是否仍成立的时间 | 按结论的时效性设定，例如流程类结论每半年复核一次 |
| 知识状态 | 记录当前所处阶段 | 可设为“草稿/已验证/已复用/已过期”，便于检索时筛选 |
必填与选填：哪些字段决定这条知识能否被复用
判断必填的依据是：缺了它，未参会的人是否还能正确使用这条结论。结论、触发条件、适用场景、来源项目、验证结果五项直接决定可用性，应作为必填；其余字段影响使用效率和长期维护，可按团队成熟度逐步补齐。
| 字段 | 必填/选填 | 理由与使用时机 |
|---|---|---|
| 知识标题 | 必填 | 检索入口，缺失则知识无法被找到 |
| 可复用结论 | 必填 | 记录的核心内容，缺失则整条记录失去意义 |
| 触发信号 | 必填 | 决定读者何时调用，缺失则知识只能被动存档 |
| 适用场景 | 必填 | 界定结论成立的前提，缺失易被误用 |
| 来源项目 | 必填 | 提供追溯线索，缺失则结论无法核实 |
| 验证结果（首次验证情况） | 必填 | 说明结论在实践中是否有效，缺失则置信度无从判断 |
| 不适用场景 | 选填 | 结论边界清晰、误用风险低时可暂缓；跨团队推广前建议补齐 |
| 关键证据 | 选填 | 有数据支撑时填写，能显著提升可信度；早期记录可先留空 |
| 关联文档链接 | 选填 | 有原始纪要或报表时填写，便于读者回看过程 |
| 复用验证情况 | 选填 | 首次记录时通常为空，每次复用后补充 |
| 置信度 | 选填 | 验证次数积累后可标注，帮助读者判断采纳力度 |
| 复用动作 | 选填 | 结论指向明确动作时可省略；面向多角色推广时建议填写 |
| 责任人 | 选填 | 小团队可由复盘主持人兼任；知识量增大后应明确到人 |
| 复核日期 | 选填 | 流程、工具类易变化的结论建议填写 |
| 知识状态 | 选填 | 知识库规模较小时可省略，靠目录区分即可 |
字段缺失时按以下方式处理：必填项暂时写不出的，记录标为“草稿”并指定补全时间，不进入正式知识目录；选填项缺失不影响发布，但在复用验证后应回填，避免记录长期停留在初始状态。若某条结论在复用时被证明不成立，应更新结论或标注失效，而不是直接删除，保留失效记录有助于后来者理解边界变化。
填写示例：一条完整填好的复盘知识记录
以下为情景演示，用于说明各字段如何对应填写，数据为示意，不代表真实项目。
| 字段 | 示例内容 |
|---|---|
| 知识标题 | 需求频繁变更时的范围冻结与重排期做法 |
| 可复用结论 | 同一需求在一周内变更超过三次时，先冻结范围，再由项目经理组织重排期，不直接插入当前迭代 |
| 触发信号 | 需求变更单一周内达到三次及以上，或变更涉及已进入开发的任务 |
| 适用角色 | 项目经理、产品经理、研发负责人 |
| 适用场景 | 迭代周期两周以内、需求方与研发同属一个业务线的中小型项目 |
| 不适用场景 | 跨部门强依赖的联合项目；合规或安全类紧急变更 |
| 来源项目 | 某业务中台迭代项目，2024年第二季度复盘 |
| 关键证据 | 冻结范围后，该迭代按期交付率由60%回升至90%，范围蔓延投诉归零 |
| 关联文档链接 | 该项目复盘会议纪要、迭代交付数据报表 |
| 首次验证情况 | 来源项目后续两个迭代未再出现范围蔓延，交付周期稳定 |
| 复用验证情况 | 另一条业务线套用后，变更评审耗时下降，待补充完整数据 |
| 置信度 | 中：有一次跨项目复用，证据以交付率为主 |
| 复用动作 | 在下一次范围评审会上引用本结论，触发冻结条件时按流程提交重排期申请 |
| 责任人 | 项目管理办公室指定接口人 |
| 复核日期 | 2025年第一季度末 |
| 知识状态 | 已复用 |
示例中“触发信号”与“适用场景”共同限定了调用条件，“不适用场景”划出了边界，“来源项目”和“验证结果”构成证据链。读者即使没有参加那次复盘，也能判断这条结论是否适用于自己手上的项目。
与普通会议纪要的区别：记录对象和用途不同
会议纪要记录过程，知识记录承载结论，两者职责不同但可以并存。复盘结束后，纪要继续保留讨论脉络和决策依据，知识记录则从纪要中提炼出可复用部分，并通过链接互相引用。
| 对比维度 | 普通会议纪要 | 复盘知识记录模板 |
|---|---|---|
| 记录对象 | 谁在什么时间说了什么、做了哪些决定 | 提炼后的可复用结论及其适用边界 |
| 用途 | 留档追溯，还原讨论过程 | 被检索、被套用，支撑其他项目决策 |
| 结构 | 按时间或议题顺序展开 | 按结论、条件、证据、复用动作组织 |
| 读者 | 参会者与需要了解过程的人 | 未参会的其他项目成员 |
| 更新方式 | 定稿后基本不再改动 | 随复用验证持续补充，定期复核 |
实践中常见的混用是把纪要直接当知识归档：结论散落在讨论过程中，检索时只能靠关键词碰运气。更稳妥的做法是纪要定稿后，由复盘主持人按模板提炼一到三条知识记录，并在纪要中链接过去。使用 ONES Wiki 时，纪要页面与知识记录页面可以放在同一页面组内，页面组关联来源项目，读者从项目入口就能同时看到过程记录和提炼结论。
调整与维护：模板如何随团队和场景演进
模板落地后需要按团队实际情况裁剪，并建立定期复核机制，否则字段会越填越形式化，知识记录逐渐失去复用价值。
按团队规模与场景裁剪。五人以下的小团队可先保留标题、结论、触发信号、适用场景、来源项目五项，验证结果在首次复用后补；跨部门协作较多时，再补上不适用场景、适用角色和复用动作。面向运维值班、客户支持等高频复用场景，可增加“快速判断步骤”字段；面向研发流程类结论，可增加“关联规范文档”字段。
新增字段的触发条件。出现以下情况时考虑扩展模板：同类知识被反复误用，说明边界字段不够；读者反馈找不到调用时机，说明触发信号写得不够具体；多条记录长期无人复用，说明缺少复用动作或责任人。新增字段应先在少量记录中试用，确认填写成本可接受后再推广。
过期知识的复核与更新机制。按复核日期定期检查，重点看三类变化：结论依赖的工具或流程是否已调整、适用场景的前提是否仍成立、复用验证是否出现反例。复核后更新知识状态，仍有效的延长复核日期，条件变化的修订结论，不再成立的标注“已过期”并说明原因。
维护责任人与节奏。每条记录指定一名责任人，负责补充复用验证和到期复核；知识库层面可由项目管理办公室或知识运营角色按季度汇总，检查草稿积压、过期未处理和长期零复用的记录。ONES Wiki 文档实时同步并记录页面版本，支持随时查看与回滚，复核修订时可以对照历史版本确认改动范围；文档中也可嵌入任务进度和报表，把复用验证的数据直接呈现在记录旁边。
常见问题
复盘会上结论很多，一条知识记录该写几条结论？
建议一条记录只承载一条可复用结论。结论多了，触发条件和适用场景会互相缠绕，读者难以判断该在什么时候调用。复盘主持人可以在纪要定稿后先列出候选结论，再按“是否可执行、是否有边界、是否有证据”筛出最值得沉淀的一到三条，分别建记录，其余留在纪要中备查。
结论还没有经过其他项目复用，能先发布到知识库吗？
可以，但要如实标注状态。首次验证情况写清来源项目中的效果，复用验证情况填“待验证”，知识状态设为“已验证”而非“已复用”，置信度按证据强度给出并简述理由。这样读者能判断这条结论目前只有单项目证据，套用前会更谨慎地核对适用场景。
模板字段太多，小团队填写负担重，怎么裁剪？
先保留决定可用性的五项：知识标题、可复用结论、触发信号、适用场景、来源项目，验证结果在首次复用后回填。不适用场景、关键证据、复用动作、责任人、复核日期等字段可以暂缓，等知识量增大或出现误用案例后再补。裁剪的原则是缺了它读者是否还能正确使用，而不是字段越全越好。
知识记录和会议纪要要不要合并成一份文档？
不建议合并。纪要按时间记录讨论过程和决策依据，定稿后基本不再改动；知识记录按复用要素组织，会随复用验证持续补充。更稳妥的做法是纪要定稿后由主持人提炼知识记录，并在纪要中链接过去。使用 ONES Wiki 时，两类页面可以放在同一页面组内并关联来源项目，从项目入口同时看到过程记录和提炼结论。
过期知识应该删除还是保留？
建议保留并标注“已过期”，同时写明失效原因和替代结论。直接删除会让后来者失去边界变化的线索，也可能让同类错误再次发生。复核时重点检查结论依赖的工具或流程是否调整、适用前提是否仍成立、复用中是否出现反例，据此决定延长复核日期、修订结论还是标注过期。
