# 想法探索模块 — 对抗式评估设计

> 创建: 2026-06-10 | 状态: 设计中

> ⚠️ **本文档为设计稿，未实施**。当前 `crates/df-ideas/src/adversarial.rs` 的 `evaluate()` 为**纯启发式**实现（基于评分与内容信号的正反方论点生成），**未接入 LLM**（代码注释明确「待接入 df-ai LlmProvider 让正反方论点由 LLM 生成，启发式降级为 fallback」）。本文档第二章「三路 LLM 对抗评估」、第五章「AI Prompt 模板」、第八章「Phase 2 实现计划」及第四章的 `idea_evaluations` 表均为**设计稿**——全仓 `grep idea_evaluations` 零命中，migrations.rs（V1-V13）无此表。设计稿标未实施，不代表落地目标变更，详见功能决策记录「📐 设计未实施」标注。核对记录见 `docs/05-代码审查/文档全量核对报告-2026-06-15.md` §11。

---

## 一、核心理念

### 魔法打败魔法

传统 AI 评估是"AI 打分 → 给建议"，问题是 **AI 倾向于说好话**。大模型天生乐观，给它一个想法，它会说"这个想法很有潜力"，因为训练数据里充满了创业成功故事。

DevFlow 的做法：**让 AI 同时扮演正方和反方，对抗辩论，最终综合裁决。**

```
传统评估:   想法 → AI评分 → "8/10，建议推进"     ← 一言堂，容易乐观
DevFlow:    想法 → 正方论证 vs 反方质疑 → 裁决     ← 对抗制，逼出真问题
```

### 设计灵感

这正是我们验证 DevFlow 自身的方式——三路代理同时论证：
1. 竞品与市场可行性（外部威胁）
2. 技术可行性（内部能力）
3. 需求真实性（用户价值）

**把这个方法论产品化**，每个想法都经历同样的三路对抗论证。

---

## 二、评估流程设计

### 2.1 三阶段对抗评估

```
💡 想法输入
    │
    ▼
┌─────────────────────────────────────────┐
│  第一轮: 三路独立论证 (并行)              │
│                                          │
│  🟢 正方辩护者          — 为什么值得做     │
│  🔴 反方质疑者          — 为什么会失败     │
│  🔵 冷眼分析师          — 客观数据和事实   │
│                                          │
│  三路独立输出，互不可见                    │
└─────────────┬───────────────────────────┘
                │
                ▼
┌─────────────────────────────────────────┐
│  第二轮: 交叉质询                         │
│                                          │
│  正方看到反方论点 → 尝试反驳或承认弱点      │
│  反方看到正方辩护 → 寻找更多漏洞           │
│  分析师汇总双方 → 补充客观数据             │
└─────────────┬───────────────────────────┘
                │
                ▼
┌─────────────────────────────────────────┐
│  第三轮: 裁决                              │
│                                          │
│  📊 综合评分 (不再是简单的 1-10)            │
│  ├── 价值分: 解决的问题有多痛？             │
│  ├── 可行分: 个人能力能否实现？             │
│  ├── 差异分: 有没有别人没做的？             │
│  └── 风险分: 最坏情况有多坏？               │
│                                          │
│  📝 最终建议: 强烈推荐 / 值得探索 /         │
│               需要更多信息 / 建议暂缓       │
│                                          │
│  ⚠️ 致命风险清单: 必须回答的问题             │
└─────────────────────────────────────────┘
```

### 2.2 三个角色详细设计

#### 🟢 正方辩护者 (Advocate)

**目标**：找出这个想法值得做的所有理由。

| 论证维度 | Prompt 方向 |
|---------|-----------|
| 用户痛点 | 这个问题真实存在吗？有多痛？谁在痛？ |
| 解决方案 | 想法的核心价值主张是什么？解决了什么？ |
| 市场时机 | 为什么是现在做而不是一年前或一年后？ |
| 个人优势 | 以你的技术栈和能力，做这个有什么独特优势？ |
| 最小可行 | 最简版本可以多简单？MVP 的核心功能是什么？ |

**输出格式**：
```
## 正方论证

### 核心价值
[一段话描述这个想法为什么有价值]

### 支撑论据
1. [论据1 + 证据]
2. [论据2 + 证据]
3. [论据3 + 证据]

### 个人匹配度
[技术栈/经验/资源的匹配分析]

### MVP 建议
[最小可行产品的核心功能清单]
```

#### 🔴 反方质疑者 (Devil's Advocate)

**目标**：找出这个想法会失败的所有可能原因。**越狠越好。**

| 质疑维度 | Prompt 方向 |
|---------|-----------|
| 伪需求 | 用户真的会为此付费/花时间吗？还是"我觉得需要"？ |
| 竞品碾压 | 现有工具是否已经解决了这个问题？ |
| 技术幻觉 | 技术上真的可行吗？还是被新技术蒙蔽了判断？ |
| 资源黑洞 | 需要多少时间/精力？机会成本是什么？ |
| 维护陷阱 | 做出来之后，维护成本有多高？ |
| 规模天花板 | 个人开发者工具的市场有多大？ |

**输出格式**：
```
## 反方质疑

### 致命风险 (任意一条成立则建议放弃)
1. [风险1 + 为什么是致命的]
2. [风险2 + 为什么是致命的]

### 严重问题 (不致命但会显著增加难度)
1. [问题1 + 影响评估]
2. [问题2 + 影响评估]

### 竞品威胁
[列出已有的解决方案，它们做了什么，差距在哪]

### 历史教训
[类似产品/项目失败的原因]
```

#### 🔵 冷眼分析师 (Analyst)

**目标**：提供客观事实和数据，不偏不倚。

| 分析维度 | Prompt 方向 |
|---------|-----------|
| 市场数据 | 这类工具的市场规模、增长趋势 |
| 技术趋势 | 依赖的核心技术成熟度、发展方向 |
| 成功案例 | 类似产品的成功经验 |
| 失败案例 | 类似产品的失败教训 |
| 工时估算 | 粗略的工时估算（MVP/完整版） |

**输出格式**：
```
## 客观分析

### 事实清单
1. [事实 + 来源]
2. [事实 + 来源]

### 竞品对照表
| 特性 | DevFlow想法 | 竞品A | 竞品B |
|------|-----------|-------|-------|

### 工时估算
- MVP: ~X 周
- 完整版: ~X 月

### 关键假设
[这个想法成立所依赖的关键假设清单]
```

---

## 三、裁决机制

### 3.1 四维评分（替代单一分数）

传统评分："可行性 8/10" — 过于笼统。

DevFlow 四维评分：

| 维度 | 含义 | 权重 | 来源 |
|------|------|------|------|
| **价值分** (Value) | 解决的痛点有多强？用户愿意花多少时间？ | 30% | 正方 + 分析师 |
| **可行分** (Feasibility) | 以个人能力，技术上能否实现？ | 25% | 反方质疑 + 分析师 |
| **差异分** (Differentiation) | 与现有方案的差异化有多大？ | 25% | 分析师竞品对照 |
| **风险分** (Risk, 反向) | 最坏情况有多坏？失败概率多大？ | 20% | 反方致命风险 |

**综合分** = Value×0.3 + Feasibility×0.25 + Diff×0.25 + (10-Risk)×0.2

### 3.2 建议等级

不再给"推荐/不推荐"二元判断，而是分级：

| 等级 | 条件 | 含义 |
|------|------|------|
| 🟢 **强烈推荐** | 综合分 ≥ 8 且无致命风险 | 痛点明确，差异化清晰，技术可行 |
| 🟡 **值得探索** | 综合分 6-7.9 或有 1 个可控风险 | 方向对，但需要验证关键假设 |
| 🟠 **需要更多信息** | 关键假设无法验证 | 先做小实验验证假设，再评估 |
| 🔴 **建议暂缓** | 综合分 < 6 或有 ≥2 个致命风险 | 痛点不清晰或竞品已覆盖 |

### 3.3 致命风险清单

无论综合分多高，只要有"致命风险"就高亮警告：

```
⚠️ 致命风险 (必须回答)
━━━━━━━━━━━━━━━━━━━━━━
❓ 竞品 X 已经实现了 80% 的功能，你的差异化在哪？
❓ 个人开发者市场验证过吗？有多少人表达过需求？
❓ 维护 13 个 Rust crate 的长期成本你考虑过吗？
```

---

## 四、数据模型

### 想法评估记录

```sql
-- 对抗式评估记录
CREATE TABLE idea_evaluations (
    id TEXT PRIMARY KEY,
    idea_id TEXT NOT NULL REFERENCES ideas(id),
    
    -- 正方
    advocate_args TEXT,           -- JSON: 正方论据列表
    advocate_score REAL,          -- 正方给的分数
    
    -- 反方
    devil_args TEXT,              -- JSON: 反方质疑列表
    devil_risks TEXT,             -- JSON: 致命风险列表
    devil_score REAL,             -- 反方给的分数
    
    -- 分析师
    analyst_facts TEXT,           -- JSON: 客观事实
    analyst_competitors TEXT,     -- JSON: 竞品对照
    analyst_estimate_hours REAL,  -- 工时估算
    
    -- 裁决
    value_score REAL,            -- 价值分
    feasibility_score REAL,      -- 可行分
    differentiation_score REAL,  -- 差异分
    risk_score REAL,             -- 风险分
    overall_score REAL,          -- 综合分
    
    recommendation TEXT,         -- 强烈推荐/值得探索/需要更多信息/建议暂缓
    fatal_risks TEXT,            -- JSON: 致命风险清单
    key_assumptions TEXT,        -- JSON: 关键假设清单
    
    evaluated_at TEXT NOT NULL
);
```

### Rust 数据结构

```rust
pub struct IdeaEvaluation {
    pub id: String,
    pub idea_id: String,
    
    // 三路论证
    pub advocate: AdvocateReport,
    pub devil: DevilReport,
    pub analyst: AnalystReport,
    
    // 裁决
    pub verdict: Verdict,
}

pub struct AdvocateReport {
    pub core_value: String,
    pub arguments: Vec<Argument>,
    pub personal_fit: String,
    pub mvp_suggestion: Vec<String>,
    pub score: f64,
}

pub struct DevilReport {
    pub fatal_risks: Vec<Risk>,
    pub serious_issues: Vec<Issue>,
    pub competitor_threats: Vec<Competitor>,
    pub historical_lessons: Vec<String>,
    pub score: f64,
}

pub struct AnalystReport {
    pub facts: Vec<Fact>,
    pub competitor_comparison: Vec<CompetitorEntry>,
    pub estimate_hours_mvp: f64,
    pub key_assumptions: Vec<String>,
}

pub struct Verdict {
    pub value_score: f64,
    pub feasibility_score: f64,
    pub differentiation_score: f64,
    pub risk_score: f64,
    pub overall: f64,
    pub recommendation: Recommendation,
    pub fatal_risks: Vec<String>,
}

pub enum Recommendation {
    StronglyRecommended,
    WorthExploring,
    NeedMoreInfo,
    Defer,
}
```

---

## 五、AI Prompt 设计

### 正方 Prompt 模板

```
你是一个技术创业导师。你的任务是为一项软件开发想法找出所有【值得做】的理由。
你要像这个想法的联合创始人一样思考，积极寻找它的价值。

想法: {{title}}
描述: {{description}}

请从以下角度论证:
1. 用户痛点 — 这个问题真实存在吗？有多痛？
2. 核心价值 — 一句话说明这个产品做什么
3. 市场时机 — 为什么是现在？
4. 技术可行性 — 实现这个想法的核心技术栈是什么？
5. 个人优势 — 做这个想法的人有什么独特优势？
6. MVP 建议 — 最简版本只需要哪些功能？

你要有理有据，不要空喊口号。每个论点都要有具体的证据或类比。
```

### 反方 Prompt 模板

```
你是一个严厉的技术投资人，你的工作是【找出这个想法会失败的原因】。
你要像在投资评审会上一样苛刻，不放过任何潜在问题。

想法: {{title}}
描述: {{description}}

请从以下角度质疑:
1. 伪需求检查 — 用户真的需要这个吗？还是"我觉得需要"？
2. 竞品碾压 — 有没有现有工具已经解决了这个问题？搜索并列出至少 3 个竞品
3. 技术幻觉 — 技术上真的可行吗？有没有低估的技术难点？
4. 资源黑洞 — 需要多少时间？机会成本是什么？
5. 维护陷阱 — 做出来后维护成本有多高？
6. 规模天花板 — 这个领域的市场天花板有多高？

区分"致命风险"（任何一个成立就该放弃）和"严重问题"（增加难度但不致命）。
越是致命的问题，越要给出具体的证据和案例。
```

### 分析师 Prompt 模板

```
你是一个中立的行业分析师。你的任务是提供【客观事实】，不偏袒任何一方。

想法: {{title}}
描述: {{description}}

请提供:
1. 事实清单 — 列出你确认为真的相关事实（市场规模、技术趋势、用户数据等）
2. 竞品对照 — 搜索并列出同类产品，对比功能差异
3. 工时估算 — 粗略估算 MVP 和完整版的开发时间
4. 关键假设 — 这个想法成立依赖哪些假设？哪些假设最可能不成立？

不要给建议，只给事实。如果你不确定某个事实，标注"待验证"。
```

### 裁决 Prompt 模板

```
你是一个公正的裁决者。你收到了三份报告，请综合裁决。

【正方论证】
{{advocate_report}}

【反方质疑】
{{devil_report}}

【客观分析】
{{analyst_report}}

请给出:
1. 四维评分 (每项 1-10):
   - 价值分: 解决的痛点有多强？
   - 可行分: 个人开发者能否实现？
   - 差异分: 与现有方案的差异化有多大？
   - 风险分: (反向) 失败风险有多大？

2. 综合建议: 强烈推荐 / 值得探索 / 需要更多信息 / 建议暂缓

3. 致命风险清单: 列出所有"如果这个问题成立，就不该做"的风险

4. 关键假设: 这个想法成立所依赖的关键假设
```

---

## 六、前端展示设计

### 想法详情页 — 对抗评估面板

```
┌─────────────────────────────────────────────────┐
│  💡 想法: AI 原生产研操作系统                      │
│  状态: Scored │ 综合分: 7.2 🟡 值得探索             │
├─────────────────────────────────────────────────┤
│                                                  │
│  ┌─── 📊 四维雷达图 ──────────────────────┐      │
│  │         价值 9.2                        │      │
│  │        ╱    ╲                           │      │
│  │  差异 8.1    可行 6.5                    │      │
│  │        ╲    ╱                           │      │
│  │         风险 5.8                         │      │
│  └────────────────────────────────────────┘      │
│                                                  │
│  ┌── 🟢 正方辩护 ─────── 📊 8.5/10 ──────┐      │
│  │  核心价值: 个人开发者缺少全流程工具        │      │
│  │  ✓ 痛点真实 — 工具碎片化严重              │      │
│  │  ✓ AI 原生 — 现有工具未深度整合 AI        │      │
│  │  ✓ 技术匹配 — Rust+Vue 正好是强项        │      │
│  └────────────────────────────────────────┘      │
│                                                  │
│  ┌── 🔴 反方质疑 ─────── 📊 4.2/10 ──────┐      │
│  │  ⚠️ 致命: Claude Code 已在做全流程       │      │
│  │  ⚠️ 致命: 个人开发者工具付费意愿极低      │      │
│  │  ⚠️ 严重: 13 crate 维护成本高 (06-14裁至8)│      │
│  │  ⚠️ 严重: 桌面应用市场天花板明显          │      │
│  └────────────────────────────────────────┘      │
│                                                  │
│  ┌── 🔵 客观分析 ─────────────────────────┐      │
│  │  📊 竞品: n8n(工作流) Linear(项目管理)    │      │
│  │  🕐 MVP 估算: 4-6 周                     │      │
│  │  📝 关键假设: AI 编排是否真比手动高效     │      │
│  └────────────────────────────────────────┘      │
│                                                  │
│  ⚠️ 致命风险清单                                  │
│  ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━       │
│  ❓ Claude Code/Cursor 等工具已覆盖大部分场景       │
│  ❓ 个人开发者愿意为一个工具投入多少学习成本？       │
│                                                  │
│  [晋升为项目]  [重新评估]  [归档]                   │
└─────────────────────────────────────────────────┘
```

---

## 七、与其他模块的联动

### 晋升为项目时

当想法晋升为项目时，评估结论自动携带：
- 正方的 MVP 建议变成项目的初始任务
- 反方的风险清单变成项目的待解决风险
- 分析师的关键假设变成需要验证的检查点

### 决策留痕

对抗评估本身就是一次重大决策，自动进入决策日志：
- 决策：是否推进这个想法
- 正方论据 / 反方论据 / 最终决定
- 如果后续项目失败，可以回溯到评估阶段看"当时反方说了什么"

### 经验进化

评估的 Prompt 模板会持续优化：
- 如果一个想法评估为"强烈推荐"但最终失败了，反方 Prompt 需要加强
- 如果一个想法被"建议暂缓"但后来被证明是好的，正方 Prompt 需要加强
- 形成"评估校准"的反馈闭环

---

## 八、实现计划

| Phase | 内容 | 依赖 |
|-------|------|------|
| Phase 2 | 实现正方+反方+分析师三路 LLM 调用 | df-ai LlmProvider 实现 |
| Phase 2 | 新增 idea_evaluations 表 | Migrations V3 |
| Phase 2 | 前端对抗评估面板 | 前端 Store 对接 |
| Phase 3 | 交叉质询（第二轮）| 多轮对话能力 |
| Phase 5 | 评估校准（经验进化）| df-evolve 模块 |

Phase 1 的想法评估继续使用固定算法评分，但数据模型预留 evaluation 字段。
