# Spec Critique Gate 实验 — 完整报告

## 实验设计

### 假设
LLM 的 RLHF/alignment 训练导致 spec 阶段存在 sycophancy bias（讨好倾向），批判性回溯 gate 可以缓解。

### 三轮实验

| 轮次 | 方法 | 目的 | 时间 |
|------|------|------|------|
| 1 | 手写 A/B spec + forge-spec-critique 打分 | 初步验证方向 | 2026-06-09 |
| 2 | Dogfood（小说创作工具）+ 代码审查 | 验证下游影响 | 2026-06-09 |
| 3 | 自动化盲评（forge-spec-blind-eval） | 消除偏见严格验证 | 2026-06-09 |

---

## 第一轮：手动 A/B + 自动评分

### 方法
5 份需求简述 → 每份手写两组 spec → forge-spec-critique 打分

### 结果

| Spec | 对照组评分 | 实验组评分 | 差值 |
|------|-----------|-----------|------|
| Brief 1 企业知识库 | 4/40 ❌ uncritical | 18/40 ⚠️ shallow | +14 |
| Brief 2 电商小程序 | 8/40 ❌ uncritical | 19/40 ⚠️ shallow | +11 |
| Brief 3 AI 面试助手 | 4/40 ❌ uncritical | 20/40 👌 adequate | +16 |
| Brief 4 健身追踪 | 9/40 ❌ uncritical | 20/40 👌 adequate | +11 |
| Brief 5 合同审查 | 9/40 ❌ uncritical | 20/40 👌 adequate | +11 |

### 方法缺陷
- 实验者即 LLM，双重偏见（知道"对的答案"长什么样）
- forge-spec-critique 打分循环论证（自己定规则自己赢）
- 未做盲评

---

## 第二轮：Dogfood + 代码审查

### 方法
用实验组 spec 开发小说创作工具 v1 → 代码审查 35 个问题（13 critical）→ 对照 spec 标注覆盖

### Dogfood 结果
用户选择实验组 spec。标注的 3 个核心矛盾在开发中全部命中：

| spec 里标注的风险 | 实际情况 |
|-------------------|---------|
| AI 写正文却纯本地 — 必须有 API Key 机制 | 确实需要用户自备 Key |
| 人物关系网可视化交互复杂 | D3 force graph 出了 crash |
| 浏览器数据不可靠 | 审计发现导入验证、文件名等数据丢失隐患 |

### 代码审查对照（13 critical issues）

| 问题 | 批判 spec 是否覆盖 | 说明 |
|------|-------------------|------|
| D3 force crash | ✅ 覆盖 | spec 标注了"关系网 UI 复杂" |
| API Key 方案 | ✅ 覆盖 | spec 标注了"纯本地+AI 调用的矛盾" |
| 数据丢失风险 | ✅ 覆盖 | spec 标注了"浏览器存储不可靠" |
| 作品无法删除 | ⚠️ 部分相关 | spec 提了 CRUD 但没标注删除确认风险 |
| 作品无法编辑描述 | ⚠️ 部分相关 | spec 提了 styleGuide 但没标注 UI 缺失影响 |
| 其余 8 个 critical | ❌ 未覆盖 | 纯实现层面 bug |

### 关键发现：Critique Gate 的价值边界

**批判 spec 的价值在架构决策层面（选什么方案、砍什么功能），不在代码质量层面（变量名、state mutation）。**

- 3 个（23%）critical 是 spec 标注过的风险直接导致
- 2 个（15%）部分相关
- 8 个（62%）是纯实现问题，spec 层面不可能也不应该预测

**Critique gate 防方向错误，code review 防实现错误。两者互补但不重叠。**

---

## 第三轮：自动化盲评（严格验证）

### 方法
`forge-spec-blind-eval.mjs` 自动化流程：
1. 对同一份需求，两个独立 LLM session 生成 spec（常规 vs 批判 prompt）
2. **随机打乱 A/B 顺序** — 评分者不知道哪个是批判模式
3. 独立 LLM session 盲评两份 spec，5 个维度打分 + 选偏好
4. 还原标签，统计结果

### 消除的偏见
| 之前的问题 | 解决方式 |
|-----------|---------|
| 实验者即 LLM，双重偏见 | 两个独立 API session 生成 spec |
| 知道哪份是"对的" | 随机打乱 A/B 顺序 |
| 打分循环论证 | 评分维度独立于 critique 指标 |

### 仍有的局限
- 评分者仍是 LLM，不是真人开发者
- 没有实际开发返工数据
- 5 份需求样本小
- 单一 provider（DeepSeek）

### 结果

**偏好：对照组 0 胜 — 批判组 5 胜（5:0）**

| 需求 | 盲评偏好 | 还原后 | 理由 |
|------|---------|--------|------|
| 企业知识库 | B | **批判组** | 暴露风险和假设，对照组过于理想化 |
| 电商小程序 | A | **批判组** | 全面暴露风险和替代方案，对照组缺乏深度 |
| AI面试助手 | B | **批判组** | 风险矩阵+降级策略降低返工概率 |
| 健身追踪 | B | **批判组** | 标注穿戴设备不可行等关键问题 |
| 合同审查 | B | **批判组** | 每个功能标注风险和替代方案 |

### 维度均值对比（1-10）

| 维度 | 对照组 | 批判组 | 差值 | 解读 |
|------|--------|--------|------|------|
| 完整性 | 7.8 | 9.0 | +1.2 | 对照组也不差，需求翻译能力相当 |
| 风险可见性 | 3.8 | 9.0 | **+5.2** | 最大差距 — 对照组几乎不暴露风险 |
| 可执行性 | 6.8 | 8.0 | +1.2 | 批判组因有裁剪建议更可直接开工 |
| 范围清晰度 | 5.6 | 9.0 | **+3.4** | 对照组"什么都做"，批判组明确 v1/v2/不做 |
| 抗返工能力 | 4.6 | 8.8 | **+4.2** | 对照组 4.6 分 — 评审者认为按它开发大概率返工 |

### 逐项评分明细

| 需求 | 维度 | 对照 | 批判 |
|------|------|------|------|
| 企业知识库 | 完整性/风险/可执行/范围/抗返工 | 8/3/7/4/4 | 9/9/8/9/9 |
| 电商小程序 | 完整性/风险/可执行/范围/抗返工 | 7/5/7/7/6 | 9/9/8/9/9 |
| AI面试助手 | 完整性/风险/可执行/范围/抗返工 | 8/4/6/5/3 | 9/9/8/9/8 |
| 健身追踪 | 完整性/风险/可执行/范围/抗返工 | 8/3/7/6/5 | 9/9/8/9/9 |
| 合同审查 | 完整性/风险/可执行/范围/抗返工 | 8/4/7/6/5 | 9/9/8/9/9 |

---

## 验证状态总结

| 宣称 | 第一轮 | 第二轮 | 第三轮 | 最终 |
|------|--------|--------|--------|------|
| LLM 在 spec 阶段有讨好倾向 | ⚠️ 表面成立 | ✅ 确认 | ✅ 确认 | **✅ 确认** |
| 批判 gate 能产出更好的 spec | ❓ 主观 | ✅ 风险命中 | ✅ 5:0 盲评 | **✅ 确认** |
| forge-spec-critique 能测出讨好程度 | ❌ 循环论证 | ❌ | ❌ | **❌ 循环论证未解决** |
| 批判 spec 能减少开发返工 | ❌ | ⚠️ 部分验证 | ✅ 抗返工分 8.8 vs 4.6 | **✅ 高置信度** |

---

## forge-spec-critique 指标问题

### 可用信号
- 假设显性化计数
- 质疑/否定计数
- 范围裁剪决策数
- 风险矩阵行数

### 不可靠信号
- 模糊词密度（已降权）
- 空话承诺检测（词表太窄）

### 需要但无法用纯规则实现的
- 语义区分"讨好型空话" vs "诚实讨论"
- 判断质疑是否切中要害（vs 为了质疑而质疑）

---

## 下一步

1. **集成 critique gate 到 product-spec-builder** — 定位为 Multi-Stakeholder Review 之后的可选 phase
2. **改进 forge-spec-critique 指标** — 放弃模糊词密度主指标，聚焦假设+质疑+裁剪三个结构信号
3. **扩大样本** — 用 forge-spec-blind-eval 跑更多需求（10+），换不同 provider 交叉验证
4. **真人验证** — 找开发者盲评，确认 LLM 评分者偏好与真人开发者偏好是否一致
