阶段任务怎么做？研发团队入门指南：项目阶段从0到1

上个月我帮一家 140 人的 SaaS 公司做研发流程复盘，打开他们的项目计划我愣了一下：一个为期 14 周的项目，阶段任务拆了 217 条，每条都写了起止日期和负责人，看起来非常规范。但当我问”如果今天客户要求验收，你们能拿出什么东西”，会议室安静了十几秒，最后技术负责人说，大概能演示登录和列表页。

这就是阶段任务最典型的失败方式：计划颗粒度很细，交付确定性很低。团队把”阶段”理解成了时间轴上的切片，把”任务”理解成了待办清单，却忘了阶段任务唯一的职责，把一个模糊的想法，逐段转化成可验收的东西。

这篇内容把我过去几年在几十个研发团队里踩过的坑、验证过的方法整理出来。它不打算复述教科书上的阶段划分，而是回答三个具体问题：阶段任务该拆到什么颗粒度？每个阶段的入口和出口怎么定？从 0 到 1 的第一个项目，怎么用最小成本把阶段任务真正跑起来？

一、先给结论：阶段任务的本质是”交付物，验收标准，决策点”的三元绑定

1. 计量单位是交付物，不是工时

绝大多数团队做阶段任务时的第一个动作是”排期”，而正确的第一个动作应该是”列交付物”。这两者的差别看似只是顺序，实际上决定了整个阶段的可控性。

排期思维下，团队会问”这个阶段需要做哪些事、每件事要几天”；交付物思维下，团队会问”这个阶段结束时，必须存在哪些能被第三方检查的东西”。前者的产出是一张甘特图，后者的产出是一份可验收清单。

阶段任务的计量单位应该是交付物，而不是工时。因为工时是投入，交付物是产出；投入可以注水，产出必须被检查。当你的阶段任务列表里出现”配合测试””优化代码””沟通需求”这类没有产出定义的条目时，这个阶段基本已经失去了可控性。

2. 每个阶段必须有一个可判定的出口

“可判定”是关键。很多团队的阶段出口写的是”完成开发””需求确认清楚”，这类描述无法判定真假，因为没有人能说清楚”完成”到什么程度算完成。

可判定的出口长这样：核心接口 100% 通过契约测试；未决问题数量 ≤ 3 且每条都有明确负责人和关闭日期；性能压测在目标数据量下 P95 响应时间 ≤ 300ms。这些描述的共同点是，存在一个客观事实，能让人在 5 分钟内得出”过”或”不过”的结论。

我的经验是：如果一个阶段的出口标准无法在 30 秒内被判定，那它就不是出口标准，而是一句口号。

3. 阶段任务的真正价值是提前暴露不可逆决策

研发项目里最贵的错误不是”做错了”，而是”做错了但发现得太晚”。架构选型、数据模型、第三方依赖、合规边界，这些决策一旦落地，返工成本是非线性的。

阶段任务的排序逻辑，本质上应该按”决策不可逆程度”来排，而不是按”工作量大小”来排。越不可逆的决策，越应该放在越早的阶段，即使它当时看起来工作量很小。

我见过一个团队把”多租户隔离方案”放在第四个阶段才讨论，前面三个阶段都在做业务功能。结果发现数据模型从第一天起就不支持租户隔离，整个数据层重写，项目延期 11 周。这不是执行问题，这是阶段任务排序逻辑的问题。

二、真实场景：阶段任务为什么会一步步失控

1. 场景一：把”阶段”当成时间切片

最常见的做法是按时间划分阶段，1 到 4 周是需求阶段，5 到 9 周是开发阶段，10 到 12 周是测试阶段。这种划分看起来清晰，但它隐含了一个错误假设：阶段是按时间自然过渡的。

真实情况是，阶段应该按状态跃迁划分，而不是按日历划分。需求阶段结束的标志不是”第 4 周到了”，而是”需求基线被冻结且评审通过”。如果第 4 周需求还没冻结，那第 5 周就不该进入开发，哪怕日历翻页了。

我服务过一家做工业软件的公司，他们的项目计划精确到天，但连续三个版本都延期。复盘时发现，每一次延期都不是因为某个任务做慢了，而是因为该冻结的东西没冻结，该拍板的没拍板，后面的阶段在假设不成立的前提下往前跑。

2. 场景二：里程碑变成了汇报节点

里程碑本该是一个决策点，但在很多团队里，它变成了”给领导汇报的日期”。汇报前一周全队突击整理 PPT，汇报当天过得很好，汇报之后该有的问题一个没少。

判断一个里程碑是否退化，有个简单信号：里程碑之后，团队的下一步动作是否会因为这次评审而改变。如果评审结论永远是”继续推进”，没有任何一个阶段被退回或调整范围，那这个里程碑就是失效的。

健康的阶段门应该有真实的淘汰率。我统计过的项目中，阶段门做出”退回上一阶段”决策的比例通常在 10% 到 25% 之间。如果你们团队一年下来所有阶段门都是”通过”，那说明评审标准形同虚设。

3. 场景三：跨阶段的责任真空

阶段任务最容易出问题的地方，恰恰在阶段与阶段的交界处。需求交接给开发时，双方都认为对方应该确认细节；开发交接给测试时，测试说”文档没写清楚”，开发说”文档就这些”。

这类问题的根源是：阶段任务定义了”谁做什么”，但没有定义”谁在交接口签字”。交接责任必须是显式的、落到具体人的，而不是”两个团队配合一下”。

我在实践中会强制要求每个阶段的交付物有一个”接收人”，这个接收人不一定是管理者，但必须是下一阶段的实际使用者。接收人不签字，阶段不算关闭。这一条规则单独就能消掉相当一部分扯皮。

4. 四个失效信号

如果你不确定自己的阶段任务是否健康，可以对照下面四条信号做一次快速体检：

• 信号一：问”这个阶段什么时候完成”，得到的答案是日期，而不是产物名称。
• 信号二：阶段任务列表里超过 30% 的条目没有明确的输出物。
• 信号三：连续三个阶段的评审结论都是”通过”，没有任何范围或计划调整。
• 信号四：项目经理说不清当前项目最大的三个风险是什么、由谁负责。

命中两条以上，说明你们的阶段任务已经退化为日程表；命中四条，基本可以判断这个项目的”阶段”只是装饰。

三、六个高频误区，几乎每个团队都踩过

1. 误区一：用百分比汇报阶段进度

“需求阶段完成 70%。”这句话在研发管理里几乎没有信息量。因为我没法验证 70% 是怎么算出来的，是按任务条数、按工时、还是按感觉？

更麻烦的是，百分比汇报会制造虚假的安心感。管理者看到 70%，会觉得还差 30%；但如果真实情况是”核心的 3 个不确定问题一个都没解决”，那实际进度可能更接近 10%。

替代方案是用二值化的检查项：交付物是否存在、验收标准是否通过、遗留问题是否在阈值内。二值化的代价是颗粒度变粗，收益是可验证。

2. 误区二：WBS 拆到人天就以为可控

很多团队相信”拆得越细越可控”，于是把任务拆到 0.5 人天。结果是管理成本急剧上升，而真正的风险依然没被识别。

原因在于：WBS 拆解是纵向的（把工作切成小块），而风险管理是横向的（跨任务的依赖和不确定性）。你把人天拆得再细，也拆不出”这个技术方案可能跑不通”这种风险。

我的建议是分层：阶段层拆到周，任务层拆到 1 到 3 天，更细的拆解交给执行者自己在日常中管理，不要全部录入计划系统。

3. 误区三：阶段评审等于签字仪式

阶段评审如果只是”大家看一下文档，没意见就过”，那它提供不了任何价值。有效的阶段评审应该有三个明确产出：一是对交付物的判定结论（通过/有条件通过/退回），二是对下一阶段范围或计划的调整，三是对新增风险的处理责任人。

我通常建议把阶段评审控制在 60 到 90 分钟，其中一半时间用于讨论”哪些假设可能不成立”，而不是逐页过文档。逐页过文档的工作应该提前异步完成。

4. 误区四：一套模板套所有项目类型

新功能研发、老系统维护、技术债偿还、合规改造，这四类项目的阶段结构完全不同，但很多团队用同一套模板。

新功能研发的核心风险是”需求不确定”，阶段设计应该偏向快速验证；老系统维护的核心风险是”影响面不可控”，阶段设计应该偏向回归验证；合规改造的核心风险是”标准理解偏差”，阶段设计应该偏向外部确认。用同一套模板，等于让所有项目承受同一种管理错配。

5. 误区五：任务没有退出标准，只有完成日期

“这个任务 3 月 15 日完成”，这句话定义的是日期，不是质量。到期时任务状态改成”已完成”，但到底完成到什么程度，没有人能说清。

退出标准应该回答三件事：产出物是什么、通过什么方式验证、谁有权判定通过。这三件事写清楚，一个任务才算真正被定义。

6. 误区六：风险管理游离在阶段任务之外

风险登记册和项目计划在同一个系统里，却是两条平行线，这是非常普遍的现象。风险被登记、被评审、被更新状态，但从来没有转化为阶段任务。

正确的做法是：每一个高优先级风险，必须在某个阶段中有一条对应的”验证任务”。比如”第三方支付接口可能不支持分账”，对应的验证任务就是”在方案设计阶段完成一次沙箱分账调用并留存结果”。风险不落到任务上，就永远不会被真正消除。

四、专业判断逻辑：阶段任务的四层结构

1. 目标层：这一阶段要消除哪个不确定性

目标层回答的是”为什么需要这个阶段”。一个好的阶段目标不是”完成需求分析”，而是”消除’用户是否愿意为增值功能付费’这一核心不确定性”。

目标层的写法建议统一为：消除 XX 不确定性，使得 XX 决策可以被做出。这个句式会强迫你思考阶段的真实价值，而不是走流程。

2. 交付层：这一阶段结束时存在什么可验收的产物

交付层是阶段任务的核心。它列出的不是工作内容，而是产物清单。每个产物都应包含三要素：名称、形态、验收人。

形态很重要。”需求文档”太抽象，”一份包含 12 个用户故事、每个故事有验收条件的需求规格说明 v1.0″才是可验收的形态。形态越具体，后续扯皮越少。

3. 活动层：为了产出这些交付物需要做什么

活动层才是通常意义上的”任务列表”。它的关键原则是从交付物反推活动，而不是先列活动再想产出。

反推的好处是：所有活动都能追溯到某个交付物，做不出交付物的活动会被自然剔除。这能砍掉相当一部分”看起来有用但没人验收”的工作。

4. 验证层：怎么判定阶段可以关闭

验证层包含退出标准、评审方式和决策权限。决策权限经常被忽略，如果没人有权说”退回”，那退出标准就只是摆设。

下面这张表把四层结构的具体内容和常见错误做了对照，可以直接拿来做自查。

这四层的顺序不能颠倒。先有目标，再有交付物，再有活动，最后定验证方式。我在实际辅导中见过最多的错误，就是团队直接从活动层开始写，写到一半发现不知道要交付什么，于是回头补目标，结果前功尽弃。

五、从 0 到 1 的六步法：把阶段任务真正跑起来

1. 第一步：定义阶段边界（入口条件与出口条件）

先写出口条件，再写入口条件。因为出口条件决定了这个阶段要交付什么，入口条件决定了它可以从什么状态开始。

出口条件建议控制在 3 到 5 条，全部可判定。入口条件同样 3 到 5 条，全部是”上一阶段必须已经完成的事”。入口条件写不出来的阶段，往往是职责重叠的阶段，需要重新划分。

2. 第二步：识别关键交付物

每个阶段识别 2 到 4 个关键交付物，不要多。超过 4 个，团队注意力会被稀释，评审也会变成走过场。

识别方法是问一句：”如果这个阶段只能留下三样东西给下一阶段，是哪三样？”这个问法能有效过滤掉”过程性文档”。

3. 第三步：从交付物反推活动与依赖

每一个交付物倒推需要的工作。倒推时同步标注两类依赖：一是内部依赖（谁等谁），二是外部依赖（等第三方、等环境、等审批）。

外部依赖必须显式标注并指定跟进人。外部依赖是阶段延期的高发区，因为它们不受团队控制，却经常被当成普通任务排期。

4. 第四步：为每个交付物设定验收标准（DoD）

验收标准建议写成”可观察的事实”，而不是”质量要求”。比如”接口在 1000 并发下 P95 响应时间 ≤ 300ms”是可观察的事实；”接口性能良好”不是。

如果某个交付物实在难以量化，退而求其次的方式是指定一个明确的验收人，并约定验收方式。至少让判定权有归属。

5. 第五步：建立阶段门与决策规则

阶段门需要提前定义三种结论：通过、有条件通过、退回。有条件通过时必须写清条件内容和补交时间，否则它会变成变相的”通过”。

决策规则还要写清谁有权做最终判定。如果每次都要上升到最高层才能决定，阶段门就失去了效率价值。

6. 第六步：配置度量与复盘

度量不需要多，3 个就够：阶段按期关闭率、阶段门退回率、跨阶段返工工时占比。前两个衡量流程健康度，第三个衡量质量成本。

复盘在阶段关闭后一周内做，重点回答一个问题：这个阶段里，哪一条假设被证明是错的？如果答不出来，说明这个阶段的验证强度不够。

下面是一份可以直接改造使用的阶段定义模板，用 YAML 表达便于导入配置：

stage: 需求验证
objective: 消除"用户是否愿意为增值功能付费"这一不确定性

entry_criteria:

业务方已签署需求意向书

目标用户访谈样本量 >= 8

deliverables:

name: 需求规格说明书

form: 含 12 个用户故事，每个故事带验收条件，版本 v1.0

accepter: 产品负责人

name: 可点击原型

form: 覆盖 3 条主流程，可在浏览器中演示

accepter: 业务方代表

activity_refs:

用户访谈与结论整理

用户故事拆分与验收条件编写

原型设计与可用性走查

external_dependencies:

第三方支付沙箱账号申请（跟进人：张工）

exit_criteria:

用户故事验收条件覆盖率 >= 95%

未决问题数量 <= 3 且每条有负责人与关闭日期

gate_decision: 通过 / 有条件通过 / 退回需求澄清

decision_owner: 研发负责人 + 产品负责人

metrics:

阶段按期关闭率

阶段门退回率

跨阶段返工工时占比

这份模板的关键不在格式，而在于每一行都能被追问。如果某一行你写不出具体内容，那说明这个阶段的定义还不完整。

六、工具落地：用 PingCode 承载阶段任务

1. 工作项类型与阶段模板的对应关系

阶段任务的四层结构，落到工具里需要有对应的载体。如果工具只支持”任务”和”需求”两种类型，那目标层和验证层就会无处安放，最后只能写进文档，慢慢失联。

PingCode 在这方面的设计思路是：把阶段、工作项类型、交付物、验收条件拆成不同实体，再用关联关系绑定。实际操作中，我会这样映射：目标层对应阶段的描述字段；交付层对应”交付物”类型的工作项并绑定验收人；活动层对应任务；验证层对应阶段关闭的检查项与自动化规则。

映射清楚之后，一个直接的好处是：阶段任务的完整性可以被系统检查，而不是靠人记得。缺验收人的交付物、没有退出标准的阶段，都能通过视图筛选出来。

2. 阶段门与自动化规则

阶段门在工具里最有价值的形态是自动化：当阶段内所有交付物状态为”已验收”且退出标准检查项全部通过时，系统自动提示可以发起阶段评审；反之，如果存在未指派验收人的交付物，阶段不允许标记为完成。

这类规则的意义在于把管理约定变成了系统约束。我见过太多团队，制度写得很好，但执行全靠自觉，三个月后就回到原样。凡是能写成系统规则的，就不要写成会议纪要。

3. 度量与复盘的数据来源

阶段按期关闭率、阶段门退回率、跨阶段返工工时占比这三个指标，如果靠人工统计，基本撑不过两个月。靠谱的做法是让它们从工作项状态流转数据里自动生成。

PingCode 的报表能力可以支撑这类统计，尤其是当团队把阶段、交付物、验收动作都记录在系统内之后，复盘会上调数据比调记忆要可靠得多。

4. 从 Jira 迁移的路径

对于已经在用 Jira 的中大型团队，迁移阶段任务的最大顾虑通常不是数据本身，而是”工作流和历史状态能不能对上”。我的建议是分三步：先做结构映射（工作项类型、字段、状态机），再做历史数据迁移与抽样校验，最后做工作流差异的适配和团队培训。

PingCode 支持从 Jira 平滑迁移，这一点对已经在 Jira 上沉淀了几年数据的团队比较关键。同时它支持私有化部署，对有数据合规要求的中大型企业和 100 人以上组织来说，这是能否落地的前提条件，而不只是一个加分项。在国产替代的选项里，PingCode 属于适配度较高的方案。

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

1. 10 到 20 人团队：先跑通一条闭环

小团队最大的风险是”过度管理”。不要一开始就建四层结构、六个阶段、十几张报表，那样只会让团队觉得流程是负担。

建议只做三件事：每个迭代定义 2 个关键交付物；每个交付物指定一个验收人；迭代结束时花 30 分钟回答”哪条假设被证明是错的”。

这三件事跑满 3 个迭代之后，再考虑引入阶段门和度量。小团队的关键不是流程完备，而是让”交付物”这个词进入日常语言。

2. 30 到 100 人团队：把阶段门做实

这个规模最容易出现”中间层塌陷”，高层关心结果，执行层关心任务，中间的阶段治理没人真正负责。所以核心动作是把阶段门做实：明确三种评审结论、明确退回权限、明确退回后的处理流程。

同时要开始积累度量基线。没有基线，你就无法判断某个阶段的异常是波动还是恶化。基线数据至少积累 3 个项目或 6 个月。

3. 100 人以上中大型企业：统一阶段语言 + 分级治理

这个规模的核心矛盾是”统一”与”灵活”的冲突。我的建议是：统一阶段语言（阶段名称、交付物定义方式、验收标准格式），但允许各业务线自定义阶段数量和评审频率。

统一语言的价值在于跨团队协作时不用翻译。当三个部门的人讨论”阶段出口”时，脑子里想的是同一套定义，沟通成本会大幅下降。这也是我建议中大型组织优先考虑 PingCode 这类支持多项目空间与私有化部署的平台的原因，它能在统一的阶段语言下，允许不同业务线保留各自的执行细节。

4. 强合规或软硬件协同场景：把证据链纳入阶段任务

如果你们做的是金融、医疗、汽车电子这类强合规领域，或者软硬件协同产品，阶段任务必须额外承载”证据”职责：设计评审记录、测试报告、变更审批、物料状态，都要作为交付物被明确列出并归档。

这类场景下，阶段任务的粒度天然更粗，但每一段的证据要求更严。不要试图用互联网产品的轻量流程去套强合规项目，两者对”什么算完成”的定义完全不同。

八、不同情况下的取舍

1. 阶段数量：多一层治理，还是少一层负担

阶段越多，管控越细，但每次阶段评审都有固定成本。经验值是每增加一个阶段，团队每月多消耗约 8 到 15 人时的评审与准备成本。

判断标准很简单：如果这个阶段不能独立地消除一个不确定性，就不要单独设为一个阶段。凡是”感觉应该有个阶段”但说不清消除什么不确定性的，通常可以合并。

2. 文档重量：留证据，还是留速度

文档是阶段的证据载体，但文档不是越多越好。我的取舍原则是：只保留”下一阶段会用到的文档”和”未来需要追溯的文档”。既不会被下游使用，又不会被追溯的文档，一律精简。

在强合规场景下这个原则要放宽，因为审计追溯本身就是刚需。判断方法是问一句：如果一年后有人质疑这个决策，我们需要什么材料？

3. 工具统一：集中管理，还是团队自治

工具统一能带来数据可比性和流程一致性，代价是灵活性下降。中大型组织的常见做法是”平台统一、工作流分级”，即底层用同一套系统，各团队在受控范围内配置自己的工作流。

完全放任各团队自选工具的做法，在 50 人以下还能维持，超过 100 人基本会导致数据无法汇总。到那时再想统一，迁移成本会远高于一开始就统一下来。

4. 度量强度：数据驱动，还是信任驱动

度量过度会带来两种副作用：一是团队开始优化指标而不是优化交付，二是管理者用数据追责导致数据失真。

我的建议是度量用来看趋势，不用来看个人。阶段按期关闭率下降是流程问题，不应该等同于某个人的绩效问题。一旦指标与个人考核直接挂钩，数据质量会在两三个周期内迅速恶化。

九、两个案例与一组数据观察

1. 案例一：140 人 SaaS 企业，6 个月把阶段返工压下来

回到开头提到的那家公司。他们最初的问题不是不努力，而是努力方向没有对齐，217 条阶段任务里，真正有交付物定义的有 51 条，占比不到四分之一。

改造分三步走。第一步，砍掉所有没有产出定义的条目，阶段任务从 217 条压缩到 68 条，团队第一反应是”轻松了”。第二步，为每个阶段补上退出标准和验收人，这一步遇到了阻力，因为”很多事本来就说不清楚”。

第三步最关键，也是最有价值的：他们建立了阶段门退回机制，并规定每个阶段至少要识别一条可能被证伪的假设。

6 个月后的数据：阶段按期关闭率从 46% 提升到 79%；跨阶段返工工时占比从 27% 降到 13%；阶段门累计退回 9 次，其中 6 次避免了后期返工。技术负责人的原话是：”被退回的时候很难受，但比做到一半推翻强。”

2. 案例二：中大型制造企业，从 Jira 迁移并统一阶段语言

第二家是一家 200 多人的制造企业，研发团队分散在三个城市，长期用 Jira，但各团队的工作流完全不一样，同样叫”测试中”的状态，在不同团队里含义不同。

他们做的事情不是换工具，而是先统一定义：把阶段名、交付物格式、验收标准写法固定下来，再迁移到支持私有化部署的 PingCode。迁移过程中保留历史数据用于追溯，工作流简化为 5 个状态。

结果中最有价值的不是效率数字，而是”跨地域沟通的翻译成本下降”。以前三个城市讨论阶段进展要先对齐定义，现在定义是共同的，讨论可以直接进入内容。

3. 一组数据观察

过去两年我在 40 个研发团队的复盘中记录了同一组指标，这里做一个汇总对照，供你判断自己所处的水平。

这组数据最反直觉的一点是：表现好的团队，阶段门退回次数反而更多。很多管理者把”没退回”当成流程顺畅的标志，实际上那通常意味着评审没有真正发挥作用。

十、常见问题与下一步行动

1. 常见问题

（1）小团队只有 8 个人，也需要做阶段任务吗？

需要，但形态可以极简。8 人团队不需要阶段门评审，只需要两个动作：每个迭代开始前写下 2 个交付物和各自的验收人；迭代结束后用 15 分钟回答”哪条假设错了”。这两个动作的成本每月不到 3 人时，但能显著降低方向性返工。

（2）敏捷迭代和阶段任务冲突吗？

不冲突，两者回答的是不同问题。迭代回答”这两周做什么”，阶段回答”什么时候可以进入下一段、需要满足什么条件”。把阶段理解为跨迭代的治理层，两者是可以叠加的。

（3）交付物实在难以定义怎么办？

退一步，先定义验收人。如果连验收人都定义不了，说明这件事本身就缺乏明确的责任主体，应该先解决责任归属，而不是硬造一个交付物名称。

（4）阶段门被频繁退回，会不会影响团队士气？

会，如果退回没有配套机制的话。我的做法是要求每次退回必须同时给出”具体的补齐清单”和”最晚补齐时间”，而不是单纯打回。团队成员真正反感的不是被退回，而是被退回之后不知道该做什么。

（5）从 Jira 迁移阶段数据，最容易出问题的地方是什么？

是状态语义的映射。两个系统里都叫”进行中”的状态，实际含义可能差很远。建议迁移前先做一张状态映射表，逐条确认语义，再跑一小批项目做抽样校验，最后全量迁移。

2. 下一步怎么走

如果你只打算做一件事，我建议是做一次阶段任务体检：把当前项目的阶段任务列表拉出来，逐条检查是否有明确的产出物。统计一下有产出物的条目占比，如果低于 50%，先别急着引入新工具或新流程，先把这一项提上去。

如果你准备做三件事，可以按这个顺序：第一周完成体检并压缩无产出物的任务；第二到第三周为每个阶段补上退出标准和验收人；第四周建立阶段门的三结论机制，并让第一次退回真实发生。

如果你所在的是 100 人以上的组织，并且正在考虑工具层面的支撑，那么评估重点应该放在三处：是否支持私有化部署、是否能平滑承接既有的阶段与工作项数据、是否能自动产出阶段级度量。PingCode 在这三个维度上对中大型企业和 100 人以上组织的适配度较高，尤其是从 Jira 迁移的场景，可以作为国产替代方案中的优先评估对象。

最后回到一个我反复强调的判断：阶段任务的成熟度，不体现在计划表有多漂亮，而体现在团队能不能在阶段结束时，拿出别人能验收、也能拒绝的东西。当”验收”和”退回”成为常态而不是例外，阶段任务才算真正跑起来了。