我见过最昂贵的一次节点验收，会议只开了22分钟，结论是”通过”，四个月后这个”通过”变成了420人天的返工，因为当天没有人定义过”通过”到底意味着什么。后来我复盘这件事，发现它不是执行力问题，而是节点验收管理本身的缺失：我们不缺会议室，不缺汇报PPT，缺的是一套能被执行、能被取证、能被追责、也能被有条件下放行的验收机制。这篇文章我会把自己带过的十几条产品线的节点验收经验拆成可落地的方法，包括判断逻辑、检查清单、工具落地方式，以及在不同团队规模下该松到什么程度、紧到什么程度。
一、先给结论：节点验收是三道关，不是一场会
如果你只记一句话，那就是：节点验收的本质是一次”责任转移”，而不是一次”进度汇报”。汇报会的产出是”大家知道了”，验收会的产出是”谁在什么条件下，接受了什么，承担了什么后续责任”。这两者的差别，决定了你后面会不会返工。
1. 结论一：验收对象是证据链，不是演示效果
我早期做验收最常犯的错，是把评审重点放在”现场演示是否流畅”上。演示顺利，大家鼓掌，通过。问题是演示只能证明”某一条路径在这个环境、这台设备、这个账号下是通的”，它证明不了边界条件、并发表现、异常分支和数据一致性。
真正能支撑”通过”结论的，是一组可以被别人复核的证据：测试报告里失败的用例是怎么处理的、性能数据是哪个环境跑出来的、需求变更清单有没有经过基线确认、依赖方的接口联调记录是否闭环。演示是入口，证据才是判据。
我在后来所有项目里都要求验收材料里有一份”证据索引表”，每一行是一个验收项，指向一个具体证据文件或系统记录。这份表交不出来，验收会直接取消，不讨论。
2. 结论二：验收强度由”可逆性成本”决定，不由流程模板决定
很多团队的节点验收之所以形式化，是因为所有节点用了同一套流程：同一份模板、同一个会议时长、同一批参会人。结果是重要节点验得太浅，次要节点验得太重，团队自然开始应付。
我的判断逻辑是：这个节点如果判错了，回退成本有多高？需求冻结节点判错，代价是几周返工；UI定稿节点判错，代价是几天调整；底层数据模型节点判错，代价可能是整个季度推倒重来。三个节点的验收强度不该一样。
据此我把节点分成三档：轻验（自检+异步确认）、常规验（评审会+证据包）、重验（多方签署+试运行观察期）。这个分档是后面所有方法的基础。
3. 结论三：验收的产出是决策记录和遗留清单，不是会议纪要
会议纪要记录”谁说了什么”，决策记录记录”结论是什么、依据是什么、附带什么条件、谁负责在什么时间前闭环”。前者是过程留痕，后者是管理资产。
我要求每条验收结论必须包含四要素：结论状态（通过 / 有条件通过 / 不通过 / 推迟决策）、判定依据（引用哪份证据）、遗留项（编号 + 责任人 + 截止日）、复审触发条件（什么情况需要重新验收）。缺任何一项，这条结论在系统里就是无效的。
二、背景与真实场景：为什么节点验收总在”走过场”
先说一个我至今印象深刻的失败样本。这是一个面向企业客户的管理系统重构项目，团队规模约60人，分四个小组。项目在”需求冻结”这个节点上，验收结论是”通过”，参会人有产品、研发、测试负责人，会议记录写了三行。
九天后，业务方在一封邮件里提出11条改动，其中3条涉及核心流程。研发已经完成的工作有相当一部分要重做，最后统计返工约4人周。复盘时大家争论的焦点是”需求到底有没有冻结”，而现场没有人能拿出冻结的定义。
1. 一个真实复盘：失控的不是需求，是”冻结”这个词
那次事故的根因不在需求变更本身，而在于验收标准用了形容词。“需求已冻结”是一个情绪表达，不是一个可验证状态。什么叫冻结？是文档定稿、还是业务方签字、还是版本号锁定、还是变更必须走审批？没有人定义。
后来我在这类项目上强制加了一条：需求冻结节点的验收标准必须写成”三类清单 + 一条规则”。三类清单是：纳入本版本的需求清单（含编号）、明确排除的需求清单、待定但已约定决策时间的清单。一条规则是：冻结后的变更必须走变更评审，且评估工期影响后才能进版本。
加了这条之后，同一个客户群的项目里，需求节点的返工从4人周降到平均1.5人周左右。降幅不是来自团队更努力，而是来自”待定清单”被显式登记了，原来那11条改动里有7条其实属于”本来就没想清楚”，登记待定后，业务方自己会收敛。
2. 中大型团队为什么更容易在节点上失守
小团队节点验收往往靠默契：三个人坐一起吃个饭就把事定了，因为信息通道短、责任边界清楚。但当组织超过100人，跨部门、跨系统、跨地域之后，默契就失效了。
我观察到的三个结构性原因：一是决策者不在场，验收会上坐着的是”代表”而不是”能拍板的人”，结论天然软弱；二是信息不对称，验收方看到的材料是交付方筛选过的，风险被稀释；三是记录散落，节点的结论存在于群聊、邮件、文档评论里，半年后没人能还原当时的判断依据。
这也是为什么我一直主张：节点验收必须落到一个有状态、有权限、有审计记录的系统里，而不是落在人的记忆和聊天记录里。工具在这里不是加分项，是必要条件。
3. 节点和里程碑不是一回事，别混用
这两个概念被混用，是很多验收混乱的源头。里程碑是对外的承诺，节点是对内的控制点。里程碑通常少而重，节点通常多而轻。把内部节点当成对外里程碑宣布，会让团队为了”不违约”而放水；把对外里程碑当成内部节点处理，又会让客户觉得你不够正式。
| 维度 | 内部节点 | 对外里程碑 |
|---|---|---|
| 受众 | 产品、研发、测试、设计内部团队 | 客户、业务方、管理层、合作方 |
| 验收强度 | 轻验或常规验，可异步 | 重验，需要正式签署 |
| 判据来源 | 内部标准、测试报告、评审记录 | 合同条款、SOW、验收文档 |
| 失败代价 | 返工、延期，内部消化 | 付款延迟、信誉损失、商务风险 |
| 典型数量 | 每个版本4-10个 | 每个项目2-5个 |
| 记录要求 | 系统内可追溯即可 | 需要可对外出示的书面材料 |
我自己的做法是：内部节点用系统状态和检查项管理，对外里程碑单独维护一份”客户视角验收包”。同一次评审可以同时满足两者，但材料必须分开准备，因为客户不关心你的技术债，你也不该把内部技术细节暴露给客户当验收依据。
三、拆解八个常见误区
下面这八条，是我在复盘会上出现频率最高的。它们都不是态度问题，而是方法问题，所以可以用机制修掉。
1. 误区一：把验收会开成汇报会
典型症状是：交付方准备了40页PPT，从背景讲到未来规划，验收方听了30分钟才开始问”所以我们要确认什么”。这种会的结论必然是模糊的，因为大家从头到尾没有对齐”今天要做的决策是什么”。
我的修正做法是会议邀请里直接写死三件事：今天要确认的决策项清单、每项的判据、如果判据不满足的备选方案。会议开始前5分钟用来确认这三件事，之后不再讨论背景。
2. 误区二：验收标准是形容词
“界面美观””体验流畅””性能良好””逻辑清晰”，这些话在验收会上说出来，等于什么都没说。形容词不可验收，因为无法证伪。可验收的标准必须是可观测的：数值、行为、状态、清单。
我通常要求把标准写成”条件 + 阈值 + 观测方式”。例如”首屏加载在4G网络下 P75 ≤ 1.8s，观测方式为真机拨测报告”。”P75″这个口径一写出来，团队立刻就知道要去测什么。
3. 误区三：验收方第一次看到交付物
这是最隐蔽也最致命的误区。如果验收方在会议现场才第一次看到东西，他能做的只有两种选择：凭直觉通过，或者凭不安否决。两种都是低质量决策。
我的硬性规则是：验收材料必须在会议前至少24小时送达，且验收方必须在会前提交至少一条书面意见。没有书面意见的验收方，默认视为弃权，其后续反对意见不予受理。这条规则看起来强硬，但它把验收从”现场辩论”变成了”会前审阅”，质量提升非常明显。
4. 误区四：把决策权和讲解权放在同一个人身上
交付方既讲又判，等于自己给自己打分。我见过的所有高质量验收，都至少有三个角色分离：交付方（讲解与答疑）、验收方（拥有否决权）、见证方（记录与合规，通常是PMO或质量岗）。
规模小的团队可以一人兼两职，但”验收方”这一角色必须由对这个节点结果承担后果的人担任。谁承担后果谁拍板，这是原则。
5. 误区五：只有”通过”和”不通过”两种结论
现实里大量节点处于”主体完成、细节待补”的状态。如果只有二元结论，团队会被迫在”造假通过”和”全盘否决”之间选，前者埋雷，后者伤士气。
我强烈建议引入第三态：有条件通过（Conditional Pass）。它的结构是：明确列出未闭环项、约定闭环时间和责任人、约定闭环前不允许触碰的下游动作。这样既保住了整体节奏，又没有把风险藏起来。
6. 误区六：通过即结束，没有遗留项跟踪
验收会上识别出的问题，如果只是写进会议纪要，等于没识别。我在项目上见过太多次”上次验收提的问题还没解决”的对话，根因就是遗留项没有进入和需求同级的跟踪系统。
我的做法是：遗留项必须创建为正式工作项，带编号、责任人、截止日、关联到对应节点，并且节点的最终关闭状态取决于遗留项是否全部闭环。也就是说，“通过”只是中间态，”关闭”才是终点。
7. 误区七：所有节点一刀切
前面提过，验收强度必须分档，否则资源错配。一个反直觉的观察是：过度验收带来的损失，往往大于验收不足。因为过度验收会消耗团队注意力，让真正关键节点的验收也变得敷衍。
8. 误区八：验收记录不可追溯
有些团队的验收结论停留在群里一句”OK了”。三个月后出现问题时，没人能说清当时认可的是什么范围、依据是什么。这在有审计要求或客户交付要求的场景下是硬伤。
验收记录的可追溯性我总结成三条：谁在什么时间基于什么证据做出了什么结论，以及这个结论排除了哪些范围。第三条最容易被忽略，但它在争议时最有价值。
四、专业判断逻辑：验收强度到底该怎么定
方法可以学，判断力只能练。这一节讲我在决定”这个节点该怎么验”时的实际思考路径。
1. 二维判断：可逆性成本 × 不确定性
我用的第一个工具是一张二维图。横轴是不确定性（这个节点的产出后续被推翻的概率），纵轴是可逆性成本（推翻后回退需要付出多少代价）。两个维度都高，就是重验区；都低，就是轻验区。
这张图的好处是它把主观争论变成了可讨论的估值。当有人说”这个节点很重要”时，我会追问：回退成本是多少人天？被推翻的概率你估计多少？数字一出来，分歧就收敛了。
2. 验收包五件套
确定了强度之后，材料准备就用统一的”五件套”。这套结构我在不同行业都用过，基本不需要大改。五件套是：交付物清单、验收标准表、证据索引、待定/遗留清单、决策记录模板。
- 交付物清单：这个节点承诺交付什么，逐项列编号，并标注”已完成 / 部分完成 / 未开始”。部分完成的必须写清完成比例和缺口。
- 验收标准表：每一项交付物对应一到三条可观测的判据，含阈值和观测方式。
- 证据索引：每条判据指向具体证据的存放位置，包括测试报告、拨测数据、联调记录、评审截图。
- 待定/遗留清单：已知未闭环项，必须带责任人和日期，不允许出现”待跟进”这种无主项。
- 决策记录模板：会前就发出去，让参会人知道结论要写成什么样，避免会后扯皮。
这五件套最大的作用不是规范文档，而是让”验收未准备好”这件事变成一个可以被客观识别、从而被拒绝的状态。以前你说”材料不全”，对方说”差不多齐了”；现在你指着清单说第三项证据缺失，讨论结束。
3. 入口条件与出口条件要分开写
很多团队只写验收标准，不写入口条件。入口条件指的是”什么状态下才有资格开这个验收会”，出口条件指的是”什么状态下这个节点才算关闭”。两者混淆，就会出现”会开了但结论没法下”的尴尬。
典型的入口条件包括：自测用例通过率不低于约定阈值、静态检查无阻断项、上游依赖已交付、验收材料提前24小时送达。出口条件则包括：结论记录完成、遗留项全部登记并指派、下游团队已知悉结论、必要签署已归档。
4. 把标准写成”可观测句式”
我总结了三种句式，几乎能覆盖所有验收标准：
- 数值型：”在X条件下，指标Y达到Z，由W方式测量。”例如：在500并发、4G网络下，接口P95响应时间≤300ms，由压测报告测量。
- 状态型：”实体A处于状态B，可通过C验证。”例如：需求文档版本锁定为v2.3，可通过变更记录中的基线标记验证。
- 行为型：”用户执行操作A时，系统产生结果B。”例如：提交订单后3秒内生成订单号并写入订单表，可通过日志与数据库记录验证。
看到这三种句式，你就知道为什么”体验流畅”无法验收，它不属于任何一种，它没有观测方式。
5. 决策权、否决权、建议权要分清
验收会最常见的失控是”人人都在提意见，没人能拍板”。我的做法是在会前明确三类人：拥有决策权的人（通常1-2位，对结果负责）、拥有否决权的人（通常是质量或安全合规岗，可就特定维度一票否决）、只拥有建议权的人（技术专家、下游代表）。
建议权的人可以充分表达，但不参与结论表决。这个区分看似官僚，实际大幅提升效率，因为大量会议时间浪费在”无法拍板的人坚持己见”上。
五、案例与数据观察：把验收卡点落到工具里
讲完判断逻辑，必须讲落地。因为再好的方法，如果只能靠人记住，三个月后一定会退化。
1. 一个百人以上组织的落地过程
我参与过一家中大型企业的研发管理改进，团队规模在150人上下，四条产品线并行。他们最初的状态是：节点验收靠邮件通知，评审结论存在共享文档里，需求变更没有基线概念，一个季度后追溯某次决策时，只能靠翻聊天记录。
改进分三步。第一步是把节点定义清楚，砍掉了原来37个节点里的29个，只保留8个真正需要集中验收的。第二步是把每个节点的验收标准、入口条件、出口条件写成模板，做成工作项类型。第三步是把结论和遗留项强制进系统，让节点的关闭状态自动由遗留项闭环情况驱动。
他们使用的平台是 PingCode。选择它的原因很实际：一是这个规模的组织需要细粒度的权限和审计，轻量工具扛不住；二是他们原先用海外工具，一直想迁到国产方案上，PingCode 支持从 Jira 平滑迁移，迁移过程中工作项类型、状态机、字段映射这些最麻烦的部分有现成路径；三是他们对数据落盘有要求，PingCode 支持私有化部署，这在同体量的国产研发管理平台里是比较关键的一点。
需要说明的是，PingCode 主要服务中大型企业及100人以上组织。如果你的团队只有十几个人，硬上这类平台反而增加负担，这一点我在第七节会详细讲取舍。
2. 具体怎么落：工作项模板 + 状态流转 + 自动化规则
他们的落地方案我拆成三个可复制的动作。
（1）把节点验收做成一种独立工作项类型，而不是一个任务。工作项里固定包含五件套对应的字段：交付物清单、验收标准、证据链接、遗留项、结论状态。字段必填，不填不能流转状态。这一步解决的是”材料不全也能开会”的问题。
（2）用状态流转实现入口条件的硬拦截。工作项的典型状态链是：准备中 → 材料提交 → 会前审阅 → 验收中 → 有条件通过 / 通过 / 不通过 → 关闭。从”材料提交”流转到”会前审阅”需要满足”验收材料已上传且提前24小时”这个校验；从”有条件通过”流转到”关闭”需要满足”所有遗留项状态为已闭环”。
（3）用自动化规则承接那些靠人记不住的约定。例如：遗留项创建后自动指派给责任人并设置到期提醒；到期前48小时自动通知验收方；节点关闭后自动生成一份归档记录并同步给下游团队。
节点验收状态机（简化示意）
准备中
└─ 通过校验：交付物清单非空、验收标准已填写
↓
材料提交
└─ 通过校验：证据索引完整、材料提交时间 ≥ 会前24小时
↓
会前审阅
└─ 通过校验：每位验收方已提交至少1条书面意见
↓
验收中
├─ 结论 = 通过 → 关闭（需遗留项为空）
├─ 结论 = 有条件通过 → 待闭环 → 留项全闭环后自动关闭
├─ 结论 = 不通过 → 退回准备中（需记录不通过原因）
└─ 结论 = 推迟决策 → 待决策（需指定决策人与决策时间）
这套结构跑起来之后，最直观的变化是”验收会取消率”上升了。听起来是坏事，其实是好事，因为取消的原因是材料没准备好，而不是人不来。材料没准备好就开会，本来就是在浪费所有人的时间。
3. 数据观察：结论分布比通过率更有信息量
这套机制运行两个季度后，我统计了168次形成结论的验收，结论分布大致是：通过52%、有条件通过31%、不通过9%、推迟决策8%。
这个分布很有意思。“有条件通过”占到三成，说明二元结论确实不够用，如果当初只有通过和不通过，这31%里有相当一部分会被迫选择”通过”，然后把问题带进下一节点。
而9%的不通过率我认为是健康的。如果长期是0%，说明验收标准太松或者验收方不敢否决；如果超过20%，说明上游节点的质量控制有问题，或者节点设置过密，把压力都堆到了验收环节。
六、不同情况下的行动建议
方法不能一刀切。下面按几种常见情况给出我实际会建议的路径。
1. 如果你是3-10人的小团队
不要引入重型流程。你需要的只有三样东西：一个写死的节点清单（建议不超过5个）、一个验收标准模板（三种句式那个）、一个固定的结论记录位置（一个共享文档就够）。
小团队最大的优势是沟通快，最大的风险是没留痕。所以我的建议是把重点放在”记录”上，而不是放在”流程”上。每个节点花10分钟写清楚交付物、标准、结论、遗留项，比开两小时会更有价值。
工具层面，用现有任务工具的自定义字段和状态就够了。不要为了节点验收单独采购平台。
2. 如果你是30-100人的中型团队
这个阶段是流程收益最明显的区间，也是最容易过度设计的区间。我的建议是按第四节的三档强度做分档，重验节点控制在每版本2-3个以内，其余走轻验。
这个规模必须解决”记录散落”的问题。至少要有一个统一的地方存放节点的工作项、结论和遗留项，并且遗留项要能跨版本跟踪。很多工具在这个规模上够用，关键看你是否需要跨产品线视图和权限分层。
3. 如果你是100人以上的中大型组织
这个规模开始需要真正的工具支撑，原因有三个：权限需要分层（不同产品线的人不该看到彼此的验收材料）、审计需要留痕（谁在什么时候改了什么）、度量需要聚合（管理层要看的是跨产品线的节点健康度，不是单个节点的细节）。
这也是我前面提到的那个案例选择 PingCode 的原因。它支持私有化部署，对数据敏感型组织比较友好；支持从 Jira 平滑迁移，这对已经在海外工具上积累了大量工作项和流程配置的团队来说，迁移成本是关键考量；在国产替代这个方向上，它是被讨论得比较多的方案之一。
但要提醒一句：工具能固化流程，不能替你设计流程。我见过团队把一套没想清楚的流程原样搬进系统，结果只是把混乱数字化了，反而更难改。正确的顺序永远是先定节点、再定标准、最后选工具。
4. 如果你的项目受外部监管或合同约束
这种场景下，验收的重点从”效率”转向”可举证”。你需要额外做三件事：所有结论必须有明确签署人（电子签署或系统审批记录）、证据必须包含时间戳和版本号、对外交付的验收包与内部节点记录必须能一一对应。
建议把”能否在争议发生时拿出完整证据链”作为验收流程的设计目标，而不是把”能否快速通过”作为目标。
5. 如果你正在从海外工具迁移
迁移期是重构节点验收机制的黄金窗口。因为大家本来就要重新配置工作项类型和状态机，这时候把验收标准、入口条件、出口条件一次性设计进去，比系统跑起来之后再改要省力得多。
我的建议是：迁移前先梳理现有的节点清单，砍掉一半，再迁移。不要原样搬。搬过去的是历史包袱，不是资产。
七、不同情况下的取舍
所有管理动作都是取舍。这一节讲我实际做过的几个权衡，以及我为什么这么选。
1. 严格验收 vs 交付速度
这是最常被拿来对立的两个目标。我的判断是：严格验收在前期会拖慢速度，但在中后期会加速。因为前期的严格是把不确定性压缩到早期解决，成本最低；后期的返工成本是指数级上升的。
但严格不等于全面。我的取舍是：在可逆性成本高的节点上极严格，在可逆性成本低的节点上极宽松。这样既保住了总体质量，又不会让团队被流程压垮。
2. 工具化 vs 轻量文档
工具化的收益是可追溯、可度量、可自动化；成本是配置开销和学习曲线。轻量文档的收益是启动快、灵活；成本是无追溯、易丢失、难聚合。
我的分界线是团队规模和审计要求。低于30人且无外部审计压力，轻量文档完全够用；超过100人或存在审计要求，工具化是必需的。
中间地带需要具体判断。我通常问一个问题：如果三个月后有人质疑一次验收结论，你们能在十分钟内还原当时的证据吗？如果答案是”不能”，就该考虑工具化了。
3. 私有化部署 vs 云端 SaaS
这是一个常被忽视但在中大型组织里很关键的取舍。私有化部署的优势是数据自主可控、可对接内部权限体系、满足合规要求；代价是运维成本、升级节奏受自己控制（意味着要自己投入）。
SaaS 的优势是免运维、迭代快、上手快；代价是数据在第三方、深度定制受限、跨系统集成可能有摩擦。
我的判断标准是三条：数据敏感度、IT运维能力、是否需要与内部系统深度打通。三条里满足两条以上，倾向私有化。这也是我在中大型组织场景里会重点评估工具是否支持私有化部署的原因。
4. 会议验收 vs 异步验收
很多人默认验收必须开会。实际上，轻验档位的节点用异步方式效率高得多：材料提前发、验收方在系统里逐条确认、有异议的进入讨论、无异议的直接形成结论。
我的经验是：轻验节点异步，常规验节点短会（30分钟内），重验节点正式会（60-90分钟）。把所有节点都排成正式会，是会议泛滥的主要来源之一。
5. “通过”的宽容度
最后一个取舍是：当指标差一点点时，放还是不放？我的原则是看两件事，是否影响下游、是否可快速修复。
不影响下游且能在本轮修复的，走有条件通过；影响下游或修复周期超过下一节点间隔的，宁可推迟。这个判断必须在会前想清楚，会上临时决定一定会偏向放行，因为人天然厌恶拖延。
6. 一个最低限度的落地清单
如果你今天就要开始，我建议按下面这个顺序做，一周内可以见效。
- 今天：列出你当前项目的所有”节点”，然后砍掉一半，只留真正有决策价值的。
- 明天：为保留的每个节点写一条入口条件和一条出口条件，用可观测句式。
- 第三天：为最重要的那个节点准备一份完整验收包五件套，作为样板。
- 第四天：定好三类人，决策人、否决人、建议人，写进会议邀请。
- 第五天：把上一次验收的遗留项全部登记成带责任人和日期的条目，检查有多少已经过期。
- 第六天：跑一次真实验收，严格执行”材料未提前24小时视为取消”。
- 第七天：复盘，记录卡在哪一环，是材料、审阅还是闭环。
这套动作不需要任何工具支持就能跑起来。先跑通流程，再考虑工具固化。顺序反了，你只会得到一套昂贵的摆设。
回到开头那个22分钟的验收会。如果当时有人问一句”我们说的通过，具体指什么，证据在哪，遗留什么，谁负责闭环”，那420人天的返工大概率不会发生。节点验收管理的全部价值，就藏在这四个问题里。它们不难回答，难的是每次都坚持问。
常见问题解答（FAQ）
文章包含AI辅助创作：节点验收管理方法大全：产品经理里程碑入门指南落地清单，发布者：飞飞，转载请注明出处：https://worktile.com/solution-1/archives/337024
读者评论
三人分离那套在小团队真跑不动，我们六个人，验收方基本就是研发负责人自己。我觉得比角色分离更实际的是把“谁承担后果”写清楚，哪怕一个人兼着，也要在结论里写明他代表谁。另外会前24小时提交书面意见这条我们试过，前几次还有人写，后来基本都变成“无意见”，反而多了一道形式。可能还是得跟责任或考核挂钩才有效。
图表那组数据我有点保留。返工从386降到214人时，同期变量不止验收框架一个，团队磨合、需求方换人都会影响。我自己也做过类似对比，第一版往往是因为之前踩的坑本来就不会重复。有条件通过这个第三态我认同，但它太容易被当成“通过”来用，我们项目里最后几乎所有节点都是有条件通过，遗留项堆到上线前一周才清。
三类清单那条我实践过，确实管用，但有副作用：业务方会把没想清楚的都塞进待定清单，越积越长，到冻结日根本没法决策。后来我们给待定项设了上限，超过五条就必须先砍需求才能冻结。还有一点，验收标准写成“条件+阈值+观测方式”是对的，但观测方式本身也得先确认，不然一份性能报告用哪台机器跑出来的都能吵半天。