企业官网建设流程全解析

把OpenClaw装好、配好模型接口、跑通第一轮对话的那天晚上，我一度觉得“行了，我拥有了一个能自己干活的AI”。然后我让它做了一件特别正经的事：“把项目仓库里所有TODO标记整理成一份按模块分类的报告”。它确实给了我一篇结构工整的Markdown，甚至连优先级都标好了。可紧接着我让它“把这十几张截图里的人物头像抠出来，按性别和年龄段分到不同文件夹”，它回了我一句：“这超出了我的调用范围，建议借助第三方图像处理工具。”

从“看到曙光了”到“果然还是个玩具”，只隔了不到十分钟。

后来我在Mixlab的AI编程专项里做了一次关于Skills的复盘，核心就一个观点：OpenClaw能不能成为真正干活的工具，分水岭不在模型强不强，而在你有没有自己的Skills。这篇文章会把那次复盘里最关键的思考、踩过的坑、实际可复现的写法都摊开来讲，适合刚把OpenClaw跑起来正愁“然后呢”的人，也适合已经写过一两个Skills但总觉得差口气的开发者。

1. 先想明白一件事：OpenClaw到底是“工具”还是“框架”

很多人第一次用OpenClaw时都会犯一个定位错误：把它当成一个“开箱即用的AI员工”。但实际上，它更像一块主机板——插上CPU（模型）、接上电源（API）、连上显示器（终端界面）之后，它能开机、能显示BIOS画面、能跑个内存自检，但你指望它直接帮你打开Word写方案，那是不可能的。主机板需要外设，OpenClaw需要Skills。

1.1 没有Skills的OpenClaw，本质上是个“带记忆的对话机器人”

先给OpenClaw一个公允的定义：它是一个开源的Agent骨架，负责连接大模型、管理多轮对话、容纳外部工具调用。它自己带了一小套基础能力，比如读文件、写文件、执行终端命令、维护会话上下文。这些能力让OpenClaw显得“能干活”——因为你可以让它“看看这个目录里都有什么文件”或者“把这份日志的报错行提取出来”，它确实能做。

但如果只靠这些通用能力，它能交付的东西非常有限。原因在于通用能力和专用交付之间存在一条鸿沟：读文件谁都会，但从一堆杂乱文件里整理出一份符合你团队规范的测试报告，需要的是“知道你团队规范是什么”的知识。执行终端命令谁都会，但从一份ROS 2的Gazebo仿真日志中定位某个节点的偶发崩溃，需要的是“知道这个节点叫什么、崩溃特征是什么、日志里哪几行值得关注”的经验。OpenClaw自带的通用能力只解决了“手”的问题，没有解决“怎么干”的问题。

所以我说它是个玩具，不是贬低。玩具的定义是“能演示，不能交付”。你可以在聚会上用五分钟demo一段“让AI自动整理通讯录”的效果，但你真的把一个杂乱无章的客户登记表丢给它，让它按你的字段规范批量清洗、去重、回填，并且每一条都能溯源，基本做不到。因为你要的这些操作流程，它从来没被明确教过。

1.2 Skills是把通用能力变成专用劳动力的那层“肌肉”

Skills在OpenClaw里的角色，就是把这层缺失的东西补上。简单说，Skills是一套“可复用、结构化、带指令和脚本的能力包”。一个Skills会包含一份给模型看的说明书（怎么触发、按什么步骤执行、输出要符合什么格式），以及一组实际干活的脚本或工具（执行检索、调外部API、解析文件）。

我更喜欢的类比是把OpenClaw比作插线板，模型是电，Skills是插在插线板上的电器。插线板本身只是导通电流，你不插个烧水壶，它就不能烧水；不插个充电器，它就不能给手机充电。OpenClaw给模型提供的是“电流通路”，至于这电流是让机器转起来还是让灯亮起来，完全取决于你插了什么Skills。一个只接了基础工具的OpenClaw，相当于一个只插了电源指示灯的插线板——指示灯亮了，但也仅此而已。

把“能对话”变成“会干活”，靠的正是这层肌肉。模型负责理解意图、拆解任务、调用Skills，Skills负责把模型的“指令”转成“确定的执行结果”。这层分离很关键：模型可以换，API可以换，甚至OpenClaw本身也可以换，但只要Skills还在，你的整套自动化流程就还能跑。

1.3 为什么必须是“自己的Skills”

社区里已经有不少现成的Skills仓库，有的做网页抓取，有的做图片压缩，有的做PDF解析，下载就能用。我的建议是：这些当然可以装，但你必须有一套自己的Skills。原因有三个。

第一，通用Skills解决的是“平均需求”，而你的工作里全是“特殊需求”。我最早装过一个“总结网页内容”的通用Skills，它确实能把一篇文章浓缩成三段。但我要的不是三段概括，而是“把竞品价格、参数、售后服务三块信息提取成表格，并和我们的产品做差异对比”。这种需求，通用Skills无论如何也做不到，因为它的说明书里根本不可能包含我关心的字段。

第二，自己的Skills天然长在自己的数据和工作流上。我自己写过最值钱的一个Skills，是“查本地笔记库”。它知道我的笔记软件用了什么目录结构、markdown文件里用什么样的标签体系、我习惯把项目进度记在哪个路径下。这些信息存在于我的工作习惯里，不存在于任何公开Skills库里。

第三，自己写一遍才是真正的理解。把Skills写好，本质上是在训练自己“结构化表达”。当你不得不把一个模糊的需求（“帮我整理一下资料”）翻译成精确的触发条件、执行步骤、输出模板时，你对AI编程的认知会上一个台阶。这个提升是看一百篇教程给不了的。

2. Skills的底层结构拆解：从一份SKILL.md开始

我见过不少人一上来就搜“OpenClaw Skills怎么写”，然后被各种复杂概念带偏。实际上，一个标准的Skills在结构上非常简单，核心就一个SKILL.md文件，外加若干个辅助脚本。

2.1 一个Skills的目录里到底该放什么

我在项目里用的结构是长这样的（这是社区里最通用的一种组织方式，OpenClaw和同类的Agent框架基本都兼容）：

my-skill/ ├── SKILL.md ├── scripts/ │ └── run.py └── assets/ └── template.md

其中SKILL.md是这个Skills的“大脑”，它定义了模型什么时候该用这个Skills、用了之后按什么步骤走、最终输出成什么样。scripts目录放的是实际执行的脚本，比如Python脚本、Shell脚本、Node脚本，模型会按照SKILL.md里的指示去调用这些脚本完成具体操作。assets目录是给模型参考的静态资源，比如模板、样例、配置说明，属于可选部分。

很多写过提示词的人，第一次见到SKILL.md会觉得“这不就是一个提示词文件吗”。表面看确实像，但它和提示词有个本质区别：提示词是贴在对话里的“一次性说明”，SKILL.md是挂在文件系统里的“结构化说明书”。模型会在需要的时候主动读取它，而不是靠你每次手动粘贴。它有自己的元信息（name、description），可以被索引、被发现、被程序化调度。

我见过最精简的Skills只需要一个SKILL.md文件，里面内嵌了Shell命令，连scripts目录都不需要。也见过很重的Skills，挂了十几个脚本和静态资源，做成一个小型应用。这两种都合理，取决于你要让AI干的活有多复杂。判断标准很简单：如果这个Skills只需要模型“按步骤思考然后输出”，那一个说明书就够了；如果它需要处理真实数据、调用系统接口、生成文件，那就必须把逻辑拆进脚本里。

2.2 frontmatter和正文该怎么写

SKILL.md的格式沿用了Jekyll/Hexo那一套frontmatter习惯，最前面是YAML格式的元信息块，后面是正文。我这里给一个最小可用的模板：

--- name: kb-query description: 在本地笔记库中检索关键词并返回相关内容，适用于回答涉及过往笔记、项目文档、个人知识库的问题。当用户询问“查一下我笔记里的”、或提到项目历史记录时使用。 version: 1.0.0 --- # 知识库检索 ## 触发条件 当用户需要查询本地笔记库中的既有内容时使用本Skills。 ## 执行步骤 1. 先运行 `python scripts/search.py "{关键词}"` 检索笔记库。 2. 如果返回结果为空，尝试更换同义词或更短的关键词再次检索。 3. 根据检索结果，整理出与问题最相关的3-5条片段，注明来源文件路径。 4. 用简洁的中文回答，并在末尾列出来源文件。 ## 输出格式 - 回答必须以“根据本地笔记库”开头。 - 每个要点后标注来源文件名。 - 如果检索不到任何内容，明确说“笔记库中未找到相关信息”，不要编造。

注意description这一项，它是最重要的一个字段，直接决定了模型会不会在合适的时机调用这个Skills。描述里要写清楚“什么时候用、解决什么问题、哪些说法会触发它”，而不是写“这是一个知识库检索工具”这种抽象描述。一个有经验的写法是把用户可能的说法直接列出来，比如“用户说‘我上个月记过…’或‘查一下项目A的进度’时使用”。模型对具体触发词的敏感度，远高于对抽象描述的敏感度。

正文的执行步骤有一个写作技巧：给模型足够的信息，让它知道每一步该命令是什么、结果长什么样、出错了该怎么降级。你的Skills不是给一个确定性的程序用的，而是给一个“会理解、会猜测、有时会猜错”的模型用的，所以说明书里必须包含应对异常情况的兜底方案。比如我那个知识库检索Skills就写了“结果为空时尝试同义词”，这条指令让模型在第一次检索失败后不会直接放弃，而是自己调整策略再试一次。

2.3 为什么Skills优于“提示词模板”

我做Mixlab专项时，经常被问到：“我只要把这段逻辑写进系统提示词里，效果差不多，何必单独做一个Skills？”表面上看确实差不多，但实际用下来差别很大。

最直观的例子是“翻译并润色”这件事。用提示词，你得在每次需要时把规则粘贴一遍，而且规则越长，前面对话中携带的信息越多，效果越不稳定。做成Skills之后，SKILL.md里可以把术语表路径、目标语言规范、禁止翻译的专有名词列表全部写好，再配合一个查术语的脚本，模型在执行时自动读取。这10个字的差别，实际工作流里就是“能用”和“不好用”的差别。

2.4 把“AI会犯错”当成默认值来设计

写完几个Skills之后，你会意识到一个做传统开发时不会注意的问题：你的“调用方”是一个会自己发挥的LLM。它可能漏看说明书里的一句话，可能把脚本参数顺序传错，可能在输出时格式走样。与其寄希望于模型“认真听话”，不如在设计Skills时就把容错做进去。

我的做法是三条：第一，在SKILL.md里写明“输出必须经过校验，如果校验失败请重新执行”；第二，脚本侧做双重保险，比如自己定义一个JSON输出格式，如果模型返回的结果没办法被脚本解析，就让脚本返回一个明确的错误格式，而不是静默失败；第三，凡是涉及“可能出错”的操作，比如网络请求或文件读写，都要在SKILL.md里提醒模型先检查前置条件，比如文件是否存在、目录是否可写。

这里分享一个亲测有效的小技巧：在SKILL.md里加一节“常见失败模式”，把模型最容易犯的错直接写出来，告诉它“不要怎么做”。比如在知识库检索Skills里，我写了“不要在检索结果为空时使用上个月的记忆补充答案，必须以实际检索结果为准”。加了这一条之后，幻觉率明显下降。模型不是故意编造，它只是需要更明确的边界。

3. 实操：从部署OpenClaw到跑通第一个自写Skills

讲完理论，进入真正动手的环节。这一部分我尽量按时间线来，把从零到一的过程完整复现出来。

3.1 部署：Windows、Ubuntu我踩过的坑

OpenClaw的部署在不同系统上有不同姿势，把环境搞定是第一步，也是不少人的第一个坑。

我在Windows上先试了原生安装，把Node环境和依赖装好，跑官方的一条curl安装脚本。这条脚本会做依赖检查、下载核心文件、初始化配置目录。如果你和我一样是Windows用户，强烈建议优先用WSL跑，因为Skills里大量涉及文件路径和Shell命令，WSL环境下路径和权限的处理比原生CMD底下顺滑很多。我之前在原生Windows下写了一个用Python处理文件的Skills，脚本里用了/tmp临时目录，直接因为路径不存在而报错，换到WSL之后同类问题基本消失。

Ubuntu上的安装最无脑，官方一键脚本走完，再把模型API的Key写进配置文件就行。我目前的生产环境放在一台Ubuntu的迷你主机上，24小时挂着跑定时任务，稳定性和资源占用都很让人放心。HDD机械盘上偶发IO卡顿，建议有条件的话放SSD上，Skills里如果有频繁的脚本调用，IO就是瓶颈。

安卓部署用的是Termux。具体流程是先装Termux，再通过proot-distro装一个Ubuntu容器，在容器里按Linux的方式安装OpenClaw。这事的可行性没有问题，Termux跑OpenClaw是走得通的，只是当你在Skills里跑模型或调脚本时，手机CPU会被顶到接近满载。我的结论是：手机端适合做“远程指挥中心”——用来查看在别处运行的OpenClaw实例的状态、下发简单指令；不适合在本地跑重型Skills任务。

无论哪个平台，装完之后第一件事不是急着写Skills，而是把OpenClaw自带的方向跑一遍，确保“对话-任务-输出”这个链路是完整的：让OpenClaw先做一件特别简单的事（“列出当前目录的文件”），然后是一件稍微复杂的事（“用Python生成一个1到100的质数列表”），确认工具调用链路、脚本执行能力都正常之后再开始自己的Skills开发。

3.2 第一个Skills：让OpenClaw真正会“查我的笔记”

我写的第一个正经Skills是“查本地笔记库”。起因是做了三四周的AI项目后，笔记散落在几十个markdown文件里，每次想找“当时那个机器人项目的调试记录”，我得自己一层层翻目录。当时就想，能不能让OpenClaw替我做这件事。

目录结构是这样：

kb-query/ ├── SKILL.md ├── scripts/ │ └── search.py └── assets/ └── field_guide.md

search.py的核心逻辑是遍历笔记目录下所有markdown文件，用关键词做简单匹配，返回文件名和命中的上下文片段。这里用的是最简单的“字符串包含”匹配，没有上向量检索，因为第一步要打通的是链路而非效果。SKILL.md按前面模板填写，把触发条件、执行步骤和输出格式都写清楚。

第一次测试，我对OpenClaw说“帮我查一下我笔记里关于Ollama部署的内容”。它正确识别出kb-query这个Skills，执行了python scripts/search.py "Ollama部署"，返回了三段命中内容，并按SKILL.md要求注明了来源文件。那一刻我确实有些兴奋：OpenClaw第一次不再是“和我聊天的AI”，而变成了“能访问我的记忆库、能按我的格式汇报工作的助理”。

如果你照着做，我提醒你注意脚本输出格式的设计。search.py打印出来的结构是：

{"ok": true, "hits": [{"file": "xxx.md", "line": 12, "context": "..."}]}

脚本的stdout被模型读取，模型根据输出决定如何呈现给用户。所以脚本的输出要在两个能力上平衡：一方面机器可读（结构化，方便模型快速提取），另一方面包含足够的上下文（让模型在不重新打开文件的情况下就能回答）。脚本输出别搞得太花哨，输出那个JSON，再由模型组织成自然语言，是最稳的。

3.3 第二个Skills：前端开发场景的落地示例

前端开发是我日常里需求最多的场景，所以第二个正经Skills就做了“前端页面生成”。这个Skills的适用场景是：给一个设计稿截图或者一个线框描述，让OpenClaw生成初步可用的React组件代码。

SKILL.md的执行步骤是：先看截图，如果没有截图就问用户要，或者让用户粘贴URL。然后识别布局结构（Header、导航、卡片区、表格、弹窗等），选择性地读取当前项目已有的tailwind.config和组件风格参考，最后生成组件代码文件。

脚本部分用了两部分：用Python读项目配置（tailwind.config.js、package.json）、检查目标输出目录是否存在。真正的组件代码生成靠模型自己完成，脚本只负责把代码安全地写到正确的目录。

实际操作中我让OpenClaw在已有的React项目里跑这个Skills，输入是一张简单的后台管理页截图，它输出了一个包含侧边栏和顶部导航的Dashboard组件，风格和我项目里已有的配色基本一致，并且能直接在dev环境跑起来。这个过程把“识别界面-对齐项目规范-输出代码-落盘”完整跑通了。

前端方向之所以经典、适合做Skills，因为它的约束足够清楚：设计稿是输入、代码是输出、风格规范是边界。模型不需要在“用户到底想要什么”上做太多猜测。

3.4 让多个Skills协作跑一个复杂任务

单个Skills能用之后，你会开始想让多个Skills协作。OpenClaw的模型调度天然具备这种能力：它会根据任务描述，先后调用多个Skills来完成一个完整的流程。

我在一次实战中完整验证过：让OpenClaw基于我笔记里的“上季度复盘”文档生成一份季度总结PPT大纲，并把所有行动项提取出来加入待办清单。当时它连续调用了三个Skills：kb-query检索笔记、doc-summary生成摘要、todo-manager写入待办文件，中间没有一次人工干预。真正的多Skills协作就是这么发生的，模型自己决定“第一步查资料，第二步总结，第三步写入”。

这里需要注意的坑是，模型不会主动记住“上次那个Skills我顺便用过了”。如果你希望它在多Skills场景里不混乱，必须在SKILL.md里写明“这个Skills的输出会作为另一个Skills的输入，此时不要重复生成，直接传递结果”。我最初没有写这句，结果模型在调用完doc-summary之后，又自作主张地把摘要重新组织了一遍再传给todo-manager，导致待办清单里的文字风格和摘要不一致。写明数据流的走向之后，问题就消失了。

4. 真实项目里Skills组合与生态观察

Skills的意义不止于个人效率工具，放到更大的场景里，它代表着一种新的软件形态。

4.1 接入ROS 2的机器人场景：Skills也能控制仿真

我认识一位做机器人仿真的朋友，他用OpenClaw搭了一个ROS 2 + Gazebo的环境，让Agent能直接控制仿真机器人。听起来很硬核，拆开看其实就是几个Skills在协作：一个是launch-manager，负责启动和关闭Gazebo仿真环境、加载不同世界的URDF模型；一个是diagnosis-reader，负责解析ros2 topic和log文件，定位节点异常；还有一个是teleop-helper，把语音指令或自然语言指令翻译成运动控制指令。

这个案例给我很大的启发：OpenClaw的Skills机制天然适合和ROS 2这类复杂系统结合。因为ROS 2指令繁多、环境配置冗长，模型再强也不可能把每一条指令都记在脑子里。但通过Skills，你可以把“启动导航仿真”“读取里程计数据”“保存当前地图”这些常见操作封装成确定性的脚本，模型只需要学会“调用哪个Skills”和“传什么参数”。

这样的组合真正发挥价值是在“日志分析”这类任务上。让Agent做常规的“跑一个launch文件、等20秒、看输出”这类操作，人类开发者做是机械劳动，让AI用Skills来做就变成了低成本自动化。

4.2 为什么WorkBuddy这类工具都在转向Skills

如果你最近关注AI编程工具的动向，会发现一个趋势：大家嘴上叫的名字不一样，内核却越来越像。有的叫Skills，有的叫Plugin，有的叫MCP Tools，但本质上都是“给模型外挂一套可复用能力”。连WorkBuddy这类主打工作流自动化的产品，也在往这套模式靠拢。这不是抄袭，是被市场验证过的必然方向。

原因说穿了很简单：纯靠模型本身，无法覆盖长尾场景。模型再聪明，也不可能内置每个团队的业务逻辑；切到外部能力市场，自然就会“把能力插件化”。Skills这套模式好在它把“能力”和“知识”解耦了——模型负责理解，Skills负责执行，两者各司其职。我越来越觉得，这种模式在未来很长一段时间里会是AI应用的主流形态，就像手机App生态真正成熟是依赖于“系统提供基础能力，App负责具体场景”的分工。

4.3 可视化：Skills UI和图形化编排的趋势

Skills生态现在还有一块在快速演化：从命令行调用到可视化编排。当前很多用户（包括我自己）是在终端里让OpenClaw做事情，但非技术用户需要更直观的界面。社区里已经有人在尝试给Skills做图形化的拨号面板、给执行流程做可视化编排，让不懂代码的人也能把几个Skills拖拽成一条工作流。

我现在自己的用法也升级了：不只在终端里给OpenClaw下达命令，还会把复杂的、长流程的Skills用配置化方式管理起来，每个Skills的输入输出、依赖关系都文档化。当Skills数量超过20个之后，有没有一套清晰的“接口文档”，体验差的不是一点半点。建议早期就养成习惯，每个Skills写清楚“输入什么、输出什么、依赖什么”，这会变成你的个人能力库索引。

5. 常见问题与排查技巧实录

最后把这几个月踩过的高频坑整理一下，方便你对照自查。

5.1 Skills不触发，模型就是不调用它

这是最让人抓狂的情况。明明Skills里的逻辑是对的，脚本也能跑，但模型根本不加载它。我总结下来就三个原因：第一，description写得不够具体，模型根本不知道这个Skills是干嘛的。第二步，Skills在文件系统里的路径没有匹配到当前工作目录。OpenClaw默认会看当前项目目录下的skills/文件夹，你把Skills放在任意位置，它不一定扫得到。第三个原因是缓存，改了SKILL.md之后模型没有立刻读到新版本，需要重启会话。

排查顺序我建议是这样：先确认路径，再检查description，最后强制重启会话。

5.2 脚本执行报错，但终端手动跑没问题

这个问题最反直觉。我在调试前端生成Skills时遇到过，脚本在终端里跑得好好的，OpenClaw调用时就报错，说Python模块找不到。原因出在可执行权限上，脚本需要在文件系统中设置正确的执行权限，以及脚本运行时所需的Python模块没有装在Agent进程相同的环境里。

想要避坑，在SKILL.md执行步骤里明确规定：“执行前先运行python -c 'import requests'，如果失败，退出码为1，不要继续后续步骤，提示用户安装依赖”。这句看起来多余，但它能帮你省下不少排查时间。

5.3 关于模型接入方式：只能用云API吗

这是我在社区里被问得最多的问题。答案是：不。OpenClaw不是只能接云API。我自己就用Ollama接了一个本地小模型跑过基础Skills，因为模型是本地推理，没有网络依赖，用起来更可控。代价是本地小模型的理解能力、指令遵循能力跟大模型差距不小。实测下来，针对同一个Skills，本地模型漏步骤的概率明显更高。所以我的建议是：基础链路验证用本地模型没问题，但要交付复杂任务还是得接正经的大模型API，两套配置留着，按需切换。

5.4 权限和安全边界

Skills给了模型直接执行脚本的能力，这也意味着你在向一个可能犯错、可能被提示词注入的模型开放你的系统。我自己的安全准则是：第一，凡涉及删除、批量重命名、覆盖文件的操作，尽量不要做成Skills，或者在SKILL.md里要求“执行前打印将要操作的完整文件列表，等待用户确认”；第二，最小权限原则，Skills尽量以独立、受限的账户运行，避免用root或管理员身份跑所有任务；第三，敏感信息（API Key、数据库密码）不要直接写死在脚本里，用环境变量或密钥管理文件注入。套一个安全框架跑起来容易，出了事兜底反而麻烦。

5.5 最后一个常见问题：怎么卸载OpenClaw

有几次我在不同机器上折腾坏了配置，最后选择重来。卸载就是反方向操作：停掉OpenClaw后台进程，删除配置目录（一般在你用户主目录下的.openclaw或类似目录），再清理安装时生成的程序文件。如果你用了Docker方式部署，那就是先docker stop再docker rm，再加一条docker image rm。别怕折腾，配置坏了重装一次的成本，通常比对着错误日志硬排要低得多。

我现在越来越确定一个判断：OpenClaw这类的Agent框架，真正的分水岭就是Skills。你把模型接好、把对话跑通，那只是拿到了一个空壳；只有当你开始写自己的Skills，把日常工作流里那些重复的、确定性的、有规则的动作一点点固化进去，OpenClaw才从一个“能说话的玩具”变成“能帮你干活的生产力工具”。

所以我的建议是，不要先花时间研究别人的Skills库或纠结格式标准，先写一个最简单、能解决你眼下实际问题的Skills。哪怕它只是“读取指定文件夹里所有图片并按月归档”，只要它是为你自己的场景写的，你就会立刻感觉到差别：OpenClaw开始懂得怎么和你配合了。

最后分享一个写Skills时的小技巧：每一次把正在做的事做成Skills，不只是为了自动化，更是在积累自己的方法库。你写下的每个Skills，都是对“我究竟是怎么干这件事的”的一次结构化总结。这个思维转变之后，你会发现可供沉淀的东西远比想象的多——而这些东西，才是你和别人用OpenClaw拉开差距的地方。