过度封装的下场：一个检查代码的活拆成六个组件，改需求改了两天

一句话总结：封装是有成本的，而且大部分成本不在写的时候，在改的时候。我按手工 5 分钟一次、封装一次 60 分钟、月维护 60 分钟算了一遍，分界点在每月 30 次——做不到这个频率，封装就是纯亏。这个数字我一开始也不信，直到自己在一个小活上拆过了头。

一、过度封装的代价：六个组件，改了两天

去年帮一个团队看他们的问题。有个活叫「提交前检查」，需求很简单：看一遍改动，指出明显的坑。

他们做成了这些：一个 slash command 当入口，一份 skill 写检查清单，三个 subagent 分别查接口、数据、前端，两个 hook 在保存时自动格式化，外加一个脚本汇总报告。

我第一次看到的时候是有点羡慕的。跑起来的日志一行一行往外出，每个 agent 各报一段，再拼成一张表，看着特别专业。

三个月后他们要改需求，加一条「只检查本次改动涉及的文件」。改了两天。

问题出在哪儿？「本次改动涉及哪些文件」这个信息，command 里算过一次，三个 subagent 各自算了一次，那个汇总脚本里又算了一次。三处逻辑，三个版本，其中一个版本用的是 git diff HEAD，另外两个是 git status，结果不一致。

他那天跟我说了句话我记到现在：「我以为封装是让东西变简单，结果是让改的地方变多了。」

二、封装的成本账：每月 30 次是分界点

这件事可以算，不用凭感觉。

假设手工做一次花 5 分钟，封装一次性投入 60 分钟，封装后每次调用 1 分钟，每月还要花 60 分钟维护（改需求、修断链、跟文档对齐）。

不封装的月耗时：5n

封装的月耗时：60 + n + 60

两边相等时，n 等于 30。

图 1：两条线的交点就是分界点。维护越贵，门槛越高

这个表最扎人的是前两行。一个月做 5 次的事，封装之后你要多花四倍的时间，而且这笔亏空要等到第 30 次才填平。

如果维护成本降到每月 20 分钟，分界点前移到 20 次。维护成本越高，门槛越高，这是必然的。

我知道有人会说参数是我拍的。对，5 分钟、60 分钟、60 分钟都是估的，你自己的数字肯定不一样。但换任何一组数进去，形状都是这样：低频的事情封装，永远是亏的。

三、四种不该封装的情况

我自己总结四种，按亏的程度排。

第一种，需求还在变。 这是最亏的。你今天封装的是一个还没定型的东西，明天需求一变，所有封装层都要跟着改。改一层还好，改六层就是灾难。

第二种，信息要在多个组件之间传递。 就是开头那个案例。同一个数据在三个地方各算一遍，迟早不一致，而且你看不出哪个是对的。

第三种，做的人和使用的人不是同一个。 你封装完拍拍屁股走了，接手的人得先读懂六个文件才敢改。他读完的时间可能比重新做一个还长。

第四种，频率本来就低。 一个月两次的活，你封装得再漂亮也没机会回本。

四、我自己的教训：一周一次的活，配了整套封装

说完别人说我自己。

有一段时间我特别热衷于把每件事都拆成 command + skill + subagent 三层，觉得这样才叫「工程化」。有个活是每周整理一次数据，我给它配了一个命令、一份规范、两个 agent，还写了测试。

问题是我一周只做一次。

那套东西的维护成本大概每月四十分钟，用来检查路径有没有断、字段名有没有变。而我手工做一次也就八分钟。

等于我每个月花四十分钟，省下三十二分钟。

后来删掉的时候我还挺不舍得，毕竟写了小半天。但留着它，每周要提醒自己一次「这套东西还有用」，其实更累。

这件事给我的教训不是「别封装」，是「先数次数再动手」。我现在做任何封装之前会先问自己一句：这活我上个月做了几次。想不起来的，一律不做。

五、封装的取舍标准：三条就够

现在只有三条，很土但管用。

同一段话粘贴到第三次，才考虑做成 Skill。 前两次可能是偶发，第三次说明它稳定复现了。

每次都要叮嘱「先别动手等我说」，才做成 Command。 这类需求的本质是「我不信任它自己判断」，而不是「我要省事」。判断清楚了这个，就知道该不该做。

要读十几个文件才做得完，才派 Subagent。 读三个文件派出去，光建立上下文就抵消了收益。

三条都满足不了，就老老实实手工做。手工做不丢人，做一套没人维护的封装才丢人。

六、坑清单

想清楚了还是决定封装，这几条能少走点弯路。

1. 同一个数据只在最外层算一次，往下传。 上面那个案例的根因就是这个。别让每个组件自己算，算出来必然对不上。

2. 封装的时候顺手写清楚「为什么这么拆」。 你三个月后回来看，只会记得「这里有个 command」，不记得它为什么不直接做。

3. 先在纸上画一遍数据流。 如果画出来超过五个节点，说明这件事本身还没想清楚，先别封装。

4. 低频的东西宁可用一段 prompt。 有一段两百字的说明就能干完的活，别为了整齐去做成 Skill。

5. 留一条「全拆掉」的退路。 我现在的做法是：封装的东西如果两个月没被用过一次，直接删。不留着占地方。

七、边界

这个算法有个前提：手工做一次的成本是稳定的。如果某类活有时候五分钟有时候两小时，那这个模型不适用，得按平均值再打折。

还有一点我没算进去：封装的隐性收益。比如你做的东西要给三个人用，那省下的不只是你的时间，还有他们三个人各自摸索的时间。这种情况下，即使每月只用一次，也值得做。

所以这个分界点更准确的表述是：只算你自己的时候是 30 次，算上团队要另说。 这一点我一开始漏了，是写完才想起来的。

结语

Command、Skill、Subagent 这些东西确实好用，我上一篇还在讲怎么把它们串起来。但串之前得先问一句：这件事配不配被串。

判断标准不在技术层面，在次数上。一个月做不到三十次的事，做成手工流程就行，写清楚放文档里，谁要用谁照着做。

留一个能马上做的动作：翻一下你现在的封装清单，找出上个月一次都没跑过的那个。如果有，今天就删掉它。删掉的那一刻你会发现轻松，因为你不再需要维护一个没人用的东西。

站里前几篇讲的是怎么用：三者配合、Skill 是什么、从零写一个。这篇讲的是反过来那一面。

参考资料

• Claude Code 原语组合指南 - 四类原语的组合示例与能力矩阵
• Agent Skills 开放标准 - Skill 的格式与按需加载机制
• Claude Code 机制选择器 - 按需求选 Command/Skill/Subagent/Hook 的决策树