主题
00 · 研究框架与方法论
⚠️ 已被取代(2026-05-19):本框架(v1)被"占位当成熟"偏差咬穿三次,11 框架 v2 取代本文为方法论真源;全专题定稿见 14 定稿总纲。00–08 为过程轨迹,按 11/12/14 限定理解,勿据本文单独决策。
本文件先于一切结论存在。它定义"凭什么相信后面的分析"——标尺、证据标准、分析流水线、偏差控制。 后续 01–08 都是这套框架的"执行实例"。框架可被质疑/替换;质疑请先驳本文。
A. 研究目标与边界
A.1 核心问题(可证伪地表述)
给定需求文档
智能会议专题.md(è§ a-cdm ä»åº docs/requirements/) 描述的"录音→口水稿→纪要→分析→待办→PDCA 闭环", 在 a-cdm 当前真实代码状态下,要把它推进到"可用"乃至"好用",存在哪些可行实现路径,各自的工程代价、架构风险、与现有底座的契合度如何,应按什么顺序推进。
它不是"做不做得到"(底座已证明能做),而是"哪条路、多大代价、什么顺序、避哪些坑"。
A.2 边界(明确不做什么)
- 不重写平台:deer-flow vendored 原生目录只读;改动限扩展点(项目红线)。
- 不在 main 直接 commit:本研究只产出
docs/reports/下文档,不改业务代码;落地由后续 MR 承接。 - 不替需求做产品决策:研究给"方案空间 + 取舍 + 推荐",最终选型留给人(产品/技术负责人)。
- 聚焦会议域 PDCA 主干:ASR 选型、报告 skills 横向扩展等列入但不展开到实现细节(标注为后续专项)。
A.3 成功标准(本研究自身的 DoD)
- 每条现状结论有
file:line或 spec/wiki 出处;矛盾点已交叉核验并消解。 - 每个关键差距给 ≥2 个可行方案,带统一口径的取舍矩阵与明确推荐。
- 路线图每阶段有可验收门(对齐 §B 标尺),不是"做完了"而是"达到了哪档 bar"。
- 风险登记册覆盖竞品验证过的花架子陷阱 + 本项目特定红线 + 本研究自身偏差。
B. 评估标尺(严谨性的核心)
任何"该做什么/做到什么程度"的判断,都必须落到下面两个正交维度上,不允许凭感觉。
B.1 双档 Bar(纵向:做到什么程度)
- 可用基线 Bar(Usable):不达标 = 用户用一两次就弃。判据偏"不出明显错 + 不变孤岛"。
- 好用粘性 Bar(Sticky):达标 = 进团队工作流、产生留存。判据偏"跨会连续性 + 可核验 + 闭环到执行"。
每个能力单元都要分别写这两档的完成定义(DoD),路线图按"先全员够到可用 Bar,再逐项抬到好用 Bar"推进。
B.2 六维评分(横向:从哪些角度评一个方案/现状)
| 维 | 关注 | 0 分锚 | 3 分锚 |
|---|---|---|---|
| ① 功能完整度 | 需求层能力是否齐 | 能力缺失/仅 stub | 覆盖该层"好用 DoD" |
| ② 可信度·防幻觉 | 产物能否回溯原文、AI/人是否可辨 | LLM 黑箱、无 source_span | 每条结论一键回原文+时间戳/行号,AI vs 人审可辨 |
| ③ 闭环度 | 是否接入执行系统、状态是否回流 | 产物躺着没人回访(孤岛) | 待办状态双向、下次会自动 Check |
| ④ 可逆性 | 是否进 substrate(软删/事务/回收站) | 物理删除、不可回滚 | 全操作走 business_transaction / 可逆存储 |
| ⑤ 性能·成本 | LLM 调用次数、缓存命中、长上下文 | 每次重扫 transcript、无缓存 | 版本化缓存 + 增量,长会多 pass 不丢中段 |
| ⑥ 可运维 | 降级开关、部署 SOP、契合现有架构 | 无开关、改动跨 vendored 只读层 | 有降级 env、走既有部署 SOP、扩展点接入 |
| ⑦ 原生杠杆度 | 是否基于 deer-flow 原生能力二开 | 绕开/对抗原生,在 acdm-backend 自建重复机制(skill 调度/记忆/上下文/委派) | 直接复用 deer-flow 原生 skill/pipeline/subagent/memory/middleware,二开仅在既有扩展点薄接入 |
B.3 首要设计原则(凌驾性):deer-flow 原生杠杆优先 = 事半功倍
当多个方案都能达到同一档 bar 时,第 ⑦ 维(原生杠杆度)是首要排序键,优先级高于"代码量更少""更灵活"等直觉。
具体判据(选型时逐条过):
- 能用 deer-flow 原生 skill 解决的,不在 acdm-backend 写服务(PDCA 复盘/周月报 = skill,不是 BFF endpoint)。
- 确定性多步链路用原生 pipeline(
langgraph.json/aegra.json注册),不自造编排器(ASR→纪要→抽取→待办 = pipeline 节点,复用weekly_report/meeting_aggregator_realtime形态)。 - 会话开场注入用原生中间件链(
DynamicContextMiddleware/custom_middlewares扩展点),不在控制面塞 BFF 拼接(Check 自动注入 = before_agent 中间件)。 - 跨会记忆/聚合优先压在原生长期记忆与上下文工程上(摘要/循环检测/记忆 namespace),acdm-backend 只做原生确实不承载的强一致结构化持久(待办状态机/归并这种需事务与查询的,才落 PG)。
- 自建是例外,必须证明"原生无法承载":在 05 每个推荐里显式回答"为什么不能纯原生"。
- 任何自建都走扩展点,绝不碰 vendored 只读层(
config.yaml/skills/custom//subagents.custom_agents/custom_middlewares/acdm-backend BFF)。
一句话:先问"deer-flow 原生有没有现成的",再问"扩展点能不能接",最后才考虑 acdm-backend 自建,且自建要被质疑。
C. 证据标准(防止"看起来很有道理"的空话)
| 主张类型 | 必须满足的证据标准 |
|---|---|
| "代码里有/没有 X" | file:line 或 grep/读文件实证;单 agent 报"不存在"必须二次核验(absence-of-evidence 偏差) |
| "需求文档说 live 的其实没有" | 必须同时给:需求原文位置 + 代码实证 + drift 消解解释(为什么文档会这么写) |
| "竞品都这么做" | 给来源链接;竞品宣称数字标注"含营销成分,仅作量级锚" |
| "应该用方案 X" | 给 ≥2 方案 + 6 维取舍矩阵 + 推荐理由 + 反对理由(devil's advocate) |
| "工程量约 N 人日" | 标注为粗估、给出估算依据(新增表/服务/节点的可比对象),不假装精确 |
D. 分析流水线(分阶段执行,逐阶段落库)
研究本身就是一条单向数据流 + 可回滚 pipeline(刻意呼应需求的设计哲学):
S0 框架/标尺 ──▶ S1 标尺细化+DoD ──▶ S2 现状核验/基线 ──▶ S3 平台积木盘点
│
S8 执行摘要 ◀── S7 风险登记 ◀── S6 路线图 ◀── S5 方案空间 ◀── S4 差距分析| 阶段 | 输入 | 动作 | 输出(落库) | 验收 |
|---|---|---|---|---|
| S0 | 需求文档 + 4 路 agent 研究 | 立框架/标尺/证据标准/偏差控制 | 00 | 标尺正交可打分;流水线可分阶段 |
| S1 | S0 + 需求 §1 + 竞品 bar | 6 维锚 + 每层"可用/好用"DoD | 01 | 每层 DoD 可验收、可证伪 |
| S2 | 代码 + spec + wiki | 实证现状、消解 drift、6 维打分 | 02 | 每结论有出处;矛盾已消解 |
| S3 | 代码 + 上游 wiki | 盘点可复用积木 + 挂载点 | 03 | 每积木有 file:line + 接入点 |
| S4 | S1−S2 | 目标减现状,差距分类与量级 | 04 | 差距可追溯到 DoD 与代码 |
| S5 | S4 + S3 | 每关键差距 ≥2 方案 + 取舍 + 推荐 | 05 | 取舍矩阵同口径;推荐有据 |
| S6 | S5 | 阶段化、依赖图、每阶段验收门 | 06 | 每阶段对齐某档 bar |
| S7 | 竞品 + 红线 + 本研究 | 花架子陷阱/项目红线/偏差控制 | 07 | 每风险有触发条件+缓解 |
| S8 | S0–S7 | 决策者一页结论 | 08 | 非技术读者可据此决策 |
每阶段产出独立文件,README.md 进度表实时更新——这就是"过程落库",可追溯、可回滚、可被他人接续。
E. 偏差与效度控制(这套研究自身的"红线")
严谨的研究必须先承认自己会怎么错,并预设对冲:
| 偏差 | 表现 | 对冲 |
|---|---|---|
| Absence-of-evidence | 单 agent 没搜到就断言"不存在" | 关键"不存在"结论二次核验(grep models/api/skills/openspec 多源);本研究已对 todo/minutes/atom-kinds 做过(见 02) |
| 需求文档权威性偏差 | 把需求文档自述状态当事实 | 代码 > 文档;文档与代码冲突时以代码为准并显式标 drift |
| 竞品光环 | 把竞品宣传当能力基线 | 数字标"营销成分";区分"产品做了"vs"做好了" |
| 方案单恋 | 只给一个"标准答案" | 强制每关键差距 ≥2 方案 + 给每个推荐写"反对理由" |
| 底座过度乐观 | "平台都有,接上就行" | 每个"复用积木"必须给具体挂载点和不触碰 vendored 只读层的证明 |
| 范围蔓延 | 把 ASR/报告横扩等全塞进主干 | 主干 = PDCA 闭环;周边标"专项",路线图分相 |
F. 关键术语对齐(避免后文歧义)
- 原子(atom):AI 从纪要/转写抽出的结构化最小单元。当前仅 4 类:entities/facts/decisions/participants(实证见 02)。需求文档想要的 risk/blocker/assumption/action_item 属未建 schema。
- InsightTree:跨会聚合形成的项目级洞察底座。当前是实时聚合 + L1/L2 缓存形态,未规范化落 PG。
- 待办池(Todo pool):一等公民、带状态机+归并+人审的项目待办。当前不存在(非"洞察面板里只读 action 展示")。
- Check 自动化:下次会议开场自动注入"上次待办进度 + AI 偏差扫描"。当前不存在。
- substrate:可逆底座(
business_transactionsaga + 可逆存储 + 软删回收站)。当前成熟且铺得广。 - 可用 / 好用:见 §B.1,贯穿全文的纵向标尺。
本框架锁定后,S1 起严格按 §B 标尺、§C 证据标准执行,任何偏离在对应文档显式标注。