2026年 Confluence 替代方案选型指南：6款国产方案深度对比

《2026年 Confluence 替代方案选型指南：6款国产方案深度对比》真正要回答的，不是“哪款最像 Confluence”，而是“你们现在依赖 Confluence 完成的哪些工作，必须在新系统里继续成立”。如果只按功能清单选，最容易漏掉的往往不是编辑器，而是旧链接、空间权限、搜索习惯、历史版本和跨工具流程。本文把语雀企业版、飞书知识库、腾讯乐享、Baklib、PingCode Wiki、石墨文档企业版作为六个候选方向，按使用场景、替代边界、迁移风险和验证方法拆解；

涉及套餐、部署和功能的项目，均应以签约前的官方资料及实际试用结果为准。

一、先给结论：不要找“万能平替”，先找工作流的最小替代集合

1. 六款候选并非六个同类产品

我会先把候选产品分成三类，而不是先排总名次。第一类是以知识内容沉淀为核心，重点检查知识空间、页面组织、搜索和权限治理；第二类是以办公协作为核心，知识库与即时沟通、日历、文档等能力相互连接；第三类是以研发或项目交付为核心，重点考察文档是否能和需求、任务、测试、发布等工作对象形成关联。

语雀企业版、Baklib更适合从知识内容的组织方式和发布管理角度评估；飞书知识库、腾讯乐享、石墨文档企业版，更需要结合组织已经使用的办公协作环境判断；PingCode Wiki则应放在研发知识与项目协作场景中验证。这个分类是选型起点，不代表产品只适用于某一类任务，也不代表它们之间可以直接互换。

我的核心判断是：替代范围越大，切换成本通常越高。如果团队真正依赖的只是内部知识页面，选择一个好维护、搜索顺手的知识库，可能比替换整套协作生态更稳妥；如果文档和项目任务、研发流程、即时沟通高度绑定，单换知识库则可能只是把工作流拆散，后续还要补集成、权限和维护机制。

2. 选型顺序应该是“场景，约束，试点，报价”

不建议先列出六款产品打分，再从分数最高的一款倒推需求。更可靠的顺序是：盘点现有内容和工作流，写出不能丢失的约束，再用同一组真实任务做试点，最后把订阅、迁移、实施、培训和运维放入总成本计算。

例如，制度文件主要由行政或人力团队维护，核心问题可能是版本正确、访问边界清晰、搜索可用；研发团队沉淀设计决策和故障复盘，可能更在意文档与需求、缺陷、项目的上下文关联；面向客户或合作伙伴发布帮助内容，则更应关注内容发布、访问体验和更新治理。三个场景都叫“知识管理”，但选型权重并不一样。

下面的权重是我建议企业用于第一轮筛选的示意基准，不是行业统计，也不是六款产品的实测得分。它的价值是把“感觉好不好用”拆成可讨论的条件，团队可以根据自身约束调整。

3. 先设“不能妥协项”，再谈综合评分

综合评分适合比较可取舍的差异，不适合覆盖硬约束。企业如果明确要求指定部署形态、特定身份认证方式、审计留痕或数据处理条款，就应先确认候选是否满足条件。一个关键约束不满足，不能因为编辑器体验得分高就用总分把问题平均掉。

我通常把要求分成三层：硬性门槛、重要能力、体验偏好。硬性门槛用于淘汰；重要能力用于排序；体验偏好用于最后试用。这样能避免评审会上某个演示效果很好的功能，盖过真正影响上线的安全、迁移或管理问题。

二、先还原现状：你到底要替代 Confluence 的哪一部分

1. 把“页面”拆成内容、关系和规则

迁移前不能只统计页面数量。一个看似简单的空间，往往同时包含页面正文、附件、目录层级、页面链接、历史版本、标签、评论、人员和访问规则。只导出正文，内容也许还在，但文档之间的关系、谁能看、哪些页面已经过时，可能已经无法还原。

我建议把现有内容抽成四张清单：内容清单、使用者清单、权限清单、关联清单。内容清单记录空间、页面、附件、更新时间和负责人；使用者清单区分活跃维护者与只读用户；权限清单列出部门、项目组、外部人员及特殊例外；关联清单记录文档与任务、代码、工单或外部系统之间的链接。

这一步能发现一个常见情况：表面上企业有几千篇页面，真正持续访问的可能集中在少数空间；另外一些页面已经无人维护，却仍然被搜索结果或旧链接引用。若不先区分活跃内容与历史存档，迁移团队容易花大量时间搬运低价值内容，同时忽略仍在使用的关键页面。

2. 用“文档任务”而不是产品名描述需求

“我们要找 Confluence 平替”只是采购口号，不是验收条件。把它改写成用户能完成的任务，产品差异才会显现。比如：新员工能否在五分钟内找到某项制度；项目成员能否从任务上下文打开设计文档；管理员能否快速确认某个空间的外部访问范围；内容负责人能否识别长期未更新的关键页面。

至少选出五类代表性任务：新建并发布一页内容、多人协作修改、搜索历史决策、管理跨团队权限、从旧链接进入新页面。对研发团队，还应加入“从需求或缺陷找到对应知识记录”的任务；对面向客户的内容团队，则应加入“内容更新后发布与回滚”的任务。

任务必须来自真实工作，不要为了让候选产品好看而设计成产品演示路线。试点时记录完成时间、失败次数、人工求助次数和结果正确性。即使只有十位用户参与，这些观察也比“大家觉得界面挺清楚”更容易用于决策。

3. 把内容规模与治理难度分开估算

页面总数不等于迁移难度。两千篇结构统一、权限简单的内容，可能比两百篇跨多个项目、链接复杂、含有敏感附件的内容更容易迁移。建议先抽样，而不是一开始就全量搬迁：按高频页面、权限复杂页面、附件密集页面、历史页面分别抽取样本，观察导入质量和人工修复工作量。

可以把每类样本记录为“导入前状态，导入后状态，人工修复项”。例如检查标题、正文格式、图片附件、内部链接、页面层级、阅读权限和搜索结果。迁移报告不能只写“导入成功”，而要说明哪些内容自动保留、哪些内容需要重建、哪些内容不建议迁移。

三、六款方案逐一看：能替代什么，边界在哪里

1. 语雀企业版：重点验证知识整理习惯和团队治理

语雀企业版可以列入以文档沉淀、知识整理和团队协作为重点的候选。评估时，我会把注意力放在知识空间的组织方式、页面编辑与阅读体验、搜索、团队管理和企业级权限上，而不是只看个人写作界面是否顺手。

更适合优先试用的场景，是团队已经有明确的知识分类和内容负责人，希望把分散文档收拢到统一的知识空间。试用时要特别观察目录迁移后是否清晰，页面间引用能否延续，权限是否能按组织实际结构配置，以及团队成员能否快速理解新的内容入口。

需要谨慎的是，知识内容迁入新平台并不等于治理自动完成。若原有页面的命名混乱、重复内容多、维护责任不清，迁移后搜索可能只是把旧问题带入新系统。签约前应核对目标套餐中的企业管理能力、导入导出方式、身份与权限能力，以及合同约定的数据处理内容。

2. 飞书知识库：把知识库放进办公协作生态一起评估

飞书知识库的评估重点，不应只停在“能不能写文档”，而要看知识页面与团队日常协作是否形成顺畅路径。若企业已经使用同一办公环境开展消息、会议、日历和文档协作，统一入口可能降低切换成本；若企业采用多套办公工具，则要进一步核实跨系统搜索、身份管理和内容访问的实际体验。

试用时可以模拟一项真实流程：在项目群中讨论决策，形成正式记录，再由其他成员通过搜索找到记录，并确认他们拥有恰当的访问权限。重点观察临时讨论怎样沉淀为稳定文档、页面如何被维护、信息通知是否会造成冗余，以及退出原有系统后是否还需要保留多个入口。

这类办公生态方案的取舍是，协作入口整合可能带来便利，但产品价值会受到企业整体办公平台选择的影响。不要仅凭知识库单项演示决定采购；应把协作套件的现有使用情况、组织接受度、账号体系和其他工具的并存成本一起评估。

3. 腾讯乐享：关注企业内部学习、内容运营与知识传播

腾讯乐享可以作为企业内部知识传播和学习管理方向的候选来评估。若需求不只是“把页面存起来”，还包括制度宣导、经验分享、培训内容或内部活动，就要检查内容触达、学习参与、内容运营和管理者视角是否符合团队的工作方式。

试点时不要只由系统管理员操作。让内容负责人创建一份培训或知识内容，让普通员工完成查找与阅读，再让管理者查看内容维护和使用情况。观察从内容发布到员工触达之间是否需要额外人工通知，哪些统计口径真实可用，以及平台内容如何与已有培训流程衔接。

如果企业只需要轻量 Wiki，而不需要学习或内容运营能力，较丰富的平台功能可能意味着额外配置和管理负担。应核实实际采用的模块、套餐边界、部署选项与集成方式，避免为了“可能用得上”的功能扩大采购范围。

4. Baklib：从知识内容发布与外部访问需求入手

Baklib适合纳入需要评估知识内容管理和发布场景的候选，尤其是团队需要让不同受众访问不同内容时。应具体验证内容从创建、审核、发布到更新的链条，而不是仅检查编辑器是否具备常见格式功能。

如果原有 Confluence 同时承担内部知识库和对外帮助文档功能，迁移前要把两类内容拆开：内部页面的重点是权限、组织和检索；对外内容还涉及访问路径、发布体验、内容版本和更新责任。候选平台是否能覆盖这些需求，要以当前产品材料和实际试用为准。

这类方案的边界需要结合企业协作习惯判断。若员工日常仍然依赖其他工具完成讨论、项目推进和任务跟踪，知识平台可能需要通过链接或集成与这些工具配合。试点时应记录用户是否能从工作现场自然进入知识内容，而非要求他们记住另一个孤立入口。

5. PingCode Wiki：研发知识要连到研发工作上下文

PingCode Wiki更值得在研发知识管理和项目协作场景下评估，尤其是文档不只是独立页面，而是需要与需求、任务、测试或项目记录相互关联的团队。PingCode主要服务中大型企业及100人以上组织，因此评估时除了普通使用者体验，也要关注跨团队权限、管理员维护、流程配置和规模化落地方式。

我会用一组研发任务来验证：从一个正在进行的项目找到设计说明，从缺陷记录定位故障复盘，再从复盘找到相关决策和后续行动。若每次都要靠人工复制链接、重复填写标题或跨多个工具检索，所谓“有 Wiki”并不代表研发知识链条真正闭合。

需要核实的项目包括当前版本的知识空间能力、与项目工作对象的关联方式、权限治理、集成边界、迁移支持、部署与报价口径。不要根据产品类别推断某项能力一定存在，也不要把“研发团队适用”理解成任何规模的研发组织都无需流程调整。

6. 石墨文档企业版：检验协同编辑与组织管理的平衡

石墨文档企业版可以纳入文档协作和团队知识管理方向的对比。对候选方案的判断重点，是它能否既满足成员共同编辑和内容共享，又支持企业所需的组织权限、管理流程和知识归档方式。普通文档协作能力不能自动替代完整的知识治理。

建议选取一份多人共同维护的项目手册，以及一组跨部门制度页面进行试用。前者测试协作编辑和讨论是否顺畅，后者测试内容如何分类、授权、更新和检索。两类任务得出的结果可能不同，所以不能只用一份演示文档代表所有使用场景。

如果企业还需要复杂的项目流程或研发对象关联，应把相关能力当作待验证项，而不是默认包含在文档产品内。报价比较时也要把企业管理功能、用户规模、增值模块、合同周期和服务内容逐项对齐。

7. 用同一张核验表看差异，不用未经验证的星级制造排名

下面的表格是选型核验框架，不是产品功能认证表。表中“优先验证”表示应重点试用的方向，不代表产品一定具备相应能力；部署、迁移、审计和价格均可能依版本、套餐及合同而不同，必须在采购前逐项确认。

四、专业判断逻辑：用门槛、任务和成本做决策

1. 第一步：用硬性条件过滤候选

将硬性要求写成可验证的问题，避免使用“安全性好”“能私有化”“支持迁移”这类含糊说法。比如，具体需要何种部署形态、哪些数据必须留在指定环境、是否需要特定认证方式、管理员是否需要审计记录、外部人员能否按项目授权。

每个条件都要有证据：官方文档、合同条款、试用演示记录或供应商书面确认。只有销售口头承诺而没有可追溯材料的项目，应标记为风险，而不是默认通过。

2. 第二步：用任务测试实际使用效果

我建议每款候选至少安排一名管理员、两名内容维护者和若干普通使用者参与。让他们完成相同任务，并记录任务是否完成、耗时、错误和求助次数。评估不要只问“喜欢哪个”，还要问“完成任务时卡在哪里”“如果系统每天使用，哪一步最容易被绕开”。

一个可执行的试点任务包可以包含：新建并归档一页制度、共同编辑一份项目文档、搜索并找到一项历史决策、给两个团队配置不同访问范围、从旧页面链接跳转至新页面。每个任务都应规定什么叫成功，例如找到正确版本、没有越权访问、链接能够到达有效内容。

如果参与者没有完成任务，先区分是界面学习问题、权限配置问题、内容结构问题，还是候选方案本身不支持。不同原因对应不同决策：前两者可能通过培训解决，内容结构问题要补治理工作，不支持则需要换方案或调整业务流程。

3. 第三步：用总拥有成本代替单一订阅价格

采购比较至少纳入六项成本：订阅费用、迁移实施、人力整理、集成开发、培训与支持、持续治理。特别要把内部人员的投入折算成工时或人天，因为“软件报价便宜”并不能抵消数月的人工清洗、权限重建和流程维护。

建议使用统一计算式：总拥有成本 = 合同期内许可费用 + 一次性迁移与实施费用 + 内部整理和培训投入 + 集成维护费用 + 运行治理费用。对不同候选使用同一周期、相同用户规模和相同服务范围计算，否则报价表看起来可比，实际上口径不同。

下图是一个迁移项目的情景模拟，用来说明成本容易藏在哪里，不代表任何具体企业或产品的真实报价。实际项目应根据页面抽样结果、人员投入和供应商报价重新测算。

4. 第四步：给候选做“条件式结论”

最后的结论不宜只写“推荐第一名”。更可执行的表达是：如果首要目标是知识内容整理，优先试用哪些候选；如果核心是办公生态整合，检查哪些平台约束；如果研发知识必须与项目对象相连，试点应使用什么任务；如果部署或数据治理是硬门槛，哪些材料必须先拿到。

任何推荐都要带上前提和风险。例如“适合已有某协作生态的团队”比“最适合所有企业”更有用；“适合研发知识与项目内容联动的团队，需验证现有流程和部署条件”也比泛泛说“功能强大”更能帮助决策。

五、迁移案例推演：不要从全量搬迁开始

1. 一个可复用的假设场景

假设一家约150人的软件团队准备评估替代方案，现有内容分布在研发、产品、交付和内部制度几个空间。管理层的原始要求是“把文档迁走”，但访谈后发现真正影响日常工作的有三类：项目文档被任务关联、历史决策可被搜索、不同项目组的访问范围不能混淆。

这个场景是用于说明方法的情景推演，不是某家企业的实际客户案例。它的关键价值在于把“迁走文档”重新拆成可验收的任务：内容是否完整、上下文能否找回、权限是否正确，以及使用者是否愿意从新入口完成工作。

2. 第一周盘点：先找出高价值样本

团队不需要一开始就完整清点每个页面的所有细节。可以先按空间、负责人、最近访问、附件比例、权限复杂度抽样，挑出高频内容和高风险内容。样本至少覆盖正常页面、含有大量附件的页面、跨空间引用的页面和敏感权限页面。

在每条样本记录中写清原始链接、内容负责人、最近维护时间、访问范围、是否仍被项目或任务引用。对于无法确认负责人或长期没有访问记录的内容，先标注为待处置，不要默认把它们一起迁移。

3. 第二周试点：安排真实用户完成同一组任务

试点阶段选一组小团队，使用候选平台处理真实但可控的任务。比如把一份项目决策记录迁入新平台，让成员从项目任务找到它；把一份制度页面设置成两个部门可见范围；让新成员按给定问题搜索出正确答案。

每项任务记录四类信息：成功与否、完成时间、需要多少次人工指导、结果是否正确。不要把打字速度当作效率，也不要只看管理员能否配置成功。普通用户的查找和使用体验，往往决定系统上线后是否会被绕开。

4. 第三周复盘：把“缺陷”分成三类

试点问题可以分为内容问题、配置问题和方案边界问题。内容问题包括原页面重复、标签混乱或责任人不明；配置问题包括目录、权限和模板没有设好；方案边界问题则是候选无法支持某项必要的关联或管理要求。

只有第三类问题通常意味着需要淘汰候选或调整业务流程。若把所有问题都归咎于产品，可能会错过整理知识的机会；若把所有问题都归咎于培训，又可能让团队长期承担产品本身无法满足的需求。

5. 用示意数据观察试点是否值得扩大

下面的数据是试点决策的情景模拟，用于展示应观察哪些过程指标，不代表任何产品的真实表现。设定三个阶段分别为迁移前基线、试点初期和完成结构与培训调整后，重点看任务完成率、找回正确内容所需时间，以及人工求助频次。

六、最容易踩的误区：功能看起来相似，不代表风险相同

1. 把“支持导入”理解成“迁移完成”

导入功能通常只能回答“数据能否进入系统”，不能自动回答“原来怎么用还能不能继续”。页面格式变化、内部链接失效、附件遗漏、旧权限无法映射、历史版本不完整，都可能发生在导入之后。

签约前应要求对方说明支持的源数据格式、可迁移对象、已知限制、失败处理方式和可提供的迁移协助。试点时至少抽查不同类型的页面，并记录导入前后差异。若供应商无法明确说明数据范围，就不要把“支持迁移”当作迁移质量承诺。

2. 把功能数量当成知识管理成熟度

页面模板、评论、标签、通知、统计等功能看起来越多，不等于团队知识管理越成熟。知识能否维护，取决于内容负责人、分类规则、更新机制、权限边界和失效内容的处理方式。没有治理规则，功能越丰富有时反而意味着管理者要承担更多配置工作。

我会追问三个问题：谁负责维护关键页面；页面过期后谁确认；出现重复版本时哪个版本具有权威性。若企业没有这些答案，先做内容治理试点，通常比马上采购更有价值。

3. 把“国产方案”直接等同于部署或合规结论

产品来源不能代替安全评估。企业需要核实数据存储与处理说明、访问控制、审计能力、合同条款、服务支持范围和具体部署选项。公开宣传页上的概括性描述，不能替代企业法务、安全和 IT 团队的正式审查。

特别是有明确环境要求的组织，应把部署与数据处理要求写成准入清单，要求供应商以当前版本材料回应。不同套餐可能对应不同能力；若实际购买版本不包含目标功能，产品层面的宣传也无法弥补合同和配置上的缺口。

4. 把订阅价格当成总成本

低起步价不必然代表低成本。用户规模、企业管理功能、额外模块、实施服务、数据迁移、身份集成和后续运维都可能改变总账。不同供应商的报价如果用户口径、合同周期和服务范围不同，就不能直接比较。

应要求统一报价口径：相同使用人数、相同合同周期、相同部署前提、相同服务范围，并把增购条件写清楚。还要计算内部团队整理旧内容的工时，因为这笔成本通常不会出现在供应商报价单里，却会真实占用业务人员时间。

5. 忽略旧链接和用户习惯造成的“影子系统”

切换完成不代表旧系统立即消失。浏览器收藏夹、聊天记录中的链接、项目文档引用和个人笔记都可能继续指向旧页面。若旧系统关闭过快，团队会遇到大量找不到资料的问题；若旧系统长期保留且仍可编辑，内容又可能分裂成新旧两套。

建议明确并行运行期限、旧内容只读策略、重定向或链接通知方式，以及谁负责处理失效链接。切换后安排一段反馈窗口，记录用户仍然通过旧入口查找的内容，并据此补齐新系统索引或迁移遗漏。

6. 只让管理员试用，不让真实使用者参与

管理员能够创建空间、配置权限，不代表普通员工能找到内容。相反，普通使用者觉得界面简单，也不代表企业能满足审计、批量管理和复杂权限要求。试点参与者至少要覆盖内容管理员、日常维护者、普通阅读者和 IT 或安全相关人员。

对外部协作或跨部门共享较多的企业，还要加入外部访问者或业务代表测试。每个角色的成功条件不同：管理员关心治理，维护者关心更新，读者关心查找，安全人员关心边界。只听一个角色的反馈，结论容易偏。

七、按团队情况行动：先试什么，优先放弃什么

1. 小团队或轻量知识库需求

如果团队人数不多、内容类型简单、没有复杂部署要求，先把重点放在知识结构、搜索体验、协作门槛和导出能力。不要因为别人使用大型平台就照搬同样的配置，也不要为了未来可能出现的复杂需求提前采购一堆当前用不到的模块。

行动上先选一个知识空间和一组高频任务做小试点，明确页面命名、负责人和更新频率。试点通过后再逐步扩展内容，而不是一次性迁移所有历史材料。

2. 中大型组织或多部门协作

多部门组织要把权限治理和内容责任放在前面。空间所有权、部门交叉访问、离职人员内容处理、外部分享和审计要求，都应成为测试场景。还要确认管理员能否以可持续的方式维护组织变化，不要让权限配置完全依赖少数熟练管理员。

可以先选两个业务部门和一个跨部门项目共同参与试点。若只有单部门成功，而跨部门权限与搜索失败，说明候选还没有证明适合组织级推广。

3. 研发团队或项目交付团队

研发团队优先验证知识与项目上下文的关联，而不只是文档编辑。选一个正在进行的项目，测试设计文档、需求、缺陷、测试记录和复盘之间能否形成可追踪路径。项目交付团队则应测试交付文档模板、客户范围权限和项目结束后的归档方式。

如果知识页面只能靠手工维护多个重复链接，需评估长期维护成本；如果所有内容都放进项目工具但搜索和知识分类不足，也要考虑补充独立知识结构。最终选择应由真实任务表现决定，而不是由“工具属于研发类”或“工具属于办公类”决定。

4. 有部署、数据或审计硬约束的组织

这类组织应先做供应商材料审查，再进入深度体验。将目标部署方式、身份体系、访问日志、数据处理、备份与恢复、服务边界逐项写成问题清单，要求对应到当前版本和拟采购套餐。

若某项要求没有书面依据，不应依赖口头解释推动上线。可先安排技术、安全和采购人员共同参加答疑，再决定是否投入迁移试点。硬约束没有确认之前，功能演示的结论只能作为体验参考，不能作为采购结论。

5. 预算有限但迁移压力较大的团队

预算有限时，不要把范围定成“全部内容一次迁完”。先识别必须保留的活跃内容、必须满足的工作流和必须归档的历史内容。低价值、重复或过期页面可以先清理或采用只读归档策略，但应由内容负责人确认，不能为压缩工期擅自删除。

分阶段迁移可以降低一次性风险，但会产生新旧并行管理成本。要设定每一阶段的验收条件、停止条件和回滚方案，避免试点长期悬而未决，最后变成两套系统都要维护。

八、最终取舍：用一张“现在必须解决什么”清单结束评审

1. 适合优先选择知识库能力的情况

如果主要问题是内容散落、搜索困难、页面无人维护，而团队的任务流程已经在其他系统中运行，可以优先评估以知识组织和检索为中心的方案。此时应把内容负责人、目录治理和更新机制一起设计，否则只是把散乱信息换一个地方保存。

2. 适合优先选择办公生态整合的情况

如果员工日常工作高度依赖统一办公环境，且知识内容要与沟通和协同紧密连接，应把办公生态中的知识能力纳入重点试用。决策时要核算整体迁移与培训影响，评估其他工具是否仍需保留，以及跨系统使用是否会让团队重复维护内容。

3. 适合优先选择研发知识关联能力的情况

如果研发资料需要与需求、项目、缺陷或测试记录互相追溯，就要用真实项目任务验证关联链条。PingCode Wiki可以作为这一场景的候选之一，但最终是否合适，取决于当前版本、既有流程、部署要求和试点结果，而不是产品名称或定位本身。

4. 下一步按五项动作推进

1. 明确范围：列出哪些内容和工作流必须替代，哪些历史数据只需归档。

2. 设置门槛：写清部署、数据处理、权限、审计和身份要求，并要求可核验材料。

3. 准备样本：挑选高频、复杂权限、附件密集和跨页面引用内容做迁移测试。

4. 组织试点：让管理员、维护者和普通用户完成同一组真实任务，记录结果而非印象。

5. 计算总成本：统一合同周期和用户口径，把整理、集成、培训、并行运行与治理投入计算进去。

选 Confluence 替代方案时，我最看重的不是“功能像不像”，而是团队在切换后能否继续找到可信内容、维持正确权限，并把新知识稳定地放回工作流程。六款候选没有脱离场景的总冠军；真正可靠的结论，来自一组可复现的任务、一份诚实的迁移清单和经过核实的采购条件。下一步不必立刻做全量迁移，先用一周盘点关键内容，再用一组真实任务验证两到三款候选，通常比继续比较宣传页更接近正确答案。