夜雨聆风
有些AI工具，你收藏的时候很激动。
过两天就忘了。
但有些东西不一样。它不是一个网址，也不是一个模型名，而是一套你反复做事的方法。你把它写清楚、跑通、验证过，下一次就不用从零开始。
这东西，在Agent时代叫 Skill。
原文讲的是作者趁 Claude Fable 5 短暂开放的窗口，做了一个“专门升级 Skill 的 Skill”，名字叫“鲁班 Skill”。听起来有点绕，但背后的判断很实在：
普通人用AI，真正能沉淀下来的资产，不是收藏了多少工具，而是有没有把自己的工作流打磨成可复用的手艺。
别把Skill想复杂了
很多人一听 Skill，就以为必须有脚本、浏览器自动化、MCP、复杂依赖。
不一定。
很多好用的 Skill，主体其实就是一段足够清楚的提示语。
它清楚到什么程度？
谁该用、什么时候用、输入什么、输出什么、遇到失败怎么办、哪些事绝对不要做，都写明白。
这就已经比“帮我优化一下”强太多了。
因为大多数临时Prompt的问题，不是不会写，而是没有边界。今天能跑，明天换个场景就散了。自己能懂，别人打开完全不知道怎么用。
这也是原文里最有价值的一句话：
能用，和能发布，中间差着一大截。
你本地有一个Skill，自己跑得挺顺，不代表别人看得懂。
别人看得懂，也不代表愿意安装。
愿意安装，也不代表三分钟内能跑出一次完整结果。
这三道坎，才是Skill从“私用品”变成“作品”的关键。
好Skill第一步，不是润色，是追问它凭什么存在
很多人让Agent优化一个 Skill，Agent通常会做几件事：
加几个小标题，补一点触发词，把描述写漂亮一点，再把格式整理整齐。
这些有没有用？有。
但不够。
真正该先问的是：这个 Skill 解决的真实问题成立吗？
用户为什么要安装它，而不是临时问一次Agent？
它的独特性来自哪里？是方法论、脚本资产、私有经验、数据、工作流，还是可展示的结果？
如果这些问题答不上来，后面再怎么排版，也只是把一个普通文件包装得更像样。
原文里“鲁班Skill”的第一步，就是派一个类似产品经理的角色，先挑战前提。
这点我很认同。
Skill不是提示词的美化工程，它更像一个小产品。
小产品就得回答一个最朴素的问题：别人为什么要用你？
如果只是“帮我总结文章”“帮我写周报”“帮我查资料”，那用户完全可以直接问Agent。除非你有固定流程、质量标准、失败处理、资料来源、输出模板，否则它就不值得单独沉淀成Skill。
横向看同类，纵向看演进
原文里还有一个很好的方法，叫横纵分析。
纵向看：这个 Skill 从哪里来，要走到哪里。
它最初解决什么痛点？现在是工具、方法论、工作流，还是自动化系统？如果要从“自己能用”变成“别人也能用”，最缺的是稳定性、展示效果、安装路径，还是验证标准？
横向看：同类东西为什么更容易被理解、收藏和传播。
名字有没有记忆点？一句话能不能讲清楚？README首屏有没有截图、GIF、结果样例？跑完之后有没有一个看得见的产物，比如HTML、PDF、报告、卡片、diff、测试结果？
这一步很容易被忽略。
很多人优化项目，只盯着自己的功能列表看。结果越改越细，越改越像自嗨。
横向一看，你才知道别人真正买账的点在哪里。
纵向一看，你才知道自己下一版到底该往哪里长。
原文里举的例子也很典型：Fable 5 没有把重点放在“再做一个更好的AI新闻站”，而是指出项目真正有差异的是那份公开的静态JSON数据接口。
这个判断就不只是功能建议了。
这是生态位判断。
很多项目卡住，不是功能不够，而是没有把自己真正独特的位置说清楚。
评分不能只看文档漂亮不漂亮
原文提到“Darwin式评分”，这个点也很关键。
一个 Skill 写得好不好，不能只看 Markdown 是否整齐。
要看它能不能在真实任务里跑出更好的结果。
所以评分维度里，应该有这些东西：
Frontmatter 和触发条件是否清楚 工作流是否一步步可执行 失败模式有没有写明 关键位置有没有检查点 指令是否具体到命令、路径、格式 有没有高风险动作黑名单 资源文件是否能找到 整体结构是否不冗余 最重要的：测试Prompt跑出来，是否真的比不用Skill更好
最后这一条，最容易被跳过。
很多Skill的README很好看，showcase也很漂亮，但你真拿一个常见Prompt跑一下，就发现它只是把话说得更复杂了，结果并没有更稳。
所以我觉得，Skill要从“看起来不错”走向“真的可复用”，至少要有两个测试：
一个典型场景，证明它能跑通主流程。
一个稍微复杂的场景，证明它遇到边界不会乱来。
如果改完之后，两个测试都没有变好，那就别急着说升级成功。
一次只改一个变量
原文里还提到一个很像做实验的原则：每一轮只改一个主要方向。
这一点特别重要。
比如这一轮只修触发词，就不要顺手重写README。
这一轮只补失败模式，就不要顺手加一堆展示图。
否则你最后根本不知道，结果变好到底是因为哪一步。
这也是很多Agent协作容易翻车的地方。它太勤快了，一次把所有东西都改了。表面看产出很多，实际上不可追踪、不可回滚、不可复盘。
真正稳的做法是：
先评估，再选最短板的一项，再改，再测。变好了就保留，没变好就回滚。
这才是“打磨”。
不是让Agent自由发挥一晚上，第二天收一个巨大的diff。
最后留下来的，是你的手艺
我最喜欢原文最后的判断：
普通人用AI最重要的资产，不是收藏了多少工具。
而是有没有把自己反复做的那几件事，变成自己的 Skill。
怎么研究一个陌生领域。
怎么判断一个选题值不值得写。
怎么把一个粗糙项目包装成能发布的作品。
怎么审校一篇文章，让它不像AI写的。
这些事，如果你每次都临时问，那它只是一次对话。
但如果你把过程沉淀下来，写成可复用流程，加上输入输出、失败处理、验收标准，它就变成了你的工作资产。
这也是我对这篇文章最大的二次理解：
未来不是谁收藏的AI工具最多，谁就最厉害。
而是谁能把自己的经验，变成可以被Agent稳定调用的工作方式。
这件事听起来不酷。
但它很值钱。
因为模型会换，工具会换，平台会换。
可你打磨出来的判断标准、工作流和验收方法，会一直跟着你。
如果你现在已经有一个自己常用的Prompt，别急着再收藏新工具。
先问它六个问题：
谁会用？
为什么装？
怎么触发？
交付什么？
比同类强在哪？
怎么证明？
答清楚了，再去补README、录GIF、做测试Prompt。
到那一步，它就不只是一个Prompt了。
它会慢慢变成你自己的手艺。
