前阵子上线 Oil UI 与付费版 Oil UI Pro 时，我完整跑通了一套付费 Skill 的线上商业化链路。

目前社区里围绕 Skill 的变现大致有两种常见做法：一种是把 Skill 完全开源，靠社群或周边服务变现；另一种是在私域里直接售卖 Skill 压缩包，靠人工一对一收款和发文件，不仅交付繁琐，往往还得靠较高的客单价来覆盖人工成本。我自己选择的是第三种路径——按照标准线上 SaaS 产品的逻辑，搭建一套全自动的在线展示、购买认证、CLI 安装与持续更新体系。这篇文章就把整套技术方案从头到尾拆解一遍。

获客与展示：开源版体验引流 + 独立官网转化

要把一个 Skill 卖出去，首先得让潜在用户看到它能做出什么效果。在这件事上我采用了“GitHub 开源版 + 独立官方网站”的双轨组合。

开源版放在 GitHub 上，本质上是付费版能力的一部分下放，同时直接充当了产品的免费体验版。用户把开源版装进自己的 Agent 试过之后，如果觉得设计效果确实有明显提升，自然会对完整版产生预期；这样付费版就不需要再去设计复杂的“免费试用几次”逻辑。在开源版的提示词里也可以设置合理的路由提示：当用户明确要求执行某项只有 Pro 版才具备的功能时，顺势提示可以升级到 Pro 版本。

但光有 GitHub 仓库还不够。仓库的 README 里通常只能放几张静态宣传图，尤其对于设计类 Skill，用户很难单凭几张截图下决心付款。因此我专门做了一个作品画廊网站，把不同模型配合这套 Skill 生成的几十个真实交互页面摆出来供人直接预览体验；同时，这个网站也承担了后续账号登录、收款和 CLI 授权的后端职责。此外，如果后续想找同领域的创作者合作推广，也可以直接利用 Stripe 自带的优惠码功能做分销追踪。

开源版与 Pro 版的功能切分及自动化构建

同时维护开源版和付费版时，最怕两边代码手动改乱。

在功能边界上，我的划分标准很清晰：开源版提供从 0 到 1 新建界面所需的绝大部分设计能力，能够独立跑通一类完整任务；而 Pro 版则保留“基于已有产品设计规范继续改版迭代 UI/UX”的深度洞察与复杂卡片模板。这样不仅用户容易理解两者的差别，后续我让 AI Agent 协助开发新特性时，Agent 也能准确判断哪些内容该放进哪个版本。

在工程实现上，我并没有分叉维护两套仓库，而是以 Pro 版作为唯一完整源，通过脚本自动裁剪生成开源版。

通过 manifest.json、replacements.md 和构建脚本自动生成开源版的流程

具体流程由三个文件配合完成：

  1. 排除清单（manifest.json）：明确列出哪些 Pro 版专属的规范文件和章节不进入开源版。
  2. 文案替换表（replacements.md）：对于两个版本共用的文件，自动把提及 Pro 专属特性的句子改写成符合开源版边界的表述。
  3. 构建与自检脚本（build_lite.py）：每次发版时自动运行，从完整版裁剪出开源版；一旦发现原文匹配不上，或者开源版里残留了指向 Pro 私有文件的死链，构建就会直接报错中止。

网站基础设施、邮箱验证与收款选型

交付网站的技术栈完全照搬了轻量 SaaS 的成熟方案，整体固定成本压得很低：

  • 域名与部署：域名在 Cloudflare 购买（一年约 10 美元），这次我直接复用了个人主域名下的子域名 ui.oiloil.org，DNS 解析与发信验证都在 Cloudflare 内完成；前后端部署在 Vercel 上，日常访问量下完全处于免费额度内。
  • 邮箱登录与发信（Resend）：为了让用户在换电脑时也能拉取自己买过的 Skill，网站必须有一套账号体系。我没有接 Google 或 GitHub 第三方登录，只做了最纯粹的邮箱验证码登录。发信服务选用 Resend，它的免费额度是每月 500 封，实际运营起来不太够用，所以我订阅了每月 20 美元的套餐，并定制了带品牌头图的验证码邮件模板。

通过 Resend 发送的自定义域名登录验证码邮件

  • 数据库（Neon）：后端数据库用来记录用户的注册邮箱与付款状态。这里我选了 Neon 而非 Supabase，主要是因为 Supabase 免费版限制每个账号最多只能建 2 个免费数据库，后续如果要做更多独立产品就得开通每月约 30 美元的付费套餐；而 Neon 的免费版不限制数据库数量，只按实际计算负载计费。像 Skill 购买认证这种低频轻量请求，Neon 的免费额度完全够用。
  • 收款渠道（Stripe）：收款我接入了 Stripe（个人开发者办好香港银行卡即可完成认证开通）。Stripe 同时支持海外信用卡以及国内的支付宝、微信支付，但有一个关键限制：支付宝和微信在 Stripe 上不支持按月自动扣款的订阅制，只能走单次付费。 如果强行做成月付，国内用户每个月都要手动扫码重付一次，流失率会非常高。因此使用 Stripe 兼顾国内外用户时，最顺畅的定价形态就是一次买断制。如果完全不需要海外收款，也可以考虑国内的个人收款渠道，但收款额度变大后需要注意合规与风控边界。

用户在购买时既可以直接在网页端登录并跳转到 Stripe 结账，也可以在还没付款时直接把安装命令发给本地 AI Agent——CLI 检测到账号尚未购买后，会在终端里直接把 Stripe 支付链接返回给 Agent，让用户点击付款，全程在对话流里闭环。

用自研 CLI 打通私有仓库鉴权与多 Agent 安装

为什么交付一个付费 Skill 还需要专门写一个开源的 oil-cli？因为付费版的文件保存在 GitHub 私有仓库的 Release 里，普通用户没有仓库权限，必须先校验购买身份才能拉取文件。

Oil CLI 的设备码浏览器确认与私有仓库安装流程

当用户在 Agent 里执行 npx github:oil-oil/oil-cli install oil-ui-pro 时，CLI 会按四个步骤完成交付：

  1. 发起设备码登录：由于 CLI 运行在本地终端里，不能直接共享浏览器的 Cookie，它会先向网站后端申请一个短设备码（例如 KDQW-7RTF），并引导用户在浏览器打开 https://ui.oiloil.org/device。
  2. 浏览器确认授权：用户在已经登录的网页端核对设备码并点击“允许”，机制和 GitHub CLI 的终端登录一致。
  3. 保存本地令牌：授权通过后，CLI 拿到专属令牌并保存在本机配置里，后续操作无需重复登录。
  4. 服务端代取与本地软链安装：网站后端核对用户确有购买记录后，用服务端的只读令牌从私有仓库 Release 拉取安装包下发（用户始终接触不到私有仓库本身的权限）；CLI 校验 SHA-256 签名无误后，自动扫描本机已安装的各类 AI Agent 目录，在本地只保留一份实体文件，再通过符号链接共享给不同 Agent。如果用户在无浏览器的服务器或 CI 环境中使用，也可以在网页账户里手动生成一个 Token，通过环境变量 OIL_TOKEN 传给 CLI。

版本管理与克制的每日更新提醒

正如我在上一篇上线复盘里提到的，明文 Skill 防君子不防小人，买家把本地目录打包分享给别人随时都能做到。但付费 Skill 真正的核心价值在于高频迭代——比如这两天我已经连续发了十几个小版本（录制视频时已迭代到 0.16.5），静态拷走的文件很快就会落后于最新版本。

为了让买过正版的用户无感用上新特性，我在发版端用脚本将构建好的开源版与 Pro 版自动同步到各自 GitHub 仓库的 Release，并在网站后端提供了一个公开的只读版本列表接口 /api/store/versions。

Skill 加载时的 check_update 版本检查与非强制提醒流程

在客户端，Skill 内部挂载了一个轻量的 check_update 脚本。每次 Agent 加载使用这个 Skill 时，脚本会请求 /api/store/versions 接口比对版本号（最多每 10 分钟联网检查一次，超过 2 秒未响应直接跳过，绝不阻塞主任务）。

这里我特意做了克制的设计：即便检测到有新版本，脚本也不会让 Agent 自动覆盖更新，而是先照常干完用户交代的设计任务，只在回复末尾顺带提一句“发现新版本及更新命令”，且同一提示每天最多出现一次，避免无意义的提示词污染 Agent 上下文。毕竟提示词工程没有绝对的“新版一定全面优于旧版”，如果用户对当前版本的产出风格非常满意，完全可以选择留在当前版本；只有当用户主动跟 Agent 说“更新”时，才会调用 CLI 完成下载、校验与替换。

把商业化洞察沉淀进 oil-skill-creator

以上这套从免费版与付费版边界切分、双版本自动构建脚本，到独立网站登录收款、CLI 设备码交付与版本更新通知的完整方案，我已经全部整理补充进了开源的 oil-skill-creator 中。

如果你手头也在打磨自己的 Skill，希望把它做成可以持续迭代、在线收款并自动交付的商业化产品，可以直接安装 oil-skill-creator，让 AI Agent 结合你项目的实际情况，帮你规划免费与付费的分界线以及配套的交付架构。