新增: 初始化 DevFlow 项目仓库
Tauri 2 + Vue 3 + Vite 6 桌面应用，Rust workspace 含 13 个 crate (df-ai / df-storage / df-workflow / df-core / df-execute 等)。 核心能力：AI 聊天 agentic 循环(工具调用+人工审批)、工作流引擎、 任务/想法/项目/阶段管理、可追溯性，及配套前端组件。
This commit is contained in:
298
docs/03-模块文档/df-ai-AI集成模块.md
Normal file
298
docs/03-模块文档/df-ai-AI集成模块.md
Normal file
@@ -0,0 +1,298 @@
|
||||
# df-ai - AI 集成模块
|
||||
|
||||
> Provider 抽象层与流式响应处理
|
||||
|
||||
## 📋 模块概览
|
||||
|
||||
`df-ai` 负责 AI 功能的核心集成，支持多个 AI Provider，提供统一的接口和流式响应处理。
|
||||
|
||||
### 主要特性
|
||||
- 多 Provider 支持（OpenAI、Anthropic、DeepSeek）
|
||||
- 流式响应处理
|
||||
- 工具调用支持
|
||||
- 错误处理和重试机制
|
||||
|
||||
## 🏗️ 架构设计
|
||||
|
||||
### 核心组件
|
||||
```rust
|
||||
// Provider trait 定义
|
||||
pub trait AIProvider: Send + Sync {
|
||||
async fn chat_completion(&self, request: ChatRequest) -> Result<ChatResponse>;
|
||||
async fn create_embedding(&self, text: &str) -> Result<Vec<f32>>;
|
||||
}
|
||||
|
||||
// 流式响应处理
|
||||
pub struct StreamProcessor {
|
||||
event_sender: mpsc::UnboundedSender<StreamEvent>,
|
||||
}
|
||||
|
||||
// 统一的 AI 服务
|
||||
pub struct AIService {
|
||||
providers: HashMap<String, Box<dyn AIProvider>>,
|
||||
default_provider: String,
|
||||
}
|
||||
```
|
||||
|
||||
### Provider 实现
|
||||
- **OpenAIProvider**: OpenAI GPT 系列模型
|
||||
- **AnthropicProvider**: Claude 系列模型
|
||||
- **DeepSeekProvider**: DeepSeek 模型
|
||||
|
||||
## 🔧 使用方法
|
||||
|
||||
### 基础聊天
|
||||
```rust
|
||||
use df_ai::AIService;
|
||||
|
||||
let ai_service = AIService::new(config);
|
||||
let request = ChatRequest {
|
||||
model: "gpt-4".to_string(),
|
||||
messages: vec![Message {
|
||||
role: "user".to_string(),
|
||||
content: "Hello, world!".to_string(),
|
||||
}],
|
||||
};
|
||||
|
||||
let response = ai_service.chat_completion(request).await?;
|
||||
```
|
||||
|
||||
### 流式响应
|
||||
```rust
|
||||
use df_ai::stream_chat;
|
||||
|
||||
let (mut receiver, mut stream) = stream_chat(&ai_service, request).await?;
|
||||
|
||||
while let Some(event) = receiver.recv().await {
|
||||
match event {
|
||||
StreamEvent::Content(chunk) => {
|
||||
print!("{}", chunk);
|
||||
}
|
||||
StreamEvent::Done => {
|
||||
println!("\n完成");
|
||||
}
|
||||
StreamEvent::Error(e) => {
|
||||
eprintln!("错误: {}", e);
|
||||
}
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 工具调用
|
||||
```rust
|
||||
let request = ChatRequest {
|
||||
model: "gpt-4".to_string(),
|
||||
messages: vec![Message {
|
||||
role: "user".to_string(),
|
||||
content: "创建一个文件".to_string(),
|
||||
}],
|
||||
tools: vec![Tool {
|
||||
r#type: "function".to_string(),
|
||||
function: FunctionDef {
|
||||
name: "create_file".to_string(),
|
||||
description: "创建文件".to_string(),
|
||||
parameters: Parameters {
|
||||
r#type: "object".to_string(),
|
||||
properties: serde_json::json!({
|
||||
"path": {"type": "string"},
|
||||
"content": {"type": "string"}
|
||||
}),
|
||||
required: vec!["path".to_string()],
|
||||
},
|
||||
},
|
||||
}],
|
||||
tool_choice: "auto".to_string(),
|
||||
};
|
||||
```
|
||||
|
||||
## ⚙️ 配置
|
||||
|
||||
### Provider 配置
|
||||
```yaml
|
||||
# config/ai.yaml
|
||||
providers:
|
||||
openai:
|
||||
api_key: ${OPENAI_API_KEY}
|
||||
base_url: "https://api.openai.com/v1"
|
||||
model: "gpt-4"
|
||||
max_tokens: 4000
|
||||
temperature: 0.7
|
||||
|
||||
anthropic:
|
||||
api_key: ${ANTHROPIC_API_KEY}
|
||||
model: "claude-3-sonnet-20240229"
|
||||
max_tokens: 4000
|
||||
temperature: 0.7
|
||||
|
||||
deepseek:
|
||||
api_key: ${DEEPSEEK_API_KEY}
|
||||
model: "deepseek-chat"
|
||||
max_tokens: 4000
|
||||
temperature: 0.7
|
||||
|
||||
default_provider: "openai"
|
||||
```
|
||||
|
||||
### 环境变量
|
||||
```bash
|
||||
export OPENAI_API_KEY="sk-your-key"
|
||||
export ANTHROPIC_API_KEY="sk-ant-key"
|
||||
export DEEPSEEK_API_KEY="your-key"
|
||||
```
|
||||
|
||||
## 🔄 错误处理
|
||||
|
||||
### 错误类型
|
||||
```rust
|
||||
pub enum AIError {
|
||||
APIError(String), // API 调用失败
|
||||
Timeout, // 请求超时
|
||||
RateLimit, // 达到速率限制
|
||||
InvalidResponse, // 响应格式错误
|
||||
ProviderNotFound, // Provider 不存在
|
||||
ConfigurationError, // 配置错误
|
||||
}
|
||||
```
|
||||
|
||||
### 重试机制
|
||||
```rust
|
||||
let config = RetryConfig {
|
||||
max_attempts: 3,
|
||||
backoff: ExponentialBackoff::from_millis(1000),
|
||||
retryable_errors: vec![
|
||||
AIError::Timeout,
|
||||
AIError::RateLimit,
|
||||
],
|
||||
};
|
||||
|
||||
let response = ai_service.chat_with_retry(request, &config).await?;
|
||||
```
|
||||
|
||||
## 📊 性能优化
|
||||
|
||||
### 缓存机制
|
||||
```rust
|
||||
pub struct CachedAIService {
|
||||
inner: AIService,
|
||||
cache: Arc<Mutex<HashMap<String, ChatResponse>>>,
|
||||
}
|
||||
|
||||
// 缓存键生成
|
||||
fn cache_key(request: &ChatRequest) -> String {
|
||||
format!("{:?}-{:?}", request.model, request.messages)
|
||||
}
|
||||
```
|
||||
|
||||
### 连接池
|
||||
```rust
|
||||
pub struct ConnectionPool {
|
||||
connections: HashMap<String, Vec<Client>>,
|
||||
max_connections: usize,
|
||||
}
|
||||
|
||||
pub async fn get_client(&self, provider: &str) -> Result<Client> {
|
||||
// 从连接池获取或创建新连接
|
||||
}
|
||||
```
|
||||
|
||||
## 🔍 监控与日志
|
||||
|
||||
### 请求追踪
|
||||
```rust
|
||||
pub struct RequestTracer {
|
||||
request_id: String,
|
||||
start_time: Instant,
|
||||
metrics: RequestMetrics,
|
||||
}
|
||||
|
||||
impl RequestTracer {
|
||||
pub fn log_request(&self, provider: &str, duration: Duration) {
|
||||
metrics.record_request(provider, duration);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 指标收集
|
||||
```rust
|
||||
pub struct RequestMetrics {
|
||||
total_requests: AtomicU64,
|
||||
successful_requests: AtomicU64,
|
||||
failed_requests: AtomicU64,
|
||||
average_duration: AtomicDuration,
|
||||
}
|
||||
```
|
||||
|
||||
## 🧪 测试
|
||||
|
||||
### 单元测试
|
||||
```rust
|
||||
#[cfg(test)]
|
||||
mod tests {
|
||||
use super::*;
|
||||
|
||||
#[tokio::test]
|
||||
async fn test_chat_completion() {
|
||||
let ai_service = AIService::new(test_config());
|
||||
let request = test_request();
|
||||
let response = ai_service.chat_completion(request).await;
|
||||
assert!(response.is_ok());
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
### 集成测试
|
||||
```rust
|
||||
#[tokio::test]
|
||||
async fn test_multiple_providers() {
|
||||
let providers = vec!["openai", "anthropic"];
|
||||
for provider in providers {
|
||||
let ai_service = AIService::new(config_for_provider(provider));
|
||||
let response = test_chat(&ai_service).await;
|
||||
assert!(response.is_ok(), "Provider {} failed", provider);
|
||||
}
|
||||
}
|
||||
```
|
||||
|
||||
## 🚨 最佳实践
|
||||
|
||||
### 1. 错误处理
|
||||
```rust
|
||||
// ✅ 正确
|
||||
match ai_service.chat_completion(request).await {
|
||||
Ok(response) => handle_response(response),
|
||||
Err(AIError::RateLimit) => wait_and_retry(),
|
||||
Err(e) => log_error_and_notify(e),
|
||||
}
|
||||
|
||||
// ❌ 错误 - 忽略错误
|
||||
let _ = ai_service.chat_completion(request).await;
|
||||
```
|
||||
|
||||
### 2. 资源管理
|
||||
```rust
|
||||
// ✅ 正确 - 使用连接池
|
||||
let client = connection_pool.get_client("openai").await?;
|
||||
|
||||
// ❌ 错误 - 每次创建新连接
|
||||
let client = Client::new(config);
|
||||
```
|
||||
|
||||
### 3. 并发控制
|
||||
```rust
|
||||
// ✅ 正确 - 使用信号量
|
||||
let semaphore = Arc::new(Semaphore::new(10));
|
||||
let permit = semaphore.acquire().await?;
|
||||
let response = ai_service.chat_completion(request).await;
|
||||
|
||||
// ❌ 错误 - 无限制并发
|
||||
let handles: Vec<_> = requests.into_iter().map(|req| {
|
||||
tokio::spawn(ai_service.chat_completion(req))
|
||||
}).collect();
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
**相关文档**:
|
||||
- [df-storage - 存储层](./df-storage-存储层.md)
|
||||
- [df-workflow - 工作流引擎](./df-workflow-工作流引擎.md)
|
||||
- [df-nodes - 节点集合](./df-nodes-节点集合.md)
|
||||
74
docs/03-模块文档/df-nodes-节点集合.md
Normal file
74
docs/03-模块文档/df-nodes-节点集合.md
Normal file
@@ -0,0 +1,74 @@
|
||||
# df-nodes 节点集合
|
||||
|
||||
> 创建: 2026-06-10 | 状态: 初稿
|
||||
|
||||
---
|
||||
|
||||
## 概述
|
||||
|
||||
df-nodes 提供 DevFlow 工作流引擎的 8 种内置节点。所有节点实现 df-workflow 的 `Node` trait。
|
||||
|
||||
## 当前状态
|
||||
|
||||
所有 8 种节点 Schema 已定义完整，`execute()` 方法均为空实现。
|
||||
|
||||
## 节点清单
|
||||
|
||||
| 节点 | 功能 | 阻塞 | 实现状态 |
|
||||
|------|------|------|---------|
|
||||
| AINode | 调用 LLM，流式输出，工具调用 | 否 | 骨架 |
|
||||
| ScriptNode | Shell/脚本执行 | 否 | 骨架 |
|
||||
| DockerNode | Docker 容器操作 | 否 | 骨架 |
|
||||
| GitNode | Git 操作 (libgit2) | 否 | 骨架 |
|
||||
| HumanNode | 人工审批/确认 | 是 | 骨架 |
|
||||
| NotifyNode | 通知 (桌面/飞书/Webhook) | 否 | 骨架 |
|
||||
| HTTPNode | HTTP 请求 | 否 | 骨架 |
|
||||
| SubflowNode | 嵌套子工作流 | 否 | 骨架 |
|
||||
|
||||
## 实现优先级
|
||||
|
||||
Phase 1 阶段优先实现：
|
||||
|
||||
1. **ScriptNode** — 依赖 df-execute 的 Shell 执行器 (已可用)
|
||||
2. **HumanNode** — 阻塞节点，工作流审批需要
|
||||
|
||||
Phase 2 实现：
|
||||
|
||||
3. **AINode** — 依赖 df-ai Provider 实现
|
||||
|
||||
Phase 4 实现：
|
||||
|
||||
4. **DockerNode** — 依赖 bollard crate
|
||||
5. **GitNode** — 依赖 libgit2
|
||||
6. **HTTPNode** — HTTP 客户端
|
||||
7. **NotifyNode** — 通知渠道对接
|
||||
8. **SubflowNode** — 嵌套工作流引擎
|
||||
|
||||
## 依赖关系
|
||||
|
||||
```
|
||||
df-core
|
||||
← df-workflow (Node trait)
|
||||
← df-nodes
|
||||
← df-ai (AINode)
|
||||
← df-execute (ScriptNode)
|
||||
```
|
||||
|
||||
## 文件结构
|
||||
|
||||
```
|
||||
crates/df-nodes/src/
|
||||
├── lib.rs — 模块入口，注册所有节点
|
||||
├── ai_node.rs — AI 节点
|
||||
├── script_node.rs — 脚本节点
|
||||
├── docker_node.rs — Docker 节点
|
||||
├── git_node.rs — Git 节点
|
||||
├── human_node.rs — 人工审批节点
|
||||
├── notify_node.rs — 通知节点
|
||||
├── http_node.rs — HTTP 节点
|
||||
└── subflow_node.rs — 子工作流节点
|
||||
```
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [df-workflow 工作流引擎](./df-workflow-工作流引擎.md)
|
||||
53
docs/03-模块文档/df-storage-存储层.md
Normal file
53
docs/03-模块文档/df-storage-存储层.md
Normal file
@@ -0,0 +1,53 @@
|
||||
# df-storage 存储层
|
||||
|
||||
> 创建: 2026-06-10 | 状态: 初稿
|
||||
|
||||
---
|
||||
|
||||
## 概述
|
||||
|
||||
df-storage 是 DevFlow 的数据持久化层，基于 SQLite (rusqlite)，负责连接管理、Schema 迁移和 CRUD 操作。
|
||||
|
||||
## 当前状态
|
||||
|
||||
| 功能 | 状态 |
|
||||
|------|------|
|
||||
| SQLite 连接管理 | ✅ 已实现 |
|
||||
| Schema 迁移 (6 张表) | ✅ 已实现 |
|
||||
| CRUD 操作 | ⬜ 待实施 |
|
||||
| 事务支持 | ⬜ 待实施 |
|
||||
|
||||
## 数据表
|
||||
|
||||
Phase 1 已创建的 6 张核心表：
|
||||
|
||||
1. **ideas** — 想法池
|
||||
2. **projects** — 项目
|
||||
3. **tasks** — 任务
|
||||
4. **workflow_defs** — 工作流定义
|
||||
5. **workflow_runs** — 工作流执行
|
||||
6. **artifacts** — 产出物
|
||||
|
||||
完整表结构见 `ARCHITECTURE.md` 数据模型章节。
|
||||
|
||||
## 依赖关系
|
||||
|
||||
```
|
||||
df-core (错误类型、ID 生成)
|
||||
← df-storage
|
||||
```
|
||||
|
||||
## 文件结构
|
||||
|
||||
```
|
||||
crates/df-storage/src/
|
||||
├── lib.rs — 模块入口，导出公共 API
|
||||
├── connection.rs — SQLite 连接管理
|
||||
├── schema.rs — Schema 定义与迁移
|
||||
└── crud.rs — CRUD 操作 (待创建)
|
||||
```
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [SQLite CRUD 模式](../01-技术文档/SQLite-CRUD模式.md)
|
||||
- [前后端类型对齐](../02-架构设计/前后端类型对齐.md)
|
||||
81
docs/03-模块文档/df-workflow-工作流引擎.md
Normal file
81
docs/03-模块文档/df-workflow-工作流引擎.md
Normal file
@@ -0,0 +1,81 @@
|
||||
# df-workflow 工作流引擎
|
||||
|
||||
> 创建: 2026-06-10 | 状态: 初稿
|
||||
|
||||
---
|
||||
|
||||
## 概述
|
||||
|
||||
df-workflow 是 DevFlow 的核心引擎，负责 DAG 定义、拓扑排序、节点执行、状态流转和事件广播。引擎不感知具体业务逻辑。
|
||||
|
||||
## 当前状态
|
||||
|
||||
| 功能 | 状态 |
|
||||
|------|------|
|
||||
| DAG 数据结构 | ✅ 已实现 |
|
||||
| 拓扑排序 | ✅ 已实现 |
|
||||
| DagExecutor (顺序执行) | ✅ 已实现 |
|
||||
| 同层节点并行执行 | ⬜ 有 TODO 注释 |
|
||||
| Node trait 定义 | ✅ 已实现 |
|
||||
| 状态机 (WorkflowRunStatus) | ✅ 已实现 |
|
||||
| EventBus (broadcast) | ✅ 已实现 |
|
||||
| 条件表达式引擎 | ⚡ 仅支持 true/false |
|
||||
| 断点续跑 | ⬜ 待实施 |
|
||||
|
||||
## 核心设计
|
||||
|
||||
### Node trait
|
||||
|
||||
```rust
|
||||
pub trait Node: Send + Sync {
|
||||
fn execute(&self, ctx: &NodeContext) -> Result<NodeOutput>;
|
||||
fn schema(&self) -> NodeSchema;
|
||||
fn is_blocking(&self) -> bool { true }
|
||||
}
|
||||
```
|
||||
|
||||
### DAG 执行流程
|
||||
|
||||
```
|
||||
1. 接收 WorkflowDef (DAG 定义)
|
||||
2. 拓扑排序 → 得到执行层 (layers)
|
||||
3. 逐层执行:
|
||||
- 同层节点并行 (TODO)
|
||||
- 阻塞节点等待人工操作
|
||||
- 非阻塞节点异步完成
|
||||
4. 状态变更通过 EventBus 广播
|
||||
5. 每个节点完成后持久化快照
|
||||
```
|
||||
|
||||
### 事件类型
|
||||
|
||||
- `WorkflowStarted` / `WorkflowCompleted` / `WorkflowFailed`
|
||||
- `NodeStarted` / `NodeCompleted` / `NodeFailed`
|
||||
- `WorkflowPaused` / `WorkflowResumed`
|
||||
|
||||
## 依赖关系
|
||||
|
||||
```
|
||||
df-core (类型、事件、错误)
|
||||
← df-workflow
|
||||
← df-nodes (节点实现)
|
||||
← df-stages (阶段节点)
|
||||
```
|
||||
|
||||
## 文件结构
|
||||
|
||||
```
|
||||
crates/df-workflow/src/
|
||||
├── lib.rs — 模块入口
|
||||
├── dag.rs — DAG 数据结构与拓扑排序
|
||||
├── executor.rs — DagExecutor
|
||||
├── node.rs — Node trait + NodeContext/Output
|
||||
├── state.rs — 状态机
|
||||
├── event.rs — EventBus
|
||||
└── condition.rs — 条件表达式引擎
|
||||
```
|
||||
|
||||
## 相关文档
|
||||
|
||||
- [df-nodes 节点集合](./df-nodes-节点集合.md)
|
||||
- [Phase1 架构决策](../02-架构设计/Phase1架构决策.md)
|
||||
488
docs/03-模块文档/想法探索-对抗式评估.md
Normal file
488
docs/03-模块文档/想法探索-对抗式评估.md
Normal file
@@ -0,0 +1,488 @@
|
||||
# 想法探索模块 — 对抗式评估设计
|
||||
|
||||
> 创建: 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 字段。
|
||||
Reference in New Issue
Block a user