workflow_requirement_analysis_quality

道-方法 · 道层 skill 全文

本页是 <code>rules/skills/drafts/workflow_requirement_analysis_quality.md</code> 的逐字投影（仅隐私清洗，零改写）。

name: workflow_requirement_analysis_quality
status: draft (Beta) — 2026-06-04 起草（RA-01）；晋级前需 requirement_analysis_gate 在真实需求分析产物上跑通 ≥1 次（含一个真实漏覆盖的反例）
description: 判一份需求分析做得妥善准确没有，核心是消息覆盖，所有用户消息/session 的 raw turn 都被覆盖了没、有没有把多个不同 turn 塌缩成一条、有没有 recency/重要性偏置泄漏进需求集。触发场景：拆完需求要自检覆盖全不全、复盘一份既有需求分析、判某次任务分析覆盖面够不够广、或要给"消息覆盖"装一个可机械验证的门。配套确定层检测器 `requirement_analysis_gate`。区别于 `workflow_requirement_decomposition_core`（做拆解的过程）和 `workflow_requirement_intake`（收单条新需求）。

需求分析质量：消息覆盖 + 妥善准确，可机械自判

目标（一句话）

给定一份需求分析（从用户消息里拆出的需求集 + 它们的来源），判它是否妥善准确且达成消息覆盖：用户在所有相关 session 的 raw turn 里提出的需求，一条不漏地进了需求集，没有把多个不同诉求塌缩成一条，也没有把"谁更重要 / 谁最近聊"偷偷编码进需求集。

为什么需要它（根因，别跳过）

workflow_requirement_decomposition_core 的 Gate 2 早就写了「建 source universe、量化 coverage、留 no-hit receipt」，可它是散文。2026-06-04 诊断（adhoc_jobs/landing_requirement_decomposition_20260531/meta_analysis_20260604/DIAGNOSIS_order_intake_insight.md）查实的根本病：需求分析的原则一直停在散文层，从没转成机械可验证的约束，所以注意力一变就漂回旧模式，同类纠偏跨 session 被重提 7 次以上（等权、消息覆盖、按消费边定序）。

这条 pipeline 自己就栽过最干净的一跤：一次需求分析把 60 条需求的来源塌缩成 3 个 prompt-session，10 个工作 session 的 raw user turn 根本没读（蒸馏产物只记 agent 做了什么、不记用户中途临时提的新要求）。靠后续一次机械枚举全集 + 盲抽对账才补回真漏的 session。「分析过了」（确定层有完成感）和「覆盖全了」（语义层无完成信号）可以同时成立，这正是诊断说的 satisfice 滑向有信号的一侧。这个 skill 把消息覆盖从散文原则变成可自判的验收 + 一个独立误差信号（requirement_analysis_gate）。

验收标准（无上下文 agent 可自判完没完）

两条轴，消息覆盖是核心、质量是配套。每条都写到能自判。

消息覆盖（MC，核心）

• MC1 来源全集机械枚举：存在一份机械枚举的来源全集（时间窗口内每一个候选消息源 / session + 处置：纳入或排除+理由），来源是「我列了全部再分类」，不是「我用了上一轮给我的 N 个清单」。判据：能指着一份枚举产物，且它不是对某个现成清单的复制。拿可疑清单当全集，等于复制同一个洞。
• MC2 逐条 provenance 锚 + 逐字非蒸馏：需求集里每条需求都有来源锚（session id + raw turn 位置），且锚指向用户原话逐字，不是蒸馏/转述产物。判据：随机抽 3 条需求，每条都能回到一段 raw user turn 原文。
• MC3 盲抽对账，零漏项零塌缩：从来源全集里盲抽若干 raw user turn（抽时不看已有需求清单，避免 force-fit），独立抽需求再与需求集对账；不存在「raw turn 里明确提出、需求集里没有」的漏项，也不存在「多个不同 turn 被塌缩成一条需求」的塌缩。判据：盲抽对账记录在、零漏零塌缩，或漏项已补回。
• MC4 负向证据：判为「排除 / 无关」的来源有 no-hit / residual receipt 说明为什么不产生需求，而不是默默跳过。判据：排除集每条有一句处置理由。

分析质量（Q，配套）

• Q1 等权、无偏置泄漏：需求集本身不编码优先级 / 紧急度；recency（用户最后聊的话题）没有泄漏成「更重要 / 先做」。定序是单独一步、只按消费边，不混进分析（接 [[feedback_equal_weight_requirements]]）。
• Q2 证据分级：区分 用户原话 / 推断需求 / 缺失来源 / 无证据假设；没有 source anchor 的需求只能标 provisional。
• Q3 联动非孤岛：需求之间的服务 / 依赖关系被识别（谁的产出喂谁），不是一堆互不相关的孤岛。
• Q4 关键判断交叉验证：lever 级判断（哪些是高扇出枢纽、定序、某两条该不该合并）经多 agent 独立互审或多模型收敛，不是单 agent 自报（接 [[project_subagent_conformity_finding]]）。

全齐了还要过 requirement_analysis_gate（确定性壳验 MC1-MC3 结构 + regulator 盲抽对账验 MC3/MC2 真伪），别拿自评当数，执行者不能当自己的 oracle（接 [[project_order_intake_insight_diagnosis]]）。

怎么做（术，结果导向）

1. 先枚举再分析：动手抽需求前，先机械枚举来源全集（列窗口内每个 session/消息源，分类纳入/排除）。不信任何上一轮给的清单，那张清单可能就是漏了某簇的那次枚举的产物。
2. 逐字进集、逐条挂锚：每条需求挂 session id + raw turn 锚，原文逐字。读 raw user turn，不读蒸馏产物 / survey 报告（那些只记完成态）。
3. 盲抽对账证没漏：抽样 raw turn 时不给自己看已有需求清单（否则会 force-fit 成「都覆盖了」）。独立抽完再对账，漏的补回。
4. 质量四问：过一遍 Q1-Q4（有没有 recency 泄漏 / 证据分没分级 / 联动连没连 / 关键判断验没验）。
5. 收口跑 requirement_analysis_gate：确定性壳验 MC 结构、regulator 盲抽对账给可定位反例（哪条 raw turn 的哪个诉求没进需求集）。FLAG 就按反例补，别声称分析完成。

边界（不做什么）

• 不做拆解本身。「怎么把模糊需求冻结成 what + 验收边界」是 [[workflow_requirement_decomposition_core]] 的七门；本 skill 判它做出来的结果够不够好。
• 不做定序。谁先谁后是消费边的事（[[workflow_requirement_intake]] 的 phase 决策纪律 + EXECUTION_ORDER §5）；本 skill 只确保定序的输入（需求集）覆盖全、不带偏置。
• 不裁决业务 closure。覆盖证明只说「需求捕捉齐了」，不说「需求实现完了」。
• 不替代信息定位召回。「怎么把该读的 session 都捞到」是 [[workflow_recall_first_locate]]；本 skill 假设来源已可枚举，判覆盖。
• regulator 盲抽是抽样不是穷举：它给的是「至少这几条漏了」的可定位反例，不是「保证零漏」的证明。零漏要靠 MC1 全集枚举 + MC3 对账记录这些确定层产物撑（V6 诚实边界）。

已知陷阱（真实发生过）

• 塌缩进蒸馏：把 13 个真交互来源塌缩成 3 个 prompt-session（10 个工作 session 的 raw turn 没读，66 个 sub-agent transcript 里只 1 个工作 session 被真正打开、且是去找审查锚不是抽需求），直接漏掉 W 组（报告矩阵 / 沟通纪律，8 条）和 N 组（原生范式，3 条）两整簇，这条 pipeline 自己犯过（接 [[feedback_distilled_vs_raw_requirement_coverage]]）。蒸馏只记 agent 做了什么，丢用户中途新要求。查需求必须读 raw user turns，且「在 ls/find 枚举里出现过」不等于「raw turn 被真正读过」。
• 拿可疑清单当全集：用上一轮给定的 session 清单做抽取，而那张清单本身就是漏了两簇的那次枚举的产物，复制同一个洞。必须机械枚举全集（COVERAGE_VERIFICATION_20260602.md 的修法）。
• 盲抽时 sub-agent 过度召回：盲读 agent 报「某簇可能漏了」，grep 复核为虚惊（4 报 1 真的过度召回偏置，接 [[feedback_llm_classifier_nondeterminism.md|feedback_llm_classifier_nondeterminism]]）。盲抽对账的「疑似漏项」必须 grep 真源复核，别直接当真漏。
• recency 偏置顺着 handoff 传染：一个 session 把最后聊的大话题（Git）排第一，错排写进 handoff 传到下个 session，要靠下个 agent 主动识别拒绝继承。分析阶段就不该让 recency 进需求集。

配套与跨域联系

• 确定层检测器 requirement_analysis_gate（tools/requirement_analysis_gate/）。形态遵循 [[workflow_complexity_drift_detection]] 的 V1–V6（确定性壳承载结构判别 MC1-MC3 + 第二 agent regulator 承载可操作误差信号 MC3 盲抽对账）。
• 上游：[[workflow_recall_first_locate]]（把该读的源都捞到）→ [[workflow_requirement_decomposition_core]]（做拆解）→ 本 skill（判拆解质量 + 覆盖）→ [[workflow_requirement_intake]]（单条新需求入库入序）。
• 落地收口走 [[workflow_landing_to_production]] 的四条件 + landing_gate；本 skill 的创建按它的 DL-02 分步协议走。
• 根因（确定层有信号 / 语义层无信号 → satisfice 滑向表面；误差信号必须可操作 + 独立）接 [[project_order_intake_insight_diagnosis]] [[project_open_loop_control_theory]] [[project_verifiable_checkpoint_experiment]] [[project_anti_performative_diligence_methodology]]。
• 充分性的另一条轴（context 对需求 Y 是否最小充分，I(T;Y)）是 [[project_recall_first_locate|requirement-anchored sufficiency]] / T703；本 skill 是 message→需求集 的覆盖，那条是 context→需求 的充分，正交互补。