绝尘
998a2f243d
squash合并: - 意图识别层论证(8维度+10业界佐证) - 多主题上下文管理愿景+并存论证+补充论证(多轮agentic) - 架构设计文档物理分类(四子目录+INDEX+命名规范+引用同步+边界清晰化) - 前端架构技术债清单归档
7.6 KiB
7.6 KiB
DevFlow 对抗论证裁决报告
创建: 2026-06-11 | 方法: 三路对抗论证（市场/技术/需求） | 结论: 方向有价值，scope 必须砍
一、论证方法
用"魔法打败魔法"：三个独立 AI 代理分别从不同立场攻击这个项目，互不可见，最后综合裁决。
| 代理 | 立场 | 综合评分 |
|---|---|---|
| 市场分析师 | 竞品全景 + 市场数据（带外部信源） | 4/10 — 不建议以当前形态推进 |
| 技术架构师 | 13 crate（2026-06-12 评审时数；2026-06-14 删 5 僵尸 crate，现 8）/ Tauri / 引擎 / AI 可行性 | 2.7/5 — 可行但必须砍 scope |
| 恶魔代言人 | 逐功能质疑需求真实性 | 核心成立，60% 功能该砍 |
二、三方共识（站不住脚的地方）
共识 1：🔴 Scope 失控是最大风险
- 8 个核心功能横跨 4-5 个产品类别（PM + 工作流 + AI 编排 + 代码分析 + 知识库）
- 22,745 字架构文档、16 张表、13 crate（评审时点数；2026-06-14 裁定为 8 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 生成处理建议 → 一键转任务
- 砍掉"任意实体标注"的重设计
四、站得住脚的部分
- 本地优先 — Obsidian 证明了本地优先工具有大市场，订阅疲劳（52% 用户因此退订）反推一次性付费
- Tauri 技术栈 — 比 Electron 小 96%，选型正确（4/5）
- 引擎代码质量 — 拓扑排序算法正确、trait 设计合理、依赖树无环
- 任务绑 Git 分支 — 6/10，最有价值的业务功能，做深"任务→分支→提交→合并→关单"全链路有空间
- 对抗式想法评估 — 这是本次论证方法本身的产品化，市场上没有工具这么做
五、调整方案
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 保留目录结构（评审时点；2026-06-14 裁定删除 5 个僵尸 crate df-evolve/df-plugin/df-stages/df-task/df-traceability，现实际 8 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-模块文档/想法探索-对抗式评估-2026-06-12.md。这是 DevFlow 吃自己的狗粮的第一个案例。