# Research Deliberation / 研议
## AI 产品经理 Case Study v0.3

> 项目阶段：Beta Prototype  
> 我的角色：用户研究、产品定义、评测设计、Prompt / Workflow 设计、版本决策与用户验证  
> 相关文档：《Research Deliberation PRD v0.3》

---

# 1. 项目概述

Research Deliberation 是一个面向人文社科研究者的研究设计预审产品。

它解决的不是“帮用户再写一份论文”，而是：

> 当研究者已经有一份 proposal，却隐约觉得研究设计不对时，帮助他判断根本问题在哪里、不同学术位置会如何质疑，以及下一步应该局部修改还是重构。

项目最重要的不是最终做出了一个多 Agent Skill，而是通过三轮 Eval 连续推翻了两个直觉：

1. 多角色 Prompt 不等于多 Agent；
2. 保护 Lead 不等于保护正确判断。

最终，产品从“一个 Skill 生成一份综合报告”演变为：

> 四个独立评议位置 + Editor + 分层 Research Review Packet。

---

# 2. 用户洞察与产品切口

## 2.1 用户已经不缺什么

早期访谈对象是一名国际关系方向博士生。她已经在使用 Claude、ChatGPT、Gemini 等工具处理：

- 文献摘要；
- 基础文献梳理；
- 初稿生成；
- 语言修改；
- 一般性问题清单。

这些任务已经被通用模型部分满足。

## 2.2 用户真正缺什么

访谈中最关键的三条洞察是：

### AI 太容易迎合用户

用户不希望 AI 只是“另一个自己”，而是希望它理解自己的研究，同时保留足够外部性，指出自己没意识到的问题。

### 用户缺少稳定的评议位置

现实中，导师和同门反馈有限，也很难同时获得：

- 大同行的理论意义判断；
- 小同行的领域与文献判断；
- 盲审人的拒稿风险判断。

### 用户缺的不是更多意见，而是根因诊断

通用模型往往能列出十个问题，却不一定能说明：

- 这些问题是不是同一个根因造成的；
- 哪一个必须先改；
- 哪些只是症状；
- 是局部修补还是整体重构。

## 2.3 为什么选择研究设计预审

访谈后其实有多个方向：

- 研究雷达；
- 选题生成；
- 期刊画像；
- 论文盲审；
- 研究设计预审。

我选择研究设计预审作为首个切口，因为它同时满足：

| 判断标准 | 原因 |
|---|---|
| 用户价值高 | 方向错误越早发现，越能减少后续无效投入 |
| 问题明确 | 用户能判断反馈是否真正击中问题 |
| 可建立 Baseline | 可直接与裸模型评审比较 |
| 可评测 | 可测重大问题覆盖、误判、角色互补和用户采纳 |
| 不依赖完整平台 | 不需要先建设学术知识库或复杂前端 |

---

# 3. 初始假设与 Eval 设计

## 3.1 初始产品假设

最初假设是：

> 把 Lead Researcher、大同行、小同行和盲审人写进同一个 Skill，再由 Editor 综合，就能比裸模型提供更全面、更可靠的学术评议。

这里隐含了三个未经验证的前提：

- 不同角色名称会自然产生不同视角；
- 更多流程和规则会提高质量；
- 一份统一报告比保留分歧更适合用户。

## 3.2 为什么先做裸模型 Baseline

强模型本身已经能做高质量评审。

没有 Baseline，就很容易把这些误认为产品增量：

- 输出更长；
- 格式更复杂；
- 角色更多；
- 表格更多；
- 看起来更专业。

所以 Eval 的核心问题不是：

> “这个 Skill 看起来好不好？”

而是：

> “在同一份研究材料上，它能否稳定提供超出裸模型的增量？”

## 3.3 测试集

测试集覆盖五类研究方法：

| 案例 | 类型 | 主要风险 |
|---|---|---|
| T01 | 数字治理 / 混合方法 | 因变量混合、按因变量选样、方法错配 |
| T02 | 质性访谈 | 成功者偏差、守门人、扎根理论、伦理 |
| T03 | 历史档案 | 时间断裂、目的论、史料偏差 |
| T04 | 横截面定量 | 反向因果、中介时序、代表性、聚类 |
| T05 | 教育实验 | 复合处理、班级混淆、测量与伦理 |

T02-T05 为合成案例，每个案例提前埋入隐藏问题键，模型在生成时不可见。

## 3.4 Rubric 的演进

### 第一阶段：九维 Rubric

第一轮同时评价：

- 核心问题召回；
- 准确性；
- 推理深度；
- 优先级；
- 建议质量；
- 新增洞见；
- 角色差异；
- 编辑质量；
- 证据纪律。

### 第二阶段：方法专项检查

跨方法测试暴露出：

- 历史研究需要检查关键时间断裂与目的论；
- 定量研究需要检查反向因果、中介时序和聚类；
- 实验研究需要检查处理混淆、随机化层级和测量效度。

因此加入历史、质性、定量和实验专项 checklist。

### 第三阶段：统一七维产品 Rubric

最终收敛为：

| 维度 | 权重 |
|---|---:|
| 核心问题覆盖 | 25% |
| 准确性与可辩护性 | 15% |
| 推理深度 | 15% |
| 建议质量 | 10% |
| 视角多样性 | 12% |
| 可追溯性与可审计性 | 10% |
| 导航与使用体验 | 13% |

Rubric 初稿来自用户访谈、同行评审一般要求和测试中暴露的 failure mode，后续根据两位人文社科博士和一位国际关系学院副教授的咨询意见进行了修订。

---

# 4. V1：单体多角色，结构变好，判断没有稳定变好

## 4.1 V1 架构

```mermaid
flowchart LR
    A[Lead 整体审读] --> B[大同行 Challenge]
    B --> C[小同行 Challenge]
    C --> D[盲审人 Challenge]
    D --> E[定向核验]
    E --> F[Editor 综合]
```

所有角色在同一上下文中顺序工作，后续角色能看到 Lead 的结论。

## 4.2 结果

V1 平均综合分略高于裸模型，但只赢 2/5 个案例；学术核心分反而更低。

| 指标 | 裸模型 | V1 |
|---|---:|---:|
| 五案例平均综合分 | 80.2 | 81.0 |
| 五案例平均学术核心分 | **86.2** | 80.3 |
| V1 获胜案例 | — | 2 / 5 |

这说明 V1 的增量主要来自：

- 结构；
- 可读性；
- 角色包装；
- 优先级和编辑组织。

但核心学术判断没有稳定提升。

## 4.3 关键 failure mode

### Lead 锚定

在 T03 历史案例中，Lead 没识别 1945-1949 的关键制度转换期。后续角色围绕 Lead 继续展开，系统最终持续漏掉最重要的历史断裂。

### 角色附和

所谓大同行、小同行和盲审人，经常只是对 Lead 结论换一种措辞，并未真正形成独立判断。

### Editor 制造虚假共识

T01 中只有一个角色偏好 QCA，Editor 却把它升级成“委员会方案共识”。

这暴露出一个重要区别：

> 大家都认为原方案有问题，不等于大家都支持同一个替代方案。

## 4.4 V1 结论

> 多角色结构可以提高覆盖和可读性，但角色名称不等于独立判断；共享上下文会把 Lead 的答案变成整个系统的锚点。

---

# 5. V2：保护 Lead，反而放大错误

## 5.1 修复方案

V2 做了三件事：

1. 把 Lead 设为不可破坏的主干；
2. 加入历史、质性、定量和实验专项 checklist；
3. 区分诊断共识和方案共识。

当时的假设是：

> V1 的问题主要是好判断在后续综合中丢失，只要保护 Lead，再用 checklist 补漏，就能解决。

## 5.2 回归结果

T02-T05 上：

| 版本 | 平均分 |
|---|---:|
| 裸模型 | 81.4 |
| V1 | 80.3 |
| V2 | **77.3** |

V2 只在 T04 小幅改善，在 T03 和 T05 明显回归。

## 5.3 为什么失败

### Lead 正确时，主干有帮助

T04 中 Lead 的因果和测量判断基本正确，因此保护 Lead 带来小幅改善。

### Lead 错误时，主干变成放大器

T03 仍然漏掉 1945-1949 关键过渡期，还把错误时间范围评价为“精准”。

### Checklist 没进入真正决策

T05 中规则文件明明已经写入实验风险，但最终判断仍然被 Lead 带偏，持续过度关注教师效应，漏掉：

- AI 组接受的是复合教学处理；
- 处理与班级绑定；
- 学校类型与单一学校绑定。

## 5.4 V2 结论

> 保真不等于保留第一个答案。Lead 正确时，主干是保护；Lead 错误时，主干是放大器。

这次回归说明问题不再是 Prompt 写得不够细，而是架构本身有问题。

---

# 6. V3：从下属挑战者到平级评议者

## 6.1 架构变化

V3 改为独立子 Agent。

```mermaid
flowchart TD
    A[同一份 Proposal] --> B1[Lead Researcher]
    A --> B2[大同行 Peer]
    A --> B3[小同行 Peer]
    A --> B4[期刊盲审人]

    B1 --> C[Editorial Deliberation]
    B2 --> C
    B3 --> C
    B4 --> C
```

关键变化不是角色更多，而是：

- 四个角色读取同一份用户材料；
- 彼此看不到其他角色结论；
- 每个角色有独立任务边界；
- Editor 只在最后汇合；
- Editor 不再代表一个统一学术权威。

## 6.2 命名变化本身也是架构证据

旧版本的文件名是：

- `broad-field-challenge`
- `specialist-challenge`

V3 改为：

- `broad-field-peer`
- `specialist-peer`

从 `challenge` 到 `peer`，不是文案变化，而是产品关系变化：

> 角色不再是 Lead 的下属挑战者，而是与 Lead 平级、独立形成判断的评议者。

同时，V3 增加了独立的 `editorial-deliberation` 文件，意味着 Editor 的职责从“默认总结”改为“明确裁决共识、分歧和优先级”。

## 6.3 T03 是最硬的架构证据

T03 历史案例中，V1/V2 持续漏掉 1945-1949 内战期。

V3 的最终评议直接把这一点标记为 Fatal：

> “1945-1949 年内战期完全未被纳入。”

这不是单纯的 Judge 分数变化，而是肉眼可见的输出差异。

它说明：

> 独立评议的价值，是在 Lead 出错时仍有其他角色能够重新发现关键问题。

## 6.4 从一份报告到 Research Review Packet

独立评议的价值存在于角色差异里。

如果 Editor 最后把所有内容压成一份统一摘要，独立性又会被消解。

因此最终交付单位改为：

| 层级 | 内容 | 用户用途 |
|---|---|---|
| Decision Brief | 总体结论、三大问题、共识与分歧 | 快速决策 |
| Expert Memos | Lead、大同行、小同行、盲审人完整评议 | 深度阅读 |
| Evidence Appendix | 文献、事实和核验状态 | 审计与复核 |

这是一种 Progressive Disclosure：

- 用户可以先看 10 分钟摘要；
- 再按需下钻到具体角色；
- 深度不会被摘要消失。

---

# 7. 真实用户与专业反馈

## 7.1 用户对照

一名全球气候治理方向博士生对比了：

- 裸模型评审；
- Research Deliberation 完整 Packet。

她认为：

- 裸模型更像症状清单；
- 完整 Packet 更能解释为什么问题会同时出现；
- “因变量缺失”“循环论证”“案例新颖性冒充理论贡献”是更关键的诊断；
- 她据此形成了本周、两周内和一个月内的修改计划。

她也指出：

- 四份角色报告过长；
- 学术最优方案可能超出用户能力；
- 对预测的否定不应过度绝对；
- 需要分层阅读和现实约束输入。

这些反馈直接形成下一阶段需求：

- 分层前端；
- 用户能力和时间进入 Intake；
- 同时展示“学术最优方案”和“当前可执行方案”。

## 7.2 教授与同领域博士反馈

两位评议者都更倾向完整 Packet，主要原因是：

- 能从多个症状中找到共同根因；
- 能识别循环论证；
- 能把理论、方法、文献和拒稿风险分开；
- 文献核验提供了人类同行通常不会逐项完成的价值。

但他们也认为：

- 裸模型的优先级表更容易马上执行；
- V3 对用户方法能力估计偏乐观；
- 中文文献语境不足；
- 部分方法判断过于绝对。

因此最终定位不是“全面替代裸模型”，而是：

> V3 更适合早期方向诊断；裸模型仍适合终稿前快速硬伤检查。

---

# 8. 成本、工具路由与产品定位

一次真实 SNA 提案评议中：

| 指标 | 结果 |
|---|---:|
| 总耗时 | 约 56 分钟 |
| 总 Token | 约 383.9 万 |
| 估算 API 成本 | 约 0.61 美元 / 4.4 元人民币 |

表面上看，单次调用成本并不高，但等待时间和 Token 使用量都不低。进一步查看执行轨迹后，我发现，成本异常并不完全来自复杂学术推理，而是集中出现在 Pass 3“定向验证”阶段。

## 8.1 一次工具路由事故：“开大货车去菜市场买葱”

在 v0.3 的 Lead Spine 架构中，Pass 3 负责核验开题报告中的高风险主张，例如：

- 研究是否真的具有所声称的创新性；
- 某个理论命题是否得到既有文献支持；
- 引用文献是否与综述中的表述一致。

主 Agent 通过 `delegate_task` 派出子代理执行文献检索。该子代理拿到 `browser` 工具后，开始逐页打开 Google Scholar、期刊网站和数据库，并持续执行点击、滚动、页面读取和截图。

问题在于，文献检索实际需要的通常只是：

- 论文标题；
- 作者和年份；
- 摘要；
- DOI 或其他元数据；
- 与待核验主张直接相关的少量原文。

而 `browser` 会把完整网页结构、动态脚本和大量无关页面内容带入上下文。它产生的计算成本并没有转化为同等规模的信息增量。

这相当于：

> 开着一辆大货车去菜市场买一把葱。

这次执行轨迹让我把问题进一步拆成了两个层次。

### 工具路由错误

纯文献搜索、元数据获取和静态页面读取，通常不需要浏览器交互。

后续版本将 Pass 3 子代理的默认工具集调整为：

```text
["terminal", "web", "file"]
```

`browser` 不再作为默认工具，而只在以下情况下使用：

- 页面必须经过 JavaScript 渲染；
- 需要点击、登录或填写表单；
- 内容无法通过静态请求获得；
- 必须验证页面的交互状态。

这里的产品判断不是“更强的工具更好”，而是：

> 应选择能够以最低上下文成本完成任务的工具。

### 检索缺少停止条件

工具变轻并不能彻底解决问题。

面对付费墙、不可开放获取的论文或证据不足的主张，子代理仍可能不断更换检索词、入口和替代来源，尝试完成实际上无法完成的全文核验。

因此，新版 Pass 3 为每组 claim 加入了明确预算：

- 最多进行 3 组查询；
- 每组最多查看 5 条结果；
- 最多深入读取 3 篇原文；
- 找到 2 条可信来源后停止；
- 达到预算仍无法确认时，返回“无法充分核验”，而不是继续搜索。

同时，核验结果不再只有“通过”或“不通过”，而是允许保留不同证据状态，例如：

- 全文已核验；
- 摘要或权威元数据已核验；
- 仅有二手来源支持；
- 全文不可访问，暂无法核验。

这使“无法完成核验”不再是一种隐藏的执行失败，而成为用户可见、可审计的证据边界。

## 8.2 成本治理的产品含义

这次事故让我意识到：

> Agent 成本治理不是简单压缩总 Token，而是识别低信息增益循环，并让系统具备有条件停止的能力。

对于文献检索等开放世界任务，Agent 不仅需要知道如何继续搜索，还必须知道：

- 当前工具是否与任务匹配；
- 新一轮检索是否仍可能带来新增信息；
- 何时已经达到可接受证据门槛；
- 何时应该诚实地返回“不足以确认”。

因此，成本控制最终被设计成三个相互配合的机制：

| 机制 | 解决的问题 |
|---|---|
| 工具路由 | 避免用高上下文工具处理轻量任务 |
| 查询预算 | 避免在不可得证据上无限尝试 |
| 失败状态 | 避免为了完成任务而制造虚假确定性 |

## 8.3 产品定位

即使单次 API 成本不高，完整运行仍然需要较长等待时间和较高推理预算。

因此产品更适合：

> 高风险、低频、值得深度判断的研究决策。

不适合：

- 日常问答；
- 快速润色；
- 每次修改都运行完整四角色流程；
- 对低风险主张进行无上限的全文核验。

# 9. 最终产品判断

## 被证伪的假设

| 假设 | 结果 |
|---|---|
| 写入多个角色就会产生多视角 | 同一上下文导致角色附和 |
| 更多规则自然提高质量 | 复杂流程可能压制模型 |
| 保护 Lead 能保护好判断 | Lead 错误时会放大错误 |
| Editor 应统一答案 | 可能制造虚假共识 |
| 一份综合报告是最佳交付 | 会压缩掉独立角色价值 |

## 得到支持的判断

| 判断 | 证据 |
|---|---|
| 裸模型必须作为强 Baseline | V1、V2 都没有稳定超过裸模型 |
| 独立上下文提高纠偏能力 | T03、T05 恢复关键问题覆盖 |
| 多 Agent 价值来自任务边界 | V3 角色互补显著提高 |
| 分层 Packet 比单一摘要更合理 | 用户既要快速结论，也要下钻审计 |
| 分歧应被保留 | 用户和专家都认为不同路线不能被强行统一 |
| 工具能力越强，不代表越适合作为默认工具 | Pass 3 使用 browser 进行轻量文献检索，产生大量低信息增益上下文 |
| 开放世界检索必须设置预算与失败状态 | 新版限定查询、结果和原文数量，并允许返回“无法充分核验” |
| 成本必须进入产品判断 | 完整运行耗时约 56 分钟，且异常消耗可追溯到具体子代理和工具调用 |

---

# 10. 这次项目体现的 AI PM 能力

| 能力 | 项目证据 |
|---|---|
| 用户研究 | 从“AI 太谄媚”提炼出保持外部性的产品原则 |
| 产品切口 | 从多个科研方向中选择可验证的研究设计预审 |
| Baseline 意识 | 与裸模型逐案对照 |
| Eval 设计 | 跨方法测试、隐藏评分键、Rubric、Judge 与人工复核 |
| Failure Analysis | 识别 Lead 锚定、角色附和和虚假共识 |
| 架构判断 | 从 Prompt 修补转向上下文隔离 |
| 交付设计 | 将一份报告重构为分层 Packet |
| 成本意识 | 记录 Token、时延和调用成本 |
| Tool Routing 设计 | 将 Pass 3 从 browser 默认改为 terminal、web、file 优先 |
| Agent 可观测性与成本治理 | 通过执行轨迹定位异常子代理，并加入查询预算、停止条件和失败返回状态 |
| 边界管理 | 不把少量用户反馈包装成规模化验证 |
| Stop Decision | 核心假设初步成立后冻结 Beta，转向外部验证 |

---

# 11. 局限

1. T02-T05 是合成案例；
2. 评分使用独立 Judge Model，并经人工复核，仍可能存在模型偏好；
3. 旧版本分数按最终七维 Rubric 重新映射；
4. V3 使用更多推理预算和输出容量；
5. V3 同时改变了角色隔离、工具路由和检索预算，整体提升不能完全归因于单一变量；
6. 尚未完成严格等 Token 消融；
7. 四角色最优性尚未做角色消融；
8. Judge 重测一致性尚未验证；
9. 教授与博士反馈不是严格双盲；
10. 真实用户样本仍然有限；
11. Context Pack 写回已实现，但长期复利尚未验证。

---

# 12. 下一步

下一阶段不再继续堆角色，而是分别验证产品价值和系统效率。

## 产品价值

1. 薄前端能否降低 Packet 的阅读负担；
2. 用户能力、时间和数据约束进入 Intake 后，建议是否更可执行；
3. 四角色是否都是必要的，还是存在更精简的角色组合。

## 系统效率与归因

1. 在等 Token、等成本条件下，独立上下文是否仍然优于 Lead Spine；
2. 在相同检索任务下，轻量工具优先是否显著降低 Token 和等待时间；
3. 查询预算、停止条件和失败状态分别带来多大收益；
4. 将角色隔离、工具路由和检索预算拆开做消融，避免把 V3 的整体提升错误归因于单一架构变化。

# 13. 面试版一句话

> 我没有假设一个专用 Skill 一定比通用模型强，而是用裸模型 Baseline、跨方法测试和三轮回归不断证伪自己的设计。第一版多角色流程在历史和实验案例中压制了模型，第二版保护 Lead 反而放大错误锚定。最终我把架构改成四个独立子 Agent，并把交付从一份综合报告重构为可分层下钻的 Research Review Packet。在四个可比案例上，统一 Rubric 下的启发式平均分从裸模型 77.3 提升到 92.7。同时，我通过执行轨迹定位了 Pass 3 的异常 Token 消耗，将文献检索从 browser 默认改为轻量工具优先，并加入查询预算和失败状态。这个项目最终验证的是：多 Agent 的价值来自上下文隔离、任务边界、可审计分歧和受约束的工具使用，而不是角色名称、Prompt 长度或无限制搜索。

---

# 附录：最终统一评测结果

> 本表采用最终七维 Rubric，对 T02-T05 四个可比案例进行统一口径比较。分数为启发式相对评分，用于版本比较，不代表绝对学术质量。

| 案例 | 裸模型 Baseline | V1 单体多角色 | V2 Lead 保护补丁 | V3 独立多 Agent 完整 Packet | V3 相对裸模型 |
|---|---:|---:|---:|---:|---:|
| T02 质性访谈 | 74.32 | 85.56 | 85.35 | **93.60** | +19.28 |
| T03 历史档案 | 76.78 | 76.08 | 68.32 | **91.64** | +14.86 |
| T04 横截面定量 | 78.44 | 81.25 | 83.17 | **90.84** | +12.40 |
| T05 教育实验 | 79.50 | 75.80 | 72.07 | **94.64** | +15.14 |
| **平均分** | **77.26** | **79.67** | **77.23** | **92.68** | **+15.42** |

最终七维 Rubric 包括：

- 核心问题覆盖；
- 判断准确性与可辩护性；
- 推理深度；
- 修改建议质量；
- 视角多样性；
- 可追溯性与可审计性；
- 导航与使用体验。

V3 按完整产品交付单位计分，即：

> 决策摘要 + 四份独立角色评议 + 共识与分歧 + 证据附录。