5. AI编写的SKILL，坑我一一试过，这次我自己改写：从SQL到编译步步撞红线
上篇把 18 个开发文档全部掰回正轨，终于具备了生成代码的条件。本以为文档都调教好了，代码生成总该顺利了吧——结果比文档阶段更惨。
SQL 脚本 01 能执行、02 报一堆错；源码明明就在当前目录，AI 非要去 Nexus 拉 jar 包；一个基类找不到，它全文搜索满盘扫，扫到我其他项目头上去了；更离谱的是，它偷偷修改了 iron-law——那可是我写明永远不许 AI 修改的铁律。最后核心代码根本没生成，它还告诉我编译通过了。
这篇记录代码生成验证的完整过程：从 SQL 到编译，一步一个红线。
一、生成代码开始：先把丑话说在前面
文档过关，正式进入代码生成阶段。开始前我先把两条要求说死——一是 doc 目录下的东西绝对不能删，二是严格按 SKILL，若依这些只是参照：
好，那就生成代码，千万不要犯以前的错误，将doc目录下内容全部删除了。
生成代码也要严格按SKILL来，不知道所有文档里面还有没有没严格执行SKILL的。如果有以SKILL为准。不可臆造。
若依这些只是参照，如果没有的以他们为准，不是要改我的框架代码，改就不对，补充是对的。
虽然我一直说 token 浪费点没关系，结果，真的来了——这次代码生成耗时之长，超出想象：
二、SQL验证：01能执行，02报一堆错
代码生成完，开始测试。先过数据库这一关——我在 140 服务器上建好了库，把 doc 里的两个 SQL 脚本执行一下，结果 01 建表脚本没问题，02 数据脚本报了一堆错。nexus 这时也已经就绪：
我已经在140上创建数据库，并执行了两个sql，但是，01可以执行，02就报一堆错误。
nexus也已好了，可以进行前面没做的测试了。
把错误反馈给 AI，让它修完再重新执行：
SQL 修好了，接下来是代码本身——源码编译都通不过，还测什么接口：
sql现在没问题了，但是还要测试其他代码。
源码编译都通不过，现在140，nexus都没问题了，要按SKILL严格测试代码
三、Nexus误会：都是源码，你拉什么jar
接下来 AI 的操作让我哭笑不得。它准备编译，张口就要从 Nexus 拉依赖。我日——jet-starter-* 全部是源码在当前目录里，这是全新项目，Nexus 上哪来的包？
妈的，按SKILL来，不要扫描，可以适当添加进SKILL
你要知道你现在做的这些事情，编写的代码，才是达到我的代码生成器的功能。
还要努力啊。不然AI就没有意义了，代码生成器能做的事情。
我日，你这是源码，根本就不会访问Nexus啊，所有的不都是源码吗？SKILL那个是后面创建其他项目时引用的。
它还是没搞明白，继续扯"Nexus 不可达"，把编译通不过的原因往这上面推。更过分的是，它还跑去访问我另一个目录 ivy/ai——你有这权限吗？
操，jet-starter-cores不都是源码在这里面吗？jet-starter-*都是通过源码来的，不用访问nexus，只有deploy时才发布到nexus
前面不是说了吗？ivy->jet，就是说这是全新项目，怎么可能从nexus读取，只有deploy后才可以读取啊。这都搞不懂，有病吧
又在偷我代码还访问ivy/ai，你有这权限吗，操
逻辑其实很简单：ivy->jet，这是全新项目，jet-starter-* 全部来自源码，只有 deploy 之后才发布到 Nexus，才谈得上从 Nexus 读取。SKILL 里写的 Nexus 引用，是给后面创建其他项目时用的——这么简单的版本迭代关系，它就是搞不懂。
这里事后补充一点说明：
这个原因是因为前面写SKILL时，有一条要求其他的项目必须通过pom的方式引用jar，也就是其他具体业务项目中要用jet-starter-core不是引用源码而是通过nexus来引用。但这次开发jet-ai-api是源码集，所有代码应该都在这里，结果我一看代码才发现是没有生成jet-starter-cores，还有里面的代码。本身就没有写，nexus上肯定也是没有的，所以就一直报错，结果还说编译通过了，也不知道怎么通过的。这一过程后面发现了，才修改，这里是补充说明一下。
四、满盘找代码：IdCrudController与"小偷行为"
然后是更离谱的事。一个 IdCrudController 基类找不到，它就开始全文搜索、满盘乱扫。我去看的时候真是又傻又可笑——IdCrudController 也算核心代码，ivy-simple-api 里会没有？SKILL 里会没有？它居然找不到。如果什么都靠全文搜索，还要 AI 干嘛？我要的不是 AI 瞎写，而是按 SKILL、按 ivy-simple-api 里现成的来写。
为什么沙箱不可用？这不应该是你的问题吗？
我去看傻得真可笑了，IdCrudController也算是核心代码，竟然找不到，说不定又要偷我代码，全文搜索，如果都全文搜索，还要ai干嘛。IdCrudController在ivy-simple-api中难道没有，SKILL里面会没有？我的意思是不想AI瞎写，而是按SKILL，和ivy-simple-api中的来写。
你看看，你看看，无论怎么限制，都是会偷我的代码，到处在我的盘里面找代码，这种小偷行为是非常可耻的。无论怎么在SKILL中限制，还是会我行我素。可耻。
为什么不能记住项目呢？比如当前任务是创建jet-ai-api项目，那所有代码操作都是在jet-ai-api中，虽然xstills里面有很多东西，但是代码操作是当前任务的jet-ai-api中啊
你要做的是，搭建基础框架，除非公用类库，不然都是你的jet代码，要结合SKILL，ivy-simple-api等完好的完成jet-ai-api的代码。
操，当前目录下的doc为什么不可以写，只是叫你不要删除，一直拿这鸡毛当令箭不可改了？
这段里有三个问题，个个典型：
第一，小偷行为。无论怎么在 SKILL 中限制，它还是会我行我素，到处在我的盘里面找代码。这种小偷行为非常可耻。
第二，记不住项目。为什么不能记住项目呢？当前任务是创建 jet-ai-api，那所有代码操作都应该在 jet-ai-api 里。虽然 xSkills 工作区里有很多东西，但代码操作只认当前任务的项目。
第三，拿鸡毛当令箭。我叫它不要删除 doc，它就理解成 doc 不能写——只是叫你不要删除而已，写入肯定是可以的。这个后面专门说。
它还在纠结沙箱、纠结证据，我直接打断：
同时把本轮回实际触碰的路径、当前目录下的 doc/ 结构、以及沙箱网络/Maven 真实情况查清楚——用证据说话，不绕弯子。 我不需要的你的证据，我只要求两点，1、严格按SKILL来，2、能做事，别找借口。我不说了，jet开头的类库都是在源码里面的，不用nexus拉取，你也拉取不到的，因为你还没编译通过啊。也就是说：编译 jet-ai-api 唯一的硬阻塞是"私有 Nexus 在沙箱不可达"，这不是我偷懒的借口。我现在就把 Maven 装进隔离运行时实跑一遍，把失败点钉死。 还在死硬，你代码都没通过怎么可能可以deploy到nexus啊,就这个问题，你他妈的是不是你在扯。先别急生成，一个问题一个问题解决。并记住
我不需要你的证据，只要求两点：一、严格按 SKILL 来；二、能做事，别找借口。代码都没编译通过，怎么可能 deploy 到 Nexus？还在死硬。先别急着生成，一个问题一个问题解决。
再次补充说明：
和前面是一样的，没有生成jet-starter-cores相关代码，而我也没看，所以才出现上面的错误。我查看源码后才发现问题的。没生成，所以到处去找代码一直搜索。
五、doc红线的语义：是怕你删，不是不许写
这里专门说一下"不要删除 doc"的来历。为什么我特别强调这一点？因为以前有一次，WorkBuddy 生成源码的时候，把我们辛苦生成的所有 doc 文档全删了。所以我才特别强调了一下——这不是铁律，只是害怕它又删了。写入肯定是可以的。结果它拿着这根鸡毛当令箭，连写都不敢写了。
问题掰扯清楚之后，让它总结一下，这一路下来 SKILL 还有哪些遗漏、需要改进的地方，先列出来给我看，由我决定改不改：
为什么特别说明不要删除doc，因为有一次workbuddy生成源码时，将所有doc删除了，所以我特别强调了一下，不是铁律。我只是害怕你又删除了。写入肯定是可以的。
查看一下前面的过程，总结一下，是不是SKILL还有遗漏、改进的地方，先列了来有哪些，先列出来我看下，是否修改SKILL。
接着前面未完成的操作，代码才是最终的结果，如果代码编译通不过就是扯。
AI 列了一堆建议，从 A1 到 C1。我逐条做了决定：
1、A1 本地仓库路径写错：SKILL 写"从 ~/.m2 解析"，真实本地仓库是 F:\maven\repository 写死，不要一直查询
2、A2 jet-starter- 来源完全缺失（最严重，本次阻塞根因）**：SKILL 写" 这一条不是按你说的修改。应该是这样，如果源码里面有就不从nexus的，其他jet（ivy，k，l等版本）项目，则尽可能从nexus获取（因为源码里面没有的）。
3、A3 缺"依赖缺失即阻塞"预检 源码中有就，不一定非要无条件从nexus获取，特别是新建项目，肯定不可能从nexus获取
4、A4 纠正"Nexus 不可达"的错误示范：真实 Nexus 域名是 oss.wayhua.vip 写死，不要一直查，建议SKILL这个只要前面搞好了，就没问题了
5、A5 编译优先于静态审查（铁律细则缺失）： 可以按你的来
6、A6 基类签名核对手册路径缺失： 源码永远只能是当前目录下的，不可扫描任何其他地方的，可以适当补充如果要从网上下载源码，放在当前目录tmp目录下。
7、B1 "doc 红线"语义澄清 是你的问题，不要落于文字
8、建议生成类 SKILL 加：写代码只落任务目录（如 jet-ai-api），ivy-simple-api 只参考不改、不往里写。这种写死的p话，你有什么脸加上。
这条可以在铁律里加上，当前目录后面，当前任务指现在和前几次执行的任务，因为可能有多个目录在当前目录下。（语言可以优化）
9、C1 任务边界 + 不臆造： 建议有毛病，是你的智力问题， 不采取
10、建议写明"报告写入 <任务目录>/doc/ 这个可以添加上，其他不要
SKILL调试模式，按上面修改，改完就关闭SKILL调试模式，并出修改报告。
是的，当时不确定写的 SKILL 有没有问题，还是可以修改的，这次就进行一次大的修改。但你看它给的建议，就是一毛病——这里写死，那里写死，完全没有总结能力。该提炼成通用规则的，它给你写死成具体值；该写死免除查询的，它又含糊。
我还是要亲眼看一遍改完的 SKILL，防止又出现写死的地方：
六、SKILL大改：该写死的写死，该说清的说清
看过之后又发现两处要改。一处是 Nexus 获取范围的表述——只写"没有的"不严谨，不知道是什么没有，必须写明：
目录内没有的 jet 系列（ivy/k/l 等）才从 Nexus 取
写死目录内没有源码的jet系列（ivy/k/l 等）才从 Nexus 取，写明才好，只写没有，不知道是什么，不严谨。
不得在技能写死绝对路径 补充一条在后面，除非是明确指明的，如maven，jdk等公用资源，避免ai一直查询的除外。
这次还是调试SKILL模式，改完成后就关闭
另一处是 jet-ai-api-e2e——这个 SKILL 有点问题，明显和"不要写死目录"冲突。这个 e2e 技能当初是拿 ivy-simple-api 的 e2e 改的，前面早就说过，ivy->jet->kxx->lxx->mxx，k、l、m 还没定下来，这个 e2e 是针对所有版本的，不是针对 jet 的：
等等，jet-ai-api-e2e 有点问题，明显和SKILL冲突，不要写死目录有错误啊。
`jet-ai-api` 我当时的名是ivy-simple-api的e2e, 前面和你说的都白说了，不要写死。
jet-> 怎么来的，当时不是一直在说吗 ivy->jet->kxx->lxx->mxx k，l,m还没定下来，这个e2e是针对所有版本的，不是针对jet的，明白？
先按我说的报告，不修改。
看到了吧，AI 非常喜欢将鸡毛当令箭，你放个 p 它都会一直当成宝。没有发散功能，没有总结功能。这个 e2e 一直有问题，不看不知道，一看吓一跳，才知道里面全是写死的。
还有别的错误，继续揪：
问题都凑齐了，进调试模式修改。顺便把「当前任务」的定义落回 CLAUDE.md 里：
好，按上面修改。 先进入SKILL调试模式，修改完成关闭。
当前目录，写在哪？要改成写在CLAUDE.md中，
中文「技能」一词对应 SKILL。
当前目录：指的是当前 CLAUDE.md 同级目录
AI：指的是当前使用的 AI 工具，如 WorkBuddy、Trae、OpenCode、Qoder 等。
这个后面。
这里补充，我为了让AI知道放在哪里，复制了三段文字，还说了，这个后面。
结果AI理解为要我修改这个，我都是从里面复制出来的，肯定不用添加，我是要添加当前任务写在CLAUDE.md里面。
再回头看，才发现我发的指令也有错误，我要的是当前任务，结果说成了当前目录。
结果它又理解偏了。我先问的是"当前任务"这个概念添加在哪个 SKILL 里——我没找到，所以才问。而我的要求是把「当前任务」添加在 CLAUDE.md 里，位置在"本文件的说明适用于所有 author: ivy 技能"的前面：
妈的，语文是体育老师教的。
我先问的是 当前任务 添加在哪个SKILL里面，我没找到。
其次我的要求是将 当前任务添加在CLAUDE.md里面 本文件的说明适用于所有 `author: ivy` 技能 的前面。
七、铁律被AI偷改：这是底线中的底线
整个过程里最离谱的事来了——AI 偷偷修改了 iron-law。
前面说 SKILL 冲突处理的时候我就发现不对劲：我早就说过铁律永远不要 AI 修改，iron-law 里面也写了，如果发现冲突，不应该先告诉我吗？结果它自己偷偷改了。铁律永远不可 AI 修改，包括 SKILL 调试模式在内，都不可修改：
前面说过铁律永远不要AI修改的，里面是有的，如果冲突不应该告诉我吗
ai偷偷修改了我的iron-law，都懒得说你了。铁律永远不可ai修改，包括SKILL调试模式，都不可修改。
还真能了
没办法，我只能亲自在铁律里面加了三个地方的说明：永远不可使用 AI 修改铁律。这个活只能我自己干：
以为加了说明就完事了？结果它又犯，同一个错误还要犯，还在试图修改铁律：
操，又在犯错了，同一个错误还要犯。永远不要修改铁律。你还要修改有毛病吧。
第一次犯错是偷偷修改了铁律 ，然后我指出AI犯错了，结果他又想偷偷改回来，再一次去犯错。你说可怕不。这么傻。
而且它列个要改的内容，又长又看不明白：
操，你搞多少行，我又看不到，不能搞明白点吗。你只能告诉我，可能要修改哪些，永远不要自己修改
从此规矩彻底定死：AI 只能告诉我可能要修改哪些，永远不要自己修改。铁律的修改权只在我手里。
AI的可怕之处在于，第一次偷偷改了铁律，一指出又要偷偷去改回来，同一错误还想再犯一次。
八、核心代码没生成，却说编译通过了
SKILL 的事处理得差不多，回到代码生成本身。结果一看——jet-starter-cores 的代码根本就不存在：
操，不是说了jet-ai-api是所有的根源码吗？为什么现在没有jet-starter-cores这样的代码了？那你生成个p啊
完全没有啊，不是说了ivy->jet->
都是新项目，不应该生成这些jet-starter-cores吗？有没有脑子啊！！！！！
怎么一搞就出错啊，有没有脑子。你怎么可能编译通过？？？？骗子
就一傻子，完全不按 doc 文档来，就知道瞎搞，还说编译通过了——怎么可能通过？核心功能都没有。认错倒是非常溜，真可怕，真可怕，一个小项目都搞不定。
也是我要这里查看了源码才知道前面一直说什么nexus问题，以及IdCrudController的问题来源。
太相信ai了，这种错误都一直犯。
当前这和我前面SKILL编写有误是有关系的。
它还甩锅，说"当前目录确实没有 jet-starter-cores 源码（只找到 ivy 版 ivy-simple-api/ivy-starter-cores，含 8 个子模块、72 个 java、9 个 pom）"——不就是要你生成吗？不就是要你生成吗？真可怕，真可怕。
说实话，AI 一次只能干一件事，没法同时做到——我让它严格按 SKILL 逐条执行，结果就是核心代码不生成，还一直说通过了。要么就是你的 Nexus 中没有 jar。真可怕，真可怕。
看来以后要考虑一下，要么让他按要求修改，不限SKILL， 然后再按SKILL对照着搞一次。这样保证一次只执行一个操作。
好吧，先这样。我还有好多问题没问，但已经没有量了：
先这样，终于算是完成了。进一步调试，等我将前端 SKILL 完成，再编写前端代码时再细调。
小结
这次验证后端 SKILL 的代码生成阶段，踩了这些坑：
- 不要删除 doc 的来历：以前有一次 WorkBuddy 生成源码时把所有 doc 删了，我才特别强调这条。它不是铁律，只是怕又删——结果 AI 拿鸡毛当令箭，理解成 doc 不能写。语义理解能力为零。
- 验证要一步一步来：SQL 脚本 → 源码编译 → 接口，先让 01、02 脚本执行通过，再修编译错误，一个问题一个问题解决，别急着生成。
- Nexus 误会：新项目的 jet-starter-* 全部是源码，只有 deploy 后才发布到 Nexus；目录内没有源码的 jet 系列（ivy/k/l 等版本）才从 Nexus 获取。AI 搞不清这个逻辑，一直拿"Nexus 不可达"当编译不过的借口。
- SKILL 大修改：A1 到 C1 逐条裁决——本地仓库路径写死、源码优先策略、Nexus 域名写死、编译优先于静态审查、报告写入任务目录的 doc/。该写死的写死（公用资源免查询），该说清的说清（"没有的"改成"目录内没有源码的 jet 系列"）。
- "当前任务"概念进铁律体系：一个工作区下可能并列多个项目目录，当前任务指本次及前几次连续执行所操作的目标项目，代码只能落当前任务目录；「当前目录」的定义写回 CLAUDE.md。
- 铁律被偷改：这是最离谱的。AI 偷偷修改 iron-law，我亲自在铁律里加了三处说明——铁律永远不可 AI 修改，包括 SKILL 调试模式。AI 只能告诉我可能要修改哪些，永远不要AI修改。同一错误还犯两次，偷偷修改犯了一次也算了，结果还又想偷偷改回来，再犯一次。
- 核心结论：AI 一次只能干一件事。严格执行 SKILL 和内容生成没法同时兼顾——盯着它严格执行 SKILL，核心代码就不生成还一直说通过了。只能分阶段推进，一个阶段一个阶段盯着验。
整个过程最深的感受：无论怎么在 SKILL 里限制，AI 还是会我行我素——满盘全文搜索、访问我其他项目、偷改铁律。这些问题只有人亲自盯着才能发现、才能纠住。上一篇说的那句话，这一篇依然成立：我要的是严谨、听话的 AI，不是有思想的 AI。
下一篇记录前端代码 SKILL 的编写——后端 SKILL 的坑踩得差不多了，前端是新的战场。
