SingClaw5 Why
- 为什么同一个问题反复出现？因为你每次只修了症状，没动根因。
- 为什么只修症状？因为症状在眼前，根因在上游，人的注意力被眼前的火吸走了。
- 为什么虾能帮忙？因为虾不会被情绪和紧迫感带偏，可以冷静追溯上游。
- 为什么要"围魏"？因为直接去"救赵"（修症状）是无底洞，围住"魏"（根因）才能一劳永逸。
- 为什么这是好策略？因为一次根因修复 = 消灭未来 100 次症状修复。
养虾36计 · 第二计
围魏救赵
在养虾语境里，围魏救赵不是绕路，而是不在问题发生的地方解决问题，而是让虾从上游切断根源——下游的火灭不完，就去上游把水龙头关了。
What
围魏救赵，就是当下游不断出问题时，不继续在下游救火，而是让虾去分析上游——数据源、输入格式、流程设计、权限配置——找到真正的"魏"，围住它，问题自然消失。
Detail What
- 症状记录：让虾记录每次出问题的现象、时间、上下文，而不是修完就忘。
- 模式识别：积累够了之后，让虾分析这些问题有没有共同根因。
- 上游追溯：从出问题的环节往上追，找到最早出错的那个节点。
- 根因修复：修那个节点，而不是继续在下游打补丁。
- 验证闭环：修完后观察下游问题是否真的消失——没消失说明还没找到真正的"魏"。
So What
围魏救赵的本质是系统性思维替代救火式思维。大多数人养虾的痛苦不是虾不行，而是天天在下游修 bug、调格式、补数据。如果你不去上游解决问题，你永远在做重复劳动。虾最大的价值之一，就是帮你做这种跨环节的根因追溯。
How（举一反三）
- 下次遇到重复出现的问题，先不要急着修，让虾记录下来。
- 积累 3 次以上同类问题后，让虾做模式分析：共同点是什么？
- 找到共同点后，往上游追一层：是输入数据的问题？还是流程设计的问题？
- 在上游做一次结构性修复，然后观察 7 天。
- 如果下游问题消失了，你就成功"围魏"了。
举一反三：日报格式总出错？别改日报模板，去看数据源格式是否统一。客服回复总跑偏？别改回复话术，去看 SOUL.md 是不是没写清楚。推送总延迟？别优化推送逻辑，去看上游采集是不是卡了。