1. 模型变强之后，为什么反而要做减法
过去一年我一直在折腾各种 Coding Agent 的配置，从最早的 AGENTS.md 到后来的 SKILL.md，再到各种 Prompt 模板库，几乎每个新概念出来我都会第一时间跟进。但最近半年我观察到一个非常明显的趋势：模型本身的能力越强，我们堆砌的那些 Skill 和 Prompt 反而越容易成为负担。这个感受不是凭空来的，是我在实际项目里反复踩坑之后总结出来的。
先说一个最直观的现象。早期用能力较弱的模型时，你需要把每一步都写清楚——"先读取文件，再分析依赖，然后生成代码，最后跑测试"，少一步它就漏一步。那时候 Prompt 写得越细越好，Skill 封装得越全越省心。但现在情况完全反过来了，你把流程写死之后，模型反而被你的框架限制住了，它明明有能力自己判断该先做什么，却被你强行按在一个固定顺序里，结果就是输出质量下降，甚至出现"prompt 闪退"这类让人摸不着头脑的问题。
这篇文章我想聊的就是这件事：当底层模型能力跨过某个阈值之后，Skill 和 Prompt 的编写策略需要从"加法"转向"减法"。具体来说，我会拆解三个层面的问题——为什么减法比加法难、哪些东西该删哪些该留、以及怎么判断自己是不是"过度配置"了。适合正在用 Coding Agent 做开发、或者维护团队级 AGENTS.md / SKILL.md 规范的同学参考。如果你刚开始接触这块，也能从里面看到一些别人踩过的坑，少走弯路。
我自己的判断是，这个转变不是某个工具的特性，而是整个行业在模型能力提升后的必然调整。理解了这个逻辑，你不管用的是哪家的 Agent，都能找到适合自己的配置节奏。
2. 从加法到减法：配置思路的根本转变
2.1 早期"加法思维"是怎么形成的
回想一下最开始接触 Prompt Engineering 的时候，大家的方法论基本都是一样的：把任务拆解成尽可能小的步骤，每一步都给明确的指令，然后用 few-shot 示例把边界情况覆盖全。这套方法在模型能力有限的时候确实有效，因为模型自己不会推理，你得替它推理。
这种思维延伸到 Skill 和 AGENTS.md 上就变成了：能封装的都封装，能写死的都写死。我见过一个团队的 AGENTS.md 写了将近两千行，里面规定了代码风格、目录结构、提交信息格式、测试覆盖率要求、甚至每个函数该怎么命名。刚开始确实管用，新人接手项目时照着做就行。但问题是，这份文档越来越难维护，每次模型升级或者项目结构调整，都要花大量时间去同步更新，而且更新完之后经常发现——模型根本不需要你写这么细。
2.2 模型能力提升带来的三个变化
第一个变化是推理能力的溢出。现在的模型在处理一个编程任务时，会自己去做需求分析、方案对比、边界检查，这些以前需要你在 Prompt 里显式引导的动作，它已经内化了。你再去写"请先分析需求再写代码"，属于重复劳动，甚至可能干扰它自己的判断节奏。
第二个变化是上下文理解的增强。以前你需要在 SKILL.md 里反复强调"这个项目的测试框架是 pytest 不是 unittest"，现在模型读一遍项目结构就能推断出来。过度强调反而会让它产生困惑，觉得你是不是在暗示什么特殊情况。
第三个变化是指令遵循的精确化。这个听起来是好事，但实际用起来有个副作用：你写的每一条规则它都会严格执行，包括那些你随手加上去的、其实没那么重要的约束。比如你在 Prompt 里写了一句"尽量使用简洁的变量名"，结果模型为了"简洁"把一些本该有描述性的变量名缩成了单字母，代码可读性反而下降。
2.3 减法不是删光，而是重新分配权重
这里要澄清一个误区。做减法不等于把所有 Skill 和 Prompt 都删掉，而是把配置的重心从"规定动作"转移到"约束边界"。打个比方，以前你是在教一个新手怎么走路，每一步都要扶着；现在模型已经会跑了，你要做的是告诉它哪里不能去，而不是继续扶着它走。
具体到操作上，我的做法是把原来的配置分成三类：必须保留的硬约束（比如安全规范、绝对不能改的接口）、可以简化的软引导（比如代码风格偏好）、应该删除的冗余指令（比如模型已经能自己判断的流程步骤）。这个分类过程本身就是一次对项目需求的重新梳理，很多时候你会发现，原来写的一大半内容其实都是"以防万一"加上去的，实际从来没触发过。
3. 哪些 Skill 该留，哪些 Prompt 该删
3.1 判断标准：三个问题快速筛选
我总结了一个简单的筛选方法，每次整理配置的时候问自己三个问题：
- 这个问题模型自己能解决吗？如果答案是"能"，那相关的 Prompt 就可以删。比如"请检查代码是否有语法错误"，现在的模型写完代码基本都会自查，不需要你提醒。
- 这条规则是项目特有的还是通用的？通用的删掉，项目特有的保留。比如"使用 4 空格缩进"是通用规范，模型默认就会遵守；但"这个项目的 API 返回格式必须是
{code, data, msg}"是项目特有的，必须写清楚。 - 删掉之后出问题的概率有多大？如果删掉之后十次里有一次会出错，那还是留着；如果一百次里都不一定出一次，那就删掉，出问题的时候再补回来。
这三个问题过一遍，通常能砍掉一半以上的内容。我最近一次整理一个中型项目的 AGENTS.md，从 800 多行压到了 200 行出头，实际使用下来效果反而更好了。
3.2 该保留的：硬约束和项目特有知识
有几类内容是绝对不能删的，删了必出问题：
安全相关的约束。比如"不要执行删除数据库的命令"、"不要修改生产环境的配置文件"，这类规则不管模型多强都要保留，因为一旦触发就是灾难性的。
项目特有的架构约定。比如"所有数据库操作必须通过 Repository 层"、"前端组件必须放在src/components目录下"，这些是模型无法从代码里推断出来的团队约定，必须显式说明。
外部系统的对接细节。比如"调用支付接口时需要先获取 token，token 有效期 30 分钟"，这类信息模型不可能知道，必须写清楚。
明确的禁止事项。比如"不要引入新的第三方依赖"、"不要修改legacy/目录下的代码"，这类约束越明确越好。
3.3 该删除的：流程指令和过度约束
下面这几类内容，是我在实际使用中验证过可以放心删掉的：
步骤化的流程指令。像"第一步读取文件，第二步分析依赖，第三步生成代码"这种，模型自己会规划，你写死了反而限制它。我试过同一个任务，写死流程的版本和让模型自由发挥的版本，后者的代码质量明显更高。
重复强调的通用规范。比如"代码要有注释"、"变量名要有意义"、"函数不要太长"，这些模型默认就会做，写上去纯属占地方。
过于具体的实现细节。比如"使用for循环而不是while循环"、"优先使用map而不是forEach"，这类偏好除非有硬性理由，否则不该写进配置里。
情绪化的强调。比如"非常重要！！！"、"一定要注意！！！"，这种表达对模型没有额外效果，只会让配置显得不专业。
3.4 一个实际的删减对照表
为了让大家更直观地理解，我整理了一个对照表，左边是常见的"加法配置"，右边是"减法之后"的写法：
| 加法写法 | 减法写法 | 删减理由 |
|---|---|---|
| 请先分析需求，再设计方案，最后编写代码 | （删除） | 模型会自行规划流程 |
| 代码必须包含注释，注释要清晰 | 公共 API 必须有文档注释 | 通用要求模型默认遵守，只保留项目特有要求 |
| 使用 pytest 运行测试，测试文件放在 tests 目录 | 测试文件放在 tests 目录 | 框架选择模型能从项目推断 |
| 非常重要：不要修改配置文件 | 不要修改config/目录 | 去掉情绪化表达，明确具体范围 |
| 变量名要有意义，函数不要太长，避免重复代码 | （删除） | 全是通用规范，模型默认遵守 |
这张表里的每一条删减，我都在实际项目里验证过，删掉之后没有出现预期外的问题。当然，如果你的项目有特殊情况，该保留的还是要保留，关键是别把"通用规范"当成"项目知识"来写。
4. 实操：一次完整的配置瘦身过程
4.1 准备工作：先备份再动手
动手之前一定要做两件事。第一是把现有的 AGENTS.md 和 SKILL.md 完整备份，最好是提交到 git 里，这样万一删多了还能回滚。第二是准备一组测试任务，用来验证删减前后的效果差异。我一般会准备 5 到 10 个有代表性的任务，覆盖日常开发的主要场景，比如新增功能、修复 bug、重构代码、写测试等。
测试任务的选择有个小技巧：优先选那些以前出过问题的任务。因为这些任务最能暴露配置里的关键约束，如果删减之后这些任务还能正常完成，说明删对了；如果出问题了，也能快速定位到是哪条约束不能删。
4.2 第一步：标记所有内容
打开配置文件，逐条过一遍，给每条内容打上标签：
- H（Hard）：硬约束，绝对不能删
- S（Soft）：软引导，可以简化
- R（Redundant）：冗余，可以直接删
这个过程不要着急，一条一条来。遇到拿不准的，先标成 S，后面用测试任务验证。我自己的经验是，标 H 的内容通常不超过总数的 20%，剩下 80% 里有一半是 S，一半是 R。
标记的时候有个判断技巧：如果这条内容删掉之后，模型有 90% 以上的概率还能做对，那就标 R。不要因为"万一出错怎么办"就全部保留，那样永远瘦不下来。
4.3 第二步：分批删减并验证
不要一次性把所有 R 都删掉，而是分批删，每批删完之后跑一遍测试任务。我一般分三批：
第一批删最明显的冗余，比如重复的通用规范、情绪化表达、模型已经能自己判断的流程指令。这批删完通常能减掉 30% 到 40% 的内容，跑测试任务基本不会有问题。
第二批删软引导里可以简化的部分，比如把详细的代码风格说明压缩成一句话，把多个示例合并成一个。这批删完可能减掉 20% 左右，需要仔细看测试结果，有时候会出现一些细微的质量下降。
第三批处理那些拿不准的边界情况，逐条验证。这批删完基本就到位了，剩下的都是真正必要的约束。
4.4 第三步：观察长期表现
删减完成之后不要马上定稿，至少观察两周的实际使用情况。因为有些问题不是测试任务能覆盖的，只有在真实开发中才会暴露。我一般会在这两周里记录每次模型输出不符合预期的情况，然后判断是配置缺失导致的，还是模型本身的问题。
如果确实是配置缺失，就把对应的约束加回来，但要用更精确的写法。比如原来写的是"注意代码风格"，现在改成"所有导出函数必须有 JSDoc 注释"，这样既解决了问题，又不会引入新的冗余。
4.5 一个真实的瘦身案例
我最近处理的一个项目，原来的 AGENTS.md 有 847 行，SKILL.md 有 12 个。瘦身之后 AGENTS.md 剩 213 行，SKILL.md 合并成了 4 个。具体的变化是这样的：
原来的 12 个 Skill 里，有 5 个是"代码格式化"、"命名规范"、"注释要求"这类通用规范，直接删掉；有 3 个是"API 调用流程"、"数据库操作流程"这类流程指令，也删掉；剩下 4 个是项目特有的业务逻辑封装，保留并合并。
AGENTS.md 的 847 行里，删掉了大约 400 行的流程说明和通用规范，简化了 200 多行的代码风格描述，保留了 200 行左右的项目架构约定和安全约束。
瘦身之后跑了一周的开发任务，代码质量没有下降，反而因为模型有了更多自主空间，一些以前需要手动调整的地方现在一次就对了。最直观的感受是，模型不再"机械执行"了，遇到配置里没覆盖的情况会主动询问，而不是硬套一个不合适的规则。
5. 常见问题与排查技巧
5.1 删减之后模型开始"自由发挥"怎么办
这是最常见的问题。删掉流程指令之后，模型可能会选择一条你不熟悉的实现路径。遇到这种情况，不要急着把流程指令加回来，而是先判断它的方案是否合理。如果方案本身没问题，只是和你习惯的不一样，那就接受它；如果方案确实有问题，那说明你需要的不是流程指令，而是一条更精确的约束。
比如模型把数据库操作直接写在了 Controller 里，你不需要写"请按照 Controller-Service-Repository 分层"，而是写"数据库操作必须在 Repository 层"。后者是约束，前者是流程，约束比流程更稳定。
5.2 怎么判断是配置问题还是模型问题
这个判断很重要，因为如果是模型问题，你改配置也没用。我的判断方法是：同一个任务，用不同的表述方式跑三次。如果三次都失败，大概率是模型能力问题；如果只有某一种表述失败，那就是配置表述的问题。
还有一种情况是任务本身超出了模型的能力范围，比如要求它理解一个非常复杂的业务逻辑。这时候正确的做法是把任务拆小，而不是在配置里加更多说明。
5.3 团队协作时怎么统一标准
个人项目做减法相对容易，团队项目就麻烦了，因为每个人对"什么该保留"的判断不一样。我的做法是建立一个最小共识集，只保留所有人都认可的硬约束，其他内容放到个人配置里。
具体操作是：团队级的 AGENTS.md 只写项目架构、安全规范、外部系统对接这三类内容，代码风格、命名偏好这些放到个人的配置里。这样既保证了团队协作的一致性，又给了个人调整的空间。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 排查方向 | 解决方式 |
|---|---|---|---|
| 模型输出格式不对 | 格式约束被误删 | 检查是否有明确的格式说明 | 加回格式约束，用示例说明 |
| 模型忽略了某个约定 | 约定表述不够明确 | 检查约定是否具体可执行 | 改成明确的禁止或必须句式 |
| 模型执行了危险操作 | 安全约束缺失 | 检查是否有安全相关约束 | 立即加回，并测试验证 |
| 模型反复询问同一问题 | 配置里有矛盾指令 | 检查是否有互相冲突的规则 | 删除冲突项，保留一条 |
| 输出质量整体下降 | 删减过度 | 对比删减前后的测试结果 | 分批回滚，定位问题约束 |
5.5 几个容易踩的坑
第一个坑是把"模型能做的事"当成"模型一定会做的事"。有些约束虽然模型有能力遵守，但如果你不写，它可能不会主动去做。比如"写完代码后运行测试"，模型有能力做，但默认不一定做，这类还是要保留。
第二个坑是删减之后没有更新文档说明。团队里其他人不知道你删了什么，可能会重新加回去。建议在配置文件顶部加一段说明，写清楚哪些内容被删了、为什么删。
第三个坑是用一次测试结果就下结论。模型的输出有随机性，一次成功不代表稳定，一次失败也不代表有问题。至少要跑五次以上，看整体表现。
第四个坑是忽略了模型版本差异。不同版本的模型能力不一样，你在这个版本上验证过的删减方案，换个版本可能就不适用了。建议在配置文件里标注验证过的模型版本。
6. 我个人的一些经验和判断
做减法这件事，说到底是一个对模型能力建立信任的过程。刚开始我也不敢删，总觉得多写点保险。但实际用下来发现，配置越精简，模型的表现反而越稳定，因为干扰少了，它能更专注地理解你的真实意图。
我现在维护配置的原则很简单：只写模型不知道的，不写模型能推断的。项目特有的架构约定、外部系统的对接细节、安全相关的硬约束，这些必须写；通用的代码规范、流程步骤、实现偏好，这些统统不写。按这个原则整理下来，配置通常能控制在 200 行以内，维护成本大幅降低。
还有一个体会是，减法不是一次性的工作，而是持续的过程。每次模型升级、项目重构、需求变化，都要重新审视一遍配置，看看有没有新的冗余产生。我一般每个月会花半小时过一遍，把不再需要的内容删掉，把新出现的约束加上。
最后分享一个小技巧：如果你不确定某条约束该不该留，可以先把它注释掉，观察一周。如果一周内没有因为缺少这条约束出问题，那就放心删掉；如果出问题了，再取消注释，同时思考怎么用更精确的方式表达。这个方法比直接删除更稳妥，适合刚开始做减法的同学。
配置这件事没有标准答案，每个项目、每个团队的情况都不一样。但方向是明确的：模型越强，配置越简。与其花时间写更多的 Prompt 和 Skill，不如把精力放在理解模型的能力边界上，知道它能做什么、不能做什么，然后只在必要的地方施加约束。这样既省心，效果又好。
