- 更新 P2 切读方案文档(确认批次B已上线) - ㉑ query LIKE 通配符转义(project/idea/task/knowledge 4 处) - ⑱ dag.rs deep_merge null 覆盖全局配置 - ⑲ dag.rs _ 通配 match 展开显式变体 - ⑩ INDEX.md 补漏 10 个文档索引 - ⑫ ARCHITECTURE.md 删除与新文档逐字重复 - ㉒ coordinator.rs 加 #[deprecated] 编译守卫 - ㉛ AiChat.vue 空值传播加 console.warn
31 KiB
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 |
关键设计原则
- AI 工具注册表是主接口:IPC 就绪后必须立刻注册为 AI 工具,页面是旁路查看器
- 页面降级为「查看层」:Dashboard / Projects / Tasks / Ideas 等页面用于事后查看、审计、回放
- 功能优先级 = AI 工具覆盖度:人对模块的操作能力取决于 AI 工具注册表中该模块的工具是否完整
- 灵感 / 项目 / 任务 三模块的 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)
合并协调:
- 冲突检测:Task 完成时自动检测与 main 的冲突
- AI 辅助解决:冲突文件交给 AI 分析并建议解决方案
- 发布编排:选择多个 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)
所有关键决策自动或半自动记录,全程可追溯。
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 模块文档。
六、数据模型
SQLite 表结构
真相源:
crates/df-storage/src/migrations.rs(V1-V13,幂等迁移)。下表对齐真实 schema,字段/类型/默认值/外键与迁移文件一致。Rust 结构体见crates/df-storage/src/models.rs。
共 13 张业务表(另含内部表 schema_version 记录迁移版本)。
-- 想法池 (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) — 迁移版本记录
七、三层模型:模板 → 工作流 → 人设
本章详细设计已迁至专项文档,详见 docs/02-架构设计/专项设计/三层模型-流程模板与人设体系-2026-06-28.md。此处仅保留摘要性定义。
7.1 三层定义
| 层 | 回答的问题 | 本质 | 生命周期 | 当前状态 |
|---|---|---|---|---|
| 流程模板 (Template) | 应该做什么 | 可复用的蓝图(节点拓扑 + 建议人设 + 质量门禁) | 长期存在,跨项目复用 | ⚡ 需重新设计(原 df-stages 已移除) |
| 工作流 (Workflow) | 怎么执行 | 模板的运行时实例(DAG + 状态 + 数据绑定) | 随项目启停,单次执行归档 | ✅ df-workflow 核心完成 |
| 人设 (Persona) | 谁来做 | Agent 角色卡(system prompt + 工具集 + 行为规则) | 长期存在,跨节点复用 | ⬜ 待设计 |
关键原则:模板不绑定具体人设、工作流不感知人设、人设与模板解耦。
详细定义、三者关系、实例化流程、数据结构及 YAML 模板示例见 专项设计文档。
八、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 之一 |
十、关键设计决策
- 引擎不绑定业务:Workflow Engine 只做 DAG 执行,阶段是插件
- 想法第一公民:想法池独立于项目,持续运转
- 多项目并行:多项目同时推进,共享资源池
- 多任务/分支并行:同一项目内多任务各绑分支,独立工作流,完成后合并
- 标注无处不在:FIXME/TODO/QUESTION 标注可附加在任何内容上,批量收集→AI 处理
- 需求-测试双向追溯:功能可选做/延/不做,每个功能映射测试用例和报告
- 决策必留痕:所有关键决策自动记录,可追溯、可审计
- 本地优先:SQLite 嵌入,不依赖云服务
- 多模型并行:统一抽象,按任务路由,不锁定单一模型
- 流式优先:AI 输出、Shell 输出全部流式推送到前端
- 模板/工作流/人设三层分离:模板是蓝图,工作流是实例,人设是角色卡。三层各自独立演化,在 AINode 执行时交汇
- 人设与模板解耦:模板标注建议人设但不绑定,同一个人设可用于不同模板的同类节点
- 模板实例化:模板 → 工作流实例 + 人设分配,允许实例化时按项目覆盖人设