一开始，大家对 skill 的想象都很美好。
它像一个能力胶囊，把一类重复工作沉淀下来。你不需要每次重新解释背景，也不需要从零组织 prompt，只要在合适的时刻调用它，AI 就能按一种更稳定的方式把事做完。
这个方向当然没错。问题是，很多 skill 写着写着，就开始失控。
最初只是为了让它多覆盖一个场景，于是补一段说明；后来发现某类输出不稳定，再补一段限制；接着又怕它漏掉上下文，于是把前情、例外、边界、失败回退全都塞进去。久而久之，一个本该是“能力单元”的东西，变成了一个越来越厚、越来越难维护、越来越依赖作者本人理解力的半黑箱 workflow。
这时候它虽然还叫 skill，但实际上已经开始像负担了。
复杂 skill 的问题，不在于复杂本身，而在于它会伪装成“更完整”
这是我最近一个很强烈的感受。复杂 skill 最麻烦的地方，并不是它步骤多，而是它总让人误以为：写得越全，系统就越可靠。
可现实通常相反。
随着 instructions 不断累加，模型并不会像一个资深工程师那样自动分辨轻重缓急。它看到的是一整片需要同时处理的上下文。东西越杂，重点越容易被稀释。很多人以为自己是在“补齐规则”，其实更像是在往系统里不断注入竞争注意力的噪声。
外部一些文章已经把这件事说得很直接了：与其做一个 do-everything prompt，不如做按需加载的模块化能力。这个判断我很认同。因为一旦一个 skill 需要同时覆盖太多变体、太多例外、太多流程分支，它本质上就已经不再是 skill，而是在替一个本该由系统层解决的问题兜底。
一个好 skill，更像“能力模块”，不是“总控剧本”
我现在越来越倾向于把 skill 理解成一种边界清晰的能力封装。
它当然可以带流程感，但它不该吞掉整个流程。它可以教 agent 在某个任务类型里怎么做事，但它不该试图代替整个 runtime、memory、tool routing、异常处理和长期协作规则。
如果一个 skill 要靠自己解释所有背景、所有工具用法、所有失败路径、所有上下文读取顺序，那只能说明一件事：系统别处太空了，于是大家开始把所有问题都往 skill 里塞。
这就是为什么很多人写 skill，会写出一种“越调越重”的感觉。因为它不是在调 skill，而是在用 skill 修补 harness 的缺口。
很多 skill 的失败，其实是 harness 的失败
我越来越觉得，这件事得换个角度看。
一个 agent 做事不稳，当然可能是 skill 本身写得不好。但更多时候，真正的问题往往在 skill 外面。比如：它有没有长期记忆？有没有稳定可用的工具？有没有明确的工作规则？有没有可追溯的文件结构？有没有评测机制？有没有在运行时区分“该主动做”和“该停下来问”的边界？
如果这些东西缺位，你再怎么打磨 skill，也很容易陷入一种熟悉的循环：面多加水，水多加面。哪儿表现不好，就往 skill 里补一层说明。补到最后，skill 成了一个大杂烩，而系统的根问题却还在原地。
所以我现在会更愿意说，很多 skill 问题，本质上不是 prompt 问题，也不是某一段 SOP 的问题，而是 harness 问题。是整个系统怎样给 agent 提供记忆、工具、边界和反馈的问题。
为什么 skill 调优会慢慢变成一种技术活
这也解释了另一个很有意思的现象：为什么很多人都觉得 skill 门槛看起来很低，但真要把它调好，最后又明显不是一个纯小白活。
因为 skill 调优表面上像写文案，实际上牵涉三层能力。
第一层，是你对模型边界的熟悉程度。你得知道哪些话模型真能吃进去，哪些要求只是写给自己看的心理安慰。很多 skill 之所以显得臃肿，就是因为作者并不确定系统到底会不会按预期理解，只能不断用更多文字去“压一压”。
第二层，是你对任务的抽象能力。你能不能把一个问题说清楚，而且是对 agent 说清楚？这和对人说清楚不是一回事。很多时候我们不是说得不够多，而是说得不够结构化；也不是说得不够细，而是把不该塞进 skill 的东西也塞了进去。
第三层，是你对整个 harness 的理解。单一 skill 的优化，很多时候必须放回整个体系里看。哪些信息应该进记忆，哪些应该进 skill，哪些应该交给工具发现，哪些应该交给运行时约束，哪些应该靠 eval 托底——这不是改几句提示词能解决的。
所以所谓“skill 调优师”听起来像玩笑，但它背后的工作内容其实已经出现了。它更像一种系统调音，而不是一句 prompt 的雕花。
真正该花力气的，不是把 skill 写得更长，而是把评测标准写得更准
如果说前几年大家最容易高估的是 prompt，那现在大家最容易高估的就是 workflow。
很多人觉得，只要把 loop 跑起来，把多步骤链起来，把 skill 写成一个像样的执行流程，事情就会越来越自动、越来越聪明。可经验恰恰说明，能不能 loop 起来并不稀缺，真正稀缺的是：你到底知不知道什么结果才算“好”。
这也是为什么这波讨论最后都会落到 auto eval、奖励函数和评价框架上。因为没有评测标准，再漂亮的 skill 也只是一个会动的主观感觉生成器。它可能有时让你惊艳，但你很难稳定复现，更难系统改进。
反过来，只要你能把偏好、验收条件和负反馈定义得足够清楚，很多东西其实都可以被迭代出来。难的从来不是“让 AI 试很多次”，而是“你能不能明确地告诉系统，什么结果值得保留，什么结果应该淘汰”。
为什么 knowhow 比单次 deep research 更有复利
还有一个我越来越相信的判断：在 skill 时代，真正值钱的，往往不是一次次临时做得很漂亮的深度检索，而是那些被沉淀下来的 knowhow。
也就是你自己的 notes、评论、判断口径、做事经验、踩坑结论，甚至你对某个领域的稳定偏好。这些东西一旦被整理成 AI 可检索、可继承的结构，它们产生的价值，通常会比一次“现搜现写”的结果高得多。
因为单次 deep research 提供的是信息，knowhow 提供的是判断。信息当然重要，但真正拉开协作差距的，往往是判断层。你给 AI 的不是更多网页，而是一套越来越像你的工作语境。
从这个角度看，skill 的上限也不只是取决于 skill 本身，而取决于它背后是否接得上你的记忆、笔记、项目上下文和长期方法库。
所以，skill 最好的状态其实是“轻”，但背后要“厚”
这是我最后最想说的一点。
一个成熟系统里的 skill，表面上往往不会太重。它应该是清楚的、克制的、边界明确的。它知道自己解决什么，不解决什么；知道什么时候该触发，什么时候不该触发；知道自己该调用哪些现成能力，而不是把整座系统背在身上。
但它背后，反而应该很厚。厚的不是 skill 文件本身，而是整个 harness：记忆、工具、runtime、规则文件、评测机制、knowhow 库、项目语境，以及长期积累出来的工作方式。
换句话说，真正成熟的系统，不是把所有复杂度堆进一个 skill，而是把复杂度分散到正确的位置。
最后一句话
Skill 真正的价值，不在于它写得多完整，
而在于它是不是一个边界清晰、可验证、可组合的能力单元。
如果一个 skill 开始越写越重，先别急着继续加料。很多时候，那不是它还不够完整，而是系统该补的东西，被你全塞进 skill 里了。
比起继续把它写成一部总控剧本，我更愿意做的事，是把它拆开，把评测补上，把 knowhow 沉下去，再把整个 harness 调顺。
因为真正能长期工作的 agent，从来不是靠一份越来越厚的 skill 长出来的。