团队的 AI 规则，别再各改各的

# 用途 把团队的 AI 规则（技能描述 / 项目说明 / 钩子 / 接入配置）当成制度来维护： - 有版本：每次改动都有提交与出处 - 有评审：至少一人复核，不靠顺手机改 - 有生效时刻：合并那一天生效，并逐台核对 # 一、一次改动的标准动作（按序，⛔ 不跳步） 1. 定位：从「最近一次被绕开」的地方找起，搜到对应条目，确认当前版本 2. 判定：写一句「改完之后，什么会被允许、什么会被拦住」 3. 分支：只改这一件；分支名写清改什么 4. 自测：这条规则在你本机确实生效了，再提交 5. 合并请求：写清三句 —— 改前 / 改后 / 为什么（为什么必须能追到一次具体的翻车） 6. 评审：复核人只答两问 —— 会不会误拦？谁依赖旧行为？ 7. 合并：发一条通知（改了什么 / 影响谁 / 要做什么） 8. 核对：每位成员拉取后逐台确认「本机实际生效」，不只是「拉下来了」 # 二、规则条目的写法（可判定优先） 每条写成：`场景 / 该停还是该继续 / 判据 / 例外` - ✅ 好条目：「在无人值守的作业里，任何需要权限的动作 → 停下并在日志里留一行 DENIED；例外：只读类动作」 - ⛔ 坏条目：「注意权限安全」「尽量小心」—— 不可判定 = 等于没有 # 三、收尾核对（每次合并后产出一行） 合并了什么：____ 影响谁：____ 需要什么动作：____ 本机生效核对结果（抽 N 台）：一致 __ / 不一致 __；不一致的条目：____ # 四、纪律 - ⛔ 规则库不设「直接往主干推」的后门；管理员也走合并请求。 - ⛔ 一次合并只改一件事；不顺手格式化。 - ⛔ 追不到出处的改动不予合并 —— 规则库不是文风练习场。 - ⛔ 别把「拉下来了」当「生效了」；生效要逐台核。