SEI：把 Skill 高风险规则漂移变成可回归问题

TL;DR

Skill 系统在第二十次修改时暴露出来的主损耗，往往来自高风险规则悄悄改义。
SEI 解决的是这一类漂移：同步更新规则定义、校验逻辑和失败样例，让每次修改都留下可回放证据。
第一轮落地不用铺满治理框架，先盯住高风险术语、完成态字段和 failure-first 回归就够了。

一次看起来普通的文案清理，删掉了某个 skill 里的 trigger boundary。review 没有人报警，因为改动看上去只是文字整理。第二天路由器把一批离线任务送进了需要联网的技能。另一个 skill 里的 fallback 同时被写成“允许跳过关键步骤”，完成态也从 action、memory、archive 三向交接退化成“有产物就算完成”。这是一种会连锁扩散的规则漂移。

SEI 只解决这一类问题：高风险规则在迭代中悄悄改义，而系统没有留下足够早的告警和回放证据。这里说的 SEI，是一套把规则定义、校验逻辑和失败回归绑在一起的演进基础设施。它不负责替代所有设计判断，只负责让那些会直接改变执行结果的规则不再靠作者记忆维持一致。

一旦把问题限定在这里，系统该做什么就清楚了。先找出最容易分叉的术语和完成态字段，再把对应定义、校验和失败样例绑成一条闭环。规则能被重写、被重构、被交接，仍然保持同一判定，Skill 演进才真正进入可回归状态。

先收敛高风险术语和完成态字段

真正需要先收敛的，是那些一旦改义就会改变执行结果的术语和字段。fallback 算一类，trigger boundary 算一类，完成态字段也算一类。它们的问题不在抽象，而在于两个 skill 只要把同名字段写成不同意思，系统就会出现协议分叉。

一个简单的判据是“同名规则是否同判定”。A skill 把 fallback 定义成“可离线执行”，B skill 却把它写成“可以跳过关键步骤”，两边都叫 fallback，执行结果却完全不同。再比如一次“文案清理”删掉 trigger boundary，作者可能觉得删的是说明文字，自动路由器拿到的却是一个缺了边界条件的技能入口。

这也是 SEI 的取舍起点。第一轮工作优先修复高风险语义分叉，低风险的文风、排版、表达习惯先停留在建议层。因为只有前者会直接改变执行结果，后者更多影响阅读体验。

规则定义、校验逻辑和失败回归必须一起更新

真正的问题不在“规则有没有写下来”，而在“规则改了以后，系统会不会用同一个口径发现它”。如果 trigger boundary 只写在文档里，重写时最先丢的就是它。如果只有 validator 没有失败样例，下一次重构就可能把旧 bug 带回来。SEI 要守住的，正是这条从定义到校验再到回归的最短链路。

一条新规则至少要落三处：文档段落、校验分支、失败样例。比如把 archive destination evidence 从建议级提升到错误级门禁，文档需要更新 references/bagakit-profile-guide.md，校验器需要更新 scripts/bagakit_skill_maker.py，测试需要更新 scripts_dev/test.sh。三处缺一，规则就只完成了部分迁移。

下面这张图描述的是 SEI 的最小闭环。它只保留三件事：定义规则、执行校验、记录失败回归。闭环一旦少掉其中一环，高风险术语就会重新退回“作者记得就算一致”的状态。

flowchart LR
    A["定义高风险规则"] --> B["更新校验逻辑"]
    B --> C["补失败回归样例"]
    C --> D["用技能自举验证"]
    D --> E["进入周度审计"]
    E --> F{"判定一致?"}
    F -- "是" --> G["继续沿用"]
    F -- "否" --> A

自举验证比设计说明更能证明规则落地

SEI 最有说服力的证据，是一条系统用自己跑通的验证链。系统能要求别人遵守某条规则，前提是它已经能要求自己遵守这条规则。

把固定 footer 字段、handoff destination、archive evidence 从“建议级”提升到“错误级门禁”，就是一个典型的自举动作。它直接回答三个问题：规则有没有被定义，校验有没有真的执行，失败时能不能留下明确证据。正文里不需要堆满完整 runbook，看一段最小回放就够了：

sh scripts/bagakit_skill_maker.sh validate --skill-dir .
bash scripts_dev/test.sh
git show --stat --oneline --no-patch HEAD
git rev-parse --short HEAD

如果这条最小回放都给不出来，后面的治理语言通常都不成立。release note 只写“规则已升级”，没有日志路径和关键哈希，审计就会退回主观判断。测试更新了，却没有 failure-first 样例，下一轮重构之后也没人能说明旧 bug 是否真的被挡住。

最小门禁和周度审计足以压住第一轮熵增

SEI 的第一轮目标是让漂移越来越难发生。对高风险规则来说，最小门禁往往已经够用：Core/Profile 触发条件可机检，固定 footer 结构可解析且字段完整，action、memory、archive 缺失关键字段即失败，每条高风险规则都有 failure-first 用例，每个变更请求都附 gate 结果与回归记录。

周度审计的价值，在于把一次次局部失败翻译成一份可比较的长期信号。比如 python3 scripts/audit_sei.py --window 14d --output reports/sei-weekly.json 可以生成最近两周的规则漂移视图，再用 rg -n "drift|mismatch|recovery" reports/sei-weekly.json 抽取异常。第一次试运行时，drift_rate > 0.15 和 recovery_time_p95 > 2d 这类数字更像起步阈值，不应被包装成永远正确的制度常量。它们的作用，是让团队先把“什么时候算分叉，什么时候算修得太慢”说清。

为了让跨周对比保持同一口径，还需要一张轻量审计卡。字段越稳定，周报越能用来做趋势判断，也越容易摆脱每周重新解释口径的成本。

policy_id=DRIFT-001
failure_case_id=F-20260221-03
recovery_owner=platform-qa
recovery_eta=2026-02-28
evidence_path=reports/sei-weekly.json

这类审计卡故意保持克制。它不承担解释世界的任务，只负责把 policy_id、failure_case_id、recovery_owner、recovery_eta、evidence_path 固定下来，让后续比较和追责不再依赖口头上下文。

SEI 的第一轮推进其实很短：先统一高风险术语和完成态字段，再把对应规则补进 validator 与 failure-first 测试，最后用自举验证和周度审计把证据链闭上。下一次遇到会直接改变执行结果的规则调整时，可以先按这三步试运行。如果同名字段再次出现不同判定，或者修复时间持续高于 2 天，就说明定义和回归还没真正绑在一起。优化是否生效，看两个结果就够了：高风险术语分叉数能否回到 0，修复链是否能稳定压回 2 天内。