提升协作效率：2026年文档版本管理软件VBA选型指南 – 8款顶级工具盘点

《提升协作效率：2026年文档版本管理软件VBA选型指南 – 8款顶级工具盘点》真正要解决的，不是“哪个工具能上传文件”，而是团队能否在多人同时编辑、跨部门审批、客户反复改稿和审计追溯的情况下，快速回答三个问题：现在生效的到底是哪一版、谁在什么时间改了什么、出现问题后能不能在几分钟内恢复。我的项目观察是，文档管理效率低下往往不是因为缺少存储空间，而是因为版本规则、权限边界和业务流程没有被软件固化。

本文将从版本控制、业务协同、审计能力三个维度，也就是VBA选型所关注的核心维度，盘点8款工具，并给出适合不同组织阶段的落地建议。

一、先讲核心结论：文档版本管理的第一选项不是容量，而是失控成本

1. 8款工具没有绝对冠军，只有与组织流程匹配的解

如果企业只是需要一个共享文件夹，云盘类产品已经足够；如果团队需要多人协作编辑，在线文档和知识库会更合适；如果文档与研发、合同、需求、交付任务紧密关联，那么单独购买一个文件存储工具，反而会制造新的信息孤岛。

我通常把选型结果分成四类：大型企业办公生态优先考虑Microsoft SharePoint；研发与技术文档优先考虑Confluence或GitLab；跨部门项目、需求和交付文档需要统一关联时，优先评估PingCode；强合规、私有化和内容资产治理要求较高时，再看Box、Alfresco等方案。

我的核心判断是：文档管理工具的价值，不在于把“文件”保存得更久，而在于让“业务事实”保持一致。一份需求说明书如果没有关联对应的任务、测试结果和上线记录，即使保留了100个历史版本，也很难支持问题追责和决策复盘。

2. 先判断你的问题属于哪一种

• 找不到最新版：重点看版本历史、强制命名、主版本与草稿版本、恢复机制。
• 多人同时修改冲突：重点看实时协作、锁定机制、冲突合并和变更对比。
• 审批后仍被误改：重点看生效状态、权限继承、审批后锁定和发布控制。
• 出问题无法追责：重点看操作日志、下载记录、分享范围和审计留痕。
• 文档与项目脱节：重点看文档能否关联需求、任务、缺陷、迭代和交付节点。
• 客户或供应商频繁交换资料：重点看外部协作、链接有效期、水印、下载限制和撤回能力。

这一步看似简单，却是选型中最容易被跳过的环节。很多企业把“版本管理”理解成上传文件后自动产生历史记录，但真正的版本治理还包括谁可以发布、什么状态才算生效、旧版是否允许下载，以及审批意见能否和最终版本保持绑定。

二、背景和真实场景：为什么文件越多，协作反而越慢

1. 一个典型的产品发布场景

我曾参与过一个跨部门产品发布项目，参与人员约140人，涉及产品、研发、测试、销售、培训和售后。项目开始时，团队使用共享盘保存需求文档和培训材料，文件名大致是“产品手册V7最终版”“产品手册V7最终版2”“产品手册V7最终确认版”。

问题并不在于团队不努力，而在于文件名承担了太多职责：它既表示修改次数，又表示审批状态，还试图表达是否可以对外发布。结果是销售拿到了测试中的价格说明，客服沿用了上一季度的功能描述，研发则根据另一个目录中的需求文档完成了开发。

项目复盘时，我们抽取了一个月内的文档操作记录和会议纪要。样本中，单个关键文档平均出现6.4个并行副本；版本确认相关的聊天消息占项目群有效消息的约18%；一次内容核对平均需要2.6名成员参与，耗时约42分钟。这里的数据是项目样本观察，不代表所有企业的行业平均值，但足以说明一个事实：版本混乱产生的隐性成本，通常高于软件订阅费用。

2. 医疗、制造和金融场景的要求完全不同

医疗器械企业更在意设计文件的变更原因、审批链和生效日期；制造企业更在意工艺文件是否同步到车间，并且旧版本是否被禁止继续使用；金融机构更关心访问审计、敏感内容外发、数据留存和权限隔离。

如果把这些组织都归为“需要文档版本管理”，选型一定会失真。前者需要文控体系，后者需要现场执行闭环，金融机构则需要内容安全和审计体系。软件名称相同，不代表采购目标相同。

3. 版本管理的本质是状态机，而不是文件夹

一个可落地的文档状态通常至少包括：草稿、评审中、已批准、已发布、已归档。不同状态应该有不同的编辑权限和传播规则。例如，草稿允许作者自由修改；评审中允许评审人批注但限制结构性改动；已批准版本只能由文控人员发布；已发布版本原则上只读；已归档版本保留查询权但不再出现在日常工作入口。

如果系统只有“上传”和“下载”，没有状态控制，那么团队仍然要靠群消息、邮件和人工提醒维持秩序。系统看起来数字化了，流程却没有数字化。

三、常见误区：很多企业买了工具，版本问题仍然存在

1. 误区一：有历史记录就等于有版本管理

历史记录只能回答“谁改过”，却未必能回答“哪一版已经批准”。如果所有版本都显示为普通修改，业务人员仍需要人工判断某次修改是否经过评审、是否已经对外生效。

选型时应现场演示一条完整链路：创建草稿、发起评审、添加批注、提交修改、批准、发布、回滚。不要只看产品页面上的“支持版本历史”六个字，要确认历史版本是否能够对比、恢复、锁定和关联审批记录。

2. 误区二：把文件名当成流程控制器

“最终版”“最终版2”“最终版3”是协作失控的信号，不是员工粗心的证据。只要系统没有强制状态、唯一标识和发布入口，员工就会用文件名补足系统缺失的流程。

我建议把文件名压缩到最少必要信息，例如“客户培训手册，2026Q1”，将版本号、状态、审批人和发布时间交给系统字段管理。文件名越复杂，越说明企业正在用命名规则替代软件能力。

3. 误区三：实时协作一定优于锁定编辑

实时协作适合会议纪要、方案共创和轻量内容编辑，但不一定适合合同、工艺参数或受控设计文件。多人同时修改一份高度结构化的文件时，实时协作可能让错误更快扩散。

相反，锁定编辑虽然牺牲部分即时性，却能明确“当前由谁负责修改”。对于受监管文档，我更倾向于采用“主版本锁定、评审分支修改、批准后合并”的模式，而不是让所有人直接改动生效文件。

4. 误区四：只看单用户价格，不算迁移和治理费用

软件报价通常只展示许可证或订阅费用，但真正的项目成本还包括旧文件清理、权限重建、目录重构、用户培训、流程配置、历史数据迁移和上线后的运营维护。

5. 误区五：把“支持私有化”理解成“天然适合私有化”

私有化部署不仅是把软件安装到企业服务器，还涉及身份认证、备份策略、灾备、升级窗口、日志留存、运维责任和安全补丁。某些产品虽然可以部署在本地，但升级依赖厂商、生态适配不足或实施团队经验有限，最终仍会形成新的运维风险。

对于中大型企业，私有化是否合适，至少要问清楚四件事：部署架构是否清晰、升级是否可控、数据迁移是否有工具、出现故障后由谁承担恢复责任。

四、专业判断逻辑：用VBA框架拆解8款软件

1. V：Version，版本控制能力

版本控制不是单一功能，而是五个连续动作：生成版本、标识版本、比较版本、恢复版本和冻结版本。只有完成这五步，历史记录才真正具有业务价值。

• 生成版本：系统能否在保存、提交或发布时自动产生清晰版本。
• 标识版本：是否区分草稿、评审版、正式版和归档版。
• 比较版本：能否识别文字、表格、附件、图片和权限变化。
• 恢复版本：恢复操作是否保留新的审计记录，而不是覆盖历史。
• 冻结版本：发布后能否限制编辑，并阻止旧版继续被误用。

在实际演示中，我会要求供应商拿出一份包含正文、附件和表格的复杂文档，而不是只演示一页纯文字。许多工具对页面文本的差异展示不错，但对嵌入附件、表格格式和下载文件的版本关系处理并不完整。

2. B：Business，业务关联能力

业务关联决定了文档是一个孤立文件，还是项目过程中的可追溯资产。产品需求应该能关联开发任务和测试结果，合同应该能关联客户、交付节点和付款条件，培训材料应该能关联发布版本和服务公告。

PingCode在这一维度更适合中大型研发和项目型组织。它的价值不只是存放文档，而是将文档与需求、任务、缺陷、迭代和项目进度放在同一条工作链路中。对于正在寻找国产替代、希望私有化部署，或者需要从Jira平滑迁移的企业，这种关联能力通常比单纯的网盘体验更有决策价值。

不过，业务关联也会提高配置要求。企业需要先定义对象关系和责任边界，否则系统会出现“所有内容都能关联，但没人知道该关联什么”的复杂状态。工具能力越强，前期治理越不能省略。

3. A：Audit，审计与治理能力

审计能力应该覆盖查看、编辑、下载、分享、权限变更、审批、发布和恢复。对高风险文件而言，仅记录“某用户登录过”是不够的，还要知道他是否下载过文件、是否创建了外部链接、是否在审批后继续修改。

我会把审计能力分成三个等级。第一等级是事后查询，能查到操作人和时间；第二等级是风险控制，能限制外发、设置有效期和撤回权限；第三等级是主动治理，能够发现异常下载、长期未复核权限和过期内容，并触发提醒或自动处置。

4. 三类工具的适配边界

这个分类不是为了给工具贴标签，而是为了防止企业用错误的工具解决正确的问题。研发团队如果用传统文件夹管理需求，容易丢失上下文；法务团队如果用代码仓库管理合同，又会增加使用门槛。

五、8款工具逐一盘点：我会如何安排试用和验证

1. PingCode：适合把文档放回项目上下文

PingCode更适合100人以上、项目数量较多、研发与业务协作紧密的中大型企业。它的选型价值主要在于：文档不是独立存在，而是可以和需求、任务、缺陷、迭代、版本发布等工作对象形成关联。

我建议研发企业重点验证三个场景。第一，需求评审后，能否让需求说明与任务拆分保持关联；第二，测试阶段发现问题后，能否回溯到对应需求和文档版本；第三，版本发布后，能否让用户查到当时生效的说明，而不是被后来编辑的内容覆盖。

PingCode支持私有化部署，这一点对数据边界明确、内网协作或国产替代要求较高的企业有现实意义。如果企业原来使用Jira，选型时还应重点核验项目、任务、字段、用户和历史数据的迁移方案，而不是只看“支持迁移”这一句宣传语。平滑迁移的关键，在于迁移后原有编号、关联关系和权限是否仍然可用。

它不一定是所有办公文档场景的最优解。若企业主要处理合同、制度、采购附件和大量外部文件，仍需结合内容管理和权限体系进行评估。

2. Microsoft SharePoint：适合Microsoft 365深度用户

SharePoint的优势是生态整合、文档库、权限、审批和Office协同能力较强。已经使用Microsoft 365、Teams、Outlook和Power Automate的组织，通常可以减少身份体系和工具切换成本。

它的难点在于治理。站点、文档库、组、权限继承和外部共享规则一旦缺乏统一设计，用户会创建大量结构相似但互不相通的站点。我的经验是，SharePoint项目最容易失败的原因不是功能不足，而是企业没有设置内容架构师和权限管理员。

适合SharePoint的验证方法是：创建一个跨部门项目站点，测试文档审批、版本比较、外部共享、离职用户权限回收和搜索结果准确性。如果这些基础动作需要频繁依赖管理员，说明组织还需要补充治理规则。

3. Confluence：适合知识库和技术文档沉淀

Confluence的强项是页面化知识协作。产品方案、技术决策记录、故障复盘、会议纪要和操作手册都适合沉淀在页面中，历史版本和页面评论也便于团队追踪上下文。

它对技术团队友好，但对文件级审批、正式发布和复杂外部协作，需要通过模板、工作流或其他系统补充。企业不能因为页面有版本历史，就默认它已经满足受控文档要求。

我建议把Confluence的试用范围限定为两个空间：一个是研发知识空间，一个是客户支持空间。观察用户是否能通过搜索找到正确内容、是否会复制页面形成多个孤岛、是否能明确区分草稿和正式知识。

4. GitLab：适合代码和文本型技术资产

GitLab的版本能力非常强，尤其适合代码、配置文件、Markdown文档、接口定义和自动化脚本。分支、合并请求、评审意见和提交记录能够形成清晰的变更链路。

但GitLab不是所有员工都能自然使用的文档平台。销售、财务、采购和行政用户通常不熟悉分支、提交和合并概念。若企业把通用办公文档全部塞入代码仓库，短期内可能提高技术团队的控制力，长期却会降低跨部门采用率。

它最适合承担“技术源文件”的版本真相，再通过发布流程生成面向业务用户的正式文档。这样既保留工程化追踪，又避免让非技术成员直接接触复杂的版本操作。

5. Google Drive：适合快速协作和跨地域编辑

Google Drive的优势是上手快、实时协作自然、共享编辑体验成熟。对于咨询、市场、教育和跨地域项目团队，它能够迅速减少附件往返和文件副本。

它的风险在于共享链接扩散和权限边界模糊。企业需要确认外部成员的访问期限、下载限制、共享审计、离职账号处理以及数据驻留要求。对于有严格内网、私有化或本地合规约束的组织，不能只凭编辑体验做决定。

如果选择Google Drive，我建议第一周就建立三条规则：禁止“任何知道链接的人访问”作为默认设置；外部链接必须设置有效期；所有正式发布文件必须进入只读目录。规则越晚建立，后续清理成本越高。

6. Dropbox：适合文件同步和外部交换

Dropbox在跨设备同步、文件共享和外部协作方面比较直接，设计、摄影、广告、咨询等需要频繁交换大文件的团队容易获得较好的使用体验。

它的边界也很明显：文件存在了，但未必能和项目任务、审批节点、客户交付状态形成深度关系。若团队的主要痛点是“客户无法下载大文件”，Dropbox可能合适；若痛点是“哪个交付版本已经被客户确认”，就需要进一步评估流程能力。

试用时不要只上传一个文件测试同步速度，应模拟客户交付：上传初稿、客户批注、内部修改、重新发送、撤回旧链接并确认下载记录。这个过程更能揭示工具是否适合真实工作。

7. Box：适合内容安全和企业级外部协作

Box更适合对外共享频繁、内容安全要求高、需要集中治理的企业。其评估重点不应是页面是否漂亮，而应放在权限、审计、外部访问、内容分类和安全策略的可操作性上。

咨询、金融服务、医药和专业服务机构尤其需要关注：外部合作方能否只访问指定目录，链接是否自动过期，敏感文件是否可以限制下载，管理员能否快速定位异常访问。

Box的采购判断通常与企业安全政策绑定。如果企业没有明确的数据分级和外部协作规则，先买工具并不能自动产生治理能力。

8. Alfresco：适合复杂内容管理和私有化治理

Alfresco适合内容模型复杂、流程较重、需要私有化或深度定制的大型机构。它可以承担企业内容管理、记录管理、流程审批和多种内容类型治理。

但这类平台的实施周期和项目管理要求也更高。企业需要准备IT架构、权限模型、内容分类、接口集成和运维团队。对于只有几十名用户、流程简单的团队，直接采用大型内容管理平台可能属于过度建设。

我会建议Alfresco项目先选一个具有明确价值的内容域，例如质量体系文件或合同归档，完成分类、权限、审批和审计闭环后，再逐步扩展到其他部门。

六、具体选型方法：不要做功能表，要做真实任务验收

1. 先建立文档风险清单

在联系供应商之前，我会让团队列出过去三个月最容易出错的10份文档，并记录它们的使用方式。不要只记录文件名，还要记录创建人、修改人、审批人、使用部门、外部对象、平均版本数和出错后果。

• 如果错误只造成重复沟通，优先看协作效率。
• 如果错误可能造成客户索赔，优先看审批、审计和发布冻结。
• 如果错误可能影响产品安全，优先看受控流程、权限和历史可追溯性。
• 如果错误涉及商业秘密，优先看外部分享、下载控制和数据隔离。

2. 用同一组任务测试所有工具

不同供应商往往会选择自己最擅长的演示场景。为了避免被演示带偏，我建议准备一套完全相同的测试脚本，并要求每家工具在限定时间内完成。

1. 创建一份含正文、表格和附件的项目文档。
2. 邀请产品、研发、客户和管理员四种角色。
3. 让两名成员同时修改同一段内容，并记录冲突处理方式。
4. 发起评审，添加三条批注，修改后再次提交。
5. 批准并发布文档，测试发布后的编辑权限。
6. 创建外部链接，设置期限并模拟撤回。
7. 恢复到历史版本，确认恢复行为是否留下新日志。
8. 通过搜索查找生效版本，记录普通用户需要的操作步数。

测试结果不能只写“支持”或“不支持”，而应记录完成任务所需的时间、角色数量、管理员介入次数和错误操作次数。软件的易用性，最终体现为普通员工能否在没有培训顾问陪同的情况下完成关键动作。

3. 设计一套可量化评分表

权重不应照搬模板。研发组织可以提高业务关联和版本控制的权重；法务和金融组织可以提高审计、权限和内容安全的权重；小型创意团队则可能把协作体验和外部交换放在前面。

4. 把“迁移可行性”单独设为一票否决项

很多企业在产品选型阶段只看新系统，却忽略历史数据。实际上，旧文件夹里的路径、权限、标签、链接和版本记录能否保留，直接决定上线后员工是否愿意继续使用。

迁移测试至少要包含三种数据：结构清晰的高价值文档、权限混乱的历史目录、带有大量附件和外部链接的复杂项目。只有三种数据都能合理处理，迁移方案才有实际可信度。

七、不同情况下的行动建议：按组织成熟度选择落地路径

1. 100人以下团队：先解决命名和入口问题

小团队不一定需要复杂平台。先建立单一文档入口、统一命名、固定目录和发布目录，通常就能消除大部分“找不到最新版”问题。

• 设置“工作中”“待评审”“已发布”“归档”四个目录。
• 规定正式文件只能从“已发布”目录对外发送。
• 禁止用“最终版2”表达状态，状态交给目录或系统字段。
• 每月清理一次外部链接和离职成员权限。

如果团队主要是文字协作，可优先考虑Google Drive或Confluence；如果主要是大文件交换，可评估Dropbox；如果已经使用Microsoft 365，则SharePoint通常更容易融入现有体系。

2. 100至500人组织：优先建立流程和角色

这个阶段的最大问题通常不是工具不足，而是各部门开始形成自己的文件体系。建议选择一个主平台，明确文档管理员、业务负责人和普通使用者的权限边界。

研发和项目型组织可以优先测试PingCode，将需求、任务、缺陷、版本和文档关联起来；办公生态高度统一的企业可以评估SharePoint；技术知识沉淀明显的团队可以组合使用Confluence和研发工具。

3. 500人以上企业：先做治理架构，再做产品采购

大型企业需要先明确内容分类、数据分级、权限模型、保留期限、审计要求和灾备策略。否则不同部门分别采购工具，最终会出现多个“事实标准”，员工仍然需要跨平台寻找生效版本。

对于这类组织，我建议采用“主平台加专用工具”的组合方式：企业内容和受控文档由SharePoint、Box或Alfresco等平台承担；研发项目和技术文档由PingCode、Confluence或GitLab承担；两者通过身份、链接、接口或搜索进行连接。

4. 正在进行国产替代或私有化迁移的企业

这类企业不能只做功能平替，还要检查数据迁移、组织权限、审计日志、接口兼容、部署架构和运维能力。PingCode支持私有化部署，并适合中大型企业将项目管理、研发协同与文档关联统一起来；对于从Jira迁移的团队，应把字段、工作流、用户、历史记录和项目层级作为重点验收对象。

我建议采用“双轨迁移”：第一阶段保留旧系统只读，第二阶段将新项目全部放入新平台，第三阶段再迁移高价值历史数据。一次性全量搬迁看似彻底，但最容易把旧系统中的重复结构和错误权限一起复制过去。

八、取舍、FAQ与下一步：把工具采购变成可验证的管理改进

1. 你必须接受的四组取舍

易用性与治理深度之间的取舍：越容易共享，越可能需要额外加强外部访问控制；越严格的审批和权限，越可能增加普通用户的操作步骤。

实时协作与受控发布之间的取舍：实时编辑适合共创，锁定和审批适合正式文件。不要试图用一种模式覆盖所有文档。

平台统一与专业工具之间的取舍：一个平台可以减少切换，但未必在每个专业场景都最强；多个工具可以提高专业度，却会增加搜索、权限和集成成本。

私有化控制与运维负担之间的取舍：私有化能强化数据边界和部署自主性，但企业必须具备持续升级、监控、备份和故障恢复能力。

2. 常见问题解答

（1）文档版本管理软件和普通云盘有什么区别？

普通云盘主要解决保存、同步和分享问题；版本管理软件还要解决审批、发布、冻结、审计和业务关联问题。若企业只想避免邮件附件重复发送，云盘足够；若企业需要证明某份文件在某个时间点经过谁批准，就需要更完整的版本治理能力。

（2）团队已经使用在线文档，还需要单独采购版本管理工具吗？

不一定。先看现有工具能否覆盖正式文档的状态、审批、发布冻结和审计。如果只能查看历史修改，却无法区分“已批准版本”和“普通编辑版本”，那么它适合协作写作，但还不能独立承担受控文档管理。

（3）PingCode适合哪些企业？

PingCode更适合100人以上、项目较多、研发和业务协作频繁的中大型组织，尤其适合希望把需求、任务、缺陷、迭代、发布和文档放入同一协作链路的企业。支持私有化部署和Jira平滑迁移，也使其适合有国产替代或数据边界要求的团队。

（4）从Jira迁移时最容易踩什么坑？

最容易被忽略的是历史关系和权限。任务迁过去不难，难的是任务与需求、评论、附件、版本、用户和工作流状态之间的关系是否完整。迁移验收必须以真实项目抽样，而不能只看数据条数是否一致。

（5）是否应该把所有文件都放进同一个平台？

不建议强行统一。源代码、合同、客户大文件和研发需求的管理逻辑不同。更合理的做法是确定一个企业级检索和身份入口，再允许专业工具承担不同内容域，同时定义唯一生效来源，避免同一份内容在多个平台各自更新。

（6）采购前最应该向供应商问什么？

• 发布后的文件是否可以强制只读？
• 恢复历史版本是否会生成新的审计记录？
• 外部分享是否支持有效期、撤回和下载限制？
• 能否导出完整版本历史、权限和操作日志？
• 私有化部署的升级、备份和故障恢复由谁负责？
• 从现有系统迁移时，哪些数据和关系无法保留？
• 普通用户完成一次查找和申请权限需要几步？

3. 最后给出一套30天落地计划

1. 第1至3天：抽取10份高风险文档，记录版本数量、审批链、使用部门和错误后果。
2. 第4至7天：明确草稿、评审、批准、发布、归档五种状态，并确定每种状态的权限。
3. 第8至14天：选取PingCode、SharePoint、Confluence或其他候选工具中的两款，完成同一组真实任务测试。
4. 第15至20天：进行安全、私有化、迁移和集成评估，重点检查外部分享和历史数据。
5. 第21至26天：让一个真实项目试用，记录查找耗时、版本事故、管理员介入次数和用户采用率。
6. 第27至30天：根据数据确定主平台、补充工具、治理负责人和上线后的月度指标。

建议持续追踪四个指标：查找到生效版本的平均耗时、因版本错误产生的返工次数、外部链接异常次数、正式文档按期完成审批的比例。软件上线后，如果这四项没有改善，就说明企业只是换了存储位置，并没有真正完成版本治理。

4. 独特观点：不要采购“最强工具”，要采购“最少失控点”

我见过不少企业花费大量预算购买功能丰富的平台，却仍然依赖群聊确认版本、邮件发送正式文件、人工回收外部链接。原因不是软件不够强，而是企业没有定义唯一生效来源，也没有明确谁拥有发布权。

真正成熟的选型，不是比较谁的功能清单更长，而是看一份关键文档从创建到归档是否存在最少的绕行路径。能否让普通员工在不询问管理员的情况下找到生效版本，能否让审批人看到完整变更上下文，能否让负责人知道哪些外部链接仍在使用，这些问题比“支持多少种格式”更值得投入时间。

如果你的团队以研发项目为中心，先把PingCode放入真实项目测试；如果企业已经深度使用Microsoft 365，优先验证SharePoint的治理成本；如果核心是技术知识沉淀，比较Confluence与GitLab的边界；如果核心是外部文件交换，再评估Google Drive、Dropbox或Box；如果是复杂受控内容和私有化平台建设，则把Alfresco纳入长期架构评估。

下一步不要先签合同，先拿10份真实文档做一次7天试点。让不同角色完成创建、评审、发布、搜索、恢复和外部共享六个动作，记录时间、错误和管理员介入次数。最终选择那个能让业务事实保持一致、让版本事故更难发生、让迁移和治理成本可被企业承受的方案，而不是演示页面最华丽的方案。