# 想法探索模块 — 对抗式评估设计 > 创建: 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, pub personal_fit: String, pub mvp_suggestion: Vec, pub score: f64, } pub struct DevilReport { pub fatal_risks: Vec, pub serious_issues: Vec, pub competitor_threats: Vec, pub historical_lessons: Vec, pub score: f64, } pub struct AnalystReport { pub facts: Vec, pub competitor_comparison: Vec, pub estimate_hours_mvp: f64, pub key_assumptions: Vec, } 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, } 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 字段。