一个被误解的核心事实
很多人以为 OpenClaw 是一个"AI 助手"——你问它问题,它给你答案。
它确实能回答问题。但如果你只把它当问答机器,你浪费了它 90% 的能力。
OpenClaw 的本质是一个 Skill 执行引擎。它最强的地方不是"知道什么",而是"能做什么"——找到对应的 Skill,执行它,把结果交给你。
那 Skill 是什么?
SKILL.md 是入口——它告诉 AI 这个能力怎么用。但真正决定 Skill 能做多少事的,是背后的脚本、命令和 API 调用。
Skill = 说明书 + 可执行代码。说明书让 AI 理解意图,代码让意图落地。
第一个真相:Vibe Coding 让不会编程的人也能构建 Skill
"我不会写代码"不再是障碍
看一个真实场景。我想让 AI 帮我自动运营小红书:从数据库取文章 → 生成图片 → 登录发布。
传统方式?你需要会 Python、会数据库操作、会浏览器自动化、会调 API——至少两年编程经验才能搞定。
Vibe Coding 方式?你只需要会说人话:
从数据库连接到浏览器操控,全程我没写过一行代码。但最终产出了一个完整的自动化 Skill——下次只需要一行命令就能跑完全流程。
Vibe Coding 的本质:你提供意图和判断,AI 提供代码和执行。
但这不是"无脑用 AI"
关键区别在于:Vibe Coding 不是让 AI 替你思考,而是你用自然语言引导 AI 构建能力。
整个过程中,我做的判断包括:
这些判断不需要编程知识,需要的是对自己需求的清晰理解。
你不需要知道 Python 怎么写、API 怎么调、浏览器怎么操控。你只需要知道:
Vibe Coding 把"会编程"的门槛降到了"会表达需求"。
第二个真相:CLI 是 OpenClaw 的原生语言
为什么 Skill 要写成 CLI 而不是 GUI
很多人觉得 CLI(命令行)是"程序员的东西",普通人用不着。
但在 OpenClaw 的世界里,CLI 不是给你用的——是给 AI 用的。
想一下 AI 怎么工作:它读取文本、生成文本、执行文本命令。
CLI 命令就是文本:
AI 天生就能理解、生成、执行这些命令。
GUI 呢?"点击左上角的蓝色按钮"、"在第三个标签页找到上传框"——AI 需要先"看到"界面,再"找到"元素,再"模拟"点击。每一步都可能出错。
CLI 是 AI 的母语,GUI 是 AI 的外语。
一个真实对比
我的小红书发布链路中,浏览器操控用的是 agent-browser——一个 CLI 工具:
每一步都是一条命令,输入输出都是纯文本。AI 读取元素列表,选择要操作的元素,生成执行命令——整个过程就是文本处理。
如果换成传统方式?AI 需要截图 → 识别图像 → 猜测按钮位置 → 模拟鼠标点击。换个分辨率、换个浏览器、换个操作系统,可能就全崩了。
CLI 让 Skill 可组合
更重要的是,CLI 工具天然可以串联:
每个环节都是独立的命令,像乐高积木一样拼在一起。
GUI 工具也能串联——通过可视化工作流(n8n、Make、ComfyUI 那种拖拽连线的方式)。但门槛不低:你需要理解每个节点的输入输出格式、配置认证信息、处理数据转换、调试失败节点。本质上还是在"编程",只是换了个界面。
而 CLI 的组合几乎是零成本的:上一个命令的输出就是下一个命令的输入,一行管道符搞定。更关键的是——AI 天然会组合文本命令,但不会拖拽连线。
在 OpenClaw 里,CLI 不是技术选择,是架构基础。 正因为 Skill 的执行单元是 CLI 命令,AI 才能理解它、执行它、组合它。
你不需要会 CLI,你只需要让 AI 构建 CLI
这里有一个认知上的转折:
CLI 是给 AI 用的,不是给你用的。你不需要记住任何命令。
你只需要说:
"帮我发布这些图片到小红书"
AI 会自动调用对应的 CLI 命令。但前提是——这些 CLI 命令必须存在。
谁来创建它们?Vibe Coding。
你通过对话帮 AI 构建 CLI 工具 → AI 以后就能自动调用这些工具。
这就是 Vibe Coding 和 CLI 的关系:Vibe Coding 是生产 CLI 工具的过程,CLI 是 OpenClaw 执行能力的载体。
实战:一个 Skill 是怎么"长"出来的
以小红书自动运营 Skill 为例。这不是一次对话搞定的——它跨越了 3 天、多个会话、几十次迭代。但全程没写过一行代码。
Day 1(3月6日):从零开始,先跑通一个点
第一天结束:能从数据库导出文章、能生成图片。花了大半天,中间踩了 SSL 证书、base64 解析、API 格式等一堆坑。
但你的参与就是:说目标 → 看结果 → 说"为什么失败"。
Day 2(3月6日晚):加上 LLM,让观点提取不再写死
你的判断:"硬编码不行,要通用"——这不需要编程知识,只需要对产品的理解。
Day 3 上午(3月9日):加上发布能力——真正的硬仗开始了
这一段有十几次迭代。每次都是"跑 → 失败 → 你说哪里不对 → AI 去修"。你不需要知道什么是 Playwright、什么是 agent-browser、什么是 DOM 渲染——你只需要看到"标题没填上"就说"标题没填上"。
Day 3 下午(3月9日):从"能用"到"好用"
回头看:这像"五轮对话"吗?
不像。真实过程是:
- 中间经历了:工具迁移(Playwright → agent-browser)、架构重构(单体 → 三模块)、环境修复(SSL、二进制架构、数据库名)、交互优化(等待时间、换行、自动发布)
- 最终产出了 3 个独立 Skill、15+ 个 CLI 命令、完整的风控体系
但全程,你没写过一行代码。你做的事情是:
- 做出判断:"发布应该独立"、"旧文件要清理"、"300 字够了"
这些判断来自常识、使用感受和业务理解——不来自编程经验。
最终产出
这些 CLI 命令永久保存在 Skill 目录里。以后不管是你自己用、还是让 AI 自动执行、还是设置定时任务——都只需要调用这些命令。
Vibe Coding 不是一次对话的魔法,是持续对话的积累。每次迭代都让 Skill 更强一点,直到它真正好用。
为什么这两件事必须一起理解
少了 Vibe Coding,你没有能力创建 Skill——除非你本身是程序员。
少了 CLI,OpenClaw 没法高效执行——GUI 工具 AI 操控不了。
Vibe Coding 降低了创建 Skill 的门槛,CLI 降低了 AI 执行 Skill 的门槛。两个门槛同时降低,普通人才真正拥有了自动化能力。
整个过程的核心洞察
给 OpenClaw 用户的建议
1. 不要学编程,学表达
Vibe Coding 不要求你会写代码,但要求你能说清楚:
表达越精确,AI 产出的 Skill 越好用。
2. 把"我想要"换成"帮我做"
❌ "我想要一个能发布小红书的工具"
✅ "帮我把这 7 张图片发布到小红书,标题用文件名"
前者是需求描述,后者是执行指令。OpenClaw 擅长的是执行,不是需求分析。
3. 接受"先跑再说"
不需要一开始就完美。第一次可能失败,第二次可能有 bug,第三次就好了。
每次失败都会让 Skill 变得更健壮:
异常处理不是设计出来的,是踩坑踩出来的。
4. 把经验写进记忆
每次发现"下次应该这样做",就告诉 AI 写下来:
"我输入的内容是第一优先级"
"安装软件前先检查本地是否已存在"
这些规则会成为 AI 的长期记忆。下次它不会再犯同样的错。
Vibe 不是玄学,是被持久化的协作默契。
结语
OpenClaw 的设计哲学很简单:
让普通人拥有自动化能力。
Vibe Coding 解决了"谁来写代码"的问题——答案是 AI。
CLI 解决了"AI 怎么执行"的问题——答案是文本命令。
两者结合,一个不会编程的人也能构建出:从数据库取文章 → 生成图片 → 自动登录 → 一键发布的完整链路。
OpenClaw 是舞台,Vibe Coding 是舞蹈,CLI 是音乐。
舞台再好,没有音乐和舞蹈,也只是一块空地。