3. AI编写的SKILL，坑我一一试过，这次我自己改写：ivy-service-scaffold技能重写：去重、单一职责与逐条纠偏
上篇搞定了 tech-article-writer 技能纠偏和实战验证，接下来轮到后端代码技能——ivy-service-scaffold。
这是整套 SKILL 体系里最复杂的一个，涉及项目目录结构、包命名、配置、Pom 依赖、数据库设计等一大堆细则。以前我完全放手让 AI 写，结果老毛病又犯了——iron-law 的内容往具体技能里塞，举例当铁律，版本号写死。这次我强参与，把 8 条重点要求先列出来，再结合 Trae 逐条改，从大框架到细节，一条条盯着过。核心就一件事：AI 写 SKILL 必须人工逐条把关，否则它总拿鸡毛当令箭。
一、先列重点要求，再让Trae帮忙编写
ivy-service-scaffold 我也不是全部重新编写，还是结合 Trae 来编写的，只是以前我不管它怎么写，现在我强参与。
先把重点要求列出来，这些内容在 ivy-service-scaffold 中都是有的，我只是先提出来放在前面，让 AI 一开始就注意到：
SKILL调试模式
我对ivy-service-scaffold要先重写，有以下要求，要求是里面都有的，只是我提出来放前面。
1、ivy，jet，k，l 等这是版本，一般都是3，4个字母的简短单词
2、application.yml 中的配置要按ivy/jet 这样先配置 redis，mysql
3、每次生成的application，必须添加日志配置，StringUtils.banner，以及doc等。Application不在独立于jet目录，如果有jet.sys则放在jet。sys下面。
4、每个项目都必须按xxxs->xxx, model必须是放在models中，并且一定要单独放。
5、初步基础框架，如jet开头的项目，是要有jet-starter-cores，要按这样要求添加完成，后期开发的具体项目，是通过pom引用方式而不是源码方式
6、配置好sdk，maven，git、oss等地址，不要每次都搜索
7、项目目录下有doc目录用于存放设计文档，下面有sql存放数据库相关的，
8、数据库设计使用pdman方式
9、父子Pom，不可以跨级编写，如 a->b->c 不可以在a中配置b.c这种。
以上的内容在ivy-service-scaffold中都是有的，我只是先提出来。
SKILL重写，
一按大框架编写，大框架里面有具体细则。
先整理一下，先从大框架编写，再细节，如引用哪个jar，怎么编写 pdman这种具体的放细节中。
前面我列的8条是我重点关注的。因为每一条都是强制项，所以要总体整理一下语言。
记住，不要将举例当铁律，有时举例只是为了说明问题。
二、AI又把iron-law内容写进具体技能了
结果 Trae 一上来就犯了老毛病——又把 iron-law 的四大准则内容写到具体技能里了。明明前面重写 iron-law 和 tech-article-writer 的时候都说过，具体技能不需要重复 iron-law 的内容，它还是给你塞进去了。
本技能由 ivy 编写（author: ivy），受 iron-law 四大准则约束。执行本技能前，必须先实际 Read `.claude/skills/iron-law/SKILL.md` 加载四大准则，再处理具体任务。
又写了四大准则内容，不是说了不要写吗？为什么总是不听话呢
不行，一句都不能写。如果无法保证 iron-law 的强制性，就别搞了。
不行，一句都不能写，你如果无法保证iron-law的强制性，就别搞了
所以说 AI 没有脑子的地方就在这里，总是拿鸡毛当令箭。总以为用户说的每个字都是重要的，不可否认确实重要，但更多时候用户可能只是举例，想要的是 AI 的总结。不过困难的是，这是不可能的。
以下每一条均为强制项（铁律细则），使用「必须/不得/一律禁止/只能」等强制措辞。各条下的「示例」段仅为说明问题，不构成铁律本身——举例不是铁律，铁律是举例所服务的规则条文。本技能全部文字（含描述段/步骤/章节/示例）均为强制，无「软性/仅供参考」之分，AI 不得自行划分「硬约束/软说明」并选择性执行。本条各款解释以字面含义为准，不得作扩大或限缩解释。 这不还是重复吗？所以说AI没有脑子的地方在这里，总是拿鸡毛当令箭。总以为用户说的每个字都是重要的，不可否认确实重要，但更多的时候用户可能是举例，想要的是AI的总结，不过，困难的是， 这是不可能的。
三、去重与单一职责：各管各的事
反复说了几遍不要重复 iron-law 的内容，AI 总算听了。接下来先做个简单去重，把 iron-law 和 CLAUDE.md 里已有的内容从具体技能中去掉。
先做个简单去重之类的操作
和前面一样，如果iron-law里面有的，CLAUDE.md里面有的，就不要重复了。
再检测一下，是否有前后重复的。
去重之后，再按单一职责原则重新整理。核心思路很简单：iron-law 干主要事情，CLAUDE.md 管说明和桥，具体的 SKILL 只专注于自己的这一块——比如写作，比如后端。没必要的事情就不要插入了。
尽可能单一职责。
iron-law干主要事情
CLAUDE.md 说明和桥，
具体的SKILL，只专注于自己的这一块，比如写作，比如后端。没必要的事情就不要插入了。
每条尽可能作自己的事情，不要互相包容。尽可能每一条都是必须的，
按这一规则，再次重新整理。
四、逐条检查SKILL内容
基本框架搭好了，开始逐条检查 SKILL 内容有没有问题。一查就查出好几个：
同一服务的两个模块必须使用相同的 domain。
这话有歧义，没有这一项强制规定吧。
**细则 4.4**：依赖版本不得写死版本号，统一从根工程的 dependencyManagement / 父链继承（各 `<prefix>-starter-*` 均为 1.0.0）。
这也是写死的1.0.0,没必要这死。
文档排版约定（必须遵守）：本技能产出或修订的所有 Markdown 文档，标题（以 `#` 开头的行）内不要使用加粗或反引号代码等行内格式，保持纯文本。需要强调的内容或文件/路径引用，放到标题下方的正文、表格或说明块中。原因：在 Typora 中，标题内混用加粗与代码会导致显示异常。
明明写在前面，还会生成这样的标题，是不是有病
E. 文件模板（把 <domain>/<Domain>/<display>/<port> 替换为实际值）
这个有问题
几个问题逐一说：
第一，"同一服务的两个模块必须使用相同的 domain"这话有歧义，没有这一项强制规定。
第二，依赖版本写死了 1.0.0，没必要写死。iron-law 里都说了不得写死具体路径和版本，这里又犯。
第三，文档排版约定明明写在前面了——标题内不要使用加粗或反引号代码——AI 生成的时候还会写出带格式的标题，说了等于没说。
五、基本功能完成
基本功能完成。先按这个来编写，进行测试后再回头修改。
小结
这次重写 ivy-service-scaffold 后端代码技能，主要做了这几件事：
- 先列重点要求：把 8 条重点关注的要求先列出来——版本命名、配置顺序、日志与 banner、目录结构、基础框架、SDK 配置、doc 目录、PDMan 设计——再结合 Trae 编写，不再完全放手让 AI 主导。
- AI 屡教不改：明明说过不要在具体技能里写 iron-law 内容，AI 还是塞进去了。一句都不能写，它还理解不了。
- 去重与单一职责：iron-law 管主要事情，CLAUDE.md 是桥，具体 SKILL 只专注自己的领域。各管各的事，不要互相包容、互相重复。
- 逐条检查纠偏：SKILL 内容有歧义（domain 规则）、写死版本号（1.0.0）、格式问题（标题内加粗）等，逐条修正。
- AI 毛病根源：总拿鸡毛当令箭，把举例当铁律。这个问题在前面几个 SKILL 重写中反复出现，到这里依然是核心痛点。
整个过程最深的感受还是那句话：AI 有两大毛病——会将特例写进 SKILL 不会转换，总拿鸡毛当令箭。这篇又验证了一次——明明说了不要写 iron-law 内容，它非给你塞进去；说了不要写死版本号，它非给你定成 1.0.0。这些问题只有人工逐条盯着才能发现，AI 自己是发现不了的。
下一篇会记录验证后端代码 SKILL 的过程——用实际项目从头测，搞文档、生成代码，看看改完的 SKILL 到底能不能严格执行。
