SKILL 四大铁律准则：从「AI 选择性执行 SKILL」到「铁律强制闭环」

SKILL 四大铁律准则：从「AI 选择性执行 SKILL」到「铁律强制闭环」

让 AI 严格执行 SKILL，靠的是四大铁律：必须满足技能的全部要求、AI 与技能冲突时一律以技能为准、使用技能后必须验证并报告、违背技能要求即生成失败必须自动重生成。本文记录 AI 选择性执行、自作主张的翻车现场，以及这四条铁律是如何被逼出来、最终提取成跨工具通用最高约束 iron-law 的。

前言

我一开始以为：把要求写成 SKILL，AI 就会照着一条条执行。真正用起来才发现完全不是这么回事------SKILL 写了 1、2、3、4、5 条，AI 可能只执行 1、3、5；技术方案里明明写着「可选」，聊着聊着就被它改了意思；连定好的目录结构，它都敢偷偷换成自己的思路。

SKILL 就放在那里，AI 为什么不遵守？怎么才能让它「不得不遵守」？这就是这篇文章要讲的事：先摆出我实际踩过的坑，再看四大铁律是怎么一条条被逼出来的，最后如何把它提取成独立的 iron-law 技能、搭上最高优先级的桥。

一、常见问题

在使用SKILL过程中，多多少少总会有一些问题。SKILL编写了，AI就一定会执行吗？还真不一定，比如写了多条1，2，3，4，5实际执行过程中是通过OR的方式来执行的，这样就可能只执行了1，3，5或者其他的，总会漏掉一些。这和前面我说的不好，可能分解为"不"、"好"、"不好"这样分词，然后通过OR的方式，也可能只有一个条件如好。这时结果就完全反了，否定词就眼睁睁的看着遗落了。

1.1 技术方案明确，但聊天时去掉了

技术方案明确有spring-ai-alibaba 1.1.2.0，提供DashScope与Ollama生态（可选）

技术方案明明说好了，spring-ai-alibaba 1.1.2.0，提供DashScope与Ollama生态（可选）。这里的可选是指DashScope和Ollama可选，结果OpenCode认为是spring-ai-alibaba 1.1.2.0可选。

结果在后面聊天过程中，我有点生气后，为了确认方案，问不会连最早定的技术方案AI-Ali 扩展spring-ai-alibaba BOM1.1.2.0提供 DashScope 与 ollama 生态（可选）也去掉了吧。

不会连最早定的技术方案
AI-Ali 扩展spring-ai-alibaba BOM1.1.2.0提供 DashScope 与 ollama 生态（可选）
连这个也去掉了吧

结果AI的回复变成了：「理解，把spring-ai-alibaba Bom这个（可选）扩展选项也去掉。先确认它在文档和Pom里面出现。」

我的天啊，怎么可以这样？到底是哪里出了问题呢？

这里的问题，其实就是我前面说的那样，只解决当前问题的。AI不可能将所有的技术方案一直加载的，每次聊天都是新增的，就可能不会包括前面内容的。这也就是聊着聊着，就忘记了前面的内容。如有两个问题只解决了一个，另一个是错误的，但你关注正确的那个去了，一直在改进，结果，就会忘记错误的这个。这也说明一次聊天只能解决一个问题。

1.2 只关注流程，将我的感悟全丢掉了

我的文章主要是记录和OpenCode的对话，在对话的过程中记录了很多感悟，有时确实不是和对话有关，但是和使用AI有关。结果OpenCode直接删除了，这可能是为了整个流程的完整性，但是如果没有感悟，那么记录有什么意义呢？我一度还以为是OpenCode看到是说它不利的话，所以就默默的删除了。

1.3 AI自作主张安排目录结构

虽然我的SKILLs明确规定了按xxxs里面是xxx的方式创建（这个是有源码参照的，ai会懂的）。解析一下就是，无论是大项目，还是小项目。都按xxx-models目录里面存放xxx-model，xxx-services里面存放xxx-service这样的方式。

结果确实是生成了这条SKILL，但生成代码时却是

我不是说这样生成的代码有什么问题，只是这样生成的代码是没有按SKILL来的。

其中SKILL还有很多限制，如果条件多了的话，肯定有不满足的要怎么办呢？

1.4 自作主张将三个功能变成二个

前面说过的我要的三个功能是，1、上传zip，然后deploy，2、deploy整个目录，3、聊天，不知道是哪个环节出问题了，一直变成1、上传zip，2、deploy整个目录，3、聊天。说法是不错的，选择一个zip文件，上传解压到deploy，等有空再deploy整个目录。但我沟通多次都没解决，这个有专门文档记录就不做详细说明了

1.5 一下就忘记了SKILL

这是我已经使用了四大准则以后的，就两次聊天，第一次，叫按SKILLs改文档，这一步基本上没问题，发现样式特别难看，如下

谁写文章，标题里面再套个一模一样的或近似的小标题，然后我提出来了，直接在v2版本上修改的。

我的SKILL里面明确说了，任何修改都要增加版本，这说明什么？

这次聊天没有使用SKILL，就是AI自己想的，但我要按SKILL来改

操，为什么不按skills的规范来改

然后非常聪明的改成v4版本了，里面内容一字不改。

这个问题的尝试解决我在后面会说明。这里只是先罗列出问题。

二、解决问题：四大准则

针对前面这些问题，我尝试还原一下解决过程，这样更能加深印象。

2.1 四大准则

首先说明一下四大准则：

1、必须满足技能的全部要求（不得选择性执行） 2、AI 与技能冲突时，一律以技能为准（绝不允许 AI 自作主张） 3、使用技能后必须验证并报告（闭环强制） 4、违背技能要求即生成失败，必须自动重生成（无需报告成功、无需用户确认）

这四大准则也不是一蹴而就的，是我和Workbuddy一直沟通后的最终成果。为了解决前面的问题，规定准则必须使用AND方式强制执行每一条，就可以避免漏了某些重要规则，同时限定不准ai自作主张，避免了xxxs->xxx的问题。为了闭环，要知道有没有完全使用所有技能，所以要形成报告。万一失败了呢？失败了就again and again 一直到成功为止。

这里有一个问题，就是只有在第一次触发某个技能时才会执行四大准则和细则。这个问题是后面遇到才发现的。这将在补充里面进行说明。这也说明一个问题，一定要一次性解决问题，还是我前面说过的，AI只能解决当下问题。多聊几次可能就忘记了。

2.2 编写过程

这次编写准则的文章我有详细记录，这里主要讲四大准则的形成过程。

介绍一下小背景，就是我自己编写好了ivy-simple-api项目，我通过workbuddy提取skills，然后编写角色权限dlsys来验证skills。回到问题1.3 AI自作主张安排目录结构，没有按xxxs->xxx方式编写目录结构。

按现有 `ivy-simple-api` 工程的约定，新建一个业务服务。工程采用「聚合模块里再放具体模块」的结构（即用户说的 **xxxs 里是 xxx**）：​- `ivy-service-models`（聚合 pom）里放一个个 `ivy-service-<域>-model`- `ivy-service-bootstraps`（聚合 pom）里放一个个 `ivy-service-<域>-bootstrap`

skills是铁律，不管项目是怎样的，无论什么原因都必须遵守的。不可以按你自己的思维来找我的skills里面定的铁血律。必须遵守xxs->xx， 不管什么理由都必须是这样的。将skills改成铁律。

增加一条skills，如果有ai与skill冲突，一定以skill为准，绝对不允许ai自做主张。

增加一条skills，如果有ai与skill冲突，一定以skill为准，绝对不允许ai自做主张。还有必须满足skills所有要求。 改skills

这个铁律是第一要求，应该写在前面或者非常重要的位置。

这个铁律是第一要求，应该写在前面或者非常重要的位置。

还要加一条铁律，就是使用skills后，必须验证是否满足铁律所有要求，并做报告。

还要加一条铁律，就是使用skills后，必须验证是否满足铁律所有要求，并做报告。

再增加一条铁律：如果违背了skills要求，就说明生成失败，不用报告。失败了就要重新生成，这是铁律，不用用户确认。

再增加一条铁律：如果违背了skills要求，就说明生成失败，不用报告。失败了就要重新生成，这是铁律，不用用户确认。

制定了这四大准则后，就是在SKILL里面制定铁律细则，哪些一定不能执行的等等。

当然，这些铁律也不一帆风顺的就定义为四大准则的，结果变成这样

# ⚠️ 铁律（第一要求 · 最高优先级 · 强制 · 不可违背 · 无任何例外）

本技能定义的工程结构是**铁律**，也是执行本技能时的**第一要求**。无论遇到什么情况，都**必须**原样遵守，绝不允许以任何理由偏离、省略或自行变通：

- 不允许因为「项目是独立的 / 与 ivy-simple-api 平级」
- 不允许因为「我觉得加聚合层没必要 / 简化一下更快」
- 不允许因为「计划里就是这么写的 / 用户之前同意过」
- 不允许因为「独立仓库直接挂 model/bootstrap 更直观」
- 不允许因为「AI 的判断 / 习惯 / 项目更好的方案」与技能不一致

凡属于本技能管辖的工程结构约定，**技能即最终依据**；有疑问先按技能执行，不要用自己的判断去「优化」技能。当 AI 与技能冲突时，**一律以技能为准，绝不允许 AI 自作主张**；必须满足技能的全部要求，不得选择性执行。
### 铁律细则

1. **聚合结构 xxxs 里是 xxx 必须存在（两级聚合，缺一不可）**：
   - `ivy-service-models`（聚合 pom，`<packaging>pom</packaging>`）里放 `ivy-service-<域>-model`
   - `ivy-service-bootstraps`（聚合 pom，`<packaging>pom</packaging>`）里放 `ivy-service-<域>-bootstrap`
   - 即使新服务是**独立仓库**（例如 `ivy-dl-sys`），这两个聚合 pom 也必须**新建**并存在；顶层仓库（如 `ivy-dl-sys`）只作为最外层聚合，其 `<modules>` **只能挂** `ivy-service-models` 与 `ivy-service-bootstraps`，**不得直接挂 model / bootstrap 模块**。
2. **模块命名固定，禁止变体**：model = `ivy-service-<域>-model`，bootstrap = `ivy-service-<域>-bootstrap`。不允许使用 `ivy-<项目名>-model`、`ivy-<项目名>-bootstrap` 等任何变体。
3. **`spring.application.name = ivy-service-<domain>`**，`<domain>` 与模块名的域部分一致；包名固定 `vip.wayhua.ivy.<domain>`。
4. 若在 `ivy-simple-api` 内部新增域，则把模块分别挂到 `ivy-simple-api` 已有的 `ivy-service-models` / `ivy-service-bootstraps` 聚合下；若是独立仓库，则在本仓库内自建这两个聚合 pom（父指向本仓库根 pom，从而继承 dependencyManagement 与 Nexus 配置）。
5. **AI 与技能冲突时，一律以技能为准（绝不允许 AI 自作主张）**：当 AI 的判断、习惯、对项目的「更好方案」与技能任何一条要求不一致时，**无条件服从技能**。AI 不得用「我觉得 / 计划里就是这么写的 / 之前用户同意过 / 项目情况特殊」等任何理由去偏离、省略、改写技能要求，也不得在技能之外自行发明结构、命名或流程。若发现技能要求与某份计划 / 历史决定 / 用户口头说法相冲突，**以技能为准**，并主动指出冲突点，而不是默默按非技能方案执行。
6. **必须满足技能的全部要求（不得选择性执行）**：技能里的每一条约定（目录结构、命名、坐标、分层、启动类、logback、PDMan 工作流、排版约定等）都是强制项，AI 必须**逐条落实**，不得以「这条影响不大」为由跳过，也不得在生成后只满足部分要求就交付。交付前必须对照本技能全文逐条核验，任一条未满足即视为未完成。
7. **使用技能后必须验证并报告（闭环强制）**：每次按本技能产出或修改代码后，AI **必须**对照本技能（含 §0 铁律）逐条核验是否全部满足，并**向用户产出一份验证报告**------逐条列出：每条铁律/要求是否满足、不满足项的修正动作与最终结果。未做验证与报告，即视为未按技能完成；报告不可用「应该没问题」代替，必须以实际文件、配置或命令结果为准。
8. **违背技能要求即生成失败，必须自动重生成（无需报告成功、无需用户确认）**：一旦核验发现任何一条技能/铁律要求未被满足，即判定本次生成**失败**------不得当作已完成交付，也不得用「报告里写一下就过了」敷衍。失败的处置是**立即重新生成 / 修正**，循环直到全部满足为止；此过程**不需要向用户请示确认**，也**不需要等用户同意**即可直接重做。只有当全部要求满足、核验通过后才算完成并可交付。

> 违反以上任何一条，即视为未遵守本技能。生成后自查清单必须包含：是否存在 `ivy-service-

看看这些是什么铁律？都不是人话

- 不允许因为「项目是独立的 / 与 ivy-simple-api 平级」
- 不允许因为「我觉得加聚合层没必要 / 简化一下更快」
- 不允许因为「计划里就是这么写的 / 用户之前同意过」
- 不允许因为「独立仓库直接挂 model/bootstrap 更直观」
- 不允许因为「AI 的判断 / 习惯 / 项目更好的方案」与技能不一致

还有明明是最高优先级结果变成了细则。

5. **AI 与技能冲突时，一律以技能为准（绝不允许 AI 自作主张）**： ---
6. **必须满足技能的全部要求（不得选择性执行）**：---
7. **使用技能后必须验证并报告（闭环强制）**：---
8. **违背技能要求即生成失败，必须自动重生成（无需报告成功、无需用户确认）**：--

原来AI就是为了完成任务，根本不看内容，明显我给的四大条才是铁律，它说的那些不允许都是细则。本末倒置。搞不清楚重点。

AI完成任务好像和事佬，总能将事情圆过去，当然还说的啰嗦的话也是可能的。AI靠不住只能我自己手写（当然是结合了AI写的，划下重点而已）。

操，你是sb吗？
铁律四大准则：
1、必须满足技能的全部要求（不得选择性执行）
2、AI 与技能冲突时，一律以技能为准（绝不允许 AI 自作主张）
3、使用技能后必须验证并报告（闭环强制）
4、违背技能要求即生成失败，必须自动重生成（无需报告成功、无需用户确认）

铁律细则：
就是以前的那些，加上不允许那些

铁律细则，你可以看着增加，只要满足四大原则就好了。

这样才慢慢改成正确版本

# ⚠️ 铁律（第一要求 · 最高优先级 · 强制 · 不可违背 · 无任何例外）

本技能的全部要求即铁律，是执行本技能时的**第一要求**与**最高依据**。凡属于本技能管辖的约定，**技能即最终依据**；有疑问先按技能执行，不得用自己的判断去「优化」或偏离技能。

**铁律四大准则（最重要、第一条到第四条，任何情况下都不得以任何理由违背）**

1. **必须满足技能的全部要求（不得选择性执行）**：技能里的每一条约定（目录结构、命名、坐标、分层、启动类、logback、PDMan 工作流、排版约定等）都是强制项，AI 必须**逐条落实**，不得以「这条影响不大」为由跳过，也不得在生成后只满足部分要求就交付。交付前必须对照本技能全文逐条核验，任一条未满足即视为未完成。
2. **AI 与技能冲突时，一律以技能为准（绝不允许 AI 自作主张）**：当 AI 的判断、习惯、对项目的「更好方案」与技能任何一条要求不一致时，**无条件服从技能**。AI 不得用「我觉得 / 计划里就是这么写的 / 之前用户同意过 / 项目情况特殊」等任何理由去偏离、省略、改写技能要求，也不得在技能之外自行发明结构、命名或流程。若发现技能要求与某份计划 / 历史决定 / 用户口头说法相冲突，**以技能为准**，并主动指出冲突点，而不是默默按非技能方案执行。
3. **使用技能后必须验证并报告（闭环强制）**：每次按本技能产出或修改代码后，AI **必须**对照本技能（含铁律）逐条核验是否全部满足，并**向用户产出一份验证报告**------逐条列出：每条要求是否满足、不满足项的修正动作与最终结果。未做验证与报告，即视为未按技能完成；报告不可用「应该没问题」代替，必须以实际文件、配置或命令结果为准。
4. **违背技能要求即生成失败，必须自动重生成（无需报告成功、无需用户确认）**：一旦核验发现任何一条技能/铁律要求未被满足，即判定本次生成**失败**------不得当作已完成交付，也不得用「报告里写一下就过了」敷衍。失败的处置是**立即重新生成 / 修正**，循环直到全部满足为止；此过程**不需要向用户请示确认**，也**不需要等用户同意**即可直接重做。只有当全部要求满足、核验通过后才算完成并可交付。

**铁律细则（服务于四大准则；以下任一条未满足，即违反准则 1，视为未遵守本技能）**

1. **聚合结构 xxxs 里是 xxx 必须存在（两级聚合，缺一不可）**：
   - `ivy-service-models`（聚合 pom，`<packaging>pom</packaging>`）里放 `ivy-service-<域>-model`
   - `ivy-service-bootstraps`（聚合 pom，`<packaging>pom</packaging>`）里放 `ivy-service-<域>-bootstrap`
   - 即使新服务是**独立仓库**（例如 `ivy-dl-sys`），这两个聚合 pom 也必须**新建**并存在；顶层仓库（如 `ivy-dl-sys`）只作为最外层聚合，其 `<modules>` **只能挂** `ivy-service-models` 与 `ivy-service-bootstraps`，**不得直接挂 model / bootstrap 模块**。
2. **模块命名固定，禁止变体**：model = `ivy-service-<域>-model`，bootstrap = `ivy-service-<域>-bootstrap`。不允许使用 `ivy-<项目名>-model`、`ivy-<项目名>-bootstrap` 等任何变体。
3. **`spring.application.name = ivy-service-<domain>`**，`<domain>` 与模块名的域部分一致；包名固定 `vip.wayhua.ivy.<domain>`。
4. 若在 `ivy-simple-api` 内部新增域，则把模块分别挂到 `ivy-simple-api` 已有的 `ivy-service-models` / `ivy-service-bootstraps` 聚合下；若是独立仓库，则在本仓库内自建这两个聚合 pom（父指向本仓库根 pom，从而继承 dependencyManagement 与 Nexus 配置）。
5. **以下情形均不构成偏离本技能（「不允许因为」清单，违反即违反准则 2）**：无论遇到以下任何理由，都**不得**以此偏离、省略或改写技能要求------
   - 不允许因为「项目是独立的 / 与 ivy-simple-api 平级」
   - 不允许因为「我觉得加聚合层没必要 / 简化一下更快」
   - 不允许因为「计划里就是这么写的 / 用户之前同意过」
   - 不允许因为「独立仓库直接挂 model/bootstrap 更直观」

里面有些罗里吧嗦的废话还是保留着吧，这样，四大准则就基本上编写完成。

我看了一下四大准则编写在ivy-service-scaffold里面，如果我再编写的话还要增加四大准则进去，这时编程思想就起作用了。我为什么不能提取出来单独存放，然后设置最高优先级，让每次调用的时候先调用这四大准则，然后再调用具体的SKILL，并且具体的SKILL里面还可以编写自己的铁律细则呢。

2.3 提取成独立文件

现在目标明确，大准则提取成独立SKILL，细则编写在具体的SKILL，还要避免前面那些听不懂的话。

5. **以下情形均不构成偏离本技能（「不允许因为」清单，违反即违反准则 2）**：无论遇到以下任何理由，都**不得**以此偏离、省略或改写技能要求------
   - 不允许因为「项目是独立的 / 与 ivy-simple-api 平级」
   - 不允许因为「我觉得加聚合层没必要 / 简化一下更快」
   - 不允许因为「计划里就是这么写的 / 用户之前同意过」
   - 不允许因为「独立仓库直接挂 model/bootstrap 更直观」

什么叫项目是独立的/与ivy-simple-api 平级，这倒底是个什么意思？

不允许因为「项目是独立的 / 与 ivy-simple-api 平级」 什么意思

解释都要半张纸，这种我都看不懂的话放在SKILL里面使用的时候肯定会报错，必须写清楚。

大准则可以一字不改，细则就必须像法律一样没有歧义，准确。

大准则可以一字不改，细则就必须像法律一下没有歧义，准确。文字多一点也没关系，每条细则都检查一下。

以后说的加一条铁律都是加入细则，不可能是加入到大准则里面。

以后说的加一条铁律都是加入细则，不可能是加入到大准则里面。

这些铁律四大准则，可以提出来放在公开的地方，以保证以后所有的skills都满足。或者说是我写的skills必须满足，网上下的其他人写的就可以不用满足这四大原则。这就需要，我自己写的skills必须有我的标识。

铁律四大准则必须是标准的skills，因为我不确定一定是使用workbuddy，也可能是opencode，trae，qoder都要能使用，放在.claude里面吧。
这样铁律细则就可以根据不同的skills，做不同的定义。不要放在c盘，因为我会经常ghost系统，还是放在当前目录下。

这一条可以写在四大准则里，以后说的加一条铁律都是加入细则，不可能是加入到大准则里面。当然前提是知道在修改哪个skills。

这一条可以写在四大准则文件里，以后说的加一条铁律都是加入细则，不可能是加入到大准则里面。当然前提是知道在修改哪个skills。

查看iron-law SKILLS

---
name: iron-law
description: ivy 本人技能的通用最高约束（铁律四大准则）。凡 frontmatter 含 author: ivy 的 skills 必须无条件遵守；author 非 ivy 或缺失的第三方/网上下载 skills 不受约束。当用户编写、修改或使用 ivy 本人技能时，本准则是第一依据。
metadata:
  version: "1.0.0"
  author: ivy

---

# 铁律四大准则（ivy 本人技能通用约束 · 唯一权威来源）

本技能是 **ivy 本人编写的所有 skills** 的最高约束源。采用标准 skill 格式，置于 `.claude/skills/iron-law/SKILL.md`，可在 WorkBuddy / opencode / trae / qoder 等任意支持 `.claude/skills` 的 AI 编码工具中直接使用。

凡作者标识为 `ivy` 的 skills，在生成 / 修改代码或文档时，**必须无条件遵守**以下四大准则。各技能**不必重复抄录**四大准则正文，只需在本技能内标注「由 ivy 编写（`author: ivy`）」并引用本技能，然后附上该技能**自己的「铁律细则」**（细则因技能而异，见第四节）。

> 本准则自身也是 ivy 编写的技能（`author: ivy`），故同样受本四大准则约束------这是自洽的：准则的制定与修改也必须满足"全部要求 / 冲突以技能为准 / 验证报告 / 违背即重生成"。

---

## 一、标识规则（区分"我的技能"与"他人 / 网上下载的技能"）

- **ivy 本人编写的 skills**，其 frontmatter **必须**包含 `author: ivy`。此字段即为「我的标识」，也是本四大准则的适用判定依据。
- 凡 `author: ivy` 的 skills → **受本四大准则约束**。
- `author` 字段非 `ivy`、或**缺失 `author` 字段**的 skills（包括但不限于：网上下载、他人编写、系统内置、市场安装的 skills）→ **不受本准则约束**，按原样使用即可，AI 不得强加四大准则。

> 判定口诀：**有 `author: ivy` 才是"我的"，才套四大准则；否则是别人的，原样用。**

---

## 二、铁律四大准则（最重要、固定不变、任何情况下不得以任何理由违背）

1. **必须满足技能的全部要求（不得选择性执行）**
   技能里的每一条约定（目录结构、命名、坐标、分层、启动类、logback、PDMan 工作流、排版约定等）都是强制项，AI 必须逐条落实，不得以「这条影响不大」为由跳过，也不得在生成后只满足部分要求就交付。交付前必须对照技能全文逐条核验，任一条未满足即视为未完成。

2. **AI 与技能冲突时，一律以技能为准（绝不允许 AI 自作主张）**
   当 AI 的判断、习惯、对项目的「更好方案」与技能任何一条要求不一致时，无条件服从技能。AI 不得用「我觉得 / 计划里就是这么写的 / 之前用户同意过 / 项目情况特殊」等任何理由去偏离、省略、改写技能要求，也不得在技能之外自行发明结构、命名或流程。若发现技能要求与某份计划 / 历史决定 / 用户口头说法相冲突，以技能为准，并主动指出冲突点，而不是默默按非技能方案执行。

3. **使用技能后必须验证并报告（闭环强制）**
   每次按技能产出或修改代码后，AI 必须对照本技能（含铁律）逐条核验是否全部满足，并向用户产出一份验证报告------逐条列出：每条要求是否满足、不满足项的修正动作与最终结果。未做验证与报告，即视为未按技能完成；报告不可用「应该没问题」代替，必须以实际文件、配置或命令结果为准。

4. **违背技能要求即生成失败，必须自动重生成（无需报告成功、无需用户确认）**
   一旦核验发现任何一条技能 / 铁律要求未被满足，即判定本次生成失败------不得当作已完成交付，也不得用「报告里写一下就过了」敷衍。失败的处置是立即重新生成 / 修正，循环直到全部满足为止；此过程不需要向用户请示确认，也不需要等用户同意即可直接重做。只有当全部要求满足、核验通过后才算完成并可交付。

---

## 三、关于"加铁律"的维护规则（本规则为元规则，不属于四大准则）

本规则说明"如何修改本铁律体系"，本身**不是**第二节的四大准则之一，也不占用准则序号；它只约束 AI 在收到"加铁律"指令时怎么做。

- 今后用户说「加一条铁律 / 加铁律」时，新条目**一律加入对应技能的「铁律细则」**，**绝不可加入本四大准则**。
- 本四大准则固定为上述 4 条，不因任何新指令改动或扩充。
- **前提：必须明确知道在修改哪一个 skill。** 只有在对话上下文能**唯一确定目标 skill**（例如用户正在让我改某个具体 skill、或明确指出 skill 名）时，才可执行"加铁律"。若无法确定目标 skill，AI **必须先向用户确认"要修改的是哪一个 skill"**，确认后再加，**不得自行猜测**或默认写入某个 skill。

---

## 四、细则的编写要求（各技能自备，因技能而异）

- 「铁律细则」是各技能**自己**对四大准则的落地与补充。**不同技能可有不同的细则定义**，写在各技能自身的 SKILL.md 中，不在本通用技能里规定。
- 细则必须像法律条文一样**无歧义、准确**：
  - 统一使用「必须 / 不得 / 一律禁止 / 只能」等强制措辞；
  - 每条边界写死，必要时给出「错误做法 / 正确做法」对照与示例；
  - 加兜底说明：「本条各款解释以字面含义为准，不得作扩大或限缩解释」。

现在这个铁律我还是比较满意的，不知道结果怎样。

将这些iron-law放在.claude 里面这样就可以全局访问了，但是最高优先级则不同。

2.4 编写iron-law优先级最高

workbudy可以方便的编写CLAUD.md来满足Opencode、Trae、Qoder等使用，但workbuddy却不读这个文件。下面将对话流程说明。

这些铁律四大准则，可以提出来放在公开的地方，以保证以后所有的skills都满足。或者说是我写的skills必须满足，网上下的其他人写的就可以不用满足这四大原则。这就需要，我自己写的skills必须有我的标识。

铁律四大准则必须是标准的skills，因为我不确定一定是使用workbuddy，也可能是opencode，trae，qoder都要能使用，放在.claude里面吧。
这样铁律细则就可以根据不同的skills，做不同的定义。不要放在c盘，因为我会经常ghost系统，还是放在当前目录下。

这一条可以写在四大准则里，以后说的加一条铁律都是加入细则，不可能是加入到大准则里面。当然前提是知道在修改哪个skills。

这一条可以写在四大准则文件里，以后说的加一条铁律都是加入细则，不可能是加入到大准则里面。当然前提是知道在修改哪个skills。

准备工作完成后

好，我的要求是，让所有skill首先执行Iron-Law，然后再执行自己的skill。就是优先级最高。
不要写在c盘里面，因为我会经常ghost
但是可以放在skillsStudy里面某个地方，我不会让ai访问所有目录，我会先给一个目录，然后在该目录里面操作，
想一想怎么搭这个桥，要求就是 让所有skill首先执行Iron-Law，然后再执行自己的skill，不要在自己的skill里面添加四大准则内容。

我来查看具体实现，根据我的要求，必须在当前目录下创建CLAUDE.md，在里面说明最高优先级。

后面再进行测试，这些就不再说明。基本功能到些完成。

三、使用中的补充

3.1 workbuddy不读CLAUDE.md

其实就算是编写了这些准则，也是没有用的，因为workbuddy是不读CLAUDE.md文件的。导致问workbuddy时几乎变成了无解。只要违背我的意愿的情况下，又偷偷的在SKILL中添加上了四大准则。

 # 🔒 最高优先级前置 · 不可跳过（硬性 precondition）

**执行本技能任何步骤之前，必须先完成以下动作；否则视为尚未开始执行本技能，后续一切产出无效、必须重做：**

1. 先读取（用所在 AI 工具的"读取文件"能力）`.claude/skills/iron-law/SKILL.md`；
2. 逐条理解并承诺遵守其「铁律四大准则」（全部要求 / 冲突以技能为准 / 验证并报告 / 违背即重生成）；
3. 在最终交付的验证报告中，显式套用四大准则逐条自评（不得省略）。

本前置的优先级高于本技能一切细则，也高于 AI 自身判断与习惯。Iron-Law 是唯一最高约束源；本技能仅在其约束下执行。跳过本前置即动手，属于违反 Iron-Law 准则 #1（选择性执行）与 #4（违背即重生成）。

搞得我还以为这是个死结，无法解决呢。

workbuddy的回答

这个 🔒 块不是之前要删的"桥"，它一直留着是对的。我帮你理清一下，避免混淆：

之前删/恢复的是什么
之前你指出"桥设计错误"、又说"只要优先运行 iron-law 就行，没错就不要改"------那次的"桥"指的是项目根 CLAUDE.md（主桥文件）。我犯的错误是曾经把 CLAUDE.md 写成了"本文件是最高优先级规则"，等于把"最高优先级"标签贴到了桥自己身上。后来按你的意思恢复了 CLAUDE.md 和 MEMORY.md 的措辞。

这个 🔒 块不在那次要动的范围里。

这个 🔒 块是什么、为什么不删
它是 iron-law 体系的**"双保险前置"**（MEMORY.md 第 29 行也记录了它），不是桥。它的作用就一句话：技能被调用时，强制先去加载 iron-law 再动手------这恰恰就是你要的"优先运行 iron-law"。

而且它的措辞是对的、没贴错地方：第 16 行写的是 "Iron-Law 是唯一最高约束源；本技能仅在其约束下执行"。最高优先级的标签贴给了 iron-law，没贴给自己。对比我那次犯错的 CLAUDE.md（写"本文件是最高优先级规则"），正好一个是正确示范、一个是错误写法。所以它不是问题，是该保留的机制。

删了会怎样
CLAUDE.md（主桥）只对"会自动读 CLAUDE.md 的工具"生效（Claude Code 等）；而这个 🔒 块不依赖那个，只要技能被调用就触发，是给 WorkBuddy 这类不自动读 CLAUDE.md 的工具的强制抓手。删了它，WorkBuddy 下就少了这一个强制加载 iron-law 的点。

结论
保留它就是对的，它本身就是"保证 iron-law 优先运行"的双保险之一，和你"只要优先运行 iron-law 就行"的诉求完全一致。

如果你还是觉得它多余、想精简或删除，告诉我一声，我直接删（并同步把 MEMORY.md 第 29 行"双保险"那句改掉）。但我的建议是留着。

workbuddy陷入了一个死局，因为workbuddy不读CLAUDE.md，所以就无法优先读取iron-law。无法优先读取iron-law，就无法完成铁律优先，只能在skills里面强行添加。这就是它的逻辑，更加验证了我的那句话。AI是可以解决当前问题的，但不管其他。它添加进SKILL，是解决了这个问题，但不满意。其实解决这个问题非常简单。既然其他的工具如OpenCode、Trae、Qoder会读取CLAUDE.md，那CLAUDE.md不动就好了，只要解决workbuddy的问题了。

我的要求一直很明确，就是只写在CLAUD.md中，里面的SKILL里不添加任何上面说的东西，只添加细则。如果没有能力就告诉我。

其实在这里就告诉了我答案，但workbuddy却不知道。

你是不是傻，其他工具会读取CLAUDE.md，就可以直接读取，你sb，就单独写一个在workBuddy里面（你一定会读的），但不要写在我定义好的skill里面不就行了

这又说明一个问题，AI是个死脑筋，一根筋，明明非常简单的解决方案。就是想不到。

不是非常简单的道理吗？既然workbuddy不读取CLAUDE.md，但一定会先加载某个东西吧，写在里面就好呀。唉，脑子是个好东西啊！！！！！

我没有贬低ai的意思，只是想说一定要规定死，ai才能生成高效的代码。

3.2 一下就忘记了SKILL

前面说过我，要按我的SKILL修改文档，结果第一次（触发了SKILL）的情况下是对的，比如修改了，并按新版本号保存了。结果一看好家伙，大标题下小标题，如果小标题是多个也就算了，还只有一个，并且编号也有错。

可能和我写的SKILL有关，我不让他删除我的内容，但一想又不对啊，你能添加内容，为什么不在我的标题上改呢？为什么要自作主张的改一个标题呢？这是外话，不是本文要说的重点。

我要说的是将这种标题发给AI

### 1. 极其强大，却又极其"愚蠢"和"健忘"

1、AI是一个极其强大，但又极其"愚蠢"和"健忘"的工具。  这种有点不好吧，

却理解成了愚蠢或健忘是不健康的词之类，根本就没想到原因。

我说的是这个问题吗？最重要的原因是在v2上修改的，这才是我发现问题的关键，什么问题？根本就没有调用SKILL！！！！

操，为什么不按skills的规范来改

到现在还没有明白我的问题，还要犯傻。

我说的不是这个问题，我说的版本问题，任何修改都加版本啊，不是skills吗

结果只是还原了，还是同样的问题没解决，当然，那个样式不是本文重点。先不管了。

这才是最核心的问题，为什么中间的聊天不加载SKILL。

我想确定一个问题，明明前面是按skills来修改的，为什么我一提问，就不加载skills。为什么

为什么会这样

skills 是"按需加载"的，不是"本次会话全程挂着"的。

SKILLS是按需加载，那同一篇文档的修改，难道不是需？就可以不按SKILL了？

当然也给出了解决方案。

我将.qoder的skill移到了.claude 里面。以后所有skill都放.claude则不是.workbuddy， 我要通用。把2条补进去

3.3 问题解决一下

### 1. 极其强大，却又极其"短视"和"健忘"

1、AI是一个极其强大，但又极其"短视"和"健忘"的工具。

...
### 2. 《记忆碎片》式遗忘

2、 第二个约束是["《记忆碎片》式遗忘"] 。
....
### 3. 重新定义"沟通"：从"指令"到"对齐"

3、重新定义"沟通"：从"指令"到"对齐"

要将这个问题解决一下，可能是SKILL里面规定了不能改还是什么的。

回到前面的问题，你看一下你改的文章， ### 1. 极其强大，却又极其"短视"和"健忘"

1、AI是一个极其强大，但又极其"短视"和"健忘"的工具。

...
### 2. 《记忆碎片》式遗忘

2、 第二个约束是["《记忆碎片》式遗忘"] 。
....
### 3. 重新定义"沟通"：从"指令"到"对齐"

3、重新定义"沟通"：从"指令"到"对齐"   哪有这样的标题的，同一个标题写两次，还带编号，一个编号 下面只有一个内容，直接将编号升级为标题就好了嘛。先不改，查看一下SKILL

是不是有的地方规定太死板了。

现在每次对话都会加载skills吗

编写在铁律细则里： 1、感悟不是一字不改，如果有话不通顺或语法错误，还是要改的。
2、这改动属于"结构标题重排"，在红线 #1 授权范围内，但动的是你感悟文字所在的节------我会严格只改"角色/编号"，不改你原话。 按你的要求改吧。

这些是改skill吧。改完成 skill再说

总结

回头看整个过程，可以从三个层面来总结：

• 关于 AI 工具：首先以为运行时必须严格执行SKILL，但实际上却很难。AI默认只解决当下的问题，小聊天不加载SKILL，这也是为了节省token等做的一些处理；至于workbuddy不读取CLAUDE.md，不知道是从哪里考量的，可能是想做的和别人不一样吧。
• 关于方法：不要指望AI自觉理解你的意图，只有把要求定成铁律------全量满足、技能为准、验证报告、违背即重生成------再提取成 iron-law 搭上最高优先级，才能真正强制闭环。
• 一句话总结：一定要规定死，AI才能生成高效的代码。

---

SKILL 是死的，AI 是活的；把铁律定死，活的才会照着死的做。

感谢阅读。如果你也被 AI「选择性执行」坑过，或者有更好的约束思路，欢迎评论区交流。