范围变更落地方案：项目经理开展项目范围的实操方法案例解析

很多项目经理来问我范围变更的问题，开场几乎都是同一句话：“客户昨天又提了个需求，我该不该拦？”我一般不会直接回答该不该拦，而是先反问三个数：你项目的范围基线是哪一版？这次变更影响多少个已经排期的任务？谁有权限批？问完这三个问题，九成的人自己就沉默了。因为我做了十几年交付和 PMO，见过太多项目不是死在需求多，而是死在变更没有“落地的容器”，没有基线、没有分级、没有影响评估、没有审批记录、没有验证闭环。

需求像水一样流进来，项目像沙一样流出去。

这篇内容我不打算再复述一遍“范围蔓延的定义、成因、危害”。你随便搜都能找到一份百科式目录。我要讲的是另一个层次的问题：当一个范围变更真实出现在你面前，从它被提出、被评估、被决策、被写进基线，到被验证关闭，中间每一步到底谁做什么、产出什么文件、卡在什么地方。我会用一套七步闭环、一张一页纸变更单、一份 RACI 分工、三个真实场景的拆解来讲清楚，并且告诉你哪些环节在 50 人团队里根本不需要，哪些环节哪怕只有 5 个人也必须保留。

一、先给结论：范围变更落不了地，问题几乎从不在“审批”，而在“基线”

我先把最核心的判断放前面，后面所有内容都是围绕它展开。范围变更之所以失控，绝大多数时候不是审批流程太松，而是项目从一开始就没有一份双方认可、版本明确的范围基线。没有基线，就谈不上“变更”，只能叫“补充”“完善”“之前忘了说的”。项目经理在这种语境下永远是被动的，因为你无法证明“这是新增”，对方也永远可以说“这本来就是需求的一部分”。

第二个判断是：落地能力等于“把口头需求转化为可比较、可谈判、可签署的结构化对象”的能力。区别不在于你懂不懂 PMBOK，而在于你会不会在客户说“这个小功能加上吧”的十分钟内，给出三个带代价的选项。第三个判断是：变更控制不是一道闸门，而是一条流水线，它的价值在“节奏”，不在“驳回率”。一个健康的项目，变更提出量不低，但大部分变更在澄清和替代方案阶段就被消化掉了，真正走到基线更新的只是少数。

1. 三个判断的优先级

如果只能记住一句话，我建议记住这个顺序：先有基线，再有分级，最后才是审批。很多团队一上来就搭 CCB、建变更流程，结果发现流程跑了两个月没人提变更，因为大家根本没有基线，所有需求都被当作“日常沟通”消化掉了，压根进不了流程。这是典型的本末倒置。

我理想中的落地顺序应该是：定义并封版范围基线 → 设置变更分级和触发条件 → 定义评估模板 → 明确决策权限 → 建立记录与通知机制 → 做验证和复盘。审批只是其中一环，把它放到最前面，你会得到一堆签字齐全但依然烂尾的项目。

2. 一个反常识的数字

我在过去五年参与过的四十多个中大型交付项目里，做过一次内部抽样复盘：凡是后期严重延期（超过原计划 30% 以上）的项目，前期记录在案的正式变更数量往往反而不多。听起来矛盾，但原因很直接，变更没有记录，需求走的是口头和群聊，到了验收才集中爆发，那时候已经无法区分“原始范围”和“新增范围”了。

二、真实场景：一个功能加不加，为什么能让项目多干六周

我把最近两年印象最深的一个场景还原一下。这是一家中型制造企业的数字化项目，客户是集团信息中心，乙方是软件供应商，我做的是乙方的外部 PMO 顾问。项目做到集成测试阶段，客户的分管副总在一次周例会上说：“系统里审批流现在只能两层，我们分公司实际有三级审批，这块能不能加上？应该不难吧，就是多一个节点。”

乙方项目经理当场答应：“没问题，我们看看。”这句话是整件事的转折点。会后他没有做影响评估，直接把需求转给了研发负责人，研发负责人评估说大概三天。于是需求进了开发队列。三天后做完，测试发现三级审批牵扯到权限模型、代理人机制、跨组织数据隔离，实际连带改动是十九个工作日，还冲掉了两个已经排期的报表任务，最终把集成测试里程碑推后了六周。

1. 失控是从哪一步开始的

如果复盘这个案例，问题不在客户提需求，客户提需求天经地义。问题出在三个具体动作上。第一，项目经理用“没问题”替代了“我需要评估后回复”，把不确定变成了承诺。第二，研发负责人只评估了编码工时，没有评估连带影响，忽略了权限、测试、文档、培训这些下游成本。第三，整件事没有任何书面记录，直到六周后甲方追问工期，大家才发现这次“小改动”从来没进过变更台账。

我把它抽象成一个更容易复用的观察：范围变更的损失，往往在“承诺那一刻”就已经发生，而不是在开发那一刻。承诺之后的所有工作，都是在为一个已经做出的决定找补。

2. 如果把时钟拨回去

正确做法其实不复杂。项目经理在会上应该说：“这个需求我理解了，我需要评估它对进度、成本、测试范围的影响，明天中午前给你三个方案。”会后立刻记一条变更登记，拉一次 30 分钟的影响评估会，产出一页纸的方案对比。第二天给客户看：方案一，原计划不变，三级审批放到二期；方案二，本期加，工期顺延六周，成本增加 X；方案三，本期先用配置方式做简化版三级审批，满足合规底线，完整版放二期。

你会发现，一旦给出带代价的选项，客户的决策往往比项目经理预想的理性得多。在那个案例里，如果当时给了这三个选项，客户大概率会选方案三。范围变更落地的本质，是把“要不要做”的模糊争论，转化成“用哪个代价做”的明确决策。

三、拆解四个高频误区：你可能一直在用错的方式控制变更

讲完场景，我想把最常见的四个误区单独拆开说，因为它们几乎出现在我接触过的每一个失控项目里，而且每一个听起来都很有道理。

1. 误区一：把“拒绝变更”当作范围管理能力

有些项目经理走另一个极端，把所有变更都当成敌人，动不动就说“这不在范围内”“要做请走变更流程”。这种姿态短期能挡住一部分需求，但代价是合作关系迅速恶化，客户会绕开你直接找老板或销售，变更从明面转入地下，你反而更难控制。

我的判断是：变更控制的目标不是降低变更数量，而是让每一个变更都在可控、可追溯、可谈判的状态下发生。健康项目的变更提出量往往不低，但因为评估快、决策快、记录全，反而不积累风险。你要防的不是变更，是“未经评估就承诺”和“进了开发还没记录”。

2. 误区二：用“影响不大”代替影响评估

这是最普遍的问题。影响评估的口头版本通常是“大概几天吧”，而真正的影响至少包含六个维度：范围、进度、成本、质量、资源、风险。软件项目里，一个看似简单的字段新增，可能牵动数据库迁移、历史数据兼容、接口协议、报表口径、权限继承和测试用例。

所以我坚持影响评估必须落到纸面，哪怕只有半页。写下来的过程本身就会暴露你没想到的东西。口头评估的准确率，我的经验值大约在 40% 左右，书面评估能提到 75% 以上，差别不在能力，而在“被迫想全”。

3. 误区三：所有变更都走同一条流程

很多团队的变更流程只有一个入口、一个审批层级，结果就是小改动被大流程拖死，大改动因为流程太长被绕过。三个月后，团队开始用“紧急通道”处理一切，流程名存实亡。

正确的做法是按影响程度分级。我通常分三级：澄清级、一般变更、重大变更。澄清级不需要审批，只需要记录；一般变更由项目经理和业务负责人确认；重大变更才上升到 CCB 或发起人层面。分级的价值在于把决策成本匹配到影响成本上。

4. 误区四：审批通过就等于变更结束

这是最隐蔽的误区。很多项目的变更流程到“审批通过”就画句号了，后面没有人去更新基线、通知相关方、更新测试用例和验收标准。结果就是计划书上还是老范围，开发做的是新范围，测试测的是旧用例，验收时双方各执一词。

我一直强调一个观点：审批通过只是变更的中点，不是终点。真正的落地动作在审批之后，更新范围说明书、更新 WBS、更新进度基线、更新验收标准、通知所有受影响方、执行、验证、关闭、复盘。这一串动作少一个，变更就有一条腿悬在空中。

四、专业判断逻辑：什么情况必须走变更，什么情况只需要澄清

上面讲的是误区，接下来讲判断标准。项目经理每天要处理几十个需求信号，如果每一个都要走流程，团队会被流程压垮；如果全部靠感觉，风险会累积。所以你需要一套可快速执行的判断标准，最好能在两分钟内做完判断。

1. 触发变更的五个硬条件

我的判断规则很简单：只要满足以下任意一条，就必须进入正式变更流程，不接受口头处理。

• 影响验收标准：改变了交付物清单、功能边界、性能指标或合规要求。
• 影响已承诺的里程碑：导致任何一个对外承诺的交付节点需要顺延。
• 影响成本或资源投入：需要追加预算、追加人力，或占用已分配给他人的资源。
• 影响其他模块或接口：牵动已冻结的设计、已完成的开发、已确认的接口协议。
• 影响合同或付款条件：涉及交付物范围、验收方式、付款节点的调整。

反过来说，如果一条需求不影响上述任何一项，它大概率属于澄清或优化范畴，记录即可，不必升温。这个判断标准最大的价值是把争论从“这算不算变更”转成“它触发了哪一条”，沟通效率会高很多。

2. 变更分级的三档设计

我在实际项目里用的分级表大致是这样，你可以直接改成自己组织的版本。

分级里最容易被忽视的是处理时限。很多变更流程失败，不是因为评估不准，而是因为决策太慢。需求方等了一周没回复，就直接绕过流程找研发了。所以时限必须写进流程，超时要有默认处理规则，比如“超时未决策视为维持原范围，需求转入下期评估”。

3. 判断逻辑的执行顺序

把上面的内容串成一个可以贴在工位上的执行顺序：听到需求 → 先判断是否触发五个硬条件 → 不触发就登记为澄清项 → 触发就定级 → 按级别拉对应评估 → 产出方案选项 → 交给对应决策人 → 决策后更新基线 → 执行验证 → 关闭复盘。

这九步听起来长，实际执行时前四步通常十分钟内能完成。真正耗时的是影响评估和方案设计，而这两步恰恰是大多数团队跳过的部分。

五、落地七步闭环：每一步做什么、产出什么、谁负责

这是整篇内容最核心的部分。我把范围变更从提出到关闭拆成七步，每一步都给出动作、输出物和责任人。你在实际使用时可以裁剪，但不建议跳过第 2 步和第 5 步。

1. 第一步：提出与登记

任何来源的需求，只要可能触发硬条件，第一动作是登记，不是评估。登记需要的最小字段包括：变更编号、提出人、提出日期、业务背景、期望效果、期望时间。注意这里不写解决方案，因为一旦提出人写了方案，讨论就会被方案绑架，而不是回到真实问题上。

登记的价值在于建立时间戳。后面无论工期怎么调整、责任怎么划分，“什么时候提的”永远是第一份证据。我见过太多项目经理在验收时被问“这个需求为什么没做”，如果有登记记录，答案就变成“X 月 X 日提出，当时评估结论是转入二期，您也确认过”。

2. 第二步：影响评估（六维度）

影响评估我坚持六个维度全覆盖，缺一个都会在后面出问题。范围维度问的是交付物和验收标准变了没有；进度维度问的是哪些任务、哪些里程碑受影响；成本维度问的是工时、预算、外部采购的变化；质量维度问的是测试范围、回归量、缺陷风险的增加；资源维度问的是需要动到哪些人、是否与他人冲突；风险维度问的是新技术、新依赖、新合规要求带来的不确定性。

评估会上我通常要求研发、测试、实施三方都在场，哪怕只有十五分钟。只让研发评估是最大的陷阱，因为研发天然只关心编码，而测试和实施往往才是真正的成本黑洞。上一节那个案例里，测试与回归占了整整三天，研发一开始完全没算进去。

3. 第三步：设计替代方案

这一步是很多项目经理的盲区，但它是把“要不要做”转成“怎么做”的关键。我一般要求至少三个选项：原范围不变（延后或不做）、按原样做（承担全部代价）、折中方案（部分满足、分阶段交付、用配置替代开发）。

三个选项不是形式主义。当你只给一个选项，客户要么接受要么拒绝，谈判变成对抗；当你给三个选项，讨论就转向“哪个更划算”，决策从立场之争变成方案比较。这也是我这么多年做交付谈判最有效的一招。

4. 第四步：决策与审批

按上一节的分级表交给对应决策人。审批环节我强调两点。第一，审批要留痕，聊天记录不算，要有明确的记录载体。第二，审批结论必须包含“生效范围”而不只是“同意”。我见过太多审批只写“同意”，结果执行时双方对“同意到什么程度”理解不同，又吵一轮。

另外，紧急变更需要单独通道。生产事故、合规时限、监管要求这类情况不能等五个工作日，可以设“先执行后补批”的机制，但必须限定触发条件、限定补批时限（我一般设 48 小时），并指定唯一批准人。

5. 第五步：更新基线（最容易被跳过）

这一步是审批之后最关键的落地动作，也是最常被跳过的。需要同步更新的至少包括：范围说明书、WBS 与任务清单、进度基线、资源分配、测试用例、验收标准、合同或附件。任何一项没更新，都会在未来某个时点以“责任不清”的形式爆发。

我给团队的要求是：变更审批通过后的 24 小时内必须完成基线更新，超出时限要有书面说明。这条规则听起来苛刻，但它是防止“审批通过却没人执行更新”的唯一有效手段。

6. 第六步：执行与验证

执行阶段最重要的不是埋头开发，而是把变更项纳入日常跟踪。我建议在项目的任务看板里给变更项打标签，让变更工作量可视化。这样你能在周报里清楚说明：本周有 30% 的产能消耗在变更上，进度偏差与此相关。这比事后解释有用得多。

验证阶段要把验收标准拿出来对照，确认交付物符合变更后定义。这一步不能由开发自己确认，最好由测试或业务方独立验证，避免“自己写自己判”。

7. 第七步：关闭与复盘

关闭动作包括：确认交付、关闭变更单、归档记录、通知所有相关方。复盘动作则更长期：统计这个月的变更数量、审批平均周期、因变更产生的返工工时占比、哪些变更本可以通过前期需求澄清避免。

复盘的价值不在单次，而在趋势。如果某个项目连续三个月变更数量上升，且集中在同一模块，那说明需求调研阶段有系统性缺口，需要调整前端流程，而不是继续在后端补漏。

六、案例解析与工具落地：从一个三级审批需求看完整闭环

上一节的七步是骨架，这一节我用一个完整案例把它串起来，同时讲一下工具层面怎么承载。案例仍然是脱敏和重构过的，数据为方法演示用途，不对应具体企业。

1. 案例背景与冲突

某集团采购管理平台项目，乙方交付，甲方为集团信息中心和三家子公司。项目已进入集成测试，距 UAT 还有三周。甲方合规部提出：采购审批从两级改为三级，且子公司需要在第三级中加入财务复核角色。提出理由是该季度内审发现两级审批存在合规风险。

冲突点很明确：三周后 UAT，这个需求涉及权限模型改造、角色配置、跨组织数据隔离。如果全做，UAT 必延；如果拒绝，合规风险无法交代；如果做简化版，需要合规部确认底线。

2. 影响评估的六维度展开

按七步法第二步，评估结果大致是：范围维度，新增一个审批节点和一个复核角色，验收标准中的审批流转用例需要重写；进度维度，影响权限模块和测试回归，UAT 预计顺延两周；成本维度，累计约十九人天，其中开发十一天、测试五天、文档培训三天；质量维度，已有审批用例需全量回归，新增用例约二十条；资源维度，需要抽调已投入报表模块的一名后端；风险维度，跨组织数据隔离可能触及历史数据兼容，存在不确定性。

注意这里最有价值的不是总数，而是风险维度的不确定性标注。它让决策者知道这不是一个确定的十九人天，而是一个“十九人天起，可能更高”的范围。这个信息直接影响决策质量。

3. 三个方案如何呈现

三个方案一摆出来，讨论立刻从“能不能做”转向“合规底线到底在哪里”。最终甲方合规部确认，本期内审关注的是审批层级数量，财务复核可以在二期落地，于是选择方案三。从提出到决策，全过程四天，实际延期三天，而不是最初担心的两周或全面失控。

4. 工具层面怎么承载这条流程

案例能四天闭环，一个重要原因是这个项目用了结构化的工作项管理来承载变更。我们的做法是把变更单本身当作一个工作项类型，和需求、任务、缺陷并列，只是字段不同。这样带来的直接好处有三个：变更单有独立编号和状态流转、评估字段结构化可统计、它与被影响的任务能建立关联关系。当变更审批通过后，能直接看到它挂接了哪些任务，基线更新不会遗漏。

工具选型上，如果是中大型企业、组织层级多、合规要求高、需要私有化部署或从 Jira 平滑迁移的场景，可以考虑 PingCode 这类面向中大型组织和 100 人以上团队的项目管理平台，它对工作项类型自定义、变更流程配置、权限与审批链的支持比较完整，也支持私有化部署和从 Jira 迁移，适合作为国产替代方案的候选之一。但如果你的团队只有十几个人、项目周期三个月以内、甲方也接受口头确认，我反而不建议上重工具，一张共享表格加每月一次复盘会更划算。

这里我要说一个经常被忽略的判断：工具解决的是“记录完整”和“可追溯”，解决不了“评估质量”和“决策意志”。我见过用着完整平台但变更照样失控的团队，因为影响评估是走过场、审批是形式签字。工具只是容器，内容还得靠人。

5. 复盘：哪些机制提前做能避免被动

这个项目复盘时我们总结了三条。第一，如果需求调研阶段就把合规部的内审要求纳入调研清单，这个变更根本不会出现。第二，如果最初的范围说明书里明确写了“本期支持两级审批”，提出时就不会有“这本来就是需求”的争论空间。第三，如果每周例会有固定 10 分钟的“变更与风险”环节，这个需求可能在提出前就被合规部内部消化，而不是在副总发言后才进入流程。

这也是我一直强调的观点：最好的变更控制是让变更不发生，其次是让变更发生得早，最差的是让它发生得晚还走全流程。变更越早，代价越小，这个规律几乎没有例外。

七、模板与话术：一页纸变更单和三种沟通场景

流程讲完了，我给你可以落地的工具。这一节包含一份变更单字段清单、一份 RACI 示例，以及三类沟通话术。

1. 一页纸变更单的字段设计

我用的变更单刻意限制在一页内，因为字段太多的表格没人填。核心字段如下。

• 基础信息：变更编号、提出人、提出日期、所属模块、变更级别。
• 变更内容：原范围描述、变更后描述、业务理由、不采纳的后果。
• 影响评估：范围影响、进度影响（人天与里程碑）、成本影响、质量影响、资源影响、风险说明。
• 替代方案：至少两个备选方案的代价对比。
• 决策：推荐方案、审批人、审批日期、生效范围定义。
• 执行：基线的版本号、执行负责人、验证标准、关闭日期。

字段设计的两个原则：一是“不采纳的后果”必须填，它会迫使提出人认真思考必要性，大量低价值需求在这一栏就自我淘汰了；二是“生效范围”必须具体，不能只写“同意”，要写清楚同意到什么程度、哪些不在本次范围内。

2. RACI 分工示例

很多变更流程卡住，本质是角色不清。我习惯在项目启动时就把变更相关的 RACI 定下来，避免每次都要临时找人。

说明一下符号含义：R 是执行者，A 是最终负责，C 是被咨询，I 是被通知。中小企业如果没有正式 CCB，可以把“重大变更决策”的 A 交给项目发起人一个人，但决策记录不能省。我见过太多“老板口头同意了”最后变成“我没说过”的场面。

3. 三类沟通话术

范围变更落地，一半靠流程，一半靠沟通。我把最常用的三类场景整理成话术模板，你可以按自己的语感调整。

（1）对客户：不直接拒绝，给选项和代价

不要说的话：“这不在范围内，要走变更流程。”

建议的表达：“这个需求我完全理解它的价值。我需要先评估它对本期的进度和成本影响，明天中午前给你三个选择：一个是不影响原计划的做法，一个是完整实现但需要调整时间，还有一个是折中做法。你看了之后我们再来定。”核心是把决策权交回给对方，同时让对方看到代价。

（2）对老板：讲影响、风险、决策点

不要说的话：“客户又要加需求，怎么办？”

建议的表达：“客户新提了一个需求，我评估了影响。它会影响 UAT 时间约两周，成本约十九人天，还存在数据兼容的不确定性。我准备了三个方案，推荐方案三是本期满足合规底线、延期三天、成本六人天。需要你在周五前定，否则会影响排期。”核心是给出结构化信息和明确决策点，而不是抛问题。

（3）对团队：讲边界、优先级、版本冻结

不要说的话：“大家辛苦一下，加个班就做完了。”

建议的表达：“这个变更是客户确认过的，优先级高于 X 和 Y，本周排在前面。同时版本冻结时间不变，所以我们需要把 Z 往后挪。如果发现工作量超出预估，第一时间告诉我，我再跟客户沟通，不要自己扛。”核心是既给清晰优先级，又给反馈通道，避免团队默默超载。

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

最后一部分我讲适配。上面的七步闭环是完整版，但不同规模、不同类型、不同合同模式的项目，需要的版本完全不同。硬套全套流程，会把小项目压垮；完全不用，会让大项目失控。

1. 按团队规模取舍

10 人以下小团队：只需要两样东西，一份封版的范围清单，一张共享的变更登记表。不需要 CCB，不需要分级表，项目经理自己判断即可。关键是每次变更都要在表里留一行，并同步给所有成员。

10 到 50 人：加上分级机制和简版影响评估表。决策人通常是项目经理加业务负责人两级。这个阶段最大的风险是口头承诺，所以要把“不评估不承诺”变成团队共识。

50 人以上或跨组织项目：需要完整的分级、CCB、RACI 和基线版本管理。这个规模下，一个人脑子记不住所有变更，必须有结构化载体。可以考虑用专业项目管理平台承载，比如前文提到的面向中大型组织的平台，把变更单做成独立工作项类型，这样统计和追溯才可行。

2. 按合同模式取舍

固定总价合同：变更等于成本，必须严格执行影响评估和书面确认，因为每一分钱都是乙方垫的。这类项目我建议宁可流程重一点，也不要人情松一点。

人天或工时合同：变更本身不直接造成亏损，但会造成排期冲突和信任损耗。重点不是成本，而是节奏和透明度。你需要让客户清楚看到变更占用了多少产能。

内部项目：没有合同约束，但有资源约束。内部项目的变更往往用“优先级调整”替代审批，容易被忽视的是被替换掉的那件事是谁决定的。我建议内部项目也保留一个轻量记录，至少要写清楚“为了做 A，我们暂时不做 B”。

3. 按项目阶段取舍

需求与设计阶段：变更成本最低，处理原则是“尽量吸收”。这个阶段的变更甚至可以不走正式流程，但要在下一版基线里体现。

开发阶段：这是最常见的战场。处理原则是“评估后吸收，明确代价”。流程必须走全，因为返工成本已经真实发生。

测试与验收阶段：原则是“宁延不分叉”。这个阶段最忌讳的是强行插入变更又不调整计划，结果就是带着缺陷上线。要么延期，要么转入下期，不要两头都想要。

4. 我自己的三个取舍原则

做了这么多年，我形成了三条不会轻易动摇的取舍原则。第一，基线可以简单，但不能没有。哪怕只是一封邮件确认的功能清单，也比“大家心里都清楚”强。第二，评估可以快，但不能省。十五分钟的评估会好过零评估，书面结论好过口头共识。第三，流程可以分级，但记录不能分级。小变更可以不审批，但任何变更都必须有一行记录，因为记录是未来所有争议的唯一依据。

5. 明天就能做的五件事

如果你读完想马上动手，我建议按这个顺序做，一天之内能完成。

1. 打开你现在的项目，找出最近一次范围基线，确认它有没有版本号和确认人。如果没有，今天就补一封基线确认邮件。
2. 建一张变更登记表，字段参考第六节，先不追求完整，能记录就行。
3. 把前面讲的五个硬条件打印出来贴在工位上，或者写进团队群公告。
4. 在下一次周例会议程里加一个固定 10 分钟的“变更与风险”环节。
5. 选最近一次已经口头答应的需求，补做一次影响评估和三方案对比，即使已经做完了，也把它写进记录，作为流程起点。

范围变更这件事，真正拉开项目经理差距的从来不是知识，而是把知识变成可重复动作的能力。一个能稳定跑通“登记，评估，方案，决策，更新，验证，复盘”闭环的团队，不需要什么黄金法则，也能把项目范围守得住。而一个没有基线、没有记录的团队，就算人手一本 PMBOK，照样会在验收会上吵得不可开交。下一步，别急着优化流程，先去确认你的项目有没有一份能拿得出手的范围基线，这才是所有落地动作的第一块砖。