【图解 Skill】Skill 重要的不是用，是写

读后感

首先感谢编辑老师赠阅这本书。

最近用 AI 越来越多，一个很明显的感受是：真正消耗人的，不是让 AI 干活，而是每次都要重新教它怎么干活。正所谓你无法教你自己都不懂的东西，无论是 skill 还是 agent，核心还是要提升大模型后面的脑袋。从这个角度来说，使用大模型和摄影有点像：设备固然重要，但核心还是怎么用。

Skill 重要的不是用，是写。

会用 Skill，只是知道 AI 多了一个能力入口；能写 Skill，才是把自己的判断、流程、边界和禁忌沉淀成可复用的生产力。Prompt 更像临场发挥，Skill 更像 SOP 的文字版。AI 越强，人的经验越要写清楚，否则强大的模型也只能在含糊的指令里原地打转。

写 Skill，本质上是在做一个小产品。

Skill 最容易被误解成某种神奇插件，好像装上就能自动变强。其实真正难的地方，还是把需求定义清楚：它解决什么问题，谁在什么时候用，需要什么输入，应该产出什么结果，有哪些规则，哪些事绝对不能做。这不就是产品定义吗？好 Skill 和好产品一样，都是从真实痛点里长出来的。痛点足够真实，Skill 才有生命力。

AI 工程里的很多复杂度，不是模型不聪明，而是我们没有把隐性规则显性化。

我很喜欢书里把任务拆成几类动作的思路：做判断、执行规则、调外援。判断就是 IF ELSE，流程里的循环其实就是 while。听起来很程序员，但这恰好说明 Skill 的写法和软件工程是相通的。好的 Skill 不是堆大段说明，而是把任务拆成稳定的判断点、可执行的步骤、必要时调用的工具。复杂任务当然需要拆分，但拆分不等于一定要上子代理。很多时候，一个写得清楚的 Skill，加上合适的工具调用，比一组昂贵的子代理更稳定、更便宜，也更容易调试。

现在开始写一个你自己的 Skill，非常重要。

这本书尤其适合三类人：第一类，是已经每天使用 AI，但总觉得每次都要重新解释需求的人；第二类，是有固定工作流、固定交付标准，希望把经验沉淀下来的人；第三类，是正在做 AI 应用、AI Agent 或团队效率工具的人。

你不一定要先搭一个复杂系统，也不一定要先学会所有新概念。先从一个真实痛点开始，把你最常重复的工作写成 Skill，让它跑起来，再慢慢调。准备好的一天永远不会到来，写第一个 Skill 的最好时间就是现在。这本书，是一个很好的开始。

读书笔记

• 调试满意 -> 同一个对话里让 AI 做 skill 初始化
• 是否生效的检测（用skill 调用更加清晰的 agent 工具）
• 技能是 SOP 的文字版，解决业务对齐的问题
• 按需加载是一个双刃剑，因为怎么是按需，怎么按需，都可能带来很多的复杂度
• description 的内容，围绕是否触发来描述（误触发、漏触发），= 功能定义 + 触发场景/触发词。
  • 反向触发词：告诉大模型什么时候不用
  • 人称：不要有 “我”，“你”
  • 长度：100字左右，最多不超过 200 字
• 任务的 3 类动作：做判断、执行规则、调外援（IF ELSE）- 现在的 LOOP 其实就是 while
• 先跑起来，再慢慢调
• 约束型技能 vs 模板型技能 vs 流程型技能
• 好技能从真实痛点长出来（好产品也是）
• 定义需求：
  • 问题 - 解决什么
  • 场景 - 谁在什么时候用
  • 输入 - 需要什么
  • 输出 - 产出什么
  • 规则 - 有什么约束
  • 禁止清单 - 绝对不能做什么

分析 Collection/03 燕子集 中文章的写作风格，从以下四个维度总结我的写作特点：用词偏好、句式习惯、结构特点、语气风格。然后帮我创建一个写作风格技能。

子代理的效果和性价比在我这里并没有得到认可，花大钱办小事在商业上是没有意义的。