Move代码质量检查器：对照 Move Book 检查清单，逐条审查你的 Move 包
- 它是什么：一个内置于 AI 编程助手的 Move 语言代码审查专家技能，按 Move Book 官方《代码质量检查清单》的 11 个类别、50+ 条具体规则系统分析 Move 包。
- 怎么触发：在包含
.move文件或Move.toml的目录中工作，或直接说“检查 Move 代码质量”“审查 Move 包”“检查 Move 2024 Edition 合规性”，技能会自动激活。 - 输出形态：结构化报告，含摘要统计（通过/推荐改进/关键问题）、带文件路径与行号的定位、坏例子与好例子对比、以及修复代码。
- 最大差异化：不是泛泛而谈的“AI 代码审查”，而是把一份真实存在的官方检查清单规则化落地，且以 Move 2024 Edition 为基线，能指出
edition缺失这类“一票否决”的关键问题。 - 适合谁：Sui Move 智能合约开发者、审计前自查的团队、正在从旧版 Move 迁移到 2024 Edition 的项目方。
1. 该技能叫什么？如何一键安装 AI 技能提升开发效率？
技能中文名：Move代码质量检查器Skill 技能英文名：move-code-quality 技能ID：12177
它解决的问题非常具体：Move 生态（尤其是 Sui）的语言版本迭代很快，Move 2024 Edition 引入了模块标签语法、方法链、宏、位置结构体等一整套现代写法，但大量存量代码仍停留在花括号模块、public entry、tx_context::sender(ctx) 这类旧风格上。人工审查这类问题既枯燥又容易漏，而通用 AI 对话又常常“说得很像但落不到具体规则”。这个技能把 Move Book 的检查清单变成可执行的审查流程，让“代码规范”从口头要求变成一份可交付的报告。
「一键安装」的思路
AI 技能（Skill）的安装本质是把技能文件放到 AI 编程助手能够读取的技能目录中，之后由助手在合适的上下文里自动加载。它带来的效率提升在于：你不需要每次审查前花时间写一大段提示词去交代“请按 Move Book 检查清单、按 11 个类别分析、给出文件路径和行号、区分关键问题与推荐改进”——这些约束已经固化在技能里。
安装与启用的一般步骤：
- 确认前提：你使用支持 Skill 机制的 AI 编程助手（例如具备技能目录或插件市场的客户端/IDE 插件），并且本地有可运行的 Move 项目环境（
Move.toml存在即可，无需先编译通过）。 - 获取技能：从官方技能仓库、插件市场或团队内部的技能分发渠道获取
move-code-quality技能包。具体的获取地址、安装命令与目录路径以官方说明为准。 - 放入技能目录：按客户端约定把技能放入对应目录（常见的做法是放置到助手的 skills/技能目录下并启用），或通过插件市场一键添加。具体路径与命名规则以官方说明为准。
- 重启或重新加载：让助手重新扫描技能列表。
- 验证是否生效：在包含
Move.toml的目录下向助手提问“检查这个 Move 包的质量问题”。如果技能已生效，你会看到它先读取Move.toml、扫描.move文件、识别测试模块，然后按“摘要 → 关键问题 → 重要改进 → 推荐增强 → 下一步”的结构输出报告。
判断是否真的生效的三个信号：① 它主动去读 Move.toml 而不是直接开始点评代码；② 它给出的问题带文件路径和行号；③ 它把 edition = "2024.beta" 缺失列为关键问题优先处理。
2. 该技能的主要功能和特点
- 清单驱动的系统化分析，而非随机点评：严格按 11 个类别展开——代码组织、包清单（
Move.toml）、导入/模块/常量、结构体、函数、函数体与结构体方法、Option 宏、Loop 宏、其他改进、测试、注释。覆盖面远超“随便看看”的对话式审查。 - 项目结构自动发现：自动在当前目录查找
Move.toml、用通配符定位所有.move文件、并识别以_tests结尾的测试模块，先建立项目地图再分析。 - Move 2024 Edition 合规性前置检查：把
edition = "2024.beta"或edition = "2024"作为第一优先级的关键项，因为清单中的绝大多数现代写法都依赖该版本。 - 规则带正反例，可直接照抄：每条规则都同时给出 ✅ 推荐写法与 ❌ 反例。例如能力结构体应带
Cap后缀（AdminCap而不是Admin）；错误常量用 EPascalCase（ENotAuthorized）而常规常量用全大写（MY_CONSTANT）；测试函数不要再加test_前缀。 - 函数签名与参数顺序专项审查：检查可见性（反对
public entry冗余组合，推荐public返回值以支持 PTB 组合）、参数顺序（对象 → 能力 → 原始类型 → Clock →TxContext恒在最后）、获取器命名（name/details_mut，而不是get_name）。 - 现代语法与宏的落地建议：方法链替代全限定调用（
payment.balance_mut().split(amount)、id.delete()、ctx.sender()、vector[10]与索引语法）；do!、destroy_or!、tabulate!、do_ref!、destroy!、fold!、filter!替代手写while循环；解包用..忽略多余字段。 - 依赖管理适配 Sui 1.45+：对 Sui 1.45+ 检查
[dependencies]中是否仍显式列出Sui、Bridge、MoveStdlib、SuiSystem（应改为隐式框架依赖），并检查命名地址是否带项目特定前缀（my_protocol_math优于通用的math）。 - 测试专项规则：合并
#[test, expected_failure]、expected_failure测试不做清理、避免滥用TestScenario、assert!里不写 abort code、优先assert_eq!、用sui::test_utils::destroy这个“黑洞”函数代替自造 destroy。 - 可交互追问：报告出来之后可以继续追问，比如“这个函数签名对吗”“审查我的
Move.toml”“我的测试有什么问题”，技能会切到对应的检查视角深入。
和普通工具比强在哪：格式化器只解决排版，编译器只解决能不能跑，通用 AI 对话解决“感觉”，而它解决的是“是否符合 Move Book 这份公认清单，以及具体在哪一行、该怎么改”。
3. 如何使用该技能？
步骤 1：进入 Move 项目目录
在包含 Move.toml 的包根目录下启动你的 AI 编程助手。这一步很关键，因为技能的发现阶段依赖当前目录结构。
步骤 2：用自然语言发起审查
技能支持多种触发方式，任选其一：
- 全包扫描：“检查这个 Move 包的质量问题”
- 审查清单合规性：“按 Move Book 检查清单审查我的代码”
- 版本合规：“我的项目符合 Move 2024 Edition 吗？”
- 单文件聚焦：“只审查
sources/vault.move”
步骤 3：明确范围（可选但推荐）
技能会询问你是要全包扫描还是特定文件/类别分析，以及这是新代码审查还是存量代码审计。存量迁移项目建议直接说：“这是从旧版迁移的项目，重点看 2024 Edition 兼容性和语法现代化。”
步骤 4：阅读报告
输出结构固定为：
## Move代码质量分析
### 摘要
- ✅ X项检查通过
- ⚠️ Y项改进推荐
- ❌ Z项关键问题
### 关键问题（优先修复这些）
#### 1. 缺少Move 2024 Edition
**文件**：Move.toml:2
**问题**：包清单中未指定版本
**影响**：无法使用检查清单要求的现代Move功能
**修复**：...
### 重要改进
### 推荐增强
### 下一步
每条问题都包含 文件 / 问题 / 影响 / 当前写法 / 推荐写法 / 修复代码 六个字段，字段之间留空行以便阅读。
步骤 5：输入示例与预期输出片段
示例输入（审查 Move.toml）：
[package]
name = "my_package"
[dependencies]
Sui = { git = "...", subdir = "crates/sui-framework/packages/sui-framework" }
预期反馈：❌ 关键问题——未指定 edition；❌ 过时——Sui 1.45+ 不应显式列出框架依赖。修复建议为补上 edition = "2024.beta" 并移除显式 Sui 依赖（具体写法以项目所用框架版本为准）。
示例输入（审查函数签名）：
public entry fun mint_and_transfer(ctx: &mut TxContext) { ... }
预期反馈：❌ public entry 属于冗余组合；✅ 推荐拆成可组合的 public fun mint(ctx: &mut TxContext): NFT 返回值形式，让 mint_and_transfer 由 PTB 链式完成，从而获得可组合性。
示例输入（测试）：
#[test]
#[expected_failure]
fun test_this_feature() { ... test.end() ... }
预期反馈：应合并为 #[test, expected_failure]；expected_failure 测试不应做清理，直接以 abort 结束以暴露失败点；测试函数名去掉冗余的 test_ 前缀。
步骤 6：交互式深入
报告后可继续要求“自动修复这些问题”“解释第 3 条为什么这么改”“再多给几个 Move Book 的例子”，或指定“深入分析 Loop 宏这一类”。
4. 同类型竞品对比分析
| 方案名称 | 定位 | 核心功能 | 安装/使用门槛 | 适用场景 | 优势与不足 |
|---|---|---|---|---|---|
| move-code-quality（Move代码质量检查器） | 清单驱动的 AI 代码质量审查 | 按 Move Book 11 类 50+ 条规则分析，输出带行号的结构化报告与修复建议 | 需支持 Skill 的 AI 助手；放入技能目录即可（以官方说明为准），无需额外编译 | 审计前自查、版本迁移、Code Review 辅助、团队规范落地 | 优势：规则明确、有正反例、覆盖测试与注释；不足：属于建议型审查，不保证编译通过，也不做形式化证明 |
| Move 格式化器（movefmt 等） | 代码风格自动化工具 | 统一缩进、换行、空格等排版 | 需单独安装 CLI 或在编辑器/CI 中集成 | 提交前自动排版、CI 卡点 | 优势：确定性强、可自动化；不足：只管格式，不管语法现代化、参数顺序、宏用法等语义级规范 |
| Move Prover（形式化验证工具） | 形式化规格验证 | 用规格语言描述不变量并数学证明 | 需学习规格语言，配置与运行成本较高 | 核心资产（金库、清算逻辑）的高保证验证 | 优势：强度最高；不足：学习曲线陡、不关注代码风格与 2024 语法现代化 |
| 通用 AI 对话 + 手工提示词 | 泛用型代码评审 | 依赖用户自行描述审查标准 | 零安装 | 零散问题咨询 | 优势：灵活；不足：每次都要重述标准，容易泛泛而谈，缺少“文件:行号”级的规则映射，结果不稳定 |
结论：格式化器管“长相”，Prover 管“正确性”，move-code-quality 管“规范与现代化”，三者互补而非互斥。实践中常见的组合是：格式化器进 CI，本技能做人工评审前的第一轮清扫，Prover 用于核心模块。
5. 该技能的典型应用场景与实际体验情况
场景一：从旧版本迁移到 Move 2024 Edition
角色/痛点：一个已经上线过一版合约的 Sui 团队，代码写得能跑，但全是花括号模块、use ...::{Self}、vector::push_back，不确定迁移到底要改多少、从哪改起。
使用方式：在包根目录发起“检查 2024 Edition 合规性 + 全包扫描”。
实际体验：这类场景收益最直接。技能会把“缺少 edition”放在关键问题第一条，然后按文件列出传统模块语法、public entry、显式框架依赖、手写 while 循环等可批量替换的模式。上手难度低，几乎不需要额外学习成本；注意事项是改动量大时要分批应用，先改 Move.toml 和模块语法，再改函数体，否则一次性修改容易定位不到编译错误来源。
场景二：提交审计前的自查清扫
角色/痛点：准备送第三方审计的开发者，希望把“不值得占用审计预算的低级规范问题”先自己清掉。
使用方式：全包扫描后，只看“关键问题”和“重要改进”两节，把“推荐增强”留到最后。
实际体验：审查阶段的定位信息（文件 + 行号）非常省时间，报告可以直接贴进 issue 列表分配任务。注意点是不要把它的通过当成安全审计结论，它检查的是代码质量与规范，不覆盖经济模型与逻辑漏洞。
场景三：团队 Code Review 规范统一
角色/痛点：多人协作时每个人风格不同，Review 时反复争论“该不该加 test_ 前缀”“能力结构体要不要加 Cap”。
使用方式：把技能输出的报告作为评审基线，让规范讨论从“我觉得”变成“清单第几条”。
实际体验：因为每条规则都有官方清单来源与正反例，争议成本明显下降。注意事项是团队需要先约定哪些类别设为强制（例如 edition、public entry 强制），哪些仅作建议（例如注释密度），否则会产生新的争论。
场景四：带着具体疑问的定点审查
角色/痛点：开发者只想知道“我这个函数签名到底对不对”“我的 Move.toml 有没有问题”。
使用方式：直接问“此函数签名正确吗”或“审查我的 Move.toml”。
实际体验：技能会切到对应视角，聚焦参数顺序、可见性、获取器命名，或版本/依赖/命名地址前缀。响应快、结论明确。注意点是单点提问容易漏掉全局问题，重要版本上线前仍建议跑一次全包扫描。
6. 该技能能为用户带来的价值
- 把“规范”从记忆负担变成可执行流程：11 类 50+ 条规则原本散落在 Move Book 文档里，靠人记靠人翻；现在一次提问就能逐条对照，显著降低查阅与记忆成本。
- 审查效率的量级提升：人工逐文件对照清单，一个中等规模的 Move 包往往要数小时；技能可在一次交互中完成结构发现、清单比对与报告生成，人只需要处理“确认与修复”。
- 降低 Move 2024 Edition 的迁移门槛：
edition缺失、花括号模块、旧式coin::split、手写循环这些高频迁移项都有明确的“当前 → 推荐”改写示例，相当于一份可交互的迁移手册。 - 让可组合性成为默认习惯：通过持续提示
public entry冗余、建议返回值的可组合函数，帮助团队自然形成适配 PTB（可编程事务块）的写法，这是 Sui 生态里最有价值的长期习惯之一。 - 可量化的收益方向：以“关键问题数 / 改进推荐数”作为项目健康度指标，在每次迭代后复测，观察两个数字的收敛趋势；同时可统计因规范问题被打回的 Review 轮次是否下降。
- 长期价值：规范一致的代码库对新成员更友好，审计沟通成本更低，重构与升级时的阻力更小。
7. 常见问题 FAQ
Q1：这个技能怎么安装？装完怎么确认能用？
A：它属于 AI 技能（Skill）形态，一般做法是从官方渠道获取技能包后放入 AI 编程助手的技能目录并在客户端启用，具体目录路径、命令与获取入口以官方说明为准。验证方式是：在含 Move.toml 的目录里问“检查这个 Move 包的质量问题”，若它先读 Move.toml、再扫描 .move 文件、最后输出带“文件 + 行号”的结构化报告，就说明已生效。
Q2：使用它收费吗？需要联网或额外装编译器吗？
A：是否收费取决于你使用的 AI 助手与技能分发渠道的计费方式，以官方说明为准。从技能描述看，它的分析基于读取项目文件（Move.toml 与 .move 文件）并与 Move Book 检查清单比对，并未要求先编译通过，因此不需要你先跑通构建就能做规范审查。产物是建议，不是编译结果。
Q3：它适合谁用？我是 Move 新手，用得上吗？ A：最适合三类人：正在做 Move 2024 Edition 迁移的团队、送审前的项目方、以及需要统一 Review 规范的多人协作组。新手同样用得上——因为每条规则都给正反例，报告本身就是一份“边改边学”的教材；建议新手先只看“关键问题”，一次改一类，避免被几十条建议淹没。
Q4：它和格式化工具、形式化验证工具怎么选？会冲突吗？ A：不冲突，层次不同。格式化工具解决排版一致性、可进 CI 自动执行；Move Prover 类工具解决数学意义上的正确性；本技能解决“是否符合 Move Book 检查清单、是否用了 2024 Edition 的现代写法”。推荐顺序是：格式化工具进 CI 兜底 → 本技能做人工评审前的第一轮清扫 → 核心资产再上形式化验证。
Q5：它说“通过”就代表代码没问题了吗？ A：不代表。它的定位是代码质量与规范审查，判定依据是清单规则，不覆盖业务逻辑漏洞、经济模型风险与权限设计缺陷。合理预期是：它能帮你把规范类问题清理干净，让审计和人工 Review 聚焦在真正有风险的地方。另外，由于部分建议会随框架版本演进（例如 Sui 1.45+ 的依赖管理变化），落地前建议核对项目所用框架版本。