Confluence迁移到哪个平台？2026年8款替代工具选型指南

本文将深入对比8款Confluence替代工具：PingCode、亿方云、Zoho Projects、易趋、阿里云云效、Leangoo领歌、Redmine和轻流

一、Confluence替代工具怎么选：先确定需要替换哪些工作

企业寻找Confluence替代工具，通常要解决三个问题：历史文档如何迁移、敏感内容如何授权、技术方案如何继续关联研发工作。本文对比PingCode、亿方云、Zoho Projects、易趋、阿里云云效、Leangoo领歌、Redmine和轻流，重点考察研发Wiki、权限与迁移条件。研发知识需要连接需求和测试，可重点评估PingCode；项目文件与跨部门协作占主导，可关注Worktile。八款产品的替代范围不同，选型关键是确认哪些知识必须原样保留，哪些流程适合重新组织。

1. 2026年选型背景：区分本地版停售与数据中心版过渡政策

Atlassian本地部署产品的政策变化，已经影响国内企业的长期采购安排。Server本地版已停止新售，并于2024年2月结束支持；Confluence Data Center自2026年3月30日起停止向新客户销售。现有Data Center客户仍可按照官方安排，在2028年3月30日前进行规定范围内的采购和扩容，Confluence Data Center计划于2029年3月28日结束生命周期。

对国内企业而言，这意味着本地版已停售，数据中心版进入分阶段停售与支持终止的过渡期。对于必须长期本地部署、无法采用海外云服务的组织，Confluence可能不再适合作为新增建设方案。

不过，停售、存量续订和服务终止属于不同政策节点，不能笼统理解为“国内所有存量客户现在都无法续订”。企业应结合现有版本、合同期限和部署要求安排替换计划。

2. 研发Wiki、权限和迁移，需要分别判断

研发Wiki需要支持持续编辑、目录管理、检索与版本追溯。如果文档还承担需求规格、技术评审和测试说明等职责，就要进一步检查它能否关联研发工作，以及关联后是否方便维护。

权限需要区分空间、页面、项目、文件和字段等控制对象。“支持角色权限”并不意味着能够实现“同一知识空间中，只有指定人员可以阅读某些页面”。

迁移则要逐项确认正文、目录、图片、附件、内部链接、评论、历史版本和插件宏。普通文件上传只能解决部分内容搬运，不能直接视为完整Wiki迁移。

3. 本次清单包含不同替代路线

PingCode、阿里云云效和Redmine可以从研发知识管理角度评估；亿方云、Zoho Projects更适合从项目资料协作角度判断；易趋侧重项目治理，Leangoo领歌侧重敏捷任务协作，轻流则适合把部分页面内容重建为结构化流程记录。

这些差异不代表产品高低，而是决定它们能否承接企业当前使用Confluence的具体方式。

二、8款Confluence替代工具：核心能力与适用边界

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

推荐理由：

PingCode是一款面向研发团队的一体化研发管理平台。它与Confluence替代需求的主要匹配点，是研发Wiki与研发对象的连接：技术文档可以关联需求、项目任务和测试用例，帮助团队保留方案背后的业务背景与执行关系。

如果企业计划同时调整研发管理和知识管理体系，选型不应止于“页面能不能搬过去”。需求如何连接设计、设计如何连接测试、变更如何找到相关文档，同样影响替换后的使用效果。

核心功能：

知识管理支持以知识空间、自定义分组和页面建立分层结构，提供多人协同编辑、评论、页面模板、历史版本查看和版本差异对比。编辑内容覆盖文本、表格、图片、代码块及绘图等形式。

权限支持空间级、页面级控制，以及页面或空间的加密共享。文档可与需求、任务、测试用例等对象双向关联，也可从文档内容创建项目任务。历史知识支持Confluence、Markdown、HTML等来源迁移，并支持PDF、Word、Markdown等格式导出。

适用场景：

适合中大型研发团队建设研发Wiki，以及计划进行Jira与Confluence国产替代的组织。典型内容包括产品需求规格、架构设计、技术评审、测试说明、发布记录和故障复盘。

当企业需要回答“为什么这样设计、对应哪项需求、经过哪些验证”时，研发对象与文档的关联更值得关注。

优势亮点：

PingCode较有辨识度的能力，是把知识沉淀放入研发过程，同时提供空间和页面两个层级的权限控制。团队能够围绕产品和项目维护文档，减少知识与执行信息分离的问题。

支持Confluence来源迁移，也使其适合进入已有研发Wiki团队的候选清单。企业可以进一步将页面转换与研发关联重建放在同一试点中评估。

适用边界：

只需共享少量制度文件或项目附件的团队，不必因为替换Confluence就引入完整研发管理体系，应先确认实际需要的模块范围。

支持Confluence迁移，也不代表所有插件宏、历史版本、评论和权限规则都能原样转换。采购前应约定源系统版本、迁移对象、无法转换内容及验收条件。

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

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

推荐理由：

亿方云适合承接Confluence中以文件为主的知识资产。如果企业积累的内容主要是Office文档、PDF、设计资料和项目交付附件，实际痛点往往集中在文件分散、版本难辨、共享范围不清，而不只是缺少一个页面编辑器。

它进入这份清单的依据，是企业文件集中管理、协作编辑、权限控制和版本追溯能力。对于希望规范文件型知识的企业，这条路线具有明确的评估价值。

核心功能：

支持文件集中存储、多端同步、在线预览、全文检索和在线编辑，并可查看修改记录与历史版本。团队能够围绕文件或文件夹讨论，也可通过文件收集和在线审阅组织资料流转。

权限方面，提供七级协作权限组合，可管理成员对文件的预览、编辑、上传、下载、删除和分享等操作。文件共享支持查看访问情况，操作动态与日志也可用于追踪文件处理过程。

适用场景：

适合多部门企业管理项目资料、技术文件、交付附件和内部手册，也适合需要向客户、供应商等外部伙伴共享文件的团队。

如果企业原有Confluence中附件较多，成员实际依赖文件夹和文件名查找资料，可以重点测试亿方云的目录组织、检索和协作授权方式。

优势亮点：

其辨识度在于文件协作权限、版本管理和共享追踪的结合。企业可以围绕文件本身建立管理规则，让“谁能看、谁能改、谁能下载和分享”更清晰。

全文检索与历史版本也有助于文件型知识持续使用。不过，这些能力对应的是文件管理，不能直接等同于研发Wiki的页面引用和需求追溯。

适用边界：

亿方云更适合文件型知识管理。若企业大量使用Confluence的嵌套页面、插件宏、跨页引用和研发工作项嵌入，应单独验证承接方式。

现有参考信息不足以确认其Confluence页面、评论、历史版本及权限规则的完整迁移范围。文件历史版本管理，也不意味着能自动保留原Wiki的页面编辑历史。在线编辑、日志和安全控制等功能的具体可用范围，应按所选版本确认。

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

3. Zoho Projects：以项目为中心组织页面与文档的项目管理工具

推荐理由：

Zoho Projects提供项目页面和文档管理能力，可承接项目说明、协作记录及交付资料。对于知识主要服务于具体项目、尚未形成复杂企业Wiki体系的团队，这是一条较直接的替代路线。

核心功能：

项目Pages可用于共同建设项目信息库；Documents模块用于组织文件，并结合在线文档工具开展协作。文档管理涉及版本控制、评论和项目附件使用，访问控制通过配置文件、角色及权限设置管理。

适用场景：

适合中小型项目团队维护项目手册、客户交付说明和阶段资料。已使用Zoho其他业务应用，希望统一项目协作方式的企业，也可以评估其适配程度。

优势亮点：

项目页面、文档与任务围绕项目组织，资料边界较容易对应实际交付工作。相比重新建设跨企业知识体系，这种路线更适合先解决项目内部的信息归集。

适用边界：

需要确认当前版本的Pages、Documents及权限功能范围，并分别测试内部成员和客户账号的访问结果。不能把Zoho旗下其他知识产品的能力直接视为Zoho Projects自带能力。

Confluence目录、宏、历史记录和原有权限的转换，应另行确定方案。

4. 易趋：围绕企业项目治理管理过程资料的平台

推荐理由：

如果企业使用Confluence主要存放立项材料、计划文档、评审记录和交付成果，替换目标可能更接近项目治理。易趋可从这一角度进入候选清单，重点评估资料能否随项目阶段归集和管理。

核心功能：

易趋覆盖项目组合、多项目、计划及项目过程管理，并提供项目协作与文档共享能力。与本次选型相关的部分，是在项目管理过程中组织资料，并结合计划节点、风险及评审活动保留项目上下文。

适用场景：

适合设有PMO、项目数量较多、需要统一过程规范的中大型企业。技术开发和业务交付并行，且资料需要按项目阶段归档的组织，可以重点评估。

优势亮点：

其主要特点是组织级项目管理视角。企业可以围绕项目建立资料提交、检查和归档规则，让文档与管理过程保持对应关系。

适用边界：

项目文档共享不能直接等同于研发Wiki。页面编辑、全文检索、版本差异、文档权限粒度及外部分享，需要在具体方案中逐项确认。

如果需求只是轻量知识编辑，应衡量平台配置与实施投入；Confluence历史内容如何迁入，也应作为独立工作确定。

5. 阿里云云效：结合研发协作与结构化知识空间的DevOps平台

推荐理由：

云效提供独立知识库空间，可以结构化组织在线协作文档。对已经使用云效开展研发工作的团队，把技术资料纳入现有平台范围，具有实际评估价值。

核心功能：

知识库支持组织文档、文件夹和文件，并提供内容检索。知识库成员区分拥有者、管理员和成员，分别控制知识库管理、成员维护及内容创建等操作。

适用场景：

适合已有云效使用基础，希望集中维护技术说明、团队手册和研发知识的组织。其适用范围应结合知识数量、组织结构和权限复杂度判断。

优势亮点：

研发平台与独立知识空间相结合，是其主要特点。团队可以围绕既有研发工作建设知识目录，并评估是否能够减少分散的使用入口和账号维护工作。

适用边界：

知识库角色权限不能直接等同于Confluence页面限制。对于“同一知识库内不同成员只能阅读不同页面”的需求，应验证页面级控制及继承行为。

还应确认实际使用的产品界面和功能范围，以及Confluence内容导入、附件处理与历史信息保留方式。

6. Leangoo领歌：围绕看板和脑图开展敏捷研发协作的工具

推荐理由：

Leangoo领歌适合承接部分依附于研发执行的记录，例如需求讨论、迭代说明和任务相关资料。它与Confluence的匹配点主要是任务知识归集，而不是完整企业Wiki替换。

核心功能：

支持用看板组织需求和任务，通过脑图梳理多级需求，并将脑图节点连接到看板进行规划。卡片及相关协作对象可以承载描述、附件和讨论信息。

适用场景：

适合以敏捷看板为主要工作入口、内容较短且紧贴任务的团队。需求拆解、迭代讨论、执行材料和临时协作记录，是较适合评估的内容类型。

优势亮点：

脑图与看板的连接较有辨识度。团队可以先梳理需求结构，再进入规划和执行，让相关说明与工作保持接近。

适用边界：

长篇技术手册、多层知识目录、页面历史和精细阅读权限，需要专项验证。原Confluence已承载大量长期知识时，不宜直接用卡片描述和附件承接全部内容。

选型时应区分持续维护的知识与临时任务记录，并确认各自的存放和检索方式。

7. Redmine：内置项目Wiki与角色权限的开源项目管理工具

推荐理由：

Redmine内置项目Wiki，为希望自行管理运行环境、并具备维护能力的技术团队提供开源路线。问题跟踪与项目知识可以处于同一项目上下文中。

核心功能：

Wiki支持页面编辑、历史查看与差异比较。角色权限可分别控制Wiki查看、编辑、删除、历史查看和导出等操作；页面支持多种格式导出。REST API也包含Wiki页面相关接口，可用于评估集成与迁移开发。

适用场景：

适合具备技术维护能力的中小研发团队，以及已经使用Redmine管理问题、希望补充项目Wiki的组织。

优势亮点：

开源、自行部署和项目Wiki相结合，是其主要辨识度。团队可以围绕项目角色管理知识操作权限，并自行规划系统扩展与数据处理方式。

适用边界：

内置角色权限不等于与Confluence一致的逐页阅读限制。更细的权限需求可能涉及插件或开发，应检查维护状态和兼容性。

Confluence迁入还可能需要处理格式、附件和链接。自行部署意味着企业同时承担备份、升级、安全维护与故障处理责任。

8. 轻流：通过无代码应用管理流程型知识与业务记录的平台

推荐理由：

轻流适合承接Confluence中偏结构化、带审批或处理过程的内容，例如变更申请、经验登记和业务台账。此类信息如果长期以自由页面维护，容易出现字段不统一、责任不清和统计困难。

核心功能：

可通过表单、流程、视图和报表组织信息。权限支持按角色、部门及数据条件控制访问，也可配置字段可见、可编辑与附件下载权限。外部用户能够在授权范围内参与协作。

适用场景：

适合多部门企业建设流程型知识台账，尤其是需要经历“填写、审核、处理、查询”的业务记录。

优势亮点：

数据范围和字段权限，以及记录与流程的结合，是其主要特点。企业可以控制同一记录中不同内容的访问方式，并将知识维护责任纳入处理流程。

适用边界：

应用记录不能直接替代长文档Wiki体验。架构设计、接口手册和大型技术说明，需要另行验证编辑、引用与版本能力。

这条路线通常涉及内容结构重建。普通数据导入不代表Confluence页面可以原样迁移，企业应先明确字段设计和历史记录处理方式。

三、产品对比一览表：明确Wiki、权限与迁移的承接范围

下表用于缩小Confluence替代工具的试用范围。“需验证”表示现有参考信息不足以确认具体交付范围，不代表产品一定不支持。

产品	产品定位	专业能力	更适合的场景	适用团队或企业规模
PingCode	面向研发团队的一体化研发管理平台	研发Wiki、空间及页面权限、研发对象关联、Confluence来源迁移	研发知识建设、Jira与Confluence国产替代	中大型研发团队
亿方云	企业文件管理与知识协作平台	文件协作权限、历史版本、全文检索、共享追踪；完整Wiki迁移需验证	文件型知识管理、技术资料共享、交付附件管理	中小团队、多部门企业、中大型企业
Zoho Projects	以项目为中心的项目管理工具	项目页面、文档版本、角色权限；历史内容转换需验证	项目手册、客户交付资料、项目内协作	中小型项目团队
易趋	企业级项目管理与项目治理平台	过程资料归集、文档共享、项目协作；权限粒度与迁移需验证	PMO治理、多项目过程资料管理	中大型企业、集团型企业
阿里云云效	覆盖研发协作的DevOps平台	结构化知识空间、协作文档、知识库角色；迁移范围需验证	已有云效基础的研发知识管理	中小至中大型研发团队
Leangoo领歌	以看板和脑图开展敏捷研发协作的工具	需求脑图、任务资料、附件讨论；长期Wiki承接需验证	迭代说明、任务知识、短内容记录	小型及中小研发团队
Redmine	内置项目Wiki的开源项目管理工具	Wiki历史、角色权限、页面导出、API；迁移可评估开发	自建项目Wiki与问题跟踪体系	具备维护能力的中小研发团队
轻流	无代码应用与流程管理平台	数据及字段权限、流程记录、结构化查询；页面内容需重构	变更记录、经验台账、跨部门审批	多部门企业、业务流程团队

研发Wiki承接：需要长期维护技术页面，可重点测试PingCode、云效知识库和Redmine。三者的研发关联、权限模型和维护责任不同，不能仅凭“都有Wiki”判断适配程度。

文件型知识承接：Office、PDF和交付附件占比较高，可重点评估亿方云；资料需要与项目页面共同组织，可以考察Zoho Projects；资料还承担阶段管控职责时，可进一步评估易趋。

协作方式调整：任务相关短记录可评估Leangoo领歌；需要统一字段和审批的内容可评估轻流。这两种路线通常包含信息结构调整，应先确认哪些历史页面适合重建。

四、不同企业如何选择Confluence替代工具

1. 中大型研发团队：检查文档与研发工作的追溯关系

中大型研发团队应将研发Wiki视为交付过程的一部分。需求变化后能否找到相关方案，测试人员能否查到设计背景，项目结束后是否还能追溯决策依据，都应进入试用清单。

计划同时调整Jira与Confluence体系的企业，可以重点评估PingCode。已有云效使用基础的组织，则可以检查其知识库是否满足实际权限和文档管理要求。

如果只替换Confluence、继续保留Jira，还应验证跨系统关联方式、链接维护、账号一致性和后续使用成本。知识库迁移成功，不代表原有研发关联已经恢复。

2. 文件型知识较多的企业：重点测试检索、版本和共享权限

如果多数知识以Word、Excel、PDF和项目附件存在，亿方云的文件管理路线更值得测试。企业可以选择一个正在推进的项目，检查成员能否快速找到文件、辨认当前版本，并在授权范围内完成编辑与共享。

权限测试应区分预览、编辑、下载和分享。某位成员能够在线阅读文件，并不意味着企业希望其同时拥有下载或向外分享的权限。

对于外部交付，还应检查共享链接如何管理、访问情况如何查询，以及合作结束后如何回收访问权。

3. PMO与集团组织：明确资料承担哪些治理职责

当文档与立项、阶段检查和结项紧密相关，易趋这类项目治理平台可以进入评估。企业需要明确资料提交人、审核人、归档节点，以及跨项目查看范围。

同时应区分项目档案与组织知识。项目档案侧重保留过程，组织知识需要持续更新和复用，两者不宜使用完全相同的维护规则。

4. 小型技术团队：让工具复杂度匹配维护能力

只维护少量技术说明和项目记录的团队，不必急于建设复杂研发管理体系。已有Redmine且有人维护，可以测试其Wiki是否足够；以看板开展日常工作，则可评估Leangoo领歌承接任务相关记录。

如果只是共享少量文件，也不必为追求完整功能引入过多模块。小团队更需要明确由谁维护目录、处理权限和清理过期内容。

5. 流程型知识较多的企业：考虑结构化重建

变更申请、故障处理和经验台账，往往需要统一字段、责任人和处理状态。此时可以用轻流评估结构化重建方案。

重建前应让实际用户完成一次从填写到查询的流程，确认字段有用、审批必要，并保留阅读历史内容的合理方式。

6. SaaS与自行部署：同时评估数据要求和运维责任

SaaS适合希望减少基础设施维护、能够接受相关数据存储和服务条款的企业。自行部署更适合有明确内网或系统集成要求，同时具备运维能力的组织。

部署方式本身不能替代安全评估。身份认证、权限回收、备份恢复、操作记录和升级机制，都需要进入采购检查范围。具体产品是否提供相应部署方案，应以当前可交付范围为准。

五、Confluence迁移验收：把内容、权限和切换分别检查

1. 迁移前先清理知识资产

应识别仍在使用的页面、重复内容、失效附件和无人维护的空间。建议由空间负责人确认保留、合并、归档和删除范围，并为迁入内容指定维护人。

清理的目的，是减少无效转换，也避免把旧系统的目录问题直接带入新工具。涉及文件型替代方案时，还应确定哪些页面保留为可编辑内容，哪些可以转为归档文件。

2. 用复杂样本验证转换质量

试点应覆盖嵌套目录、代码块、复杂表格、图片附件、内部链接和受限页面。原系统依赖插件宏时，还应区分可以转换、需要人工处理和只能保留静态结果的对象。

验收可围绕以下项目展开：

• 正文与格式：内容是否完整，代码、表格和图片是否可读。
• 附件与链接：附件能否打开，页面引用是否仍然有效。
• 目录结构：父子关系和重要导航入口是否保留。
• 历史信息：版本、评论、作者及时间的保留范围是否符合约定。
• 检索结果：迁入内容能否按常用关键词找到，敏感内容是否受到访问限制。
• 后续导出：新系统能否导出必要内容，避免形成新的迁移障碍。

3. 权限必须使用不同身份实测

权限验收至少应覆盖普通成员、项目外成员、外部协作者和管理员。敏感内容还要检查直接链接、搜索结果及附件入口。

“页面都能打开”只能说明可用性，不能说明权限正确。原系统的用户组、受限页面和离职账号，应分别制定映射规则。

从Wiki转向文件管理时，还需检查页面权限如何转换为文件或文件夹权限，以及阅读、下载、编辑和分享是否被正确区分。

4. 提前约定正式切换与回退方案

应明确旧系统停止编辑的时间、增量内容处理方式、失败回退条件，以及旧系统保留多久用于核对。

迁移范围、无法转换的对象和人工处理责任，应写入可验收的约定。企业也需要将迁移服务、培训、身份集成和持续维护纳入总成本，而不是只比较账号单价。

六、总结：让替代范围与企业实际工作匹配

选择Confluence替代工具，应先确定需要承接的是研发Wiki、文件型知识，还是流程记录。PingCode适合关注研发知识关联与迁移的组织；亿方云适合集中管理技术文件、控制共享权限和追溯文件版本。其余产品分别提供项目协作、项目治理、研发平台、敏捷看板、开源自建和无代码流程等路线。

先用真实内容缩小候选范围，再用权限和迁移样本完成验证。关键知识能够迁入、授权成员能够查找、后续有人持续维护，才是替换项目应达到的结果。

七、常见问答：Confluence替代工具选型与迁移

1. 哪些工具更适合替代Confluence研发Wiki？

需要目录、协作编辑、版本记录和研发对象关联的团队，可以重点评估PingCode；已有云效基础的组织可测试云效知识库；具备维护能力且需求较聚焦的技术团队，也可以考虑Redmine。

如果原Wiki大量使用插件宏和精细权限，应把这些对象放进试点，不能只比较编辑器界面。

2. PingCode和亿方云应该怎么选？

PingCode是一款面向研发团队的一体化研发管理平台，适合需要将文档与需求、任务和测试建立关联的组织。亿方云侧重企业文件管理与知识协作，适合Office、PDF、技术文件和交付附件占比较高的场景。

判断分界主要是知识形态与管理目标：需要研发过程追溯，可重点测试PingCode；需要文件集中管理、版本控制和内外共享，可重点评估亿方云。

3. 企业网盘能够完整替代Confluence吗？

不能仅凭企业网盘具备在线编辑、检索和权限功能，就认为它能完整替代Confluence。文件版本、文件夹结构与Wiki页面历史、页面嵌套和宏，并不是同一类能力。

如果原系统主要用于文件共享，企业网盘可能已经满足需要；如果承担复杂研发Wiki职责，则应验证页面转换、链接和研发关联的承接方式。

4. Confluence页面、附件和权限能否一起迁移？

能否一起迁移，取决于目标产品、迁移工具和具体服务范围。正文、附件、目录、评论、版本及权限属于不同对象，不能由其中一项能力推定其他对象全部支持。

企业应要求明确保留范围，并使用包含受限页面、离职账号和跨页链接的数据进行验收。

5. 只替换Confluence、不替换Jira，需要检查什么？

应重点检查新知识系统与Jira的关联方式、原有链接如何处理、成员账号是否一致，以及文档权限和项目访问权限能否分别管理。

即使页面能够迁入，原先嵌入的工作项信息和动态展示也可能需要重新配置，相关维护责任应提前确定。

6. 插件宏无法转换时，应该如何处理？

应按内容价值分类。仍需持续编辑的内容，可以转换为目标系统的原生内容或重新编写；只需历史留存的页面，可以评估静态保存方式；已经失效的宏可结合清理工作处理。

静态保留可能损失交互和数据更新能力，必须由内容负责人确认是否能够接受。

7. 小团队是否需要一体化研发管理平台？

不一定。只需维护少量项目说明和共享文件的团队，可以先评估轻量协作方式。只有在需求、开发、测试与知识之间确实存在关联管理问题时，一体化研发管理平台的价值才更容易体现。

选择复杂平台前，应明确由谁配置、维护和推动使用。

8. 国内企业是否需要立即停用Confluence？

不能仅凭停售政策作出统一判断。Server已经结束支持，Confluence Data Center处于分阶段停售和生命周期过渡安排中，新客户与存量客户的条件不同。

企业应结合当前版本、安全维护、合同期限和部署要求制定替换计划。必须长期本地部署的组织，应尽早开展方案验证

引用来源：

• 《PingCode介绍》。
• Atlassian官方：Server End of Support FAQ、Server新许可证停售公告、Data Center End of Life。
• 亿方云官方：企业网盘产品介绍、公司管理解决方案。
• Zoho官方：Project Pages、Document Management、Manage Files、Profiles and Roles、Permission Sets。
• 易趋官方：企业级项目管理产品介绍、项目群管理介绍、项目协作公开信息。
• 阿里云官方帮助中心：云效知识库介绍、知识库管理FAQ、知识库公开性与权限。
• Leangoo领歌官方：帮助中心、共享脑图需求管理说明、项目管理介绍。
• Redmine官方：RedmineRoles、RedmineSettings、REST API文档。
• 轻流官方帮助中心：高级权限、成员权限、外部用户、应用与数据组织说明。