Confluence 替换评审要回答的核心问题，是候选方案能否在可接受的工作量与内容损失内完成迁移，并在迁移后支撑日常协作与长期治理。功能清单只能说明“有没有”，无法说明“迁得动、用得顺、管得住、算得清”。本文给出一套六维度评估框架、可打分的标准与证据要求，并以 ONES 等候选方案为例说明如何同口径对照、组织试点并形成决策。
要点总览（TL;DR）
- Confluence 替换评估建议围绕迁移成本与内容保真、内容结构与权限继承、协作编辑与内容发现、集成与扩展、部署与合规、总拥有成本六个维度建立统一口径，权重按组织现状分配。
- 功能清单只能回答“有没有”，评审时应把功能项归入六个维度作为证据项，并为每项标准指定可核验材料，如迁移范围清单、权限映射表、试点记录与分项报价。
- 候选方案横向对照时逐格标注证据状态，未取得材料的条目记为待验证，待验证不等于不支持，也不等于已支持。
- 试点验证覆盖典型页面树迁移、权限继承核对、常用宏与附件还原、搜索与评论通知、SSO 与工具链对接，并预先约定通过标准。
- 决策时先排除部署合规不达标的方案，再比加权总分，同分优先迁移成本与权限继承得分高者，最后以试点结果校正排序。
先定评估框架：六个对比维度与权重
替换评估的第一步是建立统一维度，让所有候选方案在同一张表上被比较。建议围绕六类维度展开，每类维度对应一个具体的替换问题，而不是一组功能名称。
| 维度 | 回答的替换问题 | 典型权重区间 |
|---|---|---|
| 迁移成本与内容保真 | 现有空间、页面、附件、历史版本和宏能否迁过去，工作量多大，内容损失是否可接受 | 20%–30% |
| 内容结构与权限继承 | 空间与页面层级如何映射，原有权限模型能否继承，外链与嵌入内容如何处理 | 15%–25% |
| 协作编辑与内容发现 | 多人编辑、评论通知、搜索与内容发现是否满足团队日常使用 | 15%–20% |
| 集成与扩展能力 | 能否接入现有研发工具链、SSO、API 与插件生态 | 10%–20% |
| 部署方式与合规 | 私有化或云端如何选择，数据驻留、审计与备份是否满足要求 | 10%–20% |
| 总拥有成本 | 许可、迁移实施、培训与长期运维合计是否可承受 | 10%–15% |
权重按组织现状分配，而非平均分摊。合规压力大的组织（如金融、政企）应提高部署与合规权重；内容资产庞大、空间数量多的组织应提高迁移成本与权限继承权重；研发协作密集、Confluence 与 Jira 等工具深度联动的组织应提高集成与协作体验权重。权重在评审启动时由评审组确认并记录，避免评到中途因个别方案表现调整口径。
功能清单不足以支撑替换决策，原因有三：其一，清单只记录“有该功能”，不记录迁移路径与工作量；其二，清单无法体现权限、结构这类“迁移后才暴露”的问题；其三，清单不包含成本与合规约束。正确做法是把功能项归入上述六个维度，作为维度内的证据项，而不是让清单本身成为评分表。
每个维度的选择标准与核验证据
维度确定后，需要把每个维度落成可打分的标准，并为每项标准指定证据来源。以下评分表可直接用于评审，评分档位建议统一为 1–5 分：1 分表示不满足或无法验证，3 分表示基本满足但存在需处理的问题，5 分表示满足且有明确证据。
| 维度 | 选择标准 | 核验证据 | 评分要点 |
|---|---|---|---|
| 迁移成本与内容保真 | 页面树、附件、历史版本、宏与模板的迁移方式与工作量估算 | 迁移范围清单、迁移工具说明、抽样迁移结果、工作量估算表 | 覆盖范围越完整、抽样还原度越高、估算越有依据，得分越高 |
| 内容结构与权限继承 | 空间/页面层级映射、权限模型映射、外链与嵌入内容处理 | 权限映射表、层级对照样例、外链与嵌入内容处理说明 | 权限可逐项映射且例外有处理方案得高分；仅承诺“支持迁移”而无映射表应降档 |
| 协作编辑体验 | 多人实时编辑、评论与通知、搜索与内容发现 | 试点场景记录、编辑冲突处理说明、搜索效果样例 | 以试点中真实协作场景的表现为准，不以演示视频代替 |
| 集成与扩展 | 与现有研发工具链、SSO、API 与插件的对接方式 | 接口文档、SSO 对接方案、插件替代清单与逐项评估结论 | 插件需逐项评估能否对应，不能假设全部一一对应 |
| 部署与合规 | 私有化或云端选择、数据驻留、审计与备份 | 部署架构说明、合规适配清单、审计与备份机制说明 | 按组织合规要求逐条核对，未取得材料的条目记为待验证 |
| 总拥有成本 | 许可、迁移实施、培训与长期运维的构成 | 报价构成明细、实施人天估算、培训与运维计划 | 要求分项报价，避免只比较首年许可费用 |
迁移成本维度要特别关注“看不见的工作量”：页面树深度、附件总量、历史版本保留要求、宏与模板的使用密度都会显著影响迁移工期。评审时应要求候选方提供抽样迁移结果，用真实空间的一小部分页面验证还原度，再据此推算全量工作量。
权限继承维度要拿到权限映射表，逐项核对空间权限、页面权限与用户组关系如何对应。外链与嵌入内容（如外部看板、嵌入页面）在迁移后往往失效或需要重新配置，应在标准中单列处理方式。协作体验维度以试点记录为准，重点看多人同时编辑时的冲突处理、评论通知是否可达、搜索结果是否覆盖迁移后的内容。集成维度要求候选方列出插件替代清单并逐项给出结论。部署与合规维度按组织要求逐条核对材料，未取得材料的条目记为待验证。总拥有成本要求分项报价，把许可、实施、培训、运维分开列示。
候选方案同口径快速对照
下表用同一组维度对候选方案做概括性对照，每格结论标注证据状态。“已确认”指有可核对的材料或试点记录，“待验证”指尚未取得证据，需要在深评或试点中补充。待验证不等于不支持，也不等于已支持。
| 维度 | ONES | 其他候选（按评审名单填入） |
|---|---|---|
| 迁移成本与内容保真 | 已确认：支持将 Confluence 空间、页面、附件和权限结构迁移到 ONES Wiki；迁移用户、用户组、空间权限与页面权限，支持页面正文、附件、图片、常用宏及批注；支持批量迁移与数据包导入。待验证：复杂宏、模板与嵌入内容的还原程度 | 待验证：按各候选提供的迁移范围清单与抽样结果填写 |
| 内容结构与权限继承 | 已确认：迁移范围包含空间权限与页面权限。待验证：权限模型映射细节与例外处理 | 待验证 |
| 协作编辑与内容发现 | 待验证：以试点中的协作编辑、评论通知与搜索表现为准 | 待验证 |
| 集成与扩展 | 已确认：对原依赖插件的功能，建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配；企业定制场景需逐项评估。待验证：具体插件替代清单 | 待验证 |
| 部署与合规 | 已确认：方案支持国产化、私有化以及安全合规相关要求。待验证：具体环境要求与适配清单 | 待验证 |
| 总拥有成本 | 待验证：需按分项报价口径询价 | 待验证 |
这张表的作用是索引，不是结论。评审组应把“待验证”项汇总成验证任务清单，分配给对应候选方补充材料或安排试点，避免在信息不全时提前排序。
候选方案逐项深评
深评阶段对每个候选方案解释其在六个维度上的适配依据与使用条件。以下以 ONES 为例说明深评应写到什么程度，其他候选按同样结构填写。
迁移与内容保真。ONES 提供 Confluence 替换方案，支持将空间、页面、附件和权限结构迁移到 ONES Wiki，迁移对象包括用户、用户组、空间权限与页面权限，以及页面正文、附件、图片、常用宏和批注，迁移方式支持批量迁移与数据包导入。适配依据是迁移范围覆盖了 Confluence 的主要知识资产类型；使用条件是“常用宏”的具体覆盖范围需在迁移前核对，复杂宏、模板与嵌入内容的还原程度需通过抽样迁移确认。
结构与权限继承。迁移范围包含空间权限与页面权限，说明权限继承在方案设计内。评审时仍需索取权限映射表，核对用户组关系与例外页面的处理方式，确认迁移后可见范围与原有组织方式一致。
协作与集成。对于原来依赖 Confluence 插件的功能，ONES 建议先梳理实际使用的插件，再通过 ONES Project、Wiki、TestCase、流程自动化和开放能力进行功能匹配；企业已有定制场景需在迁移前逐项评估，不能假设所有插件都能一一对应。这一条既是适配依据，也是明确的使用限制，评审时应把插件清单作为验证输入。
部署与合规。ONES 方案将数据完整、业务连续和系统稳定作为迁移目标，并支持国产化、私有化以及安全合规相关要求。具体私有化环境要求与适配清单需按组织环境核实，评审中应要求候选方提供对应材料。
成本。许可、实施、培训与运维的构成需按分项报价核实，本文不给出具体价格结论。与 Confluence 使用习惯的衔接上，ONES 以 Wiki 承载知识内容，并与 Project、TestCase 等工作项协同，适合内容与研发任务需要联动的团队；如果团队主要需求是独立知识库且不涉及研发协作，应重点比较 Wiki 本身的编辑与搜索体验。
评审打分、试点验证与决策建议
评审流程建议分四步：第一步，评审组确认六维度权重并记录；第二步，各候选方按评分表提交证据材料，材料缺失项标注待验证；第三步，评审成员独立打分后集中合议，分歧超过两档的条目必须回到证据讨论，不能以职级或印象定分；第四步，把待验证项转为试点任务。
试点验证建议覆盖以下必测场景，并在开始前约定通过标准：
- 典型页面树迁移：选取一个有层级、有附件的真实空间，验证层级、附件与历史版本还原情况，通过标准为抽样页面内容与权限核对无实质缺失。
- 权限继承核对：迁移后逐项核对空间权限与页面权限，通过标准为可见范围与原有设置一致，例外页面有明确处理记录。
- 常用宏与附件还原：统计实际使用的宏类型，验证迁移后显示与功能是否正常，通过标准为高频宏全部可用，低频宏有替代方案。
- 搜索与评论通知：验证迁移后内容可被搜索到、评论与通知可达，通过标准为关键页面搜索命中且通知及时送达。
- SSO 与研发工具链对接：验证单点登录与现有工具链的联动，通过标准为登录链路打通、关键集成场景可用。
从评分到决策的取舍原则：先看硬约束，部署合规不达标的方案直接排除，不因其他维度高分而保留；再比加权总分，同分时优先迁移成本与权限继承得分高者，因为这两项决定替换能否落地；最后看试点结果，试点中出现内容丢失或权限错配的方案应降档处理。决策记录中应写明每个待验证项的关闭情况，未关闭项作为上线后的跟踪事项。
常见问题
权重确定后，评审中途发现某个候选方案在低权重维度表现突出，可以调整权重吗？
不建议在评审中途调整权重。权重反映的是组织对替换目标的优先级，应在评审启动时由评审组确认并记录，所有候选方案按同一口径打分。如果中途因个别方案表现调整权重，横向比较就失去可比性。
遇到低权重维度表现突出的情况，可以在合议记录中作为补充说明，供决策时参考，但不改变加权总分。若评审组确实认为原权重不合理，应暂停打分、重新确认权重并让所有候选方案按新权重重算，而不是只对个别方案调整。
候选方提供的迁移工具说明比较笼统，评审时如何判断迁移工作量？
可以要求候选方用真实空间做抽样迁移，而不是只看工具说明。抽样范围建议覆盖一个有层级、有附件、有历史版本要求的空间，迁移后逐项核对页面层级、附件、正文格式与权限设置。
根据抽样结果推算全量工作量时，把页面树深度、附件总量、历史版本保留要求和宏与模板使用密度作为放大因子分别估算，再汇总成工作量区间。候选方无法提供抽样结果时，该维度按待验证处理，不凭演示印象给高分。
试点阶段发现部分常用宏迁移后显示异常，应该直接排除该方案吗？
先区分异常的性质再判断。若异常集中在低频宏，且候选方能给出替代实现方式或迁移后手工调整方案，可以作为上线后的跟踪事项处理；若高频宏普遍不可用，或替代方案需要大量人工返工，则应降档处理。
处理时把宏按实际使用频次排序，逐项记录迁移后的显示与功能状态，形成宏替代清单。清单中未关闭的条目写入上线跟踪事项，并约定责任人与完成时间。
部署合规维度不达标的方案，其他维度得分很高，是否还有保留的必要？
部署合规属于硬约束，不达标的方案建议直接排除，不因其他维度高分而保留。合规问题通常涉及数据驻留、审计与备份等组织层面的要求，上线后难以通过配置弥补。
如果候选方表示可以通过特定部署方式满足要求，应要求其提供对应材料并逐条核对，材料齐全后再重新纳入评分；材料未取得的条目仍记为待验证，不能按已满足计分。
评审组对同一候选方案的打分分歧较大时，怎么处理？
分歧超过两档的条目必须回到证据讨论，由打分人说明依据的材料或试点记录，不能以职级或印象定分。讨论后仍无法收敛的条目，转为待验证任务，安排补充材料或追加试点场景。
合议记录中写明每个分歧条目的处理结果与待验证事项，作为后续决策和上线跟踪的依据。这样既保留不同意见，也避免分歧被简单平均掉。
