迭代回顾记录的价值在于形成“会前收集—会中讨论—会后行动项跟踪—下轮复盘回看”的闭环。在线文档适合轻量记录，知识库适合沉淀历史经验，项目管理工具能把回顾结论直接转成可指派、可跟踪的工作项。本文以ONES、飞书文档、Confluence、Notion、腾讯文档、Jira为候选，按记录结构、行动项跟踪、历史检索、迭代数据关联、权限协作、导出迁移六个维度做同口径对照，帮助团队判断载体与工具。
要点总览（TL;DR）
- 迭代回顾记录的关键是跑通“会前收集—会中讨论—会后行动项跟踪—下轮回看”的闭环，载体选择取决于团队对行动项跟进强度的要求。
- 在线文档适合轻量记录和会中协作，知识库适合按迭代沉淀历史，项目管理工具能把回顾结论直接转成可指派、可跟踪的工作项。
- 选型重点比较六个维度：记录结构、行动项跟踪、历史检索、迭代数据关联、权限协作、导出迁移。
- 试用时用一次真实迭代回顾做端到端演练，会前收集、会中记录、会后指派行动项、下轮回看，比看功能清单更能判断适配度。
- 已经在用项目管理工具管理迭代的团队，优先把回顾记录与行动项放在同一平台；以文档协作为主的团队可先用在线文档加模板跑起来。
候选工具与同口径快速对照
本次候选覆盖三类载体：项目管理工具包括ONES与Jira，在线文档包括飞书文档与腾讯文档，知识库与文档协作平台包括Confluence与Notion。三类工具的定位差异决定了它们在回顾闭环中的分工：项目管理工具强在行动项与迭代数据同源，在线文档强在会中协作与快速成文，知识库强在跨迭代沉淀与检索。下表按六个维度给出概览，具体版本、套餐与价格需向厂商核验。
| 工具 | 载体定位 | 记录结构 | 行动项跟踪 | 历史检索 | 迭代数据关联 | 权限与协作 | 导出与迁移 |
|---|---|---|---|---|---|---|---|
| ONES | 项目管理工具，含Wiki知识沉淀 | Wiki页面自行约定栏目，可关联工作项 | 行动项可建为工作项，指派负责人并纳入迭代 | 依赖Wiki页面组织与搜索，需试用验证 | 燃尽图、工时日志、报表与迭代同源 | 项目与Wiki权限需分别确认 | 导出格式与迁移方式需向厂商确认 |
| 飞书文档 | 在线文档与协作套件 | 标题、表格、待办清单可搭模板 | 待办可指派勾选，跨迭代汇总需配合多维表格 | 空间内关键词搜索与归档较直接 | 可嵌入表格、看板或链接工作项 | 按文档或文件夹设置查看、评论、编辑 | 支持常见办公格式导出，嵌入内容保留度需确认 |
| Confluence | 知识库与文档协作平台 | 页面树加模板，按迭代建子页面 | 任务列表较弱，常同步为Jira问题跟踪 | 搜索覆盖正文、标题与附件，可加标签 | 可嵌入Jira问题与冲刺报告 | 按空间与页面设置权限 | 支持PDF、Word、HTML导出，插件依赖需核验 |
| Notion | 文档加数据库的知识库 | 页面模板加嵌套子页面，结构统一 | 行动项数据库可设负责人、状态、看板视图 | 全局搜索加页面索引 | 关联数据库连接迭代与项目页面 | 按页面或数据库授权 | 支持文档与表格格式导出，关联字段保留需确认 |
| 腾讯文档 | 在线文档与表格 | 文档或表格固定字段，按迭代命名归档 | 表格设负责人、截止时间、状态列 | 文件夹加索引表辅助检索 | 以表格或链接附迭代数据，口径以原工具为准 | 按团队范围设置编辑与查看权限 | 支持常见文件格式导出 |
| Jira | 项目与问题跟踪工具 | 回顾issue或页面模板承载讨论 | 行动项建为issue，纳入Sprint并筛选跟踪 | JQL与保存的筛选器组合查询 | Sprint、版本与issue关联紧密 | 沿用项目权限方案 | 筛选结果可导出CSV，字段范围需核验 |
对照基于公开产品定位与通用能力整理，表中“需确认”“需核验”的条目表示本次未取得直接资料，应作为试用阶段的检查项，不能据此判定产品缺少该能力。
迭代回顾记录工具逐款评估
ONES
ONES 适合已经按迭代组织研发工作、希望把回顾记录与迭代数据放在同一套系统里管理的团队。它的相关能力分布在 ONES Project 与 ONES Wiki 两个模块：Project 承载需求、任务、缺陷和迭代，Wiki 承载文档与知识沉淀。对于正在使用 ONES 管理迭代的团队，回顾会所需的进度、质量和成本数据可以直接从既有工作项和报表中取得，记录与后续改进事项也能留在同一平台内。
回顾所需的数据基础。ONES 敏捷研发管理方案覆盖迭代回顾场景：迭代完成并发布后，团队可以召开全员回顾会，借助燃尽图、工时日志、持续集成报告等报表，复盘迭代进度、质量和成本方面的偏差，并讨论改进建议。这一流程的前提是团队采用 Scrum 等敏捷流程、按迭代交付，且回顾发生在迭代收尾阶段。ONES Project 提供看板、燃尽图等进度工具，报表的数据范围和维度可按团队需要自定义，因此回顾会前可以针对本迭代圈定要看的指标，把讨论建立在具体数据上，减少凭印象争论。
记录结构与知识沉淀。回顾会的结论可以用 ONES Wiki 沉淀为团队知识库，按迭代或主题组织页面，形成可回看的经验积累。Wiki 支持文档关联任务，也能插入 ONES Project 的工作项列表，回顾记录因此可以直接指向本迭代的具体需求、任务或缺陷，读者从文档就能跳转到对应工作项核对上下文。内置的回顾模板与固定记录结构在现有资料中未见说明，团队可以自行在 Wiki 中约定回顾页面的栏目，例如本迭代数据摘要、做得好的地方、待改进项和行动项，用统一格式保证多次回顾之间可比。
行动项跟踪与历史检索。回顾产生的改进事项需要落到可跟踪的载体上。一种可行做法是在 ONES Project 中建立改进任务或需求，指定负责人并纳入下一迭代规划，让行动项与正常研发工作走同一套状态流转；同时在 Wiki 回顾页中保留指向这些工作项的链接，形成从记录到执行的对应关系。行动项从回顾记录自动生成并闭环跟踪的完整链路，现有资料未作说明，团队需要在流程上明确由谁在会后录入、何时检查。历史回顾的检索与跨迭代对比同样建议提前确认：Wiki 的页面组织方式、搜索能力和版本记录能否满足按迭代回溯的需求，可以在试用阶段用两三个迭代的真实记录验证。
协作、权限与适配建议。回顾涉及全员参与，也会涉及敏感讨论，权限设置需要与团队文化匹配。ONES 的项目、知识、测试等能力可以按需组合使用，回顾记录放在 Wiki、行动项放在 Project 时，需要确认两处的访问权限范围一致，避免出现记录可见而行动项不可见、或反之的情况。导出格式与迁移方式在现有资料中未见具体说明，若团队有归档到外部系统或跨工具迁移的要求，建议在选型阶段实际验证导出结果的完整性与可读性。总体而言，ONES 更适合已经把迭代管理放在该平台上、并愿意用 Wiki 维护团队知识库的研发团队；回顾流程本身仍需团队自行约定会议节奏、记录模板和行动项检查机制，工具承担的是数据呈现、记录留存与工作项衔接。
飞书文档
飞书文档适合把迭代回顾从会议过程到后续跟进放在同一份文档里完成，尤其适合已经在使用飞书办公套件、希望回顾记录与日常协作保持在同一工作空间的团队。它面向的典型对象包括产品研发团队、项目负责人和敏捷教练，使用场景覆盖会前收集素材、会中同步记录、会后跟踪行动项。
记录结构方面，飞书文档支持标题层级、分栏、表格、待办清单等常见排版元素，团队可以按“本迭代做得好、待改进、讨论结论、行动项”搭建固定模板，并在后续迭代中复用。模板的价值在于让不同轮次的回顾记录保持一致的字段顺序，便于成员快速定位信息。行动项跟踪方面，文档内的待办项可以指派负责人并勾选完成状态，适合记录责任人和截止时间的轻量跟踪；如果团队需要跨迭代汇总行动项完成率，通常要配合多维表格或任务模块建立单独的行动项台账，文档承担记录与讨论沉淀的角色。
历史检索是飞书文档较直接的优势：同一空间内的回顾文档可以按标题、正文关键词搜索，也可以按时间或文件夹归档，形成连续的迭代记录序列。团队可以约定每轮回顾文档的命名规则，例如“迭代编号+回顾日期”，让检索和回溯更稳定。迭代数据关联方面，文档可以嵌入表格、看板视图或链接到需求、缺陷等工作项，把回顾讨论与具体迭代数据放在同一页面上下文中；嵌入内容的实时性取决于所引用数据源的权限与同步方式，涉及跨系统数据时需要在会前确认引用是否可正常打开。
权限与协作方面，飞书文档支持按文档或文件夹设置查看、评论、编辑权限，适合回顾会这种需要多人同时补充、会后由负责人整理定稿的协作方式。评论和@提醒可以把讨论集中在具体段落旁，减少信息散落。导出与迁移方面，文档通常支持导出为常见办公格式，便于归档或对外分享；如果团队有长期留存或跨平台迁移要求，建议提前确认导出格式对表格、待办状态和嵌入内容的保留程度。
适配建议上，把飞书文档作为迭代回顾的记录与协作载体，配合固定的文档模板、统一的命名与归档规则，以及独立的行动项汇总表，能够覆盖回顾会议的主要环节。对于行动项闭环要求高、需要统计完成趋势的团队，可以在文档之外建立结构化的行动项清单，并明确每轮回顾结束后的整理责任人与复查时间。
Confluence
Confluence 是 Atlassian 旗下的团队知识管理与文档协作平台，在敏捷团队中常被用作迭代回顾的记录与沉淀空间。它的页面树结构适合把回顾记录按团队、季度或迭代编号归档：每个迭代建一个子页面，页面内按“做得好的、待改进、行动项”分区记录，配合模板可以保持多轮回顾的格式一致。对于已经使用 Jira 的团队，Confluence 与 Jira 的联动是它在这一场景中的主要优势，回顾页面可以直接嵌入 Jira 问题列表或筛选器结果，让讨论对象与具体任务、缺陷保持对应。
记录结构与协作方面，Confluence 支持多人同时编辑同一页面，评论可以挂在段落或具体内容上，回顾会中分散的意见能够就地汇总。页面版本历史保留每次修改，便于回溯某条结论是哪一轮讨论后形成的。使用条件是团队需要事先约定页面层级和模板，否则多轮回顾容易散落在不同空间，检索时依赖标题命名规范。行动项跟踪是 Confluence 相对薄弱的环节：它可以在页面中用任务列表或表格记录负责人和截止时间，但任务完成状态、逾期提醒和跨迭代汇总需要借助 Jira 问题或第三方插件实现。把行动项同步为 Jira 任务，再在回顾页面嵌入其状态，是较为常见的做法。
历史检索与迭代数据关联方面，Confluence 的搜索覆盖页面正文、标题和附件，配合标签和页面属性可以按迭代号筛选。若团队在 Jira 中管理迭代，Confluence 页面可引用对应的 Jira 版本或冲刺报告，形成“回顾结论—迭代数据”的关联。这一关联的完整程度取决于团队是否在 Jira 中维护规范的迭代字段，以及是否愿意在每轮回顾后更新页面链接。权限与协作上，Confluence 按空间和页面设置查看、编辑权限，适合把回顾记录开放给相关团队、同时限制敏感讨论的可见范围。
导出与迁移方面，Confluence 页面支持导出为 PDF、Word 和 HTML，便于归档或向外部干系人分享；空间级别可以整体导出备份。需要核验的是插件依赖情况：任务列表汇总、看板视图、与 Jira 的深度联动等功能部分依赖 Marketplace 应用，选型时应确认所需插件在目标部署方式（云版或数据中心版）中的可用性与授权成本。
适配建议：如果团队已经在使用 Jira，并希望回顾记录与任务数据留在同一生态内，Confluence 的页面模板加 Jira 嵌入组合能够覆盖记录、讨论和行动项同步的主要环节；如果团队更看重行动项的独立跟踪与提醒，需要在 Confluence 之外明确任务落点，或评估插件方案。落地时建议先固定一套回顾页面模板和命名规则，把行动项统一转为 Jira 问题并在页面中嵌入状态，再按迭代节奏维护页面树，这样历史检索和跨迭代对比才有稳定的结构基础。
Notion
Notion 适合把迭代回顾从一次会议记录沉淀为可检索、可追踪的团队知识库。它把文档、数据库和看板放在同一工作空间里，回顾记录可以按迭代、团队或项目建立统一模板，会后行动项直接进入数据库视图跟踪，历史记录也能通过页面层级和搜索持续积累。
记录结构方面，Notion 的页面可以嵌套子页面，配合模板把回顾会议固定为“本迭代数据回顾—做得好的—待改进—行动项”几个区块。团队每次新建回顾页面时套用同一模板，记录格式保持一致，跨迭代对比时不需要重新整理结构。模板中可以嵌入数据库，把行动项作为独立条目管理，而不是散落在正文段落里。
行动项跟踪是 Notion 在回顾场景中的关键能力。行动项数据库可以设置负责人、截止时间、状态和关联迭代等属性，并通过看板视图按状态流转、通过表格视图按负责人筛选。回顾会上产生的改进项当场录入，会后由负责人更新状态，下次回顾时直接调取未关闭事项核对。这里的使用条件是团队约定好状态字段的含义和更新节奏，否则数据库视图容易停留在创建时的状态。
历史检索与迭代数据关联方面，Notion 的全局搜索可以按关键词定位过往回顾页面，页面间的关联数据库能把行动项与所属迭代、相关项目页面连接起来。团队可以在项目主页汇总各迭代回顾的链接，形成按时间排列的回顾索引。需要核验的是搜索在团队页面数量增长后的实际效果，以及关联关系是否按团队习惯设计，避免页面层级过深导致查找路径变长。
权限与协作方面，Notion 支持按页面或数据库设置访问权限，回顾记录可以限定在团队范围内，跨团队分享时单独授权。多人同时编辑页面和数据库条目，评论可以挂在具体区块上，适合会前异步补充、会中集中讨论的协作方式。导出方面，页面和数据库支持导出为常见文档与表格格式，迁移前建议先确认导出内容的层级和关联字段是否完整保留。
适配建议：团队规模中等、已经用 Notion 承载项目文档和知识库时，把迭代回顾纳入同一空间可以减少工具切换，行动项也能和项目页面自然关联。若团队更看重开箱即用的回顾流程和严格的字段约束，需要先在模板和数据库属性上做一轮设计，并明确谁维护模板、谁负责行动项状态更新，再逐步推广到各个迭代。
腾讯文档
腾讯文档适合把迭代回顾从会议记录延伸到行动项跟进和跨迭代复盘的团队，尤其是已经在使用腾讯文档做需求文档、会议纪要或项目资料沉淀的团队。它提供在线文档、表格、收集表等形态，回顾会可以用文档承载讨论过程，用表格管理行动项，再把历史记录按迭代归档，减少会后另找工具整理的成本。
记录结构方面，腾讯文档可以用在线文档按“本迭代目标—数据表现—做得好的地方—待改进项—行动项”组织回顾内容，也可以直接用表格建立固定字段，让每次回顾按同一结构填写。文档适合保留讨论上下文和结论，表格适合逐条管理改进项，团队可以按回顾习惯选择一种主结构，避免同一迭代出现多份分散记录。行动项跟踪是回顾能否落地的关键，在表格中设置负责人、截止时间、状态和验证结果等列，会后把待改进项逐条录入，并在下一次回顾前更新进度，能让行动项从会议结论变成可检查的任务。腾讯文档的协作编辑和评论功能便于负责人在线更新状态，也方便其他成员补充进展。
历史检索方面，按迭代周期建立文件夹或统一命名文档，例如“2025-Q1-迭代3-回顾记录”，可以让团队按时间或版本快速找到过往结论。腾讯文档支持在文档和表格内查找内容，团队还可以维护一份回顾索引表，记录每次回顾的日期、参与人、主要结论和行动项链接，后续复盘时从索引进入具体记录。迭代数据关联方面，回顾记录可以把需求完成情况、缺陷数量、发布节奏等数据以表格或链接形式附在文档中，便于讨论时对照。若团队已有需求管理或研发管理工具，腾讯文档更适合承担回顾讨论和结论沉淀的角色，数据口径仍以原工具为准。
权限与协作方面，回顾记录通常涉及团队内部讨论，建议按团队范围设置文档权限，区分可编辑成员和仅查看成员；涉及跨团队可见的结论，可以单独整理一份摘要文档再开放查看。腾讯文档支持多人同时编辑、评论和版本记录，适合回顾会现场共同补充内容，也便于会后由主持人整理定稿。导出与迁移方面，文档和表格可以导出为常见文件格式，便于归档或发给未加入协作空间的成员；如果团队后续调整工具，建议保留按迭代命名的原始文件和索引表，降低迁移时的整理成本。
适配建议上，如果团队规模较小、回顾频率固定，可以从一份表格模板开始，把行动项跟踪作为核心，文档只保留会议结论和背景说明；如果团队已经用腾讯文档承载项目资料，建议统一回顾记录的存放位置和命名规则，并在每次回顾开始时先检查上一轮行动项状态。需要核验的是团队账号的存储空间、外部分享权限和版本保留策略是否符合内部管理要求，具体以团队当前使用的腾讯文档版本和权限设置为准。
Jira
Jira 是 Atlassian 推出的项目与问题跟踪工具，在研发团队中常被用作敏捷迭代管理的主平台。用它管理迭代回顾记录，核心思路是把回顾从一次会议纪要变成可追踪的工作项：回顾中的讨论、结论和改进行动都落在 Jira 的 issue 上，与迭代、版本、负责人和状态流转共用一套数据。对于已经在 Jira 中跑 Sprint 的团队，回顾记录与迭代数据同源，能减少会后再手工搬运和对照的成本。
记录结构方面，常见做法是在项目下建立一个回顾专用 issue 类型或使用 Confluence 页面承载讨论内容，再为每条改进行动创建独立 issue。讨论过程可以按“做得好的、待改进的、行动项”分组，行动项作为独立工作项保留描述、负责人、优先级和截止日期。这样回顾产出有统一模板，不同迭代的记录格式一致，便于横向查看。行动项跟踪是 Jira 的强项：行动项进入 Backlog 或指定看板后，可以分配负责人、设置到期日、关联到具体 Sprint，并通过筛选器或仪表盘查看未关闭项。团队可以在下一次回顾开始时先过一遍上期行动项的状态，让回顾形成闭环。
迭代数据关联方面，Jira 的 Sprint、版本和 issue 关联能力让回顾中的结论可以直接引用当期数据，例如本 Sprint 的完成情况、遗留项和缺陷分布。回顾记录与迭代绑定后，后续检索某个 Sprint 的改进历史会比较直接。历史检索依赖 JQL 和筛选器，按项目、时间、标签或自定义字段组合查询回顾 issue，也可以保存常用查询供团队复用。权限与协作沿用 Jira 的项目权限方案，回顾内容的可见范围、评论和提及机制与团队日常使用一致，适合已经统一在 Jira 内协作的团队。
使用前需要确认几点：回顾记录采用 issue 还是页面承载，取决于团队是否同时使用 Confluence；行动项需要约定统一的字段和状态流转，否则容易散落在各 Sprint 中难以汇总；JQL 查询和仪表盘需要有人维护，才能保证历史回顾可检索。导出方面，Jira 支持将筛选结果导出为 CSV 等格式，具体字段和批量导出范围建议按团队实际版本核验。对于回顾内容涉及敏感讨论的团队，还需要提前规划项目权限和可见性设置。
适配建议：已经在 Jira 中管理 Sprint 的研发团队，可以把回顾模板固化为 issue 描述模板或页面模板，把每条改进行动建成独立 issue 并纳入下一次 Sprint 的规划；团队规模较大时，用标签或自定义字段区分回顾来源和行动项类别，配合保存的筛选器定期检查未关闭行动项。若团队尚未使用 Jira，或回顾主要以自由讨论和文档沉淀为主，则需要评估引入 Jira 后的配置与维护成本，再决定回顾记录的承载方式。
回顾记录该放文档、知识库还是项目管理工具
三类载体承担不同任务，判断的关键是团队对行动项跟进强度的要求。文档负责记录，优势在会中多人同时补充、快速成文；知识库负责沉淀，优势在按迭代归档、跨轮次检索；项目管理工具负责行动项闭环，优势在结论直接变成可指派、可跟踪、可统计的工作项。回顾记录放在哪里，取决于团队更需要“记得快”还是“跟得住”。
按团队情况可以走三条路径。团队规模小、回顾频率低、改进项以讨论为主时，用在线文档加固定模板即可，会后由主持人整理结论并口头跟进，成本最低。团队已经积累多个迭代、需要回看历史经验时，应把回顾记录放进知识库，按迭代编号建页面，形成可检索的序列。团队行动项多、跨迭代遗留常见、需要统计完成情况时，应以项目管理工具为主载体，把每条改进项建成工作项，记录页只保留讨论摘要和指向工作项的链接。
组合使用是常见做法，边界需要提前约定：回顾讨论与结论写在文档或知识库页面，行动项统一录入项目管理工具，页面中保留行动项链接；下一轮回顾开始时先过一遍上期行动项状态，再讨论新议题。组合的代价是两处维护，因此要明确谁在会后录入行动项、何时检查状态，避免记录与执行脱节。
选型维度与验证建议
六个比较维度可以落成具体检查点，试用时逐项验证，而不是只看功能列表。
| 维度 | 检查点 | 验证动作 |
|---|---|---|
| 记录结构 | 是否有可复用的回顾模板；栏目能否固定为数据摘要、做得好、待改进、行动项 | 用同一模板连续建两轮回顾页面，检查格式是否一致、字段是否齐全 |
| 行动项跟踪 | 行动项能否指派负责人、设截止时间、更新状态；能否跨迭代汇总 | 把三条改进项录入并指派，模拟逾期与关闭，检查汇总视图是否可用 |
| 历史检索 | 能否按迭代编号、关键词、时间找到过往回顾 | 建三到五个迭代的模拟记录，用搜索和筛选各找一次 |
| 迭代数据关联 | 回顾页面能否引用本迭代的进度、缺陷、工时数据 | 在回顾页中嵌入或链接迭代数据，检查打开权限与数据是否同步 |
| 权限与协作 | 记录与行动项的可见范围是否一致；能否限制敏感讨论 | 用不同角色账号分别查看记录页与行动项，核对权限差异 |
| 导出与迁移 | 导出格式是否保留表格、状态与关联；迁移路径是否清晰 | 实际导出一轮回顾记录，检查内容完整性与可读性 |
试用建议用一次真实迭代回顾做端到端演练：会前在工具中收集议题和数据，会中记录讨论，会后把改进项转为行动项并指派，下一轮回顾开始时回看上期行动项状态。这一轮走通，比任何功能清单都更能说明工具是否适配。需要向厂商确认的事项包括：目标版本是否包含所需模块、权限粒度能否满足团队要求、导出格式与批量导出范围、价格与计费方式，以及数据迁移的支持方式。
选择建议与落地步骤
选择方向可以按团队现状判断：已经在用某项目管理工具管理迭代的团队，优先把回顾记录与行动项放在同一平台，减少数据搬运；以文档协作为主、迭代管理较松的团队，先用在线文档加模板跑起来，行动项增多后再引入结构化跟踪；跨团队共享回顾经验较多的组织，把知识库作为沉淀主阵地，行动项落到项目管理工具。
落地可以按以下步骤推进：
- 确定回顾模板，固定数据摘要、做得好、待改进、行动项四个栏目，并约定页面命名规则，例如“迭代编号+回顾日期”。
- 确定行动项的唯一落点，明确每条行动项的负责人、截止时间和验收方式，会后当天完成录入。
- 把回顾页面与迭代数据关联，会前准备好本期进度、质量与工时数据，让讨论有据可依。
- 下一轮回顾开始时先检查上期行动项状态，未关闭项说明原因并决定是否延续。
- 每季度回看一次回顾记录，检查行动项完成率与重复出现的问题，据此调整模板和流程。
上线后判断闭环是否运转，可以看三个信号：行动项是否在会后一周内全部有负责人和截止时间；下轮回顾是否真的逐条检查了上期行动项；连续几轮回顾中重复出现的问题是否在减少。三个信号都稳定，说明记录、跟踪与回看已经连成一条线；若行动项长期停留在记录页、无人更新状态，则需要调整载体或明确责任人，而不是继续增加记录内容。
常见问题
团队规模小、回顾频率不高，还有必要上项目管理工具吗？
可以先从在线文档加固定模板开始。团队规模小、改进项以讨论为主时，文档能覆盖会中记录和会后整理，成本最低。判断是否需要换载体的信号是行动项开始跨迭代遗留、需要统计完成情况，或者回顾结论经常找不到落点。出现这些情况时，再把行动项迁到项目管理工具，记录页保留讨论摘要和指向工作项的链接。
回顾记录放在知识库、行动项放在项目管理工具，两处权限怎么对齐？
组合使用时，记录页和行动项的可见范围要提前核对。建议用不同角色账号分别打开回顾页面和对应工作项，确认能看记录的人也能看到行动项状态，涉及敏感讨论的内容单独限制可见范围。ONES 的项目与 Wiki 权限需分别设置，选型阶段应确认两处权限范围能否保持一致，避免记录可见而行动项不可见。
上一轮回顾的行动项没做完，下一轮回顾应该怎么处理？
下一轮回顾开始时先逐条检查上期行动项状态，未关闭项要说明原因，再决定是延续到本轮、调整负责人还是关闭。未完成的工作需要重新评估优先级和资源，不能默认自动结转到下一迭代。把这一步固定为回顾会议的第一个环节，行动项才不会停留在记录页里无人更新。
试用阶段怎么验证历史检索和跨迭代对比是否够用？
建三到五个迭代的模拟记录，按迭代编号、关键词、时间各检索一次，检查能否快速定位到目标页面。跨迭代对比则看能否把多轮回顾的同一栏目放在一起查看，例如连续几轮的行动项完成情况。ONES 的 Wiki 页面组织与搜索能力建议用真实记录验证，现有资料未对回顾模板和跨迭代对比作专门说明。
回顾记录需要长期归档或迁移到其他系统，选型时要确认什么？
重点确认导出格式能否保留表格、行动项状态和页面间的关联链接，以及批量导出的范围。建议在试用时实际导出一轮完整回顾记录，检查内容完整性和可读性。ONES 的导出格式与迁移方式在现有资料中未见具体说明，有归档或迁移要求的团队应向厂商确认后再决定。
