代码审核¶
什么时候用？¶
- 开发完成后会自动进入发布前审查（Basic），不需要单独发起
- 已有一个扩展项目，只想拿到问题清单、不要改代码时，可以直接发起
- 创建 / 转换 / 升级的入口还会自动做一次查重（Lite），确认这个库是否已经存在
两级审核
Lite 在开发入口解决「这个库是否已存在、该基于哪份源码开发」；Basic 在产物完成后决定「能不能发布」
具体要描述什么？¶
| 你需要提供 | 说明 | 是否必需 |
|---|---|---|
| 项目路径 | 要审查的扩展项目目录 | 必需 |
| 关注点 | 例如恶意代码、包体积、积木显示 | 可选 |
| 来源决定 | 查到同名库时是否允许改用官方仓库 | 可选 |
推荐提示词¶
方案 A：只报告问题，不改代码¶
使用 mindplus-extension-skills 审查 extensions/v2-xx
重点看有没有可疑的外部命令或网络发送、打包出来的 ZIP 会不会超过 5MB、每个积木的 opcode 是否有对应的生成器函数
方案 B：不要替换我的来源¶
方案 C：审查通过后发布¶
先对 extensions/v2-xx 做一次 Basic 审查，全部必需项通过后再提交并推送到 gitee.com/<你的账号>/ext2-xx 的 master 分支，有 P0 就停下来把问题列给我，不要自动改
AI 会怎么做¶
一、入口查重（Lite）¶
按模式查官方收录清单，并在 Gitee 官方组织 mind-plus 中检索公开仓库。同模式、同类型下 config.author 与 config.id 都相同才算同一个库；Gitee 账号归属、仓库数字 ID、显示名称、SKU、功能相似度都不作为判重依据
| 比对结果 | 处理 |
|---|---|
author 与 id 都相同 | 用已存在的库继续开发；非本人仓库先 fork 到你的个人账号 |
只有 id 相同、author 不同 | 不是同一个库。新目录追加 -作者id（中文转拼音），config.id 保持不变 |
仅 author 相同，或名称 / SKU 相近 | 不算重复，作为候选线索继续核对 |
二、发布前审查（Basic）¶
八项必需检查，缺一项就不发布：
| 检查 | 通过条件 |
|---|---|
| 配置合规 | 当前模式的字段、类型与必需资源符合规范 |
| 扩展静态完整性 | 入口、资源、依赖、多语言、积木到生成器的映射完整 |
| 源码语义 | 代表性及高风险功能与需求、原库一致，并说明覆盖范围 |
| 恶意代码审查 | 在执行 npm 脚本或加载扩展之前审查源码、构建脚本与依赖，无未解释的危险行为 |
| 构建通过 | 实际执行构建、退出码为 0，产物来自当前源码 |
| 积木可见 | 产物正常加载，积木与二级菜单可用，参数、文字、图标、布局正常 |
| 积木可用 | 代表性积木实际生成预期代码 / 执行预期行为，记录输入、预期与实际结果 |
| 包体积 | 最终扩展 ZIP 不超过 5,000,000 字节，且包含 main.js 与 config.json |
问题分级：
-
P0 -> 阻断，修复后重查受影响项
编译不通过、config不合规或必填缺失、入口或依赖缺失、积木与生成器映射断裂、核心行为与需求相反 -
P1 -> 提醒为主，默认不阻断发布
命名、图片样式、积木颜色、非核心本地化、菜单分组 -
P2 -> 可以不改
排版、代码风格、注释
构建通过不能替代积木显示与行为验证，只读源码也不能写成已实际运行。构建或观察条件不具备时记为 NOT_RUN / BLOCKED，项目保留但不发布；修复之后要重跑受影响的检查才算验证完成，复用旧结论不算通过