绝尘
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
144 lines
7.4 KiB
Markdown
144 lines
7.4 KiB
Markdown
# 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 吃自己的狗粮的第一个案例。
|