已有 V2 升级¶
什么时候用？¶
- 已有一个 V2 格式的扩展库项目（本地目录或 Gitee 仓库），要新增积木、修改行为或修复问题
- 需要提升扩展版本号，并同步更新 README 中的变更记录
- 目标仓库不是你本人所有（例如组织仓库），需要先 fork 到个人账号再改
不适合的情况
目标目录是空的、或要重建整个扩展，请用创建 V2 扩展；要从 V1 迁移，请用V1 → V2 转换
具体要描述什么？¶
| 你需要提供 | 说明 | 是否必需 |
|---|---|---|
| 目标项目 | 本地目录，或已克隆的仓库目录 | 必需 |
| 要做的改动 | 新增什么积木、改什么行为、修什么问题 | 必需 |
| 目标版本号 | 不指定则按语义化版本规则决定 | 可选 |
| 仓库与分支 | 非本人仓库需说明来源仓库与个人 fork 目标 | 非本人仓库时必需 |
非本人仓库先准备令牌
需要在本机准备好 Gitee 个人访问令牌；缺失时流程会停在等待状态并告知配置方式，不会读取远端或执行 Git 操作
推荐提示词¶
方案 A：本地项目加功能¶
使用 mindplus-extension-skills 升级 extensions/v2-xx：
新增「设置量程」积木，量程为下拉选择；已有积木的 opcode 和参数都不能改，要保持项目文件兼容
把 config.json 的 version 从 0.1.2 提升到 0.2.0，并在 README 里补上变更记录
做完回归验证并走 Basic 审查后告诉我结果，先不要发布
方案 B：修复问题¶
使用 mindplus-extension-skills 修复 extensions/v2-xx 的问题：
读取湿度时生成的代码写成了温度接口
请修正生成逻辑、补一个能覆盖这个行为的回归用例，并按补丁位提升版本号
方案 C：非本人仓库（先 fork 再改）¶
使用 mindplus-extension-skills 升级 gitee.com/mind-plus/xxx 这个扩展
请先 fork 到我的个人账号，在 fork 的分支上开发，新增 XXX 功能并提升版本号
未经我确认不要推送到原仓库，也不要创建 PR 或发布版本
方案 D：升级后直接发布¶
方案 E：先只做评估¶
使用 mindplus-extension-skills 看一下 extensions/v2-xx，告诉我：
1) 当前扩展版本号是多少；
2) 要实现「XXX 功能」大概需要改哪些文件；
3) 会不会影响已有积木的项目文件兼容性
AI 会怎么做¶
- 确认这是 V2 项目 —— 通过配置与入口文件特征判断，而不是「目录非空」就算数
- 查重与来源选择（Lite） —— 确认这个库的归属：本人所有、已验证的个人 fork，还是他人仓库。Git 作者名或协作者权限不能证明你是所有者，无法确认时只做只读分析并询问
- 非本人仓库处理 fork —— 先检查本地令牌，再通过官方接口验证账号并创建／复用个人 fork，核验 fork 的归属与上游关系；同名但无关的仓库会被识别为冲突而不是 fork
- 冻结基线 —— 记录改动前的项目哈希，作为只读证据，后续不会替换
- 制定改动计划 —— 明确积木行为、参数与默认值、生成代码、资源、依赖、支持主板和兼容性影响
- 实现功能 —— 修改配置、积木定义、生成器、多语言、库代码和示例；保留扩展身份、已有积木 ID 和项目文件兼容性，不替换脚手架，不自动升级无关依赖
- 提升版本号 —— 按仓库约定与语义化版本规则确定新版本，并同步所有镜像位置与 README 变更记录
- 验证 —— 运行配置、入口／资源、本地化和生成器检查，并用回归用例覆盖改动行为与保留行为
- 发布前审查（Basic） —— 核对配置合规、静态完整性、源码语义、恶意代码、构建通过、积木可见、积木可用和包体积（不超过 5,000,000 字节）八项；未通过不发布
- 交接 —— 输出已实现功能、新旧版本号、受影响文件、验证结果和限制