Confluence 替代选型要检查哪些能力，取决于现有页面体系、权限边界和日常写作人群的真实需求。建议围绕内容结构、权限合规、编辑协作、搜索发现、集成开放、迁移退出六类能力建立检查表，用真实页面样本和试用任务逐项验证，再进入评分与试点，避免只比较功能数量。
要点总览（TL;DR）
- Confluence 替代选型应围绕六类能力建立检查表：内容结构与空间体系、权限与合规、编辑协作体验、搜索与知识发现、集成与开放能力、迁移与退出成本。
- 内容结构要用真实空间做映射：抽取深层研发空间、模板最多的业务空间和历史归档空间，在候选工具中试建，记录无法对应的对象和人工调整量。
- 权限核验以敏感内容样本走完授权、访问、回收闭环，并确认审计日志留痕；合规材料与法务或安全团队共同确认。
- 编辑协作与搜索用真实任务试用：多人同时编辑、评论评审、关键词检索和移动端访问，由真实写作人群参与并记录卡点。
- 把检查结果转成加权评分，选一个真实团队和代表性空间做试点，试点前定好通过标准，结论形成决策记录。
替代选型先看哪六类能力
Confluence 替换选型的第一项工作，是把“好不好用”拆成可以逐项核对的能力类别。六类能力分别对应六个问题：现有内容能否接得住、敏感内容能否管得住、主要写作人群是否愿意用、沉淀的知识能否被找到、系统能否接入现有链路、未来调整是否付得起成本。每一类都应有明确的检查目标和验证动作，而不是停留在功能清单打勾。
| 能力类别 | 检查目标 | 典型验证动作 |
|---|---|---|
| 内容结构与空间体系 | 页面层级、模板、附件和归档方式能否承接现有体系 | 抽取真实空间做结构映射，试建页面树与模板 |
| 权限与合规 | 空间、页面、附件级权限能否按组织边界开放 | 用敏感内容样本配置权限，核对访客与审计能力 |
| 编辑与协作体验 | 主要写作人群的日常写作、评论、通知是否顺畅 | 组织多人同时编辑与评审任务，记录卡点 |
| 搜索与知识发现 | 历史内容能否被搜到、筛出且不越权 | 用真实关键词测试相关性、筛选与结果权限 |
| 集成与开放能力 | 能否接入研发工具、办公套件与统一身份 | 核对 SSO、API、Webhook 与常用工具连接 |
| 迁移与退出成本 | 搬迁工作量与未来再次调整的灵活度是否可控 | 试迁样本页面，核对导出范围与格式 |
六类能力的优先级随组织情况变化。研发文档占比高、插件依赖多的团队，应把内容结构和集成能力前置；对外协作多、内容敏感度高的组织，权限与合规应作为一票否决项；写作人群分散、历史内容量大的团队，搜索与编辑体验的权重应提高。先确定权重，再安排试用顺序，能避免试用阶段被演示效果带偏。
内容结构与空间体系怎么核对
判断替代工具能否承接现有 Confluence 页面体系，核心方法是做结构映射：把现有空间、页面树、模板、附件和归档方式逐项对应到候选工具的结构对象上，看哪些能直接对应、哪些需要调整、哪些会丢失。只听取产品介绍无法回答这个问题，必须用真实页面样本动手试建。
结构映射可按以下清单逐项核对：
- 空间与页面树：现有空间数量、层级深度、跨空间引用关系，在候选工具中如何组织；深层页面树是否仍然便于导航。
- 模板：常用模板的数量与复杂度，候选工具能否复建同类模板，模板中的占位内容和固定结构是否保留。
- 附件与图片：附件类型、单文件大小、页面内嵌图片的引用方式，迁移后链接是否仍然有效。
- 宏与嵌入内容：统计实际使用的宏类型和频次，逐项确认候选工具的对应方式；依赖插件的宏需要单独评估。
- 归档与清理：历史空间是否有归档规则、过期内容如何处理，候选工具是否支持归档状态与批量整理。
操作上，建议从现有 Confluence 中抽取两到三个代表性空间：一个结构最深的研发空间、一个模板最多的业务空间、一个历史内容最多的归档空间。在候选工具中按原结构试建，记录无法对应的对象和需要人工调整的页面数量，再据此估算整体迁移工作量。归档内容应单独统计，明确哪些需要迁移、哪些只需导出留存，避免把清理工作带入迁移项目。
在 Confluence 替换场景中，ONES Wiki 可承接空间、页面、附件和权限结构的迁移，帮助团队保留原有知识组织方式。实际迁移前，仍需用上述样本核对页面树深度、模板复建和宏的对应范围，把差异项列入迁移清单。
权限、合规与数据边界怎么验证
权限核验要回答的是：敏感内容能否只对应该看到的人开放，外部协作能否被控制，数据存放和操作记录能否满足合规要求。验证时应使用真实的敏感内容样本，而不是用演示账号走一遍流程。
| 核验项 | 检查内容 | 验证方式 |
|---|---|---|
| 权限粒度 | 空间级、页面级、附件级权限是否可分别设置，继承与覆盖规则是否清晰 | 用含敏感附件的页面配置不同层级权限，检查实际可见范围 |
| 用户与用户组 | 能否按部门、项目组批量授权，人员变动时权限如何回收 | 模拟人员调岗与离职，观察权限变化 |
| 外部协作与访客 | 访客访问的范围、有效期与审批方式是否可控 | 创建访客账号，测试其可见页面与操作边界 |
| 数据存放 | 部署方式与数据存放位置是否符合组织要求 | 核对部署选项与数据存放说明，确认适用条件 |
| 审计日志 | 登录、权限变更、内容操作是否留痕，日志能否导出 | 执行若干敏感操作后检查日志记录完整性 |
| 合规材料 | 可提供的合规说明与认证材料范围 | 向供应商索取材料清单，按组织要求逐项确认 |
权限核验的完成标志是：用一份包含敏感信息的真实页面，在候选工具中完成授权、访问、回收的完整闭环，并确认日志中有对应记录。合规材料的确认应与法务或安全团队共同进行，把结论写入评估记录，避免在选型后期才发现边界不符。
ONES 方案把数据完整、业务连续和系统稳定作为迁移目标，并支持国产化、私有化以及安全合规相关要求；具体适配范围需按项目确认。对于权限日常配置的细节，应在试用中按上表逐项验证。
编辑协作与搜索体验怎么试
编辑协作与搜索体验直接影响主要写作人群的日常成本和知识被发现的程度，适合用任务脚本试用，而不是看演示。试用应覆盖三类任务：多人协作写作、内容评审流转、历史内容检索。
多人协作任务可这样设计：选一篇需要三人共同完成的真实文档，安排同时编辑不同章节，中间插入评论和修改意见，观察光标位置、内容冲突提示、评论回复和通知到达情况。记录每位参与者的操作卡点，以及通知是否准确送达相关人。
搜索验证应使用真实关键词，覆盖三类场景：精确标题检索、正文关键词检索、按空间或标签筛选。重点观察结果相关性排序是否合理，筛选条件是否够用，以及搜索结果是否遵守权限设置——用低权限账号搜索敏感内容，确认不会出现越权结果。
移动端与外部访问的检查点包括：移动端编辑和查看是否可用、评论通知是否及时、外部网络环境下的访问稳定性。试用结束后，把观察结果填入记录表：
| 任务 | 观察项 | 记录内容 | 是否通过 |
|---|---|---|---|
| 三人同时编辑 | 冲突提示、保存、通知 | 卡点描述与发生次数 | |
| 评论与评审 | 评论定位、回复、状态流转 | 意见是否被准确跟踪 | |
| 关键词搜索 | 相关性、筛选、权限 | 前十条结果的相关程度 | |
| 移动端访问 | 查看、编辑、通知 | 可用功能与限制 |
试用应安排真实写作人群参与，而不是只由 IT 团队操作。完成标志是每类任务都有明确结论和记录，能支撑后续评分。
集成、迁移与退出成本怎么算
集成与迁移决定替换的总投入，退出成本决定未来再次调整的灵活度，三者应放在同一张评估表中核算。集成核对项包括：与研发工具（如需求、缺陷、测试管理）的关联方式，与办公套件的账号和通知打通，统一身份认证（SSO）的接入方式，以及 API、Webhook 等开放能力是否满足现有自动化脚本。
迁移范围要逐项列清：页面正文、附件、图片、评论、权限结构、用户与用户组。每一项都应有对应的验证方式——试迁一批样本页面后，抽查正文格式、附件链接、评论归属和权限是否与源端一致。常用宏和插件依赖需要单独梳理，逐项确认对应方案；企业已有的定制场景应在迁移前评估，避免假设所有插件都能一一对应。
| 评估项 | 核对内容 | 成本口径 |
|---|---|---|
| 研发与办公集成 | 工具连接方式、SSO、通知打通 | 接入工作量与后续维护 |
| 开放能力 | API、Webhook 覆盖范围 | 现有自动化脚本的改造量 |
| 迁移范围 | 页面、附件、权限、评论、宏 | 人工调整页面数量与试迁轮次 |
| 数据导出 | 导出格式、范围与完整性 | 未来再次迁移的可行性与工作量 |
退出成本的评估方法是：确认候选工具能否将页面、附件和权限结构完整导出为通用格式，导出后内容是否仍可读、可再导入。导出能力越完整，未来调整的灵活度越高。ONES Wiki 的 Confluence 迁移支持批量迁移与数据包导入，迁移内容包括用户、用户组、空间权限与页面权限，以及页面正文、附件、图片、常用宏和批注；具体迁移范围与操作限制需以迁移服务说明为准，并在试迁中逐项核对。
用评分表做候选筛选与试点验证
能力检查完成后，需要把结果转成可比较的评分，再用小范围试点验证结论。评分表按六类能力设置权重，权重由组织情况决定：合规要求高的组织提高权限项权重，研发文档密集的团队提高结构与集成项权重。每项按统一口径打分，例如 1 至 5 分，并附上试用中的具体证据，避免只凭印象打分。
| 能力类别 | 权重 | 评分依据 | 候选 A | 候选 B |
|---|---|---|---|---|
| 内容结构与空间体系 | 结构映射差异项数量 | |||
| 权限与合规 | 权限闭环与合规材料确认结果 | |||
| 编辑与协作体验 | 试用任务卡点记录 | |||
| 搜索与知识发现 | 检索任务通过率 | |||
| 集成与开放能力 | 集成核对项完成情况 | |||
| 迁移与退出成本 | 试迁调整量与导出完整性 |
试点范围建议选一个真实团队和一个代表性空间，周期以覆盖完整写作、评审、检索和权限场景为准。通过标准在试点前确定，例如：结构映射无阻断性差异、权限闭环验证通过、主要写作人群试用任务完成且卡点可接受、样本迁移后内容与权限一致。试点结束后输出结论：推荐候选、保留意见、待确认事项和迁移准备清单，并记录决策依据，便于后续复盘。
评分与试点结论应形成一份决策记录，写明权重设置理由、各候选得分、试点观察和最终选择。这样即使后续组织需求变化，也能清楚知道当时的判断依据，为下一次调整保留参照。
常见问题
现有 Confluence 页面数量很多，结构映射要抽多少样本才够？
样本量以覆盖结构差异为目标，不必按比例抽取。建议至少选三类空间：层级最深的研发空间、模板和宏使用最密集的业务空间、历史内容最多的归档空间。每类空间抽取若干代表性页面，重点记录无法直接对应的对象，例如特定宏、复杂模板或深层页面树。样本试建后，用差异项数量估算整体迁移的人工调整量，再决定是否需要扩大样本。
权限核验做到什么程度可以进入下一阶段？
完成标志是用一份包含敏感信息的真实页面，在候选工具中走完授权、访问、回收的完整闭环，并确认审计日志中有对应记录。同时要模拟人员调岗或离职，观察权限是否按预期变化；创建访客账号，确认其可见范围和操作边界。合规材料的确认应与法务或安全团队共同进行，把结论写入评估记录，避免在选型后期才发现边界不符。
试用阶段由 IT 团队操作和由真实写作人群操作，结论会有什么差别？
IT 团队更熟悉配置和权限设置，但日常写作中的卡点往往只有主要写作人群才能发现，例如模板填写是否顺手、评论通知是否及时、搜索结果是否符合预期。建议 IT 团队负责环境准备和权限场景搭建，写作、评审、检索任务交给真实使用者完成，观察记录由双方共同填写。这样得到的结论才能支撑后续评分，而不是停留在功能可用层面。
迁移时哪些内容容易在评估中被低估？
常见低估项包括：常用宏和插件依赖、页面内嵌图片与附件的链接有效性、评论归属、权限继承关系。宏需要按实际使用类型和频次逐项梳理，确认候选工具的对应方式；附件和图片要在试迁后抽查链接是否仍然有效；评论要确认迁移后归属正确；权限要核对空间级与页面级设置是否与源端一致。把这些列入迁移清单并安排试迁轮次，比在正式迁移时才发现问题更可控。
评分权重应该由谁定，定完还能调整吗？
权重应由负责替换决策的团队共同确定，参与方通常包括 IT、安全合规和主要写作人群的代表。权重依据组织情况设定：合规要求高的组织提高权限项权重，研发文档密集的团队提高结构与集成项权重。权重在试用前确定并记录理由，试用过程中如发现某类能力存在阻断性问题，可以调整权重或将其设为一票否决项，但调整应写入决策记录，保持评分口径可追溯。
