绝尘
f3c0967f41
build_approval_reason 改 async + 接收 db，对 delete/restore/purge/update/bind/create_task 的 id/project_id 查 ProjectRepo.get_by_id 拼「项目名」(id=x)（原只拼裸 id，用户反馈'只返回 ID 不知道是什么数据'） 新增 resolve_project_label helper；process_tool_calls 调用改 await 来源 aichat审查报告 第二章 + 用户 2026-06-14 再反馈;cargo 0 err
350 lines
13 KiB
Markdown
350 lines
13 KiB
Markdown
# 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 评分
|