审计上下文构建Skill：审计动工前先建好“系统地图”，让漏洞挖掘有的放矢
- 先建模型，再挖漏洞：这个技能把“审计准备阶段”变成一套可复用的检查流程，帮你在动手找 bug 之前，先看清资金在哪、谁能操作、谁在依赖谁。
- 四步走框架：侦察 → 系统映射 → 威胁建模 → 环境检查，每一步都有明确的动作清单，不需要凭经验去猜该看什么。
- 输出即交付物：最终生成一份结构化的《审计上下文报告》，包含角色权限表、资产流转表、外部依赖表、异步调用图与威胁摘要，可直接作为审计底稿。
- 面向 MultiversX 生态做了专门适配：识别
#[multiversx_sc::contract]、#[payable]、#[endpoint]、sc:地址字面量、mxpy.json等特征，同时思路对其他智能合约项目也有参考价值。 - 有明确完成标准：五条验收条件全部打勾，才算“上下文构建完成”，避免半途而废。
该技能叫什么？如何一键安装 AI 技能提升开发效率？
这个技能的中文名是「审计上下文构建Skill」，英文名是 audit_context，技能ID是 12585。
它要解决的问题非常具体：大多数审计事故的根因，出在审计开始之前的理解偏差，并非漏洞本身太隐蔽。审计员拿到一个陌生代码库，常见的困境是——不知道从哪个文件读起、不知道哪些函数持有资金、不知道合约之间怎么互相调用、不知道项目方说的“简单升级”背后牵扯几个合约。于是时间和精力被消耗在漫无目的的翻文件上，真正高风险的地方反而被漏看。
这个技能就是把这套“读懂系统”的动作标准化。它不帮你写代码，也不直接给你漏洞结论，它做的是审计的前置工程：用固定的四步流程和固定的报告模板，确保任何一个审计员在动手之前，都能拿到一份内容一致、要素齐全的系统认知底稿。
一键安装的思路与步骤
所谓“一键安装”，本质是把一份结构化的技能说明（Skill 定义）装进你常用的 AI 编码助手或智能体平台，让它在你对话时自动按这套方法论工作。通用步骤如下：
- 确认前提：你使用的工具需要支持「AI 技能 / Skill / 自定义指令」这类扩展能力，并且能够读取技能描述文件。具体支持范围以你所用平台的官方说明为准。
- 获取技能：通过技能平台搜索技能ID
12585或技能英文名audit_context，进入技能详情页。若平台提供一键安装按钮或订阅入口，按其引导完成即可；具体的安装命令、导入路径与入口位置以官方说明为准。 - 完成安装：安装成功后，该技能通常会自动挂载到你的会话中，或在技能列表里显示为“已启用”。
- 验证是否生效：新开一个会话，输入类似「我要审计一个 MultiversX 智能合约，先帮我构建审计上下文」的指令。如果回复中出现了「侦察 / 系统映射 / 威胁建模 / 环境检查」这四个环节，并产出了角色表、资产表、外部依赖表等结构化内容，说明技能已正常生效。
如果只能手动导入，通常是把技能说明作为系统提示词或自定义指令粘贴进工具配置中，效果等价。安装细节请以官方文档为准，不要随意执行来源不明的命令。
该技能的主要功能和特点
- 核心逻辑定位：引导你快速找到“钱在哪里、关键判断在哪里”，而不是从第一个文件开始顺序阅读。对 MultiversX 项目，明确指向
#[multiversx_sc::contract]注解、#[payable]函数和impl实现块。 - 外部依赖盘点：强制你去回答“这个合约还跟谁打交道”——有没有跨合约调用、有没有硬编码的
sc:智能合约地址字面量。这是审计中最容易被跳过、也最容易出事的一环。 - 文档资产清点：把
README.md、specs/、whitepaper.pdf纳入清单，MultiversX 项目还要看mxpy.json（构建配置）、multiversx.yaml、snippets.sh。文档与代码的不一致本身就是风险信号。 - 角色权限建模：把
Owner、Admin、User、Whitelisted四类角色拉出来，逐一对应到具体端点，形成“谁能做什么”的权限矩阵。越权问题在矩阵里一目了然。 - 资产流转映射：区分 EGLD、ESDT、NFT、SFT 四类资产，标注是铸造、燃烧还是转移，以及资金是流入、流出还是双向。资产流向图画不出来，审计基本等于盲人摸象。
- 状态存储梳理：识别
SingleValueMapper、VecMapper等存储结构，明确“合约里到底持久化了什么数据”，为后续检查状态一致性打基础。 - 初步威胁建模：从“风险资产 → 攻击者画像 → 入口点”三层倒推，先假设合约已经出事，再问“丢了什么、谁干的、从哪个门进来的”。
- 入口点穷举：要求列出所有
#[endpoint]函数，并特别标注哪些是未经检查的。这是把攻击面显性化的关键动作。 - 环境与测试基线检查：看
cargo.toml里的multiversx-sc版本是否过新或有已知问题，看scenarios/目录是否存在、能否用sc-meta test-gen生成最新测试。测试缺失本身就是一项风险，应记录在案。 - 标准化输出模板：直接给出《审计上下文报告》的固定骨架，含合同名、提交哈希、框架版本、测试套件状态、系统概览、角色表、资产表、外部依赖表、异步调用图、威胁摘要、范围确定。产出物统一，团队协作和交接成本大幅下降。
- 明确的完成标准：五条验收条件——角色权限已记录、资产流动已映射、外部依赖已识别、每个攻击者画像至少对应一个风险、范围确定已填写。达不到就不算完成，防止“看起来做了其实没做”。
和普通做法相比，它强在不依赖个人经验与记忆。老审计员凭直觉也会这么做，但会漏项；新人则根本不知道从哪开始。这个技能把“老手的下意识动作”变成了“新手的检查表”。
如何使用该技能？
以下是一套可直接照做的使用流程。
第 1 步：提供项目入口信息 在会话中把代码库情况告诉技能，越具体越好。例如：
这是一个 MultiversX 智能合约项目，路径在
contracts/staking/，包含一个质押合约和一个奖励分发合约，请先帮我构建审计上下文。
第 2 步：执行「侦察」
技能会引导你定位核心逻辑文件、识别外部依赖、清点文档。你要做的是配合回答或让它分析代码，例如确认是否存在硬编码的 sc: 地址、是否引用了第三方合约。产出：核心逻辑一句话描述 + 依赖清单 + 文档清单。
第 3 步：执行「系统映射」 进入角色、资产、状态三张地图的构建。此时应产出：谁能调用什么（角色—端点对照）、哪些代币在动（EGLD / ESDT / NFT / SFT 及流转方向）、合约持久化了哪些存储结构。
第 4 步：执行「威胁建模（初步）」
按“风险资产 → 攻击者画像 → 入口点”顺序填写。重点是列出全部 #[endpoint] 函数并标注未经检查的那些。此时应能回答：如果这个合约明天被掏空，最可能是哪三个端点出的问题。
第 5 步：执行「环境检查」
核对 cargo.toml 中 multiversx-sc 版本，检查 scenarios/ 是否存在、测试数量多少、测试是否最新（可用 sc-meta test-gen 重新生成以比对）。
第 6 步：生成《审计上下文报告》 按技能给定的模板输出完整报告。示例片段（示意）：
合同: staking
提交: [哈希值]
框架: multiversx-sc [来自 Cargo.toml 的版本]
测试套件: scenarios/ 存在: 是 测试数量: [N]
系统概览:
- 核心逻辑: 用户质押 ESDT 代币，按区块时间线性释放奖励。
- 价值流: 用户存入代币 → 合约持有 → 到期后本金与奖励返还用户。
角色:
| 角色 | 访问级别 | 端点 |
|------|----------|------|
| 所有者 | #[only_owner] | setRewardRate, pause |
| 用户 | 公开 | stake, unstake, claim |
第 7 步：对照完成标准验收 逐条核对五条完成标准，任何一条未满足就回到对应环节补齐。全部满足后，才进入真正的漏洞挖掘阶段。
输入输出说明：输入主要是代码库信息与项目背景；输出是一份结构化报告。报告的价值在于“后续所有审计动作都可以引用它”——比如威胁摘要里排前三的高风险端点，就是你第一批要精读的函数。
同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| audit_context（审计上下文构建Skill） | 审计前置阶段的方法论与产出模板 | 侦察、系统映射、威胁建模、环境检查四步流程，输出结构化上下文报告 | 低，安装后对话即用；需平台支持技能扩展，细节以官方说明为准 | 接手陌生代码库、多合约系统、审计交接、团队协作统一口径 | 优势：把“读懂系统”标准化，几乎零学习成本，产出可直接当审计底稿；不足：不直接给出漏洞结论，仍需人工分析 |
| Slither 等静态分析工具 | 自动化代码扫描 | 基于规则的模式匹配，输出可疑点与告警 | 中，需本地环境与依赖，配置有一定学习曲线 | 已有明确规则的常见缺陷批量筛查 | 优势：自动化程度高、可集成 CI；不足：不理解业务语义，容易漏掉逻辑型与业务型风险 |
| 符号执行 / 模糊测试工具 | 动态或半动态验证 | 通过约束求解或随机输入触发异常路径 | 高，需要编写测试与调参，耗时较长 | 关键函数的深度验证、边界条件探索 | 优势：能发现深层路径问题；不足：成本高、覆盖依赖输入建模质量 |
| 人工审计清单 / 自建模板 | 纯文档化经验沉淀 | 检查项罗列 | 低，但需自行维护 | 有经验的团队内部复用 | 优势：贴合团队习惯；不足：依赖个人维护，易过时、易漏项，新人上手仍靠口传 |
可以看出，audit_context 与其他方案是互补关系：它负责“把事情看清楚”，静态分析负责“把可疑点扫出来”，动态工具负责“把疑点验证掉”。跳过第一步直接上工具，往往得到一堆无法判断优先级的告警。
该技能的典型应用场景与实际体验情况
场景一：安全审计员接手陌生 MultiversX 项目 角色：外部安全研究员。痛点：项目方只给了一个仓库地址，代码量大、文档零散，不知道从哪切入。 使用方式：先让技能跑完四步，快速得到角色权限表与资产流转说明，再锁定威胁摘要里排名前三的端点精读。 实际体验：上手难度低，几乎不需要额外学习，按清单逐项回答即可。效果上最明显的改善是“不再恐慌”——有了地图之后，阅读是有方向的。注意事项：技能依赖你提供的信息质量，如果项目方文档缺失，需要在报告里如实标注“文档缺失”而不是凭空补全。
场景二：DeFi 团队上线前自查
角色：项目方开发或内部安全负责人。痛点：自己写的合约容易“想当然”，看不见自己的盲区。
使用方式：用技能强制走一遍威胁建模，特别是“风险资产 + 攻击者画像 + 入口点”三连问，逐条确认每个 #[endpoint] 是否有权限检查。
实际体验：效果体现在发现“没想清楚”的地方。比如某个端点到底是公开还是仅限 Owner，写代码时觉得显然，填表时才发现注解与预期不一致。注意事项：自查的心态要诚实，表格填得漂亮不等于安全。
场景三：多合约系统与异步调用梳理 角色：审计组长。痛点：多个合约之间异步调用与回调交织，调用链一长就容易看漏。 使用方式：用技能中的异步调用图格式，把“合同 A --async_call–> 合同 B --callback–> 合同 A”的链路画清楚，并给每条外部依赖标注高/中/低风险。 实际体验：这是该技能价值最集中的环节。异步回调场景下的状态一致性问题，靠肉眼读代码极易漏掉，画成图之后一目了然。注意事项：外部依赖的风险等级需要人工判断，技能只提供字段不替你下结论。
场景四：审计交接与团队复用 角色：团队负责人。痛点：不同审计员风格差异大，交接时对方要重新理解一遍系统。 使用方式：把《审计上下文报告》作为标准交接物，新人接手直接读报告 + 对照完成标准复核。 实际体验：可量化的收益是交接时间大幅缩短，因为系统认知不再存在个人脑子里，而是落在文档上。注意事项：报告需要随代码变更更新，建议在提交哈希变化后重跑一次。
该技能能为用户带来的价值
第一，把隐性经验变成显性流程。 资深审计员的“直觉”其实是长期积累的检查清单，但这个清单从未被写下来。这个技能把它固化为四步流程和五条完成标准，新人的起点从“零”变成“有一张地图”。
第二，显著压缩审计准备期。 传统做法下，理解一个中等规模合约系统往往要消耗相当比例的总工时，且质量参差不齐。按固定流程走，重复劳动被消除，注意力被集中到真正需要判断的地方。收益不是“省掉这段时间”，而是“同样的时间看得更全”。
第三，降低漏项风险。 角色、资产、依赖、入口点、环境版本、测试覆盖——这六类要素任何一项缺失，审计结论的可信度都会打折。清单化最大的价值就是让“忘记检查”这件事变得不可能被忽略。
第四，提升交付物专业度与可复用性。 结构化报告可以直接作为审计底稿、项目方沟通材料和团队知识资产。它同时具备三重身份：工作记录、沟通语言、培训教材。
长期价值在于知识沉淀。每审计一个项目就积累一份标准化的上下文报告，团队会逐渐拥有一套可检索、可对比的历史资料库，这对提升整体审计质量和响应速度是复利式的。
常见问题 FAQ
Q1：这个技能怎么安装？需要付费吗？
A：在支持 AI 技能扩展的平台上，通过技能ID 12585 或英文名 audit_context 找到技能详情页，按其引导完成安装或启用。是否收费、是否提供免费额度、具体的安装命令与入口位置，请以官方说明为准。若平台不支持自动安装，也可以将技能说明作为自定义指令或系统提示词手动导入，效果等价。
Q2：它只能审计 MultiversX 项目吗？
A：技能详情中对 MultiversX 做了明确适配，包括识别 #[multiversx_sc::contract]、#[payable]、#[endpoint]、sc: 地址字面量、mxpy.json 等特征，并支持 EGLD、ESDT、NFT、SFT 资产分类与 SingleValueMapper、VecMapper 存储结构。其四步方法论（侦察、系统映射、威胁建模、环境检查）本身具有通用性，但具体到其他链或语言时，特征识别部分需要你自行补充，不要默认它能自动适配所有框架。
Q3：用了它是不是就能直接找出漏洞？ A：不能。这个技能的定位是“审计前建立上下文的指南”，产出的是系统认知与威胁摘要，不替代漏洞挖掘本身。它的作用是让你后续的挖掘有优先级、有方向、不遗漏关键区域。把它和人工精读、静态分析、测试验证配合使用，效果最好。
Q4：和直接问 AI「帮我看看这个合约有什么问题」有什么区别？ A：直接提问往往得到一个笼统、难以验证的回答。而按这个技能走，你会先得到角色权限矩阵、资产流转表、外部依赖风险表和按风险排序的入口点，然后才是针对性的分析。有底稿的分析和没有底稿的分析，可信度不在一个层级上。此外，固定模板让不同人、不同次数的产出可对比、可交接。
Q5：适合谁用？我需要多少安全经验？ A：三类人最受益：一是安全审计员，尤其是刚接手陌生代码库时；二是项目方内部安全负责人，用于上线前自查；三是团队负责人，用于统一审计口径和交接标准。门槛很低，按清单回答即可上手。但要注意——技能给的是框架，判断仍需专业能力。威胁等级高低、某个端点是否真的危险，这些结论要由人来下。