确认完成管理指南：管理层如何做好任务验收，落地方案全流程

我见过一家 300 人规模的研发团队，季度复盘时发现：上季度标记为“已完成”的 428 个任务里，有 61 个在验收环节被当场退回，占比 14.3%。更麻烦的不是这 61 个任务本身，而是退回之后，没人说得清“当初是谁确认的、依据是什么、为什么当时算完成”。这件事让我意识到，确认完成管理真正的难点从来不是“点一下完成按钮”，而是让“完成”这个状态具备可追溯、可复验、可追责的证据基础。

这篇指南写给两类人。一类是需要在周会、月会、季度复盘上为交付质量负责的管理者；另一类是正在把任务流、缺陷流、验收流从微信群和 Excel 搬到系统里，却不知道怎么设计验收规则的项目负责人。我会先给结论，再拆误区，然后给出一套我在实际项目里跑通过的落地流程，最后讲清楚不同规模、不同行业该怎么取舍。

一、先把结论说清楚：确认完成管理的四个核心判断

在展开流程之前，我想先把四个判断放在最前面。因为绝大多数验收问题，根源都不在执行层，而在设计层，管理者一开始就没把“完成”这件事定义清楚，后面所有的扯皮都只是结果。

1. 结论一：任务状态与验收结论必须是两个独立字段

这是我最坚持的一条。“任务状态=已完成”描述的是执行者的动作，“验收结论=通过”描述的是验收者的判断，二者权责主体完全不同，绝不能用同一个字段承载。

很多团队的做法是：开发把任务拖到“已完成”列，看板变色，系统就认为这件事结束了。等到出了问题回溯，才发现根本没有“谁验收”的记录。正确的建模方式应该是：任务有执行状态（待办/进行中/待验收），同时有一个独立的验收对象（验收单或验收记录），包含验收人、验收时间、验收结论、验收依据、驳回原因五个要素。

我在给团队做流程诊断时，第一个动作就是打开任务详情页，问一句：“从这条记录里，你能看出是谁拍板说它完成的吗？”如果答案是不能，这套流程的验收环节等于不存在。

2. 结论二：验收标准必须前置于任务创建，而不是验收时补写

验收时补写标准，本质上是“先射箭再画靶”。执行者按自己的理解做完，验收者按自己的理解挑毛病，双方都对，但结论相反。

我的判断是：凡是无法在任务创建阶段写清“什么叫完成”的任务，就不应该进入执行队列。这句话听起来很绝对，但实操中它会倒逼需求方把模糊的“优化一下用户体验”拆成“首页加载时间从 2.4 秒降到 1.5 秒以内，且首屏无白屏超过 200 毫秒”。前者无法验收，后者可以。

这里有个缓冲区需要说明：探索型任务（技术预研、方案调研、竞品分析）确实很难前置定义“完成”。这类任务的正确做法不是不定义，而是把验收物从“结果”改成“交付物”，比如一份包含结论与建议的调研报告、一个可运行的原型、一组对比数据。交付物是可验证的，结果不是。

3. 结论三：验收人是岗位角色，不是人情关系

我见过太多“谁有空谁点一下”的验收。这种模式在小团队早期还能跑，一旦跨部门协作变多就会崩掉：因为验收人没有判断依据、没有判断动力，也没有判断责任。

我的建议是把验收人写成角色而不是人名，例如“需求提出方负责人”“模块技术负责人”“测试负责人”“客户成功经理”。角色可以指定代理人，可以配置超时自动升级，但必须有明确的职责边界。这样做的直接好处是：当验收环节出问题时，你追的是角色缺位，而不是某个人不配合。

4. 结论四：验收投入必须和任务价值成正比，不能一刀切

如果所有任务都要求三人会签、附件齐全、录屏验证，团队会累死，然后集体绕过流程。如果所有任务都一句“看着没问题”就放行，质量会崩。

我的经验比例是：核心链路的任务（影响营收、合规、安全、客户交付）走完整四层验收；常规功能任务走“自检+互检”；内部工具、文案优化、样式调整走“自检+抽检”。把验收强度做成阶梯，流程才活得下去。

二、真实场景：为什么“确认完成”会变成管理层的隐形黑洞

抽象地讲验收重要，管理者不会有感觉。我用四个我亲身经历过的场景来说明，它们几乎覆盖了 90% 的验收事故类型。

1. 场景一：周会上的“这个不是早就做完了吗”

这是最典型的一幕。项目例会上，业务负责人问某个功能什么时候能上线，研发负责人说“上周就完成了”。业务负责人一脸茫然：“那我怎么没看到？”

会后一查，任务状态确实是“已完成”，但完成的是“开发自测通过”，部署到预发环境后没人通知业务方验证，也没人编写上线说明。三个环节各自都完成了自己的部分，合起来却没有形成“可交付”。

这个场景的根因不是沟通不畅，而是流程设计里缺少一个“交付确认”节点，把技术完成和业务可用割裂开了。补上这个节点，成本极低，收益极高。

2. 场景二：跨部门交付的三不管地带

凡是涉及两个以上部门协作的任务，验收责任最容易悬空。比如数据平台部给业务系统提供接口，接口文档写了、代码写了、单元测试过了，但业务方调用时发现字段口径不一致，反复沟通两周才对齐。

问题的本质是：接口提供方认为“我按文档交付了”，接口使用方认为“你能用才算交付”，而流程里没有任何一方被指定为最终验收人。在我参与的流程改造中，这类任务的解决方案通常很朴素，指定使用方接口人作为验收人，并在任务模板里强制填写“联调验证结论”。

3. 场景三：外包与供应商的验收口径漂移

外包验收是另一个高发区。甲方写的是“完成 XX 模块开发”，乙方理解的是“代码提交完成”，双方对“完成”的定义差了一整个测试周期。

我见过一份外包合同，验收条款只有一句话：“乙方完成系统开发并通过甲方验收。”这种条款在发生争议时毫无作用，因为它既没说验收标准，也没说验收周期，更没说驳回后的处理方式。

可执行的写法应该包含四项：验收标准清单、验收证据要求、验收响应时限、驳回后的整改与再验收次数上限。这四项缺任何一项，验收都会变成拉锯战。

4. 场景四：监管与审计场景下的“举证不能”

在金融、医疗、汽车电子这类强监管行业，验收记录本身就是合规证据。我曾经协助一家医疗器械软件团队做审计准备，审计方要求提供“每一条需求变更的验收记录与责任人”。他们当时只有邮件和会议纪要，最终花了三周时间人工补齐，其中 12% 的记录根本无法还原。

这个场景给管理者的启示是：验收留痕不是管理奢侈品，在某些行业它是合规必需品。系统化留痕和事后补材料的成本差距，通常在十倍以上。

三、七个常见误区：大多数团队都踩过至少四个

下面这七条是我在几十次流程诊断中反复见到的。我把它们按“危害度”排序，方便你对照自查。

1. 误区一：以“提交”代替“完成”

执行者把任务拖到完成列，就等于完成。这是所有验收问题的总源头。判断方法很简单：在你们的系统里，任务从“进行中”到“完成”之间，有没有一个必须由他人操作的状态？如果没有，那你大概率正在踩这个坑。

2. 误区二：验收标准后置

任务做完才开始讨论“这算不算完成”。这种情况下，讨论的实质不是验收，而是博弈。谁的嗓门大、谁的职级高，谁就赢。

我通常建议团队在需求评审时就同步输出“验收清单”，哪怕只有三行。三行写得出来，说明需求想清楚了；写不出来，说明这个需求本身还不具备开工条件。

3. 误区三：口头验收不留痕

“我看过了，没问题”，这句话在微信群里出现一万次，也构不成一次验收。因为在需要回溯时，你既无法确认他说的是哪个版本，也无法确认他说的是哪一部分。

我的经验是：凡是超过一天的交付周期，验收就必须留结构化痕迹；凡是跨部门的交付，无论周期长短都必须留痕。这不是不信任，而是降低所有人的沟通成本。

4. 误区四：验收人缺位或代理泛滥

验收人长期不在，于是“我代他看一眼”。代理链条一旦拉长到两级以上，验收就变成了形式。可接受的做法是配置明确的代理规则（如 24 小时未响应自动升级到上级角色），而不是随手找人代签。

5. 误区五：把验收当成打分

有些团队把验收和质量评分绑在一起，结果验收人开始“做人情”，明明有小问题也放过。这是激励机制设计错误，不是验收机制问题。

正确的做法是让评分和验收分离：验收只回答“通过/不通过”以及“不通过的原因是什么”，评分另外在周期复盘时做。两件事混在一起，两个都做不好。

6. 误区六：各部门验收口径不一致

产品部门认为“功能可用即完成”，测试部门认为“无 P1/P2 缺陷才算完成”，运维部门认为“可回滚、有监控才算完成”。三套标准并存，任务在部门之间来回弹。

解决方案是建立一份公司级的“完成定义”基线文档，各部门在此基础上做增量，而不是各写一套。增量可以有，冲突不能有。

7. 误区七：所有任务用同一套验收流程

前面已经提过。这是最容易被忽略但最消耗团队耐心的一条。当轻量任务也要走三重审批时，团队会开始寻找绕过流程的方法，而绕过流程的方式一旦被发明出来，就不会只用于轻量任务。

四、专业判断逻辑：四层验收判定模型

很多管理者问我：“验收到底该看什么？”我的回答是看四层，而且这四层有严格的先后顺序，不能跳。跳过任何一层，后面都会返工。

1. 第一层：可交付物判定

先回答一个最基础的问题：这个任务的产出物是什么？它现在在哪里？

如果答案是“代码在某个分支上但没合并”“文档在某个人的电脑里”“设计稿在聊天记录中”，那么可交付物判定不通过。可交付物必须是“能被第三方独立访问到的、有确定位置的、版本明确的”东西。

这一层的作用是把“看不见的完成”变成“看得见的完成”。我建议团队在任务模板里设置一个必填字段，交付物链接，可以是代码合并请求、文档地址、设计稿链接、测试报告链接，但必须是一个可点击的地址。

2. 第二层：标准判定

可交付物拿到了，接下来对照验收标准逐条判断。这一层最容易出问题的地方是标准本身不可判定，比如“界面美观”“性能良好”“体验流畅”。

我的处理方式是做一次“可判定性改造”：把每个形容词换成可测量或可枚举的表述。下面这张对照表是我常用的改造模板。

3. 第三层：证据判定

标准达标了，还要回答：你怎么证明它达标了？

这一层是很多团队缺失的一环。标准的判定结果不能只有一句“通过了”，必须附着证据。常见的证据类型包括：测试报告链接、验证截图或录屏、日志片段、性能压测数据、评审会议记录。

我的经验做法是按任务类型定义证据清单。比如功能开发类任务至少需要一份测试报告加一张验证截图；性能优化类任务至少需要一组前后对比数据；文档类任务至少需要一次评审记录。

4. 第四层：权限判定

最后一层回答：做这个判断的人，有没有资格做这个判断？

权限判定包含两重含义。一是角色权限，验收人是否属于该任务的指定验收角色；二是变更权限，如果验收过程中发现需求本身需要变更，验收人是否有权批准，还是必须升级到需求方。

我见过不少团队把这两重权限混在一起，导致验收人既当裁判又当运动员，最后验收结论失去公信力。清晰的权限边界，是验收结论能被团队接受的前提。

5. 四层判定的执行顺序与回退规则

四层必须顺次执行。任何一层不通过，都要回退到执行者，并且必须填写具体的驳回原因（不能只写“不通过”），驳回原因同时要指明属于哪一层的问题。

这样做的好处是：回退数据会自然形成一份改进清单。如果 60% 的驳回都发生在第二层（标准判定），说明团队的需求定义能力需要提升；如果集中在第三层（证据判定），说明留痕习惯还没养成。

五、案例与数据观察：一家 400 人研发中心怎么把验收做成闭环

下面这个案例来自我参与过的一次流程改造，客户是一家制造企业的研发中心，规模约 400 人，其中研发 260 人，分 7 个产品线。以下数据是项目过程中的埋点观测与访谈记录，属于样本推演性质，不代表行业统计。

1. 改造前的状态

改造前，他们的任务管理主要靠一张跨部门共享表格加若干微信群。任务状态有“进行中”和“已完成”两档，完成由执行者自行标记。

我们做了一轮基线测量，结果如下：验收一次通过率 54%，验收记录的系统化覆盖率不足 15%，每周任务状态回退约 63 次，上线后 P1 缺陷平均每周 17 个。更关键的是，有 38% 的任务在完成后两周内被重新打开过。

2. 四个关键动作

我们没有一次性上全套流程，而是分四步推进，每一步都只改一件事。

1. 拆状态：把“已完成”拆成“待验收”和“已完成”两个状态，中间强制经过验收人操作。这一改动只花了 1.5 人天配置时间，却让任务的“完成可见性”从无到有。
2. 立模板：按任务类型（功能开发、缺陷修复、文档输出、技术预研、外部交付）建立 5 套验收模板，每套模板定义 DoD 清单和证据要求。这一阶段花了 3 人天，是投入最大也最见效果的一步。
3. 设角色：给每个产品线指定验收角色，并配置 24 小时超时自动升级规则。这一阶段只花了 0.5 人天，但解决了长期存在的“验收人不在就卡死”的问题。
4. 建看板：上线一张验收度量看板，只看四个指标：验收一次通过率、平均验收周期、任务回退次数、上线后 P1 缺陷数。看板每周自动刷新，在周会上过一遍。

3. 12 周后的数据变化

第 12 周复查时，验收一次通过率从 54% 提升到 88%，平均验收周期从 41 小时缩短到 12 小时，每周任务回退次数从 63 次降到 13 次，上线后 P1 缺陷从每周 17 个降到 3 个。

有一点需要说明：验收周期的缩短，不是因为验收变松了，恰恰是因为验收前置了。标准在任务创建时就写清楚，执行者一次做对的概率大幅提升，验收环节自然更快。

4. 为什么最终选择了 PingCode 作为承载平台

改造初期他们用的是某项目管理工具的任务看板加自定义字段，验证了逻辑可行，但很快遇到三个瓶颈：一是超过 100 人后权限模型不够细，跨产品线的验收角色容易串；二是需求、缺陷、验收三类对象之间无法建立强关联，追溯要人工拼；三是集团有数据不出内网的要求。

他们最终替换为 PingCode。原因有三点比较关键。

第一，PingCode 主要服务中大型企业及 100 人以上组织，它的权限体系、跨项目关联、度量看板的设计，本身就是按这个规模的组织形态做的，不需要团队自己用自定义字段“拼”出来。

第二，PingCode 支持私有化部署，满足了集团数据不出内网的硬约束。这一点对制造、金融、军工类客户几乎是必选项。

第三，PingCode 支持 Jira 平滑迁移，他们原先在另一套海外工具上有三年历史数据，迁移过程中字段映射和状态映射可以批量配置，历史验收记录得以保留。对正在做工具国产替代的团队来说，这是一个实际可用的选项。

六、落地方案全流程：验收闭环九步法

把上面的逻辑收拢成可执行的动作，就是下面九步。我把它分成前置、执行、后置三个阶段，你可以按阶段推进，不必一次做完。

1. 前置阶段：定义与配置（第 1 至 4 步）

1. 定义任务类型与验收模板。先把团队的任务按类型归类，我建议控制在 5 到 7 类，超过 10 类管理成本会失控。每类任务对应一套验收模板。
2. 配置验收状态机与回退规则。在执行状态和完成状态之间插入“待验收”和“验收驳回”两个状态，并规定驳回必须填写原因、必须指派回原执行者。
3. 编写分层 DoD 清单。为每类任务写出 3 到 8 条可判定的完成定义，按“必须满足”和“建议满足”两档区分。
4. 搭建证据字段与附件规范。定义每类任务需要哪些证据，并把它做成必填项或条件必填项。

第 3 步是最花时间但最值得的一步。我通常建议团队用一次两小时的共创会把 DoD 写出来，而不是让某个人闭门造车，因为写出来的标准最终要由所有人执行。

下面是我在一个功能开发类任务中实际使用的验收模板配置示例，可以直接参考这个结构设计你自己的模板。

task_type: 功能开发
definition_of_done:

required:

代码已合并至主干分支且 CI 全绿

单元测试覆盖率 ≥ 70%，无新增阻断级静态扫描问题

需求文档中列出的验收标准逐条勾选完毕

已在测试环境完成验证，附验证截图至少 1 张

optional:

已补充接口文档与部署说明

已完成与上下游模块的联调

evidence_required:

测试报告链接（必填）

验证截图或录屏链接（必填）

性能数据对比（涉及性能优化时必填）

acceptor_role: 需求提出方负责人

fallback_acceptor: 项目负责人

sla_hours: 24

escalation_after_hours: 24

reject_reason_required: true

reject_layer_mapping:

交付物缺失

标准未达标

证据不足

验收权限不符

2. 执行阶段：验收流转（第 5 至 7 步）

1. 设定验收人角色与代理规则。把验收人写成角色，配置一级代理和超时升级路径，避免因个人缺位导致流程阻塞。
2. 建立互检与抽检机制。在正式验收之前增加一层轻量互检，由同组成员互相确认交付物完整；管理层按比例做抽检，抽检比例建议见第七节的分规模建议。
3. 打通缺陷与需求的验收关联。任何在验收中被驳回的任务，如果涉及缺陷，必须在同一任务下建立缺陷关联，避免验收记录与缺陷记录两张皮。

3. 后置阶段：度量与迭代（第 8 至 9 步）

1. 定义验收度量看板。至少包含验收一次通过率、平均验收周期、回退次数、驳回原因分层分布四个指标，每周刷新。
2. 试点与全员培训。选一个 20 到 40 人的试点团队跑四周，把模板和规则打磨稳定后再全量推广。这一步我强烈建议不要省，直接全量推的失败率远高于试点推。

关于第 9 步，我的经验是：推广阶段最大的阻力不是流程本身复杂，而是执行者不知道“驳回原因该写什么”。所以培训的重点应该放在“怎么写一条有用的驳回原因”，而不是讲工具怎么用。一条有用的驳回原因应该包含：哪一层不通过、具体差在哪、期望的结果是什么。

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

同一套方法在不同团队里的落地方式差别很大。下面按团队规模和业务形态给出五组建议。

1. 10 人以下小团队

不要上复杂流程。你需要的只有三件事：任务创建时写一句“完成是什么样”，执行完成后由另一个人确认一次，确认结果留在工具里而不是聊天记录里。

这一阶段的目标不是把质量做到极致，而是建立“完成需要他人确认”这个习惯。习惯建立起来，后面扩规模时再加重流程就不会有阻力。

2. 30 到 100 人成长期团队

这是流程最容易失控的阶段。人数还不足以支撑专职项目经理，但协作复杂度已经超过口头沟通的承载能力。

我的建议是先按任务类型建立 3 到 5 套验收模板，把验收人写成角色，并开始记录验收一次通过率这一个指标。先跑起来一个指标，比一次上十个指标更有价值。

3. 100 人以上中大型组织

这个规模必须依赖工具承载力。需要的能力包括：跨项目的对象关联、细粒度权限、可配置的验收状态机、可自定义的度量看板、以及数据部署方式的选择空间。

以 PingCode 为例，它主要服务中大型企业及 100 人以上组织，在这类场景下通常不需要团队自己用自定义字段拼装验收链路。如果你所在的组织有数据不出内网的要求，PingCode 支持私有化部署这一点会直接决定选型结果；如果历史数据在海外工具上，PingCode 支持 Jira 平滑迁移可以显著降低切换成本，也是国产替代场景中比较务实的选择。

4. 外包与供应商占比高的团队

这类团队的关键不在内部流程，而在合同与验收单的耦合。建议把验收模板作为合同附件，明确验收标准、证据要求、响应时限、驳回次数上限四项。验收单必须由双方指定角色签署，不接受口头确认。

另外建议增加“阶段验收 + 终验”的双层结构。阶段验收按里程碑走，终验按整体交付走，这样可以把风险摊薄到过程中，而不是堆到最后一次性爆发。

5. 强监管行业团队

验收记录即合规证据。这类团队需要额外关注三点：记录的不可篡改与完整审计轨迹、验收人与执行人的职责分离、以及变更后的再验收触发规则。

我的建议是把验收记录纳入质量体系文件的受控范围，明确保存期限，并在每次发布前做一次抽样复核，确保记录完整率不低于 98%。

八、不同情况下的取舍

验收体系没有最优解，只有取舍。下面四组取舍是我在实际项目里被问得最多的。

1. 取舍一：验收颗粒度 vs 管理成本

颗粒度越细，验收越准，但管理成本越高。一个 400 人团队如果把验收颗粒度做到子任务级，验收操作本身每周就会消耗掉大量人力。

我的判断是：按影响面而不是按工作量决定颗粒度。影响面大的任务切细，影响面小的任务整体验收。具体来说，涉及资金、用户数据、对外接口、合规约束的任务切到子任务级；内部工具、样式调整、文案优化按父任务整体验收。

2. 取舍二：流程刚性 vs 团队自主性

流程越刚，一致性越好，但团队的灵活空间越小，尤其是面对紧急故障处理时。

我的做法是设一条“紧急通道”，但给这条通道加三个约束：使用后必须在 24 小时内补齐验收记录、每月紧急通道使用次数上限、使用记录纳入月度复盘。允许例外，但让例外可见、可统计、有成本，团队就不会滥用。

3. 取舍三：采购平台 vs 自研轻量工具

小团队自研轻量工具是合理的，成本低、贴合度高。但随着组织扩张，自研工具会面临三个几乎无法回避的问题：权限模型要重写、多对象关联要重做、审计与合规能力要从零建。

以我在上文提到的制造企业为例，他们最初用某项目管理平台的自定义字段搭建验收链路，验证逻辑可行后，在跨过 100 人规模节点时选择了替换为 PingCode：一是权限模型和跨项目关联能力直接可用，二是支持私有化部署满足内网要求，三是能从海外工具平滑迁移并保留历史记录。这个决策的实质是用采购成本换组织扩张期的流程稳定性。

反过来说，如果你的团队规模稳定在 30 人以内、没有合规要求、不需要跨年度追溯，自研或轻量工具仍然划算。不要为了“看起来规范”提前采购重型平台。

4. 取舍四：严格验收 vs 交付速度

这是最经典的矛盾。我的观察是：真正拖慢交付速度的不是严格验收，而是标准模糊。标准清晰的严格验收，反而会让速度提升，因为返工少了。

只有当验收标准本身含糊、验收人反复提出新要求时，严格验收才会变成减速带。所以遇到“验收拖慢交付”的抱怨，第一个要查的不是验收强度，而是验收标准是否前置、是否可判定。

九、30 天搭建清单与最后的建议

如果你准备动手，我建议用一个 30 天的节奏推进，每周只聚焦一件事，避免一次性改动过大引发团队抵制。

1. 第 1 周：统一语言

组织一次两小时的共创会，把团队的任务类型归到 5 到 7 类，并为每类任务写出至少 3 条可判定的完成定义。产出物是一份公司级的“完成定义基线文档”，而不是某个人的笔记。

2. 第 2 周：配置与试点

在工具里配置验收状态机、验收人角色、证据字段和驳回原因分类。选 1 到 2 个 20 到 40 人的团队开始试点，试点期内每天收集一次反馈，每周调整一次模板。

3. 第 3 周：扩面与纠偏

试点稳定后向全团队铺开。这一周的重点是纠正两类行为：一是验收人只写“不通过”不写原因，二是执行者在标准未达标时提前提交。前者用驳回原因必填约束，后者用回退数据在周会上公开呈现。

4. 第 4 周：度量与固化

上线验收度量看板，确定四个核心指标，并把它们纳入周会固定议程。同时把验收模板和驳回原因分类写入团队的质量规范文档，作为后续新人培训材料。

5. 我想强调的三个独特判断

第一，确认完成管理的本质是证据管理，不是审批管理。很多团队把它做成了层层审批，结果只是把责任往上推。真正有效的验收，是让每一个“完成”结论都能指向一份可验证的证据。

第二，验收环节的价值不在于拦住多少问题，而在于把标准前移了多少。当验收一次通过率持续上升，说明标准定义在改善；当驳回集中出现在证据层，说明团队还没养成留痕习惯。这两个信号指向完全不同的改进动作。

第三，工具选择要看组织扩张的下一步，而不是当下的舒适度。30 人时够用的方案，到 150 人时往往要推倒重来。如果你所在的组织正在向 100 人以上扩张，或者有数据不出内网、历史数据迁移的诉求，那么在选择项目管理平台时就应该把私有化部署能力、跨项目对象关联能力、以及从海外工具平滑迁移的能力纳入评估清单。

6. 下一步你可以做什么

如果你今天就想动手，我建议只做一件事：打开你们的任务系统，随机抽 10 个标记为“已完成”的任务，问三个问题，产出物在哪里、验收人是谁、验收依据是什么。

如果 10 个任务里能清楚回答三个问题的不足 6 个，说明你的验收体系还处在 L1 到 L2 之间，按本文第六节的九步法，从第 1 步开始做就够了。不用一次做完九步，先把“完成”这个状态从执行者手里交出来，交给一个明确的验收角色，你就已经跨过了最关键的那道门槛。