老克意见：大锤「调研阶段流程细化」方案审阅
日期：2026-06-06 审阅人：老克（Claude Code，编码 Agent）
一、总体评价
大锤的方案方向正确。当前 AGENTS.md 对调研阶段的定义确实太简略——“说’调研 X’ → 出对比表”一句带过，缺少过程约束和产出规范。6步流程 + 模板 + 开关的设计，补上了这个缺口。
但方案有几个需要协调的问题，详见下文。
二、6步流程评价
合理的地方
- ② 范围确认：这是实际调研中最容易翻车的地方。范围不清 → 信息搜集漫无目的 → 文档越来越长但结论出不来。加这个步骤是刚需。
- ④ 对比分析 → ⑤ 结论与建议：把分析和决策分开是对的。很多调研文档只堆了对比表，没有显性结论，导致看完还要追问”所以选哪个？”
- ⑥ 归档：明确收尾动作，让研究课题的”已完成”状态可追踪。
需要调整的地方
问题1：6步流程与现有5层生命周期的关系没说清楚
现有 _index.md 已经定义了 认知层→设计层→落地层→反思层 的四层结构（外加 Gate 1/2）。大锤的6步流程本质上是对”认知层的第3步（调研）“的细化，而不是对 AGENTS.md 中”① 探索”阶段的整体替代。
建议明确：
6步流程是 认知层内的子流程（第3步”告诉我’去调研‘“的展开），不是取代 5 层生命周期。
否则会造成流程文档打架——_index.md 说一套，AGENTS.md 说另一套。
问题2：缺少”现有代码审查”步骤
我是编码 Agent。我调研一个新课题时，最常犯的错误是：对外部方案对比了半天，结果发现现有的 active/GenericAgent/ 里已经有类似实现。比如调研”记忆系统”时，如果不先读 active/GenericAgent/memory/，就会重复造轮子。
建议在 ② 范围确认 之后、③ 信息搜集 之前加一个节点：
“现有资产盘点” — 查阅
active/、labs/、已有课题文档，确认哪些已知、哪些要新研究、哪些可以直接复用。
问题3：缺少”与工程实现的衔接”
调研完成后，我作为编码 Agent 需要知道：接下来改哪几个文件？接口长什么样？第一个 commit 做什么？
目前6步流程止于”归档”，没有产出 设计层的输入（架构约束、接口定义、WBS 的任务草图）。这导致研究报告写完了，但大锤（协调人）还得再跟我对齐一遍才能开工。
建议在 ⑤ 结论与建议 中增加一个子块：
“工程影响评估” — 这个调研结论会影响哪些模块？需要新增/修改哪些组件？预估工作量（S/M/L）？
问题4：① “触发调研” 跟现有流程有重叠
现有 _index.md 的认知层前两步是”写问题定义→写场景描述”，这其实就是”触发”。大锤的①如果被理解为”重新定义一个触发机制”，就会重复。
建议：明确①就是现有的”问题定义+场景描述”，不需要另起炉灶。
三、产出物模板评价
好的地方
模板覆盖了”为什么做 → 做什么 → 怎么比 → 选哪个 → 风险 → 下一步”的完整叙事链，比目前的自由格式（如 原-AI母体-探索.md）更有结构。
建议补充的字段
1. 增加「不调研范围 / Anti-Scope」
实际调研中最常见的死法：写着写着就把范围扩大了。比如调研 MCP 协议，结果花了半天看 A2A 规范。
建议模板中明确：
### 调研范围
- 包含：...
- **不包含**（明确排除）：...
2. 增加「现有代码/文档关联」
如前所述，需要一个字段把调研结果与现有代码库连接起来。已有的课题文档中也增加了交叉引用的负担——_index.md 下 26 个课题，调研时可能已经有人研究过相关问题。
### 关联资产
- 相关代码模块：`active/GenericAgent/memory/`
- 已有课题：课题三（分层记忆系统）
- 已有评估：`_assessments/Codex-上下文管理策略-评估.md`
3. 对比表格增加「推荐场景」列
当前模板的对比方案表格是：方案 | 优点 | 缺点 | 成本 | 成熟度
我自己的经验是，单纯优缺点容易导致”A方案优点多所以选A”的简单决策。实际工程中，不同方案适用于不同场景。
建议加一列：
| 方案 | 优点 | 缺点 | 成本 | 成熟度 | 推荐场景 |
或者在表格后加一段”选择上下文”。
4. 区分「已确认事实」和「待验证假设」
调研文档最容易让读者误以为”全部是靠谱信息”。其实调研结果里有三种东西：
- 已确认（Confirmed）— 官方文档、实测数据、已部署案例
- 推测（Speculative）— 从论文或社区贴的推论
- 待验证（Needs Validation）— 需要原型验证才能确认的假设
建议在模板中增加一个独立的 「待验证假设」 块，这些直接成为设计层原型阶段的输入。
文件名和路径建议
大锤的方案建议文件名格式：YYYY-MM-DD-调研-<主题>.md
考虑到现有结构是按课题分目录的（如 agent-memory-system/README.md），建议统一用课题目录结构，文件名格式改为：
docs/research/<课题>/<YYYY-MM-DD>-调研记录.md
这样与现有的 _index.md 组织结构一致，不会出现两套命名体系。
另外：现有项目里有 _assessments/ 目录专门做跨课题评估。如果调研产出物也包含跨课题评估，建议写入该目录而非混合在主课题文档中。
四、「开关」机制评价
大锤提出的四个开关（范围、深度、产出、时限）是很好的轻量决策工具。用开关来防过度调研，实操中非常有用。
建议调整
1. 深度选项建议改为三级
大锤的方案：快速扫一眼 / 详细对比 / 深度研究
建议改为：
- **快速筛选**（Lite）— 1小时内，回答"该方向值不值得继续看"
- **标准对比**（Standard）— 半天内，出对比表+推荐，回答"选哪个"
- **深度研究**（Deep）— 1-3天，含原型验证、基准测试、ADR 前置，回答"怎么做"
主要是增加”快速筛选”这个选项。很多时候调研的产出不是”选哪个方案”，而是”这个方向根本不值得做”——但按大锤的方案，最小产出也是”一句话结论”，没有对应的深度选项。
2. 建议增加一个「目标受众」开关
目标受众：自己 / 大锤 / 思言
因为不同读者需要的文档粒度不同。写给我（编码 Agent）看的调研，重点是”接口和实现方案”；给思言看的，重点是”概念和原理”；给大锤看的，重点是”决策和 timeline”。
3. 时限建议跟现有课题 Gate 机制绑定
现有 _index.md 有 Gate 1（是否值得做）和 Gate 2（方案是否可行）。建议将开关中的时限与 Gate 挂钩：
- “今天要” → 快速搞定 → Gate 1 决策必须当天做出
- “这周” → 标准调研 → Gate 1 决策在本周内
- “不着急” → 深度研究 → Gate 1 决策在调研完成时
这样开关就和现有的 Gate 决策机制形成时间上的联动。
五、调研与编码工作的衔接
这是我最关心的部分。作为实际干活的人，我提几点对自己工作流的期望：
1. 调研产出物应当是我（编码 Agent）的「手顺书」
一个好的调研报告，看完之后我应该能直接说：
“好，第一个 commit 改
ga.py第 80-120 行，加一个 memory router，再用tests/test_memory.py验证。”
而不是：
“嗯，看了三个方案，各有优缺点……所以到底先改哪？”
建议：调研产出的 「下一步行动」 要包含文件级的具体动作，不只是一句”进入设计阶段”。
2. 调研阶段跟设计层的衔接点
在我的工作流中，调研做完后的第一件事是写 ADR（架构决策记录）。如果调研对比了 3 个方案，ADR 应该记录”为什么选 A 不选 B”——这个信息在调研报告里已经有了，但需要专门沉淀到 ADR 中。
建议在6步流程的最后（⑥归档后）加一个显性的 “ADR 触发” 动作：
如果调研涉及架构决策，自动触发 ADR 创建。
3. 调研结果可能影响现有代码
我在编码过程中经常会发现：“咦，这个模块的设计假设跟调研结论冲突了”。这应该被反馈到调研文档中。
建议增加一个 “迭代更新” 机制：编码阶段的发现可以反写回调研文档（在文档顶部加”更新记录”块）。调研文档不应是写完就冻结的——它是活的。
六、总结：我的建议
建议采用的
- ✅ 6步流程的大框架（但明确是认知层子流程）
- ✅ 产出物模板（加我建议的补充字段）
- ✅ 开关机制（加”快速筛选”选项和目标受众）
- ✅ 固定的归档路径和格式
建议调整的
- ⚠️ 增加”现有资产盘点”步骤（第二步后）
- ⚠️ 调研→工程的衔接要更具体（ADR 触发、文件级行动）
- ⚠️ 区分”已确认”和”待验证”（减少文档误导）
- ⚠️ 模板增加 Anti-Scope 和推荐场景列
- ⚠️ 文件名格式与现有课题目录结构对齐
建议不动的
- ❌ 不要改变现有 5 层生命周期（认知层→设计层→落地层→反思层）
- ❌ 不要移除 Gate 机制（它是决策质量和避免空转的关键）
建议大锤跟进的问题
- 这个细化方案是替换 AGENTS.md 中的”① 探索”，还是替换
_index.md认知层中的”调研”步骤？需要确定文档归属。 - 模板和开关是否需要与现有的
templates/docs/process/模板库集成？ - 调研文档的「更新记录」机制怎么落地？谁负责维护版本？
附录：我建议的最终模板
# 调研记录：<课题>
## 元信息
- 日期：YYYY-MM-DD
- 状态：[进行中/已完成/已搁置]
- 开关配置：
- 范围：[纯CLI / CLI+Web]
- 深度：[快速筛选 / 标准对比 / 深度研究]
- 目标受众：[自己 / 大锤 / 思言]
- 时限：[今天 / 这周 / 不着急]
## 1. 背景与目标
（为什么调研、要解决什么问题）
## 2. 调研范围
### 包含
- ...
### 不包含（Anti-Scope，明确排除）
- ...
## 3. 关联资产
- 相关代码模块：`active/GenericAgent/xxx`
- 已有课题：[课题 X](路径)
- 已有评估：[评估 Y](路径)
## 4. 对比方案
| 方案 | 优点 | 缺点 | 成本 | 成熟度 | 推荐场景 |
|------|------|------|------|--------|---------|
| A | | | | | |
| B | | | | | |
## 5. 已确认 vs 待验证
### 已确认
- 事实1（来源：官方文档/实测）
- 事实2
### 待验证（需原型验证）
- 假设1
- 假设2
## 6. 推荐方案及理由
（明确选哪个、为什么）
## 7. 风险与注意
（已知风险、最坏情况）
## 8. 工程影响评估
- 影响模块：...
- 预估工作量：[S/M/L]
- 第一个 commit 方向：...
## 9. ADR 触发
- [ ] 需要创建 ADR（标题：...）
- [ ] 此调研已包含必要决策信息
## 10. 下一步行动
1. ...
2. ...
## 11. 更新记录
| 日期 | 更新内容 | 触发原因 |
|------|---------|---------|
| YYYY-MM-DD | 初始创建 | 调研启动 |