Tracing Knowledge Lineages

追溯知识脉络

概述

想法都有来历。了解我们为何采用当前方案，以及之前尝试过什么，可以避免重蹈覆辙，也能重新发现已被弃用的解决方案。

核心原则： 在评判当前方案或提出“新”方案之前，先追溯其脉络。

何时追溯脉络

在以下情况下先追溯：

• 提议替换现有方案（先了解它为何存在）
• 否定“旧”模式（它们可能是因为错误的理由而被弃用）
• 实施“新”想法（它们可能是值得重新考虑的旧方案）
• 宣称某种做法是“最佳实践”（先了解它的演变过程）

触发脉络追溯的危险信号：

• “这看起来太复杂了”（以前是不是更简单？为什么变复杂了？）
• “为什么我们不直接……？”（很可能有人试过，结果如何？）
• “这是现代做法”（旧做法教会了我们什么？）
• “我们应该改用 X”（当初是什么让我们弃用 X？）

追溯技巧

技巧 1：决策考古

查找当前方案是在何时、为何选定的：

1. 查看决策记录（常见位置：docs/decisions/、docs/adr/、.decisions/、架构决策记录）
2. 搜索对话记录（skills/collaboration/remembering-conversations）
3. Git 考古（git log --all --full-history -- path/to/file）
4. 询问编写者（如果可以联系到）

记录：

## Lineage: [Current Approach]

**When adopted:** [Date/commit]
**Why adopted:** [Original problem it solved]
**What it replaced:** [Previous approach]
**Why replaced:** [What was wrong with old approach]
**Context that drove change:** [External factors, new requirements]

技巧 2：失败尝试分析

有人说“我们试过 X，但没成功”时：

不要假设： X 本身存在根本缺陷 而应追溯：

1. 当时的背景是什么？（现在已不再适用的限制条件）
2. 具体是什么失败了？（整个方案，还是某个方面？）
3. 当时为何失败？（技术限制、团队约束、时间压力）
4. 背景是否发生了变化？（新工具、不同需求、更多经验）

记录：

## Failed Attempt: [Approach]

**When attempted:** [Timeframe]
**Why attempted:** [Original motivation]
**What failed:** [Specific failure mode]
**Why it failed:** [Root cause, not symptoms]
**Context at time:** [Constraints that existed then]
**Context now:** [What's different today]
**Worth reconsidering?:** [Yes/No + reasoning]

技巧 3：识别方案复兴

评估“新”方案时：

1. 查找历史先例（它以前是否以别的名称尝试过？）
2. 确定哪些是真正的新内容（而非重新包装的旧内容）
3. 了解它为何没落（如果这是旧方案复兴）
4. 检查是否具备复兴条件（背景是否已充分改变？）

常见的方案复兴模式：

• 微服务 ← 面向服务的架构 ← 分布式对象
• GraphQL ← SOAP ← RPC
• 无服务器 ← CGI 脚本 ← 云函数
• NoSQL ← 扁平文件 ← 文档存储

请问：“我们从前一种形态中学到了什么？”

技巧 4：绘制范式转变图

发生重大架构变更时：

绘制转变过程：

## Paradigm Shift: From [Old] to [New]

**Pre-shift thinking:** [How we thought about problem]
**Catalyst:** [What triggered the shift]
**Post-shift thinking:** [How we think now]
**What was gained:** [New capabilities]
**What was lost:** [Old capabilities sacrificed]
**Lessons preserved:** [What we kept from old paradigm]
**Lessons forgotten:** [What we might need to relearn]

搜索策略

查找脉络的途径：

1. 决策记录（常见位置：docs/decisions/、docs/adr/、.adr/，或搜索“ADR”“decision record”）
2. 对话历史（使用 skills/collaboration/remembering-conversations 进行搜索）
3. Git 历史（git log --grep="keyword"、git blame）
4. 议题/PR 讨论（GitHub/GitLab 议题历史）
5. 文档演变（git log -- docs/）
6. 团队知识（询问：“有人以前试过这个吗？”）

搜索模式：

# Find when approach was introduced
git log --all --grep="introduce.*caching"

# Find what file replaced
git log --diff-filter=D --summary | grep pattern

# Find discussion of abandoned approach
git log --all --grep="remove.*websocket"

危险信号——你正在忽视历史

• “我们干脆重写吧”（却不了解它为何如此复杂）
• “旧做法显然是错的”（却不了解当时的背景）
• “现在已经没人用 X 了”（却不查明它为何没落）
• 因为方案“旧”而否定它（年代 ≠ 质量）
• 因为方案“新”而采用它（新颖 ≠ 质量）

这些情况都意味着：停下来，先追溯脉络。

何时可以推翻历史经验

以下情况可以忽略历史脉络：

1. 背景发生了根本变化

   • 现在有了过去尚不存在的技术
   • 曾经迫使我们做出决策的限制已不复存在
   • 团队现在具备了不同的能力

2. 我们吸取了重要教训

   • 行业整体认知已有进步
   • 过去的尝试让我们知道哪些做法要避免
   • 更好的模式已经出现并得到验证

3. 最初的推理有误

   • 决策基于后来被证明错误的假设
   • 不理解原因就盲目照搬
   • 由潮流驱动，而非由需求驱动

**但要记录你为何推翻历史经验：**未来的你需要知道，这是经过深思熟虑的决定，而非因为不了解历史。

文档格式

提出变更时，注明历史脉络：

## Proposal: Switch from [Old] to [New]

### Current Approach Lineage
- **Adopted:** [When/why]
- **Replaced:** [What it replaced]
- **Worked because:** [Its strengths]
- **Struggling because:** [Current problems]

### Previous Attempts at [New]
- **Attempted:** [When, if ever]
- **Failed because:** [Why it didn't work then]
- **Context change:** [What's different now]

### Decision
[Proceed/Defer/Abandon] because [reasoning with historical context]

示例

良好的历史脉络追溯

“我们以前用 XML，后来改用 JSON。XML 因冗长而损害开发者体验，最终被淘汰。但 XML 命名空间解决了实际问题。如果我们在 JSON 中遇到命名空间冲突，就应该研究 XML 是如何解决的，而不是重新发明一套方案。”

忽视历史脉络的反面示例

“REST 太老了，我们用 GraphQL 吧。”（忽略了：REST 为何胜过 SOAP？它擅长解决哪些问题？这些问题已经不复存在了吗？）

结合背景重启旧方案

“我们在 2010 年尝试过客户端路由，但因浏览器支持不佳而放弃。如今浏览器已普遍支持，工具也更完善了，值得结合过去的经验重新考虑。”

请记住

• 当前的做法都有其原因（追溯这些原因）
• 过去失败的方案如今或许可行（背景会改变）
• “新”方案或许是旧方案的复兴（查找先例）
• 演进过程能带来启示（研究变化过程）
• 忽视历史，注定重蹈覆辙