我带过一个 14 人的研发团队，某个迭代里我们把 62 个任务塞进两周看板。到第 9 天，41 个任务仍停在“进行中”，没有任何一个模块能完整演示。复盘会上大家都以为是排期太满，但把数据拉出来看，真正的问题藏在别处：62 个任务里有 47 个的颗粒度落在“半天到三天”之间，看起来挺合理，实际上每一个都无法在一天内被独立验证。
后来我把这个团队三年的任务数据重新做了一遍归因，得到一个反常识的结论：迭代失控的第一原因不是任务太多，而是任务不可验证。当一个任务需要三天才知道自己做没做对，它的风险就从“开发风险”变成了“管理风险”，而管理风险是任何排期工具都消化不掉的。
这篇指南想解决的就是这件事，研发团队怎么拆分任务，怎么把拆分动作和数据分析的全流程接上，让“拆”产出的是可交付单元，而不是一堆看起来整齐的待办卡片。文中数据来自我在 3 家中大型研发组织（90 人、180 人、420 人规模）做过的拆分改造样本，标注“样本观察”的为项目记录，标注“示意数据”的为说明变量关系的推演值。
一、核心结论：拆分的终点不是“小任务”，而是“可验证的交付单元”
先把结论摊开说，避免后面绕弯。任务拆分管理的本质，是把不确定性切成可被独立验证的片段。验证的对象不是“代码写完了没”，而是“这件事有没有产生可以被观察的结果”。代码写完、提交、合并，都不算结果；能被演示、能被测试、能被回滚，才算结果。
1. 一句话结论
我见过的所有做得好的拆分体系，都满足同一个特征：任何一个任务，都能在 24 小时内由第三方判断“它是对的还是错的”。这条判据听起来很朴素，但它同时约束了粒度、验收标准、依赖关系三件事，只要有一项不满足，任务就会在 24 小时后依然无法判断。
反过来，所有做不好的拆分体系，症状也高度一致：任务状态更新变成了“打卡”，而不是“证据”。开发说“还在做”，测试说“还没提测”，产品说“不知道进度”，三方说的其实都是实话，因为任务本身就没有设计出可判断的节点。
2. 拆分的三条硬性约束
把“可验证”翻译成可执行规则，我通常给团队定三条硬约束，它们是拆分的下限，不是上限。
- 可演示：任务完成后，能在测试环境或预发环境看到某个具体行为的变化，而不是“底层重构完成”。
- 可独立回滚：这个任务上线出问题，能单独回退，不必连带回退另外三个任务。做不到这一点的任务，往往是拆错了维度，而不是拆得不够细。
- 可归因：任务的验收人不是执行者本人。自己验收自己的任务，等于没有验收。
这三条约束会直接决定拆分的粒度。比如“重构订单查询模块”这个任务，三条都不满足；拆成“订单查询接口新增分页参数并保持旧行为不变”，三条就都满足了。区别不在于做得细不细，而在于是否给验收人留了一个判断入口。
3. 为什么“数据分析全流程”必须和拆分绑在一起
很多团队把数据分析理解成“事后看报表”，这是最大的浪费。拆分阶段产出的每一条信息，预估规模、依赖对象、验收标准、阻塞原因，本身就是结构化数据。如果拆分时不带这些字段，后面无论多贵的度量平台都算不出有用的东西。
我在 180 人那家组织的改造中做过对比：仅仅是把任务卡片的字段从“标题 + 负责人 + 截止日”扩展为“标题 + 负责人 + 验收标准 + 依赖对象 + 预估规模 + 阻塞类型”，后续做迭代归因分析的时间从每迭代 12 小时降到 1.5 小时，而且结论质量反而更高，因为字段是结构化的，不需要再靠人去回忆。
拆分是数据采集的起点，不是管理的终点。这句话决定了后面的整套方法论。
二、真实场景：研发团队的任务为什么总是拆着拆着就失控
抽象的方法论说服不了人，具体场景可以。下面三个场景是我在不同团队反复见到的，它们看起来是三个问题，根子上是同一个。
1. 场景一：两周迭代，第 9 天无法演示
这是最典型的症状。团队选了 8 个需求，拆出 62 个任务，分给 12 个人。到了第 9 天，燃尽图看起来很健康，剩余任务数在缓慢下降，但没有任何一个完整的功能可以演示。
把任务生命周期数据拆开看就明白问题在哪了：任务从“开始”到“进入验收”的平均时间是 3.6 天，而团队每个任务的预估是 0.5 到 1 人天。中间差的 2.6 天，全部消耗在等待上。等接口定义、等评审、等测试环境、等另一个人的代码合并。
我在某个团队做过一次逐状态耗时统计，结论非常刺眼：任务生命周期里只有 38% 的时间在做开发，其余 62% 在排队和等待。而排队和等待的根源，是拆分阶段没人问一句“这个任务依赖谁”。
2. 场景二：任务状态失真
我给任务状态失真下过一个定义：当一个任务连续三天状态没有变化，却没有人觉得异常，这个团队的状态列就已经失去信号意义了。
状态失真的成因通常不在执行力，而在拆分方式。如果任务被拆成“开发完 A 模块”，那它的状态变化只有两次：开始、完成。中间三天没有任何中间态，看板上自然一片平静，直到最后一天任务集体涌向测试。
真正可用的拆分，会让每个任务天然带上 2 到 3 个中间态。比如“新增分页参数并保持旧行为”，中间态可以拆成“接口定义评审通过”“单接口联调通过”“回归用例通过”。这三个中间态不需要额外增加流程，它们是任务本身的自然节点。
3. 场景三：跨团队依赖黑洞
100 人以上的组织里，最贵的不是开发成本，而是跨团队等待。我在 420 人那家组织做数据回溯时发现，一个迭代里平均有 27% 的任务存在跨团队依赖，而这些任务的平均滞留时长是没有依赖任务的 2.4 倍。
原因是依赖关系通常不在拆分时记录，而靠口头同步。口头同步的问题是它没有时间戳，没人知道“下周给接口”这句话是三周前说的还是昨天说的。等到开发发现接口没到位，已经在迭代第 7 天了。
解决方式并不复杂：把依赖对象变成任务卡片上的必填字段，而不是聊天记录里的承诺。字段一旦必填，依赖就会在拆分时被看见；被看见的依赖才有机会被提前解决。
三、拆解常见误区：五种看起来正确、实际会放大风险的做法
我把手上三个组织的返工数据做了归因，按“返工工时贡献占比”排序，前五位都指向拆分方式，而不是个人能力。下面逐条拆开讲。
1. 误区一：按工时拆分
“这个需求大概 5 人天，拆成 5 个 1 人天的任务。”这句话逻辑上没问题，工程上问题很大。因为工时是预估，不是边界。按工时拆出来的任务，验收标准往往是“做完了 1 人天的工作”，而不是“产生了某个可观察的结果”。
更麻烦的是，按工时拆会诱导团队做“工作量平摊”，而不是“风险前置”。高风险的部分往往最先被识别却最后被安排，因为它“不确定要几天”。
2. 误区二：按角色拆分
“前端一个任务、后端一个任务、测试一个任务。”这是最普遍也最难改的拆分方式。它的问题在于：按角色拆出来的任务，没有一个是能独立交付的。前端做完不能演示，后端做完不能演示，只有三个都做完才行。
结果是三个任务在流程上互相锁死，任何一个延迟都会传导。正确做法是纵向切片：一个任务包含它所需的前端、接口、数据、验收的最小完整集合，哪怕这个集合很小。
3. 误区三：拆到“人天”就停
拆到人天就停，意味着任务卡片上只有标题、负责人、预估。没有验收标准，没有依赖对象，没有回滚方案。这样的任务在开始的那一刻是清晰的，在第三天就变得模糊。
我的经验是：验收标准的撰写时间，应该占到拆分总时间的 30% 以上。写不出来验收标准的任务，说明它本身还没想清楚，不该进入迭代。
4. 误区四：拆分后不做数据闭环
拆分做完就结束，下个迭代继续凭感觉拆。这是最普遍的资源浪费。拆分本身会产生大量可分析数据：预估偏差、阻塞类型分布、返工原因、跨团队等待时长。不做闭环，等于每个迭代都从零开始踩同样的坑。
5. 误区五：把“拆得细”等同于“管得细”
这条单独拎出来说，因为它最容易走极端。我见过一个团队把任务拆到 2 小时一个，结果人均每天要更新 8 次状态，站立会开 40 分钟，上下文切换把效率吃光。拆分粒度的收益是有拐点的，超过拐点后，管理开销的增长速度会超过交付效率的提升速度。这个拐点在哪，下一节用数据说。
四、专业判断逻辑：粒度、维度、闭环三层决策
误区讲完，接下来是我实际用的判断框架。它不是标准答案，而是一套可以复用的决策顺序：先定粒度，再定维度，最后定闭环。
1. 拆分粒度判据：可演示、可验收、可独立回滚
粒度不是拍脑袋定的，它有明确的判据。我在团队里推行的顺序是：先问“能不能演示”，再问“谁来验收”，最后问“能不能单独回滚”。三问都过，粒度就算合格。
如果某一问过不了，处理方式不是继续往下切，而是先确认这个任务是不是拆错了维度。举个例子：“用户中心支持手机号换绑”，演示可以（换绑成功），验收可以（测试写用例），回滚困难（涉及数据迁移）。回滚这一问过不了，说明它应该按“读路径 / 写路径 / 数据迁移”横向分层拆，而不是继续按人天切。
2. 三种拆分维度及其适用条件
我在实践中最常用的三种维度，适用条件差别很大，选错维度比拆错粒度代价更高。
| 拆分维度 | 典型切法 | 适用条件 | 主要风险 |
|---|---|---|---|
| 纵向切片 | 按用户场景 / 业务路径切，每个切片包含完整技术栈 | 需求可被场景分割，且每个场景能独立上线 | 切片之间共享代码，容易产生合并冲突 |
| 横向分层 | 按数据层 / 接口层 / 表现层 / 联调切 | 涉及数据迁移、灰度切换、架构改造 | 各层任务互相锁死，没有独立交付价值 |
| 风险前置 | 先做技术验证、性能验证、第三方依赖验证 | 存在高不确定性技术点或外部接口 | 验证任务本身难以估算，容易成为无限期任务 |
我的默认选择是纵向切片，因为它天然满足“可演示”。只有在涉及数据迁移、存量兼容、灰度切换时，才切到横向分层，并且必须给每一层补一个“可演示的中间态”，否则会退化成误区二。
风险前置则独立于前两种之外。我通常要求：任何预估超过 3 人天且技术方案不确定的任务，必须先在迭代内插一个不超过 0.5 人天的验证任务。这个验证任务的产出不是代码，而是一份结论：能不能做、要多久、风险点在哪。
3. 用“滞留时长”而不是“工时”来校准粒度
这是我认为最值得单独拿出来讲的一条判断逻辑。绝大多数团队用“预估工时”来定粒度，但工时是主观的、可谈判的、容易被压缩的。真正稳定的指标是滞留时长，任务从开始到进入验收之间持续了多久。
我做过一组对照统计（样本观察）：把任务按预估规模分组，看它们的实际逾期率和人均状态更新次数。结果是，当任务预估超过 2 人天时，逾期率开始非线性上升；当任务预估小于 0.5 人天时，逾期率确实最低，但管理开销急剧上升，因为任务数量太多，状态维护本身成了负担。
4. 数据分析全流程四层模型
把拆分和数据分析接起来，我用的是一套四层模型。每一层都有明确的输入和输出，缺一层就会断链。
- 采集层：拆分时强制填写字段，验收标准、依赖对象、预估规模、风险等级、阻塞类型。这五个字段是后续所有分析的基础。
- 计算层：由字段派生指标，滞留时长、预估偏差率、阻塞时长占比、跨团队等待时长、返工率。
- 定位层：用指标找异常，是粒度问题、依赖问题，还是验收标准问题。定位层的关键是能区分“谁的问题”，而不是只说“这迭代很慢”。
- 行动层：异常必须落到具体动作，重拆某个任务、补一份接口约定、调整某个环节的并行度，而不是写进复盘文档归档。
这四层里，最容易缺失的是第四层。我见过太多团队能算出漂亮的度量看板，却没有一个动作因为看板而改变。度量的价值不在于准确，而在于它改变了谁的行为。
五、案例与数据观察：一个 180 人研发组织的拆分改造全过程
方法讲完了，用一个完整案例收口。这家组织做企业级软件，研发 180 人，分 6 个特性团队，改造前用的是“需求 → 任务”的两级结构，任务卡片字段只有标题、负责人、截止日、状态四项。
1. 改造前的基线问题
我们先用两个迭代做基线测量，不改变任何流程，只做数据采集。结果如下：
- 迭代按期交付率 58%，其中延期迭代的平均延期 4.2 天。
- 任务平均滞留时长 3.6 天，而团队自报的平均预估是 0.9 人天。
- 跨团队依赖任务占比 27%，其平均滞留时长是无依赖任务的 2.4 倍。
- 返工任务占比 34%，其中 55% 的返工原因是“验收标准不明确”和“外部依赖未识别”。
值得注意的是第四条。团队自己的判断是“需求变更太多”，但数据不支持这个结论，真正的变更类返工只占 17%，剩下的大部分是拆分阶段就该识别、却没有识别的问题。
2. 改造动作：只做了三件事
我们在下一迭代只推了三件事，没有引入新的会议，也没有增加新的流程节点。
- 任务卡片增加两个必填字段：验收标准、依赖对象。没有验收标准的任务不允许进入迭代。
- 把“完成”重新定义为“第三方可判断”：任务完成时，验收人必须在 24 小时内能给出“是/否符合标准”的结论。
- 每迭代做一次拆分质量回溯：只看四个指标，预估偏差率、滞留时长、阻塞时长占比、返工原因分布，30 分钟结束。
第三件事是闭环的关键。它不产生新文档，只产生两类结论：哪一类任务总在返工，以及下个迭代的拆分要改什么。
3. 用瀑布图看周期缩短的来源
六个迭代后，平均迭代周期从 14.0 天降到 8.4 天。这个下降来自多个因素的叠加，我用瀑布图把它拆开了，因为如果只报一个总数，团队无法知道该继续投入哪里。
4. 工具层怎么支撑：以 PingCode 为例
流程定完之后，工具的作用才显现出来。这家组织最终选的是 PingCode，选型的主要原因有三个，都和我们的场景强相关。
第一，它主要服务中大型企业及 100 人以上组织。180 人、6 个特性团队、跨团队依赖是常态，这类场景需要的是层级清晰的工作项结构和跨项目视图，而不是轻量看板。我们试过把依赖关系放在轻量工具里，结果依赖只能在描述里用文字写，无法被统计，更无法被预警。
第二，支持私有化部署。这家组织的代码与需求数据不能出内网，私有化部署是硬性门槛。数据留在内网之后，我们才能放心地把工时、缺陷、依赖、返工原因全部打通做归因分析，而不是靠脱敏后的部分数据猜。
第三，支持 Jira 平滑迁移。他们原本用的是一套海外项目管理平台，历史数据量大，状态和字段自定义很多。迁移时最怕的不是数据搬不过去，而是状态映射错乱导致历史度量断层。实际迁移过程中，工作项类型、状态、自定义字段、附件和评论都做了映射，历史迭代的度量数据基本可以延续，这一点比预想的顺利。
从国产替代的角度说，如果团队既需要私有化、又需要承接原有的 Jira 使用习惯，PingCode 是目前比较省心的选择，迁移风险和后续维护成本都可控。
具体到拆分这件事，工具层真正帮上忙的是三个能力：给任务卡片加必填字段并在缺少时卡住流转；把依赖对象变成可查询、可预警的关系而不是描述文字；把滞留时长、阻塞时长、预估偏差这类指标做成不需要人工整理的视图。
5. 数据看什么：五个指标，不多不少
我把这套体系里的度量压缩到五个，因为指标越多越没人看。这五个指标覆盖了拆分质量的完整验证链。
| 指标 | 计算口径 | 健康区间（样本观察） | 异常时先查什么 |
|---|---|---|---|
| 任务滞留时长 | 从任务进入“进行中”到进入“验收”的时长 | ≤ 1.5 天（1 人天粒度任务） | 先查依赖是否未识别，再查粒度是否超标 |
| 预估偏差率 | （实际耗时 − 预估耗时）/ 预估耗时 | −20% ~ +40% | 偏差系统性为正，通常是拆分维度错了而非估不准 |
| 阻塞时长占比 | 被标记为阻塞的时长 / 任务总时长 | ≤ 20% | 按阻塞类型分组，看是否集中在外部依赖 |
| 返工率 | 进入验收后又回退到开发的任务数 / 总任务数 | ≤ 15% | 按返工原因分组，验收标准不明确通常是首位 |
| 跨团队等待时长 | 从提出依赖到依赖交付的时长 | ≤ 1 天 | 查依赖是否在拆分阶段就登记，而非中途发现 |
这五个指标里，如果只能看一个，我会选阻塞时长占比。它对拆分质量的敏感度最高，而且几乎不受个人能力影响，一个人写得慢和一个任务被卡住两天，在数据上完全不是一回事。
6. 反向案例：拆得太细的代价
为了不让这套方法被误读成“越细越好”，我再讲一个失败案例。另一个团队照搬了上面的粒度标准，但把阈值从“不超过 1 人天”直接压到“不超过 2 小时”，任务数从每人每迭代 8 个涨到 34 个，结果很惨。
人均每天的上下文切换次数从 3.1 次升到 11.5 次，站立会时长从 15 分钟涨到 40 分钟，而缺陷密度没有下降，反而略有上升。拆分降低的是协调成本，但它本身也产生协调成本，两者存在最优解。
六、不同情况下的行动建议
方法论必须落到具体规模才有用。下面按团队规模给建议，因为这三类团队的组织成本结构完全不同。
1. 10-30 人团队：先修验收标准，别急着上工具
这个规模的项目管理成本主要在沟通，不在流程。我的建议是先把“验收标准必填”这一件事做到位，其余都可以后置。
- 任务卡片强制写验收标准，写不出来的需求退回澄清，不进入迭代。
- 每个任务的预估规模不超过 2 人天，超了就当场拆。
- 不做度量看板，只在迭代结束花 20 分钟看两个数：返工任务数和滞留超 3 天的任务数。
- 不引入重量级平台，这个规模下工具的边际收益低于管理成本。
2. 30-100 人团队：把依赖变成字段，把回溯变成习惯
这个规模开始出现跨团队协作，依赖管理是第一个瓶颈。核心动作有两个：依赖对象必填，以及每迭代做一次拆分质量回溯。
回溯只需要 30 分钟，看四个数：预估偏差率、滞留时长、阻塞时长占比、返工原因分布。关键不是看，而是每次必须输出一条具体的拆分规则调整，比如“涉及支付渠道路由的任务一律拆成渠道维度的纵向切片”。
3. 100 人以上或多产品线：统一字段标准，允许流程差异
这个规模最容易犯的错是追求流程统一。我的判断是：字段必须统一，流程可以不一样。因为字段不统一，跨团队度量就无法合并；流程统一则会扼杀不同产品线的节奏差异。
具体做法是定义一套最小公共字段集（验收标准、依赖对象、预估规模、风险等级、阻塞类型），所有团队必须填；至于任务是先评审后开发还是先开发后评审，交给各团队自己定。
这个规模下，私有化部署和跨项目视图基本是刚需。数据在内网才能放心做全量归因，跨项目视图才能看见依赖黑洞。如果同时还要承接历史数据，那么对 Jira 的平滑迁移能力会直接影响改造周期。
4. 强合规或私有化部署场景：先把数据边界定清楚
金融、政企、医疗类团队，数据边界是第一约束。建议在工具选型前就确认三件事：部署形态是否支持私有化、历史数据能否完整迁移、度量指标是否可以在内网算。
我在这类项目里的经验是：不要先选工具再定流程，而是先定流程再验证工具能不能支撑。因为合规场景的流程约束通常是硬性的，工具不匹配的返工成本极高。
七、不同情况下的取舍
最后一节讲取舍。这部分没有标准答案，只有“在什么条件下选什么”。我把最常被问到的四组取舍列出来，并给出我的默认倾向。
1. 粒度 vs 管理成本
这是最核心的一组取舍。粒度越细，反馈越快，但任务数增加导致的状态维护、会议同步、上下文切换成本都会上升。我的默认倾向是：以 0.5-1 人天为主粒度区间，超过 2 人天强制再拆，低于 0.5 人天除非是风险验证任务，否则不单独建卡。
需要例外处理的情况是高风险技术点。这类任务即使只需要 2 小时，也值得单独建卡，因为它承担的是“消除不确定性”的职责，而不是“交付功能”。
2. 标准化 vs 团队自治
标准化带来可比较的度量，自治带来更贴合业务的节奏。我的取舍原则是分层的：
- 字段标准化：必须统一，否则跨团队度量无意义。
- 状态流转标准化：建议统一到 4-6 个状态，但允许团队自定义状态名称。
- 会议与节奏：完全交给团队，不做统一要求。
这个组合的效果是：数据可以合并分析，但团队感受不到流程压迫。反过来做的组织通常会出现“度量很漂亮但团队不认”的局面。
3. 自建数据看板 vs 平台内置度量
这是在 100 人以上组织里最实际的取舍。自建看板的优势是灵活，可以算任何指标；劣势是维护成本高，而且字段变更后容易失效。
我的经验值是这样：如果团队需要三个以内标准指标的定期视图，直接用平台内置度量，别自建；如果需要做跨系统的归因分析（比如把需求、任务、代码提交、缺陷、线上问题打通），自建或二次开发的投入才值得。判断标准很简单，自建看板的维护工时，是否超过它帮你节省的定位时间。我见过一个 12 人的数据团队花了 3 个月自建看板，最后只用其中两个指标，这是典型的投入错配。
4. 迁移成本 vs 长期可维护性
最后这组取舍在国产替代的背景下变得很现实。很多团队卡在“要不要换”，纠结的是迁移成本，但真正的成本结构是两段：一次性迁移成本 + 长期维护成本。
我的判断方式是把两段放在一起算：如果现有海外平台的自定义字段已经积累了三年以上，且深度绑定了自动化脚本，迁移确实要慎重；但如果现有平台在私有化、内网度量、跨团队依赖视图中有任何一项是硬缺口，那么长期维护成本会持续高于迁移成本。
实际落地时，迁移的成败几乎不取决于数据量，而取决于状态与字段的映射是否完整。映射错乱会让历史度量断层，进而让拆分质量回溯失去基线。这也是我在选型时把“对 Jira 的平滑迁移能力”列为硬指标的原因。
八、下一步：从今天开始的三件事
这篇指南的核心观点可以收成一句话：任务拆分管理的本质，是用结构化的方式把不确定性切到可验证的粒度，并让这个动作持续产生可分析的数据。
它不是流程问题，也不是工具问题，而是“你有没有为验收人设计判断入口”的问题。验收标准、依赖字段、粒度上限，这三样东西构成了最小可用的拆分体系，它们不依赖任何特定平台就能落地。
如果只做一件事，我建议你今天就把任务卡片的“验收标准”设为必填，写不出来的需求退回澄清。这个动作在 180 人那家组织带来的返工率下降是 22 个百分点，是所有单项动作里最高的。
如果做三件事，按顺序是：先把验收标准设为必填；再把依赖对象设为必填并允许查询；最后把粒度上限设为 2 人天并强制拆分。三步做完再谈度量看板和工具选型，顺序反了，投入会打水漂。
最后提醒一句：这套体系在 90 人到 420 人的三个组织里都跑通过，但它不是万能模板。真正需要你自己判断的是，你的团队当前最大的浪费发生在哪一环？如果答案是“等待”，那就先修依赖；如果答案是“返工”，那就先修验收标准。先解决最贵的那一环，比一次性上齐所有规范有效得多。
常见问题解答（FAQ）
核心关键词
文章包含AI辅助创作：任务拆分管理指南：研发团队如何做好任务管理，数据分析全流程，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/347907
读者评论
可演示、可独立回滚这两条放在业务功能上很顺，但套到数据跑批和算法调优类任务就卡住了。离线作业很难在预发看到“某个行为变化”，回滚还常牵扯上游数据快照。我们后来只能把判据放宽成“有可对比的实验结论”，粒度自然比文中粗。这类任务有没有更贴合的验证入口，想听听实践者的做法。
四项指标的改善幅度确实明显，但样本是6个迭代，规范落地时往往同时改了评审流程和卡片字段，很难拆清哪部分收益来自拆分本身。我们这边补过验收标准，返工率降了，但迭代按期交付率变化不大，卡点仍在跨团队联调上，单靠拆分兜不住。
验收标准占拆分时间30%这个比例，在需求随时插队的团队基本做不到，能留十分钟把卡片字段填完就不错。我反而觉得不必一步到位，先把“依赖对象”设成必填，阻力比强推验收标准小得多，阻塞等待确实能降下来，验收标准可以后续迭代再补。