title: " 鲁班Skill升级 | Prompt产品化" category: 人工智能 tags:

这两天Claude Fable 5的开放窗口和可用状态变化很快。Anthropic官方页面在6月12日更新过访问暂停说明，所以具体能不能用、什么时候恢复，都应该以官方页面为准。对普通开发者来说，更值得沉淀的不是“某个模型窗口期里闲聊了几轮”，而是把高能力模型跑通过的复杂工作流保存下来，变成以后还能复用的Skill。

这篇就借开源「鲁班」Skill这个案例，聊一个更长期的主题：怎么把一个本地能用的Skill，升级成别人愿意安装、看得懂、跑得通、还愿意分享的公共资产。

1. Skill不是神秘脚本，而是可复用工作方式

很多人第一次听到Skill，会以为它必须包含复杂脚本、MCP、浏览器自动化、数据爬取和一整套工程工具。确实，有些Skill需要这些东西，但大量真正好用的Skill，核心其实是一份写得足够好的SKILL.md。

好的Skill至少要讲清楚五件事：

也就是说，Skill不是一次提问，而是一套可复制的行动说明。它把“我每次都要和模型解释一遍的经验”，变成了模型可以反复调用的工作方式。

鲁班Skill的意义就在这里：它不是做一个具体内容生成工具，而是做一个“升级Skill的Skill”。它的目标不是把文案润色得更漂亮，而是把一个粗糙的私用Skill，打磨成能公开发布的产品。

2. 为什么“能用”和“能发布”差这么远

很多开发者手里都有一堆私用Skill。自己用的时候没问题，因为背景都在自己脑子里：这个Skill什么时候用、哪里容易错、跑出来算不算成功、需要哪些前置文件，自己都知道。

但一旦要开源，问题就出来了：

这就是“本地能跑”和“公开可用”之间的差距。前者像个人笔记，后者像产品说明书。

鲁班Skill把这个过程拆成了一套工匠式流程：先验料，再访行，再过尺，再慢刨，最后回炉。听起来有点江湖味，但背后其实是很工程化的产品打磨逻辑。

3. 第一步：验料，先证明这个Skill值得存在

大部分Skill的问题不是写得不够好，而是没有想清楚为什么值得存在。

鲁班工作流的第一步，是先挑战前提：

这个Skill解决的真实用户问题成立吗？
用户为什么要安装它，而不是临时问Agent一句？
它的独特性来自方法论、脚本资产、数据、工作流，还是展示效果？
它有没有一句话能讲出去的传播钩子？

这一步很像产品经理做需求评审。比如一个“帮我写周报”的Skill，如果只是把日常提示词包装了一下，安装理由就很弱。用户完全可以临时问模型。

但如果它能读取团队固定模板、自动区分项目进度和风险、生成可提交到飞书或Notion的结构化周报，并且有失败处理规则，那它就有了安装价值。

可以用下面这张表做初筛：

维度 不合格表现 合格表现
真实问题 只是作者自己觉得有趣 目标用户经常重复做这件事
安装理由 临时问一句也能解决 安装后能稳定复用工作流
独特性 只有泛泛提示词 有方法论、数据、脚本或验证资产
可传播 一句话说不清 10秒内知道它能干嘛
可验证 只说“效果更好” 有输出样例、测试prompt或前后对比

如果这张表前两项都答不上来，先别急着写README。这个Skill可能还没到发布阶段。

4. 第二步：访行，去看同类为什么被安装

很多Agent帮你改Skill时，会直接在当前文档里润色。鲁班的做法更像做市场调研：先找同行。

可以把搜索分成三组：

功能词：它做什么，例如 news radar、skill polish、prompt library
人群词：谁会用，例如 developer、writer、researcher、designer
形态词：它是什么，例如 skill、agent skill、SKILL.md、Claude skill

再分三路搜索：

这一步不是为了抄功能，而是为了回答两个问题：

比如鲁班案例里，一个有价值的判断是：有些项目表面看是“AI新闻站”，但真正稀缺的资产可能不是页面，而是公开、稳定、可fork、可curl的静态数据接口。这个判断就从“再加页面功能”，转向了“把开放数据接口讲清楚”。

这就是生态位判断。它比多加一个按钮更重要。

5. 第三步：横纵分析，找准升级方向

鲁班工作流里有一个很关键的动作：同时做纵向和横向分析。

纵向看这个Skill从哪里来：

它最初解决什么具体痛点？
它现在是工具、方法论、工作流、风格迁移，还是自动化系统？
它从私用变成公开可用，还缺哪一步？
下一版最应该强化功能、展示、安装、适配，还是验证？

横向看同类为什么站得住：

命名是否有记忆点？
一句话定位是否清楚？
安装路径是否足够短？
README首屏有没有可信证据？
跑完有没有可见产物？
安全边界有没有写明？
是否兼容多个Agent runtime？
有没有故事感，而不只是功能列表？

纵向回答“我是谁，我要去哪”；横向回答“别人为什么愿意选我”。两个方向交叉，才能决定真正要抢的生态位。

很多Skill发布失败，不是因为没有功能，而是生态位模糊。读者看完只知道“这是一个能让AI做事的东西”，但不知道为什么非它不可。

6. 第四步：过尺，用评分表找最该打磨的面

Skill升级不能只靠感觉。鲁班Skill把体检拆成多个维度，其中最重要的不是文案，而是实测表现。

一份可复用的评分表可以这样设计：

维度 看什么 权重建议
Frontmatter与触发条件 名称、描述、触发词是否准确 10%
工作流清晰度 步骤是否可执行、边界是否明确 15%
失败模式 常见异常是否有处理策略 10%
检查点 是否有中途确认和停止条件 10%
可执行具体性 是否能直接指导Agent行动 15%
资源整合度 是否包含脚本、示例、数据或参考 10%
README展示 首屏、GIF、截图、安装路径 10%
安全边界 权限、删除、外部请求、隐私说明 10%
实测表现 测试prompt、前后对比、真实产物 20%

这里最该强调的是最后一项：实测表现。

一个Skill写得再漂亮，如果没有测试prompt、没有输出样例、没有前后对比，它就很难证明自己真的有用。公开Skill不是只给模型看的，也是给人看的。人需要信任证据。

7. 第五步：慢刨，每轮只改一个主要变量

鲁班Skill借鉴了SkillOpt一类思路：把Skill文档看成一个可以迭代优化的状态，但每次修改要有边界。

最忌讳的是一轮里同时做十件事：

这样最后即使效果变好，你也不知道是哪一步起作用。

更稳的做法是：

第1轮：只修触发词和适用范围
第2轮：只补失败模式
第3轮：只优化README首屏
第4轮：只增加测试prompt和样例输出
第5轮：只减少安装摩擦

每一轮都要过验证门：

至少2个典型测试prompt输出优于原版
README首屏能在10秒内说明价值
安装路径没有新增明显摩擦
权限范围没有变得更危险

这就把“写Prompt”变成了“做实验”。你不再是凭感觉润色，而是在做可回滚、可比较、可验证的优化。

8. 第六步：摆活，把价值展示出来

很多Skill其实有价值，但展示太弱。README首屏全是抽象概念，没有截图，没有GIF，没有真实输出，用户自然不会安装。

摆活不是包装过度，而是把“它能交付什么”放到读者眼前。

建议README首屏至少包含：

比如一个新闻雷达类Skill，不要只写“聚合AI新闻”。更好的展示是：

输入：帮我找今天最值得关注的AI产品更新
输出：带评分、来源、时间线和热点模式的可读报告
附加产物：静态JSON接口、HTML页面、可复制摘要

用户不是因为功能列表安装Skill，而是因为他看到了自己能拿到的结果。

9. 用4SAPI做鲁班工作流的多模型版本

Claude Fable 5这种高能力模型很适合做一次深度打磨，但它的可用窗口、容量和成本都可能变化。更长期的办法，是把鲁班工作流拆成多个阶段，再通过4SAPI这类大模型API中转站接入不同模型。

可以这样分工：

阶段 任务 推荐模型档位
验料 判断问题是否成立、生态位是否清楚 强推理模型
访行 搜索同类、整理竞品表 联网搜索或长上下文模型
横纵分析 提炼差异化定位 强推理模型
过尺 按评分表做体检 稳定主力模型
慢刨 小步改写SKILL.md 性价比模型
摆活 README、GIF脚本、showcase 多模态或代码模型
回炉 跑测试prompt、比较前后效果 主力模型加人工验收

这样做的好处是，不必每一步都用最贵模型。深度判断交给强模型，批量改写交给性价比模型，展示素材和脚本交给代码模型，最后再用强模型复核。

在4SAPI里可以给不同阶段建不同Key或不同模型路由，例如：

skill-research-key：用于访行和资料整理
skill-polish-key：用于慢刨和文档改写
skill-review-key：用于最终验收和风险检查

这样既能控制成本，也能把每一步的Token消耗和结果质量记录下来。

10. 一个可直接套用的鲁班式升级模板

如果你手里已经有一个SKILL.md，可以把下面这段当成升级提示词：

你是一个Skill升级顾问。
目标：把当前Skill从“本地能用”升级为“别人愿意安装、能跑通、能验证”的公开Skill。

请按以下步骤工作：
1. 验料：判断真实问题、目标用户、安装理由、独特性和传播钩子。
2. 访行：列出需要调研的同类Skill或项目，并说明对标维度。
3. 横纵分析：纵向看它从哪里来、下一版该往哪里走；横向看同类凭什么被安装。
4. 过尺：按Frontmatter、触发条件、工作流、失败模式、检查点、可执行性、README、实测表现评分。
5. 慢刨：每轮只提出一个主要修改方向，不要一次重写全部内容。
6. 验证：给出至少2个测试prompt、预期输出和通过标准。
7. 摆活：给出README首屏结构、GIF或截图建议、安装路径和安全边界说明。

限制：
- 不要为了好看而扩大功能。
- 不要新增危险权限。
- 如果安装理由不成立，请直接指出，不要硬改。
- 每个建议都要说明它提升的是理解、安装、传播、验证还是进化。

跑完以后，别急着直接接受全部修改。先看它有没有回答这六个问题：

这六个问题答清楚，再去写README、录GIF、补测试prompt，成功率会高很多。

11. 风险提醒：别让“打磨”变成过度包装

鲁班式工作流很有用，但也有边界。

第一，不要把没有真实价值的Skill包装成“产品”。如果安装理由不成立，应该回炉重想，而不是继续美化README。

第二，不要为了展示效果扩大权限。比如自动录屏、自动访问外部网站、自动发布内容，都要明确用户确认和安全边界。

第三，不要把竞品调研变成照抄。访行的目标是理解生态位，不是复制别人的命名、README结构和卖点。

第四，不要让模型一次改太多。Skill升级最好像代码重构一样，小步提交、小步验证。

12. 总结

Claude Fable 5这类高能力模型的窗口期会变化，但它带来的一个启发很稳定：普通人真正应该沉淀的，不是“我今天试了哪个模型”，而是“我把哪件反复做的事变成了自己的Skill”。

鲁班Skill把这件事讲得很清楚：一个好Skill，不只是提示词写得顺，而是有定位、有触发、有边界、有验证、有展示、有进化路径。

如果你正在用Claude Code、OpenClaw、Codex或其他Agent工具，建议找一个已经能用但还没发布的SKILL.md，按“验料、访行、横纵、过尺、慢刨、摆活、回炉”走一遍。哪怕最后不公开，它也会让你的私人工具库更像资产，而不是一堆散落的提示词。

参考资料：