Confluence 替换评估容易滑向功能清单逐项打勾，结果评审会上各候选各说各话。更稳妥的做法是先盘点要承接的空间、页面、附件与高频用法，再围绕内容迁移与兼容、权限与空间治理、协作与编辑体验、集成与扩展、部署与合规、成本与切换风险六个维度建立同口径对照表，为每个维度设定可核验的通过标准，最后用代表性空间试点验证。本文给出一套可直接用于候选方案评审会的框架、表格模板与评分规则。
要点总览（TL;DR）
- 先盘点空间、页面、附件、宏与高频用法，把替换对象落到具体内容资产，再设定评估维度。
- 围绕内容迁移与兼容、权限与空间治理、协作与编辑体验、集成与扩展、部署与合规、成本与切换风险六个维度建立同口径对照表，每个维度写明要回答的问题和证据要求。
- 权重按业务影响分配，关键维度设最低通过线或一票否决；未确认项标注为待补证据，不默认视为支持。
- 用代表性空间做迁移试点，验证权限继承、宏与附件、搜索与历史版本等关键项，再结合使用者反馈形成推荐结论与回退条件。
替换评估先定范围：哪些内容与用法必须承接
替换评估的第一步是把评估对象从“Confluence 这个工具”落到具体内容资产和使用场景。范围不清，后续维度就没有判断基准：有人按页面数量估算迁移量，有人按活跃用户数讨论许可，结论无法对齐。建议由知识库管理员牵头，联合各空间负责人完成一次内容资产盘点。
盘点对象应覆盖以下内容：
- 空间清单：空间数量、归属团队、活跃度、是否对外共享；
- 页面与层级：页面总数、目录深度、是否存在大量孤立页面；
- 附件与图片：附件类型、单文件大小分布、总存储量；
- 宏与模板：使用了哪些宏、哪些是自定义或第三方插件宏、模板被复用的频率；
- 评论与批注：评审记录、决策讨论是否沉淀在评论中；
- 历史版本：是否需要保留版本记录，保留多长时间。
在资产盘点基础上识别高频用法。常见的有四类：日常文档协作、知识沉淀与检索、评审与决策记录、对外发布或跨组织共享。每类用法对应不同的评估重点，例如评审记录依赖评论与版本追溯，对外发布依赖权限边界与访问控制。
盘点结果按三类标注承接优先级：必须承接（业务中断即产生实际损失）、可替代（换一种组织方式可接受）、可放弃（长期无人访问的归档内容）。同时明确迁移窗口与业务不可中断的约束，例如财务结账期、版本发布期不宜安排大规模迁移。这份清单是后续所有维度打分的输入，也是试点选样的依据。
六个对比维度：从功能清单转向可验证的评估框架
功能清单的问题在于只回答“有没有”，不回答“在我们的内容规模和使用方式下是否成立”。六个维度各自对应一个必须回答的问题，评审时按问题要证据，而不是按功能打勾。
| 维度 | 要回答的问题 | 典型证据 |
|---|---|---|
| 内容迁移与兼容 | 页面结构、附件、宏与历史版本能迁移到什么程度？迁移后需要多少人工修补？ | 迁移工具说明、试点迁移结果、宏映射清单 |
| 权限与空间治理 | 空间级与页面级权限能否承接现有结构？外部协作如何控制？操作是否可审计？ | 权限模型文档、权限继承演示、审计日志样例 |
| 协作与编辑体验 | 实时协作、评论、模板与结构化写作是否满足主要用法？ | 实际使用者试用反馈、模板配置演示 |
| 集成与扩展 | 与研发工具链、SSO、API 与自动化流程如何衔接？原插件功能如何匹配？ | 集成清单、接口文档、插件替代逐项评估表 |
| 部署与合规 | 私有化或云端如何选择？数据驻留、审计与安全要求能否满足？ | 部署方案说明、合规适配清单 |
| 成本与切换风险 | 许可、迁移人力、培训与并行期成本合计多少？切换期间业务如何兜底？ | 报价口径、人力估算、并行期方案 |
内容迁移与兼容是可行性的前提。评估时要区分“能迁过去”和“迁过去还能用”：页面正文、附件、图片、常用宏与批注属于基础项，历史版本、模板和定制宏往往需要单独确认。以 ONES 的 Confluence 迁移方案为例，其迁移范围包括用户、用户组、空间权限与页面权限，以及页面正文、附件、图片、常用宏和批注，支持批量迁移与数据包导入；宏的覆盖范围为常用宏，特殊或定制宏需要在迁移前逐项评估。这类边界信息正是该维度要收集的证据。
权限与空间治理关注知识资产的可控访问。需要确认空间权限与页面权限能否按原有结构继承，外部协作是否有独立边界，权限变更是否留痕。协作与编辑体验则要落到具体用法：模板能否配置成团队习惯的结构，评论能否承担评审记录，多人同时编辑是否稳定。集成与扩展决定替换后研发流程是否断链，尤其是原来依赖 Confluence 插件的功能，应先梳理实际使用的插件，再逐项做功能匹配，不能假设所有插件都能一一对应。部署与合规按企业实际要求确认私有化、数据驻留与审计能力。成本与切换风险要把迁移人力、培训和并行期运行成本计入，而不只是比较许可费用。
同口径对照表：候选方案按统一标准填写
对照表的作用是让不同候选在同一组问题下作答。每个维度先约定评分口径，例如按“完全满足、部分满足需人工处理、不满足”三档，并规定每档需要什么证据。填写时区分三类信息：已确认事实（有文档或演示支撑）、待验证项（厂商口头答复或尚未测试）、不适用项（本企业无此用法）。
| 维度 | 候选 A 结论 | 证据类型 | 状态 | 成立条件 |
|---|---|---|---|---|
| 内容迁移与兼容 | 页面、附件、常用宏可迁移；定制宏需人工处理 | 迁移说明 + 试点结果 | 已确认 / 部分待验证 | 定制宏数量低于约定阈值 |
| 权限与空间治理 | 空间与页面权限可承接 | 权限演示 | 待验证 | 试点空间权限继承无误 |
| 协作与编辑体验 | 满足文档协作与评审记录 | 使用者试用反馈 | 待验证 | 试点团队覆盖主要用法 |
| 集成与扩展 | SSO 与研发工具链可衔接 | 集成清单 | 已确认 / 部分待验证 | 插件替代逐项评估完成 |
| 部署与合规 | 支持私有化部署 | 部署方案说明 | 已确认 | 合规适配清单经确认 |
| 成本与切换风险 | 许可与迁移人力可估算 | 报价口径 + 人力估算 | 待补证据 | 并行期方案确定 |
表格必须保留“成立条件”列。同一结论在不同条件下可能反转，例如“支持私有化部署”在特定合规清单下才成立，条件不写清楚，评审会后无法复核。候选方案的部署形态与适用范围也应单独标注，避免把云端版本的结论套用到私有化场景。
选择标准与权重：把评审共识写成可打分的规则
维度确定后，评审会需要一套可打分的规则，否则讨论仍会回到印象和偏好。权重按业务影响分配，不平均分配。判断方法很直接：如果某维度不达标，业务是否真的无法运转？如果是，它就该获得更高权重或设为通过线。
建议的规则结构如下：
- 权重分配：内容迁移与兼容、权限与空间治理通常权重最高，因为它们决定历史资产能否承接、访问是否可控；集成与扩展次之，取决于研发流程对工具链的依赖程度；协作体验、部署合规、成本风险按企业实际情况调整。
- 最低通过线：为关键维度设定最低档位，例如内容迁移与兼容不得低于“部分满足且人工处理量可控”，权限治理不得低于“空间与页面权限可承接”。未达通过线的候选不进入综合排序。
- 一票否决项：涉及数据安全与合规的硬性要求可作为否决项，例如无法满足数据驻留要求。
- 证据来源：每项打分注明证据来自文档、演示、试点结果还是厂商答复，厂商答复单独标记，不与已验证事实混算。
- 未确认项处置：未确认项显式标注为待补证据，不计入满足项，也不默认视为支持；评审结论中列出补证责任人与期限。
评分规则应在候选方案演示之前定稿，避免看到演示后再调整标准。规则本身也需要评审会确认，形成书面记录，后续复核时以同一套规则为准。
试点验证与评审结论：用证据替代功能清单
试点是把待验证项转为已确认事实的环节。选取一到两个代表性空间，覆盖不同用法：一个高频协作空间，一个含较多附件与宏的知识空间。迁移试点按以下步骤推进：
- 导出并迁移试点空间，记录迁移耗时与人工修补工作量；
- 核对页面层级、附件、图片与常用宏的还原情况，逐项登记差异；
- 验证权限继承：空间权限与页面权限是否与原有结构一致，外部访问边界是否有效；
- 验证搜索与历史版本：迁移后内容能否被检索到，版本记录是否符合保留要求；
- 组织实际使用者试用，收集协作、评论与模板使用的反馈；
- 对原插件依赖功能做逐项匹配验证，记录可替代、需调整与无法匹配三类结果。
试点结束后形成评审结论，包含三部分：推荐候选及理由、待补证据项及补证方式、回退条件。回退条件要具体，例如“若定制宏人工处理量超过约定阈值，则暂停全量迁移并重新评估”。在内容协作与研发流程衔接的场景中，ONES 可作为候选之一纳入同一套对照表评估：其 Confluence 迁移方案覆盖空间、页面、附件与权限结构，支持批量迁移与数据包导入，并把数据完整、业务连续和系统稳定作为迁移目标，同时支持国产化、私有化与安全合规相关要求；历史版本、模板迁移覆盖、实时协作与审计细节等仍需在试点中核验。无论最终选择哪个方案，结论都应建立在同一套维度、同一套证据标准之上，使评审结果可复核、可追溯。
常见问题
替换评估时，如何判断哪些 Confluence 内容必须承接？
按业务影响分三类标注：必须承接（业务中断即产生实际损失）、可替代（换一种组织方式可接受）、可放弃（长期无人访问的归档内容）。盘点时覆盖空间、页面层级、附件、宏与模板、评论与历史版本，并识别高频用法，例如日常文档协作、知识沉淀与检索、评审与决策记录、对外发布。承接优先级清单同时作为试点选样的依据。
六个对比维度中，哪个维度应该设为一票否决项？
一票否决项通常来自数据安全与合规的硬性要求，例如无法满足数据驻留要求。内容迁移与兼容、权限与空间治理更适合设最低通过线，例如迁移后人工处理量超出可控范围、或空间与页面权限无法承接，则候选不进入综合排序。具体否决项和通过线应在候选演示前由评审会确认，并形成书面记录。
候选方案对某些维度答复“支持”，但拿不出文档或演示，该怎么处理？
将这类答复标记为待验证项，不计入满足项，也不默认视为支持。在对照表中单独记录证据类型为“厂商答复”，并在评审结论中列出补证责任人与期限。试点阶段优先验证这些待验证项，把口头答复转为文档、演示或试点结果后再参与打分。
试点空间应该选几个、选什么样的空间？
建议选一到两个代表性空间，覆盖不同用法：一个高频协作空间，一个含较多附件与宏的知识空间。试点要记录迁移耗时与人工修补工作量，核对页面层级、附件、图片与常用宏的还原情况，验证权限继承、搜索与历史版本，并组织实际使用者试用。试点结果用于把待验证项转为已确认事实，而不是替代全量迁移评估。
评审结论中除了推荐候选，还需要写什么？
结论应包含三部分：推荐候选及理由、待补证据项及补证方式、回退条件。回退条件要具体可执行，例如“若定制宏人工处理量超过约定阈值，则暂停全量迁移并重新评估”。同时保留同口径对照表和评分规则作为附件，便于后续复核时使用同一套标准。
