技能使用指南

multiversx-spec-compliance（MultiversX规范合规性验证）Skill 是什么？如何下载安装？

MultiversX规范合规性验证Skill 帮你把白皮书、技术规范与MIP标准里的要求逐条提取，并映射到Rust合约代码，输出已验证、偏差与未找到清单。覆盖公式、约束、状态机、MIP-2/3/4与Tokenomics验证，附偏差报告与合规性报告模板。了解它是什么、怎么安装、适合谁用，立即上手提升审计效率。

MultiversX规范合规性验证Skillmultiversx-spec-compliance
21 个章节 约 18 分钟阅读 AI 智能生成

MultiversX规范合规性验证：让白皮书里的每一条“必须”都能在 Rust 合约里找到落地代码

  • 它是做什么的：把白皮书、技术规范和 MIP 标准里写下的要求逐条提取出来，再回到 Rust 合约代码中定位实现位置，判断“已验证 / 有偏差 / 未找到”。
  • 核心方法：以 MUST、MUST NOT、SHOULD、SHALL、MAY 等规范语言关键词为线索做要求提取，然后映射到 src/*.rs，最后做逻辑验证并输出报告。
  • 覆盖面：公式验证、约束验证、状态转移验证、MIP-2/3/4 合规检查、Tokenomics（总量、通胀、燃烧、分配）验证五大方向。
  • 交付物是可复用的文档：要求清单表格、偏差报告模板、规范合规性报告模板，可直接交给审计方或项目方内部复核。
  • 最适合谁：MultiversX 智能合约开发者、准备上审计的项目方、做升级提案评审的技术负责人，以及验证代币经济学实现的通证设计者。

1. 该技能叫什么？如何下载安装 AI 技能提升开发效率？

技能中文名：MultiversX规范合规性验证 技能英文名：multiversx-spec-compliance 技能ID：12526

它到底解决什么问题

MultiversX 上的智能合约通常用 Rust 编写，而合约“应该做什么”却写在另外几个地方：白皮书 PDF、仓库里的 README.md、specs/ 目录下的设计文档，以及 MultiversX 改进提案（MIPs）这类社区标准。设计文档是用自然语言写的，代码是用 Rust 写的，两者之间天然存在一条鸿沟：

  • 白皮书说“最少质押 1000 EGLD”，代码里可能写成了别的单位或者漏掉了 wei 换算；
  • 规范说“年通胀率 5%”，代码里的基点整数除法可能悄悄把通胀压到了 3.65%；
  • 规范说“状态只能 INACTIVE → ACTIVE → COMPLETED”，代码里也许存在某个能直接 .set(State::) 的后门端点；
  • 规范引用了 MIP-2，但 SFT 元数据字段和版税编码并没有按标准来。

这类问题不是“代码有 bug”，而是“代码没按设计意图执行”，人工逐条比对极其枯燥，而且很容易漏。MultiversX规范合规性验证Skill 就是专门用来弥合文档与代码之间这道差距的：它以技能的形式接入 AI 编程助手，在几轮对话内帮你把规范拆成清单、把清单映射到代码、把偏差写成报告。

如何“一键安装”并让它生效

AI 技能的通用安装思路是：在支持 Skill 的 AI 客户端或代理平台中，用技能名称或技能 ID 检索并启用。本技能的安装入口、具体命令与支持的客户端清单，以官方说明为准。下面给出的是通用流程，实际操作时按平台指引执行即可。

安装前提（建议在安装前准备好）

前提 说明
运行环境 一个支持 AI 技能（Skill）加载的编程助手或代理环境
代码 合约源码目录，通常是 src/*.rs
规范 whitepaper.pdf、README.md、specs/ 等设计文档
版本锚点 明确规范版本和代码版本（commit 或 tag），避免拿新规范审旧代码
MIP 参考 需要核对的 MIP 条目，如 MIP-2（SFT）、MIP-3（动态 NFT）、MIP-4（版税）

通用安装步骤

  1. 打开你所使用平台的技能库或技能市场；
  2. 用英文名 multiversx-spec-compliance 或技能 ID 12526 检索；
  3. 点击安装 / 启用，并按平台提示完成授权；
  4. 把合约仓库目录和规范文档目录加入技能可读取的范围；
  5. 验证是否生效：直接问它“你能验证哪些类型的合规性要求？”如果它能准确复述要求提取、代码映射、公式/约束/状态转移验证、MIP 合规和 Tokenomics 验证这几类能力，并输出要求清单表格的字段（ID、类型、要求、来源、代码位置、状态），说明技能已经加载成功。

2. 该技能的主要功能和特点

  • 规范语言关键词驱动的要求提取：自动抓取包含 MUST（必需）、MUST NOT（禁止）、SHOULD（建议）、SHALL（义务）、MAY（可选）的语句，把散落在白皮书段落里的自然语言翻译成可核查的要求条目，并为每条生成唯一 ID。
  • 要求清单表格化：输出「ID / 类型 / 要求 / 来源章节 / 代码位置 / 状态」六列表格，例如 C1 | MUST | 最少质押 1000 EGLD | WP §3.1 | stake.rs:45 | 已验证，让“规范覆盖率”变成可统计的数字。
  • 代码映射能力：针对每条要求定位 src/*.rs 中的实现位置，并给出映射检查清单：代码位置是否找到、逻辑是否理解、常量/数值是否匹配规范、边缘情况是否按规范处理。
  • 公式验证：把规范里的数学表达式（如 APY = base_rate * (1 + boost_factor)）与 Rust 实现逐项对照，特别针对 BigUint 精度、PRECISION 缩放因子、整数除法截断这类“规范没写、代码却做了”的隐含处理提出质疑。
  • 约束验证：核对锁定期、上下限、权限限制等约束是否真的生效，并追问三个关键问题——参数是否按规范初始化、参数是否可被管理员篡改、是否存在其他端点可以绕过。
  • 状态机验证：对着规范画出的状态转移图检查 Rust 枚举与端点，标注合法迁移，并主动搜索 .set(State:: 这类可能绕过流程的直接赋值。
  • MIP 标准合规性检查：覆盖 MIP-2 半同质化代币（SFT 的 nonce 与 quantity 规则、元数据格式、版税编码）、MIP-3 动态 NFT 属性更新机制、MIP-4 版税计算与分发。
  • Tokenomics 验证：围绕总供应量上限、通胀率、燃烧率、初始分配比例四类常见要求，检查铸币约束与计算公式是否与文档一致。
  • 偏差分级与报告模板：把发现按关键 / 主要 / 次要 / 增强四级分类，输出带根本原因、影响量化（例如“通胀比文档低约 27%”）、修复建议和状态的偏差报告，并汇总成含执行摘要、规范覆盖率统计、MIP 合规表的完整合规性报告。

和普通代码审计工具相比，它的差异点很明确：普通工具回答“代码有没有漏洞”，它回答“代码有没有按设计意图办事”。前者看的是安全性，后者看的是忠实度，二者互补而非替代。

3. 如何使用该技能？

整个使用流程在技能详情中被概括为四步：提取要求 → 映射到代码 → 验证逻辑 → 文档化。以下是可直接照做的操作指南。

步骤 1：准备并声明输入

向技能明确三类输入：代码（Rust 实现，src/*.rs）、规范（whitepaper.pdf、README.md、specs/）、MIP 参考（MultiversX MIPs）。同时告知规范版本与代码版本，这一步直接决定了后续所有结论是否可靠。

步骤 2：让它做要求提取

你可以直接给出指令：“请从我的白皮书第 3、4、5 章提取所有 MUST / MUST NOT / SHOULD / SHALL / MAY 级别的要求，输出要求清单表格，并为每条生成 ID。”

假设白皮书原文是：

“质押合约必须强制执行最少 1000 EGLD 的质押。奖励必须使用 APY = base_rate * (1 + boost_factor) 计算。用户在锁定期内不得提现。”

技能应当输出类似这样的提取结果：

1. [MUST] 最少质押：1000 EGLD
2. [MUST] 奖励公式：APY = base_rate * (1 + boost_factor)
3. [MUST NOT] 锁定期内提现

步骤 3：让它做代码映射

继续追问：“为上述每条要求在 src/ 中找到实现代码，标注文件名与行号。”它会返回类似 stake.rs:45、rewards.rs:78、withdraw.rs:23 的定位结果，并把状态标记为「已验证」「偏差」或「未找到」。若某条要求在代码里完全找不到，这就是一个「未实现要求」，需要在报告里单列。

步骤 4：逐类做逻辑验证

这是最有价值的一步，建议按公式、约束、状态转移三类分别发起追问。

公式验证示例：规范写 APY = base_rate * (1 + boost_factor)，代码里却多了一步 / PRECISION。技能会指出：规范中并未提及精度缩放，这个额外除法属于潜在偏差，需要确认 PRECISION 的取值是否会导致结果失真。

约束验证示例：规范写“7 天锁定期内不得提现”，代码读的是 self.lock_period().get()。技能会连问三件事：lock_period 是否初始化为 7 天（604800 秒）？它是不可变的还是管理员可改？是否存在其他端点能绕过这个 require!？

状态转移验证示例：规范写 INACTIVE → ACTIVE → COMPLETED，技能会核对 activate 只允许从 Inactive 触发、complete 只允许从 Active 触发，然后追问“是否存在方式倒退”“状态能否被直接 set”。

步骤 5：做 MIP 与 Tokenomics 专项检查

对 MIP-2，可以要求核查：代币类型是否为 SFT（nonce > 0 且允许 quantity > 1）、元数据字段是否齐全（name、royalties、hash、attributes、uris）、版税是否以基点（0–10000）编码。对 Tokenomics，则按总供应量、通胀率、燃烧率、分配比例逐项验证。

步骤 6：输出偏差报告与合规性报告

最后让它生成两份文档。偏差报告应包含：要求、来源、代码位置、预期值、实际值、根本原因、影响、推荐修复、严重性、状态。合规性报告则应包含执行摘要、按章节统计的规范覆盖率表格（例如 §3 质押 12 条要求 / 已验证 10 / 偏差 1 / 未找到 1）、已验证要求清单、偏差详情、未实现要求、MIP 合规表、推荐事项和总体结论。

使用中的六条最佳实践

  1. 先对齐规范版本与代码版本，版本错位会让整份报告失效；
  2. 规范含糊时要求它记录假设，而不是默默做出判断；
  3. 主动要求测试边界值，如恰好 1000 EGLD、锁定期最后一秒；
  4. 重点检查单位：EGLD 与 wei、秒与 epoch、基点与百分比；
  5. 关注 BigUint 计算的精度损失；
  6. 核对规范是否随版本演变，代码是否同步更新。

4. 同类型竞品对比分析

方案名称 定位 核心功能 安装/使用门槛 适用场景 优势与不足
MultiversX规范合规性验证（本技能） 文档与代码之间的一致性核查 要求提取、代码映射、公式/约束/状态机验证、MIP 与 Tokenomics 合规、偏差分级报告 在支持 Skill 的平台按名称或技能 ID 启用；需准备规范文档与 Rust 仓库 上审计前自检、升级提案复核、白皮书落地核查 优势：输出结构化表格与报告，覆盖 MIP 与通证经济；不足：依赖规范文档本身的质量，规范写得含糊时结论需要人工确认
人工逐条比对 传统审计方式 人读白皮书 + 人读代码，手工列表 门槛最低但成本最高，强依赖审计师经验与排期 小型合约、正式审计前的补充核对 优势：判断力强，能理解商业意图；不足：耗时、易漏、结论难复用，重复劳动多
通用静态分析与漏洞扫描工具 代码安全检测 模式匹配、数据流分析、已知漏洞规则库 一般需要本地安装与配置，学习曲线中等 寻找重入、溢出、权限类漏洞 优势：擅长安全漏洞；不足：不读白皮书，无法判断“实现是否符合设计”，也不理解 MIP 标准
通用大模型对话式审查 通用代码理解与问答 代码解释、片段审查、文档摘要 门槛低，直接对话即可 快速理解陌生代码、初步排查 优势：灵活；不足：缺少固定的要求提取流程、偏差分级与报告模板，结论容易碎片化、不可追溯

选择建议：安全漏洞交给静态分析工具，设计忠实度交给本技能，最终定论交给人工审计。三者是分层关系，不是替代关系。

5. 该技能的典型应用场景与实际体验情况

场景一：项目上审计前的内部自检

角色：MultiversX 合约开发团队。 痛点：审计机构报价按时间和范围计算，如果送审时规范与代码已经严重脱节，审计师大量时间会花在“你到底想实现什么”的沟通上。 用法：先跑一遍完整验证流程，输出规范覆盖率表，把「未找到」和「关键偏差」在内部修掉，再带着合规性报告去送审。

实际体验：这类结构化输出对审计沟通帮助最大——审计师可以直接顺着要求 ID 逐条复核。需要注意的是，规范覆盖率统计的准确性取决于你是否把全部规范文档喂给了技能，遗漏章节会导致覆盖率虚高。

场景二：Tokenomics 实现验证

角色：通证经济设计者或合约负责人。 痛点：白皮书里写的“年通胀 5%”在代码里可能因为整数除法变成 3.65%，而这种偏差在链上要跑一年才能被观察到。 用法：把通胀、燃烧、分配章节交给技能，要求逐条做公式验证并量化偏差。

实际体验：这是最容易“一用就发现真问题”的场景。技能会主动质疑基点除法、epoch 假设（例如代码假设每日一个 epoch 是否成立）这类精度细节。注意事项是：结论依赖你对 EPOCHS_PER_YEAR 等常量的真实取值确认，不要照搬示例中的假设值。

场景三：MIP 标准合规性检查

角色：发行 SFT 或动态 NFT 的项目方。 痛点：MIP-2 对 SFT 的 nonce、quantity、元数据格式和版税编码有明确要求，一旦不符合，钱包和市场的兼容性会出问题。 用法：指定 MIP-2 / MIP-3 / MIP-4 作为参考标准，要求逐项核对创建端点与版税计算逻辑，输出 MIP 合规表。

实际体验：上手难度低，因为 MIP 要求本身就是条款式的，提取起来比白皮书散文容易得多。注意不同 MIP 版本可能更新，务必确认引用的是当前生效版本。

场景四：升级提案与规范同步评审

角色：治理参与者或技术负责人。 痛点：合约升级时，代码改了，规范没改；或者规范改了，代码没跟上，形成新的偏差。 用法：以新版本规范为基准重跑验证，对比变更历史，确认哪些要求被新增、哪些实现被遗漏。

实际体验：这是长期价值最高的用法，相当于给“文档—代码”这对关系建立了持续对账机制。建议把它固化成每次发版前的固定动作。

6. 该技能能为用户带来的价值

  • 把“逐条核对”从几天压缩到几轮对话：要求提取、代码定位、状态标注、报告撰写原本是审计师最枯燥的重复劳动，现在可以批量完成，人只需要复核结论。
  • 降低规范落地的门槛：开发者不必是 MIP 标准专家，也能得到一份逐条对照的检查结果，尤其适合刚进入 MultiversX 生态的团队。
  • 让风险提前暴露，而不是在链上暴露：整数精度损失导致的通胀偏差、可被管理员篡改的锁定期、能被绕过的状态机——这些问题在测试网阶段修复的成本，远低于上线后发现。
  • 产出可复用的资产：要求清单表格、偏差报告、合规性报告不是一次性对话记录，而是可以进仓库、进审计包、进治理提案的文档。
  • 可量化的收益参考：以技能详情中的通胀示例为参照，一处精度偏差就可能造成约 27% 的通胀差异；在抽取质押与奖励章节的示例里，25 条要求中 22 条已验证、2 条存在偏差、1 条未在代码中找到——这类统计能让团队清楚知道“还差多少”。
  • 长期价值：把“文档与代码一致性”变成团队流程中的固定环节，而不是依赖某位资深工程师的记忆。

7. 常见问题 FAQ

Q1：这个技能怎么安装？需要付费吗？ A：安装方式是在支持 AI 技能的平台里，用英文名 multiversx-spec-compliance 或技能 ID 12526 检索并启用。具体支持的客户端列表、安装命令以及是否收费、如何计费，请以官方说明为准，本文不代为承诺。

Q2：它能替代正式的安全审计吗？ A：不能。它检查的是“代码有没有按规范实现”，属于设计忠实度核查；重入、溢出、权限提升这类安全漏洞属于另一类问题，需要专业的静态分析工具和人工审计。更合理的做法是把它当作送审前的自检工具，让审计师把时间花在真正的难题上。

Q3：它只认 MultiversX 的 MIP 标准吗？我自己的白皮书也能用吗？ A：可以。要求提取环节依靠的是 MUST / MUST NOT / SHOULD / SHALL / MAY 这类规范语言关键词，与你写的是什么标准无关。MIP-2、MIP-3、MIP-4 只是内置的常见对照项，你自己的白皮书、README 和 specs/ 目录同样适用。

Q4：输入需要准备什么？规范写得比较含糊怎么办？ A：需要三样东西：Rust 源码（src/*.rs）、规范文档（whitepaper.pdf、README.md、specs/）、以及要核对的 MIP 条目。如果规范表述含糊，技能的最佳实践建议是记录假设而不是默默判断，这样每条结论都能被追溯和复核。

Q5：适合谁用？和漏洞扫描工具怎么选？ A：适合 MultiversX 合约开发者、准备上审计的项目方、做升级评审的技术负责人，以及验证代币经济学实现的设计者。选择上不必二选一：漏洞扫描工具负责“有没有漏洞”，本技能负责“是不是按设计做的”，两者叠加再配合人工审计，才是完整的质量链条。