项目管理新趋势：8款领先的云文档记录工具对比（2026版）

项目管理新趋势：8款领先的云文档记录工具对比（2026版）

项目管理新趋势：8款领先的云文档记录工具对比（2026版）真正要解决的，不是“哪款软件功能最多”，而是一个更棘手的问题：会议纪要、需求变更、项目决策和执行结果，能不能在几个月后被准确找到、追溯并继续使用。我的判断是，2026年的云文档工具选型，核心已经从“在线写文档”转向“让项目上下文持续可见”。

我见过不少团队同时使用即时通信、网盘、在线文档、任务工具和个人笔记。项目刚开始时，每个人都觉得效率很高；到了需求变更多、人员流动加快、客户频繁参与之后，问题便集中出现：同一个需求有三个版本，会议结论无法确认，任务已经关闭却找不到决策依据，项目复盘只能依靠参与者回忆。

因此，本文不做简单的“软件排行榜”，而是按照项目生命周期，比较8款具有代表性的云文档记录工具：Notion、Confluence、飞书云文档、腾讯文档、语雀、Microsoft Loop、Google Docs，以及PingCode。重点观察它们在记录、协作、搜索、任务衔接、权限、AI、迁移和企业治理方面的真实差异。

一、先讲核心结论：没有绝对第一，只有信息流最匹配的工具

1. 先把8款工具放进正确的类别

很多对比文章一上来就把笔记工具、知识库、办公套件和项目管理平台放在同一张榜单里。这样做很容易得到一个看似完整、实际无法采购的结论，因为它们解决的根本问题不同。

这张表最重要的地方，不是给工具贴上“好”或“坏”的标签，而是提醒采购者：如果你的核心问题是多人共同编辑一份通知，选择知识库平台可能过重；如果你的核心问题是需求、任务和版本之间缺少关联，单纯购买在线文档又可能不够。

2. 我的场景化判断

如果团队人数较少，项目流程并不复杂，优先考虑上手速度、模板和自由组织能力，Notion、飞书云文档、腾讯文档更容易快速产生价值。

如果项目资料需要长期沉淀，且研发、产品、客服和交付人员都要反复查阅，Confluence和语雀的知识库思路更合适。它们的价值不在于“记录得快”，而在于“半年后仍然找得回来”。

如果团队希望把需求、缺陷、迭代、任务和项目文档放在同一套管理逻辑中，PingCode更值得重点评估。尤其是中大型企业、100人以上组织，或者正在考虑私有化部署、国产替代、从Jira平滑迁移的团队，采购重点应从编辑体验转向流程完整性、数据治理和迁移成本。

如果外部客户、供应商或合作方需要频繁参与文档编辑，Google Docs和腾讯文档的分享体验通常更直接；如果企业已经深度使用微软办公环境，Microsoft Loop的组件化协作价值会更明显。

二、为什么项目团队开始重新重视云文档记录

1. 项目真正丢失的不是文件，而是上下文

一份需求文档通常只记录“要做什么”，却未必解释“为什么这样做”。真正影响项目执行的内容，往往藏在会议讨论、聊天消息、评审意见和临时决定中。

当这些内容没有进入统一的项目文档，后续人员只能看到结果，看不到决策过程。于是，需求变更会被误认为反复修改，延期会被误认为执行效率低，客户意见会被误认为临时插入。项目管理中的许多争议，本质上是上下文没有被保存。

云文档记录工具的价值，是把“讨论，决定，执行，复盘”串成一条可检索的信息链。它不一定取代任务管理工具，却应当让任务拥有来源，让决策拥有依据，让复盘拥有材料。

2. 一个典型项目的信息断层

以一次产品迭代为例，产品经理在会议中确认需求，研发在聊天群里提出技术限制，设计师把最终稿放进网盘，测试人员在缺陷工具中记录问题，项目负责人又在表格里维护进度。

这些工具单独看都没有问题，但它们之间缺少关联。到了版本发布前，团队需要人工回答四个问题：这个需求是谁提出的？为什么删掉某个功能？当前版本的验收口径是什么？哪些风险已经被谁确认过？如果每次都要重新翻找，工具越多，管理成本反而越高。

3. 记录工具正在从“被动存储”转向“主动辅助”

过去的云文档主要解决异地保存和多人编辑。现在，团队更关注语音转文字、会议摘要、行动项提取、全文搜索、知识问答和相关资料推荐。

但我不建议把“支持AI”直接等同于“适合项目管理”。AI是否有用，要看它能否处理项目中的具体任务：能否区分决定与讨论，能否识别负责人和截止时间，能否引用原始来源，能否遵守文档权限，能否让用户发现它的判断依据。

一个只会把长文压缩成三段摘要的功能，未必能减少项目管理工作。真正有价值的AI，应该帮助团队减少查找、整理和转录，而不是制造一份无法核验的新文本。

三、常见误区：为什么很多团队买了工具，项目还是混乱

1. 把云文档当成网盘的升级版

网盘擅长保存文件，云文档擅长共同编辑和持续更新。两者都能存资料，但信息组织逻辑不同。

如果团队只是把原有的Word、Excel和PDF全部上传，却没有建立项目目录、文档负责人、版本规则和归档机制，云端只会把混乱复制一遍。搜索功能也无法完全弥补命名混乱、重复文件和权限失控。

我的建议是，迁移前先定义三类内容：需要共同编辑的工作文档、需要长期维护的知识文档、需要与任务绑定的执行文档。不同类型不必强行放在同一位置。

2. 只看功能数量，不看使用路径

产品页面列出的功能越多，不代表项目成员越愿意使用。项目记录的第一要求是低摩擦：会议结束后，谁负责把内容写进去？行动项如何产生？相关人员是否会收到提醒？新成员能否找到入口？

如果完成一份会议纪要需要打开多个页面、手工复制任务、重新设置权限，再漂亮的模板也很难坚持。团队最终会回到聊天群里用一句“大家按刚才说的执行”。

3. 把实时协作误认为项目协作

多人同时编辑是一项基础能力，却不等于项目管理。实时协作解决的是“几个人一起改一份内容”，项目协作还需要解决“谁在什么时间完成什么事情，以及为什么要这样做”。

Google Docs、腾讯文档和飞书云文档在共同编辑场景中很有优势，但如果任务、风险和验收条件仍然分散在其他工具中，团队依然要承担信息搬运成本。

4. 看到AI摘要就忽略权限和来源

项目文档包含客户信息、商业计划、技术架构和人员决策。AI功能上线后，管理员必须确认数据是否用于模型训练、是否支持组织级开关、是否能遵守页面权限，以及生成结果是否保留引用来源。

对企业来说，一个回答很快但无法说明来源的AI，不一定比传统搜索更可靠。特别是涉及合同、研发方案和合规事项时，用户需要的是可验证答案，而不是语言流畅的猜测。

5. 把“市场领先”当成采购结论

下载量、品牌知名度和应用商店评分，只能说明产品获得了某种关注，不能直接证明它适合大型项目。企业选型还要看权限层级、审计能力、部署方式、接口开放程度、迁移方案和供应商服务。

因此，本文使用“具有代表性”而不是绝对市场排名。任何工具进入采购清单，都应经过真实项目试用和数据导出测试。

四、专业判断逻辑：我如何比较这8款工具

1. 第一层：看记录是否足够快

我会用一次30分钟项目会议作为基础测试，而不是只浏览首页。测试内容包括：新建会议页面、插入议程、记录决定、标记行动项、上传附件、@相关人员和发布纪要。

如果一个工具需要用户频繁切换页面，或者行动项必须重新录入任务系统，它的“记录效率”就不能只按编辑器速度评价。真正要测的是从会议结束到任务可执行之间用了多少步骤。

2. 第二层：看文档能否连接任务

项目文档不是静态报告，而是执行过程的入口。优秀的项目记录应当能回答：这项工作对应哪个目标？当前状态是什么？负责人是谁？还有哪些风险？完成后如何验收？

Notion可以通过数据库和关联页面实现较灵活的连接；飞书云文档可以借助表格、任务和组织协作形成工作流；PingCode则更适合把需求、任务、迭代和项目文档放到同一管理体系中。对于研发团队，这种一体化可以减少从会议纪要复制到任务系统的重复劳动。

但一体化并非越强越好。内容团队如果主要工作是文章策划、素材评审和客户反馈，使用过于复杂的项目管理平台，可能会增加培训成本。工具与流程的匹配度，比功能数量更重要。

3. 第三层：看搜索能否找回“为什么”

搜索测试不能只输入标题。真实场景中，用户通常只记得一个模糊片段，例如“上次评审提到的兼容性问题”“客户为什么不同意第二版方案”。

我建议使用三组关键词测试：准确关键词、模糊关键词和附件关键词。准确关键词测试基础检索，模糊关键词测试内容理解，附件关键词则可以判断扫描件、图片和嵌入文件是否真正可用。

4. 第四层：看权限、部署与迁移

个人笔记工具可以容忍权限简单，企业项目却不能。采购前至少要确认空间级、目录级、页面级和外链级权限是否足够细；还要确认离职人员的资料如何转移，外部成员是否会看到不该看到的内容。

对研发和制造类企业而言，部署方式也可能决定采购结果。PingCode支持私有化部署，并提供Jira平滑迁移方向，这类能力更适合对数据边界、内部网络和国产替代有明确要求的中大型组织。不过，是否满足具体行业合规要求，仍需由企业结合部署架构、合同条款和供应商安全材料核验，不能只看产品宣传。

迁移测试尤其容易被忽略。很多平台能导出正文，却无法完整保留评论、附件、历史版本、页面关系和权限。试用时最好拿一组真实但已脱敏的项目资料进行导入导出，而不是只导出一篇空白文档。

五、8款工具逐一对比：优势之外，更要看边界

1. Notion：适合快速搭建项目空间

Notion的优势是自由度高。项目负责人可以用页面搭建项目主页，用数据库维护需求、风险和会议记录，再通过模板复制到不同项目中。对于内容、市场和产品小团队，它通常能较快形成“项目总入口”。

它的代价也是自由度。没有明确的信息架构时，不同成员会按照自己的方式建页面，最终产生重复数据库、命名不一致和权限难维护的问题。复杂研发项目还需要额外配置任务状态、版本、缺陷和验收关系。

适合：小型团队、内容项目、产品探索和轻量知识库。

不适合：需要严格研发流程、复杂权限和大规模项目治理的组织。

2. Confluence：适合长期维护的企业知识库

Confluence更像一个组织级知识基础设施。它适合把产品需求、技术方案、架构说明、操作手册和复盘文档放入具有层级的项目空间中。对于研发团队，页面历史、评论和空间结构往往比“快速写一段笔记”更重要。

它的关键挑战是治理。页面越多，越需要制定命名规则、归档规则、模板规则和内容负责人制度。否则，知识库会从“项目资料中心”变成“历史文档墓地”。

适合：研发、产品、技术支持和大型组织的长期知识管理。

不适合：只需要临时共同编辑，且没有专人维护知识结构的短周期团队。

3. 飞书云文档：适合办公协作密集型团队

飞书云文档的优势在于协作链路短。会议、即时沟通、文档、表格和组织通讯录可以形成较自然的工作路径，适合日常会议频繁、跨部门沟通密集的团队。

它更适合把文档作为办公流程的一部分，而不是单独建设深度研发知识库。若团队需要复杂的版本、缺陷、迭代和交付管理，仍要认真评估现有项目流程能否在其上完整落地。

适合：市场活动、运营项目、行政协作和跨部门工作组。

选型提醒：不要只试用文档编辑，要把会议、任务、审批和外部协作一起跑一遍。

4. 腾讯文档：适合快速共享和共同编辑

腾讯文档通常在邀请协作者、共同编辑表格和收集反馈方面具有较低的使用门槛。它适合活动排期、名单收集、预算协作、客户资料整理等短周期场景。

它的边界在于长期项目治理。若团队需要复杂知识库、跨文档关联、任务状态和项目复盘，单独依赖在线文档可能会不够。此时可以把它作为资料协作入口，而不是完整项目管理中枢。

适合：外部协作、活动项目、临时表格和多人资料收集。

不适合：需要长期维护复杂项目知识结构的企业团队。

5. 语雀：适合中文内容和经验沉淀

语雀的价值主要体现在中文知识库和文档组织。对于产品规范、技术手册、运营SOP、客户交付资料和项目复盘，它适合通过目录和知识库形成较清晰的阅读路径。

如果团队期待“文档一写完就自动变成项目计划”，它可能不是最合适的选择。它更擅长知识沉淀，而不是替代复杂的任务、排期和资源管理。

适合：中文知识库、产品文档、操作规范和内容团队。

选型提醒：提前设计知识库负责人和过期内容清理机制，否则目录会不断膨胀。

6. Microsoft Loop：适合微软生态中的灵活协作

Microsoft Loop的特点是组件化。团队可以把文字、列表、表格、任务等协作内容放入不同工作空间，并在微软生态的其他协作场景中继续使用。它适合快速讨论和共同完善尚未定型的内容。

它的长期价值取决于团队是否建立统一的空间、页面和归档规则。没有规则时，组件可能散落在不同会话和页面中，后续检索难度会上升。

适合：已经大量使用微软办公产品，且需要灵活协作组件的团队。

不适合：希望开箱即用地获得完整项目知识库和严格流程治理的组织。

7. Google Docs：适合实时共同编辑和外部协作

Google Docs的核心优势是成熟的在线共同编辑、评论和版本能力。跨地域团队、咨询交付团队和需要客户直接参与的项目，通常可以快速开始。

它的问题也很清楚：文档本身不是完整的项目管理系统。需求状态、负责人、风险和迭代计划如果没有配套工具，最终仍会通过表格或邮件维护。

适合：跨地域协作、文案交付、客户审阅和多人共同起草。

选型提醒：确认企业数据区域、账号体系、外链权限和离职账号处理方式。

8. PingCode：适合文档与研发项目流程一体化

PingCode更适合把项目文档放进需求、任务、迭代和交付流程中管理，而不是只作为独立笔记空间使用。对于中大型企业及100人以上组织，项目记录往往需要连接产品需求、研发任务、缺陷、版本和项目进度，这种一体化思路能够减少重复录入。

它支持私有化部署，并支持Jira平滑迁移方向，因此对于数据不能离开内网、正在做国产替代，或者希望降低迁移阻力的企业，值得进入重点试用名单。这里的关键不是“功能是否最多”，而是迁移后原有需求、任务、字段、关系和人员权限能否连续保留。

它的边界同样明显：如果只是三五个人记录读书笔记、活动灵感或简单会议内容，完整的项目管理能力可能会显得偏重。企业需要先确认自身是否真的需要流程、权限和治理能力。

适合：研发、产品、制造、交付和100人以上的中大型组织。

选型提醒：重点测试私有化部署、权限模型、Jira迁移、历史数据完整性、接口能力和实施服务，而不是只看页面编辑体验。

六、具体案例和数据观察：工具价值要落到项目动作上

1. 研发团队案例：从会议纪要到可执行任务

我建议研发团队不要用“文档写得是否漂亮”作为试用标准，而要观察一次需求评审能否完整闭环。测试会议可以设置为：确认3项需求、否决1项方案、产生2个技术风险，并由不同角色承担行动项。

试用结束后，检查四个结果：需求是否有唯一编号，决策是否保留原始讨论，风险是否拥有负责人和截止时间，研发人员能否从任务回到需求背景。如果只能做到前三项中的一部分，说明工具仍然是文档容器，而不是项目协作系统。

上表是用于试用设计的情景模拟，不是某个厂商的公开效果承诺。它的作用是帮助团队把“效率提升”改写成可测量的问题：少花了多少时间，少复制了多少次，少问了多少个人。

2. 100人以上企业案例：先解决迁移，再谈全面替换

中大型组织更换项目工具时，最大的风险不是员工不会使用新界面，而是历史数据失去可追溯性。一个运行多年的研发项目通常包含需求、缺陷、版本、附件、评论、成员、状态和权限。只迁移正文，不迁移关系，等于只搬走了项目的一部分记忆。

以正在评估PingCode的企业为例，我会把Jira迁移拆成四个阶段：先选择一个已结束迭代进行小规模迁移，再校验字段和关系；然后迁移一个正在执行的项目，观察团队是否能正常工作；接着进行权限和报表验证；最后才制定全组织切换时间表。

1. 整理源系统字段、项目、用户、状态和工作流。
2. 抽取脱敏数据，验证需求、任务、缺陷和评论的迁移结果。
3. 让产品、研发、测试和项目经理分别执行真实操作。
4. 检查历史链接、附件、权限、报表和导出结果。
5. 保留回滚方案，并为切换后的前两周设置问题响应机制。

私有化部署也不应被简单理解为“数据放在企业自己的服务器上就结束”。企业还需要确认升级方式、备份策略、灾备目标、接口安全、账号同步、运维责任和供应商响应时效。部署方式改变的是治理边界，不会自动解决流程混乱。

3. 内容与市场团队案例：不要用重型平台管理轻量工作

市场活动通常需要策划案、预算表、供应商资料、物料清单、审批记录和复盘报告。团队最关心的是谁能快速更新，外部人员能否安全参与，截止时间是否清晰，而不是复杂的研发字段。

这类团队可以优先考虑飞书云文档、腾讯文档、Google Docs或Notion，再根据任务复杂度补充轻量任务管理。若活动需要大量外部协作者，权限和外链控制要比知识库层级更重要。

相反，如果市场部门同时管理几十个长期项目，且每个项目都需要资源排期、状态统计和跨部门依赖，那么单纯使用在线文档会逐渐失控。此时，文档与任务一体化平台的价值才会显现。

七、不同情况下的行动建议：先做小规模验证

1. 小团队和个人项目

小团队不需要一开始就购买最复杂的平台。可以先选一款支持模板、全文搜索和基础协作的工具，建立三个固定页面：项目主页、会议记录、决策与风险。

试用周期建议为两周。不要只邀请管理员使用，而应让实际负责产品、设计、执行和汇报的人共同参与。两周后重点检查：是否有人回到聊天工具记录关键信息，是否出现多个项目入口，是否能在一分钟内找到上周的决定。

2. 研发和产品团队

研发团队应把需求、任务、缺陷、迭代和版本作为一个整体验证。只试文档编辑没有意义，因为研发项目的成本主要产生在需求变更、依赖等待、缺陷追踪和验收确认。

• 要求每条关键需求都有唯一标识。
• 要求会议决策可以回链到需求或任务。
• 要求风险拥有负责人、时间和处理状态。
• 要求测试人员能够看到验收标准和变更记录。
• 要求项目经理可以按版本或迭代查看整体进展。

3. 100人以上组织或多部门企业

这类组织应优先评估组织架构同步、空间权限、审计、私有化部署、数据导出和迁移服务。产品演示阶段看起来很顺畅，但真正决定成败的是管理员能否在员工变动、项目跨部门共享和权限调整时保持可控。

如果企业正在做国产替代，或者希望从Jira迁移，应把迁移验证写入采购验收条款，而不是把它留给实施阶段临时处理。PingCode可以作为重点候选进行私有化和迁移能力评估，但最终仍应以脱敏数据测试结果为准。

4. 需要外部客户参与的项目

外部协作首先要测试“最小权限”。客户应该只能看到与自己有关的页面，供应商只能编辑指定表格，内部讨论不应因为外链分享而暴露。

建议分别建立内部空间和外部协作空间，不要把内部项目主页直接开放给客户。对于合同、报价、技术方案等敏感信息，必须明确哪些内容可以复制、下载、转发和长期保留。

八、不同情况下的取舍：你放弃什么，换来了什么

1. 自由度与标准化之间的取舍

Notion、Loop等工具提供较高自由度，适合探索和快速搭建。但自由度意味着团队必须承担信息架构设计责任。Confluence、语雀以及企业项目平台更强调结构和规范，长期治理更稳定，但初期配置和学习成本可能更高。

如果项目经常变化，先接受一定自由度；如果项目需要跨部门复制和审计，尽早建立标准化模板。不要在项目规模已经扩大后，才开始补做目录和权限设计。

2. 一体化与轻量化之间的取舍

文档、任务、缺陷、版本和报表放在一套平台里，可以减少切换和重复录入，但也会增加系统复杂度。PingCode这类项目管理平台适合流程完整、角色较多的团队；腾讯文档、Google Docs等更适合快速共同编辑。

判断方法很简单：如果团队每周都在复制文档内容到任务系统，一体化的价值很高；如果项目从开始到结束只需要共同写一份方案，重型平台可能属于过度建设。

3. 便捷云服务与部署控制之间的取舍

公有云通常上线快、维护轻，适合希望快速开始的团队。私有化部署可以提供更强的数据边界和内部控制，但企业需要承担服务器、升级、备份、监控和运维协同责任。

私有化不是安全的同义词，公有云也不是不安全的同义词。真正需要比较的是数据存储、访问控制、审计、灾备、漏洞响应和合同责任，而不是只看部署标签。

4. AI自动化与人工核验之间的取舍

AI可以减少整理和搜索时间，但不能替代项目责任人确认关键事实。会议摘要、风险提取和任务建议都应保留人工确认环节，尤其是涉及客户承诺、上线时间、合同范围和安全事项时。

我建议企业将AI功能分成三档管理：低风险内容可以自动摘要，中风险内容需要负责人确认，高风险内容只允许辅助检索，不允许直接生成最终结论。

九、采购前的验证清单：不要被演示环境说服

1. 用真实项目资料做试用

演示账号里的空白页面无法暴露工具的真实问题。企业应准备一组脱敏资料，包括一份需求文档、三次会议纪要、一个项目计划、若干任务、两份附件和一段历史讨论。

让不同角色独立完成操作，再收集结果。管理员关注权限和审计，项目经理关注进度和复盘，研发关注需求与任务关联，普通成员关注搜索和日常使用。

2. 至少测这10个问题

1. 新成员能否在10分钟内理解项目背景？
2. 能否从一条任务回到原始需求和会议决定？
3. 能否按模糊关键词找到历史结论？
4. 附件、图片和评论是否能被统一检索？
5. 外部成员能否只看到指定页面？
6. 离职成员的内容能否转交给团队空间？
7. 能否批量导出正文、附件和结构？
8. 导出后链接、评论和版本是否仍然可用？
9. AI回答是否提供引用来源并遵守权限？
10. 系统故障或供应商更换时，企业能否恢复工作？

3. 用加权评分代替“感觉不错”

如果是个人或小团队，可以把记录与编辑、价格的权重提高；如果是研发组织，应提高任务衔接和知识复用；如果是100人以上企业或有国产替代需求的组织，则应提高权限、安全、部署和迁移权重。

十、最终建议：把云文档当成项目记忆系统来建设

1. 先确定项目的主要信息类型

如果项目主要是共同起草文本，优先看编辑和评论；如果项目主要是知识沉淀，优先看目录、搜索和权限；如果项目主要是研发交付，优先看文档、需求、任务、缺陷和版本之间的关联。

不要因为某款工具同时拥有文档、表格、看板和AI，就默认它能解决所有问题。功能集合不等于工作流闭环，真正重要的是项目成员能否在一个自然路径中完成记录、执行和复盘。

2. 先测试搜索、权限和导出，再看界面美观

界面是否好看会影响第一印象，但搜索、权限和迁移决定长期成本。一个看起来简洁的工具，如果三个月后找不到决策、无法交接离职人员资料，或者导出时丢失附件，团队最终仍然要为它付出高昂代价。

我的优先级通常是：先测历史资料能否找回，再测外部协作是否可控，接着测任务是否能从文档中产生，最后才比较模板、配色和页面布局。

3. 按场景给出最后选择

• 个人、小团队和内容项目：优先考虑Notion、腾讯文档、Google Docs或飞书云文档，重点看上手速度和协作门槛。
• 长期知识库和研发文档：重点评估Confluence、语雀以及具备企业知识管理能力的平台，重点看结构、搜索和维护机制。
• 微软生态团队：可以重点试用Microsoft Loop，并同步验证长期归档和权限规则。
• 100人以上的研发和项目型组织：重点评估PingCode等项目管理平台，关注需求、任务、迭代、文档、权限、私有化部署和迁移能力。
• 外部客户参与频繁的项目：优先验证Google Docs、腾讯文档、飞书云文档等工具的外链权限、评论和协作者管理。

云文档工具的真正趋势，不是把所有项目内容塞进一个软件，而是让重要信息在产生时就拥有位置，在执行时能够被引用，在变化时留下轨迹，在项目结束后继续产生价值。

下一步可以这样做：选出两款最符合团队场景的工具，准备一组脱敏的真实项目资料，安排为期两周的并行试用；分别让项目负责人、执行成员、管理员和外部协作者完成任务，最后按照记录效率、搜索准确性、任务衔接、权限安全和数据迁移五个维度评分。

如果试用后仍然无法回答“这个决定为什么产生、现在由谁执行、相关资料在哪里、未来能否复用”，就不要急着采购。对项目管理而言，最好的云文档工具不是功能最多的那一个，而是能让团队少问一次、少复制一次、少丢失一次上下文的那一个。