Jira+Confluence国产替代怎么做？研发流程与知识库选型指南

本文将深入对比7套研发协作与知识管理方案：PingCode、亿方云、FlowUs 息流、语雀、石墨文档、Baklib、Notion

一、Jira+Confluence替代选型：先确定整体替换还是分层替换

Jira+Confluence怎么替代，关键在于企业要保留哪些研发流程、如何管理历史知识。需要同时承接需求、迭代、测试和研发文档的团队，可以重点评估PingCode；文件归档、版本和共享管理需求突出的企业，可以关注亿方云。本文对比PingCode、亿方云、FlowUs 息流、语雀、石墨文档、Baklib和Notion七套方案，从研发能力、知识组织、迁移条件和使用边界展开。核心判断是：复杂研发组织应先验证流程承接，轻量团队可以从文档与任务协作切入。

1. 2026年替换Jira与Confluence，需要了解哪些政策

截至2026年10月，Atlassian本地部署产品的停售与支持政策，需要区分Server和Data Center，也要区分新客户与现有客户。

Server本地版已于2021年2月停止新许可证销售，并于2024年2月15日结束支持。Data Center自2026年3月30日起停止向新客户销售新的订阅及相关Marketplace应用；现有客户仍有过渡安排，可以在2028年3月30日前按政策采购相关订阅、应用和扩容。受影响的Jira、Confluence Data Center产品计划于2029年3月28日结束生命周期。

这些全球性安排同样影响国内企业。对于必须长期本地部署的国内组织，继续新建或扩展原有体系，可能不再适合长期使用规划。但不能将新客户停售，理解为现有客户在2026年已经全部无法续费。

企业应结合当前许可证、插件依赖和部署要求安排迁移，而不是等到支持结束前再集中处理。

2. 七套方案分别能替换哪些部分

Jira主要承接研发工作项与执行流程，Confluence主要承接文档协作与知识沉淀。替代方案可以分为两条路线。

整体替换适合希望统一需求、迭代、测试和研发知识的企业。PingCode可以纳入这类评估，重点检查原有研发流程与知识关联能否共同承接。

分层替换适合已经有稳定研发系统，或只想调整知识管理方式的企业。亿方云侧重文件资产，语雀侧重结构化知识沉淀，石墨文档侧重多人共创，Baklib侧重知识发布。FlowUs 息流和Notion则适合验证轻量项目与文档协作。

这七套方案并不承担相同职责。选型时应比较它们能解决的具体问题，避免把“能够管理文档”等同于“能够完整替代Jira+Confluence”。

3. 企业选型应坚持的四个判断标准

研发流程能否运行，是复杂团队需要先确认的问题。需求层级、状态规则、迭代、版本和缺陷流转，都应通过真实项目验证。

知识能否与工作关联，决定成员能否找到需求背后的技术方案、评审结论和测试依据。仅将文档集中存放，并不能自动建立这些关系。

历史数据能否持续使用，决定迁移是否真正完成。正文、附件、内部链接、账号、权限和评论应分别检查，不能只核对导入数量。

长期维护是否可控，则需要同时计算订阅、实施、集成、培训与运维投入。可配置能力越多，越需要明确流程和模板的维护负责人。

二、7套Jira与Confluence替代方案：能力与适用边界

1. PingCode：面向研发团队的一体化研发管理平台

推荐理由：

PingCode是一款面向研发团队的一体化研发管理平台。对于计划同时调整Jira研发流程和Confluence知识空间的企业，PingCode可以将需求执行与研发知识放入相互关联的管理体系。

它进入这份清单的主要原因，是能够围绕需求、项目、测试和文档建立联系。企业可以同时验证工作项是否承接到位、技术文档是否仍能服务研发执行，减少分别迁移后重新连接业务信息的工作。

核心功能：

PingCode支持敏捷、看板、瀑布和混合项目管理模式，覆盖多级需求、迭代、版本及自定义工作流。团队可以按项目需要配置工作项类型、字段、状态和流转规则。

知识管理通过知识空间、分组和页面组织内容，支持多人协同编辑、历史版本、版本差异对比，以及页面锁定和归档。文档能够与需求、任务、测试用例等对象双向关联，也可以从文档内容创建项目任务。

针对历史系统，PingCode提供Jira与Confluence迁移方案，知识管理支持Confluence、Markdown、HTML等内容迁移。PingCode同时支持私有化部署，具体实施范围需要结合企业环境确认。

适用场景：

适合需要同时管理研发交付与技术知识的中大型研发团队，尤其是计划开展Jira与Confluence国产替代的企业。

当不同团队分别采用敏捷、瀑布或混合模式，又需要统一需求、测试和文档关联规则时，可以重点验证PingCode。对于有私有化部署要求的组织，还应评估部署架构、账号认证、日志审计和运维安排。

优势亮点：

PingCode的差异主要体现在研发对象与知识内容之间的关联。例如，技术方案可以连接对应需求和任务，测试用例又可以关联需求与缺陷，成员能够沿着业务关系寻找上下文。

这类能力适合解决“文档已经写完，却很难判断对应工作进行到哪里”的问题。页面锁定与归档也有助于区分讨论中的方案和已经确认的交付依据。

适用边界：

PingCode覆盖多个研发环节，企业需要投入一定时间配置流程、权限和模板。只有少量待办、会议纪要和文件共享需求的团队，可以先评估更轻量的方案。

历史迁移也不意味着插件、脚本和页面宏都能原样复用。选型时应拿真实项目进行样本迁移，将字段、状态、页面、附件和关联关系逐项验收，并明确不能直接承接的内容如何处理。

官方：https://sc.pingcode.com/0dcjk

2. 亿方云：以企业文件资产管理为核心的协作平台

推荐理由：

亿方云更适合承接Jira+Confluence体系中的文件资产管理部分。对于历史知识主要以Office文档、PDF和项目附件存在的企业，替换时需要先解决文件存放、版本和共享问题。

如果原有痛点是交付资料分散、同名文件版本混乱、外部共享难管理，可以重点评估亿方云。研发需求、迭代和缺陷流程则应由相应研发管理系统承接。

核心功能：

亿方云提供文件集中存储、多格式预览、在线编辑、全文检索、评论和版本管理，支持设置文件协作权限。

企业可以按部门、项目或业务范围组织文件，并管理内部成员及外部合作伙伴的访问。亿方云开放平台提供API和SDK，企业可以评估将文件存储、预览与共享能力接入现有业务系统。

亿方云也提供私有化部署方案，具体部署架构、交付内容及运维责任需要在选型阶段确认。

适用场景：

适合研发、交付、售后及外部合作伙伴共同维护资料的多部门企业。例如，项目交付依赖大量文档和附件，且需要经常向客户或供应商共享时，文件治理应成为独立的选型重点。

如果企业已经有稳定的研发任务系统，只需要补齐文件归档、版本和访问管理，亿方云可以作为分层替换方案的一部分。

优势亮点：

亿方云以文件作为主要管理对象，更贴近已有文档格式和文件协作习惯。历史资料较多的企业，不必为了建立知识入口而将所有内容重新编写成在线页面。

开放接口也为文件能力接入业务流程提供了条件。企业可以在保留业务系统的同时，评估统一文件存储和访问入口，减少多个系统重复保存资料。

适用边界：

亿方云不宜直接替代复杂Jira项目中的需求层级、迭代排期、缺陷流转和测试管理。采用组合方案时，需要明确研发工作项与文件之间的关联方式。

文件集中存储之后，企业仍需规定目录、命名、有效版本和维护负责人。如果多个系统都允许重复上传，应明确正式文件的保存位置，避免版本再次分叉。

官网：https://sc.pingcode.com/x9168

3. FlowUs 息流：以文档和多维表组织轻量项目协作

推荐理由：

FlowUs 息流适合评估轻量替换路线。当团队使用Jira主要记录负责人、任务状态和截止时间，使用Confluence主要编写需求与会议纪要时，可以尝试用文档和多维表组织工作。

FlowUs 息流的价值在于让团队按自身流程搭建协作空间，适合规则仍在变化、尚不需要复杂研发流程的项目组。

核心功能：

FlowUs 息流提供块式文档、多维表、知识库、文件夹和团队空间。文档支持插入表格、代码、音视频和网页等内容，也支持嵌入第三方服务。

团队可以将项目说明、需求文档和任务记录集中组织，用多维表维护结构化信息，用文档记录背景和讨论结论。

适用场景：

适合中小产品团队、创新项目组，以及产品、设计和运营共同参与的轻量协作场景。

如果项目主要依靠负责人、状态和时间安排推进，没有复杂测试追踪与发布控制要求，可以先用一个真实项目验证FlowUs 息流的承载能力。

优势亮点：

文档与多维表可以灵活组合。团队既能编写较完整的需求说明，也能用结构化记录查看任务进度，不必一开始就建立多层审批和复杂状态规则。

对于工作方式仍在调整的团队，这种搭建方式便于逐步形成稳定的项目模板。

适用边界：

自行搭建需要持续维护。如果不同项目各自创建字段和状态，后续容易出现含义不一致、统计口径难统一的问题。

需要复杂缺陷流转、测试资产管理和跨项目发布追踪的企业，应进一步确认承接方式，不能将任务记录能力直接等同于完整研发管理能力。

4. 语雀：围绕结构化知识库沉淀团队文档

推荐理由：

语雀适合重点替换Confluence知识管理部分的企业。对于技术规范、接口说明、团队手册和研发经验分散的问题，结构化知识库比单纯增加共享文件夹更有针对性。

如果研发执行系统已经稳定，企业可以单独评估知识管理工具，无需为了调整文档协作而同时重建所有研发流程。

核心功能：

语雀提供文档编辑、结构化知识库和团队空间，可用于企业知识沉淀、文档协作及接口文档管理，也提供任务管理和话题讨论等团队协作能力。

企业可以按产品、技术领域或团队建立知识库，再通过目录组织需要长期维护的内容。

适用场景：

适合以文档协作为主要诉求的中小团队，以及希望建立部门知识库的企业团队。

当技术规范、培训材料和接口说明需要持续更新，而迭代、缺陷和版本管理已经由其他系统承担时，语雀的职责比较清晰。

优势亮点：

语雀以知识库组织内容，适合把分散的文档整理为可持续维护的知识体系。企业可以围绕目录、模板和更新责任形成管理规则，帮助新成员寻找资料，也便于团队复用已有经验。

选型时可以重点观察知识是否容易整理、查找和更新，而不只是比较编辑器包含多少功能。

适用边界：

语雀不宜直接承接复杂Jira项目的整体迁移。文档协作中的任务与专业研发工作项，管理深度和使用目的有所不同。

历史Confluence内容仍需试迁移，检查页面格式、图片、附件、内部链接和权限。旧知识库中已经过时、重复或无人维护的内容，应先清理再迁入。

5. 石墨文档：以多人实时编辑支持跨部门共创

推荐理由：

如果Confluence的主要用途是共同编写方案、评审需求和维护项目表格，石墨文档值得纳入比较。

这类场景的关键是成员能否顺畅编辑和讨论同一份内容。产品、研发、销售和交付共同参与时，在线协作办公工具往往更贴近已有工作方式。

核心功能：

石墨文档提供在线文档、表格、幻灯片等协作应用，支持多人实时编辑、评论、成员提醒和历史版本。

企业服务还覆盖组织管理、权限控制和知识沉淀，并提供SaaS与私有部署形态。团队可以用这些能力承接需求草稿、评审记录、项目表格与交付方案。

适用场景：

适合文档共创频繁的中小团队和多部门企业，尤其是需求评审需要业务部门共同修改、补充内容的场景。

已有业务系统、希望接入文档协作能力的企业，也可以评估相关集成方案，确认编辑能力与现有业务入口的衔接方式。

优势亮点：

石墨文档的特点是围绕内容开展协作。成员可以对具体段落提出意见，并在同一文档中修改，减少来回传递多个副本的工作。

多种办公内容形态也有利于研发之外的部门参与，不必将所有信息都改写为任务卡片或知识页面。

适用边界：

在线文档和表格不宜长期承担复杂研发状态管理。跨项目依赖、测试覆盖和发布控制要求增加后，依靠人工维护表格可能难以保持一致。

企业还应区分持续编辑的草稿与正式发布的知识，并核对所选版本提供的历史记录、权限、日志和外部协作能力。

6. Baklib：面向知识门户与帮助中心的内容平台

推荐理由：

当Confluence同时承担内部知识库和外部产品文档职责时，Baklib提供了知识整理与发布的替换路线。

如果企业希望将产品手册、常见问题和支持文档形成独立入口，选型应关注内容如何发布、读者如何访问，以及知识如何持续更新。

核心功能：

Baklib提供知识库空间、目录树、文档编辑、导入导出和Wiki应用发布能力，也包含站点搜索、访问控制、成员权限、域名管理和数据看板等功能。

企业可以分别设计后台内容维护与前台阅读流程，为内部成员、客户或合作伙伴组织不同的知识入口。

适用场景：

适合软件企业的产品文档团队、客户支持团队，以及需要建设帮助中心和知识门户的组织。

如果替换Confluence的主要目标是改善知识对外发布和访问方式，可以重点验证Baklib的内容组织、站点展示和授权流程。

优势亮点：

Baklib更关注知识如何发布并被读者找到。目录、搜索、站点与访问控制组合起来，适合围绕特定受众组织内容。

企业可以将内部讨论与正式发布内容分开管理，避免直接向外部用户开放内部协作目录。

适用边界：

Baklib不能直接承接Jira中的研发执行流程。需求、缺陷和测试仍需配套系统，知识页面与研发对象之间的关联也需要另外设计。

迁移时应检查图片、附件、内部链接和页面结构，同时区分后台编辑权限与前台阅读权限，避免授权范围设置错误。

7. Notion：以页面和数据库连接项目、任务与知识

推荐理由：

Notion代表以页面和数据库组合项目管理与知识管理的海外方案。对于流程较轻、希望自行设计工作空间的团队，它可以作为不同技术路线的参考。

企业可以用Notion连接任务与说明文档，但是否能够承接原有研发体系，需要根据流程复杂度判断。

核心功能：

Notion支持项目与任务数据库，可以通过表格、看板和时间线等视图查看信息，并提供子任务、依赖关系和数据库关联能力。

团队可以把项目与会议记录、需求说明等页面连接起来。Notion官方也提供Confluence导入能力，可作为历史知识迁移的验证起点。

适用场景：

适合中小产品团队、跨职能项目组，以及需要中英文内容协作的团队。

如果任务模型较简单，且有成员负责维护模板、数据库关系和权限，可以尝试集中管理轻量项目与团队知识。

优势亮点：

数据库记录能够包含详细页面内容，任务和背景说明可以自然连接。通过关联关系，团队也可以从项目、任务或会议记录等不同入口查找信息。

这种方式适合工作规则仍在调整的团队，但需要保持数据库结构清晰，避免重复建设。

适用边界：

Notion空间需要持续治理。字段规范、页面归属和模板维护责任不清晰时，容易出现重复数据库和难以理解的关联关系。

国内企业还应在真实网络环境下测试访问、附件操作和跨地区协作，并评估数据存储与访问安排是否满足内部要求。复杂Jira流程、插件逻辑和测试管理需求，应逐项确认承接方式。

三、产品对比一览表

这份Jira+Confluence替代方案对比表，重点区分研发流程、知识内容和文件资产三类职责。表中能力不能直接理解为原有系统的逐项等价替换。

产品	产品定位	专业能力	更适合的场景	适用团队或企业规模
PingCode	面向研发团队的一体化研发管理平台	需求与迭代、工作流、测试关联、研发知识管理	同时承接研发流程与知识库，开展历史数据迁移	中大型研发团队
亿方云	企业文件管理与协作平台	文件版本、全文检索、协作权限、开放接口	研发资料归档、文件共享及外部交付	多部门企业、集团型企业
FlowUs 息流	文档与多维表协作平台	块式文档、多维表、知识库、团队空间	轻量任务跟踪与项目资料集中组织	中小团队、创新项目组
语雀	文档协同与结构化知识管理工具	文档编辑、知识库、团队空间、话题讨论	技术规范、接口说明与部门知识沉淀	中小团队、企业部门
石墨文档	在线协同办公产品	实时编辑、评论、历史版本、企业权限	跨部门需求评审与方案共创	中小团队、多部门企业
Baklib	知识管理与内容发布平台	知识库、站点发布、搜索、访问控制	帮助中心、产品手册与知识门户	产品文档团队、企业支持部门
Notion	页面与数据库组合的协作工作空间	项目任务、子任务依赖、数据库关联、文档管理	轻量项目与团队知识集中管理	中小团队、跨职能项目组

四、整体替换还是分层替换？不同研发团队如何选择

1. 中大型研发团队：从完整交付流程开始验证

如果企业需要同时管理需求、开发、测试与发布，应先比较研发流程承接能力。PingCode可以纳入整体替换评估，但试点不应只展示任务看板。

建议选择包含需求变更、跨角色交接和缺陷回流的真实项目。从需求评审、任务拆分到测试和交付，检查每个节点能否找到对应方案、责任人和执行记录。

技术方案发生调整时，还应检查成员能否找到相关需求、任务和测试依据，以及团队准备如何通知受影响人员。验证目标是流程能够运行、信息能够追溯，而不是界面与原系统相似。

2. 资料密集型企业：比较文件治理与文档共创的比重

当企业知识主要以Office文档、PDF和项目附件存在时，可以重点比较亿方云与石墨文档。

如果问题集中在存放位置、版本、检索和外部共享，应先验证亿方云的文件管理能力。如果问题集中在多人修改、意见讨论和跨部门共创，则应重点检查石墨文档的协作编辑流程。

两类需求也可能同时存在。采用组合方案时，应明确草稿在哪里编辑、正式文件在哪里保存，以及其他系统如何引用，避免多个位置都成为内容源头。

3. 轻流程团队：保留必要规则，减少无效配置

如果项目只需要负责人、状态、截止时间和需求说明，可以先用FlowUs 息流或Notion试运行。若主要问题是技术知识难整理，语雀更贴近这一需求。

替换Jira不意味着必须复制所有历史字段和状态。已经不再使用的审批、统计字段和流转步骤，可以在迁移前清理。

是否需要复杂研发管理平台，应由测试追踪、跨项目依赖、版本控制等实际要求决定。流程简单的团队，应关注成员能否持续更新任务和文档。

4. 对外知识服务团队：区分内部讨论与正式发布

维护帮助中心、产品手册和客户支持知识时，可以重点评估Baklib。

这类项目需要检查读者能否找到内容、授权是否清晰，以及发布后的知识是否有人维护。内部技术讨论和面向客户的正式文档应有明确界线。

如果知识经常随版本变化，应规定更新负责人和发布时间，避免产品已经上线、帮助文档仍停留在旧版本。

5. 有部署约束的企业：同时检查数据要求和运维能力

SaaS适合希望快速启动、减少基础设施维护的团队，但仍需核对数据存储、账号管理、导出方式与服务条款。

有明确内网、数据控制或集成要求的企业，可以评估私有化方案。PingCode、亿方云和石墨文档均有相关部署方案，但具体架构和交付范围应在选型时核验。

私有化部署后，备份、恢复、升级、漏洞修复和故障处理仍需要有人负责。企业应将这些工作纳入长期成本，而不是仅比较软件采购金额。

五、Jira与Confluence迁移要检查哪些数据和功能

1. 先清理资产，再建立映射关系

迁移前，应分别盘点研发工作项与知识资产。

研发工作项需要检查类型、字段、状态、评论、附件和关联关系。知识资产需要检查空间、目录、页面、图片、附件、内部链接和访问权限。

清理时可以区分正在使用、需要归档和可以删除的内容。对历史流程中的无效状态、重复字段和过期页面，应先确定处理方式，避免把旧问题完整搬入新系统。

2. 用复杂样本检验迁移结果

试迁移应包含日常内容，也应包含容易出问题的对象，例如自定义字段较多的需求、多次流转的缺陷、嵌入宏的页面，以及设置受限权限的知识空间。

验收时至少检查以下项目：

• 关键字段、负责人和状态是否映射正确。
• 需求、任务、缺陷与文档关联是否保留，或已有替代方式。
• 图片、附件、目录与内部链接是否可用。
• 普通成员、管理员及外部协作者的权限是否符合预期。
• 插件、脚本和页面宏是否有明确处理方案。
• 重要历史记录能否满足后续查询与追溯要求。

导入数量一致，只能说明基础数据核对通过。业务验收应由产品、研发和测试人员参与，确认迁入内容能继续支持实际工作。

3. 明确切换窗口、增量处理和回退条件

正式切换前，应确定数据冻结时间，以及冻结之后产生的新内容如何处理。新旧系统并行期间，也要说明成员在哪个系统更新任务和文档。

回退条件应在迁移前确定。例如，关键权限异常或重要附件无法访问时，是否暂停切换，由谁作出决定，恢复后如何处理新增数据。

旧系统保留方式需要结合许可证、历史查询和内部管理要求安排。对于仍被大量引用的旧链接，应准备查询说明或可行的跳转方案，减少成员寻找历史资料的时间。

六、总结：按研发复杂度与知识形态确定替代路线

Jira+Confluence怎么替代，应从企业需要保留的研发流程、知识内容和文件资产出发。需要整体承接研发管理与知识关联，可以重点评估PingCode；文件存储、版本和共享问题更突出，可以关注亿方云。

FlowUs 息流和Notion适合验证轻量项目与文档协作，语雀侧重结构化知识沉淀，石墨文档侧重多人共创，Baklib侧重知识发布。

企业不必追求所有旧功能原样保留，但必须确认关键流程能运行、重要资料能查找、权限能执行、后续有人维护。候选方案应通过真实项目和迁移样本确定，而不是仅凭功能清单作出决定。

七、Jira+Confluence替代常见问答

1. 有没有一款产品可以同时替代Jira和Confluence？

可以评估同时覆盖研发流程与知识管理的平台，例如PingCode。企业需要确认需求、迭代、测试和文档关联是否符合实际流程，并验证历史数据迁移范围。

同时覆盖不代表逐项复刻。原有插件、脚本和页面宏，仍可能需要转换、重新配置或保留历史查询方式。

2. 亿方云能直接替代Jira吗？

亿方云更适合承接研发文件、版本、共享和资料管理，不宜作为复杂Jira项目的直接等价替代。

如果企业需要需求层级、迭代、缺陷和测试流程，应配置相应研发管理系统，并明确文件与工作项如何关联。

3. 只替换Confluence，需要同时替换Jira吗？

不一定。企业可以分阶段调整研发执行与知识管理，只要过渡期间能够维持必要的访问、链接和检索方式。

如果成员频繁跨系统查找技术方案、需求背景和测试依据，应将关联能力纳入选型，避免拆分后增加维护成本。

4. 支持Confluence导入，是否意味着可以无损迁移？

不能。支持导入，说明存在数据迁入路径，不代表宏、附件、历史版本、内部链接和权限都能原样保留。

企业应使用自身数据进行试迁移。对重要内容写明预期结果，再决定采用转换、归档还是保留旧系统查询等处理方式。

5. 哪些团队不需要复杂的研发管理平台？

任务规模较小、交接环节较少，且没有复杂测试追踪、发布审批和跨项目依赖的团队，可以先评估轻量协作方案。

采用轻量工具后，仍应规定任务状态、文档目录和维护责任。工具是否简单，与协作规则是否清楚，是两个不同问题。

6. 私有化部署和SaaS应该怎么选？

有明确内网、数据控制或特定集成要求的企业，可以重点评估私有化部署。希望快速启用、减少基础设施维护的团队，可以先评估SaaS。

两种方式都需要检查数据管理、权限、导出和恢复条件。私有化方案还应明确升级、安全修复与故障处理责任。

7. 2026年还可以继续使用现有Jira和Confluence Data Center吗？

现有客户仍有官方过渡安排，不能把新客户停售理解为现有系统立即停用。但受影响产品已有明确生命周期时间表，企业应结合当前订阅与应用情况制定计划。

对于必须长期本地部署的企业，适合尽早完成资产盘点、替代试点和迁移演练，给复杂插件与历史知识处理留出时间。

8. 企业试用替代方案时，应该先测试什么？

先测试一条真实业务流程，再测试一组复杂历史数据。业务流程应覆盖需求、执行、评审和交付；历史数据应包含附件、受限权限、内部链接及自定义内容。

演示环境中的功能展示不能替代实际验收。试用结果应说明哪些能力能够直接承接、哪些需要配置，以及哪些需要另配系统。

引用来源：

• 《PingCode介绍》产品文档。
• PingCode官方Jira对比与迁移介绍页面。
• Atlassian官方公告：Reminder: New server app sales are ending on February 15th。
• Atlassian官方说明：Farewell Server, Hello Cloud。
• Atlassian官方政策：Data Center End of Life。
• 亿方云官方网站产品介绍及开放平台API文档。
• FlowUs 息流官方网站产品介绍。
• 语雀官方介绍：语雀空间，团队和企业的在线文档协同平台。
• 石墨文档官方常见问题及《什么是私有化部署》。
• Baklib官方文档中心。
• Notion帮助中心：Sub-items & dependencies。
• Notion官方指南：Connect projects and docs to get more done, faster。
• Notion帮助中心：Import from Confluence to Notion。