在 3 个以上不同领域看到同一模式时…

当你发现同一个「形状」反复出现在多个不同领域、或在解决问题时产生「似曾相识」的既视感，用它把重复模式抽象成可复用的普适原理并找到新应用场景。

适用场景

解决思路

1. 发现重复：主动留意同一个模式形状是否已在 3 个及以上不同领域出现过（例如 CPU/DB/HTTP/DNS 缓存、LLM prompt 缓存、CDN 都属同一形状）。
2. 抽取抽象形态：用完全脱离具体领域的语言重新描述这个模式，只保留本质机制（如把各类缓存描述为「把频繁访问的数据放得更近」，把分层描述为「把关注点分离成抽象层级」，把排队描述为「用缓冲解耦生产者与消费者」，把池化描述为「复用昂贵资源」）。
3. 用速查表记录三列：模式出现处 / 抽象形态 / 还能用在哪，逐条填出跨领域的对应实例。
4. 识别变体：逐一分析该模式在每个领域中如何被适配，明确变化点是什么（例如限流模式中的变化点是：限制什么资源、上限是多少、超限后发生什么）。
5. 检查可迁移性：拿着抽象形态反问「这个原理还能用在哪些别的地方」，并列出候选新场景（例如把「限制资源消耗以防止枯竭」套用到 LLM token 预算，防止上下文窗口被耗尽）。
6. 把抽象形态套到新领域上做一次具体验证：写出在新领域里对应的资源、限制与超限行为，确认迁移成立。
7. 把以下现象当作「自己漏掉了元模式」的红旗信号并立即回溯排查：心里冒出「这个问题很独特」的念头；多个团队各自独立地用完全一样的方式解决「不同」的问题；在不同领域重复造轮子；产生「我们以前是不是做过类似的事？」的既视感（答案通常是「是」，那就去把它找出来）。
8. 记住四条判据：3 个以上领域出现 ⇒ 大概率是普适原理；抽象形态能揭示新的应用场景；变体揭示了适配点；普适模式是经过实战检验的。

适用边界 · 注意事项

• 模式只出现在 1～2 个领域时，不要急着下「普适原理」的结论——3 个以上领域才算。
• 不要把抽象做得过于空泛，否则会丢失各领域变体的适配细节，无法指导实际落地。
• 不要用抽象出的模式替代具体领域的实测验证，迁移前须在新场景中确认限制与超限行为。