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

技术文档共享平台最容易被低估的成本，不是每人每月的订阅费，而是工程师找不到“当前有效答案”时反复确认、重复实现和误用旧接口的时间。挑选 2026 年的工具，我不会先问谁的功能最多，而会先问三个问题：文档能否被目标读者快速找到，修改能否追溯到责任人与版本，内容能否进入团队已有的开发流程。按这三个问题评估，下面七款工具分别适合不同的团队结构，没有一款能包办所有场景。

一、先讲结论：选平台，不如先选文档运行方式

1. 七款工具各自擅长什么

如果团队把技术文档视为产品的一部分，例如需要发布 API 参考、开发者指南或面向客户的集成说明，我会优先评估 GitBook 和 ReadMe。如果文档主要用于研发协作、方案沉淀和项目决策，Confluence 通常更容易接入成熟的企业协作流程。

如果团队更看重灵活编辑、轻量知识库和数据库式组织，可以评估 Notion；如果企业已经深度使用 Microsoft 365 或 Google Workspace，则 SharePoint 或 Google Drive 往往能减少身份、权限和协作上的额外成本。Slab 更适合希望把内部知识库做得简单、易搜索的团队。

这张表不是功能排名，而是用途筛选。七款产品所处的位置并不完全相同：ReadMe 偏 API 开发者体验，SharePoint 偏企业内容治理，Google Drive 偏日常协作与文件共享。若把它们放进同一套“功能数量”打分表里，结论往往会误导采购。

2. 我的核心判断：文档平台是检索与变更的基础设施

我建议把技术文档平台看成一条“内容进入，审核，发布，检索，反馈，更新”的工作链，而不是一个可以放文件的地方。文档只有被目标读者找到、被正确理解，并且在系统变化后及时更新，才算真正完成了协作任务。

所以，选型时我更关注两类成本：一类是读者寻找答案的成本，另一类是作者维护内容的成本。只降低作者写作门槛，可能换来更多页面和更严重的重复；只强调审批和权限，又可能让更新慢到工程师转去问同事。

3. 对 2026 年选型的特别提醒

产品功能、套餐和集成能力会迭代，尤其是搜索、AI 辅助、权限管理和发布能力。本文不把某个时点的价格、套餐上限或 AI 功能当成长期承诺；采购前应以产品官方定价页、帮助中心、企业安全说明和实际试用结果为准。

我更建议把试用变成一项可复现的任务：拿同一批文档、同一组读者、同一套问题，分别放进候选平台测试。与其根据演示环境里最漂亮的页面下结论，不如观察新员工能否在十分钟内找到正确的部署说明。

二、背景与真实场景：文档问题往往不是“没有写”

1. 文档散落在不同系统，才是最常见的起点

在中小型研发组织里，技术知识通常不会从一个干净的空白页面开始。API 说明可能在代码仓库，部署步骤在协作文档，故障处理经验在聊天记录，架构决定则留在会议纪要。每个局部都“有人知道”，但组织缺少可靠的入口。

一个典型场景是：值班工程师收到告警，需要判断某个服务最近是否改过超时设置。他能找到一份部署文档，却不知道这是去年版本；能找到代码提交，却不确定是否包含生产环境的例外配置。平台若只提供编辑器，不提供版本线索、负责人和有效状态，问题仍然存在。

2. 同一份技术文档，读者任务可能完全不同

新员工要的是“从哪里开始、先做什么”；开发者要的是参数定义、示例和错误边界；值班人员要的是能在压力下快速执行的操作步骤；管理者要的是风险、依赖与决策背景。一个平台可以支持多种内容，但内容结构不能把所有任务都压成一篇长文。

我会先把文档按读者任务分为四类：解释背景的概念文档、指导操作的流程文档、供机器或开发者查阅的参考文档，以及记录取舍的决策文档。分类的价值在于让团队讨论“怎么写、谁维护、多久复查”，而不只是讨论“放在哪个空间”。

3. 用“找到答案的路径”检查现有问题

选型前可以抽取 10 至 20 个高频问题，不要只统计页面数。例如“新服务怎样接入监控”“客户端超时默认值是多少”“生产回滚谁负责”。让目标读者独立完成搜索，记录是否找到、花了多久、答案是否适用，以及是否需要再问人。

这不是严谨的行业基准，而是团队自己的起点测量。样本不必追求大，关键是覆盖不同角色与问题类型。页面浏览量高不一定代表知识有用；有些页面只是因为搜索结果不清楚，读者不得不反复打开多个版本。

4. 文档价值要与工作任务相连

我不会用“团队有多少篇文档”作为主要成功指标，因为大量低价值页面也能让数字看起来增长。更有决策意义的是：关键问题的自助解决比例、过期内容占比、从代码变更到文档更新的间隔，以及读者搜索后是否继续向同事求助。

团队可以从最常见的三类损耗着手：重复提问、重复排查、依据旧说明执行。若这些问题几乎没有发生，未必需要马上更换平台；若它们反复发生，再去判断根因是搜索、权限、结构、责任人还是更新流程。

三、七款平台逐一拆解：不要用一种尺子量所有产品

1. Confluence：适合内部协作体系已经成形的团队

Confluence 的评估重点通常不是“能不能写页面”，而是空间如何划分、页面如何组织、权限如何治理，以及怎样与团队现有工作流关联。对已经有稳定研发、运维和产品协作节奏的组织，空间和页面层级能帮助不同团队建立相对清晰的知识边界。

它适合架构方案、技术决策记录、运行手册、项目复盘等多人共同维护的材料。如果团队的关键诉求是发布漂亮的外部开发者门户，或者从 OpenAPI 定义直接生成高质量参考文档，我会另外评估面向产品文档或 API 文档的专用工具。

实际试用时，我会检查三件事：新员工是否能从统一入口到达当前有效页面；页面负责人和审阅周期是否容易展示；跨空间搜索是否能把旧版本、草稿与正式说明区分开。若这三项需要大量人工约定，工具本身的层级优势可能被维护负担抵消。

2. GitBook：适合把技术内容作为发布产品来维护

GitBook 更适合需要将技术内容组织成易浏览文档站点的团队，尤其是产品指南、开发者指南和面向客户的技术说明。评估时要观察内容编写、导航结构、预览、发布和版本管理是否符合作者的实际工作方式，而不仅仅是看最终站点是否美观。

对工程团队，我会重点验证代码仓库协作方式、变更审阅流程、文档版本与软件版本的对应关系。若产品有多个长期支持版本，用户很可能需要阅读与自己所用版本匹配的说明；版本入口若不明确，页面再漂亮也可能让人按错步骤。

它不一定是所有内部讨论的最佳归宿。比如架构争议的来龙去脉、临时项目记录和跨部门协作内容，可能仍需放在团队日常协作空间。采用多个工具并非失败，前提是团队定义好内容的权威来源和相互链接方式。

3. ReadMe：面向 API 使用者，而非所有知识类型

当核心交付物是 API，ReadMe 值得进入候选名单。它的评估应围绕开发者完成任务的路径展开：能不能快速找到认证说明、端点参数、请求示例、响应结构、错误处理和变更信息。文档是否像产品的一部分，比页面是否能承载任意内容更重要。

我会拿一个真实 API 场景做试验：让未参与项目的开发者从空白状态完成认证、调用一个常见接口，并理解失败响应。记录他们在哪一步停下来，是术语不清、示例不可运行、必填参数缺失，还是版本不匹配。这类测试比让内部作者评价编辑器更接近目标用户。

若团队还需要大量内部架构材料、招聘入职流程和跨部门会议纪要，ReadMe 未必适合承担全部知识管理。把 API 门户和内部知识库分开管理是合理选项，但需要明确哪些事实在两处重复，如何同步，以及发生冲突时哪一处为准。

4. Notion：灵活度高，必须用规则换取长期可检索性

Notion 的优势是编辑和组织内容较为灵活，团队可以用页面、数据库和模板快速搭建知识空间。对正在探索内容结构、团队规模尚不大或跨职能协作较频繁的组织，这种灵活性可以降低启动成本。

风险也来自同一个地方：任何人都能快速建页面，不代表组织能持续分辨草稿、项目记录和正式规范。页面模板、命名约定、归档规则和内容负责人若长期缺位，搜索结果可能越来越像一个未经整理的共享盘。

我的建议是不要从“全员开放自由编辑”开始，而是先设立少量有明确用途的入口，例如“当前操作手册”“技术决策”“团队项目资料”。新页面创建时标明读者、负责人、适用范围和复查日期，避免过度设计几十层目录。

5. SharePoint：强治理需求下，重点评估管理成本

对于已经深度采用 Microsoft 365、身份体系和企业协作流程的组织，SharePoint 的价值不只是文件存放，而是可以纳入企业级内容治理与访问管理。涉及受控资料、组织级知识门户和权限边界时，应该把它放在真实的企业架构中评估，而不是拿个人免费空间体验代替。

重点检查站点结构是否与实际业务部门和读者群匹配、权限继承是否可理解、离职与岗位变更后访问权如何处理，以及用户能否在大量资料中定位权威版本。复杂的权限能力是一种治理能力，也可能成为配置和排错的成本。

如果团队规模较小，只是想快速维护几篇工程说明，完整搭建企业内容门户可能过重。反过来，如果企业已经在 Microsoft 生态中做身份和合规管理，另起一套身份与权限体系也可能带来重复管理。取舍要看整体架构，不应只看页面体验。

6. Google Drive：协作顺手，但共享盘不自动等于知识库

Google Drive 与 Workspace 的共同编辑和文件共享体验，适合团队日常协作、会议材料和轻量技术说明。对已经使用该生态的组织，成员不需要为了打开文档再适应一套新编辑习惯，启动成本通常较低。

但“文档能共享”与“知识能被发现”是两件事。文件名相似、多个副本并存、链接散落在聊天记录里，都会增加读者确认版本的成本。若把 Drive 作为正式知识入口，至少要明确文件命名、目录负责人、共享范围、版本状态和旧内容归档方式。

它适合以协作文件为主的场景；若需求是公开发布、维护多版本开发者文档或建立完整的 API 参考体验，就应比较专用文档平台。工具的边界不代表能力不足，而是任务设计不同。

7. Slab：适合重视内部知识入口简洁度的团队

Slab 可以作为内部知识库候选，特别是团队希望把常见问题、流程说明和组织知识集中起来，并减少复杂门户搭建时的管理负担。试用时不要只看内容创建速度，还要验证真实用户如何搜索、浏览和判断页面是否有效。

我会用跨团队问题测试它：问题的答案由另一个团队维护，提问者能否在没有人带路的情况下找到页面？搜索是否能理解团队常用简称？旧页面是否会与新规范同时出现？这些场景能暴露出知识库是否真正支持日常工作。

采购前还应核实与现有身份、代码仓库、项目协作及消息工具的集成方式，以及所需能力是否包含在目标套餐中。某项集成“存在”不代表它能满足团队的同步、权限和审计要求。

四、常见误区：工具上线后仍然找不到文档的原因

1. 误区一：页面越多，知识沉淀越好

页面数量只能说明内容被创建过，不能说明它仍然正确、可发现、可执行。大量会议记录、草稿和重复页面会稀释搜索结果，甚至使旧做法看起来与新规范同样可信。

我会为重要文档添加最小必要的治理信息：内容类型、负责人、适用范围、更新时间或复查节点、权威状态。不是每一页都需要审批，但影响生产操作、安全或接口兼容性的页面，应该有比普通讨论笔记更明确的维护要求。

2. 误区二：上 AI 搜索就不用治理内容

生成式搜索可以降低读者提出问题和浏览资料的门槛，但不能把过时内容自动变成可靠事实。若系统同时检索到两份相互矛盾的操作步骤，回答写得再流畅，也可能放大错误信息的影响。

评估 AI 功能时，我会追问答案是否展示来源、能否区分权限范围、如何处理相互冲突的页面、内容更新后多久生效，以及管理员能否审计使用情况。对关键操作，仍要让用户能回到原文核对，而不是把生成式回答当作唯一依据。

3. 误区三：把搜索框存在当作搜索可用

搜索质量不仅是能否搜到关键词，还包括是否能找到正确版本、是否理解团队术语、结果是否按内容权威性排序，以及用户能否从结果摘要判断要不要点开。标题写成“流程说明”通常不如写成“生产环境如何回滚某服务”更能帮助读者。

试点时可以准备一组固定问题，覆盖精确词、缩写、自然语言问法和旧术语。让目标读者现场检索并记录前几个结果，特别观察第一个结果是否可用。一次体验不能证明长期表现，但同一组问题可用于候选工具间的公平比较。

4. 误区四：权限越严，安全性就越高

权限控制需要与内容风险匹配。若普通技术手册也要层层申请，工程师可能把内容复制到权限更宽松的地方；若敏感架构材料完全开放，又会产生不必要的信息暴露。

我会先按内容风险分类，再定义访问边界。例如公开产品说明、组织内通用操作手册、限制性系统细节和敏感应急材料，适用的共享范围不应相同。工具能否支持边界只是起点，权限变更、离职回收和外部共享审计同样重要。

5. 误区五：只看作者体验，不让读者参与试用

选型会议通常由文档作者、管理员或采购人员主导，但技术文档平台的成败往往取决于读者能不能在具体任务中找到答案。作者喜欢的编辑器，并不一定是新员工和值班工程师最容易使用的入口。

至少让三类角色参与试用：内容作者负责检查编辑与审阅，知识管理员负责检查权限和维护，目标读者负责完成实际任务。若团队只让管理员演示，容易把“后台配置成功”误认为“前台使用成功”。

五、专业判断逻辑：用一套可复现的方法比较候选工具

1. 先划定“权威来源”，再谈迁移

迁移前先做内容盘点，至少区分仍然有效的规范、仍可复用的说明、仅作历史参考的资料和可以删除的内容。若不做分层就把所有文件批量导入新平台，旧问题只会换一个界面继续存在。

对每种关键内容，明确唯一权威来源。例如，API 参数以版本化参考文档为准，部署操作以受控运行手册为准，决策背景以决策记录为准。其他页面可以链接到权威来源，但不要复制整段内容后各自维护。

2. 让候选工具完成同一组任务

公平比较不应该是让供应商各自演示最擅长的功能，而是给每个平台相同的测试材料与目标任务。这样才能分清差异来自产品能力、内容结构还是使用者熟悉程度。

1. 选取 10 至 20 个有真实使用价值的问题，覆盖新人入职、日常开发、API 接入和故障处理。
2. 准备相同的源材料，包含一份有效说明、一份旧版本、一份含歧义的记录和一份需要权限控制的内容。
3. 让不同角色分别执行搜索、编辑、审阅、发布和撤回任务，避免只由管理员操作。
4. 记录每个任务是否完成、耗时、错误次数、是否需要求助，以及最后引用的是哪个页面。
5. 试用结束后检查内容导出、链接稳定性、权限审计、版本管理和退出迁移条件。

3. 用权重评分，而不是让一个功能决定全部

下表是一套可按组织情况调整的建议基准，不是行业标准。对外部开发者门户，发布体验和版本管理权重应提高；对受控企业知识库，权限、审计和身份集成应提高；对小团队，可以降低复杂治理能力的权重，优先降低维护门槛。

总分有用，但不能掩盖硬性限制。如果产品无法满足组织必须遵守的身份管理、数据驻留或审计要求，即使其他维度得分很高，也不应靠平均分把风险“抵消”。先设淘汰条件，再对通过的产品评分，决策会更稳健。

4. 计算总拥有成本，而非只看订阅价格

工具成本至少包含席位或套餐费用、配置和迁移投入、管理员维护时间、作者培训、内容清理，以及未来退出时的导出与重建成本。订阅价格通常最容易拿到，却未必是最大的长期支出。

例如，一款工具每月费用更低，但需要团队自行维护大量页面规范、权限映射和发布脚本，最终可能把节省的预算变成工程师的管理工时。反过来，价格较高的平台若能显著减少重复答疑和错误执行，仍可能具备合理的总拥有成本。关键是把工时记入账本。

5. 关注“内容和代码是否一致”这一条变更链

技术文档的一个独特风险是产品持续变化，而内容并不会自动同步。接口改了、部署参数改了、功能下线了，如果文档更新依靠某个人事后想起来，时间差就会形成错误使用窗口。

我会让研发团队把文档更新纳入变更流程：哪些代码变更必须同步文档，哪些修改需要技术审阅，文档更新失败时如何提醒，谁负责版本不一致的修复。平台能否支持代码仓库、审阅和发布流程，是重要条件，但责任规则仍需团队建立。

六、具体案例与数据观察：先做小范围试点，避免把模拟数字当成果

1. 一个可复用的 45 人研发团队试点场景

下面给出的是情景模拟，不是某家公司的真实经营数据。假设一个 45 人的 SaaS 研发团队，有 3 个产品小组、1 个平台工程小组和轮值运维安排。资料分散在协作页面、代码仓库、共享文件和聊天记录中，团队想在六周内验证新平台是否值得推广。

我会先选两个高频、风险可控的内容域：新服务接入指南与常见故障处理手册。前者检验入职和开发任务的可复用性，后者检验高压场景中的检索与执行能力。先不迁移全部项目历史记录，避免把试点变成清理多年资料的无限工程。

2. 试点如何执行

1. 第一周建立 15 个测试问题，邀请 8 至 12 名非内容作者参与基线检索。
2. 第二周整理 30 至 50 篇相关页面，为每页标注负责人、读者、适用范围和有效状态。
3. 第三至四周在两款候选平台中分别搭建同一套内容入口和导航结构。
4. 第五周重复检索任务，并测试修改、审阅、发布、权限变更及旧页面归档。
5. 第六周复盘用户反馈、人工求助次数、维护工时和关键风险，再决定扩展或停止。

试点数据要区分“可用性变好”和“内容被迁移了”。如果只是把页面从一个系统复制到另一个系统，搜索耗时可能暂时下降，却没有证据证明责任机制、版本准确性和长期维护真的改善。

3. 一组演示数据应该怎样解读

下图中的数字是为说明测量方法而构造的情景模拟：假定同一批读者在试点前后完成相同问题任务。它不代表任何平台的真实提升，也不适合直接当成投资回报预测。团队应记录自己的基线，并用相同任务重复测试。

4. 观察结果时避免三种过度归因

第一，不要把短期培训效果误认为平台长期优势。试点初期，作者和读者都会受到集中培训帮助；几周后再测一次，才能观察用户能否独立使用。

第二，不要把页面整理效果全部归因于新工具。如果试点同时进行了去重、改标题、补责任人和清理旧内容，结果改善可能主要来自内容治理，而不是产品本身。评估报告应记录同步发生的改变。

第三，不要只看平均数。少数熟悉系统的用户可能显著拉低平均耗时，掩盖新员工或跨团队读者的困难。可以同时报告中位耗时、任务完成率和最常见失败原因，解释会更完整。

5. 权威资料与数据边界

本文对产品定位的描述以各产品官方产品页、帮助中心及公开功能说明为核对入口，包括 Atlassian Confluence 文档、GitBook 文档中心、ReadMe 产品与帮助资料、Notion 帮助中心、Microsoft SharePoint 官方说明、Google Workspace 帮助中心和 Slab 官方产品说明。各产品功能与套餐可能变化，采购前应核对当时的正式资料。

文中的评分、时间和团队试点数字均已明确标注为定性评估或情景模拟，并非第三方性能测试、行业平均值或真实客户案例。若要用于预算申请或商业论证，应以组织自己的检索实验、工时记录、安全审查和实际报价替换示例数值。

七、不同情况下的行动建议与取舍

1. 如果你要发布面向外部的技术文档

优先比较 GitBook 与 ReadMe，选择依据不是品牌偏好，而是内容中心任务：前者更适合广义产品指南和文档站点评估，后者值得围绕 API 开发者门户做深入测试。若主要材料是接口参考、请求示例和开发者集成步骤，应让目标开发者亲自完成调用任务。

不要忽略版本管理、搜索引擎收录、访问统计、内容更新流程和域名迁移。外部文档的读者可能不知道内部产品术语，标题和导航要按用户问题组织，而不是按组织部门组织。采购前也要验证内容是否容易导出，避免门户成为难以退出的单点依赖。

2. 如果你要建设内部研发知识库

先比较 Confluence、Notion 和 Slab，再根据团队已有工具栈考虑 SharePoint 或 Google Drive。对于已经形成较强协作规范的团队，结构与流程集成值得优先评估；对于希望轻量启动的组织，则应把维护规则简单化，避免先搭建庞大门户再等待内容填充。

最重要的取舍是自由与治理。自由编辑能提升启动速度，但需要负责人、命名、有效状态和归档规则；治理越严格，内容越容易保持秩序，但作者更新成本也会上升。理想状态不是规则最多，而是高风险页面严格、普通知识轻量。

3. 如果企业已经有成熟办公生态

已有 Microsoft 365 的组织，应把 SharePoint 放进现有身份、权限、审计和内容管理设计中评估；已有 Google Workspace 的团队，可以先检查 Drive 是否通过目录治理和统一入口解决了主要问题。不要为了“技术文档专用”而自动引入新平台，除非它确实补足了现有生态的检索、版本或发布短板。

但也不要因为全员已经会用办公套件，就默认它足以承载开发者门户、版本化 API 文档或高风险运行手册。生态集成降低协作成本，却不能替代内容结构设计。正确问题是“现有工具是否能可靠完成这类读者任务”，不是“大家是否已经有账号”。

4. 如果团队规模小、专职管理员有限

优先减少系统数量和管理动作。可以先选择现有工具，搭一个小型权威入口，建立少量模板和复查规则，再用真实搜索任务验证是否达到要求。团队不需要在第一天就把所有历史知识搬迁，也不需要为极少发生的场景设计复杂审批。

小团队需要尤其注意“工具简单、规则缺失”造成的隐性债务。每篇重要文档仍应有负责人和适用范围；当团队成员增加、项目分叉或外部文档需求增长时，再评估是否拆出专用平台。

5. 如果涉及敏感内容、审计或严格权限

把安全与合规设成硬性门槛，而不是评分表上的普通加分项。要求供应商提供适用的安全、数据处理和审计资料，并由内部安全、法务或合规角色核对。具体控制能力需根据套餐和合同确认，不能仅凭产品宣传页推断。

还要测试生命周期场景：员工离职后访问如何收回，外部协作者如何到期，权限变更能否追溯，导出文件是否会绕开平台权限，链接是否可能被转发。一个权限按钮并不能回答这些运营问题。

6. 如果预算有限，怎样判断要不要迁移

如果当前主要问题只是目录混乱，先做内容清理和搜索入口改造，往往比立刻采购新平台更划算。如果反复出现权限无法治理、外部发布困难、版本对应混乱或系统集成障碍，才有更充分的迁移理由。

做迁移决策时，将成本拆成一次性和持续性：一次性包括盘点、清理、迁移、链接修复和培训；持续性包括订阅、管理员时间、作者维护和审计。另设退出方案，验证未来能否批量导出页面、附件、结构和关键元数据。

7. 候选产品接近时，优先选更容易退出的方案

当两款工具都通过安全与任务测试，且使用体验差异不大时，我会把可迁移性作为重要的决胜因素。内容能否批量导出、链接是否可重定向、页面层级和元数据能否保留、权限信息能否审计，决定未来变化时的转移成本。

还要区分“有导出按钮”和“可恢复成可用知识库”。试导出少量包含图片、表格、代码片段和附件的复杂页面，再确认内容结构是否保留。只导出纯文本，可能让团队失去导航关系、版本线索和内容责任信息。

八、结语：先修复知识链路，再决定买哪款工具

1. 我的独特判断

技术文档平台的真正竞争，不是页面编辑器之间的竞争，而是“谁能让正确答案在正确时间到达正确的人”。搜索快但版本错，知识库仍然危险；内容准确但读者找不到，知识仍然没有进入工作流；文档站点漂亮但作者不更新，也只是更好看的过期资料。

因此，我不会把“功能最多”当成最佳答案。最适合的工具，是能够匹配主要读者任务、接住团队变更流程，并且让维护成本长期可承受的工具。七款平台的定位不同，先明确任务，再选择候选，比从排行榜倒推需求更可靠。

2. 下一步怎么做

• 抽取 10 至 20 个高频问题，测量当前找到正确答案所需的时间和人工求助比例。
• 把内容分成内部知识库、产品文档、API 参考、受控内容等类别，明确各自的权威来源。
• 按团队任务筛出两到三款候选工具，不要让七款产品都进入同一轮深度试用。
• 用相同样本和相同任务进行试点，同时记录检索、更新、权限、迁移和维护成本。
• 在推广前确定内容负责人、过期处理方式、数据导出方案和停止试点的条件。

如果只能做一件事，我建议先找出团队最近一次“因为文档找不到或版本不清而多花时间”的真实事件，把相关读者、内容、系统和更新节点画出来。这个小型复盘通常比看十场产品演示更快告诉你：团队缺的是新平台，还是一套能让知识持续有效的工作方式。