企业官网建设流程全解析

在 openclaw 里折腾技能库的时间越长，我越觉得真正值得研究的不是某个功能炫酷的成品 skill，而是这个看起来有点套娃的东西：skill-creator。它做的事情一句话就能讲清楚——让智能体根据你的自然语言描述，自己去生成一套新的技能文件。听起来没什么了不起，但它直接改变了我扩展智能体能力的方式：以前是我手动写脚本、改配置文件、小心翼翼地把能力喂给它，现在变成我描述需求、它出初稿、我做验收和修正。这篇文章我会把 skill-creator 解决的问题、标准调用流程、生成结果怎么拆解，以及我实际踩过的一堆坑一次性讲完。如果你也在给 openclaw 这类智能体框架维护技能库，这篇应该能帮你省不少时间。

1. skill-creator 到底在解决什么问题

1.1 手动开发技能的瓶颈到底有多痛

先说个很现实的情况。没有 skill-creator 之前，我想给 openclaw 加一个新能力，比如“把一段乱七八糟的会议录音转文字整理成待办清单”，流程是这样的：先自己写一个脚本或者复用别人的代码，再照着技能文件格式做 metadata 和描述，然后放进技能目录，改配置，重启服务，拿两三条数据测试。如果模型没在正确时机调用它，还要回头改 description 的措辞。

这还不算最痛苦的。真正麻烦的是，这种工作完全重复且没有积累价值。每个新技能的代码逻辑可能只有几十行，但为了让它能被智能体“正确唤起”，我反复调描述、调触发词，前后花掉的时间远超写代码本身。技能库里的文件越堆越多，每个都像是一个需要单独维护的小项目，时间一长，我根本不想再给智能体加新能力了——因为加一个能力，意味着多一套要维护的东西。

skill-creator 的核心价值就在这里：它把“开发技能”从写代码任务变成了对话任务。它本身也是一个普通的 skill，只不过它做的事情不是帮用户处理某个具体事务，而是观察用户的自然语言需求，结合内置的技能模板和技能库现状，生成一套可以被 openclaw 直接加载的新技能文件。等于让智能体拥有了自我扩展能力的能力。

1.2 本质是把“写技能”变成两段式对话

想理解 skill-creator 的工作方式，就不要把它当成一个自动编程工具。它做的更像是一个需求分析师加脚手架生成器。当我对它说“帮我做一个技能，功能是整理会议纪要”时，它不会立刻甩给我一堆代码，而是先追问一些关键信息：这个技能在什么场景下被唤起？输入是纯文本还是文件？输出格式有没有要求？依赖外部命令吗？

收到足够明确的需求后，它才在技能目录下生成一套符合 openclaw skill 规范的文件。整个过程可以拆成两段：第一段是人跟它对话、把模糊想法变成明确规格；第二段是它根据规格产出初稿，然后由我做 review、测试、修改。

为了更直观，我把传统开发方式和 skill-creator 方式的差别整理成了一张对比表：

我自己用下来的感受是，skill-creator 并没有取消“人”在开发技能里的责任，它只是把责任从“写代码”转移到了“把需求说清楚”和“做好验收”这两件事上。后面你会发现，这两件事同样需要技巧，但门槛低得多。

2. 第一次实操：从安装到生成第一个技能

2.1 安装与环境准备

先解决环境问题。要把 skill-creator 用起来，前提是 openclaw 本身已经能正常运行，并且技能目录的路径是明确的。不同版本或不同部署方式里，技能目录可能叫 skills、plugins、capabilities 之类的名字，但原理都是一样的：框架启动时会扫描这个目录，加载里面的技能文件。

安装 skill-creator 这件事本身很朴素：把下载好的 skill-creator 文件夹放进你的技能目录，然后确认它里面的 SKILL.md 或对应的 manifest 文件写的依赖项、权限声明是完整的。我的做法是装完之后先跑一句命令确认加载状态：

ls -la ~/openclaw/skills/skill-creator cat ~/openclaw/skills/skill-creator/SKILL.md | head -30

如果框架自带技能列表查询命令，也可以查询一下是否出现了 skill-creator 条目。这里要特别提一句：如果你的 openclaw 版本比较老，配置文件的字段名可能和新版不一样，不要硬套网上教程里的路径，重点理解“框架扫描目录 → 解析技能描述 → 按触发条件调用”这条主线。只要主线对得上，细节差异都好办。

一个容易被忽略的点是文件写权限。skill-creator 要往技能目录里创建新文件夹，运行 openclaw 的用户必须对该目录有写权限。我之前在一台机器上遇到过生成失败却没有任何报错的情况，最后排查发现是目录权限只读。这种坑很小，但很折腾人。

2.2 调用 skill-creator 的标准输入格式

skill-creator 的输入是自然语言，但“自然语言”不等于“随口一说”。我试过最省事的模板是五个要素，把它讲清楚后生成质量会明显提升：

• 技能名称：一个简短、唯一、能表达功能的英文标识符；
• 一句话目标：这个技能到底完成什么任务，不要在目标里混入多个功能；
• 触发条件：什么场景下智能体应该调用它，什么场景下不该调用；
• 依赖环境：脚本需要用到哪些外部命令、系统工具或路径；
• 输入输出示例：给一个具体的输入样本，以及你期望的输出格式。

我实际用的描述模板大概是这样的：

请用 skill-creator 创建一个新技能。 技能名称：meeting_minutes 一句话目标：把口语化的会议发言文本整理成结构化会议纪要。 触发条件：当用户给出多段会议发言记录，并且需要提取决定事项、待办事项、负责人时使用。 不适用场景：图片转文字、实时录音转写、PDF 解析。 依赖环境：需要 python3，无第三方库依赖。 输入示例：一段包含“官网上线时间”“客服外包”“预算讨论”的对话文本。 输出格式：分为“决定事项”“待办事项”“未决事项”三个板块，用无序列表列出。

不要嫌麻烦。第一次多写两分钟，后面能省两个小时。因为 skill-creator 生成技能时，很大程度是把你描述里的触发条件、输出格式直接翻译进 SKILL.md 的 description 和 steps 里。你描述得越具体，它生成的技能定位就越准。

2.3 一个真实的生成示例：会议纪要整理技能

我拿上面那段描述做过一次完整生成。过程中 skill-creator 补问了两个问题：输出要不要保留发言人的名字？对文本中的口语逻辑断裂要不要做自动补全？我回答“人名保留在括号里，不乱补全”，然后它就开始生成了。

生成完成的目录结构大概是这样的：

~/openclaw/skills/meeting_minutes/ ├── SKILL.md ├── format.py └── tests/ └── sample_input.txt

SKILL.md 的核心内容被生成成了这样（我做了一点点精简）：

name: meeting_minutes version: 0.1.0 description: 将多段口语化会议发言文本整理为结构化会议纪要。仅处理纯文本输入，不适用于图片、PDF、录音文件。 steps: - 读取用户输入的会议文本 - 调用 format.py 进行结构化整理 - 按“决定事项 / 待办事项 / 未决事项”输出结果

我拿了一段很乱的例会口述文本去测，输入大概是大家七嘴八舌讨论官网时间、客服外包、预算之类的口语内容。format.py 输出的结果会按板块归置清楚，比如“决定事项”下面列出“官网定于 15 号上线，前端负责人 A”；“待办事项”下面列出“整理官网页面清单，周五前完成，负责人 A”。第一次跑就有这样的效果，已经超出我的预期了。

但注意，这只是初稿。它不代表技能可以立刻进生产环境。我拿边界情况一测，问题就来了：如果输入文本里根本没有“决定事项”，format.py 依然会把这个板块列出来，然后写“无明确决定”。这不算错，但不够好。这一类的打磨工作，正是后面章节要说的重点。

3. 拆解生成结果：一份合格技能文件的核心层次

3.1 metadata：决定技能何时被唤起

技能文件里最容易被忽视的是最前面的 metadata 区域。几乎所有智能体框架都会优先读取技能的名称和描述，用来判断当前用户的请求是不是该交给这个技能处理。你可以把它理解成技能的名片：名片写得模糊，对方就不知道什么时候该找你办事。

关键字段无非就是 name、description、version、dependencies 这几个。name 要短且唯一，避免和已有技能撞车；version 要保留，因为技能迭代后要能追踪历史；dependencies 要写清楚，这样框架在启动阶段就能提前告诉你环境缺什么。

description 是整个 metadata 里最重要的。我曾经犯过一个典型错误，给一个文件整理技能写“处理各种文档相关任务”，结果智能体动不动就把翻译、格式转换也丢给它，输出一塌糊涂。后来改成“将 Markdown 文件中的重复段落去重，仅处理 .md 文件，不处理 PDF、Word 和图片”，准确率立刻上来了。这就是边界条件的作用。

3.2 description：能力边界比能力本身更重要

刚才已经提到 description 要写边界，这里展开细说。好的 description 应该回答三件事：这个技能做什么、在什么输入下适用、什么情况下绝对不要使用它。

我总结过一个对比，大家可以参照着检查自己的技能文件：

生成技能之后，一定要手动检查这一块。skill-creator 生成的描述通常够用，但它的措辞往往偏保守或偏宽泛，需要你结合实际使用场景去校准。校准描述不是文字游戏，它直接决定了技能被调用的准确率和整个智能体的响应质量。

3.3 steps 与可执行脚本：把确定性工作交给代码

SKILL.md 里的 steps 是给智能体看的执行指引，而真正干活的是背后的可执行脚本。这两者要有明确分工：所有需要大模型发挥理解力的部分留在 steps 里，所有确定性、可重复、需要精确计算的逻辑尽量移到脚本里。

比如会议纪要技能，文本里哪些句子算“决定事项”、哪些算“待办事项”，这类判断可以靠大模型完成；但输出格式的排版、去重、字段排序这类操作，让脚本做更可靠。如果全部依赖模型在步骤里自由发挥，每次输出的格式都会不一样，后来再做统计和分析会很痛苦。

脚本本身也要有基本的健壮性。skill-creator 生成的脚本经常是能跑通但没做错误处理。我建议至少让脚本做到：从标准输入读取数据、异常时向标准错误输出明确信息、以非零退出码结束。下面这段就是一个很朴素的框架：

import sys def main(): try: text = sys.stdin.read() if not text.strip(): print("输入为空，无法生成会议纪要", file=sys.stderr) sys.exit(1) result = summarize(text) print(result) except Exception as e: sys.stderr.write(f"处理失败: {e}\n") sys.exit(1) if __name__ == "__main__": main()

有了退出码和错误输出，智能体在技能执行失败时才能把问题反馈给用户，而不是闷头当作什么都没发生。

3.4 测试用例：技能交付前的最后一道质量门

很多人在生成技能后只拿一个正常样例跑一遍就收工了，这远远不够。skill-creator 的优势在于它可以顺便生成测试用例，关键是你要专门把它往刁钻方向引。

我常用的测试集包括四类输入：正常输入、空输入、超长输入、完全在能力边界之外的内容。还是拿会议纪要来说，我会让 skill-creator 分别生成“一段完全没有讨论出结论的对话”“只有一句话的会议记录”“超过一万字的发言稿”，然后挨个跑。正常输入看效果，空输入看是否报错，超长输入看是否截断，边界外内容看是否还强行输出纪要。

有了测试用例，新技能上线时心里才有点底。我见过太多技能在常规输入下表现完美，一旦遇到用户随便丢来的一句话就直接输出一堆不知所云的模板内容。测试这件事不能省。

4. 高频翻车现场：生成结果不好用的五个原因与修法

4.1 需求说得太“口号”，生成的是花架子

最常见的翻车原因是用户需求说得太宏观。比如你告诉 skill-creator“帮我做一个提高效率的技能”，它根本无从下手，最后生成一个什么都会一点、什么都干不好的东西。

我对比过两类需求。一类是“帮我做一个自动整理文件的技能”，生成结果通常是遍历目录、按后缀分类，听起来不错，但实际用的时候用户想按项目名分、想跳过隐藏文件、想保留原文件名规则，全都没考虑。另一类是“把下载目录中超过一周未打开的文件按月份归档到 archive 目录，并在日志中记录移动路径”，生成结果就非常具体，也更容易一次跑通两者差异的本质是后者把触发条件、规则、输出都定义清楚了。skill-creator 不是读心术，它只能基于你给的约束生成方案。

修法也很简单：生成之前多跟它对话两轮，把模糊的形容词替换成可验证的标准。把“效率”换成“耗时小于 10 秒”，把“智能”换成“基于关键词规则”，它的输出立刻会从花架子变成可执行的东西。

4.2 环境依赖被写死，换台设备就崩

另一个高频问题是脚本里的环境依赖写得太死。skill-creator 生成的技能在你这台机器上运行良好，挪到另一台机器就报错，多半是因为脚本里出现了绝对路径、硬编码的 Python 解释器路径、或者直接调用了某台机器独有的命令。

比如我见过一个技能脚本里有这样一行：

interpreter = "/home/某用户/.venv/bin/python"

这行代码在三台机器上可能只有一台能跑。修法是把这类内容改成相对路径或环境变量，脚本里用sys.executable获取当前解释器路径，或者用shutil.which("ffmpeg")这类方式动态探测依赖是否可用，不可用时给出明确提示而不是直接崩溃。

skill-creator 本身不知道你的目标机器环境，所以你在描述需求时就要主动讲清楚“脚本运行环境”这一项。如果技能要跨机器用，就必须把环境差异纳入设计范围。

4.3 技能命名撞车，旧技能被悄悄覆盖

命名问题我曾经踩过一次大的。有一次我让 skill-creator 生成一个“总结文章重点”的技能，名字起成了summarizer，结果已有的技能库里有一个同名技能。加载完之后，旧技能的调用记录全部消失，一些依赖旧技能描述的流程直接错乱。

不同框架对同名技能的处理方式不一样，有的覆盖，有的冲突报错，有的静默跳过。无论哪一种，都不是你想要的结果。修法很简单：生成前先查一遍技能库现有名称，或者强制给新技能加一个唯一前缀，比如my_summarizer、beta_meeting_notes。等你确定这个技能稳定了，再考虑合并或改名的方案。

4.4 生成内容太长，把上下文窗口塞爆

skill-creator 生成的文件如果篇幅失控，会带来另一个问题：技能描述在你每次对话时都会占据上下文上下文是有上限的，技能文件越长，留给实际对话和任务处理的空间就越小。

我这边的经验是把 SKILL.md 当索引而不是说明书。描述控制在两百字以内，步骤控制在八步以内，大量细节放进配套脚本或单独说明文件里。如果生成出来的 SKILL.md 本身就超过几百行，那基本可以判定它把太多不该放在前台的内容堆进来了。你要做的不是硬着头皮用小技巧压缩，而是把可执行细节下放到脚本里，让模型在需要时再去查细节。

4.5 失败时静默无声，排错只能靠猜

最后一个坑最隐蔽也最伤体验。skill-creator 生成的脚本如果没有任何错误处理，一旦执行失败，智能体会用默认的“完成”“处理好了”来回应，但实际产出是空的。这种情况下，你既不知道失败在哪一步，也不知道是输入问题还是环境问题，只能靠一遍遍重跑猜测。

解决办法就是前面提到的退出码和标准错误输出。更高级一点的做法，是在技能步骤里加一条“如果脚本退出码非 0，把 stderr 内容原样返回给用户，并附加一句可能的原因”。这句话不需要写进 SKILL.md 的核心步骤，但能帮你把排错成本压得很低。我把这个规则当成所有生成技能的默认要求之后，维护技能库的焦虑感明显下降。

5. 把 skill-creator 升级成你自己的技能工厂

5.1 迭代生成法：把第一次输出当草稿

很多人第一次用 skill-creator 就期待一步到位，结果发现生成物有各种不满意，于是下结论说工具不好用。实际上，skill-creator 的正确用法是迭代生成，不是一次成型。

我现在的工作流分五步：第一，用清晰的描述生成初稿；第二，拿一个正常样例冒烟测试，记录表现；第三，把我发现的问题逐条反馈给它，让它调整；第四，用边界和异常样例做第二轮测试；第五，通过后再决定是否正式入库。每一步之间的间隔通常只有几分钟，但效果比一次性生成好得多。

不要害怕在对话里直接告诉技能生成器“你的脚本缺少对空输入的处理”“输出格式不符合模板”。它能理解这些反馈，并且下一次生成会明显改善。我把这当作用对话方式做代码评审，效率意外地高。

5.2 我给每个新技能定的验收清单

经过一段时间踩坑，我给自己定了一个技能验收清单，生成完的新技能必须逐项打勾才能正式启用：

这套清单不是摆设。我统计过，严格走一遍大概十几分钟，但后续省下来的维护时间远远不止。真正可靠的不是工具一次生成得有多完美，而是你每一次都按照标准流程验收。

5.3 技能库的归置与归档

技能多了以后，文件怎么摆放就会影响维护效率。skill-creator 默认生成的技能目录结构可能不区分用途，我习惯在主技能目录下按功能域分子目录，比如writing、data_process、automation、dev_tools，同时在文件名里体现状态，像是beta_前缀代表未验收完的技能，正式版本不带前缀。

时间久了，有些技能会被新版本替代，或者不再使用。不要急着删除它们，我的做法是丢进一个archive文件夹，保留历史版本。因为 openclaw 的 skill 本质上是文件和文件夹，配合常见的版本管理工具，完全可以像管理代码库一样管理技能库。每次大改动提交一次，回滚和对比都方便。

5.4 从使用日志反哺技能描述

这是我个人认为最有价值的一条经验：技能描述不是写一次就完了，要定期回头改。openclaw 这类框架运行时会留下调用日志，记录每个技能被命中的情况。如果你发现某个技能经常被错误唤起，或者某个请求反复提示找不到合适技能，那大概率不是模型的问题，而是你的 description 和实际情况匹配不上。

我会每隔一两个星期翻一次日志，把“误调用”和“漏调用”的案例收集起来，逐条反馈给 skill-creator，让它根据这些真实案例更新描述。这个闭环跑起来之后，我技能库里老技能的准确率也是肉眼可见地在提升。

我现在的习惯是，每次给 openclaw 增加新能力时，都默认先打开 skill-creator，而不是直接动手写脚本。这个习惯刚开始只是一个效率选择，用久了你会发现，自己提需求的方式也变了——变得更具体、更注意边界、更清楚怎么验收。这大概就是它真正的价值。