地震仪

地震的破坏力并非由震中决定，而是由震中与周边区域之间的地质条件——断层线、土壤成分、基岩深度所决定。代码变更也是如此。

功能概述

在进行变更之前，地震仪会绘制传播路径——每一个会感受到震动的函数、模块、测试、类型、配置和下游系统。不仅仅是什么调用了这个函数（你的IDE就能做到），还包括：

• - 其他地方存在哪些关于这段代码的假设？
• 哪些测试验证了你即将更改的当前行为？
• 哪些文档承诺了你即将破坏的行为？
• 哪些下游系统依赖于你即将修改的输出结构？
• 这段代码的哪些副作用已被依赖，即使它们并非有意为之？

地震模型

地震解剖 → 变更解剖

波分析

P波：直接影响

分析：
├── 每个导入变更模块的文件
├── 每个调用变更函数的函数
├── 每个扩展或实现变更类型的类型
├── 每个直接测试变更行为的测试
└── 预估：受影响文件数，可能影响的代码行数

S波：间接影响

分析：
├── 传递性导入者（A使用B，B使用变更）
├── 消费变更函数输出的函数
├── 读取变更代码写入数据的系统
├── 由变更逻辑解析的配置
└── 预估：传播深度，最薄弱的中介

面波：副作用影响

分析：
├── 响应变更代码发出事件的事件订阅者
├── 对变更行为进行模式匹配的监控/告警规则
├── 从变更代码输出计算出的缓存值
├── 由变更代码查询触发的数据库触发器
├── 期望变更代码日志格式的日志解析器/聚合器
├── 学习（而非约定）了输出形状的下游服务
└── 预估：面波损害概率，检测难度

震级标度

地质调查：变更前分析

阶段1：震中映射
├── 识别正在变更的确切代码行
├── 分类变更类型：
│ ├── 重命名（最低风险）
│ ├── 签名变更（中等风险）
│ ├── 行为变更（高风险）
│ ├── 删除（最高风险）
│ └── 新增（通常安全，除非重载现有名称）
└── 确定震级基线

阶段2：波传播
├── P波分析：
│ ├── 静态依赖图遍历
│ ├── 类型系统影响（编译时什么会破坏？）
│ └── 直接测试影响（哪些测试会失败？）
├── S波分析：
│ ├── 传递性依赖遍历（2-3跳）
│ ├── 数据流追踪（输出在哪里被消费？）
│ └── 集成测试影响
└── 面波分析：
├── 事件/消息订阅者
├── 数据库触发器和视图
├── 监控和告警规则
├── 缓存失效影响
└── 日志格式依赖

阶段3：断层线评估
├── 对于每条波路径，评估中间架构：
│ ├── 强边界（类型化接口、契约）→ 波衰减
│ ├── 弱边界（鸭子类型、约定）→ 波放大
│ ├── 无边界（直接耦合）→ 波通过
│ └── 断层线（已知脆弱点）→ 波放大
└── 调整每个受影响位置的烈度

阶段4：余震预测
├── 如果修复主要破坏，会发生哪些二次破坏？
├── 哪些修复是安全的（局部化）vs 级联的（引发更多波）？
├── 预估总变更集：原始变更 + 所有必要的适配
└── 总变更集是否超出原始意图的合理范围？

阶段5：地震仪报告
├── 震级和烈度图
├── 受影响位置的优先级列表
├── 推荐的变更策略（直接、分阶段、功能开关后）
├── 余震预测
└── 推荐：执行 / 分阶段发布 / 重新考虑

输出格式

╔══════════════════════════════════════════════════════════════╗
║ 地震仪分析报告 ║
║ 提议：重命名 User.email → User.emailAddress ║
║ 震级：4.7（显著） ║
╠══════════════════════════════════════════════════════════════╣
║ ║
║ 震中：src/models/user.ts:24 ║
║ ║
║ P波（直接影响）： ║
║ ├── 14个文件导入User并访问.email ║
║ ├── 8个测试断言.email ║
║ ├── 2个API序列化器包含email键 ║
║ └── 编译时破坏：是（TypeScript将捕获） ║
║ ║
║ S波（间接影响）： ║
║ ├── 3个服务消费包含email字段的User API响应 ║
║ ├── 1个webhook负载包含email（外部消费者） ║
║ ├── 1个CSV导出使用email作为列标题 ║
║ └── 运行时破坏：可能（在下游服务中） ║
║ ║
║ 面波（副作用影响）： ║
║ ├── Elasticsearch索引映射email字段 → 搜索破坏 ║
║ ├── 监控告警匹配日志输出中的email ║
║ ├── 2个Zapier集成引用email字段 ║
║ └── 检测难度：高（数周后才能发现） ║
║ ║