Source: https://x.com/kasong2048/status/2075508272946450880
Author: kasong2048
Date: 2026-07-14
| title | author | content | url | | --- | --- | --- | --- | | AI Native CLI 会是一种新商业模式 | kasong2048 | 对于泛知识付费领域的 KOL，Skill 是一种非常好的获客、建立影响力、提高收入 的工具，因为：
- 获客、建立影响力：一个凝聚领域SOP 的 Skill，如果真的好用，很容易在该领域指数传播，进而为作者带来曝光
- 提高收入：Skill 可以将标品包装成非标品（因为融入 KOL 自身方法论），或者降低 非标品的交付成本，进而提高收入
但 Skill 本身并不能成为一种商业模式，因为他的复制成本为 0。这就造成两种极端情况：
1. 一些 KOL 把好用的 Skill 藏着掖着自用
2. 一些 KOL 将 Skill 完全开源作为建立影响力、提高收入的工具
两种情况都不是最优解，前者没壁垒，后者赚钱效率低。
只有包装成 AI 解决方案，才能兼顾 壁垒 & 赚钱效率。
AI 解决方案
一个 AI 解决方案，通常包含 3 部分：
1. Agent：通常是 codex、pi、cc
2. workflow：skill 编排的SOP
3. 领域私有知识
前两者都没壁垒，壁垒在于 不断积累的领域私有知识。
问题的关键在于 执行 AI 解决方案的容器。你确实可以开发一个 网站/App/小程序 来执行你的方案，再将 Skill 来的流量导入容器里变现。
但是，这个引流路径卡点太多。
你的流量来自于 Skill，这些“使用 Skill 的用户”可能是在 豆包、workbuddy 里用的，让他们迁移到 外部应用 损耗是很大的。
最理想的状态是：用户在哪用 Skill 就在哪用你的应用，“从免费Skill 到 付费应用”是同一容器下的升阶行为。
能实现这种商业模式的容器，就是 AI Native CLI
AI Native CLI
我们平时用鼠标点击的界面叫 GUI（Graphical User Interface，图形用户界面）
CLI 是相对于 GUI 的概念， Command-Line Interface（命令行界面），也就是靠打字输入指令来操作的窗口。
举个例子：你要把“我的照片”目录内容拷贝到备份盘，CLI 操作是：
cp -r 我的照片 备份盘/
CLI 通常是面向人类开发者的，AI Native CLI 则指 —— 给 AI 使用的 CLI。
比如飞书CLI，你可以让 agent 使用 飞书CLI 操作你的飞书。
Human Native 和 AI Native CLI 的一些区别：
- 前者要开发者自己看文档学习后使用，后者会内置 Skill，教 Agent 在不同场景下该怎么操作
- 前者出错后通常只会报错，后者出错后会给 Agent 修复的提示，Agent 可以自己尝试修复问题并继续执行
总之，给到 AI 一个 AI Native CLI，他会自己学不同场景该怎么用（当然，背后是为不同场景 SOP 设计 Skill）。
AI Native CLI 商业模式
在任何“能使用 Skill”的载体中，都能使用 AI Native CLI。比如：飞书CLI 的安装提示词：
AI Native CLI 可以是一个包含完整 登录/鉴权/CRUD/付费 的应用，这意味着：他能区分 免费/付费用户，并区别对待。
举例，你是一名 心理咨询师，提供一个 Skill 帮用户做基础的心理疏导：
- 免费用户：基于标准 SOP 返回结果
- 付费用户：基于用户场景的私有 SOP + 相似患者案例数据 给到更精准的结果
甚至 可以进一步 梳理用户的情况后 推荐 1v1 咨询服务，相当于建立了阶梯服务：
免费 Skill 用户 -> 付费 Skill 用户 -> 咨询服务
且这个阶梯是完全自动化的升阶。
总结
基于：
1. 会有越来越多 泛知识付费领域的 KOL 开始写 Skill
2. AI Native CLI 可以在 SKill 内部完成商业闭环
得出结论：
AI Native CLI 会是一种新商业模式。
最后，对于那些把好用 Skill 藏着掖着的 KOL，我劝一句：Skill 是马太效应非常强的工具。你同领域要是冒出个好用的 Skill，基本没你啥事儿了。
你说我比他更好用啊，然后赶紧开源。 别人看你好用，第二天就把你的理念抄过去。
复制粘贴文本有成本么？回答我！ | https://x.com/kasong2048/status/2075508272946450880 |