V1 → V2 转换¶
什么时候用？¶
- 你有一个 V1 格式的 Mind+ 扩展库，希望得到一个行为和积木一致的 V2 版本
- V1 源码保持只读，转换结果输出到一个全新的目录
- 希望保留原有
author、id、积木 opcode、参数顺序、下拉选项和生成代码行为，而不是重新设计一遍
不适合的情况
V1 与已有 V2 项目之间的同步不支持：已有 V2 项目想对齐新版 V1，请改用已有 V2 升级手动实现差异部分
具体要描述什么？¶
| 你需要提供 | 说明 | 是否必需 |
|---|---|---|
| V1 源码 | 上传模式含 arduinoC/main.ts，Python 积木模式含 python/main.ts | 必需 |
| 目标目录 | 转换结果输出位置，需为空目录 | 推荐指定 |
| 运行模式 | 上传模式 / Python 积木模式，一次只转换一个库、一个模式 | 可选 |
| 依赖处理 | 是否按 V1 原样保留依赖与版本 | 可选 |
| 敏感节点策略 | 遇到敏感冲突时是否暂停询问 | 可选 |
转换前会先查重
会用 V1 原库的 author / id 在官方清单与 Gitee 官方组织中比对：已存在同身份的库会沿用现有库继续开发（非本人仓库先 fork）；只有 id 与他人重名时，新目录会自动追加作者后缀作为去重手段
推荐提示词¶
方案 A：最小可用¶
使用 mindplus-extension-skills，把 extensions/v1-demo 从 V1 转换到 V2，输出到 extensions/v2-demo
保留原有积木、参数和生成行为，完成后走 Basic 审查，先不要发布
方案 B：明确模式与依赖处理¶
使用 mindplus-extension-skills 转换 extensions/v1-sensor 到 extensions/v2-sensor:
- 模式：上传模式
- 依赖：libraries 中的 Arduino 库按原样保留，不要升级版本
- 主板条件：与 V1 保持一致
完成转换并走 Basic 审查，先不要发布
方案 C：Python 积木模式¶
使用 mindplus-extension-skills 把 extensions/v1-ai 转换为 V2 的 Python 积木模式扩展，输出到 extensions/v2-ai
依赖只按 V1 的 requirements 记录原样写入，不要根据 import 自行推断、增删或升级，只做转换和审查
方案 D：转换后发布¶
方案 E：不确定模式时¶
AI 会怎么做¶
- 建立运行记录 —— 在网络、Git 或转换动作之前先开一个检查点日志，保证中断后可以恢复
- 查重与来源选择（Lite） —— 用 V1 原库的
author/id查询官方清单与 Gitee 官方组织，确认是否为已存在的库；涉及非本人仓库时先核验令牌与 fork - 从 V1 事实判断模式 —— 读取 V1 入口文件结构，输出候选模式、证据和置信度。出现并列、冲突或未支持的模式时会停下来让你选择
- 按需加载资料 —— 校验内置的 V2 规范资料集可用，并只加载本次转换真正需要的条目
- 准备目标项目 —— 下载并校验固定版本的 Builder 脚手架作为最终项目根目录
- 安装依赖（最多一次） —— 有超时与停滞保护。遇到卡住、锁冲突或权限问题时会停止等待，交给你手动处理，并继续完成后续的源码转换与静态步骤
- 冻结并转换行为 —— 再次读取 V1 做漂移比对（源码被改动则停止），然后生成 V2 配置骨架并逐项按证据填写；为每个可见积木、菜单、参数、生成代码片段、依赖、资源和主板条件建立语义对照
- 写入多语言与代码生成 —— 所有用户可见文本走稳定的多语言 ID；保留原有的 opcode、函数名、参数键与顺序、菜单取值
- 更新 README、执行静态检查与构建 —— README 校验、转换检查全部通过后才允许构建，构建同样最多一次
- 发布前审查（Basic） —— 核对配置合规、静态完整性、源码语义、恶意代码、构建通过、积木可见、积木可用和包体积（不超过 5,000,000 字节）八项；未通过不发布
- 交接 —— 输出日志路径、项目路径、检查结果和构建状态