绝尘
98393b4908
Tauri 2 + Vue 3 + Vite 6 桌面应用，Rust workspace 含 13 个 crate (df-ai / df-storage / df-workflow / df-core / df-execute 等)。 核心能力：AI 聊天 agentic 循环(工具调用+人工审批)、工作流引擎、 任务/想法/项目/阶段管理、可追溯性，及配套前端组件。
489 lines
18 KiB
Markdown
489 lines
18 KiB
Markdown
# 想法探索模块 — 对抗式评估设计
|
||
|
||
> 创建: 2026-06-10 | 状态: 设计中
|
||
|
||
---
|
||
|
||
## 一、核心理念
|
||
|
||
### 魔法打败魔法
|
||
|
||
传统 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 维护成本高 │ │
|
||
│ │ ⚠️ 严重: 桌面应用市场天花板明显 │ │
|
||
│ └────────────────────────────────────────┘ │
|
||
│ │
|
||
│ ┌── 🔵 客观分析 ─────────────────────────┐ │
|
||
│ │ 📊 竞品: 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 字段。
|