kuangjia-chaijielisted

# 框架主题深度拆解 · 工作流 > **这个 skill 不输出文章。它输出"完整、可口头复述的理解"。** > 输入：一个框架/代码库 + 一个主题词 > 产出：4 份结构化 markdown 文档 > 写文章是 skill 结束之后的事。 --- ## 适用 / 不适用 ✅ 适用： - 准备写技术分享 / 公众号 / 团队讲座，但还没完全摸清主题 - 主题跨多个模块（不是单文件可解释的） - 想要"完整不漏"地理解某个子模块 ❌ 不适用： - 单文件、单函数问题 → 直接 Read / Grep - 调试具体 bug → 用 debugging skill - 设计新功能 → 用 brainstorming → writing-plans --- ## ⚠️ 核心基础原则：不猜 → 先 Read → 再问 **这条原则凌驾于一切阶段流程之上，是这套方法论可信度的根。** **所有结论必须有依据**——要么是读到的代码 / 文档 / 数据文件，要么是用户明确告知。**禁止用 "通常"、"一般来说"、"应该是"、"按惯例"、"大概率" 这类先验知识填空。** LLM 训练语料里有大量同类框架的"通用模式"，这些模式很可能跟当前项目实际实现不同——靠常识猜出来的结论是这套方法论最大的污染源。 ### 不确定时的决策顺序 ``` 遇到不确定 │ ├─[1]─→ Read 相关文件 │ （源码 / README / 测试用例 / 样本数据 / config / 注释） │ └─→ 读到了 ──→ 把结论写进产物，附 file:line 引用 │ ├─[2]─→ 文件里找不到，扩大搜索范围 │ （rg / git log / git blame / 历史 RELEASE_*.md） │ └─→ 找到了 ──→ 同上，附 file:line / commit-hash 引用 │ └─[3]─→ 仍找不到 ──→ 问用户 - 明确说："我已经查过 X / Y / Z 都没找到" - 不要让用户自己去找，给出具体问题 - 用户答复后回填到产物里，注明 "据用户 {date} 告知" ``` ### 必须显式标注的两种情况 1. **依据不足但需要给出阶段性产物**：用 `[待澄清: ...]` 标记，写进当前阶段的"待澄清问题"列表，**不要混在正文里假装是结论** 2. **跨阶段假设**：阶段 1 时为了推进做了某个假设、留到阶段 2 验证 → 在阶段 1 产物末尾的"假设清单"里列出，阶段 2 开头先逐条验证。 #### ⚠️ 假设清单准入闸 **下笔写"假设"前必答**："如果我现在就 Read 那个文件，能不能 5 分钟内验证？" 能 → **必须现在去 Read**，不准写进假设清单。读完写进正文带 `file:line` 引用。 ✅ **合法假设**（无法在阶段 1 当场验证，才能写入清单）： - 依赖**运行时行为**才能验证（如"`on_memory_write` 在每次 memory tool 写入后触发"——需观察运行时调用栈或测试用例） - 依赖**用户决策**（如"假设外部依赖 X 不算本主题核心，归到剔除"） - 依赖**跨模块综合判断**（如"假设这 3 个文件构成一个完整子模块，无遗漏成员"——需要阶段 2 深挖才能确认） ❌ **非法假设**