在不熟悉的代码库中审计前先建立上下文理解：梳理每个函数的假设…

在开始审计、威胁建模或架构评审前，对不熟悉的代码先建立整体理解，为后续漏洞挖掘提供上下文。

适用场景

解决思路

1. 不要下结论，只建立理解；此阶段在漏洞挖掘之前运行，并为后续工作提供输入。
2. 在审计、威胁建模或架构评审开始时使用，尤其是面对不熟悉的代码；也适用于此前产出的发现无人能判断、因为没人梳理过系统整体结构的情况。
3. 不要命名漏洞、建议修复、编写 PoC 或评定严重性——这些属于下一阶段的漏洞挖掘工作。
4. 当代码依赖某个条件而没有任何地方检查它时，如实记录并继续，是否重要留待后续判断。
5. 对已经理解的代码不值得花费 token。
6. 不要在此上下文中做分析：分析内容很长，而此上下文需要存活下来以使用它，因此要分发出去。
7. 面对一个代码库或不止一个函数时，运行 `/audit-context-building:audit-context <path>`：它会做整体定位，在每个子代理中分析每个函数，并写出 `audit-context/DOSSIER.md` 以及 `audit-context/functions/` 下每个函数一个文件；只有紧凑记录返回此处。
8. 面对单个函数时，派发 `audit-context-building:function-analyzer` 代理处理它：它把叙述写到磁盘并返回一条记录。
9. 然后基于返回的内容工作：索引、未被强制执行的假设、开放问题；需要某函数细节时再读它的文件。
10. 依靠工作流来强制分发，而不是靠这段文字：绑定返回 schema 的子代理无法返回叙述性文字；把本节当作路由，去路由。
11. 每条记录列出必须始终为真的内容（附显示它的行号）、函数凭信任接受的内容（附确立它的依据）、它调用的函数及对每个函数的需求、以及任何仍不清楚的地方。
12. dossier 额外补充跨多个函数的规则、谁能访问什么、以及复杂部分聚集在哪里。
13. 重点关注标记为 `nothing found` 的假设：代码依赖某条件为真，而任何地方都没有使它为真；这是交给漏洞挖掘阶段最有用的东西。
14. 重点关注开放问题：诚实列出仍不清楚的内容，胜过自信但最终错误的答案；把它们带下去，而不是关闭它们。
15. 当两条记录不一致时，引用两者而不是悄悄调和——这是关于代码的事实，不是分析的缺陷。
16. 格式由 [ANALYSIS_FORMAT.md](resources/ANALYSIS_FORMAT.md) 定义，[FUNCTION_MICRO_ANALYSIS_EXAMPLE.md](resources/FUNCTION_MICRO_ANALYSIS_EXAMPLE.md) 用 C 和 Solidity 示例演示；在扩展此插件或判断某条记录是否可信时阅读它们。
17. 无论目标是什么，格式相同；变化的是每个槽位填什么，以及什么算作无法看透的调用；[DOMAIN_NOTES.md](resources/DOMAIN_NOTES.md) 映射了智能合约、C 和 C++、反编译固件以及 Web 服务中的差异——当目标不是普通源代码时阅读它。
18. 最重要的规则：跟随调用。一个函数是否正确通常取决于另一个函数做了什么，仅从调用方看不出来；一个限制看起来被强制执行，是因为值来自一个名字暗示已检查的函数。因此要读被调用的函数，跟随其中的每条路径而不仅是成功路径，并说明是什么让每个假设为真；当没有任何东西使其为真时，就用这些词：`nothing found`。每条断言都要引用行号，否则就变成开放问题。

适用边界 · 注意事项

• 不要命名漏洞、建议修复、编写 PoC 或评定严重性——这些属于下一阶段的漏洞挖掘工作。
• 对已经理解的代码不值得花费 token。
• 当代码依赖某条件而没有任何地方检查它时，不要在此阶段判断其重要性，如实记录并继续。