DevFlow/docs/02-架构设计/功能创意池-2026-06-14.md

功能创意池 — 2026-06-14

性质: 创意池 / 待评估(非已定决策。评估通过后才转正式 concept 文档 + 进 todo) 关联: df-ideas · df-workflow · df-ai · Decision 实体 · 规格契约自检机制 生成背景: 基于当前系统做功能架构创意,尽量避开已构想范围(创意 4/5 与规格契约自检为延伸关系,见各创意独创列) 修订: 2026-06-14 自审后修订 —— 可行性论证诚实化(复用/新造分清)、创意 4/5 重定位为规格契约自检延伸、首选从 4 改为 1、每创意补「难点与风险 + 失败模式」

---

一、怎么用这个池子

• 每个创意 = 一个候选功能方向,非已定决策
• 状态流转: 💡待评估 → 📐待设计(立 concept 文档) → 🔨待实施(进 todo)
• 评估维度: 新颖性 / 实用价值 / 可行性 / 与现有构想的差异度
• 转正流程: 评估通过 → 单独立 <主题>-concept.md(参考 任务推进构想-2026-06-14.md 风格)→ 进 todo

二、已避开的方向(防重复提案)

已有/已构想方向	落点
AI-First 任务推进链(三闸门)	任务推进构想-2026-06-14.md 已设计
对抗式想法评估(三路论证)	df-ideas 启发式版已实现
工作流审批子系统	Wave5 已完成
对话内异步审批	aichat异步审批构想-2026-06-14.md
信息密度优化(折叠)	aichat信息密度构想-2026-06-14.md
模型能力系统/路由	todo F-260614-01
数据变更联动刷新	todo AR-11
创作模板系统	todo 已构想
知识库 MCP Server	todo F-260614-10
规格契约自检(活契约+AI自检)	规格契约自检机制-2026-06-14.md。⚠️ 创意 4/5 是其延伸(从一致性 → 陈旧度/回归),非完全避开

本池 5 个创意切入的空白维度: 演化 · 时效 · 回溯 · 债务 · 契约

---

三、创意清单

每个创意含: 核心表格(可行性列区分「复用」与「新造」)+ ⚠️ 难点与风险 + 💀 失败模式

1. 想法演化图谱(Idea Genealogy Graph) 💡待评估 ⭐首选评估

维度	内容
核心	给想法做版本控制: 分裂(A→A1/A2 变体)、合并(B+C→D)、演化(A1→A2 迭代)。形成有向演化树,而非当前扁平列表。注: related_ideas 字段是否真闲置待核实
独创	中。把想法当"活体"追踪血统,区别于笔记/看板的扁平存储。但"分裂/合并"本质是版本控制 + 关系图(Git 已是此模型),套到想法上是应用层创新,非机制创新
价值	独立开发者痛点: 想法散落、重复想同一件事而不自知。演化图能回答"这想法三年前想过、演变成啥、为何没做"
可行性	复用: Idea 实体加 parent_id / derived_from[] / merged_into 三字段 + 前端复用 df-workflow DAG 可视化 + 评分引擎增量重算子树。新造: 关系建立机制(见难点,是真正成本所在)
落地关键	关系字段建模 + 演化树渲染 + 分裂/合并交互

⚠️ 难点与风险

• 关系谁来建是核心漏洞: 手动建 → 用户不知两想法相关,图谱永远稀疏;AI 辅助建 → 需语义相似度检索(当前 df-ideas 无此能力),不是"加三字段"那么轻
• 演化树布局算法非平凡(多层 DAG 节点排布,复用 DAG 可视化但树 ≠ 工作流 DAG)
• 关系正确性: 错误的合并/分裂会污染反推的产品方向

💀 失败模式: 图谱稀疏(没人建关系)→ 沦为摆设;或 AI 误判相似度 → 错误合并污染演化树。

2. 灵感孵化器(Idea Incubator) 💡待评估

维度	内容
核心	评估为 Defer / 低分的想法进"孵化器"。三类事件触发自动再评估: ①新技术栈匹配能力;②新想法建立演化关联;③固定周期(如 30 天)。时机成熟浮出提醒
独创	中。承认想法有时效性,把评估从"快照"变"持续监听"。但"延迟队列 + 条件触发"是通用模式,挂到想法上是场景应用
价值	好想法死于"现在不是时候"后被遗忘。背景静默复检,贴合产研节奏
可行性	复用: adversarial.rs 评估管线(已预留 LLM 接口)。新造: incubator 表 + 后台 ticker + 触发条件 DSL。注意: 评估当前手动触发(晋升走前端),后台自动重评估触及触发机制,非纯增量
落地关键	触发条件 DSL + 后台 ticker + 浮出提醒

⚠️ 难点与风险

• 评估从手动 → 自动触及核心链路(触发机制改造),不是"纯增量不碰核心"
• 触发条件①"新技术栈匹配"要求 Idea 能表达"我需要什么技术栈",当前 Idea 实体无此字段 —— 可行性有前置漏洞
• 依赖创意 1: 触发器②"演化关联"依赖创意 1 的演化关系先存在(见第四节依赖)

💀 失败模式: 触发条件太宽 → 频繁打扰变垃圾提醒;太窄 → 永不触发,等同丢弃。

3. 执行回放时间线(Execution Replay) 💡待评估

维度	内容
核心	工作流执行 + Git commit + AI 决策录制为不可变时间线。可回退到任意历史节点,隔离环境改参数重放分支(what-if),对比结果差异
独创	中。可回放工作流是成熟模式(temporal/cadence 的 event sourcing + replay)。独创点应收敛到"决策级 what-if 回放"(面向产研决策维度的假设检验),工作流回放只是载体,非独创本身
价值	回答"如果当时审批选了另一分支会怎样""AI 节点为何这么决策"。对复盘、调试失败工作流价值高
可行性	复用: df-execute Docker 隔离 + df-workflow DAG / node IO 结构化。新造: 节点 IO 快照持久化 + 状态机重放 + 副作用处理。注意: Docker 隔离 ≠ 可重放,隔离只解决执行环境,快照/重放是新工作量
落地关键	节点 IO 快照持久化 + 隔离环境重放 + diff 对比视图

⚠️ 难点与风险

• "架构已铺好差最后一公里"高估 —— 最后一公里(快照序列化 + 状态机重放 + 副作用处理)可能是最难的
• 副作用处理: 有外部副作用的节点(写文件/调 API)无法纯重放,需标记 + mock
• 存储成本: 全程录制 IO,长期项目存储膨胀

💀 失败模式: 副作用节点无法重放 → what-if 结果失真;或快照存储膨胀 → 用户关闭录制。

4. 上下文债务追踪(Context Debt Tracker) 💡待评估

维度	内容
核心	AI 定期审计项目"隐式债务": ①引用已删除文件的决策;②"暂时如此"从未回头的 TODO;③前提假设失效;④重复实现/废弃路径。生成债务报告 + 偿还优先级
独创	中高(重定位): 本创意是 规格契约自检机制的延伸 —— 从"AI 自检决策规格是否被遵守(一致性)"扩展到"AI 自检决策是否腐化(陈旧度)"。非全新方向,是规格契约自检的第二个应用维度
价值	长期项目头号隐性成本是"上下文腐化"。让 AI 当项目审计师。对维护多项目尤其救命
可行性	复用: df-project Git/路径扫描 + Decision 实体 + df-ai 路由 + df-nodes agent 抽象。新造: 债务探测器 agent + 偿还优先级算法。注意: agent 跨文件推理判断"前提失效"可靠性存疑,"纯 agent 编排"低估了质量风险
落地关键	债务类型分类 + 探测 agent + 偿还优先级算法(未定义,核心难点)

⚠️ 难点与风险

• 依赖多项目基础(未就绪): 价值高度依赖"一人维护多项目"场景,而 devflow 当前单项目/本地优先,导入历史项目(todo)未做。时序倒置
• agent 跨文件推理可靠性: 误判"前提失效"会误报,误报泛滥 → 用户关闭
• 偿还优先级算法无现成方案,需自设计

💀 失败模式: agent 误报泛滥 → 用户关闭功能;或单项目场景下债务量不足以体现价值。

5. 决策回归守护(Decision Regression Guard) 💡待评估

维度	内容
核心	关键决策绑定可执行验证契约("选 A 因性能优" → 绑性能基准脚本)。代码变更触及相关模块(Git diff 关联)时守护自动重跑;契约失败 = 决策失效,阻断发布或报警
独创	中(降级): 实现机制等同测试(跑脚本验证断言),差异仅在断言语义来源(决策 vs 需求)。准确定位为"决策驱动的测试生成" —— 独创点在从决策自动生成守护测试,非守护机制本身
价值	解决"决策当初对、后来悄悄变错"的隐患
可行性	复用: df-workflow DAG + df-execute 脚本执行 + Decision 实体 + Git diff。新造: 契约绑定语法 + 守护触发节点。注意: 审批(事前)与守护(事后持续)机制不同,Wave5 审批基座未必直接复用为持续触发
落地关键	契约绑定语法 + Git diff 关联触发 + 失效阻断策略

⚠️ 难点与风险

• 与创意 4 争抢 Decision 实体扩展: 4 要腐化审计标记,5 要 guard_contract 字段。若都做需先定义 Decision 统一扩展模型
• 从决策文本自动生成有意义的守护测试,LLM 生成质量是瓶颈
• "代码变更触及相关模块"的关联判定(Git diff → Decision)需决策到代码的映射,无现成方案

💀 失败模式: LLM 生成的守护测试无意义/假通过 → 守护形同虚设;或关联判定不准 → 该触发没触发。

---

四、优先级建议

创意	落地难度	独创性	依赖	建议
1 想法演化图谱	低	中	无	⭐首选评估: 改动最局限(df-ideas)、依赖最少,但先解"关系谁来建"漏洞
2 灵感孵化器	中	中	依赖 1 的演化关系字段	与 1 有依赖非并行;独立做需砍"演化关联"触发器
5 决策回归守护	中	中	与 4 争 Decision 扩展	决策驱动测试生成,待 LLM 生成质量成熟
4 上下文债务追踪	中高	中高	依赖多项目基础(未就绪)	价值高但时序靠后 —— 等"导入历史项目"做完
3 执行回放	高	中	副作用处理/存储成本	工作量最大,后置;独创点重定位为决策级回放

首选变更说明: 原⭐推荐创意 4,自审后发现三理由均打折(痛点依赖多项目/无需新基建被高估/差异化因与规格契约自检重叠而削弱),且依赖未就绪的"导入历史项目"基础,降级。首选改创意 1 —— 改动最局限、依赖最少,但须先解决「演化关系建立机制」核心漏洞。

---

五、后期跟进入口

1. 选一个创意(首选 1 演化图谱,先解关系建立机制;4 债务追踪价值最高,但等"导入历史项目"基础就绪)
2. 走 devflow 自身评估链: df-ideas 对抗评估(启发式 → LLM)
3. 评估通过 → 立 <主题>-concept.md → 进 todo
4. 本池对应创意状态改为 📐待设计

---

相关: 想法探索-对抗式评估 · 任务推进构想 · 规格契约自检机制