#行为设计

avatar
sitin
5天前
为什么别人写的 Skill 装上就能用，自己写的怎么调都不对？ 后来慢慢发现——问题真的不在 YAML，也不在目录结构，而是在“你到底在设计什么”。 以前写 Skill，本质就是在写一段“更长的提示词”。 但这玩意儿有个致命问题：如果没有在设计“行为”，那只是在描述“期望”。AI 听懂一部分，但执行的时候很容易跑偏。 看了 Google 那篇总结之后，我有一个很强的共鸣：Skill 本质不是 prompt，而是一个“工作模式”。 比如你让它写代码规范，其实不是在让它“生成内容”，而是在让它“遵守规则”（Tool Wrapper）。 让它写报告，也不是让它自由发挥，而是让它“按模板填空”（Generator）。 让它帮你检查代码，本质是“拿 checklist 一条条过”（Reviewer）。 一旦用“模式”去想，而不是“我该怎么写提示词”，整个思路会完全变掉。 一个很深的体感是：Agent 不缺能力，缺的是“被约束的结构”。 你不给结构，它就会用最省力的方式——猜 + 直接输出。 这在简单任务上是优势，在复杂任务上就是灾难。 所以有两个特别关键的模式： Inversion：强行让它先问清楚再动手（这个我现在几乎必加） Pipeline：用阶段 + 门控，把它锁在流程里，不让它乱跳 这两个东西一旦用上，你会明显感觉： Agent 不再是“有点聪明但不稳定”，而是开始像一个“能被管理的人”。 还有一个我自己的总结：Skill 写得好不好，本质不是你写得多复杂，而是你有没有“选对模式”。 很多人一上来就想搞复杂 Pipeline，其实完全没必要。 我反而建议： 先做 Tool Wrapper（最立竿见影） 再做 Reviewer（复用性极高） 然后再看 Generator / Inversion 最后才是 Pipeline 你会发现，一旦你脑子里有这几种“套路”， 写 Skill 就不再是试错，而是在做设计决策。 说白了就是一句话：以前你是在“写 prompt”，现在你是在“设计一个小系统”。
#Skill设计 #YAML #目录结构 #行为设计 #谷歌总结