11 · 分析框架 v2(吹毛求疵 · 业务技术两手 · 反占位)

2026-05-19。本框架取代 00 作为后续(重构智能会议→论证 05 模型→A-CDM 底座)的方法论真源。 v1 有偏差控制 §E,却仍被"占位当成熟"咬穿三次,只由人反馈拦下——说明 v1 把它当"软提醒"而非"硬闸"。v2 的核心改动:把实现真实性升为一等强制闸,引入四角色对抗评审,改以原子业务需求为分析单元,业务与技术强制双轨。

---

A. 为什么要 v2(v1 的失效复盘)

v1 失效	根因	v2 对策
"spec 写了/容器在跑"=成熟,被咬 3 次	§E 偏差控制是"建议",无强制门;证据标准未分级	§C 实现真实性闸(强制,过不了不准下结论) + §B 证据分级(spec/wiki 不算兑现证据)
结论层乐观、技术视角单一	无业务视角、无对抗评审、无角色分工	§D 四角色对抗评审(每角色 kill-question,任一否决即打回)
分析单元是"层/GAP",粒度粗、易笼统	没有"原子业务需求"这一可验收最小单元	§E 原子业务需求为分析单元(期望+价值+验收+反例)
"做成底座"无判据,易做成会议专用	缺底座性 gate	§F 底座级判据(领域无关+可被非会议业务复用才算)
文档漂亮 ≠ 真做到	无"成果须运行/代码证据"纪律	§G PMO 纪律(无 T0/T1 证据不得称"达成")

---

B. 证据分级(任何主张必须标级;级别决定能下什么结论)

级	含义	能支撑的结论
T0	运行实测(真实数据跑过,有输出/耗时/错误样本)	"可用/好用/慢"等质量与性能结论
T1	实际执行路径源码 file:line(真正会跑到的那条)	"已实现/占位/退化/缺失"等兑现结论
T2	接口/类型/schema(签名存在,未证实跑到)	"接口存在",不得推成"已实现"
T3	spec / wiki / 注释 / OpenSpec	仅作意图与期望,永不作兑现证据

铁律:"成熟/可用/已交付"必须 ≥T1;"好用/够快"必须 T0。 只有 T3 → 只能说"意图如此,兑现未验"。

---

C. 实现真实性闸(强制 · 任何能力结论的前置;过不了不准进 D/E)

对每个被评估能力,按序回答,任一为"否/未知"则该能力判为占位/未验,不得计入"已具备":

1. 执行路径定位:真实会跑到的代码在哪(file:line)?(不是接口、不是 spec 引用的目录)
2. 占位探针:该路径有无 placeholder / in-memory / Zero* / ={} / pass / stub / TBD / TODO / phase-B / "follow-up 再做"?有→默认占位,需 T0 反证。
3. 退化检查:默认部署下,公式/分支是否被空配置/默认实现退化(如 entity_overlap≡0、embedding_sim≡0)?退化后实际等价于什么?
4. spec 对账:spec/wiki 的承诺与执行路径是否一致?不一致 → 立即给 spec 打叉(非破坏式 ⚠️ 勘误块 + 证据 file:line + 指出哪条 Scenario 在默认部署下虚构 + 修复指向;正式化走 OpenSpec change)。
5. 判级:真实 / 部分兑现 / 占位 / 夸大 / 缺失,记入 10 §3 台账。

这是 v2 最重要的升级:它不是"提醒注意",是"门"。研究里任何"X 已 live/已具备"若无本闸记录,视为无效结论。

---

D. 四角色对抗评审(每个设计/结论必须四审;角色互为反方)

角色	视角	Kill-question(命中即打回重做)
吹毛求疵架构师	耦合/契约/可演进/可回滚	契约边界在哪?失败如何回滚到上一可信态?换实现要改几处?是否又造一份真相(双源漂移)?
AI 系统构建专家	LLM 失败模式/幻觉/延迟/成本/上下文/可评测	幻觉如何被程序拦(非靠 prompt 自律)?长输入分块/多 pass?延迟与 token 成本上界?有无离线评测集与回归?
PMO	范围/里程碑/依赖/止损/验收/不夸大	最小可证明价值是什么?依赖是否先验真?里程碑验收门可证伪吗?哪步是止损?有没有把"计划"说成"成果"?
业务顾问	真实工作流/价值/采用/反孤岛/谁买单	用户在哪个触点用、不用会怎样?产物进不进他既有执行系统(否则=孤岛=花架子)?谁为此买单、ROI?

规则:四角色全过才算结论成立;任一角色否决,该项回 §C/§E 重做并留痕。

---

E. 原子业务需求(分析的最小单元,替代 v1 的"层/GAP")

"基于源码和原子业务需求"是用户明确要求。原子业务需求 = 不可再拆、独立有用户价值、可独立验收 的业务期望。

每个原子业务需求卡片(ABR)字段:

• 期望:来自 A-CDM 业务需求/05 模型/竞品基线——只取意图,不信其占位实现(T3 来源标注)
• 用户价值:谁、在什么触点、解决什么真实痛点;不做会怎样
• 验收(可证伪):可用档 / 好用档,各一句可测断言(对齐 01 双 bar)
• 反例:什么样算"看着像做了其实没用"(防花架子)
• 源码现状:走 §C 闸后的判级 + file:line
• 实现方法:在 deer-flow 原生 × 05 模型上的落地路径(给 ≥2 方案 + 7 维取舍 + 推荐 + devil's advocate,沿 05 范式)
• 底座性:该实现是否领域无关、可被非会议业务复用(§F)

ABR 是 12 的产出形态,也是后续 OpenSpec change 的素材单元。

---

F. 底座级判据(决定"会议专用"还是"A-CDM 真底座")

一个能力/原语只有同时满足才算 substrate-grade(否则只是会议功能,北极星不成立):

1. 领域无关:不含"会议/纪要"特化假设;会议只是它的一种"任务卡类型"。
2. 契约稳定:输入/输出/失败语义是显式契约(可写成 OpenSpec change),换实现不破契约。
3. 可复用验证:能用一个非会议业务最小改动复用(哪怕纸面演练),作为北极星判据 4 的证据。
4. 可逆可审:每步产物可被人在卡片层审阅/回滚/续跑(05 任务流契约),失败回退人工而非静默兜底。

不满足 1–4 的实现可以先做(交付会议价值),但不得宣称为底座;宣称底座必须四条 T0/T1 证据齐。

---

G. PMO 纪律与诚实留痕

• 无 T0/T1 证据不得出现"已达成/已具备/成熟/事半功倍";只能说"意图/计划/待证"。
• 文档=诚实基线与宪章,不是成果;成果=可演示的运行证据。每篇显式标证据级与 supersession。
• 每阶段必有止损位与可证伪验收门;依赖未验真不得在其上叠结论(先验底座依赖,再谈架构)。
• 框架自身也受 §C 约束:本研究任何"底座可行"的话,落地前必须有依赖项 T1 实证(正在并行核验原生记忆/HITL/Pipeline 持久化三依赖)。

---

H. v2 分析流水线(取代 00 §D)

S′0 框架v2(本文)
  └─ S′1 依赖真实性核验(原生记忆/HITL/Pipeline 持久化…走§C闸,T1)   ← 命门,先做
       └─ S′2 原子业务需求解构(§E,全链路 ABR 卡)
            └─ S′3 每 ABR 源码级实现方法(deer-flow 原生×05,§E+§D 四审)
                 └─ S′4 底座抽象(§F,四判据)+ 写成 OpenSpec change(契约真源)
                      └─ S′5 标杆最小闭环 M1(T0 跑通,论证模型)→ 推广

每步产出落 docs/reports/2026-05-18-智能会议专题深度实现研究/,README 进度表追踪;每步过 §C 闸 + §D 四审 + §G 留痕。

一句话:v2 = 把"别再把占位当成熟"从口号变成强制门,用四角色互相拆台,以原子业务需求为单元,业务技术双轨,且只认运行/源码证据。 后续 12 起严格按此执行。