夜雨聆风
有一天我发现竞品分析工作台的定时任务，跑出来的结果跟CLAUDE.md里写的规则对不上，查了一圈，问题出在SKILL.md 定时任务的指令文件。
定时任务跑的时候读的是SKILL.md，CLAUDE.md里也有一份相同的规则，两份内容高度相似，但是独立的复制品，不是引用。
然后有一天我改了CLAUDE.md里的规则，忘了同步到SKILL.md。
就这么一个小疏忽，定时任务按旧规则跑了一周。
不是改一个文件的问题
发现之后我的第一反应是，把两边同步一下不就完了？
但Claude问了我一个问题：为什么同一个规则要存在两个地方？
这个问题比修bug重要得多，它不是在问"怎么修"，而是在问"为什么会发生"。一对上这个问题，后面的事就通了，不是这次忘同步了，而是这个结构本身决定了迟早会忘同步。
"规则源不唯一"，一旦同一件事有两份独立的指令文本，脱节不是概率问题，是时间问题。
解法不是更勤快地同步，是消灭第二个副本。我把SKILL.md改成了三行：读CLAUDE.md → 按竞品监测章节执行 → 因为是无头模式，跑完之后通知用户结果。
SKILL.md从规则容器变成了入口指针，它不承载业务逻辑，只做两件事：告诉AI去哪找规则、在什么模式下执行。
这个改动很小，但触发了一系列连锁反应。
连锁反应一：AI自作主张加了一行
改完SKILL.md之后我复查，发现Claude在第一版里多写了一句"先读INDEX.md"。
跟它说只读CLAUDE.md，它加了一句读INDEX.md。平白无故多一行，好心办坏事。
我追问：为什么加这句？
它说：因为以往的习惯，觉得多读一个索引更周全。
我说：CLAUDE.md里第一条就是"每次会话先读INDEX.md"，你已经在SKILL.md里写了读CLAUDE.md，为什么还要再写一遍读INDEX.md？
它承认：冗余，没有想清楚指令层级。
这件事让我意识到一个模式，AI倾向于做加法，你觉得它可能遗漏了什么，它会帮你补上，但补的东西往往是冗余的，甚至跟已有指令冲突。
修正的方法不是让它"别自作主张"，而是把指令写得更精确。不是"你按这个流程做"，而是"你只做这三件事，不要多做任何事"。精确的指令不给AI留发挥空间。
连锁反应二：随手写的小写，暴露了一个习惯问题
同一天的另一次对话里，我在新建AI信息聚合Project的时候，让Claude生成了几个文件。打开一看：sources.md、source-log.md——全小写。
而目录里已有的核心配置文件全是全大写：CLAUDE.md、INDEX.md、TEMPLATE.md。
我问它：为什么小写？
它说：随手写的，没想清楚。
我问它：那CLAUDE.md为什么大写？
它说：因为那是系统级文件，大家都这么写。
我问它：那sources.md是不是也是Project的核心文件？它跟TEMPLATE.md有什么本质区别？
它沉默了一下，承认没有区别。
这让我意识到，命名不一致不是粗心，是分类逻辑没到位。CLAUDE.md和TEMPLATE.md被自动归类为"重要的大写文件"，sources.md被自动归类为"普通的小写文件"。但这个分类标准是什么？文件重要性？使用频率？创建顺序？没有标准，就是纯凭直觉。
直觉遇到边缘情况就会不一致，今天是小写，明天换个文件可能是大驼峰，后天可能是下划线。目录看起来就是一个杂货铺。
修法不是把所有文件改成大写，修法是先想清楚分类标准：核心配置文件（管规则管索引的全大写），日常内容文件（管内容的全小写或日期前缀）。然后把这个标准写下来，变成可检查的规则。
连锁反应三：从修一个bug到修一类bug
SKILL.md的指令双写问题修完之后，我回头扫了一眼其他Project。果然，AI信息聚合的定时任务SKILL.md有同样的问题。
但这次我没有只改它，我做了一件事：写了一个定时任务的SKILL.md标准模板。四段结构：导语（声明这是入口指针）、入口（指向CLAUDE.md的具体章节）、执行模式（headless说明）、通知规则（跑完怎么通知用户）。
模板存成了实体文件，放在Scheduled目录下。以后每创建一个新定时任务，不是凭记忆写，是对着模板抄。
这个动作的本质是，不是修了一个bug，而是修了一类bug的发生条件。
提问的策略
回顾整个过程，有一个模式反复出现：我问的不是"哪里错了"，而是"为什么会发生"。
"为什么会发生"会指向系统设计，"哪里错了"只指向修bug。
当AI多写了一行冗余指令，我问的不是"你多写了什么"，而是"你为什么要加这一行"。答案是"因为我觉得多读一个索引更周全"，这就暴露了AI的默认行为模式：做加法、补全、不确定就多来一点。知道了这个模式，以后写指令我就知道要反向操作，写得越精确越好，不给留加法空间。
当AI用了小写命名，我问的不是"你写错了"，而是"你为什么默认用小写、CLAUDE.md默认用大写"，答案是"没有标准，纯凭直觉"，这就暴露了分类逻辑的缺失。知道了这个，以后建新文件我就不靠直觉了，而是先看同类文件是什么格式。
从修bug到修一类bug，关键是追问多一步。
最后
这个系列写了四篇。从"为什么开始"，到"结构怎么长出来"，到"长歪了怎么修"，到这最后一篇"AI犯的错和怎么问回来"。
如果你只带走一个东西，我觉得是这个：跟AI协作，你的角色不是指令发出者，是指令设计师。好的指令不是写得多详细，而是写得恰好够，不多一行、不少一行、每个词都有被追问过的理由。
日常协作中的那些小错，SKILL.md多一行、文件名小写了、模板缺了一个字段，它们不是AI的问题，是你不追问的话，永远发现不了的系统设计问题。
而追问本身，就是协作中最值得锻炼的能力。
