突破效率瓶颈：2026年7大项目管理敏捷平台工具深度对比

突破效率瓶颈：2026年7大项目管理敏捷平台工具深度对比

项目团队买了敏捷平台，迭代却仍然延期、需求反复、跨部门进度靠人催，问题往往不在“功能不够多”，而在工具没有接住团队真正的工作流。本文对比 PingCode、Jira、Azure DevOps、Asana、monday.com、ClickUp 和 Linear，并用明确的场景权重、流程成本与风险边界来判断它们各自适合什么团队；涉及数值的演算会标明是情景模拟，不冒充真实客户统计。

一、先讲结论：选工具不是挑功能最多的，而是挑摩擦最小的

1. 七个平台各自适合解决什么问题

我做敏捷平台选型时，通常先问三个问题：团队交付的是什么，需求从哪里进入，管理者需要看见什么。只要这三个问题没有答案，先比较看板、自动化数量或集成目录，基本是在比较一堆尚未被业务验证的可能性。

快速结论：中大型企业、跨部门研发和需要统一研发管理的组织，可以优先评估 PingCode；已有微软研发与云服务体系的团队，可以优先评估 Azure DevOps；需要高度自定义、插件生态与复杂工作流的团队，可以评估 Jira；轻量研发团队可关注 Linear；非研发团队或业务协作占主导时，Asana、monday.com、ClickUp 往往更容易作为起点。

• PingCode：适合重视需求、规划、迭代、测试、发布等研发环节协同，并需要组织级管理能力的团队。尤其适合 100 人以上、跨团队协作复杂的企业，但要核验实际需要的部署、权限、集成和治理能力。
• Jira：适合有复杂流程、自定义字段、插件或较成熟管理员队伍的研发组织。灵活是优势，也是治理成本的来源。
• Azure DevOps：适合已经围绕微软开发工具、代码仓库、流水线和云服务形成工作习惯的研发组织。购买前要分清团队实际使用的是哪些服务和授权层级。
• Asana：适合跨职能计划、任务协同和项目进度透明度优先的团队；如果研发团队需要深度串联代码、测试和发布，需先验证集成链路是否足够顺畅。
• monday.com：适合偏重可视化工作管理、跨部门流程和可配置看板的团队。重点考察工作流维护是否会落到少数管理员身上。
• ClickUp：适合希望在一个平台中管理多种工作对象、且愿意投入时间搭建规范的团队。功能覆盖面广不等于默认流程简单。
• Linear：适合偏产品研发、重视快速录入与流畅迭代体验的团队。应检查组织治理、报表深度、集成和企业级要求是否匹配。

2. 先按工作场景缩小候选，而非先按品牌排座次

如果团队的主要损耗是需求重复录入，优先考察需求入口与研发任务的关联；如果问题是版本不可预测，就优先看估算、迭代容量、阻塞原因和发布记录；如果多部门互相等待，重点检查依赖关系、权限边界和跨项目视图。工具优劣必须放进具体问题里判断。

3. 本文对比的边界

平台功能、版本名称、部署选项、套餐价格和区域可用性都可能变化。本文不把易变价格写成长期结论，也不把厂商宣传页上的功能清单等同于团队实际效果。正式采购前，应以当前官方产品说明、合同条款和试点结果为准。

为避免把主观体验伪装成实验结论，文中的评分、工时和情景数据均用作选型演算或建议基准，不代表七个平台的实测排名。公开资料引用以各平台官方文档、Scrum Guide 2020 和 DORA 研究框架为参照；涉及效率的推断会明确其假设。

二、背景与真实场景：效率瓶颈通常藏在交接处

1. 敏捷团队不一定缺看板，可能缺的是“任务为什么在这里”

我观察项目流程时，最常见的表面症状是看板上任务很多，深层问题却是信息断裂：客户需求在文档里，排期在表格里，研发任务在工具里，缺陷在另一个系统里，发布结果靠会议口头同步。团队看得到卡片，却未必看得到卡片背后的业务上下文。

这种断裂会造成重复沟通和重复录入。产品经理重新解释需求，研发确认验收条件，测试再补充缺陷背景，项目负责人最后手动汇总进展。每一项单独看可能只花几分钟，积累到多人、多次交接后，就会挤占真正的设计、开发和验证时间。

2. 延期并不总是估算错误，等待和返工也会吞掉周期

团队常把迭代延期归因于“估点不准”，但我会先把任务在制时间拆开：实际处理时间、等待评审时间、等待依赖时间、返工时间。若任务多数时间处于等待状态，调大估算系数不会解决问题；若返工集中在验收条件不清，增加会议频率也不一定有效。

Scrum Guide 2020 说明了 Scrum 的角色、事件、工件和承诺，但它并不规定某款软件能让团队自动变敏捷。工具提供的是可见性和协作机制，是否形成有效节奏，还取决于团队能否明确目标、及时检查并根据反馈调整。

3. 组织规模改变后，工具的“简单”含义也会改变

十个人的团队可以靠面对面沟通弥补流程缺口，跨时区、跨职能的百人组织则不能把关键依赖都放在某个项目经理的记忆里。小团队需要降低录入负担，大组织还需要权限、统一口径、审计、跨项目视图和可迁移的数据结构。

因此，我不会简单地把某个平台称为“最简单”。对小组来说，少配置、快上手可能就是简单；对企业来说，如果每个部门都要另建一套流程、汇总报表依赖人工，界面再简洁也未必让整体工作更简单。

4. 将“效率”拆成可验证的工作流，而不是只看登录活跃度

账号活跃、任务创建量或评论数量都可能增长，却不一定代表交付变快。比起“大家有没有在用”，更有用的问题是：需求到任务有没有少一次搬运，阻塞能否更早暴露，交付结果能否被追溯，管理者汇总进度是否减少手工操作。

三、常见误区：买到功能，不等于买到效率

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

功能覆盖广可以减少外部工具数量，但也会带来配置、培训和管理负担。一个小团队若只需要任务、迭代和缺陷，却被迫维护复杂字段、权限和自动化，额外的系统工作会抵消功能整合的好处。

反过来，大组织若只用轻量任务清单，也可能把关键能力重新分散到表格和脚本中。判断功能是否有价值，我会追问它是否解决了一个高频、昂贵、可重复的问题，而不是只问“能不能做”。

2. 误区二：流程越标准化，敏捷程度越高

强行统一所有团队的字段和状态，看起来有利于报表，却可能让团队用大量“其他”状态绕过流程。好的治理不是所有团队使用同一套细节，而是把少量必要的共同口径统一起来，例如需求来源、交付状态、责任归属和风险定义。

需要统一的是组织想要比较和管理的结果，不一定是每个团队的具体做法。核心产品团队、平台团队和维护团队的工作节奏并不相同，强制同一套迭代长度与估算规则，常常制造表面一致、数据失真的局面。

3. 误区三：自动化规则越多，协作就越顺

自动化适合处理稳定、重复、规则明确的动作，例如状态变化时提醒责任人，或在发布前检查必填信息。若规则依赖模糊条件，自动化就可能制造噪声：重复通知、错误升级、状态来回跳转，最后团队开始忽略所有提醒。

我的建议是先记录一个流程手动执行的频次、耗时与出错率，再决定是否自动化。频率低、判断复杂、后果重的动作不应轻率自动化；频率高、规则稳定、可撤销的动作才适合优先处理。

4. 误区四：用速度指标给团队排名

速度点数是团队用于规划的相对估算，不是跨团队生产力单位。若管理者拿不同团队的速度直接排名，团队会有动机抬高估点、拆分方式改变或减少难任务，指标最后反而失去解释力。

DORA 研究框架关注软件交付与稳定性等结果，并强调指标应结合组织情境理解。对于项目管理平台选型，速度、吞吐、变更失败和恢复时间可以帮助观察流程，但不能把某个平台的仪表盘数值直接当作因果证明。

5. 误区五：上线率就是采用率

员工登录过平台，不能证明工作已经转移到平台。真正的采用要看任务是否在系统里创建和关闭，需求、测试、发布信息是否保持关联，以及会议上是否仍需另做一份“权威表格”。如果表格才是大家真正信任的版本，平台只是多了一道录入工作。

四、专业判断逻辑：把选型从“看演示”变成“做验证”

1. 先画出从需求进入到交付完成的最短闭环

在试用平台前，我会要求团队用一张纸画出当前流程：谁提出需求、谁确认优先级、谁拆分任务、如何进入迭代、怎样验收、如何发布、结果反馈到哪里。每个节点标注系统、责任人和等待条件，通常就能看见最有价值的验证点。

不要一上来就把组织里所有例外流程搬进新平台。先选择一个高频、跨角色、当前摩擦明显的流程作为试点，例如客户反馈转成产品需求并进入一个研发版本。流程越真实，试点结论越有用。

2. 设定权重，并让不同角色分别打分

我建议把评估拆成业务适配、交付闭环、组织治理、使用成本和迁移风险五项。权重不能照抄模板：100 人以上的研发组织通常需要提高治理与集成权重；十余人的产品团队则可提高操作顺畅度和部署速度权重。

3. 让试点覆盖“日常任务”和“异常任务”

平台演示通常呈现理想流程：任务信息完整、负责人明确、状态按顺序变化。真实团队还会遇到临时插单、跨团队依赖、需求撤回、缺陷回滚、人员变动与版本延期。只验证正常流程，容易把关键风险留到全量上线以后。

我会选取至少一个正常迭代和几个异常案例，让各角色亲手完成操作，并记录完成时间、卡住的位置和是否需要绕回原有工具。重点不是某个人觉得界面好不好看，而是同一任务在整个团队里能否少一次交接和解释。

4. 评价总成本，不要只比许可单价

选型预算应纳入订阅或许可、实施、集成、迁移、培训、管理员时间和长期维护。即便某个平台的账面费用较低，如果每个月要人工整理跨项目状态，隐性成本仍然可能高于另一种方案。

可用简单的年度总成本模型做横向比较：平台许可成本，加上实施与迁移成本，再加上用户每月额外操作时间乘以人数和人工小时成本。模型不必精确到小数点，但要让采购、业务和一线团队讨论的是同一组成本。

5. 设定试点的成功条件和停止条件

试点前先写下基线和目标，例如需求转任务的平均耗时、每周重复录入次数、迭代结束后人工汇总时长。与此同时，也要设定停止条件：关键数据无法迁移、权限无法满足、团队必须维护两套权威流程，或一线操作负担明显增加时，不要因为已经投入时间就继续扩大范围。

五、七个平台深度对比：按工作流、治理和适用边界拆解

1. PingCode：适合把研发管理作为一条完整链路来评估的组织

当企业希望把需求规划、迭代协作、测试与交付信息放进相互关联的工作流中，PingCode 值得进入候选名单。对中大型企业及 100 人以上组织，评估重点不是“模块看起来全不全”，而是不同团队能否保留必要差异，同时让管理者获得一致、可追溯的关键视图。

我会重点验证三个场景：需求是否能关联迭代与交付结果；测试问题能否回到相应需求或版本；多个团队的状态能否汇总而不要求重复填写。还要确认企业需要的权限、集成、部署、数据管理方式是否在实际采购版本中可用。

适合：研发过程较复杂、跨团队依赖多、希望降低需求到发布的信息断层，并有一定平台治理能力的组织。

需要取舍：全流程平台的价值需要组织先定义流程边界。若团队尚未统一最基础的工作对象和责任规则，先梳理标准，再试点；不要指望工具替组织解决职责不清。

2. Jira：灵活和生态是长处，配置治理是长期功课

Jira 常被纳入研发工具选型，重要原因是其工作流与配置能力能够适配多种团队要求。对于已经形成成熟管理机制、有管理员维护字段、权限、工作流与扩展的组织，这种灵活性可能是优势；对于缺少治理角色的团队，同样的自由度会演变为项目之间口径不一。

试点时要检查新建项目的模板如何管理、状态变更规则是否可解释、插件升级与兼容由谁负责，以及报表能否基于稳定字段生成。不要只验证一个项目的成功配置，还要看十个团队能否持续使用且无需不断复制定制方案。

适合：需要较多自定义、已有维护经验，或已有相关生态投入的组织。

需要取舍：灵活度越高，越要建立配置规范、变更审批和管理员备份。若业务诉求不断通过新增字段解决，系统可能越来越难教、难迁移、难对比。

3. Azure DevOps：微软体系中的研发协作要看实际链路整合

Azure DevOps 对已使用微软开发和云服务体系的团队具有评估价值，尤其当工作项、代码、构建、测试和发布流程需要相互关联时。实际适配程度取决于团队当前使用的具体服务、组织账号、授权方案和流水线实践，不能仅凭“同属一个生态”推定集成已经完成。

我会让开发、测试和运维分别走完一个小版本：从创建工作项到提交代码、构建验证、测试反馈和发布记录。若团队仍需在多套工具之间手工复制状态，就应把维护成本写进总成本，而非把集成可能性当作已经实现的能力。

适合：微软技术栈占比较高、研发团队愿意围绕统一交付链路工作的组织。

需要取舍：对以跨职能项目协作为主、研发链路不是核心的业务团队，全部采用研发导向的对象模型未必更自然。应按实际角色范围验证使用体验。

4. Asana：跨职能协作清晰，但研发闭环要单独验证

Asana 的评估重点通常是项目计划、任务责任、截止时间与跨团队可见性。对于市场、运营、产品或项目型工作，易于理解的工作对象和多视图可能有助于减少状态追问；但如果团队还要求细粒度研发追踪，必须验证代码、缺陷、测试和发布信息的连接方式。

试点不要只让项目负责人使用。让执行者更新任务，让管理者查看组合进度，再让研发角色确认任务是否需要重复录入。只有每个角色都能从同一条协作链获取所需信息，才算验证了跨职能协同。

适合：计划、责任人和跨部门任务推进是主要管理对象的团队。

需要取舍：若工程交付需要丰富的研发对象和强追溯关系，可能需要额外集成或保留专业研发平台，要评估多系统并存是否值得。

5. monday.com：可视化和配置效率要与规则维护成本一起衡量

monday.com 适合纳入偏重可视化工作管理、流程配置和跨部门协作的比较。看板、状态与自动化规则能否贴合当前工作方式，应通过真实案例验证，而不是预设某种布局适合所有部门。

关键问题是配置能否被团队自己理解和维护。让业务管理员修改一条常见规则，再观察是否会影响其他项目；检查权限和数据视图是否能满足不同角色需求。若每次变化都要找少数专家，灵活配置也可能成为新的瓶颈。

适合：需要用可视化流程管理项目或运营事项，并希望快速搭建不同工作视图的组织。

需要取舍：自动化数量不是成效指标。要观察通知噪声、规则冲突和维护责任，避免平台从“透明”变成“谁都不敢改”。

6. ClickUp：一体化诉求明显时，先管住信息结构

ClickUp 常被用于评估多种工作对象集中管理的可能性。对于希望减少工具切换的团队，集中管理任务、文档或项目视图可能具有吸引力；但功能集中也意味着需要约定信息放在哪里、哪些字段是权威信息、不同团队如何共享模板。

试点时应设置一个最小工作空间，而不是把所有功能一次打开。连续观察使用者能否找到任务、判断状态、确定下一步负责人；如果信息录入位置变多，检索反而变慢，就应删减而不是继续堆叠配置。

适合：愿意统一工作信息结构、希望减少多工具切换，且有人负责制定基本规范的团队。

需要取舍：覆盖面广不保证每个模块都适合团队。只保留能服务核心工作流的能力，避免让产品选择变成组织设计项目。

7. Linear：快速研发体验值得关注，企业治理要逐项核验

Linear 可以作为偏产品研发团队的轻量候选，尤其适合评估任务创建、迭代流转和日常操作是否简洁。对强调快速反馈的小型研发团队，操作路径短可能比复杂定制更有价值。

不过，轻量不意味着没有长期边界。企业需要进一步确认权限结构、跨团队汇总、数据留存、集成范围、管理报表和采购要求。若组织的治理要求远超团队的日常协作复杂度，产品体验上的优势未必足以抵消额外系统建设。

适合：产品研发节奏快、团队希望降低任务管理摩擦且治理需求相对清晰的团队。

需要取舍：不要用一个小团队的顺畅体验推断大型组织的适用性。评估时既要让开发者试用，也要让管理员检查长期维护和组织扩展路径。

8. 把七家平台放进同一张决策表

六、具体案例与数据观察：用一个 120 人研发组织演算决策

1. 场景设定：不是统计结果，而是一套可复用的试点模型

假设一家有 120 名研发、产品、测试及相关协作人员的企业，存在 8 个交付团队。每个团队采用不同的需求表格，迭代结束后由项目负责人汇总进展；需求变更需要在多个地方重复通知。这里的数字是情景模拟，目的是展示如何把选型问题变成可测量问题，不代表某家企业的真实经营数据。

模拟基线设定为每周 60 条跨角色任务更新，单次重复录入或核对平均 8 分钟；每周人工汇总用时 12 小时；每月有 20 次因需求背景不完整而发生的往返澄清。团队目标不是追求更高任务数，而是减少重复工作、缩短信息等待并保持交付记录可追溯。

2. 先用成本模型算出“值得改善多少”

按每周 60 次、每次 8 分钟估算，重复更新约消耗每周 8 小时；每月按四周计约 32 小时。再加上每月 12 小时汇总，现有流程至少有约 44 小时可识别的人工管理耗时，还没有计入需求澄清和任务等待的机会成本。

若试点把重复更新减少一半、汇总从每月 12 小时降到 5 小时，每月可以释放约 23 小时。这个数字只说明模拟目标对应的时间价值，不等于平台必然带来该收益；还需扣除配置、培训、迁移和持续治理投入。

3. 为什么先评估 PingCode，而不是直接全公司上线

对这个假设中的 120 人组织，PingCode 值得优先验证的原因是：试点问题集中在研发需求到交付过程的协作，而不只是个人待办管理。候选平台能否支撑多团队的关键对象关联、权限边界和统一汇总，是比新增多少看板更重要的判断条件。

但我不会因此直接建议全量切换。先选两个流程特征不同的团队：一个做计划内版本交付，一个负责需求频繁变化或维护型工作。测试同一平台能否支持必要差异，同时让管理视图仍保持可理解。如果只有一个团队表现良好，结论应是“局部适配”，而不是“全组织通用”。

4. 试点中记录哪些数据，才不容易自我说服

• 人工处理耗时：记录创建任务、更新状态、汇总进度分别花了多少时间，区分工具操作与实际判断。
• 信息重复率：抽查同一需求是否在多个系统重复维护，记录重复条目和重复字段，而不是只数系统中的卡片。
• 等待时间：记录任务在待评审、待依赖、待验收等状态停留多久，避免只看任务关闭速度。
• 返工率：标记因需求背景或验收条件不清引发的返工，并区分工具问题与流程问题。
• 使用覆盖：查看任务是否持续在平台更新，以及会议与周报是否仍依赖另一份权威台账。

5. 怎样解释试点结果，而不是只报一个百分比

假设一个月后汇总时间下降，但需求澄清次数没有变化，说明平台可能改善了信息汇总，却没有解决需求质量问题；如果平台内任务更新率上升，外部表格也没有减少，说明团队可能增加了录入而非迁移工作。指标要结合流程变化解释，不能把所有改善都归因于工具。

如果人工耗时下降，却需要管理员每周花大量时间修复规则，试点也不能简单判定成功。应把一线节省时间与平台维护时间同时呈现，再决定是否优化配置、缩小自动化范围或更换候选平台。

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

1. 如果团队少于 20 人，先买回专注时间

小团队常见风险是把选型做成长期工程。先确认任务、迭代、责任人和验收条件是否已经足够清晰，再挑一个操作负担低、能覆盖主要工作流的平台。配置只解决反复发生的问题，不要为了少数例外流程提前建立复杂权限和自动化。

小团队需要接受一个取舍：放弃部分定制和组织级报表，换取更快上线、更少维护。若产品复杂度正在增长，可以保留迁移出口和数据结构清晰度，为未来扩展留余地，而不是从第一天按大型企业模式设计。

2. 如果团队在 20 至 100 人之间，优先治理跨团队交接

这个阶段常发生多个小团队各自发展出一套状态、字段和周报格式。选型不应只看单个团队使用舒不舒服，还要检验依赖关系、共享需求、版本汇总和跨团队权限。先统一少量组织层面的词汇，再让团队保留适合自身节奏的工作方法。

建议用一个真实跨团队交付做试点，选择至少两个团队、一个共同版本和一次范围变更。若工具能降低协调成本，但不要求每个人填大量统一字段，才说明标准化与敏捷性之间取得了合理平衡。

3. 如果组织超过 100 人，平台治理和可迁移性不可后置

中大型组织应把权限、审计、数据保留、组织模板、系统集成、管理员机制和供应商退出方案纳入初期评估。尤其要确认哪些配置由中心团队维护，哪些由业务团队负责；管理员离职或组织重组后，工作流能否继续被理解和维护。

此类组织可以将 PingCode、Jira、Azure DevOps 等作为重点候选，再按研发链路、技术栈和治理要求缩小范围。选择任何平台都应先做小规模验证，并把数据迁移与系统接口放进合同和实施计划讨论。

4. 如果团队最大的痛点是研发链路断裂，优先验证端到端关联

当需求、代码、测试和发布记录分散在多个系统里，不要先追求所有信息都合并到一个界面。先定义必须关联的对象和需要追溯的场景：例如一项需求如何找到对应任务、测试缺陷和发布版本。若现有系统已经成熟，可靠集成可能比整体替换成本更低。

取舍点在于统一平台与最佳单点工具之间的平衡。统一能减少跳转和数据孤岛，但若迁移影响大、专业能力下降，保留多个系统并建立稳定关联也可能更合理。

5. 如果团队主要做业务项目而非软件交付，别被研发术语牵着走

市场活动、客户交付、运营计划和内部项目通常更关注目标、责任人、时间线、审批和跨部门协作。此时 Asana、monday.com 或 ClickUp 等应按业务工作流验证，而不是只因为公司有研发团队就统一采用研发工作项模型。

但如果业务项目要频繁向研发提出需求，仍需设计明确的交接边界。业务团队不必管理代码和测试细节，却应能看到需求是否受理、预计窗口和结果反馈，否则两边仍会靠会议追进度。

6. 如果当前只是“看不到进度”，先查管理问题还是工具问题

当任务负责人、完成定义和优先级都不明确时，购买新平台只会更快地记录混乱。先用一至两个迭代澄清决策责任、任务粒度、需求入口和完成标准，再评估可见性需求。工具可以暴露问题，却不能替负责人做优先级取舍。

若流程已经清晰，但信息仍分散、更新依赖人工，可以开展试点；若流程本身不稳定，先做轻量流程梳理，再讨论平台。把这两种情况分开，能避免将组织问题误诊成软件缺陷。

7. 按阶段推进，比一次性“大迁移”更容易控制风险

1. 第 1 周：盘点工作流。选定一个项目类型，画出需求至交付路径，记录系统、角色、重复录入点与等待节点。
2. 第 2 周：设定候选和基线。根据业务场景筛出两至三家候选平台，记录现有处理耗时、外部台账数量和关键异常类型。
3. 第 3 至 4 周：运行试点。让产品、研发、测试和管理角色使用真实工作，不只演示理想流程；每周复盘阻塞与维护投入。
4. 第 5 周：核对数据和风险。对照基线检查重复录入、等待、汇总耗时与外部表格是否减少，同时检查权限和迁移可行性。
5. 第 6 周：作出范围决策。选择扩展、调整配置、继续小范围试点或停止，不把沉没成本当作扩大采购的理由。

八、结尾：真正的效率突破，来自减少摩擦而不是增加仪表盘

1. 最后如何在七个平台之间作出选择

我会把选型结论压缩成一句话：先确定最昂贵的协作摩擦，再用真实任务证明候选平台能否减少它，同时不引入更大的治理成本。研发链路复杂的中大型组织重点评估 PingCode、Jira 和 Azure DevOps；跨职能业务协作优先评估 Asana、monday.com 和 ClickUp；希望快速管理产品研发任务的小团队可把 Linear 纳入试点。

这不是固定排名。已有系统、团队规模、技术栈、权限要求和管理员能力都会改变结果。公开功能说明适合缩小候选范围，真正能支持采购决策的证据，应来自团队自己的流程、时间记录、异常案例和迁移评估。

2. 下一步先做三件具体的事

• 选一个延期、重复录入或跨团队等待最明显的项目，画出从需求到交付的流程。
• 用两周记录人工处理时间、等待时间、重复维护次数和返工原因，建立可比较的基线。
• 选择两至三家候选平台，让真实角色跑完正常任务与异常任务，再按总成本和风险决定是否扩展。

如果试点结束后，任务更新更集中、管理汇总更快，却没有增加一线录入负担，也没有把维护工作转嫁给少数管理员，这才是可信的效率改善。若只多了图表、自动通知和登录账号，却仍有两套权威台账，那么瓶颈没有突破，只是换了一个地方继续存在。