lxy/DevFlow
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
dcc3f0d230aeea9a62af10aee846eebb0108f3dc
DevFlow/ARCHITECTURE.md
绝尘 dcc3f0d230 新增: 三层模型设计文档 — 模板/工作流/人设体系 
- ARCHITECTURE.md 补充执行层级模型 + 重写 §七 三层模型章节
- 新建专项设计: 流程模板 YAML 规范/AgentPersona 数据结构/实例化流程
- 注册新文档到架构设计 INDEX
- Agent架构说明补充前向关联引用
2026-06-28 04:44:01 +08:00

730 lines
34 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters
This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
# DevFlow — 产研全流程工作流平台
> 版本: v0.1.0 | 创建: 2026-06-10 | 状态: 设计阶段
## 一、项目定位
**AI 原生的产研操作系统**，从想法到上线的全流程编排。
### 核心特性
- **想法池 (Idea Pool)**：持续捕捉、AI 评估、漏斗筛选、晋升立项
- **多项目并行**：多项目同时推进，共享 AI/执行资源
- **多任务/分支并行**：同一项目内多任务同时开发，各绑独立 Git 分支，完成后合并
- **工作流引擎**：DAG 驱动，节点可扩展，支持条件分支和断点续跑
- **AI 编排**：多模型并行（Claude/GLM/DeepSeek），多 Agent 协作
- **标注系统 (Annotation)**：所有内容支持 FIXME/TODO/QUESTION 等标注，统一收集后批量交给 AI 处理
- **需求-功能-测试可追溯**：功能可选做/延/不做，每个功能对应测试用例和测试报告
- **决策留痕 (Decision Journal)**：所有关键决策自动记录（原因/方案/时间/上下文），全程可追溯
- **经验进化 (Evolution)**：开发过程中的模式自动沉淀为知识库（审查规则/Prompt模板/踩坑经验），持续进化复用
- **阶段插件**：想法→需求→编码→测试→发布，阶段即模板
### 层级模型（业务层级）
DevFlow 的业务抽象分三层，自上而下层层实例化：
```
💡 Idea Pool (想法池) — 独立运转，持续捕捉和评估
└→ 📂 Project (项目) — 多项目并行
├→ 🔀 Task (任务) — 绑定 Git 分支，独立工作流
│ └→ Workflow DAG (编码→测试→审查)
├→ 🔀 Task (任务) — 另一个并行任务
│ └→ Workflow DAG
└→ 🎯 Release (发布) — 合并多个 Task → 集成测试 → 发布
```
### 层级模型（执行层级）
Workflow DAG 的执行层进一步拆分为三层，这是 AI Factory 的核心抽象：
```
┌──────────────────────────────────────────────────┐
│ 模板层 (Template) │
│ "应该做什么" — 阶段蓝图、行业最佳实践 │
│ │
│ 职责: 定义节点拓扑 + 产出物规范 + 质量门禁 │
│ 生命周期: 长期存在，跨项目复用 │
│ 存储: YAML 文件 / DB 模板库 │
├──────────────────────────────────────────────────┤
│ 工作流层 (Workflow) │
│ "怎么执行" — DAG 实例、状态机、运行时 │
│ │
│ 职责: 拓扑排序 + 节点调度 + 状态流转 + 持久化 │
│ 生命周期: 随项目启动/结束，单次执行后归档 │
│ 载体: df-workflow (DAG + Executor + StateMachine) │
├──────────────────────────────────────────────────┤
│ 人设层 (Persona) │
│ "谁来做" — Agent 角色、能力边界、行为风格 │
│ │
│ 职责: 定义 system prompt + 可用工具 + 输出格式 │
│ 生命周期: 长期存在，跨节点复用 │
│ 注入点: AINode 执行时载入对应人设 │
└──────────────────────────────────────────────────┘
```
**关键设计原则**：三层各自独立演化，在 AINode 执行时交汇。
- 模板 = 可复用的蓝图（定义节点拓扑 + 建议人设 + 质量门禁）
- 工作流 = 模板的运行时实例（含状态、数据绑定、执行记录）
- 人设 = Agent 的角色卡（system prompt + 工具集 + 行为规则）
### AI Working 定位体系
DevFlow 的终极交互模型是 **AI 驱动 (AI Working)**：**AI 是系统的主要操作者，人是监督者与决策者**。
```
┌──────────────────────────────────┐
│ AI Chat（唯一对话入口） │
│ 工具注册表 ←→ Agentic Loop ←→ 审批 │
└──────────────┬───────────────────┘
│
┌───────┬───────┬───┴───┬───────┬───────┐
│ 查看 │ 驱动 │ 创意 │ 决策 │ 录入 │ ← 人的五种行为
└───────┴───────┴───┬───┴───────┴───────┘
│
┌──────────────┴──────────────┐
│ IPC 命令层 │
│ project / task / idea / │
│ knowledge / workflow / ai │
└──────────────┬──────────────┘
│
┌──────────────┴──────────────┐
│ 数据层 (SQLite) │
└─────────────────────────────┘
```
#### 人的五种行为（均通过 AI Chat 完成）
| 行为 | 说明 | 示例 |
|------|------|------|
| **查看数据** | 不点页面翻列表，自然语言查询 | "最近 blocked 的任务有哪些？" → AI 调 `list_tasks` |
| **驱动执行** | 不手动推进状态，对话指令驱动 | "把子1推进到 in_progress" → AI 调 `advance_task` |
| **创意捕获** | 不打开灵感表单，对话中自然捕获 | "这个想法记一下" → AI 调 `create_idea` |
| **决策审批** | 不逐条点批准，Chat 内确认/拒绝 | 工具审批卡片（Agentic Loop 内） |
| **录入信息** | 不填 CRUD 表单，自然语言录入 | "建个项目叫 foo，在 E:/bar" → AI 调 `create_project` |
#### 关键设计原则
1. **AI 工具注册表是主接口**：IPC 就绪后必须立刻注册为 AI 工具，页面是旁路查看器
2. **页面降级为「查看层」**：Dashboard / Projects / Tasks / Ideas 等页面用于事后查看、审计、回放
3. **功能优先级 = AI 工具覆盖度**：人对模块的操作能力取决于 AI 工具注册表中该模块的工具是否完整
4. **灵感 / 项目 / 任务 三模块的 AI 工具必须完全覆盖 CRUD + 状态推进 + 升级/评估**
## 二、技术栈
| 层 | 技术 | 说明 |
|----|------|------|
| Desktop | Tauri v2 | Rust 后端 + WebView 前端 |
| Frontend | Vue 3 + TypeScript + Pinia | Arco Design 组件库 |
| Engine | Rust (Workspace) | 多 crate 架构 |
| Storage | SQLite (rusqlite) | 本地优先，零运维 |
| AI | Multi-Provider | Claude/GLM/DeepSeek/OpenAI 兼容 |
| Container | Docker (bollard) | 隔离构建/测试环境 |
## 三、系统架构
```
┌──────────────────────────────────────────────────────────────────┐
│ DevFlow Desktop │
│ Tauri v2 · Vue 3 · TS │
├──────────────────────────────────────────────────────────────────┤
│ 💡 Idea Pool │ 📂 Multi-Project Manager │
│ 捕捉·评估·晋升 │ 多项目并行·资源调度 │
├────────────────────────┴─────────────────────────────────────────┤
│ 🔀 Task & Branch Manager (任务/分支管理) │
│ 多任务并行·分支创建·合并协调·冲突解决 │
│ ┌──────────┬──────────┬──────────┬──────────────────────────┐ │
│ │ Task A │ Task B │ Task C │ Release │ │
│ │ feat/auth│feat/pay │fix/login │ main │ │
│ │ [DAG] │ [DAG] │ [DAG] │ [合并→测试→发布] │ │
│ └──────────┴──────────┴──────────┴──────────────────────────┘ │
├──────────────────────────────────────────────────────────────────┤
│ Workflow Engine (DAG · Node · State · Event · Persist) │
├──────────────────────┬───────────────────────────────────────────┤
│ AI Orchestrator │ Execution Runtime │
│ Multi-Provider │ Shell (tokio::process) │
│ Agent Coordinator │ Merge · Conflict Resolve │
├──────────────────────┴───────────────────────────────────────────┤
│ Storage Layer (SQLite) │
│ ideas · projects · tasks · branches · workflows · artifacts │
└──────────────────────────────────────────────────────────────────┘
```
## 四、Crate 结构
```
devflow/
├── Cargo.toml # Workspace 根
├── crates/
│ ├── df-core/ # 核心类型、错误、常量、事件
│ ├── df-workflow/ # 工作流 DAG 引擎 (核心)
│ ├── df-nodes/ # 内置节点集合 (AI/Script/Human)
│ ├── df-ai/ # AI 编排层 (Multi-Provider/Coordinator)
│ ├── df-execute/ # 执行运行时 (Shell)
│ ├── df-storage/ # 存储层 (SQLite)
│ ├── df-ideas/ # 想法池引擎 (捕捉/评估/评分/晋升)
│ └── df-project/ # 多项目管理 (调度/上下文/时间线)
│
│ 注: df-task / df-traceability / df-evolve / df-stages / df-plugin
│ 5 个 crate 已移除（2026-06-14 零引用清理，推翻原"保留骨架"取舍）
├── src-tauri/ # Tauri 主入口 (Rust)
│ └── src/
│ ├── main.rs
│ ├── state.rs
│ └── commands/ # IPC 命令
├── src/ # Vue 3 前端
│ ├── views/ # 页面组件
│ ├── components/ # 业务组件
│ ├── stores/ # Pinia 状态
│ └── composables/ # 组合式函数
├── templates/ # 工作流模板 (YAML)
└── plugins/ # 外部插件目录
```
## 五、核心模块设计
### 5.1 Workflow Engine (df-workflow)
引擎不感知具体业务，只负责 DAG 执行。
- **Node trait**：所有节点的统一抽象 (`execute`, `schema`, `is_blocking`)
- **DAG Executor**：拓扑排序 → 并行调度 → 状态流转 → 持久化
- **EventBus**：`tokio::sync::broadcast` 异步事件广播
- **Persister**：SQLite 快照，支持断点续跑
- **Conditions**：基于表达式的条件分支引擎
### 5.2 Idea Pool (df-ideas)
想法是独立于项目的第一公民。
- **Capture**：文本/剪贴板/快捷键捕捉，不打断当前工作
- **Evaluator**：AI 自动评估市场潜力、竞品、技术可行性
- **Scoring**：多维加权评分 (0-100)
- **Graph**：想法关联图，相似想法自动发现，可合并
- **Promotion**：高分想法晋升为项目，自动携带评估结论
想法状态：`Draft → PendingReview → Approved → Promoted / Rejected / Archived`
### 5.3 Multi-Project Manager (df-project)
- **ProjectSlot**：每个项目的运行时槽位（活跃任务数、优先级、AI 配额）
- **Scheduler**：AI 并发预算分配、Docker 资源配额
- **Context**：项目上下文（代码结构、依赖、规范），供 AI 消费
- **Timeline**：项目时间线，所有事件的时序视图
项目状态：`Planning / InProgress / Testing / Releasing / Completed / Paused / Cancelled`
### 5.3.1 ~~Task & Branch Manager (df-task)~~ — 已移除
> **2026-06-14 零引用清理**：df-task crate 已删除。以下内容保留作为历史设计参考，不再对应实际代码。
项目内部的并行任务管理，每个任务绑定一个 Git 分支。
- **Task**：独立工作单元，包含标题、描述、绑定的分支、关联的工作流
- **BranchManager**：自动创建分支、跟踪分支状态、与 main 的 diff 统计
- **MergeCoordinator**：合并策略管理、冲突检测、AI 辅助冲突解决
- **ReleasePlanner**：选择多个已完成的 Task 合并，编排集成测试和发布流程
```
Task 生命周期:
Todo → InProgress → InReview → Testing → Done
↓ (随时) ↓
Blocked Cancelled
分支策略:
main ────────────────────────────────
└── feature/auth ──── ✅ merged
└── feature/payment ─ 🔄 in progress
└── bugfix/login ──── ✅ merged
└── release/v2.3 ──── ⏳ waiting (merge auth + payment)
```
合并协调:
1. 冲突检测：Task 完成时自动检测与 main 的冲突
2. AI 辅助解决：冲突文件交给 AI 分析并建议解决方案
3. 发布编排：选择多个 Task → 创建 release 分支 → 合并 → 集成测试 → 发布
### 5.4 ~~Traceability & Annotation (df-traceability)~~ — 已移除
> **2026-06-14 零引用清理**：df-traceability crate 已删除。以下内容保留作为历史设计参考，不再对应实际代码。
贯穿所有阶段的可追溯性引擎。
#### 5.4.1 标注系统 (Annotation)
任何内容（需求文档、代码、测试报告、设计文档）中都可以插入标注：
| 标记 | 含义 | 场景 |
|------|------|------|
| `[FIXME]` | 需要修复 | 代码/文档中发现问题 |
| `[TODO]` | 待办事项 | 后续需要补充的内容 |
| `[QUESTION]` | 疑问待确认 | 需要人工决策的问题 |
| `[RISK]` | 风险标记 | 潜在的技术/业务风险 |
| `[DECISION]` | 决策标记 | 记录为什么做此选择 |
| `[OPTIMIZE]` | 优化建议 | 可改进但不紧急 |
**批量处理流程**：
```
人工在各内容中插标注 → 系统统一收集所有未处理标注
→ 按类型/优先级分组 → 一键交给 AI 批量处理
→ AI 逐条处理并标记完成 → 人工确认处理结果
```
标注可以附加在任何实体上（需求、功能、代码文件、测试用例）。
#### 5.4.2 需求-功能-测试映射
```
📋 需求 (Requirement)
└→ 功能 (Feature) [状态: Selected / Deferred / Rejected]
└→ 测试用例 (TestCase) [自动/手动生成]
└→ 测试执行记录 (TestRun)
└→ 测试报告 (TestReport)
```
- **功能状态**：`Selected(选中做)` / `Deferred(延期)` / `Rejected(不做)`
- 每个功能可标注不做的**原因**（自动进入决策留痕）
- AI 根据功能描述**自动生成测试用例**
- 测试用例与功能**双向关联**，覆盖率一目了然
- 测试报告自动生成，标注 PASS/FAIL/SKIP
#### 5.4.3 决策留痕 (Decision Journal)
所有关键决策自动或半自动记录，全程可追溯。
```rust
pub struct Decision {
pub id: DecisionId,
pub project_id: ProjectId,
pub context: String, // 决策背景
pub question: String, // 需要决定的问题
pub alternatives: Vec<String>,// 考虑过的方案
pub decision: String, // 最终决定
pub reason: String, // 决策原因
pub decided_by: DecidedBy, // AI / Human
pub related_entity: EntityRef,// 关联实体(功能/需求/代码等)
pub impact: String, // 影响范围
pub created_at: DateTime,
}
```
**自动记录的决策场景**：
- 功能标记为"不做"时，强制填写原因
- AI 选择了方案 A 而非方案 B 时，记录理由
- 代码审查中发现风险时的处理决策
- 测试失败后的修复策略选择
- 发布前的检查点决策
**决策时间线视图**：按时间展示项目的所有决策，支持按类型/阶段筛选。
### 5.4 AI Orchestrator (df-ai)
- **LlmProvider trait**：统一接口，各模型实现（`provider.rs`）✅
- **ModelRouter**：按任务类型路由到最优模型 + 降级链 — ❌ 已删（R-PD-7），模型选择改由调用方在 `LlmProvider` 实现间直接指定
- **AgentCoordinator**：多 Agent 协作（Planner/Coder/Reviewer/Fixer）— ⚠️ 骨架空壳（`coordinator.rs`，仅单元结构体 + 日志，未实现实际协调）
- **ContextManager**：Token 预算管理（`context.rs`，完整实现）✅
- **ToolRegistry**：工具注册（`ai_tools.rs`，供 Agent 调用）✅
### 5.5 内置节点 (df-nodes)
| 节点 | 功能 | 状态 |
|------|------|------|
| AINode | 调用 LLM，支持流式输出、工具调用 | ✅ 已实现 |
| ScriptNode | Shell/脚本执行 | ✅ 已实现 |
| HumanNode | 人工审批/确认 (阻塞) | ✅ 已实现 |
| DockerNode | Docker 容器操作 | ❌ 未实现 |
| GitNode | Git 操作 (libgit2) | ❌ 未实现 |
| NotifyNode | 通知 (桌面/飞书/Webhook) | ❌ 未实现 |
| HTTPNode | HTTP 请求 | ❌ 未实现 |
| SubflowNode | 嵌套子工作流 | ❌ 未实现 |
> `crates/df-nodes/src/` 实际仅 ai_node / script_node / human_node 3 文件（Docker/Git/Notify/HTTP/Subflow 为设计预留，尚未实现）。详见 [df-nodes 模块文档](docs/03-模块文档/df-nodes-节点集合-2026-06-12.md)。
## 六、数据模型
### SQLite 表结构
> 真相源：`crates/df-storage/src/migrations.rs`（V1-V13，幂等迁移）。下表对齐真实 schema，字段/类型/默认值/外键与迁移文件一致。Rust 结构体见 `crates/df-storage/src/models.rs`。
共 **13 张业务表**（另含内部表 `schema_version` 记录迁移版本）。
```sql
-- 想法池 (V1 建表 / V2 补 promoted_to + ai_analysis + scores)
CREATE TABLE ideas (
id TEXT PRIMARY KEY,
title TEXT NOT NULL,
description TEXT NOT NULL DEFAULT '',
status TEXT NOT NULL DEFAULT 'draft', -- draft/pending_review/approved/rejected/promoted/archived
priority INTEGER NOT NULL DEFAULT 1,
score REAL,
tags TEXT, -- JSON 数组
source TEXT,
promoted_to TEXT, -- 晋升后的 project_id (V2)
ai_analysis TEXT, -- AI 分析结果 JSON (V2)
scores TEXT, -- 多维评分 JSON: feasibility/impact/urgency/overall (V2)
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL
);
-- 项目 (V1 建表 / V11 补 deleted_at / V12 补 path + stack)
CREATE TABLE projects (
id TEXT PRIMARY KEY,
name TEXT NOT NULL,
description TEXT NOT NULL DEFAULT '',
status TEXT NOT NULL DEFAULT 'planning',
idea_id TEXT REFERENCES ideas(id),
path TEXT, -- 绑定的本地代码目录绝对路径 (V12,可空=未绑定)
stack TEXT, -- 技术栈 JSON 数组字符串 (V12,探测填充)
deleted_at TEXT, -- 软删回收站: NULL=正常, 非空=已进回收站 (V11)
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL
);
-- 任务 (V1 建表 / V2 补 workflow_def_id + base_branch)
CREATE TABLE tasks (
id TEXT PRIMARY KEY,
project_id TEXT NOT NULL REFERENCES projects(id),
title TEXT NOT NULL,
description TEXT NOT NULL DEFAULT '',
status TEXT NOT NULL DEFAULT 'todo', -- todo/in_progress/in_review/testing/done/blocked/cancelled
priority INTEGER NOT NULL DEFAULT 1,
branch_name TEXT,
assignee TEXT,
workflow_def_id TEXT, -- 关联的工作流定义 ID (V2)
base_branch TEXT, -- 基础分支 (V2)
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL
);
-- 分支 (V2 建表) — 任务与 Git 分支绑定
CREATE TABLE branches (
id TEXT PRIMARY KEY,
project_id TEXT NOT NULL REFERENCES projects(id),
task_id TEXT REFERENCES tasks(id),
name TEXT NOT NULL,
base TEXT NOT NULL DEFAULT 'main',
status TEXT NOT NULL DEFAULT 'active',
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL,
merged_at TEXT
);
-- 发布计划 (V1 建表)
CREATE TABLE releases (
id TEXT PRIMARY KEY,
project_id TEXT NOT NULL REFERENCES projects(id),
version TEXT NOT NULL,
status TEXT NOT NULL DEFAULT 'planned',
task_ids TEXT NOT NULL DEFAULT '[]', -- JSON 数组: 包含的 Task ID 列表
changelog TEXT,
created_at TEXT NOT NULL,
released_at TEXT
);
-- 工作流执行 (V1 建表 / V2 补 project_id + task_id)
-- 注: 不区分 def/run, DAG 直接序列化进 dag_json, 一次执行一行
CREATE TABLE workflow_executions (
id TEXT PRIMARY KEY,
name TEXT NOT NULL,
dag_json TEXT NOT NULL, -- DAG 的 JSON 序列化
status TEXT NOT NULL DEFAULT 'pending', -- pending/running/paused/completed/failed/cancelled
triggered_by TEXT,
project_id TEXT, -- 关联项目 ID (V2)
task_id TEXT, -- 关联任务 ID (V2)
created_at TEXT NOT NULL,
completed_at TEXT
);
-- 节点执行 (V1 建表) — 工作流执行过程中每个节点的运行快照
CREATE TABLE node_executions (
id TEXT PRIMARY KEY,
workflow_id TEXT NOT NULL REFERENCES workflow_executions(id),
node_id TEXT NOT NULL,
node_type TEXT NOT NULL,
status TEXT NOT NULL DEFAULT 'pending',
input_json TEXT,
output_json TEXT,
error_message TEXT,
started_at TEXT,
completed_at TEXT
);
-- AI 提供商配置 (V9 建表) — 多 Provider 统一抽象
CREATE TABLE ai_providers (
id TEXT PRIMARY KEY,
name TEXT NOT NULL,
provider_type TEXT NOT NULL DEFAULT 'openai_compat',
api_key TEXT NOT NULL,
base_url TEXT NOT NULL,
default_model TEXT NOT NULL,
models TEXT, -- JSON array of model names
is_default INTEGER NOT NULL DEFAULT 0,
config TEXT, -- JSON extra config
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL
);
-- AI 对话 (V3 建表 / V4 补 archived / V5 补 prompt_tokens + completion_tokens / V6 补 models)
CREATE TABLE ai_conversations (
id TEXT PRIMARY KEY,
title TEXT,
messages TEXT NOT NULL DEFAULT '[]', -- JSON array of ChatMessage
provider_id TEXT,
model TEXT,
models TEXT, -- 用过的所有 model JSON 数组字符串 (去重, V6)
archived INTEGER NOT NULL DEFAULT 0, -- 是否归档(侧栏折叠展示, V4)
prompt_tokens INTEGER, -- 输入 token 累计 (流式 usage 落库, V5)
completion_tokens INTEGER, -- 输出 token 累计 (流式 usage 落库, V5)
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL
);
-- AI 工具执行审计 (V9 建表) — Agent 工具调用的审批/执行留痕
CREATE TABLE ai_tool_executions (
id TEXT PRIMARY KEY,
conversation_id TEXT,
tool_call_id TEXT NOT NULL,
tool_name TEXT NOT NULL,
arguments TEXT NOT NULL,
result TEXT,
status TEXT NOT NULL DEFAULT 'pending', -- pending/approved/rejected/executing/completed/failed
risk_level TEXT NOT NULL DEFAULT 'medium', -- low/medium/high
requested_at TEXT NOT NULL,
executed_at TEXT,
decided_by TEXT -- human/auto
);
-- 知识条目 (V7 建表 / V8 补 embedding / V10 补 reasoning) — 经验沉淀基本单元, 共享记忆层
-- 状态机: candidate → pending_review → published → archived
CREATE TABLE knowledges (
id TEXT PRIMARY KEY,
kind TEXT NOT NULL DEFAULT 'pitfall', -- 7 种: review_rule/prompt_template/pitfall/architecture_pattern/diagnosis/deployment_note/workflow_optimization
title TEXT NOT NULL,
content TEXT NOT NULL DEFAULT '',
tags TEXT, -- JSON 数组字符串
status TEXT NOT NULL DEFAULT 'candidate', -- candidate|pending_review|published|archived
confidence TEXT, -- high|medium|low (AI 提炼自评)
reuse_count INTEGER NOT NULL DEFAULT 0, -- 唯一客观排序信号
verified INTEGER NOT NULL DEFAULT 0, -- 发布审核时一次性人工标
source_project TEXT, -- 来源项目(仅溯源不过滤)
source_ref TEXT, -- 来源实体引用(如 conv:{id})
reasoning TEXT, -- AI 提炼判断依据("为何值得沉淀"), 手动录入为 NULL (V10)
embedding BLOB, -- Vec<f32> 小端字节序列化, NULL=未嵌入走 LIKE 降级 (V8)
created_at TEXT NOT NULL,
updated_at TEXT NOT NULL
);
-- 知识生命线事件 (V10 建表) — 追加型审计: 产生/审核/引用/归档
CREATE TABLE knowledge_events (
id TEXT PRIMARY KEY,
knowledge_id TEXT NOT NULL,
event_type TEXT NOT NULL, -- created | extracted | status_changed | referenced | archived
source_ref TEXT, -- 触发来源: conv:{id} / manual / system
context_json TEXT, -- JSON: 因 event_type 而异
timestamp TEXT NOT NULL
);
-- 通用应用设置 (V13 建表) — 前端 localStorage 迁移目标 KV 表
CREATE TABLE app_settings (
key TEXT PRIMARY KEY,
value TEXT NOT NULL, -- JSON 字符串
updated_at TEXT NOT NULL
);
-- 内部表: schema_version (version INTEGER PRIMARY KEY) — 迁移版本记录
```
## 七、三层模型：模板 → 工作流 → 人设
### 7.1 三层定义
| 层 | 回答的问题 | 本质 | 生命周期 | 当前状态 |
|----|-----------|------|---------|---------|
| **流程模板 (Template)** | 应该做什么 | 可复用的蓝图（节点拓扑 + 建议人设 + 质量门禁） | 长期存在，跨项目复用 | ⚡ 需重新设计（原 df-stages 已移除） |
| **工作流 (Workflow)** | 怎么执行 | 模板的运行时实例（DAG + 状态 + 数据绑定） | 随项目启停，单次执行归档 | ✅ df-workflow 核心完成 |
| **人设 (Persona)** | 谁来做 | Agent 角色卡（system prompt + 工具集 + 行为规则） | 长期存在，跨节点复用 | ⬜ 待设计 |
### 7.2 三者关系
```
流程模板 (蓝图)
│ 实例化（填入项目参数）
▼
工作流实例 (运行时 DAG)
│ 分配人设（绑定到每个 AINode）
▼
人设驱动 Agent 执行
```
**关键点**：
- 模板不绑定具体人设，只标注"建议人设类型"，实例化时由用户覆盖
- 工作流不感知人设，只管 DAG 执行；人设注入发生在 AINode 执行时
- 人设与模板解耦：同一个人设可用于不同模板的同类节点
### 7.3 模板实例化流程
```
① 选择模板 → "功能开发模板"
模板定义: [需求分析]→[架构设计]→[编码]→[测试]→[审查]→[发布]
建议人设: analyst → architect → coder → tester → reviewer → none
② 实例化为工作流 DAG
┌─ AINode(需求分析) 建议人设: analyst
├─ AINode(架构设计) 建议人设: architect
├─ AINode(编码) 建议人设: coder
├─ AINode(单元测试) 建议人设: tester
├─ ScriptNode(运行测试) 无人设（纯脚本）
├─ HumanNode(审批发布) 无人设（人工）
└─ AINode(发布说明) 建议人设: writer
③ 实际分配人设（可覆盖）
编码节点 → coder-rust（项目是 Rust 后端）
测试节点 → tester-py（测试框架是 Python）
④ 执行
工作流引擎按 DAG 拓扑调度节点
每个 AINode 执行时载入对应人设的 system_prompt + 工具集
NodeContext 中传递 persona_id，AI Node 据此取人设配置
```
### 7.4 人设定义
```rust
/// 智能体人设（Agent 角色卡）
pub struct AgentPersona {
pub id: PersonaId,
pub name: String, // 人设名称
pub description: String, // 一句话描述
pub system_prompt: String, // 角色系统提示词
pub allowed_tools: Vec<String>, // 可用工具列表
pub suggested_tier: ModelTier, // 推荐模型层级
pub output_format: OutputFormat, // 输出格式约束
pub rules: Vec<BehaviorRule>, // 行为规则
pub examples: Vec<PersonaExample>, // Few-shot 样例
}
// 预置人设（平台内置，用户可自定义扩展）
Persona::coder → "你是资深 Rust/TS 工程师..."
Persona::reviewer → "你是代码审查员，关注安全漏洞..."
Persona::architect → "你是系统架构师，关注模块划分..."
Persona::tester → "你是测试工程师，生成边界用例..."
Persona::analyst → "你是需求分析师，拆解用户故事..."
```
### 7.5 模板示例：功能开发模板（YAML）
```yaml
# templates/feature-dev.yaml
id: feature-dev
name: 功能开发模板
description: 标准功能开发流程，从需求分析到发布
template_version: 1
nodes:
- id: analysis
type: ai
persona_hint: analyst
prompt: "分析以下需求：{{inputs.requirement}}"
inputs:
requirement: "$ctx.requirement"
outputs:
prd: text
- id: design
type: ai
persona_hint: architect
prompt: "基于 PRD 设计架构：{{inputs.analysis.prd}}"
inputs:
analysis: "$nodes.analysis"
outputs:
arch_doc: text
- id: coding
type: ai
persona_hint: coder
prompt: "按架构设计实现：{{inputs.design.arch_doc}}"
inputs:
design: "$nodes.design"
outputs:
code: text
- id: review
type: ai
persona_hint: reviewer
prompt: "审查代码：{{inputs.coding.code}}"
inputs:
coding: "$nodes.coding"
quality_gates:
- node: review
condition: "output.verdict == 'pass'"
on_fail: "goto coding"
artifacts:
prd: "$nodes.analysis.prd"
code: "$nodes.coding.code"
review_report: "$nodes.review.text"
## 八、Phase 规划
### Phase 1 — 引擎骨架 (4-6 周)
- df-core + df-workflow (DAG + Node trait + Executor)
- df-storage (SQLite 基础表)
- df-execute (Shell 执行)
- 最小前端：项目列表 + 工作流执行日志
- 验证：能跑通一个 3 节点的简单工作流
### Phase 2 — AI 集成 (3-4 周)
- df-ai (Multi-Provider + Router + Stream)
- AI Chat 面板
- AI Node 实现
- 验证：AI 节点能流式输出到前端
### Phase 3 — 想法池 + 多项目 (3-4 周)
- df-ideas (捕捉/评估/评分/晋升)
- df-project (多项目调度/上下文)
- 前端：想法池视图 + 多项目 Tab
- 验证：想法捕捉 → AI 评估 → 立项 → 工作流执行
### Phase 4 — 节点丰富 + 三层模型落地 (3-4 周)
- df-nodes (Docker/Git/Human/HTTP)
- 流程模板系统（YAML 定义 + 模板库 + 实例化引擎）
- 人设系统（AgentPersona 数据结构 + 内置人设 + 工具过滤）
- 条件分支 + 断点续跑
- 验证：跑通标准产研流程模板
### Phase 5 — 体验打磨 (4-6 周)
- 拖拽式 DAG 编辑器
- Dashboard + Timeline
- 工作流模板市场
- 桌面通知 + 系统托盘
- 自动更新
- 发布 v1.0
## 九、与现有资产的关系
| 现有资产 | 关系 |
|---------|------|
| u-desk-rust (Tauri v2) | 复用架构经验：Workspace + crate 拆分 + Vue 3 传输层 |
| workpod (Docker) | DockerNode 的执行后端，API 集成 |
| proxy 工具链 (Rust) | 连接管理 + 执行后端，内嵌调用 |
| Skills 体系 | 核心逻辑迁移为节点模板，不保留 skill 形态 |
| product-delivery-control | 演进为「标准产研工作流模板」 |
| mission-control | 合同/质量门禁机制融入 Workflow Engine |
| CPA (LLM 代理) | AI Provider 之一 |
## 十、关键设计决策
1. **引擎不绑定业务**：Workflow Engine 只做 DAG 执行，阶段是插件
2. **想法第一公民**：想法池独立于项目，持续运转
3. **多项目并行**：多项目同时推进，共享资源池
4. **多任务/分支并行**：同一项目内多任务各绑分支，独立工作流，完成后合并
5. **标注无处不在**：FIXME/TODO/QUESTION 标注可附加在任何内容上，批量收集→AI 处理
6. **需求-测试双向追溯**：功能可选做/延/不做，每个功能映射测试用例和报告
7. **决策必留痕**：所有关键决策自动记录，可追溯、可审计
8. **本地优先**：SQLite 嵌入，不依赖云服务
9. **多模型并行**：统一抽象，按任务路由，不锁定单一模型
10. **流式优先**：AI 输出、Shell 输出全部流式推送到前端
11. **模板/工作流/人设三层分离**：模板是蓝图，工作流是实例，人设是角色卡。三层各自独立演化，在 AINode 执行时交汇
12. **人设与模板解耦**：模板标注建议人设但不绑定，同一个人设可用于不同模板的同类节点
13. **模板实例化**：模板 → 工作流实例 + 人设分配，允许实例化时按项目覆盖人设
Reference in New Issue View Git Blame Copy Permalink