⚡

追踪知识谱系Skill TracingKnowledgeLineages

这是一个用于追踪知识和想法历史演变的技能，帮助软件开发者和项目管理者在决策时理解背景，避免重复过去错误，并重新评估旧方法。它通过决策考古、失败尝试分析和复兴检测等技术，支持架构设计和技术选型。关键词：知识谱系、历史追踪、决策考古、Git分析、避免重复错误、复兴旧方法、软件开发实践。

架构设计 0 次安装 0 次浏览 更新于 3/16/2026

名称: 追踪知识谱系 描述: 理解想法随时间如何演变，以找到新问题的旧解决方案并避免重复过去的失败 使用时机: 当质疑“我们为什么使用X”时，在放弃方法之前，或评估可能是复兴的“新”想法时 版本: 1.1.0

追踪知识谱系

概述

想法有历史。理解为什么我们到达当前方法 – 以及之前尝试过什么 – 可以防止重复失败并重新发现被放弃的解决方案。

核心原则: 在评判当前方法或提出“新”方法之前，追踪它们的谱系。

何时追踪谱系

追踪前:

  • 提议替换现有方法（先理解为什么它存在）
  • 驳回“旧”模式（它们可能因错误原因被放弃）
  • 实施“新”想法（它们可能是值得重新考虑的复兴）
  • 声明某物为“最佳实践”（理解其演变）

触发谱系追踪的红旗:

  • “这似乎过于复杂”（以前更简单吗？为什么它发展了？）
  • “我们为什么不就…”（有人可能尝试过，发生了什么？）
  • “这是现代方式”（旧方式教会了我们什么？）
  • “我们应该切换到X”（最初是什么让我们离开X的？）

追踪技术

技术1: 决策考古学

搜索当前方法被选择的时间和原因:

  1. 检查决策记录（常见位置: docs/decisions/, docs/adr/, .decisions/, 架构决策记录）
  2. 搜索对话（技能/协作/记住对话）
  3. Git考古学 (git log --all --full-history -- path/to/file)
  4. 询问编写者（如果可用）

文档:

## 谱系: [当前方法]

**何时采用:** [日期/提交]
**为何采用:** [解决的原始问题]
**替换了什么:** [先前方法]
**为何替换:** [旧方法的缺点]
**驱动变更的上下文:** [外部因素、新需求]

技术2: 失败尝试分析

当有人说“我们尝试了X，但没成功”时:

不要假设: X从根本上是有缺陷的 改为追踪:

  1. 当时上下文是什么? （不再适用的约束）
  2. 具体失败了什么? （整个方法还是一个方面？）
  3. 为什么当时失败? （技术限制、团队约束、时间压力）
  4. 上下文改变了吗? （新工具、不同需求、更多经验）

文档:

## 失败尝试: [方法]

**何时尝试:** [时间段]
**为何尝试:** [原始动机]
**失败了什么:** [特定失败模式]
**为什么失败:** [根本原因，非症状]
**当时上下文:** [当时存在的约束]
**当前上下文:** [今天有什么不同]
**值得重新考虑吗?:** [是/否 + 推理]

技术3: 复兴检测

评估“新”方法时:

  1. 搜索历史先例 （这是否以前以不同名称尝试过？）
  2. 识别真正新颖之处 （vs. 重新包装）
  3. 理解为什么它消亡了 （如果是复兴）
  4. 检查复活条件是否存在 （上下文是否改变足够？）

常见复兴模式:

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

问: “我们从先前化身学到了什么？”

技术4: 范式转变映射

发生重大架构变更时:

映射转变:

## 范式转变: 从 [旧] 到 [新]

**转变前思维:** [我们如何思考问题]
**催化剂:** [触发转变的因素]
**转变后思维:** [我们现在如何思考]
**获得了什么:** [新能力]
**失去了什么:** [牺牲的旧能力]
**保留的教训:** [我们从旧范式中保持的]
**遗忘的教训:** [我们可能需要重新学习的]

搜索策略

在哪里寻找谱系:

  1. 决策记录 （常见位置: docs/decisions/, docs/adr/, .adr/, 或搜索“ADR”、“决策记录”）
  2. 对话历史 （使用技能/协作/记住对话搜索）
  3. Git历史 (git log --grep="关键词", git blame)
  4. 议题/PR讨论 （GitHub/GitLab议题历史）
  5. 文档演变 (git log -- docs/)
  6. 团队知识 （询问: “以前有人尝试过这个吗？”）

搜索模式:

# 找到方法何时被引入
git log --all --grep="引入.*缓存"

# 找到替换了什么文件
git log --diff-filter=D --summary | grep 模式

# 找到放弃方法的讨论
git log --all --grep="移除.*websocket"

红旗 – 您正在忽略历史

  • “让我们重写这个”（不理解为什么它复杂）
  • “旧方式显然是错的”（不理解上下文）
  • “没人再使用X了”（不检查为什么它消亡）
  • 因为“旧”而驳回方法（年龄 ≠ 质量）
  • 因为“新”而采用方法（新颖性 ≠ 质量）

所有这些都意味着: 停止。先追踪谱系。

何时覆盖历史

您可以忽略谱系当:

  1. 上下文根本改变

    • 以前不存在的技术现在可用
    • 迫使决策的约束不再适用
    • 团队现在有不同能力

  2. 我们学到了关键教训

    • 行业理解进化了
    • 过去尝试教会我们避免什么
    • 更好的模式出现并被证明

  3. 原始推理有缺陷

    • 基于后来证明错误的假设
    • 模仿而无理解
    • 时尚驱动，非需求驱动

但记录为什么覆盖: 未来的您需要知道这是故意的，不是无知的。

文档格式

提出变更时，包括谱系:

## 提议: 从 [旧] 切换到 [新]

### 当前方法谱系
- **采用:** [何时/为什么]
- **替换了什么:** [它替换的]
- **工作因为:** [它的优势]
- **挣扎因为:** [当前问题]

### 以前对 [新] 的尝试
- **尝试过:** [何时，如果曾尝试]
- **失败因为:** [为什么当时没成功]
- **上下文变化:** [现在有什么不同]

### 决策
[进行/推迟/放弃] 因为 [带历史上下文的推理]

示例

良好的谱系追踪

“我们以前使用XML而非JSON。XML消亡是因为冗长损害了开发者体验。但XML命名空间解决了真实问题。如果我们在JSON中遇到命名空间冲突，应该研究XML如何解决的，而不是重新发明。”

差劲的谱系忽略

“REST是旧的，让我们使用GraphQL。”（忽略: 为什么REST胜过SOAP？它解决什么问题好？那些问题消失了吗？）

带上下文的复兴

“我们在2010年尝试了客户端路由，由于浏览器支持差而放弃。现在支持是通用的，我们有更好的工具，值得用学到的教训重新考虑。”

记住

  • 当前方法存在有原因（追踪这些原因）
  • 过去失败可能现在有效（上下文改变）
  • “新”方法可能是复兴（检查先例）
  • 进化教育（研究转变）
  • 忽略历史 = 注定重复