audit-context-building

审计上下文构建

构建理解，而不是下结论。在任何人开始寻找漏洞之前运行，并为后续工作提供依据。

何时使用

在审计、威胁建模或架构审查开始时，代码尚不熟悉时使用。如果之前的分析得出了无人能判断的发现，因为没人梳理过系统各部分如何协同，也可以使用。

何时不要使用

不要指出漏洞、建议修复方案、编写概念验证或评定严重性。这些属于接下来进行的漏洞搜寻阶段，届时应基于完整的整体情况开展。如果代码依赖某项条件，但没有任何地方对其进行检查，就如实记录，然后继续——这是否重要留待后续判断。

不要在你已经理解的代码上浪费 token。

不要在此上下文中分析

分析过程很长，而此上下文需要保留下来以便使用。请分派任务：

• 一个代码库或多个函数——运行 /audit-context-building:audit-context <path>。它会梳理代码库，使用各自的子 Agent 分析每个函数，并写入 audit-context/DOSSIER.md 以及 audit-context/functions/ 下每个函数对应的文件。这里只返回简明记录。
• 单个函数——将 audit-context-building:function-analyzer Agent 分派给该函数。它会将分析文字写入磁盘，并返回一条记录。

然后根据返回内容继续工作：索引、未强制执行的假设和未解答的问题。需要了解函数详情时，再阅读该函数的文件。

真正强制执行这一工作流的是工作流本身，而不是这段文字：受返回格式约束的子 Agent 无法返回散文。请将本节视为任务路由，并据此分派任务。

返回内容及其解读方式

每条记录都会列出必须始终成立的条件（以及证明这一点的代码行）、函数所依赖的假设（以及相应依据）、它调用的函数及其所需内容，以及任何尚不明确之处。档案还会补充跨多个函数的规则、各处的可达性，以及复杂部分集中的位置。

有两点比其他内容更重要：

• 标记为 nothing found 的假设。 代码依赖某项条件成立，但没有任何地方能确保它成立。这是最值得交给漏洞搜寻阶段的内容。
• 未解答的问题。 坦诚列出尚不清楚之处，胜过给出自信却最终证明错误的答案。请将这些问题带入后续阶段，而不是草草结案。

如果两条记录存在分歧，就同时引用两者，而不是悄悄将其调和。这是代码本身的事实，并非分析缺陷。

格式

ANALYSIS_FORMAT.md 对格式作了定义；FUNCTION_MICRO_ANALYSIS_EXAMPLE.md 则通过 C 和 Solidity 示例逐步讲解。扩展此插件或判断某条记录是否可信时，请阅读这些文件。

无论分析对象是什么，格式都相同。不同之处在于各栏填写的内容，以及哪些调用属于无法查看内部实现的调用。DOMAIN_NOTES.md 介绍了智能合约、C 和 C++、反编译固件及 Web 服务在这方面的差异——分析对象不是普通源代码时，请阅读该文件。

最重要的规则：追踪调用。 一个函数是否正确，通常取决于另一个函数的行为，而仅凭调用方无法看出这一点。某个限制看似得到了执行，只是因为返回值来自一个名称看起来像是已经检查过该限制的函数。因此，请阅读被调用的函数，遍历其中的每条路径，而不只是成功路径，并说明每个假设如何成立。如果没有任何依据，就使用这几个字：nothing found。每项断言都必须引用代码行，否则就列为未解答的问题。