DevFlow/docs/03-模块文档/想法探索-对抗式评估-2026-06-12.md

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

创建: 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 的长期成本你考虑过吗？

---

四、数据模型

想法评估记录

-- 对抗式评估记录
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 数据结构

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 维护成本高            │      │
│  │  ⚠️ 严重: 桌面应用市场天花板明显          │      │
│  └────────────────────────────────────────┘      │
│                                                  │
│  ┌── 🔵 客观分析 ─────────────────────────┐      │
│  │  📊 竞品: 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 字段。