在动手写代码或下结论前，先摸清真实代码与数据

适用于任何非平凡改动、排查 bug 或在不熟悉代码中工作之前，用证据而非猜测来建立对代码库的真实认知。

适用场景

解决思路

1. 读实现而不是读名字：一个叫 `validate` 的方法默认并不真的做校验，先验证它实际做什么，再基于它的名字去构建。
2. 引用你的证据：计划中每个关键论断都要有 `file:line`、确切的查询结果或命令输出；无法佐证时就明说，而不是假设。
3. 绝不猜测约定：仓库如何命名、如何接线依赖、如何处理错误、如何跑测试，几分钟内都能查清楚。
4. 相信代码而不是状态：文档或工单自报的状态不是执行状态的证据，先用代码和历史（`git log -S <symbol>`、grep 代码树）裁定，再在其上构建。
5. 先复现再修复：对 bug，先亲眼看到失败发生，再改任何东西。
6. 在调用方汇聚处修复：bug 报告只提到一条路径上的一个症状，编辑前先找出进入该代码的每一条路径；当缺陷位于共享代码时，守卫应放在共享处——这既是更小的 diff，也能覆盖工单从未提到的兄弟路径。只补报告中的路径只是修了报告，不是修了 bug。
7. 梳理改动不能破坏的不变量：grounding 的产出是一张地图——触点、当前行为（带引用）以及那些不变量。以旧 bug 命名的测试、带解释性注释的守卫、编码了来之不易阈值的常量，都标记着过往的事故。
8. 只读改动触及的部分加一圈外围，深度按风险决定，而不是读所有东西。
9. 当代码无法回答意图问题时（为什么阈值是 7？），去问历史或负责人；无法回答的问题要变成具名假设，绝不静默略过。
10. 本次会话已确立的事实不重复 grounding：ground 一次，之后引用即可。

适用边界 · 注意事项

• 不要从框架文档去推断本项目代码的行为——项目可能 fork、包装或误用了框架，代码树才告诉你真相。
• 不要只 grounding 快乐路径——不变量藏在错误路径和边界守卫里。
• 不要因为任务“看起来像”以前做过的就跳过 grounding——模式匹配到已知情况的信号可能有不同成因，要检查证据是否支持当前这个案例。