minecraft-modding-skill

优化AI的一些代码规范

安装方式

• git clone
• 直接扔到对应的skills文件夹， 目前只测试在codex上的情况

如何判断触发

触发时AI会发这句话

我做了什么？

关于代码规范

• 所有新增物品和方块都必须加入模组对应的 creative tab/item group；方块需要包含其已注册的物品形式。只有用户明确要求不加入时才能排除，不能自行以内部、调试或测试用途为由省略；完成前必须检查分类填充与注册接线。
• 开始 Mod 实现前，先判断项目是空项目还是已有工程，并确认项目面向什么对象、是否准备上线或仍处于工程设计阶段。空项目只有在确认为 Mod API、API 适配或兼容层、插件/扩展平台、库或其他公共框架项目时，才按实际 API 需求设计结构化、抽象化、工厂化框架；普通功能按目标做最小实现，拒绝没有职责依据的过度设计。已有项目要先读取现有框架和代表性代码，分析调用方式、参数、变量、类设计和书写风格，再决定新增或修改功能需要多少框架。
• 禁止用 GPT 记忆猜测项目意图、上线状态、现有架构或 API 契约；证据不足且会影响设计时，先向用户确认。
• 这个规范限制无必要的静态常量，简单的一次性值优先保持在局部作用域
  • 因为AI会在一个功能内写入大量的静态常量， 而这个常量只在一个方法调用，我要求改为局部常量
  • 只有在写 物理，数学，自定义系统内容才会使用静态常量
  • 当存在多个相同语义的局部常量时，会考虑升级为静态常量
  • 当在方法中构建一个常量存在大开销时，会考虑为静态常量
  • 当删除多个功能时导致静态常量（不包含物理数学等常量类）几乎没有调用时，会降级为局部常量或删除
  • 单例，注册相关的内容会使用静态常量
  • 构造函数的默认参数值禁止引用静态常量；Kotlin 也不能用“构造函数参数默认值 + 同名属性再次赋值”的写法绕过这条限制。一次性功能参数应直接内联字面量，或改用显式重载。
• 我要求了AI在写代码之前先通过本Skill提供的脚本查询相关修改方法的相关调用，从而避免出现改了功能导致另外一个功能损坏的问题
• 我要求AI在修改，新增功能之前，会检查是否会和现有功能互斥， 存在互斥则会告知用户
• 我要求AI区分实现路径：只需完成现有接口或抽象类已声明的未实现契约，或只需增加独立代码且不改变既有契约时，直接实现即可；必须修改公共API或抽象方法契约时，先说明兼容性风险以及不能只靠实现或增量完成的原因，得到确认后再改；修改已有具体实现的行为时，先追踪调用方和影响边界，列出可能受影响的功能与验证范围，再实施
• 我要求AI区分共享能力和调用流程：A、B需要完全一致的能力时复用同一个核心实现；B特有的前置、后置或额外处理放在B自己的流程中，不得污染共享方法；核心语义不同时拆分实现；修复问题时按问题所属层修改，并分别回归共享核心和各调用流程
• 下面关于何时优先使用增量代码而不是修改原有方法或类的三条条件仍在讨论中，本次不作为硬约束
• 我要求AI在完成用户需求的时候， 如果存在歧义，会让AI停下来问用户（这里可能需要引导回复，如果不理会按AI自己的想法来）
• 我要求AI在完成接口，抽象方法的时候，一定会增加中文用例，注释 详细解释其中要实现的内容
• 我要求AI在创建 Manager、Helper、Util 等API入口或工具类时，为每个 public 方法添加详细的中文注释和简短用例。效果一眼可见的简单注册方法，或者名称和参数已经完整表达功能的方法（例如 Int.plus），可以省略用例，但不能省略必要的作用和契约说明。Manager 的类注释还要说明管理对象、管理方式和基本调用入口
• 我要求AI为所有枚举添加详细的中文介绍注释，说明枚举的领域和用途、全部成员的含义与有效使用范围，以及默认行为、生命周期、逻辑侧、序列化或兼容性边界等容易影响调用方的约束；成员语义未被枚举注释完整覆盖时，还要为成员单独添加中文注释
• 我要求AI在完成复杂算法的时候，按照算法初学者认为的复杂的情况，给算法添加行注释用来解释思路，分支思路
• 我要求AI在写浮点数，Double类型的时候，会按照人最正常的情况写（至少我是这么干的） 例如 1D,1.0, 1F,1.2
• 我要求AI在写kotlin类的时候，会查询类的扩展函数（这可能会减慢AI的速度或者增加token，如果你不需要这个功能可以让你的智能体删除掉这个约束） 优先采用实现好的扩展函数
• 我要求AI在写kotlin类的时候，对应getter setter属性会使用xxx.xxx 而不是xxx.getXxx()
• 我要求AI在为Mixin写接口Interface时，不采用modid$method的命名方式

关于工具

• 使用 Blockbench 建模时，优先使用当前会话实际可用的 Blockbench MCP，先核实工具及参数，不猜测接口；工具不可用或能力不足时说明限制，再使用可用且已获授权的替代方式。
• Blockbench 建模必须先完成 UV 展开，再参照实际 UV 布局或 UV 模板绘制贴图；禁止先画调色板/色块图，再把 UV 移动、堆叠或缩到色块上取色。调色板只能辅助选色，不能替代模型专用贴图；已有有效 UV 应保留，新增或修改的面必须同步处理 UV 和贴图。验收必须检查 UV 与贴图的对应关系，不能只看模型预览。具体流程见 Blockbench 建模规则。
• Blockbench 显示变换未被明确指定时，方块必须使用默认方块预设，武器必须使用武器预设。涉及 GUI、第一人称等显示修改时，也以对应预设为基础，仅覆盖用户明确要求的设置；不得自行设计其余位置的旋转、平移或缩放，也不得覆盖范围外已有的用户指定设置。必须核实当前环境中的预设及保存、导出结果，不能凭记忆编造预设参数。
• 我让AI补充了对于1.21.1 mojang mapping的源代码知识库
• 我让AI制作了大量查询方法引用，kotlin扩展函数的脚本（防止AI自己写自己查询，也算是节约时间了）