最近几天感受到SKILL带来的便利之后，发现其核心能力除了本身渐进式披露的特性之外，scripts 部分可以大大拓展其能力边界，使其产出稳定可靠的产物。
虽然很多大佬提供了很多优秀的 SKILL 可以直接用，但是他们的 SKILL 也是AI构建的，公布的成品仅仅是AI对他们脑子里想法的实现，一旦他们的工作流发生变化，SKILL也会跟着发生变化。
所以你要么和别人步伐完全一致，要么就要自建自己的SKILL、脚本。
而且不要觉得重建自己的工具是多么麻烦的一件事，不管是谁，都是用AI编写的。不会编程的，用自然语言也能写好SKILL。会编程的，用AI写出的脚本会更贴合自己的需求，并且可以随着自己工作流的进化而逐渐丰富。
做什么东西都考虑成本的思维在这个时代真的需要转换一下，写工具已经近乎没有成本了。现在是需要把自己脑子里的东西倾泻，然后落地。
以我重构@zzclub/z-cli项目为例，分享一下最近使用opencode时的一些感受。
永远先Plan再Build
在使用vscode里的Github Copilot时，它已经有了Plan模式，但它明显不是一个真实的Plan模式，仅仅是把Agent的编辑能力给禁用了，Agent在得到指令后会马上想去执行，而不是真的给我做计划，然后发现自己不能编辑，再回头把自己要写的东西先输出给我。多少有点鸡肋。
如果直接Build，经常会出现它做了你意料之外的工作，然后你不得不再补充一句：我不是让你xxx，你怎么xxx，给我xxx
所以只有先让Agent输出它的Plan，你才能提前发现它的错误，从而避免一轮又一轮的纠错。
但这就对非开发者有点影响，因为Plan通常比较详细，如果你看不懂代码，仅靠文字描述，很有可能没能发现AI已经“走错了路”
所以，作为全栈开发者，又能非常清晰的输出自己的架构，在Plan阶段就可以纠正绝大部分错误。
另外，架构并不是指细节到代码里的每个类负责什么都告诉AI，AI本身的编码能力就强于高级开发，只需要从更高的维度用自然语言表述自己的意图即可。
只要不是简单的一句我想要什么什么，而是把自己的产品/脚本语言、背景、用途、使用场景交待清楚，相信顶级的大模型都能输出一个优秀的技术架构。
我的老项目基于JavaScript，包含 chalk、commander、inquirer、ora、shelljs这些依赖包。是一个之前服务于公司内部项目的一些小工具，功能包括：i18n、翻译api、图片压缩等。
首先我让AI分析项目，输出包含全部功能的文档到docs目录下，方便后续它根据此文档来重构。
然后明确要求AI使用 Bun+TypeScript 重构，核心依赖包改为 consola，并附上GitHub地址让AI去读文档。
再结合新技术栈和功能文档，以及此项目要达成的什么效果，比如兼容目前的什么主流应用、自己的独立应用，支持用户使用npx直接调用等等，输出一份重构文档。
重构文档包含了所有它完整的架构方案、目录结构以及一些代码实例，**此时就可以仔细审查，然后指出它的错误，直到整个文档都没问题。**这一步你指不出错误，就不要怪后面它再出错了。
确认无误后切换到Build模式，开始工作
这次长任务一共修改了45个文件，近5000行代码，中间经过了它自己的自动测试和纠错。在完成后，我没有发现任何错误。
从Plan到Build，用时不到20分钟。
完成后我可以生成一个 compress-image SKILL，里面明确指定调用 z tiny -f {目标文件或目录} -r --output {输出目录} 来完成图片压缩任务。
z 是此 cli 的别名
这个CLI工具既可以单独使用，也可以让SKILL明确调用，并且它一定完全适合自己。如果有其他应用想调用，自己也可以很方便的对接。
用别人用AI写的SKILL就会陷入：AI读AI写的，AI再自己对接上个AI写的，中间只有你啥都不知道。
别人可能是用各种方式（各种脚本语言）实现的SKILL，并不一定适合你，并且一旦改动，也不可能要求作者单独再教你。
所以还是尽早学着创建自己的SKILL吧。