AI摘要
现实的底层逻辑是概率分布，AI agent 也不例外
翻车现场
睡前我让 Agent 自己升级系统。
"update yourself"
"好的，正在升级..."
早上醒来，发现一晚上的定时任务全没跑。
日志里一堆：
Error: Cannot find module './dist/gateway.js'
网关重启中...
Error: Cannot find module './dist/gateway.js'
网关重启中...
循环了一夜。升级失败 → 崩溃 → 重启 → 又崩溃。
我的 AGENTS.md 里明明写着：
升级规则
- 升级前检查 git status
- 返回 skipped 要处理
- 不要只 pull 不编译
它全部忽略了。一晚上白等。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
之前我写过一篇《4层防御体系》，核心观点是：
Markdown is Suggestion，Code is Law
pre-commit hook 是法律——你 commit 不了就是 commit 不了。
AGENTS.md 是建议——Agent 可能听，可能不听。
今天这篇是那个观点的延续：当你没法用代码的时候，怎么让 Markdown 尽量接近法律？
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
命中率层级
命中率层级
之前的经验告诉我， Markdown的条例是不稳定的
但我发现一个例外：
Markdown + 结构化失败经验 → 命中率可达 90%+
不是所有 Markdown 都只有 40%。关键在于怎么写。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
案例 1：升级失败 → 自我修复
回到开头那个翻车。
Agent 升级时返回了：
markdown
{"status": "skipped", "reason": "dirty"}
它没看这个返回值。直接跑 git pull && restart。
TypeScript 项目，只拉源码不编译 = 崩溃。
我的修复：把抽象规则改成具体流程：
自升级检查清单
- 升级返回 "skipped"？
→ 运行 git status --porcelain
→ 清理或 stash 脏文件
→ 重试升级 - 永远不要只 git pull 就重启
三天后，同样的场景：
我：update yourself
返回值：{"status": "skipped", "reason": "dirty"}
这次 Agent 的反应不一样了： - 分钟完成。我没碰键盘。
$ git status --porcelain
?? skills/nano-banana-pro/*.png
$ mv *.png ~/drafts/
$ gateway.update.run
→ status: "ok"
差别在哪？
之前："升级要小心" → 抽象指令 → Agent 会忘
之后：if skipped → git status → clean → retry → 可执行流程 → Agent 能机械执行
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
案例 2：规则文件膨胀综合症
我的 AGENTS.md 曾经有 426 行。
配置安全、密钥管理、代码规范、进程管理、发帖规则、交易纪律...全写在一个文件里。
结果？Agent 开始选择性遗忘。
我做了个测试：
前 50 行规则 → 遵守率 ~70%
50-200 行 → 遵守率 ~50%
200 行之后 → 遵守率 <30%
为什么？
Context 不是无限的。128K 看起来很大，但塞太多，每条规则分到的"注意力"就被稀释了。
这在学术上叫 Attention Budget——注意力是有预算的。
我的修复：426 行 → 96 行。
怎么做到的？把详细规则移到 Skill 文件里，AGENTS.md 只保留指针：
发帖规则
写 X 回复前，先读 x-draft skill。
Agent 需要的时候才加载完整规则，不是一次性全塞进 context。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
案例 3：检查流程被静默跳过
我建了一个 x-content-checklist skill，要求每次写回复前跑 24 条去 AI 味规则。
第一次测试：成功。5 条 draft 都带着 Humanizer: ✅ 已检查。
两小时后：失败。5 条 draft 全部跳过检查，直接出内容。
为什么？
长对话会被压缩。OpenClaw 为了省 token，会把长对话总结成短摘要。
压缩 = 总结 = 丢细节。
压缩后的摘要里只剩下 "skill created"，没有 "must use before draft"。
规则存在，但没到 Agent 眼前。
我的修复：不依赖 context 记忆，依赖输出格式强制。
输出格式（强制）
每条 draft 必须包含这一行：
Humanizer: ✅ 已检查
没有这一行 → 系统不显示发送按钮
Before（被跳过时）：
Draft: 这个工具很好用，推荐大家试试
[✅ 发送] [❌ 取消] ← 直接出按钮，没跑检查
After（强制格式后）：
Draft: 笑死 这玩意儿我折腾俩月 现在离不开了
Humanizer: ✅ 已检查
[✅ 发送] [ 取消] ← 必须有 Humanizer 行才出按钮
规则写在文件里 → 可能被压缩丢失。
规则写在输出格式里 → 不输出就没法继续。
这就是把建议伪装成Code Law。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
命中率公式
三个案例的共同点：
命中率 = 具体程度 × 是否来自真实失败
"配置要小心" → 具体程度低 + 无失败经验 = ~30% 命中率
"配置前备份" → 具体程度中 + 无失败经验 = ~50% 命中率
if skipped → git status → clean → retry → 具体程度高 + 真实失败 = ~90% 命中率
Agent 不需要通用智能。它需要的是你喂给它的结构化失败经验。
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
Checklist
下次写规则之前，问自己：
markdown
- [ ] 够具体吗？ 是
if-then-else流程，还是抽象指令？ - [ ] 来自真实失败吗？ 还是你"觉得应该这样"？
- [ ] 文件够短吗？ 超过 200 行就该拆了
- [ ] 有输出格式强制吗？ 规则不只写在文件里，还写在输出模板里
- [ ] 会被压缩丢掉吗？ 核心规则要在每次会话都加载的文件里
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
总结
回到那句话：Markdown 是建议，代码是法律。
但当你没法写代码的时候：
把建议写成 if-then-else 流程 → 接近法律
让建议来自真实翻车 → 接近法律
把建议写进输出格式 → 接近法律
把文件控制在 200 行以内 → 建议不被稀释
Agent 不需要变聪明。它需要的是你把建议伪装成法律的技巧。
