文章目录第一版翻车删是第一步第二版先迁 → 再删 → 后修附带坑自检清单要跟着扩和主流说法对齐两个教训你可以直接拿去用的提示语常见问题用Cursor/Claude Code指挥 AI仓库里有一份每轮对话都加载的全局规则长到861 行。里面塞满需求编译、契约生成、文档同步细则——跟下游脚本大量重复。Token 烧得快模型也更容易忽略中间段落。AI 说瘦身很简单直接删重复段落就行。你一动手——脚本里到处「详见 §4.2」「参考 §7.1」对应章节没了全变死链。下次执行报错或更糟静默跳过。AI 说规则瘦身直接删就行满仓库「详见 §x」却全变死链。第一版翻车删是第一步听起来合理重复内容删掉规则变短上下文预算省下来。真正开刀才摸到刺最可怕的不是内容多是交叉引用。触发器、工作协议、执行脚本互相指章节锚点。你先删中间状态里到处指向虚空——仓库当场不自洽。用户点破删不是第一步。先把独有知识迁走再删最后修引用。第二版先迁 → 再删 → 后修步做什么结果先迁「只有触发器写了、别处没有」的独有知识搬到可读规则层路径匹配矩阵、增量更新原则、按文档类型的变更记录——落户到唯一正文再删已在下游脚本里的细则整段移除换成「摘要 链接」861 → 约 180–250 行触发器只负责何时触发、去哪看正文后修全局搜旧锚点协议 / 脚本引用重定向rg验旧章节标号从仓库消失每一步做完仓库都自洽——中途停手也不留死链。附带坑自检清单要跟着扩文档同步自检原来 4 项后来加了「契约一致性」清单没扩到 5 项——新维度裸奔。规则演进时验证清单必须跟规则正文同步。和主流说法对齐Context 优化全局规则越长每轮都塞进上下文又贵又被稀释——瘦身是预算问题不只是洁癖。Harness触发器该是薄门禁何时触发、去哪看细则在可读规则与脚本里顺序错误会把门禁拆成死链。系列 #5 讲规则元治理#41 讲改规则假评审本篇补长规则怎么安全拆薄。两个教训① 「迁」必须写在「删」前面——拆薄计划里顺序写反中途停手就满仓库死链。② 触发器只负责引路——不该代行整条流水线细则。你可以直接拿去用的提示语 点击展开提示语模板可直接复制使用这是一个每轮对话都会加载的全局规则文件已长到 {N} 行里面塞了 {需求编译 / 契约生成 / 文档同步} 等多条流水线的细则大量内容和下游可执行脚本重复{粘贴文件或给路径}。 我想瘦身但最怕删出死链。请按「先迁后删」帮我 1. 先识别哪些是真·规则哪些只是重复了下游脚本 / 其他文档已有的细节。 2. 列死链风险下游脚本里「详见 §x」「参考 §y」这类交叉引用删哪节会让哪些引用变死链。 3. 迁移方案重复内容挪到哪个唯一正文让每步做完仓库都自洽、中途被打断也不留死链。 4. 最后才给删除清单每条标前置「等 X 迁移完成后再删」。 不要一步给我删光的新版本——我要的是先迁后删、可中断的路径。AI 给的是初稿——哪节是真规则、哪条引用会变死链得你对着仓库核。删不删、什么时候删还是你拍板。常见问题压到多少行才算够没有魔法数字。要点是触发器只保留「何时触发 去哪看正文」。能不能让 AI 一步给出删光版不要。要可中断路径保证中间状态自洽。自检清单漏了怎么办规则正文每加一个风险维度验证清单同步 1。同系列延伸阅读本篇单独成立· 第 1–9 篇见系列目录 ·本篇为第 10 篇你的全局规则删出过死链吗欢迎评论交流。