lxy/DevFlow
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

新增: 初始化 DevFlow 项目仓库

Browse Source 
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:
绝尘
2026-06-12 01:31:05 +08:00
commit 98393b4908
178 changed files with 27859 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

38
docs/01-技术文档/SQLite-CRUD模式.md Normal file
View File

@@ -0,0 +1,38 @@
# SQLite CRUD 模式
> 创建: 2026-06-10 | 状态: 初稿
---
## 概述
DevFlow 使用 SQLite (rusqlite) 作为本地存储引擎。df-storage 负责 SQLite 连接管理、Schema 迁移和 CRUD 操作。
## 当前状态
- SQLite 连接池: 已实现
- Schema 迁移 (6 张表 + 4 索引): 已实现
- CRUD 层: **待实施**
## 设计要点
### 待实施内容
1. **泛型 CRUD trait** — 定义统一的 `Repository<T>` 接口
2. **SQL 构建** — 参数化查询，防止 SQL 注入
3. **事务支持** — 跨表操作的原子性保证
4. **批量操作** — `insert_batch` / `update_batch`
5. **查询构建器** — 条件查询、分页、排序
### 约定
- ID 字段统一使用 `TEXT` (UUID v4)
- 时间字段使用 `INTEGER` (Unix timestamp)
- JSON 字段使用 `TEXT` 存储 JSON 字符串
- 所有写操作返回 `Result<(), df_core::error::Error>`
## 相关文件
- `crates/df-storage/src/lib.rs` — 存储层入口
- `crates/df-storage/src/schema.rs` — Schema 定义与迁移
- `crates/df-core/src/error.rs` — 统一错误类型

47
docs/01-技术文档/Tauri-IPC模式.md Normal file
View File

@@ -0,0 +1,47 @@
# Tauri IPC 模式
> 创建: 2026-06-10 | 状态: 初稿
---
## 概述
Tauri v2 的 IPC 机制是 DevFlow 前后端通信的核心桥梁。本文档描述 DevFlow 中 Tauri IPC 的设计模式。
## 当前状态
- Tauri Commands: 仅 `greet` 示例命令
- 业务 IPC: **待实施**
## 设计要点
### 待实施内容
1. **Command 定义** — 在 `src-tauri/src/commands/` 下按模块组织
2. **序列化约定** — Rust 结构体 derive `Serialize`/`Deserialize`
3. **错误传递** — `Result<T, String>` 返回给前端
4. **流式支持** — AI 输出、Shell 输出的流式推送
5. **状态注入** — 通过 `tauri::State` 共享 Rust 运行时状态
### IPC 层次
```
Vue Component
→ Pinia Store (Action)
→ @tauri-apps/api (invoke)
→ Tauri Command (Rust)
→ Crate 业务逻辑
→ df-storage (SQLite)
```
### 命名约定
- Rust command: `#[tauri::command] fn get_projects(...)`
- 前端调用: `invoke("get_projects", { ... })`
- Store action: `async fetchProjects()`
## 相关文件
- `src-tauri/src/main.rs` — Tauri 入口
- `src-tauri/src/commands/` — IPC 命令目录
- `frontend/src/stores/` — Pinia Store

46
docs/02-架构设计/Phase1架构决策.md Normal file
View File

@@ -0,0 +1,46 @@
# Phase 1 架构决策
> 创建: 2026-06-10 | 状态: 初稿
---
## 概述
Phase 1 是 DevFlow 的引擎骨架阶段，聚焦于核心数据流打通。本文记录此阶段的关键架构决策。
## 决策记录
### ADR-001: 引擎不绑定业务
- **决策**: Workflow Engine (df-workflow) 只做 DAG 执行，不感知具体业务语义
- **原因**: 保持引擎通用性，阶段逻辑通过 df-stages 插件化注入
- **影响**: df-workflow 的 Node trait 是纯接口，业务逻辑在 df-nodes / df-stages 实现
### ADR-002: 本地优先架构
- **决策**: 使用 SQLite 嵌入式数据库，不依赖云服务
- **原因**: DevFlow 定位为桌面工具，零运维，离线可用
- **影响**: 无网络层、无认证系统，数据全部本地存储
### ADR-003: 多 Crate Workspace
- **决策**: 拆分为 13 个独立 crate
- **原因**: 模块解耦、独立编译、按需引用
- **影响**: 依赖关系需严格管控，避免循环依赖
### ADR-004: 无 panic 原则
- **决策**: 所有占位代码返回空/默认值，不使用 `todo!`/`unimplemented!`
- **原因**: 保证应用不会因为未实现功能而崩溃
- **影响**: 未实现的方法返回 `Ok(default)` 而非 panic
### ADR-005: Phase 1 最小可用路径
- **决策**: 优先打通 `df-core → df-workflow → df-storage → Tauri IPC → Vue` 链路
- **原因**: 验证架构可行性，尽早发现集成问题
- **影响**: Phase 1 不实现 AI、想法池、多项目等高级功能
## 参考文档
- `ARCHITECTURE.md` — 完整架构设计
- `PROGRESS.md` — 当前进度与全局性问题

349
docs/02-架构设计/业务系统设计.md Normal file
View File

@@ -0,0 +1,349 @@
# DevFlow 业务系统设计
> 创建: 2026-06-10 | 状态: 设计中 | 基于: 功能审查结论
---
## 一、产品定位
| 维度 | 定义 |
|------|------|
| **一句话** | AI 原生的产研操作系统，从想法到上线的全流程编排 |
| **目标用户** | 个人开发者优先，后续扩展到小团队 |
| **核心价值** | 全流程编排 — 想法池 → 项目 → 任务 → 工作流 → 发布，AI 贯穿每个环节 |
| **差异化** | 想法第一公民 + AI 全程参与 + 本地优先（零运维） |
---
## 二、用户旅程设计
### 2.1 核心旅程
```
💡 想法池 📂 项目 🔀 任务 🚀 发布
─────────────────────────────────────────────────────────────────────────────────────
捕捉想法 ──→ AI评估评分 ──→ 晋升立项 ──→ 创建任务 ──→ 绑定分支 ──→ 执行工作流 ──→ 合并发布
│ │ │ │ │
└── 淘汰/归档 └── 多任务 └── DAG └── AI辅助 └── 自动化
并行推进 自动执行 冲突解决 发布流程
```
### 2.2 五个阶段详细设计
#### 阶段一：💡 想法池 (Idea Pool)
**用户场景**：开发者日常产生大量想法（看到新技术、遇到痛点、产生产品灵感），需要一个地方快速捕捉、评估、筛选。
| 操作 | 描述 | AI 参与 |
|------|------|---------|
| **捕捉** | 文本输入、快捷键快速记录、剪贴板导入 | 无 |
| **评估** | AI 分析可行性、市场潜力、技术难度 | ⭐ 核心场景：LLM 评估报告 |
| **评分** | 多维打分 (可行性/影响力/紧迫性) | AI 给出建议分 |
| **关联** | 相似想法自动发现，可合并 | AI 语义相似度 |
| **晋升** | 高分想法晋升为项目 | AI 生成项目初始化建议 |
| **淘汰** | 低分想法归档或删除 | 无 |
**状态机**：
```
Draft → Evaluating → Scored → Approved → Promoted
→ Rejected → Archived
```
**关键问题**：
- ✅ 想法是独立于项目的第一公民，不需要先有项目
- ✅ AI 评估是核心差异化功能
- ⚠️ 评分维度需要与实际对齐（当前有3套不同的维度定义）
#### 阶段二：📂 项目 (Project)
**用户场景**：从想法晋升或手动创建项目，管理项目全生命周期。
| 操作 | 描述 | AI 参与 |
|------|------|---------|
| **创建** | 从想法晋升 或 手动创建 | AI 生成项目描述/技术栈建议 |
| **阶段管理** | 5阶段管线：想法→需求→编码→测试→发布 | 阶段推进时 AI 检查前置条件 |
| **上下文** | 项目代码结构、依赖、规范 | AI 自动分析项目结构 |
| **暂停/恢复** | 项目可暂停后恢复 | 无 |
**状态机**：
```
Planning → InProgress → Testing → Releasing → Completed
→ Paused → InProgress (恢复)
→ Cancelled
```
**阶段管线**（current_stage，独立于 status）：
```
Idea → Requirement → Coding → Testing → Release
```
**关键问题**：
- ⚠️ 当前 `status`（项目生命周期）和 `current_stage`（当前阶段）是两个维度，前端混用了
- ⚠️ 数据库 projects 表缺少 `current_stage`、`repo_path`、`priority`、`tags` 字段
#### 阶段三：🔀 任务 (Task)
**用户场景**：项目内创建多个并行任务，每个任务绑定一个 Git 分支，独立工作流。
| 操作 | 描述 | AI 参与 |
|------|------|---------|
| **创建任务** | 标题+描述，自动创建分支 | AI 从需求拆解任务 |
| **绑定分支** | 每个任务一个独立分支 | 自动生成分支名 |
| **执行工作流** | 触发 DAG 工作流（编码→测试→审查） | AI 参与每个节点 |
| **审查** | 代码审查、质量检查 | AI 自动审查 |
| **合并** | 合并到主分支，冲突解决 | AI 辅助冲突解决 |
**状态机**：
```
Todo → InProgress → InReview → Testing → Done
→ Blocked → InProgress (解除阻塞)
→ Cancelled
```
**关键问题**：
- ⚠️ 缺少 `branches` 表，分支信息无法持久化
- ⚠️ 任务到工作流的关联 (`workflow_def_id`) 缺失
- ⚠️ 前端 TaskStatus 有 4 套不同的值
#### 阶段四：⚙️ 工作流 (Workflow)
**用户场景**：DAG 驱动的工作流自动执行，支持条件分支、并行、人工审批。
| 组件 | 描述 |
|------|------|
| **DAG 定义** | 可序列化的节点+边定义，持久化到 SQLite |
| **节点类型** | Script / AI / Docker / Git / HTTP / Human / Notify / Subflow |
| **执行器** | 按拓扑层并行执行，支持暂停/恢复 |
| **事件总线** | 实时推送节点状态到前端 |
| **NodeRegistry** | 根据类型字符串动态创建节点实例 |
**工作流执行生命周期**：
```
Pending → Running → Completed
→ Paused → Running (恢复)
→ Failed → Running (重试)
→ Cancelled
```
**关键问题**：
- ✅ DAG 拓扑排序算法正确
- ✅ DagDef/NodeRegistry 已实现
- ⚠️ Executor 同层节点尚未并行化
- ⚠️ 条件分支引擎未实现
- ⚠️ HumanNode（人工审批）暂停/恢复未连通
#### 阶段五：🚀 发布 (Release)
**用户场景**：选择多个已完成任务，编排发布流程。
| 操作 | 描述 | AI 参与 |
|------|------|---------|
| **选择任务** | 选择要发布的 Done 状态任务 | 无 |
| **创建发布** | 合并分支到 release 分支 | AI 生成 changelog |
| **集成测试** | 运行完整测试工作流 | 自动 |
| **发布** | 部署 + 健康检查 | 自动 |
| **回滚** | 发布失败回滚 | AI 分析失败原因 |
**状态机**：
```
Planning → Integrating → Testing → Ready → Published
→ RolledBack
→ Cancelled
```
**关键问题**：
- ⚠️ 前端完全缺少发布入口
- ⚠️ releases 表缺少 `branch_name`、`workflow_def_id`
---
## 三、跨领域功能设计
### 3.1 标注系统 (Annotation)
**设计理念**：任何内容（代码/文档/需求/测试报告）都可插入标注，统一收集后交给 AI 批量处理。
| 标记 | 含义 | AI 处理方式 |
|------|------|-----------|
| FIXME | 需要修复 | AI 定位问题并生成修复建议 |
| TODO | 待办 | AI 拆解为任务 |
| QUESTION | 疑问 | AI 尝试回答 |
| RISK | 风险 | AI 评估风险等级 |
| DECISION | 决策 | 自动记录到决策日志 |
| OPTIMIZE | 优化 | AI 给出优化方案 |
**批量处理流程**：
```
收集所有 Open 标注 → 按类型分组 → AI 逐条处理 → 标记为 Resolved
```
### 3.2 决策留痕 (Decision Journal)
**设计理念**：所有关键决策自动或半自动记录，全程可追溯。
**自动记录的决策场景**：
- 想法评估结果（为什么批准/拒绝）
- 功能标记为"不做"时（为什么不做）
- AI 选择了方案 A 而非方案 B 时
- 代码审查中发现风险时的处理决策
- 发布前的检查点决策
### 3.3 经验进化 (Evolution)
**设计理念**：开发过程自动沉淀知识，越用越聪明。
| 知识类型 | 来源 | 复用场景 |
|---------|------|---------|
| 审查规则 | 代码审查结论 | 后续审查自动应用 |
| Prompt 模板 | 成功的 AI 对话 | 类似场景复用 |
| 踩坑经验 | 错误修复过程 | 遇到类似问题时提醒 |
| 架构模式 | 项目结构分析 | 新项目初始化建议 |
### 3.4 AI 编排
**多模型策略**：
```
任务类型 → ModelRouter → 最优模型
代码生成 → Claude/GPT-4
代码审查 → Claude (长上下文)
文档生成 → GLM/DeepSeek (性价比)
快速问答 → DeepSeek (低成本)
```
**Agent 协作模式**（Phase 2+）：
```
Planner Agent → 拆解任务
Coder Agent → 编码实现
Reviewer Agent → 代码审查
Fixer Agent → 修复问题
```
---
## 四、数据模型设计（按阶段）
### Phase 1 最小表集（当前 + 补全）
| 表 | 用途 | 状态 |
|----|------|------|
| ideas | 想法池 | ✅ 已有，需补字段 |
| projects | 项目管理 | ✅ 已有，需补字段 |
| tasks | 任务管理 | ✅ 已有，需补字段 |
| releases | 发布管理 | ✅ 已有，需补字段 |
| workflow_defs | 工作流定义 | ❌ 缺失 |
| workflow_executions | 工作流执行 | ✅ 已有，需补字段 |
| node_executions | 节点执行记录 | ✅ 已有 |
| branches | 分支管理 | ❌ 缺失 |
### Phase 2 扩展表
| 表 | 用途 |
|----|------|
| ai_providers | AI 模型配置 |
| connections | 连接配置 |
| artifacts | 产出物 |
### Phase 3+ 完整表
| 表 | 用途 |
|----|------|
| annotations | 标注系统 |
| decisions | 决策留痕 |
| features | 需求功能清单 |
| test_cases | 测试用例 |
| test_runs | 测试执行记录 |
| knowledge | 经验知识库 |
| merge_requests | 合并请求 |
---
## 五、关键设计决策
### D1: 想法是第一公民
- 想法池独立于项目，可以独立运转
- 想法不需要关联项目即可被评估和打分
- 晋升是单向操作（想法→项目），但保留追溯
### D2: 多任务/分支并行
- 同一项目内多个任务同时开发
- 每个任务绑定独立 Git 分支
- 任务间互不干扰，完成后合并
### D3: 引擎不绑定业务
- DAG 引擎纯粹做编排，不知道"想法"/"项目"等概念
- 阶段是 DAG 模板，可自定义
- 节点通过 Node trait 扩展
### D4: 本地优先
- SQLite 嵌入，不依赖云服务
- 所有数据存储在本地
- 零运维，安装即用
### D5: AI 贯穿全程
- 不是"加了 AI 功能"，而是"AI 是系统的一部分"
- 每个阶段都有 AI 参与
- AI 输出作为决策依据，最终决策权在人
### D6: 决策必留痕
- 所有关键决策自动记录
- 决策可追溯到具体上下文（哪个想法、哪个功能、哪次审查）
- 未来可回溯"为什么这么做"
---
## 六、审查发现的设计问题与决策
| # | 问题 | 设计决策 | 优先级 |
|---|------|---------|--------|
| 1 | 状态枚举三套不一致 | **以 types.rs 为准**，ARCHITECTURE.md 和 SQL 同步 | Phase 1 |
| 2 | projects 缺 status vs stage | **status 和 current_stage 分开**：status 管生命周期，stage 管进度 | Phase 1 |
| 3 | ideas.promoted_to 缺失 | **V2 补字段**，晋升时回写 | Phase 1 |
| 4 | branches 表不存在 | **V2 新增表**，分支管理需要持久化 | Phase 1 |
| 5 | workflow_executions 缺 project_id | **V2 补字段**，执行记录必须关联业务 | Phase 1 |
| 6 | DAG 不可序列化 | **DagDef/Dag 分离**（已完成） | Phase 1 |
| 7 | Executor 串行 | **同层并行化**（待实现） | Phase 1 |
| 8 | 前端 id 类型不对 | **统一为 string (UUID)** | Phase 1 |
| 9 | Store 未接入 View | **先建 API 层再接 Store** | Phase 1 |
| 10 | 标注/决策表缺失 | Phase 3 再建表，当前 UI 标注 "Coming Soon" | Phase 3 |
| 11 | 需求-测试追溯 | Phase 4 再建表 | Phase 4 |
| 12 | 经验进化 | Phase 5 实现 | Phase 5 |
---
## 七、MVP 验证场景
**Phase 1 目标**：跑通"创建想法 → 晋升项目 → 创建任务 → 执行 3 节点工作流 → 查看结果"
```
1. 用户在想法池输入"做一个 Markdown 编辑器"
2. AI 评估可行性，给出评分和建议
3. 用户点击"晋升为项目"
4. 系统创建项目，进入编码阶段
5. 用户创建任务"实现基础编辑功能"
6. 系统创建分支 task/abc123
7. 用户点击"运行工作流"
8. DAG 执行: [Shell: 环境检查] → [Shell: 运行测试] → [Shell: 构建产物]
9. 前端实时展示执行日志
10. 执行完成，结果持久化到 SQLite
11. 用户刷新页面，数据仍在
```
---
## 八、已确认的设计决策
### Q1: 想法评分维度 ✅ 已确认
**决策**：采用 C 方案 — 可行性/影响力/紧迫性 + 综合分 (3+1 维)
- 与 `evaluator.rs` 已实现的 `EvalDimension` 对齐
- `IdeaScores { feasibility, impact, urgency, overall }` 保留
### Q2: 发布模块 Phase 1 范围 ✅ 已确认
**决策**：Phase 1 简化 — 只做 Release 记录 + 手动标记任务
- releases 表保留，支持 CRUD
- 不做自动化发布流程（合并→测试→部署）
- 前端在 ProjectDetail 中添加简单 Release 面板
### Q3: AI 评估 Phase 1 范围 ✅ 已确认
**决策**：Phase 1 用固定算法评分，延后接入 AI
- `ScoringEngine` 当前返回固定 5.0，改为基于启发式规则的简单算法
- Phase 2 接入 LLM 后替换为 AI 评分

145
docs/02-架构设计/产品定位调整.md Normal file
View File

@@ -0,0 +1,145 @@
# 产品定位调整报告
> 从"想法到代码"到"想法到创作"的升级转型
## 📊 背景分析
### 原定位的问题
- 过于狭窄：只面向开发者
- 竞争激烈：代码工具市场已饱和
- 限制场景：无法满足多元化的创作需求
### 新定位的优势
- **普适性强**：覆盖所有创作者
- **场景多样**：技术、商业、教育、创意
- **价值更大**：从单一工具到创作平台
## 🎯 新产品定位
### 核心价值主张
**"从想法到创作成果的全流程管理平台"**
### 目标用户画像
| 用户类型 | 创作内容 | 使用场景 |
|---------|---------|---------|
| **开发者** | 代码、技术文档 | 项目开发、技术分享 |
| **产品经理** | 需求文档、原型方案 | 产品规划、项目提案 |
| **设计师** | 设计方案、创意文档 | 设计展示、概念提案 |
| **研究者** | 学术论文、分析报告 | 研究、报告撰写 |
| **内容创作者** | 博客、课程、培训 | 知识分享、教育 |
### 核心功能矩阵
| 功能模块 | 代码创作 | 文档创作 | 演示创作 | 内容创作 |
|---------|---------|---------|---------|---------|
| **想法池** | ✓ | ✓ | ✓ | ✓ |
| **对抗评估** | ✓ | ✓ | ✓ | ✓ |
| **任务管理** | ✓ | ✓ | ✓ | ✓ |
| **工作流引擎** | ✓ | ✓ | ✓ | ✓ |
| **模板系统** | ✓ | ✓ | ✓ | ✓ |
| **协作功能** | ✓ | ✓ | ✓ | ✓ |
## 🔄 功能升级规划
### Phase 1: 基础创作支持
- [x] 代码创作（现有）
- [ ] Markdown 文档编辑器
- [ ] PPT 演示文稿生成器
- [ ] 文档模板库
### Phase 2: 智能创作辅助
- [ ] AI 内容生成
- [ ] 自动格式化
- [ ] 多格式导出
- [ ] 版本管理
### Phase 3: 创作生态
- [ ] 创作市场
- [ ] 团队协作
- [ ] 知识库集成
- [ ] 发布平台
## 📈 产品差异化
### 竞争优势
1. **全流程覆盖**：从想法到发布
2. **对抗式评估**：独特的质量控制机制
3. **本地优先**：数据安全、隐私保护
4. **跨平台支持**：桌面端 + Web 端
### 差异化场景
- **学术研究**：论文写作 + 代码实现
- **产品设计**：需求文档 + 原型设计
- **技术培训**：课程内容 + 示例代码
- **创意策划**：概念方案 + 可视化展示
## 🎨 视觉识别调整
### 品牌口号
- **原**："本地优先的开发流程工具"
- **新**："创意工作流的私人助手"
### 颜色系统
保持现有的紫色系作为主色，增加：
- 橙色：创意和活力
- 绿色：成长和产出
- 蓝色：专业和可靠
### 图标体系
- 🧠 思维导图
- ✍️ 创作工具
- 📊 产出展示
- 🚀 发布分享
## 📋 实施计划
### 短期（1个月）
- 更新文档和营销材料
- 完成文档创作基础功能
- 发布 V2.0 版本
### 中期（3个月）
- 完成演示文稿生成器
- 实现模板系统
- 上线创作市场 Beta
### 长期（6个月）
- 建立创作者生态
- 集成协作功能
- 考虑 SaaS 服务
## 🎯 成功指标
### 用户增长
- 月活跃用户：1000+
- 创作者留存率：>60%
- 日均创作次数：>3/用户
### 内容质量
- 作品发布率：>40%
- 用户满意度：>4.5/5
- 重复使用率：>50%
### 业务指标
- 付费转化率：>5%
- 平均客单价：$50
- 年营收目标：$100K
## 🔮 未来展望
### 5年愿景
成为**创作者的首选工作平台**，连接想法与世界的桥梁。
### 技术演进
- AI 驱动的智能创作
- 虚拟现实创作空间
- 区块链确权和版权保护
### 社会价值
- 降低创作门槛
- 促进知识分享
- 支持创意经济
---
**总结**：从"想法到代码"到"想法到创作"不是功能减少，而是价值升级。我们不再局限于技术工具，而是成为所有创作者的伙伴。

82
docs/02-架构设计/前后端类型对齐.md Normal file
View File

@@ -0,0 +1,82 @@
# 前后端类型对齐
> 创建: 2026-06-10 | 状态: 初稿
---
## 概述
DevFlow 前端 (TypeScript) 和后端 (Rust) 通过 Tauri IPC 和 JSON 序列化通信。两侧的类型定义必须保持一致。
## 类型映射
### 基础类型
| Rust | TypeScript | 说明 |
|------|-----------|------|
| `String` | `string` | 文本字段 |
| `i64` | `number` | 时间戳 (Unix timestamp) |
| `Option<String>` | `string \| null` | 可空字段 |
| `Vec<String>` | `string[]` | 数组 (JSON 序列化) |
| `bool` | `boolean` | 布尔值 |
### ID 类型
| 实体 | Rust | TypeScript | 格式 |
|------|------|-----------|------|
| 所有 ID | `String` | `string` | UUID v4 |
所有 ID 统一使用 UUID v4 字符串，便于前后端传递。
### 枚举对齐
#### IdeaStatus (8 值)
| Rust | TypeScript |
|------|-----------|
| `Draft` | `"Draft"` |
| `Evaluating` | `"Evaluating"` |
| `Scored` | `"Scored"` |
| `Hot` | `"Hot"` |
| `Promoted` | `"Promoted"` |
| `Parked` | `"Parked"` |
| `Merged` | `"Merged"` |
| `Discarded` | `"Discarded"` |
#### TaskStatus (6 值)
| Rust | TypeScript |
|------|-----------|
| `Created` | `"Created"` |
| `BranchCreated` | `"BranchCreated"` |
| `InProgress` | `"InProgress"` |
| `ReviewReady` | `"ReviewReady"` |
| `Merged` | `"Merged"` |
| `Abandoned` | `"Abandoned"` |
#### WorkflowRunStatus (6 值)
| Rust | TypeScript |
|------|-----------|
| `Pending` | `"Pending"` |
| `Running` | `"Running"` |
| `Paused` | `"Paused"` |
| `Completed` | `"Completed"` |
| `Failed` | `"Failed"` |
| `Cancelled` | `"Cancelled"` |
#### ProjectStatus (4 值)
| Rust | TypeScript |
|------|-----------|
| `Active` | `"Active"` |
| `Paused` | `"Paused"` |
| `Completed` | `"Completed"` |
| `Archived` | `"Archived"` |
## 约定
1. 枚举值使用 PascalCase 字符串，前后端保持一致
2. JSON 字段（如 `scores`、`tags`）在 Rust 侧用 `TEXT` 存储 JSON 字符串，前端解析为对象/数组
3. 时间字段统一用 `i64` (Unix timestamp)，前端用 `new Date(ts * 1000)` 转换
4. 新增枚举值时，Rust 和 TypeScript 两侧必须同步更新

143
docs/02-架构设计/对抗论证裁决报告.md Normal file
View File

@@ -0,0 +1,143 @@
# DevFlow 对抗论证裁决报告
> 创建: 2026-06-11 | 方法: 三路对抗论证（市场/技术/需求） | 结论: 方向有价值，scope 必须砍
---
## 一、论证方法
用"魔法打败魔法"：三个独立 AI 代理分别从不同立场攻击这个项目，互不可见，最后综合裁决。
| 代理 | 立场 | 综合评分 |
|------|------|---------|
| 市场分析师 | 竞品全景 + 市场数据（带外部信源） | **4/10 — 不建议以当前形态推进** |
| 技术架构师 | 13 crate / Tauri / 引擎 / AI 可行性 | **2.7/5 — 可行但必须砍 scope** |
| 恶魔代言人 | 逐功能质疑需求真实性 | **核心成立，60% 功能该砍** |
---
## 二、三方共识（站不住脚的地方）
### 共识 1：🔴 Scope 失控是最大风险
- 8 个核心功能横跨 4-5 个产品类别（PM + 工作流 + AI 编排 + 代码分析 + 知识库）
- 22,745 字架构文档、16 张表、13 crate —— **这是操作系统的野心，不是 MVP 的规划**
- 现实工时：v1.0 全功能需全职 8-12 个月 / 业余 1.5-2 年
- 历史教训：Firebase/Heroku/全生命周期 API 平台都被"组件化组合"打败
### 共识 2：🔴 身份危机 — 无法一句话说清
- Cursor = "AI 编辑器"，Linear = "快的 issue 追踪器"，DevFlow = ？
- "全流程"不是定位，是定位的缺失
### 共识 3：🔴 部分功能是伪需求（对个人开发者）
| 功能 | 需求方评分 | 市场方评分 | 裁决 |
|------|-----------|-----------|------|
| 插件系统 (WASM) | 1/5 | — | **砍掉**（为 0 个用户设计生态） |
| 经验进化（自动沉淀） | 1/5 | 3/10 | **砍掉**（技术上无法落地，连骨架都是空的） |
| 需求-测试追溯 | 1/5 | — | **砍掉**（企业需求硬塞给个人） |
| 多模型路由 + Agent 协作 | — | 4/10 | **砍掉**（OpenClaw/大厂赛道，无法竞争） |
| 想法池（完整版） | 2/5 | 2/10 | **降级**（简化为列表+对抗式评估） |
| 决策留痕（独立子系统） | 2/5 | 4/10 | **降级**（字段级方案，不建独立体系） |
### 共识 4：🟡 AI 信任危机的时代背景
- Stack Overflow 2025：开发者对 AI 信任度从 40% 跌至 29%
- 66% 开发者花更多时间修复 AI 的"差不多对"代码
- **定位必须从"AI 帮你做事"转向"AI 帮你控制流程"**——AI 是副驾驶，不是自动驾驶
---
## 三、三方冲突点的调和
### 冲突 1：DAG 工作流引擎
- 需求方：**5/5 必须有**（产品的灵魂，本地工作流有空白）
- 市场方：**2/10 伪需求**（GitHub Actions 已免费解决）
**裁决**：两者都对，但说的是不同的东西。
- GitHub Actions 解决的是 **仓库内 CI/CD**（push 触发、云端跑）
- DevFlow 的空隙是 **本地的、跨项目的、AI 参与的交互式流程**（不依赖 push、可以有人工审批节点、能调用本地资源）
- **保留 DAG 引擎，但作为内部基础设施，不作为对外卖点**。用户看到的是"一键执行编码→审查→测试流程"，而不是"DAG 编辑器"
### 冲突 2：标注系统
- 需求方：**1/5 砍掉**（IDE 已解决）
- 市场方：**6.5/10 全场最高差异化机会**（"扫描代码库 FIXME/TODO → AI 批量处理 → 关联任务"是真空地带）
**裁决**：需求方批的是"在文档/测试报告上加标注"的重模式（确实没人用）；市场方挺的是"代码库 TODO 扫描器 + AI 处理"的轻模式。
- **采用轻模式**：扫描代码 TODO/FIXME → 汇总 → AI 生成处理建议 → 一键转任务
- 砍掉"任意实体标注"的重设计
---
## 四、站得住脚的部分
1. **本地优先** — Obsidian 证明了本地优先工具有大市场，订阅疲劳（52% 用户因此退订）反推一次性付费
2. **Tauri 技术栈** — 比 Electron 小 96%，选型正确（4/5）
3. **引擎代码质量** — 拓扑排序算法正确、trait 设计合理、依赖树无环
4. **任务绑 Git 分支** — 6/10，最有价值的业务功能，做深"任务→分支→提交→合并→关单"全链路有空间
5. **对抗式想法评估** — 这是本次论证方法本身的产品化，市场上没有工具这么做
---
## 五、调整方案
### 5.1 产品定位调整
**旧**：AI 原生的产研操作系统，从想法到上线的全流程编排（❌ 无法一句话说清）
**新**：**本地优先的个人开发流程驾驶舱 — 把想法、任务、分支和 AI 流程放进一个不联网也能跑的桌面应用**
一句话版本：「你的项目流程，本地跑，AI 辅助，数据不出门」
### 5.2 功能调整清单
| 功能 | 原计划 | 调整后 |
|------|--------|--------|
| DAG 工作流引擎 | 对外核心卖点 | ✅ 保留为内部引擎，UI 上呈现为"流程模板一键执行" |
| 任务+分支 | 一般功能 | ✅ **升级为核心**：任务→分支→工作流→合并全链路 |
| 想法池 | 完整漏斗系统 | ⬇️ 简化：列表 + **对抗式评估**（正方/反方/分析师三路论证，差异化卖点） |
| 标注系统 | 任意实体标注 | ⬇️ 简化：代码库 TODO/FIXME 扫描器 + AI 批处理 |
| 决策留痕 | 独立子系统 | ⬇️ 降级：关键操作自动写决策字段，无独立 UI |
| AI 编排 | 多模型路由+四 Agent | ⬇️ 砍：单 Provider (Claude) + AI 节点，无 Agent 协作 |
| 阶段插件 | 5 阶段 | ⬇️ 3 个内置流程模板（编码/测试/发布） |
| 8 种节点 | 全部实现 | ⬇️ Phase 1 只做 Shell/AI/Subflow，Git 用 Shell 调 CLI |
| 需求-测试追溯 | 完整体系 | ❌ 砍掉（v2.0 团队版再说） |
| 经验进化 | 自动沉淀引擎 | ❌ 砍掉（降为手动 Snippet 收藏，Phase 5 再议） |
| 插件系统 | WASM/动态加载 | ❌ 砍掉（v2.0 再说） |
**砍掉比例：约 60%，与三方建议一致。**
### 5.3 架构调整
- **13 crate 保留目录结构**（已建好，删除反而费工），但 Phase 1 只激活 6 个：
`df-core / df-workflow / df-storage / df-execute / df-nodes / src-tauri`
- 其余 7 个 crate 标记为 `[预留]`，从 workspace 默认构建中保留但不再投入开发
- Git 操作走 Shell CLI，不引入 libgit2（技术报告建议，省 1-2 周）
### 5.4 Phase 重排
| Phase | 旧目标 | 新目标 |
|-------|--------|--------|
| 1 | 引擎骨架（含一切基础） | **跑通一条 Shell→AI→Shell 工作流 + 任务/分支 CRUD + 前端真数据** |
| 2 | AI 集成（多模型） | Claude 单 Provider + AI 节点 + 想法对抗式评估 |
| 3 | 想法池+多项目 | TODO 扫描器 + 3 个流程模板 |
| 4 | 节点丰富+阶段插件 | 任务→分支→合并全链路（Git 深度集成） |
| 5 | 体验打磨 v1.0 | 打磨 + 自用验证 3 个月 → 决定是否对外 |
### 5.5 验证策略调整
市场报告的最重要建议：**先验证再深投**。
- DevFlow 首先是**自用工具**（管理 wk-* 工作空间的真实项目）
- 自用 3 个月，记录每天真实打开次数
- 如果自己都不用，停止投入；如果离不开它，再考虑对外
---
## 六、裁决结论
> **方向有价值，形态要收敛。** "本地优先 + 任务分支驱动 + AI 辅助流程"是真空隙；"全流程操作系统"是幻觉。砍掉 60% 的功能不是失败，是论证的胜利——它们本来会消耗 6-9 个月却没人用。
>
> 同时，本次论证方法本身（三路对抗）被产品化为想法池的"对抗式评估"功能，详见 `docs/03-模块文档/想法探索-对抗式评估.md`。这是 DevFlow 吃自己的狗粮的第一个案例。

298
docs/03-模块文档/df-ai-AI集成模块.md Normal file
View 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
View 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
View 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
View 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
View 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 字段。

37
docs/04-功能迭代/DEVFLOW-1.CRUD层实施.md Normal file
View File

@@ -0,0 +1,37 @@
# DEVFLOW-1 CRUD 层实施
> 创建: 2026-06-10 | 状态: 待实施
---
## 概述
为 df-storage 实现完整的 CRUD 操作层，使所有 crate 能够持久化数据。这是 Phase 1 的首要任务，所有后续功能的前置条件。
## 目标
- [ ] 定义泛型 `Repository<T>` trait
- [ ] 实现 ideas 表 CRUD
- [ ] 实现 projects 表 CRUD
- [ ] 实现 tasks 表 CRUD
- [ ] 实现 workflow_defs 表 CRUD
- [ ] 实现 workflow_runs 表 CRUD
- [ ] 实现 artifacts 表 CRUD
- [ ] 事务支持
- [ ] 单元测试
## 实施记录
*(待填写)*
## 变更文件
*(待填写)*
## 遗留问题
*(待填写)*
## 下一步
*(待填写)*

35
docs/04-功能迭代/DEVFLOW-2.IPC桥接实施.md Normal file
View File

@@ -0,0 +1,35 @@
# DEVFLOW-2 IPC 桥接实施
> 创建: 2026-06-10 | 状态: 待实施
---
## 概述
建立 Tauri IPC 命令层，将 Rust 后端业务逻辑暴露给 Vue 前端。依赖 DEVFLOW-1 (CRUD 层) 完成。
## 目标
- [ ] 按 CRUD 模块组织 commands 目录结构
- [ ] 实现 projects 相关 commands
- [ ] 实现 tasks 相关 commands
- [ ] 实现 workflow 相关 commands
- [ ] 统一错误处理 (Rust Error → 前端字符串)
- [ ] 状态注入 (AppState)
- [ ] 前端 invoke 封装
## 实施记录
*(待填写)*
## 变更文件
*(待填写)*
## 遗留问题
*(待填写)*
## 下一步
*(待填写)*

35
docs/04-功能迭代/DEVFLOW-3.Store对接实施.md Normal file
View File

@@ -0,0 +1,35 @@
# DEVFLOW-3 Store 对接实施
> 创建: 2026-06-10 | 状态: 待实施
---
## 概述
将 Vue 前端的硬编码数据替换为 Pinia Store，通过 Tauri IPC 连接真实后端数据。依赖 DEVFLOW-2 (IPC 桥接) 完成。
## 目标
- [ ] Store 添加 async actions (调用 invoke)
- [ ] ProjectsView 接入 projectStore
- [ ] TasksView 接入 taskStore
- [ ] WorkflowView 接入 workflowStore
- [ ] IdeasView 接入 ideaStore (如有)
- [ ] 加载状态 / 错误状态 UI 处理
- [ ] 按钮事件绑定真实操作
## 实施记录
*(待填写)*
## 变更文件
*(待填写)*
## 遗留问题
*(待填写)*
## 下一步
*(待填写)*

41
docs/04-功能迭代/DEVFLOW-4.端到端验证.md Normal file
View File

@@ -0,0 +1,41 @@
# DEVFLOW-4 端到端验证
> 创建: 2026-06-10 | 状态: 待实施
---
## 概述
端到端验证 Phase 1 骨架：在 DevFlow 中跑通一个 3 节点的简单工作流。依赖 DEVFLOW-1/2/3 全部完成。
## 验证目标
- [ ] 创建项目 → SQLite 持久化 → 前端显示
- [ ] 创建任务 → 绑定工作流 → 前端显示
- [ ] 启动工作流 → 3 节点顺序执行 → 状态实时更新到前端
- [ ] 工作流完成 → 产出物记录 → 前端查看
## 验证工作流设计
```
3 节点简单工作流:
ScriptNode (echo "start")
→ ScriptNode (echo "processing")
→ ScriptNode (echo "done")
```
## 实施记录
*(待填写)*
## 变更文件
*(待填写)*
## 遗留问题
*(待填写)*
## 下一步
*(待填写)*

97
docs/06-前端开发/View改造指南.md Normal file
View File

@@ -0,0 +1,97 @@
# View 改造指南 — 硬编码到 Store 对接
> 创建: 2026-06-10 | 状态: 初稿
---
## 概述
当前所有 Vue 页面使用硬编码数据 (`ref([...])`)，Pinia Store 和 View 完全独立。本文档指导如何将 View 改造为通过 Store → IPC 获取真实数据。
## 当前问题
1. **数据硬编码** — 每个 View 用 `ref([...])` 定义假数据
2. **Store 未接入** — Pinia Store 有 state/getter 但无 action
3. **事件处理空函数** — 按钮点击绑定 `() => {}`
4. **Arco Design 未使用** — 仅 CSS 变量覆盖，未引入组件
## 改造步骤
### Step 1: Store 添加 Actions
```typescript
// stores/projectStore.ts
import { invoke } from '@tauri-apps/api/core'
export const useProjectStore = defineStore('project', () => {
const projects = ref<Project[]>([])
// 新增 action
async function fetchProjects() {
projects.value = await invoke<Project[]>('get_projects')
}
async function createProject(input: CreateProjectInput) {
const project = await invoke<Project>('create_project', { input })
projects.value.push(project)
}
return { projects, fetchProjects, createProject }
})
```
### Step 2: View 接入 Store
```typescript
// views/ProjectsView.vue — 改造前
const projects = ref([
{ id: '1', name: '项目A', ... }, // 硬编码
])
// views/ProjectsView.vue — 改造后
const store = useProjectStore()
const { projects } = storeToRefs(store)
onMounted(() => {
store.fetchProjects()
})
```
### Step 3: 事件绑定真实操作
```typescript
// 改造前
const handleCreate = () => {}
// 改造后
const handleCreate = async () => {
await store.createProject(form)
modalVisible.value = false
}
```
### Step 4: 加载与错误状态
```vue
<template>
<a-spin :loading="store.loading">
<!-- 内容 -->
</a-spin>
</template>
```
## 涉及页面
| 页面 | Store | 改造优先级 |
|------|-------|-----------|
| ProjectsView | projectStore | P0 |
| TasksView | taskStore | P0 |
| WorkflowView | workflowStore | P0 |
| IdeasView | ideaStore | P1 |
| DashboardView | 多个 Store | P2 |
## 相关文档
- [Tauri IPC 模式](../01-技术文档/Tauri-IPC模式.md)
- [前后端类型对齐](../02-架构设计/前后端类型对齐.md)
- [DEVFLOW-3 Store 对接实施](../04-功能迭代/DEVFLOW-3.Store对接实施.md)

65
docs/07-项目管理/Phase1任务清单.md Normal file
View File

@@ -0,0 +1,65 @@
# Phase 1 任务清单
> 创建: 2026-06-10 | 状态: 进行中
---
## 概述
Phase 1 目标：**引擎骨架**，打通 `df-core → df-workflow → df-storage → Tauri IPC → Vue` 最小可用路径。
预计周期：4-6 周
## 任务总览
### 已完成
| # | 任务 | 状态 | 说明 |
|---|------|------|------|
| 1 | df-core 类型系统 | ✅ 完成 | 错误/事件/状态枚举/ID 生成 |
| 2 | df-workflow DAG 引擎 | ✅ 完成 | 拓扑排序/执行器/状态机/EventBus |
| 3 | df-storage SQLite 基础表 | ✅ 完成 | 6 张表 + 4 索引 |
| 4 | df-execute Shell 执行 | ✅ 完成 | tokio::process 实现 |
| 5 | 13 个 Crate 骨架 | ✅ 完成 | 类型/接口/Schame 定义完整 |
| 6 | 9 个 Vue 页面 UI | ✅ 完成 | 设计系统 + 硬编码数据 |
### 待实施 (按优先级排序)
| # | 任务 | 优先级 | 依赖 | 文档 |
|---|------|--------|------|------|
| 7 | df-storage CRUD 层 | P0 | 无 | [DEVFLOW-1](../04-功能迭代/DEVFLOW-1.CRUD层实施.md) |
| 8 | Tauri IPC 命令层 | P0 | #7 | [DEVFLOW-2](../04-功能迭代/DEVFLOW-2.IPC桥接实施.md) |
| 9 | Store 接入 View | P0 | #8 | [DEVFLOW-3](../04-功能迭代/DEVFLOW-3.Store对接实施.md) |
| 10 | 端到端验证 (3 节点工作流) | P0 | #7, #8, #9 | [DEVFLOW-4](../04-功能迭代/DEVFLOW-4.端到端验证.md) |
| 11 | 首次 Git Commit | P0 | 无 | 建立版本基线 |
### 已知问题
| # | 问题 | 优先级 | 说明 |
|---|------|--------|------|
| 1 | 同层节点未并行执行 | P1 | DagExecutor 有 TODO 注释 |
| 2 | 条件表达式引擎 | P2 | 仅支持 true/false 字面量 |
| 3 | i18n 未注册 | P2 | 翻译文件存在但未挂载 |
| 4 | AI Provider 无实现 | P1 | Phase 2 任务 |
## 依赖关系
```
#7 CRUD 层 ──→ #8 IPC 桥接 ──→ #9 Store 对接 ──→ #10 端到端验证
↑
#7 + #8 + #9
```
## 代码规模 (当前)
| 类别 | 文件数 | 行数 |
|------|--------|------|
| Rust 后端 | 71 | ~4,108 |
| Vue 前端 | ~20 | ~3,896 |
| **总计** | ~91 | **~8,000** |
## 参考文档
- [ARCHITECTURE.md](../../ARCHITECTURE.md) — 完整架构设计
- [PROGRESS.md](../../PROGRESS.md) — 工作进展与交接
- [Phase1 架构决策](../02-架构设计/Phase1架构决策.md)

108
docs/07-项目管理/Phase2计划.md Normal file
View File

@@ -0,0 +1,108 @@
# Phase 2 开发计划
> 本地优先开发流程验证 - 2026-06-11 至 2026-09-11
## 🎯 阶段目标
### 核心目标
- **验证核心价值链**：任务→分支→工作流→合并的完整流程
- **自用验证 3 个月**：每天使用，记录真实场景
- **聚焦差异化**：对抗式评估作为核心卖点
### 成功标准
- 自己每天都在用
- 解决实际问题
- 流程顺畅无卡点
## 📋 任务清单
### Phase 2.1: 核心链路验证 (2周)
- [x] 验证任务创建和分支管理
- [x] 验证工作流执行和日志
- [x] 验证 Git 集成
- [x] 验证 AI Chat 功能
### Phase 2.2: 想法池完善 (3周)
- [ ] 基础 CRUD 功能
- [ ] 简单评分系统
- [ ] 标签和分类
- [ ] 搜索和过滤
### Phase 2.3: 对抗式评估 (4周)
- [ ] 正方观点生成
- [ ] 反方观点生成
- [ ] 分析师综合分析
- [ ] 评估报告生成
### Phase 2.4: 工作流增强 (3周)
- [ ] 自定义工作流编辑器
- [ ] 更多节点类型
- [ ] 条件分支支持
- [ ] 并行执行优化
## 🔄 优先级排序
### P0 - 必须完成
1. **核心链路验证**：确保基本流程可用
2. **自用记录**：每天使用日志
3. **对抗式评估 MVP**：基础三路论证
### P1 - 重要功能
1. **想法池基础功能**：记录和管理想法
2. **工作流自定义**：支持简单自定义
3. **UI/UX 优化**：提升用户体验
### P2 - 可选增强
1. **团队协作**：多用户支持
2. **数据导出**：备份和分享
3. **插件系统**：扩展功能
## 📊 关键指标
### 使用指标
- **日活用户**：至少自己每天使用
- **任务完成率**：> 80% 任务按计划完成
- **工作流成功率**：> 90% 自动执行成功
### 质量指标
- **响应时间**：< 1s（本地操作）
- **错误率**：< 5%
- **用户满意度**：自用评分 > 4/5
## 🚀 交付物
### 阶段性成果
1. **第1个月**：核心功能可用，开始自用
2. **第2个月**：想法池 + 对抗评估完善
3. **第3个月**：工作流增强，评估是否对外
### 最终交付
- 可用的 DevFlow 应用
- 3 个月使用报告
- 产品定位调整建议
## 🎯 风险与应对
### 主要风险
1. **自用动力不足**
- 应对：设置使用提醒
- 应对：建立使用习惯
2. **功能过于复杂**
- 应对：保持极简原则
- 应对：砍掉非核心功能
3. **技术债务累积**
- 应对：定期重构
- 应对：单元测试覆盖
### 成功退出条件
如果满足以下条件，可以开始考虑对外发布：
- 连续 3 个月每天使用
- 核心功能无重大 Bug
- 对抗式评估效果显著
- 明确的产品差异化
---
**回顾**: Phase 1 已完成基础架构，Phase 2 专注于验证价值

716
docs/08-用户指南/使用手册.html Normal file
View File

@@ -0,0 +1,716 @@
<!DOCTYPE html>
<html lang="zh-CN">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width,initial-scale=1">
<title>DevFlow 使用手册</title>
<style>
/* DevFlow Design System */
:root {
/* — Surface — */
--df-bg: #0c0e1a;
--df-bg-raised: #12152a;
--df-bg-card: #171b33;
--df-bg-card-hover: #1c2140;
--df-sidebar-bg: #090b15;
/* — Text — */
--df-text: #eef0f6;
--df-text-secondary: #8b90a8;
--df-text-dim: #4a4f6a;
/* — Accent: 紫色系 — */
--df-accent: #7b6ff0;
--df-accent-hover: #6a5de0;
--df-accent-soft: rgba(123,111,240,0.15);
--df-accent-bg: rgba(123,111,240,0.08);
/* — Semantic — */
--df-success: #3ddba0;
--df-success-bg: rgba(61,219,160,0.12);
--df-warning: #f0c75e;
--df-warning-bg: rgba(240,199,94,0.12);
--df-danger: #f06565;
--df-danger-bg: rgba(240,101,101,0.12);
--df-info: #5eaff0;
--df-info-bg: rgba(94,175,240,0.12);
/* — Border — */
--df-border: rgba(255,255,255,0.06);
--df-border-strong: rgba(255,255,255,0.10);
/* — Radius — */
--df-radius-sm: 6px;
--df-radius: 8px;
--df-radius-lg: 12px;
}
/* 页面样式 */
body {
padding: 2rem;
max-width: 768px;
margin: 0 auto;
background: var(--df-bg);
color: var(--df-text);
font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
line-height: 1.7;
}
/* 按钮样式 */
.btn {
padding: 8px 16px;
border: none;
border-radius: var(--df-radius);
font-size: 13px;
cursor: pointer;
transition: all 0.15s;
}
.btn-primary {
background: var(--df-accent);
color: #fff;
}
.btn-primary:hover {
background: var(--df-accent-hover);
}
/* 卡片样式 */
.card {
background: var(--df-bg-card);
border: 0.5px solid var(--df-border);
border-radius: var(--df-radius-lg);
padding: 1.5rem;
margin-bottom: 1.5rem;
}
/* 标题样式 */
h1 {
font-size: 28px;
font-weight: 500;
color: var(--df-text);
margin: 0 0 0.5rem;
}
h2 {
font-size: 20px;
font-weight: 500;
color: var(--df-text);
margin: 0 0 0.75rem;
}
h3 {
font-size: 16px;
font-weight: 500;
color: var(--df-text);
margin: 0 0 0.5rem;
}
p {
font-size: 14px;
color: var(--df-text-secondary);
margin: 0 0 1rem;
line-height: 1.6;
}
/* 小标题 */
.section-title {
font-size: 12px;
font-weight: 500;
color: var(--df-text-dim);
letter-spacing: 0.05em;
text-transform: uppercase;
margin: 0 0 1rem;
}
/* 特性卡片 */
.feature-row {
display: flex;
align-items: flex-start;
gap: 12px;
margin-bottom: 1rem;
}
.feature-icon {
font-size: 20px;
flex-shrink: 0;
margin-top: 2px;
}
.feature-text {
font-size: 14px;
color: var(--df-text-secondary);
line-height: 1.6;
}
.feature-text strong {
color: var(--df-text);
font-weight: 500;
}
/* 按钮样式 */
.btn-demo {
background: transparent;
border: 0.5px solid var(--df-border);
border-radius: var(--df-radius);
padding: 8px 16px;
font-size: 13px;
cursor: pointer;
color: var(--df-text);
transition: background 0.15s;
margin-top: 1rem;
}
.btn-demo:hover {
background: var(--df-bg-raised);
}
/* 代码块 */
code {
font-family: 'SF Mono', Monaco, 'Cascadia Code', monospace;
font-size: 12px;
background: var(--df-bg-raised);
padding: 2px 6px;
border-radius: 4px;
color: var(--df-accent);
}
/* 主题切换 */
.theme-toggle {
position: fixed;
top: 1rem;
right: 1rem;
background: var(--df-bg-card);
border: 0.5px solid var(--df-border);
border-radius: var(--df-radius);
padding: 8px;
cursor: pointer;
color: var(--df-text-secondary);
transition: all 0.15s;
z-index: 100;
}
.theme-toggle:hover {
background: var(--df-bg-raised);
color: var(--df-text);
}
/* 标签 */
.tag {
display: inline-block;
padding: 2px 8px;
border-radius: var(--df-radius-sm);
font-size: 11px;
font-weight: 500;
margin-left: 0.5rem;
}
.tag-purple {
background: var(--df-accent-bg);
color: var(--df-accent);
}
.tag-teal {
background: var(--df-success-bg);
color: var(--df-success);
}
.tag-amber {
background: var(--df-warning-bg);
color: var(--df-warning);
}
.tag-coral {
background: var(--df-danger-bg);
color: var(--df-danger);
}
/* 流程演示 */
.flow-demo {
background: var(--df-bg-raised);
border: 0.5px solid var(--df-border);
border-radius: var(--df-radius);
padding: 1rem;
margin: 1rem 0;
}
/* 响应式 */
@media (max-width: 640px) {
body {
padding: 1rem;
}
h1 {
font-size: 24px;
}
h2 {
font-size: 18px;
}
}
/* 代码块容器 */
.code-block {
background: var(--df-bg-raised);
border: 0.5px solid var(--df-border);
border-radius: var(--df-radius);
padding: 1rem;
margin: 1rem 0;
overflow-x: auto;
}
.code-block pre {
margin: 0;
font-size: 12px;
color: var(--df-text);
}
.code-block code {
background: none;
padding: 0;
color: inherit;
}
</style>
</head>
<body>
<button class="theme-toggle" id="themeToggle" title="切换主题">
<i class="ti ti-moon"></i>
</button>
<h1>🚀 DevFlow 使用手册</h1>
<p style="margin-bottom: 2rem">"本地优先的个人创作流程驾驶舱"</p>
<!-- Mermaid 流程图 -->
<div class="flow-demo">
<h3 style="font-size: 14px; margin-bottom: 1rem;">核心流程</h3>
<div style="text-align: center; margin-bottom: 1rem;">
<p style="font-size: 12px; color: var(--df-text-dim); margin-bottom: 0.5rem;">想法到创作成果的完整链路</p>
</div>
<div class="code-block">
<pre><code>想法池 → 对抗评估 → 创作（代码/文档/PPT） → 发布/分享</code>
</pre>
</div>
<div style="display: flex; justify-content: center; gap: 1rem; margin-top: 1rem;">
<span class="tag tag-purple">评估</span>
<span class="tag tag-teal">创作</span>
<span class="tag tag-amber">执行</span>
<span class="tag tag-coral">发布</span>
</div>
</div>
<!-- 快速开始 -->
<div class="card">
<h2>🏃 快速开始</h2>
<div class="feature-row">
<span class="feature-icon">💻</span>
<div class="feature-text">
<strong>运行应用</strong><br>
<code>bun install</code><br>
<code>bun run tauri dev</code>
</div>
</div>
<div class="feature-row">
<span class="feature-icon">💡</span>
<div class="feature-text">
<strong>一句话功能</strong><br>
你的创作流程，本地跑，AI 辅助，数据不出门
</div>
</div>
</div>
<!-- 核心价值链 -->
<div class="card">
<h2>🎯 核心价值链</h2>
<p style="font-weight: 500; margin-bottom: 1rem;">想法 → 评估 → 创作 → 发布</p>
<div class="feature-row">
<span class="feature-icon">💡</span>
<div class="feature-text">
<strong>想法管理</strong><br>
收集、分类、评估创作想法<br>
支持多种类型的创作灵感
</div>
</div>
<div class="feature-row">
<span class="feature-icon">⚖️</span>
<div class="feature-text">
<strong>对抗评估</strong><br>
正方观点 + 反方观点 + 分析师建议<br>
确保创作质量和价值
</div>
</div>
<div class="feature-row">
<span class="feature-icon">🎨</span>
<div class="feature-text">
<strong>创作执行</strong><br>
代码、文档、PPT 等多种创作形式<br>
AI 辅助和模板支持
</div>
</div>
<div class="feature-row">
<span class="feature-icon">📤</span>
<div class="feature-text">
<strong>发布分享</strong><br>
多格式导出、版本管理<br>
一键发布到各平台
</div>
</div>
</div>
<!-- 功能模块 -->
<div class="card">
<h2>📋 功能模块</h2>
<p style="font-size: 12px; color: var(--df-text-dim); margin-bottom: 1rem;">聚焦核心，拒绝过设计</p>
<div class="feature-row">
<span class="feature-icon">🤖</span>
<div class="feature-text">
<strong>AI Chat</strong><br>
单 Provider 简化配置<br>
工具调用：代码生成、文件操作、Git 操作<br>
流式响应：实时输出
</div>
</div>
<div class="feature-row">
<span class="feature-icon">💡</span>
<div class="feature-text">
<strong>想法池</strong><br>
轻量版：聚焦核心<br>
预留对抗评估：后续升级
</div>
</div>
<div class="feature-row">
<span class="feature-icon">📂</span>
<div class="feature-text">
<strong>项目管理</strong><br>
多项目支持<br>
与 Git 分支联动
</div>
</div>
<div class="feature-row">
<span class="feature-icon">📚</span>
<div class="feature-text">
<strong>知识库（收藏夹）</strong><br>
静态收集：个人经验碎片<br>
分类管理：审查规则、Prompt 模板、踩坑经验
</div>
</div>
<div class="feature-row">
<span class="feature-icon">⚙️</span>
<div class="feature-text">
<strong>设置</strong><br>
AI 配置：Provider、模型选择<br>
通用设置：主题、语言
</div>
</div>
</div>
<!-- 特色功能 -->
<div class="card">
<h2>🌟 特色功能</h2>
<div class="feature-row">
<span class="feature-icon">🏠</span>
<div class="feature-text">
<strong>本地优先</strong><br>
SQLite 本地数据库<br>
基础功能离线可用<br>
代码不出本地
</div>
</div>
<div class="feature-row">
<span class="feature-icon">⚡</span>
<div class="feature-text">
<strong>实时监控</strong><br>
WebSocket 实时更新<br>
工作流执行进度<br>
错误原因分析
</div>
</div>
<div class="feature-row">
<span class="feature-icon">🔧</span>
<div class="feature-text">
<strong>工作流节点</strong><br>
Script：执行 Shell 命令<br>
Human：人工审批<br>
Condition：条件判断<br>
Parallel：并行执行
</div>
</div>
</div>
<!-- 使用场景 -->
<div class="card">
<h2>🎨 界面说明</h2>
<div class="section-title">颜色系统</div>
<div style="display: flex; flex-wrap: wrap; gap: 1rem; margin-bottom: 1rem;">
<div style="display: flex; align-items: center; gap: 0.5rem;">
<span style="width: 16px; height: 16px; background: var(--df-accent); border-radius: 4px;"></span>
<span style="font-size: 12px;">紫色（主色）</span>
</div>
<div style="display: flex; align-items: center; gap: 0.5rem;">
<span style="width: 16px; height: 16px; background: var(--df-success); border-radius: 4px;"></span>
<span style="font-size: 12px;">青绿（成功）</span>
</div>
<div style="display: flex; align-items: center; gap: 0.5rem;">
<span style="width: 16px; height: 16px; background: var(--df-warning); border-radius: 4px;"></span>
<span style="font-size: 12px;">琥珀（警告）</span>
</div>
<div style="display: flex; align-items: center; gap: 0.5rem;">
<span style="width: 16px; height: 16px; background: var(--df-danger); border-radius: 4px;"></span>
<span style="font-size: 12px;">珊瑚（危险）</span>
</div>
</div>
<div class="section-title">图标含义</div>
<div style="display: flex; flex-wrap: wrap; gap: 1rem; margin-bottom: 1rem;">
<span style="font-size: 14px;">📋 待开始</span>
<span style="font-size: 14px;">🔨 进行中</span>
<span style="font-size: 14px;">👀 待审查</span>
<span style="font-size: 14px;">✅ 已合并</span>
<span style="font-size: 14px;">🗑️ 已废弃</span>
</div>
</div>
<!-- 注意事项 -->
<div class="card">
<h2>⚠️ 注意事项</h2>
<div class="feature-row">
<span class="feature-icon">🔗</span>
<div class="feature-text">
<strong>Git 集成</strong><br>
必须初始化 Git 仓库<br>
配置用户邮箱和姓名<br>
保持分支命名规范
</div>
</div>
<div class="feature-row">
<span class="feature-icon">🔌</span>
<div class="feature-text">
<strong>AI 配置</strong><br>
需要有效的 API Key<br>
检查网络连接<br>
关注 Token 使用量
</div>
</div>
<div class="feature-row">
<span class="feature-icon">⚙️</span>
<div class="feature-text">
<strong>工作流设计</strong><br>
避免长时间阻塞操作<br>
设置合理的超时时间<br>
保留人工干预接口
</div>
</div>
</div>
<!-- 更新日志 -->
<div class="card">
<h2>🔄 更新日志</h2>
<div class="feature-row">
<span class="feature-icon">✅</span>
<div class="feature-text">
<strong>v1.0 (2026-06-11)</strong><br>
完成核心功能<br>
任务管理系统<br>
工作流引擎<br>
AI Chat 集成<br>
本地数据存储
</div>
</div>
<div class="feature-row">
<span class="feature-icon">🔄</span>
<div class="feature-text">
<strong>计划功能</strong><br>
想法对抗式评估<br>
更多工作流节点<br>
团队协作功能
</div>
</div>
</div>
<!-- 配置指南 -->
<div class="card">
<h2>⚙️ 配置指南</h2>
<div class="section-title">AI 配置</div>
<div class="feature-row">
<span class="feature-icon">🤖</span>
<div class="feature-text">
<strong>Provider 设置</strong><br>
支持 OpenAI、Anthropic、DeepSeek<br>
配置 API Key 和模型选择
</div>
</div>
<div class="feature-row">
<span class="feature-icon">⚙️</span>
<div class="feature-text">
<strong>高级参数</strong><br>
Temperature: 0-2（创造性）<br>
Max Tokens: 限制回答长度
</div>
</div>
<div class="section-title">Git 集成</div>
<div class="feature-row">
<span class="feature-icon">🔗</span>
<div class="feature-text">
<strong>基础配置</strong><br>
git config user.name/email<br>
自动分支创建：feature/任务名
</div>
</div>
<div class="section-title">工作流配置</div>
<div class="feature-row">
<span class="feature-icon">🔄</span>
<div class="feature-text">
<strong>节点类型</strong><br>
script: Shell 命令<br>
human: 人工审批<br>
condition: 条件判断
</div>
</div>
</div>
<!-- 常见问题 -->
<div class="card">
<h2>❓ 常见问题</h2>
<div class="section-title">安装启动</div>
<div class="feature-row">
<span class="feature-icon">🚀</span>
<div class="feature-text">
<strong>无法启动</strong><br>
检查 Node.js >= 18<br>
bun clean + bun install<br>
确认端口 1420 可用
</div>
</div>
<div class="section-title">功能使用</div>
<div class="feature-row">
<span class="feature-icon">💡</span>
<div class="feature-text">
<strong>任务不显示</strong><br>
确认选中项目<br>
刷新页面<br>
查看控制台错误
</div>
</div>
<div class="feature-row">
<span class="feature-icon">🤖</span>
<div class="feature-text">
<strong>AI 无响应</strong><br>
检查 API Key<br>
确认网络连接<br>
切换 Provider 测试
</div>
</div>
<div class="section-title">数据管理</div>
<div class="feature-row">
<span class="feature-icon">💾</span>
<div class="feature-text">
<strong>存储位置</strong><br>
Windows: %APPDATA%\devflow\ <br>
macOS: ~/Library/Application Support/devflow/ <br>
Linux: ~/.config/devflow/
</div>
</div>
<div class="feature-row">
<span class="feature-icon">🔧</span>
<div class="feature-text">
<strong>数据备份</strong><br>
备份数据库：cp devflow.db backup/ <br>
备份配置：cp config.json backup/
</div>
</div>
</div>
<!-- 核心原则 -->
<div class="card">
<h2>💡 产品哲学</h2>
<div class="feature-row">
<span class="feature-icon">🎯</span>
<div class="feature-text">
<strong>聚焦核心</strong><br>
不是全流程操作系统<br>
专注于本地任务流程<br>
简单、实用、可靠
</div>
</div>
<div class="feature-row">
<span class="feature-icon">👨‍💻</span>
<div class="feature-text">
<strong>开发者第一</strong><br>
功能设计以开发者需求为中心<br>
避免过工程化的设计<br>
保留必要的扩展性
</div>
</div>
<button class="btn-demo" onclick="window.location.href='https://github.com/your-repo/devflow'">
🚀 开始使用 DevFlow
</button>
</div>
<script>
// 主题切换
const themeToggle = document.getElementById('themeToggle');
const html = document.documentElement;
// 检查本地存储的主题
const currentTheme = localStorage.getItem('theme') || 'dark';
html.setAttribute('data-theme', currentTheme);
themeToggle.addEventListener('click', () => {
const newTheme = html.getAttribute('data-theme') === 'dark' ? 'light' : 'dark';
html.setAttribute('data-theme', newTheme);
localStorage.setItem('theme', newTheme);
});
// 模拟 Tabler Icons（实际项目中需要引入）
document.addEventListener('DOMContentLoaded', () => {
// 创建图标映射
const icons = {
'ti-moon': '🌙',
'ti-sun': '☀️',
'ti-home': '🏠',
'ti-settings': '⚙️',
'ti-chart-bar': '📊',
'ti-calendar': '📅',
'ti-star': '⭐',
'ti-bolt': '⚡',
'ti-brain': '🧠',
'ti-arrow-right': '→'
};
// 替换图标
document.querySelectorAll('.ti').forEach(icon => {
const iconClass = icon.className.split(' ')[1];
if (icons[iconClass]) {
icon.textContent = icons[iconClass];
}
});
});
</script>
</body>
</html>

225
docs/08-用户指南/使用手册.md Normal file
View File

@@ -0,0 +1,225 @@
# DevFlow 使用手册
> "本地优先的个人开发流程驾驶舱"
```mermaid
graph LR
A[想法池] -->|评估| B[项目管理]
B -->|创建| C[任务队列]
C -->|执行| D[工作流引擎]
D -->|合并| E[Git仓库]
```
```mermaid
graph LR
A[想法] -->|收集| B[任务]
B -->|分配| C[分支]
C -->|自动化| D[工作流]
D -->|提交| E[代码]
```
## 🚀 快速开始
### 运行应用
```bash
bun install
bun run tauri dev
```
### 一句话功能
你的项目流程，本地跑，AI 辅助，数据不出门
## 🎯 核心价值链
### 任务 → 分支 → 工作流 → 合并
#### 1. 任务管理
- **创建任务**：指定项目、标题、分支名
- **状态流转**：待开始 → 进行中 → 待审查 → 已合并
- **优先级**：P0（紧急）到 P3（低）
#### 2. 分支绑定
```bash
# 创建任务时自动生成分支
# 例如：feature/devflow-improve
```
#### 3. 工作流执行
- **环境检查**：依赖验证、端口检查
- **运行测试**：单元测试、集成测试
- **构建产物**：打包、优化、部署
#### 4. 实时监控
- **事件日志**：每个节点执行状态
- **错误处理**：失败重试、人工审批
## 📋 功能模块
### 🤖 AI Chat
- **单 Provider**：简化配置
- **工具调用**：代码生成、分析
- **流式响应**：实时输出
### 💡 想法池
- **轻量版**：聚焦核心
- **预留对抗评估**：后续升级
### 📂 项目管理
- **多项目支持**：切换不同仓库
- **状态同步**：与 Git 分支联动
### 📚 知识库（收藏夹）
- **静态收集**：个人经验碎片
- **分类管理**：审查规则、Prompt模板、踩坑经验
- **快速搜索**：标题、标签、内容
### ⚙️ 设置
- **AI 配置**：Provider、模型选择
- **通用设置**：主题、语言
## 🔧 核心功能详解
### 任务操作流程
#### 1. 创建任务
```typescript
// 在项目详情页点击 "+ 新任务"
- 填写任务标题
- 选择项目
- （可选）指定分支名
```
#### 2. 任务执行
- **自动创建分支**：`git checkout -b feature/task-name`
- **绑定任务 ID**：Git commit 自动关联
- **状态同步**：合并后任务标记为已完成
#### 3. 工作流运行
```typescript
// 点击"运行测试工作流"
1. 环境检查 → 验证依赖
2. 运行测试 → 执行单元测试
3. 构建产物 → 生成发布包
```
### AI Chat 使用
#### 基础对话
- 直接提问
- 代码审查
- 问题诊断
#### 工具调用
- **生成代码**：根据描述生成完整实现
- **文件操作**：读取、编辑项目文件
- **Git 操作**：提交、推送、合并
## 💡 想法池功能
### 创建想法
```typescript
// 简单记录
- 标题：一句话描述
- 描述：详细说明（可选）
- 优先级：P1~P3
- 标签：便于分类
```
### 状态管理
- **草稿**：初始想法
- **活跃**：正在考虑
- **已完成**：已实现或放弃
### 未来升级
- **对抗式评估**：正方+反方+分析师
- **智能推荐**：相关想法关联
## 🌟 特色功能
### 本地优先
- **数据存储**：SQLite 本地数据库
- **无需网络**：基础功能离线可用
- **隐私保护**：代码不出本地
### 实时监控
- **事件流**：WebSocket 实时更新
- **进度显示**：工作流执行进度
- **错误提示**：失败原因分析
### 工作流节点
```typescript
// 支持的节点类型
- Script：执行 Shell 命令
- Human：人工审批
- Condition：条件判断
- Parallel：并行执行
```
## 📊 使用统计
### 个人效能
- **任务完成率**：按时完成任务比例
- **分支管理**：活跃分支数量
- **工作流成功率**：自动执行成功率
### 项目进度
- **阶段分布**：规划/开发/测试/上线
- **任务积压**：待处理任务数量
- **开发速度**：每周完成任务数
## 🎨 界面说明
### 颜色系统
- **主色**：紫色（#6B46C1）
- **成功色**：绿色（#10B981）
- **警告色**：黄色（#F59E0B）
- **错误色**：红色（#EF4444）
### 图标含义
- 📋：待开始
- 🔨：进行中
- 👀：待审查
- ✅：已合并
- 🗑️：已废弃
## ⚠️ 注意事项
### Git 集成
- 必须初始化 Git 仓库
- 配置用户邮箱和姓名
- 保持分支命名规范
### AI 配置
- 需要有效的 API Key
- 检查网络连接
- 关注 Token 使用量
### 工作流设计
- 避免长时间阻塞操作
- 设置合理的超时时间
- 保留人工干预接口
## 🔄 更新日志
### v1.0 (2026-06-11)
- ✅ 完成核心功能
- ✅ 任务管理系统
- ✅ 工作流引擎
- ✅ AI Chat 集成
- ✅ 本地数据存储
### 计划功能
- 🔄 想法对抗式评估
- 🔄 更多工作流节点
- 🔄 团队协作功能
- 🔄 数据导出功能
## 📞 支持
- 问题反馈：创建 Issue
- 功能建议：想法池提交
- 使用交流：Discord 社区
---
**记住**：这不是全流程操作系统，而是专注于本地任务流程的工具。简单、实用、可靠。

109
docs/INDEX.md Normal file
View File

@@ -0,0 +1,109 @@
# DevFlow 文档索引
> 创建: 2026-06-10 | 当前阶段: Phase 2 本地优先开发流程验证
> 更新: 2026-06-11 | 清理 60% 功能，聚焦核心链路
---
## 目录结构
```
docs/
├── README.md # 快速开始与文档导航
├── 使用指南/ # 用户文档
│ └── 使用手册.html # 完整使用指南（HTML）
├── INDEX.md # 本文件 — 文档导航
├── 01-技术文档/ # 技术专题研究
│ ├── SQLite-CRUD模式.md # CRUD 层设计模式
│ └── Tauri-IPC模式.md # Tauri IPC 设计模式
├── 02-架构设计/ # 架构方案、设计决策、迁移记录
│ ├── Phase1架构决策.md # Phase 1 关键架构决策
│ ├── 业务系统设计.md # 业务系统设计
│ ├── 前后端类型对齐.md # Rust/TS 类型对齐规范
│ ├── 对抗论证裁决报告.md # 60% 功能清理决策
│ └── 产品定位调整.md # 新定位：本地优先个人开发流程驾驶舱
├── 03-模块文档/ # 各功能模块实现文档
│ ├── df-storage-存储层.md # 存储层概览
│ ├── df-workflow-工作流引擎.md # 工作流引擎概览
│ ├── df-nodes-节点集合.md # 8 种节点概览
│ ├── df-ai-AI集成模块.md # AI Provider 集成
│ └── 想法探索-对抗式评估.md # 想法池对抗评估设计
├── 04-功能迭代/ # 功能开发过程记录
│ ├── DEVFLOW-1.CRUD层实施.md # CRUD 层实施记录
│ ├── DEVFLOW-2.IPC桥接实施.md # IPC 桥接实施记录
│ ├── DEVFLOW-3.Store对接实施.md # Store 对接实施记录
│ ├── DEVFLOW-4.端到端验证.md # 端到端验证记录
│ ├── DEVFLOW-5.功能清理.md # 60% 功能清理记录
│ └── DEVFLOW-6.想法池开发.md # 想法池基础功能开发
├── 05-代码审查/ # 审查报告、代码质量
│ └── 代码审查报告.md # 首轮代码审查结果
├── 06-前端开发/ # 前端分析、优化
│ ├── View改造指南.md # 硬编码 → Store → API 迁移指南
│ └── 组件设计规范.md # Vue 3 组件设计规范
├── 07-项目管理/ # 项目状态、功能清单、版本管理
│ ├── Phase1任务清单.md # Phase 1 任务清单
│ ├── Phase2计划.md # Phase 2 开发计划
│ └── PROGRESS.md # 项目进展与交接记录
└── 08-用户指南/ # 用户手册、配置指南
├── 快速上手.md # 5分钟快速上手
├── 配置指南.md # AI 配置、Git 集成
└── 常见问题.md # FAQ 和故障排除
```
---
## 快速导航
| 分类 | 入口 | 说明 |
|------|------|------|
| 🚀 快速开始 | [README.md](./README.md) | 安装、启动、快速上手 |
| 📖 使用指南 | [使用指南/](./使用指南/) | 完整交互式使用手册 |
| 📋 项目进度 | [PROGRESS.md](../PROGRESS.md) | 实时项目进展与状态 |
| ⚙️ 技术文档 | [01-技术文档/](./01-技术文档/) | SQLite CRUD、Tauri IPC 等技术专题 |
| 🏗️ 架构设计 | [02-架构设计/](./02-架构设计/) | 架构方案、设计决策、产品定位调整 |
| 🔧 模块文档 | [03-模块文档/](./03-模块文档/) | 各 Crate 模块实现与设计 |
| 📈 功能迭代 | [04-功能迭代/](./04-功能迭代/) | DEVFLOW-N 系列功能开发过程 |
| 🔍 代码审查 | [05-代码审查/](./05-代码审查/) | 审查报告、代码质量分析 |
| 🎨 前端开发 | [06-前端开发/](./06-前端开发/) | Vue 3 前端分析、优化、迁移指南 |
| 📊 项目管理 | [07-项目管理/](./07-项目管理/) | 任务清单、开发计划、进度跟踪 |
| 📚 用户指南 | [08-用户指南/](./08-用户指南/) | 快速上手、配置指南、FAQ |
---
## 新文档放置规则
| 文档类型 | 放置位置 |
|----------|----------|
| 技术专题研究 | `01-技术文档/<主题名>.md` |
| 架构设计/改进方案 | `02-架构设计/` |
| Crate 模块实现文档 | `03-模块文档/` |
| 功能开发过程记录 | `04-功能迭代/DEVFLOW-N.<名称>.md` |
| 代码审查/走查报告 | `05-代码审查/` |
| 前端优化/迁移指南 | `06-前端开发/` |
| 项目状态/任务清单 | `07-项目管理/` |
| 用户手册/配置指南 | `08-用户指南/` |
---
## 核心文档速查
| 文档 | 路径 | 说明 |
|------|------|------|
| 架构设计 | `../ARCHITECTURE.md` | 22,745 字完整架构文档 |
| 项目进展 | `../PROGRESS.md` | 工作进展与交接 |
| Crate 结构 | `../ARCHITECTURE.md#四crate-结构` | 13 个 Crate 概览 |
| 数据模型 | `../ARCHITECTURE.md#六数据模型` | SQLite 表结构定义 |
| Phase 规划 | `../ARCHITECTURE.md#八phase-规划` | 5 个 Phase 路线图 |
---
## 技术栈
| 层 | 技术 | 说明 |
|----|------|------|
| Desktop | Tauri v2 | Rust 后端 + WebView 前端 |
| Frontend | Vue 3 + TypeScript + Pinia | Arco Design 组件库 |
| Engine | Rust Workspace (13 crate) | 多 crate 架构 |
| Storage | SQLite (rusqlite) | 本地优先，零运维 |
| AI | Multi-Provider | Claude/GLM/DeepSeek/OpenAI 兼容 |
| Build | Bun + Vite | 前端构建 |

57
docs/README.md Normal file
View File

@@ -0,0 +1,57 @@
# DevFlow 文档
> **本地优先的个人创作流程驾驶舱**
> 从想法到创作（代码/文档/演示）的全流程管理
## 📚 文档目录
### 📖 使用指南
- [DevFlow 使用手册](使用指南/使用手册.html) - 完整的使用指南，包含功能介绍、操作流程和最佳实践
### 📋 项目进度
- [PROGRESS.md](PROGRESS.md) - 项目开发进展与交接记录
## 🎯 核心理念
DevFlow 帮助你将**想法转化为创作成果**，支持多种输出形式：
### 创作类型
- **代码实现**：应用程序、脚本、工具
- **技术文档**：API 文档、用户手册、架构设计
- **演示文稿**：项目提案、技术分享、培训材料
- **内容创作**：博客文章、分析报告、学习笔记
- **创意输出**：设计方案、概念图、原型
### 核心流程
```
想法池 → 对抗评估 → 创作（多样化） → 发布/分享
```
## 🚀 快速开始
```bash
# 安装依赖
bun install
# 启动开发服务器
bun run tauri dev
```
---
## 📖 文档说明
### 使用指南
HTML 格式的交互式文档，包含：
- 核心功能介绍（想法管理、创作流程）
- 操作指南（代码/文档/PPT 创作）
- 界面说明
- 最佳实践
- 常见问题解答
### 项目进度
Markdown 格式的开发记录：
- 功能模块完成情况
- 重要决策记录（从代码到创作的定位升级）
- 技术难点攻克
- 版本更新日志