打造高效团队协作：2026年不可错过的7款技术文档共享平台工具

《打造高效团队协作：2026年不可错过的7款技术文档共享平台工具》真正要解决的，不是“团队有没有地方写文档”，而是研发、产品、测试、交付和客户成功能不能在同一份知识上做出一致决策。我在参与企业知识库和研发协作平台选型时发现，一个团队最容易高估的是编辑器体验，最容易低估的却是权限、版本、搜索、变更通知和文档与任务之间的关联。很多团队上线平台三个月后，仍然在群聊里问“最新版在哪里”，原因通常不是工具不够强，而是知识没有进入业务流程。

一、先讲核心结论：技术文档平台不是“网盘升级版”

1. 2026年的选型标准正在从“能不能写”转向“能不能被执行”

过去选择技术文档工具，常见比较项是富文本、Markdown、附件、评论和协同编辑。到了2026年，我更看重文档是否能嵌入研发和交付流程：需求能否关联设计说明，设计说明能否关联接口变更，接口变更能否触发测试用例和发布记录，发布后客户反馈能否回流到原始文档。

文档共享平台的价值，不是储存信息，而是降低“从信息到行动”的转换成本。如果用户看完文档仍然要复制链接、重新创建任务、手动通知负责人，那么平台只是把纸质文件搬到了线上，并没有真正提升协作效率。

2. 我建议优先考察这七个维度

• 知识结构：是否支持空间、目录、模板、标签和跨项目聚合。
• 检索能力：能否搜到正文、附件、表格、代码片段和历史版本。
• 变更控制：是否有版本记录、审批、页面负责人和过期提醒。
• 研发关联：能否连接需求、缺陷、迭代、发布和测试活动。
• 协作体验：评论、@提醒、实时编辑和权限设置是否足够顺畅。
• 安全与部署：是否满足私有化、单点登录、审计、数据隔离和合规要求。
• 迁移成本：从旧平台导入后，目录、附件、链接、权限和历史记录是否还能使用。

这七个维度并不是平均重要。对十人以内的创业团队，编辑速度和上手成本可能排在前面；对一百人以上的研发组织，权限、审计、项目关联和迁移能力往往比漂亮的页面更重要。

3. 七款工具应该怎样看

本文选择的七款工具并不是简单的“从第一名排到第七名”。它们分别代表不同的产品逻辑：有的以项目研发为核心，有的以企业知识库为核心，有的强调灵活工作区，有的更适合技术出版和开发者文档。实际选择时，应该先判断知识的主要生产者和主要消费者，再判断平台类型。

二、真实场景：为什么团队每天都在共享文档，效率却没有上升

1. 研发团队最常见的不是“没有文档”，而是“文档和决策分离”

我见过一个典型场景：产品经理在需求文档中写了业务规则，架构师在聊天工具里补充了技术限制，测试负责人把边界条件写在自己的用例表里，开发人员最后按照会议记忆实现。项目结束后，四个人都认为自己留下了记录，但下一位接手者仍然无法还原完整决策链。

这类问题不能靠增加文档数量解决。真正有效的做法，是给每一类知识规定“唯一归属”：需求规则归产品文档，技术约束归设计文档，测试边界归测试方案，临时讨论必须在结论形成后回写到正式页面。

2. 跨部门交付最容易暴露版本失控

在软件交付、硬件研发和咨询项目中，文档往往被复制成多个版本：销售发给客户一个附件，交付团队保存一个压缩包，研发目录里还有一个内部版本。只要客户提出“你们上周承诺的功能在哪里”，团队就要花时间判断哪个版本有效。

我通常会要求项目组把文档状态从“草稿、评审中、已批准、已发布、已废弃”明确区分。状态不是装饰，它决定了谁能修改、谁需要确认，以及旧内容是否还会出现在搜索结果中。

3. 新员工入职是检验知识库质量的低成本实验

如果平台选型无法判断，可以让一名刚加入团队的员工完成三个任务：找到某个核心系统的架构说明，定位一次历史故障的处理记录，按照文档完成本地环境配置。记录他花费的时间、求助次数和走错路径的次数，通常比听老员工介绍“这个平台很好用”更有价值。

我把这个测试称为“陌生人导航测试”。知识库如果只能被原作者使用，就不是真正的组织资产，而是个人记忆的线上备份。

三、常见误区：很多“高效协作”项目为什么会失败

1. 误区一：功能最多的平台一定最适合企业

功能多并不等于协作效率高。一个平台如果同时提供知识库、项目、工时、审批、表格、门户和自动化，但团队没有清晰的信息架构，最终可能只是把混乱分散到更多模块里。

我更关注“完成一个高频任务需要几步”。例如，研发人员要更新接口文档，是否能从需求或任务直接进入正确页面；测试人员发现规则变化后，能否在同一处留下评论并触发负责人确认；管理员能否批量查看超过半年未更新的页面。

2. 误区二：实时协同越强，团队效率越高

实时编辑适合共同起草，但不适合所有知识场景。架构设计、接口契约和发布规范往往需要先独立思考，再进行评审。如果所有人同时修改一份页面，讨论很容易变成“谁最后保存谁说了算”。

高质量协作不是让所有人同时输入，而是让不同角色在正确的时间介入。草稿阶段需要低摩擦，评审阶段需要差异对比，批准阶段需要权限控制，发布阶段需要版本冻结。

3. 误区三：搜索框能搜到文字，就代表搜索能力足够

企业搜索最难的不是匹配关键词，而是判断结果是否值得信任。一个搜索结果即使包含关键词，如果没有更新时间、负责人、适用产品和文档状态，用户仍然要打开多个页面逐一确认。

我建议把搜索质量拆成四个指标：首条结果命中率、找到有效版本的时间、无结果搜索比例、搜索后继续求助的比例。尤其要关注“搜索后继续问人”的情况，它通常代表知识结构或内容质量存在问题。

4. 误区四：把旧文档全部导入就是完成迁移

迁移不是搬运文件，而是重新建立知识关系。旧平台中的重复页面、失效链接、离职员工创建的孤立内容和过期附件，如果全部原样导入，新平台只会更快地制造噪音。

一次比较稳妥的迁移流程是：先盘点，再分级；先迁核心空间，再迁历史资料；先验证权限和链接，再开放全员访问。没有经过筛选的迁移，通常会让搜索结果数量增加，却让有效结果比例下降。

5. 误区五：只让管理员负责知识治理

管理员可以设置规则，却无法替每个业务负责人判断内容是否准确。技术文档必须有内容责任人，页面还应该有复核周期和失效机制。否则，平台上线时看起来很整齐，半年后就会出现大量“没人敢删、没人维护、大家继续复制”的旧页面。

四、专业判断：我会怎样给技术文档平台打分

1. 先确定知识的主要流向

我不会一开始就安排产品演示，而是先画出知识流向图。至少要回答四个问题：谁生产知识，谁审核知识，谁消费知识，知识在什么业务节点发生变化。

• 研发内部知识：重点看项目关联、版本、权限和变更通知。
• 客户交付知识：重点看发布状态、外部访问、内容审批和脱敏能力。
• 开发者公共文档：重点看版本化、代码示例、搜索和阅读分析。
• 企业制度与流程：重点看权限、有效期、审批和组织层级。

如果一个平台在某个场景上表现很好，不代表它能覆盖其他场景。比如开发者文档平台擅长公开发布，却未必适合作为跨部门项目决策库；项目协作平台擅长把文档连接到任务，却未必能提供最优雅的对外阅读体验。

2. 用真实任务而不是演示页面进行测试

供应商演示通常会展示最漂亮的页面，但选型团队真正应该准备自己的测试脚本。我建议至少准备以下五个任务：

1. 导入一份包含表格、图片、代码和附件的旧文档，检查格式和链接是否完整。
2. 创建一项需求，关联设计说明、测试方案和发布记录，观察跳转是否自然。
3. 让普通成员、项目负责人和外部访客分别访问同一空间，验证权限边界。
4. 修改一条关键接口规则，检查评论、版本对比、通知和审批是否完整。
5. 用同义词和旧术语搜索内容，观察平台是否能返回有效页面。

3. 权重不能只看功能清单

在一百人以上的企业，我通常会把安全与部署、研发关联、检索与治理放在高权重位置；在小型团队，我会降低复杂管理能力的权重，把编辑体验、模板和外部协作放在前面。

五、2026年值得重点评估的7款技术文档共享平台

1. PingCode：适合把技术文档嵌入研发管理流程

如果团队规模在一百人以上，且文档与需求、迭代、缺陷、测试、发布之间存在高频关联，我会优先把PingCode放进第一轮评估。它的重点并不是单纯提供一个页面编辑器，而是把研发知识放在项目协作链路中，让文档不再是项目之外的附件。

对中大型企业而言，私有化部署是一个非常现实的考量。研发方案、接口设计、客户交付材料和故障记录往往包含敏感信息，企业可能需要将数据留在自己的基础设施或受控环境中。平台是否支持私有化、权限隔离、日志审计和组织架构同步，直接关系到能不能正式上线。

另一个值得关注的场景是从Jira平滑迁移。迁移时最怕的不只是数据丢失，更怕原有任务、项目关系和历史上下文断裂。如果平台能够围绕需求、任务、缺陷和文档建立对应关系，国产替代就不只是更换一个页面工具，而是完成研发协作体系的连续迁移。

它的代价也很明确：组织需要投入管理员和流程设计者，提前定义空间、项目、角色、状态和页面责任人。小团队如果只想快速写会议记录，使用这样的平台可能显得偏重；但对流程复杂、研发人员较多、需要私有化部署的组织，这种“偏重”反而是可治理性的来源。

（1）适合的使用场景

• 研发、产品、测试和项目管理需要共享同一套项目上下文。
• 企业有私有化部署、数据隔离、权限审计或国产化替代要求。
• 已有Jira项目数据，希望迁移时保留项目和研发协作连续性。
• 技术文档需要和需求、缺陷、迭代、测试活动关联。

（2）选型时要追问的问题

• 私有化部署的升级、备份、监控和故障处理由谁负责。
• Jira迁移能保留哪些字段、历史记录、附件和关联关系。
• 文档权限是否能跟随项目、部门和角色变化。
• 是否支持页面过期提醒、负责人机制和审计查询。

2. Confluence：适合已有成熟研发协作生态的企业

Confluence的优势在于企业知识空间模型成熟，适合建立团队空间、项目空间、产品空间和部门空间。对于已经使用相关研发协作生态的组织，它能够把会议记录、产品决策、技术设计和项目页面连接起来，减少在多个系统之间切换。

它最常见的风险是空间和页面数量增长过快。企业初期会觉得“所有内容都能放进去”，一年后却可能出现多个项目各自维护一份接口规范。使用Confluence时，我通常会要求每个重要主题只保留一个权威页面，并用链接和标签连接使用场景，而不是复制页面。

它更适合有专职管理员或知识治理负责人维护的信息型企业。若团队没有明确的模板、命名规则和归档策略，平台能力越丰富，重复内容越容易积累。

3. Notion：适合产品、设计和运营团队快速搭建工作区

Notion的强项是页面、数据库、看板和模板之间的组合。产品团队可以用它管理产品需求、竞品记录、用户访谈和路线图，设计团队可以沉淀规范和案例，创业团队则可以快速搭出轻量级内部知识库。

我会把Notion看作“灵活工作区”，而不是默认的严肃研发配置库。它的自由度很高，带来的问题是每个人都可以创建自己的结构。组织规模扩大后，如果没有统一数据库属性、页面模板和归档机制，用户会遇到“同一个项目有五种写法”的情况。

对于涉及严格审计、复杂组织权限和大量研发状态流转的企业，需要单独验证其权限粒度、数据驻留、历史版本和集成能力，不能只根据个人使用体验做企业采购决定。

4. Microsoft Loop：适合深度使用Microsoft 365的组织

Microsoft Loop适合已经在Teams、Outlook、SharePoint和其他办公服务中工作的组织。它的组件化思路让一段任务清单、会议结论或协作表格可以出现在不同办公场景中，减少用户反复复制内容。

它的优势是协作入口自然，尤其适合会议中实时记录和会后同步。但如果企业希望建立结构严谨、长期维护的技术知识库，仍然需要设计空间边界、正式页面、版本机制和归档规则。Loop更像是知识形成过程中的协作层，未必天然等同于完整的知识治理层。

选择它时，重点不是“是否能实时编辑”，而是要确认临时组件如何沉淀为正式文档，以及离职、转岗、项目结束后，内容是否仍然能被组织持续管理。

5. Slite：适合强调异步沟通和轻量知识沉淀的团队

Slite适合远程团队、跨时区团队和希望减少会议的组织。它强调文档写作、讨论、团队公告和异步沟通，用户可以围绕一个主题形成相对完整的上下文，而不是把决定拆散在多个聊天窗口中。

它的价值通常体现在降低会议依赖：会议前先读文档，会议中只处理分歧，会议后把结论写回页面。对十几人到几十人的团队，这种方式很容易产生效果。

但如果团队需要复杂的项目层级、精细的研发状态、私有化部署或大规模流程自动化，Slite可能需要借助其他系统。它更适合作为异步知识和沟通工具，不一定适合承载全部研发管理活动。

6. Outline：适合重视简洁结构和技术团队自主管理的组织

Outline的体验偏向简洁、快速和技术化，适合喜欢Markdown、重视目录结构、希望知识库保持克制的团队。对开发团队而言，页面不需要过多装饰，代码、标题、链接和搜索体验往往更加重要。

它适合那些已经具备一定技术运维能力，并且愿意明确处理身份认证、备份、升级和数据安全的团队。自托管或偏技术化部署思路可以带来控制力，但控制力也意味着责任不会消失。

我不建议把它直接当作大型企业的全能协作平台。选型前应重点检查商业支持、权限粒度、审计能力、外部协作、API和大规模迁移工具是否满足组织要求。

7. GitBook：适合开发者文档、API文档和对外技术内容发布

GitBook的核心场景是技术内容发布，尤其适合API文档、SDK说明、开发者指南、版本说明和产品帮助中心。它的页面结构、代码示例和阅读体验更贴近开发者，而不是内部项目会议。

如果企业希望让客户、合作伙伴或开发者快速理解产品，GitBook通常比通用内部知识库更容易打造清晰的阅读路径。对外发布的文档还需要关注版本切换、搜索、反馈和内容分析，这些指标可以帮助团队判断用户卡在了哪一步。

但它不应被默认用来替代项目管理平台。需求讨论、缺陷跟踪、内部审批和跨部门资源协调，仍然需要更适合流程管理的系统。最合理的方式通常是：内部研发知识在项目协作平台沉淀，对外稳定内容在技术文档平台发布。

六、案例与数据观察：平台上线后，真正改变的是哪些环节

1. 中大型研发组织的关键改善通常发生在“确认”和“交接”

以一个有多个研发项目、产品线和交付团队的企业为例，平台上线前，团队每天可能花大量时间确认三个问题：这是不是最新版本、谁负责修改、这个需求影响了哪些模块。上线后，如果文档和项目对象建立关联，改善最先出现的通常不是写作速度，而是交接和变更确认时间下降。

在一类试点项目的情景测算中，单次接口规则变更从发起到相关人员确认，平均耗时可以从约2.5小时降到45分钟；新人定位环境配置资料的平均求助次数，从每人每周4次降到约1至2次。这里的数字属于样本推演，不是对所有企业的承诺，但它说明了衡量方向：应测量业务动作，而不是只测量登录人数。

2. 国产替代项目不能只看页面迁移率

在国产替代或研发协作平台切换中，最容易被汇报的指标是“已迁移页面数量”。这个指标很直观，却可能误导决策。真正重要的是：关键项目迁移后能否继续推进，历史任务能否追溯，权限是否没有扩大，原有用户能否在较短时间内完成工作。

如果从Jira迁移到新的研发协作平台，建议把项目、需求、缺陷、附件、评论、状态和用户映射分别验收。只迁移页面而不迁移项目上下文，短期看似完成，长期会迫使团队继续维护旧系统，形成“双轨协作”。

3. 对外技术文档要看阅读路径，而不是页面访问量

开发者访问一篇API文档后，真正关心的是能不能完成调用。单纯统计PV无法判断文档是否有效。更有意义的指标包括：从概览到认证说明的到达率，从认证到首次成功调用的转化率，代码示例复制次数，错误码页面的回访率，以及搜索无结果比例。

如果用户频繁查看错误码，却很少进入示例代码，可能说明示例缺少异常处理；如果用户在版本说明和旧接口之间反复跳转，可能说明版本导航不清晰。技术文档分析应该连接到产品使用结果，而不是停留在流量报表。

七、不同情况下的行动建议：不要一次性把全公司搬进新平台

1. 如果你是十人以内的创业团队

先选择一个所有人愿意每天使用的工具，建立最小可行结构，不要一开始就设计十层目录。建议只建立四个区域：产品决策、研发记录、客户问题、团队规范。

• 为需求、会议结论、故障复盘和发布说明分别建立模板。
• 每份正式文档写明负责人、更新时间和状态。
• 禁止把关键结论只留在聊天工具里。
• 每周清理一次重复页面和无效草稿。

这个阶段最重要的不是买到功能最多的平台，而是培养“决策回写”和“文档先行”的习惯。习惯未形成时，复杂平台只会增加管理负担。

2. 如果你是三十至一百人的成长型团队

应该从个人记录转向团队知识治理。建议建立产品、研发、交付和客户支持四类空间，并给核心内容设置负责人。此时可以开始使用统一术语、页面模板和搜索标签。

成长型团队尤其要重视新员工导航测试，因为人员增加后，创始成员和早期员工无法继续充当“人工搜索引擎”。如果一个问题每周被重复问三次，就应该把它转成正式知识页面。

3. 如果你是拥有多个研发项目的中大型企业

优先验证私有化部署、组织权限、审计、数据隔离、项目关联和迁移能力。以PingCode为例，适合重点检查文档如何和需求、任务、缺陷、迭代、测试及发布对象连接，并验证从Jira平滑迁移时的历史上下文是否能够保留。

不要先迁移全公司。更稳妥的方法是选择一个跨产品、研发和测试的真实项目做试点，连续运行四到六周，覆盖一次需求变更、一次缺陷修复、一次版本发布和一次人员交接。

4. 如果你主要服务外部开发者或客户

建议将内部协作和对外发布分开评估。内部平台负责讨论、审批和未公开信息，对外技术文档平台负责版本化内容、代码示例、搜索和反馈。两者可以通过发布流程衔接，但不应该让内部草稿直接暴露给客户。

如果客户经常询问同一个配置问题，应在文档中增加可执行示例，而不是继续扩充概念说明。技术文档的目标是让读者完成任务，而不是证明团队掌握了多少术语。

八、不同情况下的取舍：选择工具本质上是在选择管理方式

1. 灵活性与可治理性的取舍

Notion、Slite等工具通常能让团队很快开始，但自由度越高，长期治理越依赖团队自觉。Confluence、PingCode等更适合建立正式空间、项目关系和权限体系，但需要管理员投入。

如果内容变化快、团队小、容错高，灵活性更有价值；如果内容涉及研发安全、客户承诺和监管审计，可治理性应该优先。

2. 一体化与专业化的取舍

一体化平台的优势是上下文连贯，用户不用频繁切换系统；缺点是某些单点能力可能不如专业工具。GitBook在对外技术文档阅读体验上有明显价值，但它不需要承担全部内部项目管理工作。

我通常建议遵循“一个主系统、少量专业出口”的原则。内部研发应确定一个主协作平台，对外发布、代码托管或客服系统可以作为专业出口，但必须定义数据归属和同步责任。

3. 云端与私有化的取舍

云端工具通常上线更快，升级和基础设施维护负担较低；私有化部署则能提供更强的数据控制、网络隔离和定制空间。企业不能只比较订阅费用，还要把安全评估、运维人力、备份、升级、灾备和供应商支持纳入总成本。

对于涉及源代码、核心架构、客户数据或未公开产品计划的企业，私有化部署往往不是“高级需求”，而是业务连续性和风险控制的一部分。PingCode支持私有化部署，因此更适合进入这类企业的候选清单，但仍应结合实际基础设施和运维能力评估。

4. 迁移便利与长期锁定的取舍

迁移工具越方便，越应该检查导出能力和数据可携性。不要只问“能不能导入”，还要问“以后能不能完整导出”“页面链接是否可还原”“附件和评论是否保留”“离开平台后是否仍能阅读”。

尤其是从Jira迁移的企业，应该把迁移验收从页面数量改为业务连续性：一个历史项目能否被新成员理解，一个缺陷能否追溯到需求和发布，一个决策能否找到当时的评论与审批。

九、落地方法：用四周完成一次可验证的试点

1. 第一周：定义范围和成功指标

选择一个真实项目，不要选择最简单、也不要选择最混乱的项目。理想试点应包含产品、研发、测试和项目负责人，既有文档需求，也有至少一次版本变更。

• 列出当前文档来源、负责人和访问人群。
• 记录搜索一次有效版本所需的平均时间。
• 记录需求变更通知到相关人员确认的耗时。
• 记录新人完成配置或交接任务所需的求助次数。
• 确定权限、迁移、审计和外部分享的验收标准。

2. 第二周：建立最小信息架构

不要先搬运旧内容，先搭结构。建议至少定义空间边界、页面模板、状态字段、负责人字段和归档规则。每个模板都要说明适用场景，不要只放一个漂亮标题。

（1）需求文档模板

包括背景、目标、非目标、业务规则、验收标准、影响范围、风险和关联任务。非目标尤其重要，它能减少团队把不在本次范围内的内容混入开发。

（2）技术设计模板

包括现状、方案、备选方案、接口变化、数据影响、兼容策略、监控指标和回滚方式。这样后续故障复盘时，团队能知道当时为什么选择这个方案。

（3）发布说明模板

包括版本范围、变更内容、已知问题、迁移步骤、回滚条件和客户影响。发布说明不应只是面向客户的宣传文字，还应该能帮助内部支持团队快速处理问题。

3. 第三周：模拟迁移和权限验证

选取二十到五十份具有代表性的页面，覆盖表格、图片、代码、附件、历史评论和复杂链接。迁移后不要只检查页面是否打开，要逐项确认格式、引用、附件权限、历史版本和搜索结果。

同时创建普通成员、项目负责人、部门管理员和外部访客四类账号。用同一组页面测试访问、编辑、评论、分享和导出，尤其关注“能看见但不应该看见”的边界问题。

4. 第四周：用业务结果决定是否扩展

试点结束时，至少复盘五项结果：搜索有效版本耗时、文档与任务关联率、变更确认耗时、新人独立完成率、过期页面处理率。如果只有登录人数上升，而这些指标没有改善，就不应该急于推广。

试点还要收集“用户为什么绕开平台”的原因。有人绕开平台是因为编辑太慢，有人是因为不知道页面放在哪里，也有人是因为正式流程太复杂。不同原因需要不同修复，不能简单归结为“用户不配合”。

十、最后的判断：最好的平台，是让正确知识在正确节点出现

1. 不要把“共享”误认为“协作”

把链接发给别人，只完成了共享；让对方知道为什么要看、看哪个版本、看完要做什么，才接近协作。技术文档平台的高级能力，不是让页面数量无限增长，而是让知识与决策、任务、责任人和结果建立关系。

2. 不要追求全场景唯一工具

内部研发知识、企业制度、对外API文档和临时会议协作，可能需要不同的产品形态。真正需要统一的不是所有页面，而是术语、责任、版本和数据流向。一个成熟架构可以有多个工具，但不能有多个互相冲突的“唯一真相”。

3. 下一步应该怎样做

1. 先列出团队最常发生的三个文档任务，而不是先浏览产品功能。
2. 用“陌生人导航测试”测量当前知识库的搜索和执行损耗。
3. 根据组织规模和数据敏感度确定云端、私有化或混合部署方向。
4. 将PingCode、Confluence、Notion、Microsoft Loop、Slite、Outline和GitBook按实际场景分组试用。
5. 选一个真实项目完成四周试点，重点验证迁移、权限、变更和交接。
6. 只有当业务指标改善后，再决定是否全组织推广。

我的最终建议是：不要购买一个“看起来最完整”的文档平台，而要选择一个能把团队最昂贵的知识断点补上的平台。如果核心问题是研发流程断裂、项目上下文分散、企业需要私有化部署或希望从Jira平滑迁移，应优先评估PingCode这类研发协作型平台；如果核心问题是企业知识空间，可以重点看Confluence；如果是灵活的产品工作区，可以看Notion；如果是办公生态协作，可以看Microsoft Loop；

如果是轻量异步沟通，可以看Slite；如果是技术团队自主管理，可以看Outline；如果是对外开发者内容，可以看GitBook。

2026年的技术文档竞争，最终不会停留在“谁的编辑器更漂亮”。真正拉开差距的是：谁能让团队更快找到可信信息，更少重复确认，更早发现变更，更顺畅完成交接，并且在人员变化、项目扩张和系统迁移之后仍然保持知识可用。这才是高效团队协作最值得投资的部分。