阶段验收落地方案：产品经理开展项目阶段的数据分析案例解析

阶段验收最容易失效的时刻，不是数据缺失，而是数据全绿。

2023 年第三季度，我参与评审过一条产品线的阶段验收。当时看板上需求完成率 96%，缺陷收敛曲线漂亮得像教科书，燃尽图按计划触底，评审会上几乎没有人提出反对意见。这个阶段顺利通过验收，团队拿到了下一阶段的资源。

结果上线两周后，三个 P1 级缺陷连续爆发，其中一个直接导致核心业务流程中断 4 小时。复盘时我们发现，问题不在执行，而在口径，那个 96% 的”完成率”，统计的是开发自测通过，而不是验收通过。真正走完验收流程的需求，比例只有 71%。这 25 个百分点的差额，就是整个阶段验收数据分析失效的全部原因。

这篇文章基于我过去几年在中大型研发组织里做阶段验收的实操经验，拆解产品经理该怎样开展项目阶段的数据分析：口径怎么定、指标怎么选、阈值怎么设、工具怎样承载，以及不同规模、不同监管强度的团队该怎样取舍。

一、核心结论：阶段验收的数据分析，本质是在为”继续投入”找证据

很多产品经理把阶段验收的数据分析理解成”给领导做一份好看的汇报”。这个定位一旦错了，后面所有的指标体系都会跟着错。我先把五条结论放在前面，后面再逐条拆。

1. 结论一：验收数据的服务对象是决策，不是汇报

阶段验收的核心问题只有一个：下一个阶段，资源应该继续投、需要纠偏、需要收缩，还是应该暂停？

所有指标都应该回答这个问题的某个侧面。如果一个指标很好看，但它无法影响上述四个决策中的任何一个，那它就是装饰品。我在做验收数据设计时有个习惯：每加一个指标，先问自己”如果这个指标跌了 20%，我会改变决策吗”。答不上来，就删掉。

2. 结论二：口径必须先于数据存在

这条是我踩坑最多的地方。同一个词在不同角色嘴里意思完全不同：”完成”对开发是代码提交，对测试是用例通过，对产品是验收通过，对运维是上线成功。如果口径没有在阶段开始前写死，”完成率”这个数字就是不可比的。

我的做法是把口径写成一句话可复述的定义，并且落到工具里成为可执行的过滤条件，而不是停留在文档里。例如”需求完成”定义为：该需求关联的所有子任务状态为已完成，且关联缺陷中不存在未关闭的阻断级缺陷，且验收人已点击验收通过。

3. 结论三：证据要分三层，不能混在一张表里

第一层是事实层，由系统自动采集，不可人工修改，比如状态流转时间、代码提交记录、缺陷关闭时间。第二层是判断层，由人给出，比如验收人评分、需求价值复核结论。第三层是预测层，基于前两层做的趋势外推，用于判断”如果保持当前节奏，下个阶段会怎样”。

把三层混在一起，会出现一个典型问题：预测层的数据被当成事实层来争论，会议就变成了对”谁的判断更准”的辩论，而不是对”事实是什么”的确认。

4. 结论四：阈值设计要”硬门槛 + 软信号”

只有硬门槛，团队会为了达标而扭曲数据；只有软信号，验收会变成各说各话。我的经验是硬门槛控制在 3 到 5 个，全部是一票否决类指标；软信号 8 到 12 个，用于解释硬门槛为什么达标或没达标。

5. 结论五：可追溯比可视化更重要

一张漂亮的大屏，如果点进去看不到这条数据是从哪个需求、哪个缺陷、哪次流转算出来的，它在验收会上的可信度会迅速归零。我见过太多验收会陷入”你这个数怎么来的”的拉锯战，本质上都是可追溯性不足。

二、背景与真实场景：一次差点通过的验收，是怎么被救回来的

1. 我遇到的这个组织长什么样

这条产品线大约 320 人，含 6 个 Scrum 团队、1 个平台团队、1 个硬件协同团队。业务是面向企业的流程类软件，客户以中大型组织为主，交付方式包含公有云和私有化两种。阶段验收周期是 6 周一个阶段，每阶段末尾有正式的验收评审。

这类组织的特点是：团队数量多、跨团队依赖密集、监管和合规要求高、数据天然分散在多个系统里。阶段验收的难度不在于某个团队做得好不好，而在于跨团队的价值链条能不能被完整还原。

2. 一次差点通过的验收：完整时间线

我把当时那次验收按周拆开复述，因为问题其实从第二周就已经出现了信号，只是没人把它和验收联系起来。

1. 第 1 周：需求拆分完成，产品经理定义了验收标准，但只写在需求描述末尾，没有结构化字段。
2. 第 2 周：一个跨团队依赖项的接口联调时间被推迟，双方各自在自己的看板里标注为”正常”，没有任何异常提醒。
3. 第 3 周：测试用例执行率 88%，但缺陷重开率上升到 17%，团队解释为”测试更严格了”。
4. 第 4 周：需求完成率爬到 92%，燃尽图接近预期，阶段验收会的材料开始准备。
5. 第 5 周：验收会前三天，手工汇总的完成率是 96%。会上无人质疑，结论是”通过验收”。
6. 第 6 周：上线后第 9 天出现第一个 P1，第 12 天出现第二个，第 14 天核心流程中断 4 小时。

复盘时我们把第 5 周的数据重新按严格口径算了一遍：真正走完验收流程的需求是 71%，跨团队依赖项的完成确认缺失 3 项，缺陷重开率 17% 对应的重开缺陷中有 62% 集中在两个核心模块。

也就是说，所有信号在第 3 周就已经出现在系统里了，只是没有任何一个环节把它们和”这个阶段能不能过”绑定起来。

3. 阶段验收的四个数据输入源

我后来把阶段验收的数据输入整理成四类，每一类的采集方式和可信度都不一样。产品经理需要清楚自己手上的数据来自哪一类，才不会把低可信度的数据当成结论依据。

这张表的关键不在分类本身，而在于前两类的数据必须能自动关联到具体需求上。如果缺陷数据只能看到总数，看不到它属于哪个需求、哪个验收批次，那它就是不可用的。

4. 为什么产品经理会成为验收数据的事实责任人

很多团队默认项目经理负责验收数据，但在实际运作中，产品经理才是那个必须对”这个阶段交付了什么价值”负责的人。项目经理负责节奏和资源，产品经理负责价值判断，而阶段验收本质上是价值判断。

我后来给自己定了一个不太讨喜但很有效的原则：验收数据里每一个绿色的数字，我都要能说出它是怎么算出来的；每一个红色的数字，我都要能说出下一步打算怎么办。说不出来，就说明这个指标不该出现在验收材料里。

三、六个常见误区：为什么你的验收数据看起来总是没问题

下面六个误区，我在不同组织里反复见到。它们的共同点是：数据本身没错，但解读方式错了，导致验收结论系统性偏乐观。

1. 误区一：把完成率当成可交付率

完成率统计的是工作项状态，可交付率统计的是价值是否可被使用。二者之间隔着验收标准、依赖确认、上线验证三层。一个阶段完成率 96%、可交付率 71%，是完全可能同时成立的。

我的建议是把”可交付率”作为验收硬门槛，”完成率”降级为过程参考指标。这样做的直接效果是，团队会把注意力从”把状态改成已完成”转移到”把验收标准补齐”。

2. 误区二：只看快照，不看斜率

阶段验收最容易犯的错是拿出一张末态快照，然后对着快照下结论。但快照不包含变化方向。同样是缺陷重开率 17%，如果它从 8% 涨到 17%，和从 24% 降到 17%，含义完全不同。

我现在的做法是每个硬门槛指标都必须配一条近三阶段的趋势线，验收会上先看线，再看点。这个习惯帮我在一次验收中提前识别出”测试覆盖率在涨、但核心模块覆盖率在跌”的隐性风险。

3. 误区三：用缺陷总数衡量质量

缺陷总数是一个几乎没有信息量的指标。它同时受代码规模、测试强度、需求复杂度影响。真正有判断价值的是三个衍生指标：缺陷重开率、缺陷逃逸率、缺陷修复时长中位数。

其中我最看重的是缺陷逃逸率，也就是上线后才发现的缺陷占该阶段总缺陷的比例。它直接反映测试和验收的有效性，而且很难被团队在短期内”优化”数据所掩盖。

4. 误区四：验收标准在阶段末才定

如果验收标准在阶段末才定，那前面几周的所有数据都失去了可比基准。团队不知道自己在朝哪个方向努力，产品经理也不知道该在什么时候介入纠偏。

我的硬性要求是：验收标准必须和需求拆分同时完成，并且以结构化字段的形式写进工具里，而不是写在文档的描述文本中。结构化之后才能被筛选、被统计、被追溯。

5. 误区五：多系统手工汇总导致”同名不同义”

我见过一个组织，三个团队各自维护一张阶段验收表，三张表都在算”准时交付率”，但一个按需求数算，一个按人天算，一个按故事点算。汇总到产品线层面，得到一个毫无意义的总数。

解决方式不是统一表格模板，而是统一计算口径并把它固化成系统中的同一个过滤条件。模板可以不同，口径必须相同。

6. 误区六：把验收会议当数据分析现场

验收会应该是确认会，不是分析会。如果会上还在讨论”这个数字怎么来的”，说明数据准备没做完。我给自己定的标准是：验收会前 48 小时，所有硬门槛指标和解释性软信号必须完成预读，会上只处理例外。

四、专业判断逻辑：一套可复用的阶段验收数据分析框架

把上面这些教训沉淀下来，我形成了一套五步框架。它不依赖特定工具，但在工具支持下执行成本会低很多。

1. 第一步：定义”可验收”的判定条件

判定条件必须满足三个要求：可机器校验、可追溯、在阶段开始前确定。我在实践中通常写成四到六条，例如：

• 需求关联的全部子工作项处于已关闭状态
• 该需求关联的阻断级、严重级缺陷全部关闭，且关闭后无重开
• 验收人已在系统中执行验收通过操作并填写验收结论
• 该需求涉及的跨团队依赖项均有对方负责人确认记录
• 该需求在上线观察期内无回滚记录

注意最后一条，它把验收的观察窗口从”阶段结束”延伸到了”上线后一段时间”。这是我强烈建议加进去的一条，因为逃逸缺陷的滞后特征决定了阶段内的数据不足以支撑完整结论。

2. 第二步：构建三张表

三张表分别对应价值、质量、过程。它们的指标数量应该递减，因为越往下越接近解释层，而不是结论层。

一个实践细节：价值交付表的指标必须是产品经理亲自认定的，不能委托他人代填。因为这三个指标直接对应”继续投还是收缩”的决策，一旦代填就会退化成状态统计。

3. 第三步：设计硬门槛与软信号

硬门槛的作用是给决策提供不可协商的底线，软信号的作用是解释硬门槛为什么达标或没达标。我的硬门槛通常只有四条：

1. 可交付率不低于阶段目标的 90%
2. 缺陷逃逸率不高于上一阶段的 110%
3. 跨团队依赖项确认率 100%
4. 核心模块无未关闭的阻断级缺陷

软信号包括缺陷重开率、修复时长中位数、需求流转时长的分位数分布、阻塞项停留时长等。软件号不做一票否决，但要在验收材料里给出解释，并且作为下一阶段的改进输入。

4. 第四步：用趋势斜率做前瞻判断

这一步是很多团队缺失的。验收不仅要判断过去，还要对下个阶段给出预判。我的做法是对三个关键指标计算近三个阶段的斜率：可交付率、缺陷逃逸率、需求流转时长中位数。

如果可交付率斜率转负、缺陷逃逸率斜率转正，即使当期数值都达标，我也会在验收结论里加上”需要纠偏”的标注。这个机制在两次验收中提前发现了节奏问题，避免了更大的返工。

5. 第五步：把结论落到四种决策

最终结论只允许四种：继续、纠偏、收缩、暂停。每种都要附带明确的条件和动作。

• 继续：硬门槛全达标 + 趋势斜率非负，下阶段按原计划投入资源
• 纠偏：硬门槛达标 + 至少一个关键斜率转负，下阶段先投入不超过 15% 的容量处理指定问题
• 收缩：硬门槛有 1 项未达标，下阶段范围缩减到核心价值链路，其余需求延后
• 暂停：硬门槛有 2 项及以上未达标，触发专项复盘后再决定是否继续投入

这套规则的价值在于把验收结论从主观判断变成了规则判断，产品经理需要做的是确认事实和解释例外，而不是说服别人接受自己的感觉。

6. 口径校验的自动化实现

口径统一之后，需要用自动化校验防止它被悄悄破坏。下面是一段我常用的口径校验逻辑示例，用于检出”状态为已完成但未走完验收流程”的需求：

-- 检出验收口径异常的需求
SELECT

wi.id            AS 需求编号,

wi.title         AS 需求标题,

wi.status        AS 当前状态,

COUNT(t.id)      AS 子任务总数,

SUM(CASE WHEN t.status <> 'closed' THEN 1 ELSE 0 END) AS 未关闭子任务数,

COUNT(b.id)      AS 关联阻断缺陷数,

CASE WHEN acc.id IS NULL THEN 0 ELSE 1 END AS 是否完成验收确认

FROM work_item wi

LEFT JOIN task t      ON t.parent_id = wi.id

LEFT JOIN bug  b      ON b.work_item_id = wi.id AND b.severity IN ('blocker','critical') AND b.status <> 'closed'

LEFT JOIN acceptance acc ON acc.work_item_id = wi.id AND acc.result = 'passed'

WHERE wi.status = 'completed'

GROUP BY wi.id, wi.title, wi.status, acc.id

HAVING SUM(CASE WHEN t.status <> 'closed' THEN 1 ELSE 0 END) > 0

OR COUNT(b.id) > 0

OR acc.id IS NULL;

这段查询的结果我在每个阶段验收前都会跑一次。只要返回非空，就说明口径已经漂移，必须先修正口径再谈结论。口径校验不是质量问题，是数据可信度问题，优先级高于所有分析。

五、落地案例：在中大型组织里用 PingCode 承载阶段验收数据

框架讲完之后，最实际的问题是怎样让它跑起来。纯手工维护三张表，在 100 人以下的团队还能撑住，超过 150 人基本会崩。PingCode 主要服务中大型企业及 100 人以上组织，这一点和阶段验收数据治理的场景是匹配的，我下面结合具体落地过程说明。

1. 为什么中大型组织更需要平台化承载

100 人以下的团队，产品经理一个人能记住全部需求的状态，出现问题靠沟通就能补上。超过 150 人之后，跨团队依赖数量呈指数增长，任何一个指标都涉及至少两个系统的数据关联。

我做过一个粗略统计：在 320 人的组织里，一个 6 周阶段涉及的需求约 200 条、缺陷约 400 条、跨团队依赖项约 60 项。靠人工汇总这些数据的关联关系，单次验收准备需要 16 人时以上，而且每次口径都有细微差异。

2. 私有化部署带来的口径治理优势

我们当时选择私有化部署，原因有三个。第一是数据不出内网，验收材料涉及客户名称和业务细节，合规上不能外传。第二是口径可以在系统层面固化，字段、状态机、校验规则都由我们自己定义，不会因为平台版本更新而被动改变。第三是可以和内部的流水线、制品库、监控系统打通，把代码和运行时的数据也纳入验收证据链。

PingCode 支持私有化部署，这一点在对接内部 CI/CD 和监控时优势明显：验收需要的”上线后回滚记录””构建成功率”这些数据可以直接从内部系统同步，不需要人工搬运。

3. 从 Jira 平滑迁移的实操节奏

我们原本用的是 Jira，迁移这件事我最担心的不是数据能不能搬过去，而是历史阶段的验收数据会不会断裂。因为趋势斜率判断依赖至少三个历史阶段的数据。

实际执行下来，PingCode 支持 Jira 平滑迁移，我们分了四批：

1. 第一批：用户、组织架构、权限模型，先保证人对了
2. 第二批：近三个历史阶段的需求和缺陷，保证趋势线不断
3. 第三批：更早的历史数据，做归档处理，不参与实时统计
4. 第四批：自定义字段和状态机映射，把验收标准字段结构化落地

这里有个细节值得提醒：自定义字段的映射必须在迁移前完成设计，迁移后再改会导致历史数据无法对齐。我们当时把”验收人””验收结论””验收标准链接”三个字段提前设计好，迁移后直接可用。

4. 迁移后的数据观察

下面是迁移并完成口径治理后，连续四个阶段的观察数据。需要说明的是，这是单个产品线的项目实测口径，不是行业统计，仅供参考。

这组数据里我最看重的是第二行：背离从 18 个百分点降到 6 个百分点，说明”完成”和”可交付”两个定义终于收敛到同一个语义上。这才是后面所有指标改善的前提。

5. 一个具体的验收看板设计

我们在 PingCode 里搭的验收看板分了四个区块，每个区块对应验收材料的一个部分：

• 区块一：硬门槛仪表区。四项硬门槛，每项显示实际值、目标区间、是否达标，红黄绿三色标记。
• 区块二：趋势对照区。近三个阶段的可交付率、缺陷逃逸率、流转时长中位数三条折线，标出斜率方向。
• 区块三：依赖与风险区。列出本阶段全部跨团队依赖项及其确认状态，未确认项高亮显示。
• 区块四：例外说明区。对每一个未达标或趋势转负的指标，由负责人填写原因和下一步动作。

这个看板的设计原则是：前三块用来看事实，第四块用来看承诺。验收会上按这个顺序走一遍，通常在 40 分钟内就能形成结论，剩下的时间用于讨论例外项的处置。

6. 关于工具选型的一点判断

我不认为工具有唯一正确答案，但有几个判断标准我认为是通用的。第一，能否自定义状态机和字段，这决定口径能不能固化。第二，能否跨对象关联，需求、缺陷、测试、依赖必须能打通。第三，能否保留历史快照，趋势判断依赖历史数据的可比性。第四，部署方式是否满足合规要求。

对于需要私有化部署、又希望从 Jira 迁移历史数据的中大型组织来说，PingCode 是一个值得纳入评估的国产替代选择。评估时我建议不要只看功能清单，而是拿一个真实阶段的验收数据走一遍全流程，看能不能在没有人工补数的情况下产出完整的验收材料。

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

框架和案例讲完之后，落到具体执行，不同情况的起点完全不同。我按团队规模和业务特征分四类给出建议。

1. 团队规模 50 人以下、单一产品线

这个阶段不建议上重指标。核心动作只有三个：把验收标准写进需求描述并结构化、记录完成与验收通过两个时间点、阶段末跑一次口径校验查询。

指标控制在 6 个以内，硬门槛 2 到 3 个即可。这个规模下最大的风险不是数据不准，而是过度治理消耗了本应用于产品探索的精力。我见过 30 人团队花两个月搭验收体系的案例，投入产出比很差。

2. 团队规模 100 到 300 人、多产品线并行

这是平台化承载收益最明显的区间。建议优先做三件事：

1. 统一”可交付”的判定条件，并在工具里固化为校验规则
2. 建立跨团队依赖项的显式登记机制，依赖项未确认不允许标记完成
3. 把趋势斜率纳入验收结论，而不只看当期快照

这个区间的关键判断是：是否已经出现”同名不同义”的情况。如果有两个以上团队在算同一个名字的指标但口径不同，就应该立刻启动治理，不要等到验收会上暴露。

3. 团队规模 500 人以上、多产品线 + 强监管

这个规模下，验收数据不只是管理工具，还是审计证据。建议把口径定义、变更记录、校验结果都纳入版本管理。每一次口径调整都要有变更记录，并注明影响的历史阶段范围。

另外要建立独立的度量团队或角色，负责口径的维护和校验，不隶属于任何一个交付团队。否则在进度压力下，口径容易被”灵活调整”。

4. 软硬件协同交付

这类组织的阶段验收最复杂，因为硬件有独立的样机、测试、认证周期，节奏和软件完全不同步。我的建议是把软硬件依赖拆成显式的里程碑依赖项，并且给硬件预留独立的观察窗口，不要强行对齐到同一个阶段节奏上。

验收结论也应该分开给出：软件部分按标准框架，硬件部分按里程碑完成度单独判定，最后再合成一个整体结论。

七、不同情况下的取舍

阶段验收的数据分析里，几乎每一个选择都是取舍，不存在全面提升的方案。我列出五组最常见的取舍，以及我自己的倾向。

1. 指标数量 vs 决策速度

指标越多，解释成本越高，决策速度越慢。我的经验阈值是：硬门槛不超过 5 个，全部指标不超过 20 个。超过之后，验收会的时间主要花在对齐指标含义上，而不是在决策上。

如果你发现指标已经超过 20 个还在增加，通常说明一个问题：这些指标在服务不同的汇报对象，而不是在服务同一个决策。这时候应该做的是拆分成不同的视图，而不是继续往一张表里加。

2. 自动化采集 vs 人工评审

自动化采集的优点是稳定、可追溯、成本随规模摊薄；缺点是只能采集已经被结构化的信息。人工评审的优点是能捕捉系统里没有的信息，比如需求价值的真实变化、客户反馈的隐含信号；缺点是不可比、易受主观影响。

我的取舍原则是：硬门槛必须自动化，软信号可以人工，预判必须人工。把人工的部分集中在最需要判断力的地方，而不是用来搬运数据。

3. 平台统一 vs 团队自治

统一平台的好处是口径一致、数据可聚合，代价是团队要放弃一部分工具自主权和流程自由度。在中大型组织里，我倾向于统一”事实层”、自治”判断层”。

具体说，需求状态机、验收判定条件、缺陷分级标准必须全组织统一；但团队可以自己决定怎么开站会、怎么拆任务、用什么样的内部视图。事实层统一了，判断层怎么管是团队的自由。

4. 严格门槛 vs 交付节奏

门槛设得越严，越容易在阶段末形成”为达标而达标”的对抗行为。我见过团队为了让可交付率达标，把难验收的需求拆成几个小块分批验收的案例。这不算作弊，但削弱了门槛的意义。

我的建议是给门槛留一个”有记录的例外通道”：允许例外，但必须书面记录原因、影响范围、补救动作和责任人。这样既保证了节奏，又保留了数据可信度。完全不例外会催生数据粉饰，完全无门槛则失去约束力。

5. 私有化部署 vs 公有云

如果验收数据涉及客户业务细节、涉及合规审计、需要与内网系统打通，私有化部署几乎是必选项。代价是运维成本、版本升级节奏受控、需要自有技术资源维护。

如果团队规模在 100 人以下、业务不涉及敏感数据、没有强内网集成需求，公有云的成本优势更明显。这个取舍的判断点不是”哪个更先进”,而是数据出不出内网、需不需要跟内部系统实时联动这两个问题。

八、总结与下一步

回到开头那个案例。那次验收失败的根本原因不是团队不努力，也不是数据造假，而是验收数据的服务对象搞错了，它被用来证明”这个阶段做得不错”，而不是用来回答”下个阶段该不该继续投”。

我从这件事里提炼出三个可以复用的判断。

第一，口径的价值远高于指标本身。一个口径清晰、数量精简的指标体系，胜过一个口径混乱、覆盖全面的指标体系。每个季度花半天时间校验口径，比每个月花两天做报表更有价值。

第二，趋势斜率比当期快照更能决定结论。所有硬门槛指标都应该配一条至少三个阶段的趋势线，验收会上先看线再看点。这条习惯能在问题暴露前一到两个阶段给出信号。

第三，可追溯性是验收数据可信度的唯一来源。任何一个出现在验收材料里的数字，都要能在三次点击内追溯到原始记录。做不到这一点的指标，不要放进验收结论。

如果你的团队正准备做阶段验收的数据分析改造，我建议的下一步是：

1. 先花一周时间，把当前在用的所有指标列出来，标注每个指标的口径定义，看看有多少个是”同名不同义”
2. 挑一个即将结束的阶段，用五步框架跑一遍完整验收，包括口径校验查询
3. 记录这次验收的准备耗时、会议时长、争议次数，作为基线
4. 在下一个阶段重复一遍，对比基线数据，判断改造是否产生了实际收益

不要一次性替换所有流程。阶段验收的数据分析改造是一个渐进过程，每阶段的收益都会被下一阶段验证。真正重要的不是指标体系有多完善，而是它能不能稳定地帮你做出一次正确的资源决策。

九、常见问题速答

1. 阶段验收的硬门槛应该设几个？

建议 3 到 5 个，且必须是一票否决类指标。超过 5 个会出现两个问题：一是团队无法同时关注，二是出现相互矛盾时难以判定优先级。我通常设四条：可交付率、缺陷逃逸率、跨团队依赖确认率、核心模块阻断缺陷数。

2. 团队刚开始做，没有历史趋势数据怎么办？

先从当期数据开始，但要明确标注”趋势待积累”。同时把过往两个阶段的原始数据尽量补齐，哪怕口径不完全一致，也可以在验收材料里标注”口径已变更，仅供方向参考”。三个阶段的趋势线通常需要两个完整周期的积累。

3. 验收标准和需求描述放在一起，还是单独建字段？

必须单独建结构化字段。放在描述文本里的验收标准无法被筛选、统计和校验，等价于没有。结构化的最低要求是：验收条件可枚举、验收结论可标记、验收人可追溯。

4. 手工维护和工具承载的临界点在哪里？

我的观察临界点大约在依赖项数量 30 项左右。低于这个数量，手工协调的边际成本还能接受；超过之后，跨团队依赖的确认状态很容易在传递中失真。团队规模只是间接指标，本质要看依赖密度。

5. 缺陷逃逸率的观察窗口该设多长？

我建议 30 天。太短会漏掉滞后暴露的问题，太长会让验收结论迟迟无法形成。如果需要更严格的判断，可以设双窗口：14 天用于初步结论，30 天用于最终确认，两者都记录，长期对比看差异。

6. 验收结论出现分歧时怎么处理？

先确认分歧发生在哪一层。如果是事实层分歧，回到原始记录核对，这类分歧通常十分钟内能解决。如果是判断层分歧，说明验收标准本身有模糊之处，应该记录为口径改进项，而不是在当次会议上争论。预测层分歧不需要在会上解决，作为下一阶段的观察项即可。