一个反直觉的事实
在 Prompt Engineering 中，我们总倾向于"加"。加一条规则、加一个示例、加一个兜底说明------每个加法都有充分的理由。但很少有人问：这段话删掉之后，Agent 的表现会变差吗？
我这次尝试了一种反向方法论：逐句审查，每遇到一段话就问自己一个问题------
如果我把这句删掉，Agent 在相同输入下，会不会做出不同的决策？
如果答案是"否"，就毫不犹豫地删掉。
结果出乎意料：在 15 个技能文件中，我找到了几十处这样的"无害冗余"。它们可能是：
对 Agent 已经知道的框架背景的复述
已经被更上层规则覆盖的重复约束
解释性文字（Agent 不需要理解"为什么"，只需要执行"什么"）
"注意""请确保""请记住"这类软化词------它们消耗 Token 但不改变行为边界
我把这个过程叫做 "no-op 修剪"（无操作修剪）。删掉的内容不改变一行代码输出，不改变一个决策路径------只改变 Token 消耗量。
剪枝的三种策略
这次实践中，我总结了三种可复用的剪枝策略：
策略一：覆盖性去重
当全局规则（如 AGENTS.md）和某个技能（如 code-review/SKILL.md）都提到了"提交前必须验证"，保留哪个？
原则：保留层级最高的那个，删除低层级的重复。Agent 在处理任务时，高层级规则已经在上下文中了，低层级再重复一遍不会增加遵守概率------只会增加成本。
策略二：功能性去重
当一个技能的功能可以被另一个更通用的技能覆盖时，前者就是冗余。例如：
有一个专门的"调试循环"技能，但系统已经内置了更强大的调试工作流
有一个"提交规范"技能，但 Agent 的基础指令已经包含了提交格式要求
这类技能的价值往往来自"心理安全感"------"万一 Agent 不懂呢？"但实际测试会发现，删掉之后表现完全一致。
策略三：解释性剥离
最常见也最难察觉的冗余：解释性文字。
❌ 坏："在开始之前，请确保你理解了项目结构。这意味着你需要先查看目录布局，因为了解整体架构对于后续的代码修改至关重要。"
✅ 好："先查看项目结构再开始修改代码。"
前者 60 字，后者 12 字。传达的信息完全一致，但 Token 消耗差了 5 倍。Agent 不需要你解释"为什么重要"------它需要的是清晰、可操作的约束。
从"加"思维到"减"思维
这次瘦身之后，我有两个感悟：
第一，每个 Prompt 都有一个"边际收益拐点"。
在拐点之前，加一段话确实能让 Agent 表现更好。但过了拐点，再加就是噪音------甚至可能稀释真正重要的约束。问题是，大多数人（包括我）都在拐点右侧工作，却意识不到。
第二，删除比添加更需要勇气。
加一段话，即使没用，也"不会出错"。删一段话，如果真的影响了 Agent 行为，代价就是一次调试。这导致了一个自然的熵增趋势------Prompt 只会越来越长，除非有人主动逆向操作。
所以我现在给自己定了一个规矩：每次要加一条规则时，必须先找到一条可以删掉的旧规则。 如果找不到，说明那条新规则可能没那么必要。
几个具体的技术实践
如果这套思路对你有用，以下是一些可以直接尝试的做法：
用"删掉会怎样？"替代"加上够不够？"来审查每一条 Prompt。
用函数式思维写 Prompt：一个约束一个职责，避免复合句。如果一段话说两件事，拆开------你会发现其中一件可能根本不需要。
消除软化词："请""建议""可以尝试"之类的词在 Agent 上下文里只是字节垃圾。和代码一样，Prompt