企业官网建设流程全解析

当OpenClaw不再是“能对话的玩具”，而是一个真能分担重复劳动的代理时，我第一次意识到：模型能力决定它的智商，Skills（技能）才是它的干活的双手。之前两篇我写了怎么搭建基础环境、怎么接上模型、怎么跑通第一条工作流；从那一篇起，我彻底掉进了“装技能、调技能、写技能”的坑里。结果就是，我越用越猛，最后给它装了三十多个现成技能，还忍不住自己动手写了几个专属技能。

这个阶段最值钱的经验，不是“装得多”，而是“明白什么该装、什么该自己写、怎么让技能之间不打架”。这篇文章我把完整的思路、装技能的流程、自研技能的方法，以及我踩过的坑一次说清楚。适合已经搭好OpenClaw基础、正在琢磨“下一步能干什么”的朋友，也适合那些把AI代理当“数字员工”用、想让代理真正前后忙碌起来的人。

1. 为什么“装30+技能”是必经之路

1.1 技能到底是什么，和插件、工作流有什么区别

很多人一上来就问：OpenClaw的Skills到底是插件还是工作流？我的理解很简单：技能是一个“最小的可复用干活单元”，它把意图、提示词、参数和可执行动作打包在一起。同一个技能，你可以让它处理邮件、生成报表、抓取网页摘要，也可以让它跑定时任务。本质上，它是给代理留了一张写好的“工序卡”。

打个生活化的比方：模型是大厨，算力是厨房火力，而技能是菜刀、砧板、烤箱这类工具。大厨再聪明，没有菜刀也不能切菜；大厨不可能每次临时找一块铁片磨成刀。技能就是那把已经开好刃的刀，你要切丝有切丝的刀，要切片有切片的刀，干不同的活直接换刀就行。

工作流和技能的区别在于粒度。工作流是把多个步骤串成一条流水线，比如“抓取邮件附件→转成表格→归档→发通知”；技能更底层，通常做一件事：解析邮件、提取附件、生成摘要、查日历。由代理在运行时决定调用哪个技能、组合哪些技能。我把工作流想象成车间主管的排程单，把技能想象成工人的单项手艺。小活多，技能就得多，这是最根本的原因。

1.2 技能体系的四种类型

我的30多个技能不是随手堆的，而是按使用场景分了四类，建议照抄这个分类思路：

• 指令型技能：直接执行明确指令，比如“读取某文件夹的CSV并统计值”“给某标签邮件打星标”“发送一条待办提醒”。这类技能偏轻量，主要价值是省去你反复描述任务。
• 提取型技能：从非结构化内容里抽取结构化信息。比如“从PDF里抽出发票号码”“从邮件正文提取关键词”“从会议纪要中总结决策事项”。这类技能是我用得最多的，因为AI模型天生擅长语义提取，把这类能力固化成技能收益最大。
• 生成型技能：帮助产出内容，比如“生成周报”“写项目复盘”“生成客户感谢信”。这类技能不只是调用大模型写文字，还会自动带入上下文（本周任务、邮件统计、日程数据），生成结果可靠得多。
• 联动型技能：用来衔接外部系统和数据，比如“把表格数据写入数据库”“调用某API推送消息”“把文件上传到网盘”。这类技能往往涉及凭证和权限，配置稍复杂，但它们是让代理真正“替你打工”的关键。

这四类技能的配比可以按照自己的实际任务灵活调。我的30多个里，提取型和指令型大概各占三成，生成型占两成，联动型不到两成。别觉得联动型少，因为外部联动最容易出问题，不稳定的时候宁可先不用，保住核心体验。

1.3 装了30+后，效果到底怎么样

装30+个技能听起来很唬人，但真实价值是覆盖高频场景。我给自己代理设定的高频任务清单是：

• 每天早上整理前一日邮件：摘要、分类、列出需要回复的3件事。
• 每周五下午自动跑项目数据统计：把各渠道的任务清单合并成一张周报表格。
• 每周日生成一份个人复盘：基于日程、任务完成率、未处理事项，给出一页纸纪要。
• 收到特定格式附件时自动备份到本地归档目录。
• 网页内容定期抓取，改成结构化摘要存入笔记。

这些事如果全手动，一周怎么也要花2到3小时。代理有了对应技能后，人工缩成了“点一下确认”和“偶发纠错”。我做了个朴素统计：连续使用四周后，日常重复任务的人工干预比例从第一周的大约40%降到了第四周的不到15%。这15%主要来自不可预见的异常情况，比如某个系统登录态失效、某个网页结构改了。技能本身是稳的，外部环境才是不稳因素。

1.4 别为了装而装，技能也是负债

这里泼一盆冷水：技能不是越多越好。每多一个技能，代理做意图路由时的备选池就大一格，如果多个技能描述高度重叠，模型就可能选错。比如我装了一个“总结邮件”和一个“邮件摘要”，描述几乎一样，结果代理经常随机调用，输出却差不多，纯属浪费。

后来我把重叠技能删掉，保留一个更好的，反而整体准确率上来了。所以，装30+个技能的底气是“覆盖广”，但它需要靠后面管理来保障。技能是资产，也是负债，关键在于你能不能维护得住。在动手创建自己的技能之前，先把自己手头技能盘清楚，比盲目追求数量重要得多。

2. 批量安装与管理Skills的实操方法

2.1 技能从哪里来

OpenClaw的技能来源主要有三个渠道：

• 官方技能库（一般随框架发布）：质量高、测试充分，但数量有限，通常只有十几个通用场景。
• 社区共享合集：很多开发者会把手写的技能按“邮件处理包”“报表生成包”的方式打成合集共享，覆盖面大、更新频率不定，需要自己甄别质量。
• 自建私有库：把自己或团队沉淀的技能放在统一目录里，用版本管理工具维护。这是最推荐的长期做法，尤其是你自己开始造技能以后。

我一开始只盯官方技能库，后来发现社区合集里好东西不少。比如有人做了一套“CSV自动清洗”技能，支持几十种脏数据修正规则，比我打算自己写的强多了，直接拿来用省了大量时间。不过社区技能的质量参差不齐，装之前一定要先看它依赖什么模型上下文长度、调用了哪些外部命令，再决定是否引入。

2.2 安装三步走

OpenClaw的技能安装逻辑不复杂，无非是“把技能放进它认识的地方”。我实操下来，标准流程是：

1. 把技能文件（一个目录，里面含技能定义文件和脚本）下载到本地skills/目录下。
2. 用框架自带的扫描命令注册一次，让代理把新技能“读进”内存。
3. 跑一个简单的测试对话或测试命令，确认技能能被路由、能正常返回结果。

有个细节值得注意：技能目录命名要规范。我习惯用“动词_对象”这种命名方式，比如read_csv_stats、summarize_mail、weekly_report。一旦命名乱成skill_v2_final2，后面维护技能列表时想哭都找不到人。

注册完别忘了刷新技能索引。我遇到过好几次以为装了技能，结果代理根本调不到，最后发现是注册后少刷新了一步。扫描命令通常会输出一份技能清单，我建议扫完核对三件事：技能总数、名称列表、是否有加载失败的告警。

2.3 统一管理技能版本

当技能数量上了30，版本管理就是刚需。我踩过最狠的坑是：社区合集更新了一个技能，我顺手覆盖了旧版，结果新版本依赖一个我没装的新库，整个技能运行直接崩溃。所以无论从哪获取技能，都别直接覆盖，而是保留版本号并建立一个“技能锁文件”。

我建议的做法是：

• 每个技能目录内单独维护一个CHANGELOG.md，记录变动。
• 根目录建一个skills_manifest.yaml，写明当前启用的技能名、版本号、来源路径、依赖项。
• 更新时整体拉取到临时目录，对比manifest的差异后，再定向替换。

这样操作虽然多一点步骤，但换来的是可回滚、可追溯。别嫌麻烦，等到出了问题再排查就是十倍时间。

2.4 给技能分好权限，别一上来全放权

技能运行在代理环境里，权限配置直接决定“它能不能安全干活”。我见过不少人直接把所有权限调到最大，结果某个技能的脚本误删了文件，惨不忍睹。OpenClaw的权限模型一般分为两类：

• 凭证级权限：给技能绑定哪组API密钥、数据库账号、网盘令牌。
• 执行级权限：技能能否执行本地命令行、能否访问文件系统、能否访问外网。

我的配置原则很简单：最小够用。比如邮件摘要技能，只给邮件读取凭证，不给发信权限，更不给文件系统写权限；需要写文件的归档技能，才单独开放指定目录。每个技能都要问一遍：它完成任务至少需要哪些权限？答案之外的一律不授。

这里再提供一个技巧：把凭证和技能做映射时，尽量用“运行身份”而不是“账号主人”。比如某技能只处理指定工作邮箱，那它的凭证就该是那个邮箱的专用授权，不建议用包含个人所有邮箱权限的主账号。这样就算技能被滥用，损失也是局部的。

2.5 我的技能目录长什么样

我把自己常用的30多个技能分类存放，目录结构大致是这样：

skills/ ├── email/ │ ├── mail_summary/ │ ├── mail_filter_tag/ │ ├── attachment_saver/ │ └── outbox_review/ ├── report/ │ ├── weekly_report/ │ ├── monthly_review/ │ ├── project_status/ │ └── data_cleaning_report/ ├── file/ │ ├── csv_stats/ │ ├── pdf_invoice_extract/ │ ├── folder_archiver/ │ └── image_resize_batch/ ├── web/ │ ├── page_zh_summary/ │ ├── rss_monitor/ │ └── link_meta_extract/ └── calendar/ ├── agenda_plan/ ├── meeting_minutes_action/ └── free_slot_finder/

这个结构的核心是按“业务域”纵向分文件夹，再按单一技能横向分条目。好处是找技能快、写技能也清楚。后面自己造技能的时候，直接往对应分类里放就行，不会把目录搅成浆糊。

3. 从“会用”到“会造”：创建自定义技能完整流程

3.1 自定义技能的第一步：拆需求，而不是写代码

不少人一上来就想写技能，结果写出来四不像。我的经验是先别碰代码，先把你想让代理做的事拆成“输入→处理→输出”三段。以我当时最想做的“月度工作复盘”为例：

• 输入：当月邮件文件夹路径、当月任务完成清单路径、日历事件导出文件路径。
• 处理：统计完成率，提取邮件中重点项目，对照日历找出关键里程碑，计算各分类耗时分布。
• 输出：一份Markdown格式的月度复盘报告，包含数据统计、重点事件、未完成项和下一月建议。

这一步拆完，技能的结构基本上就自己浮出来了。你需要的不是灵感，而是清晰的流程。如果连输入是什么都回答不清楚，那代理拿到手也不知道怎么干活。

3.2 技能文件里到底装了什么

OpenClaw的技能目录里一般包含三个核心文件：技能定义文件（YAML格式）、执行脚本（可能用Python或JavaScript）、说明文档（README）。其中技能定义文件是大脑，它决定了代理什么时候调用这个技能、怎么向模型描述自己的用途、传入哪些参数、执行哪段脚本。

我以一个自创的简单技能为例，展示核心内容：

# helper functions def parse_mail_file(path): # 读取当月的邮件落盘文件 ...

name: monthly_work_review version: 1.1.0 category: report description: 根据当月邮件、任务清单和日历文件，自动生成结构化月度复盘报告 trigger: - "月度复盘" - "本月总结" - "月报生成" params: mail_dir: type: string required: true description: 当月邮件文本所在目录 task_csv: type: string required: true description: 任务完成情况CSV路径 cal_export: type: string required: false default: "" description: 日历导出文件路径，可选 prompt: | 你是OpenClaw的复盘助手。 请按照以下步骤生成月度复盘报告： 1. 统计任务CSV中的完成率与延期率。 2. 从邮件目录中提取本月出现3次以上的项目关键词。 3. 若提供日历文件，识别本月重要里程碑。 4. 用Markdown格式输出报告：本月概览、重点项目、未完成事项、下月建议。 output: format: markdown target: reports/monthly_review.md exec: command: python3 run_monthly_review.py workdir: .

这个文件的关键点在于：

• description要写得准确且唯一，帮助代理在多个技能中选中它。
• trigger是自然语言触发词，不是死板的命令，而是几个常见说法，让意图路由更稳。
• params定义了需要外部传入的字段，类型和必填与否要写清楚，模型才能正确生成调用参数。
• prompt是给模型的具体操作指令，步骤越清楚，输出越接近预期。
• exec指定实际执行脚本，OpenClaw会先调用模型按prompt进行规划，接着执行脚本，再把输出交给模型做最终整理。

3.3 从0到1：创建“月度复盘报告”技能

具体操作时，我建议分成四步走。

第一步，准备执行脚本。脚本不需要写模型推理，只做数据处理。我用Python写了一个简单的统计脚本，核心逻辑如下：

import csv import glob import re from collections import Counter def load_tasks(csv_path): with open(csv_path, "r", encoding="utf-8") as f: return list(csv.DictReader(f)) def task_stats(tasks): total = len(tasks) done = sum(1 for t in tasks if t.get("状态") == "完成") overdue = sum(1 for t in tasks if t.get("状态") == "延期") return total, done, overdue def mail_keywords(mail_dir, top_n=5): words = [] for f in glob.glob(f"{mail_dir}/*.txt"): with open(f, "r", encoding="utf-8") as fh: words.extend(re.findall(r"[\u4e00-\u9fa5]{2,}", fh.read())) return Counter(words).most_common(top_n) if __name__ == "__main__": import sys mail_dir, task_csv, cal_export = sys.argv[1], sys.argv[2], sys.argv[3] tasks = load_tasks(task_csv) stats = task_stats(tasks) keywords = mail_keywords(mail_dir) print("TASK_STATS:", stats) print("MAIL_KEYWORDS:", keywords)

这段脚本的作用是把“数据统计”这种确定性强的计算从模型那里抽出来，确保数字准确。模型不擅长精确算术，一旦让它自己数任务数，经常算错，把计算交给脚本是明智选择。

第二步，写技能定义文件。这是上文的YAML内容，需要重点打磨prompt。我的写法是给模型的prompt按序号约定清楚步骤，并且明确输出格式。实测下来，加上“若未提供日历文件，则自动跳过里程碑部分”这样的条件判断，输出的稳定性会高很多。

第三步，放目录并测试。将技能放回skills/report/下，运行注册扫描，然后在对话里手动触发“帮我做一下本月复盘”。如果代理没有自动填充参数，先手动把三个路径给定，再让它跑。测试通过后再逐步去掉手动传参。

第四步，模拟异常。比如把任务CSV里故意填错一列名，看脚本会不会崩溃。如果会崩溃，就说明prompt没有告诉模型参数格式要求，需要回退修改。我在这一步花了大量时间，因为真实数据永远比测试数据脏。

3.4 创建“邮件筛选摘要”技能

另一个我自建的技能是“邮件筛选摘要”。它解决的问题非常具体：每天早上打开邮箱太累，几百封邮件里只有几封重要，让代理先读一遍，只给我看重点。

技能设计成两步：

1. 用脚本把邮箱最近24小时的新邮件导出为文本文件，按发件人和主题命名。
2. 让模型读取这些文本，按预设的重要度规则（提到某个项目名、来自指定联系人、主题包含“待确认”等）筛出重点邮件并生成摘要。

技能定义里，我着重写了prompt规则：

prompt: | 你是邮件筛选助手。请逐封阅读邮件文本，按以下规则给邮件打重要度标签： - P0：含合同、付款、项目延期等关键词。 - P1：含待确认、评审、紧急等关键词。 - P2：其余一般邮件。 输出要求：只输出P0和P1的邮件，按重要度排序，每封邮件给出发件人、主题、和一句摘要。

这个技能的难点不是代码，而是重要度规则定义。规则太粗会把大量邮件选进来，规则太细又会漏。迭代了一个星期，我最终把规则精简到10条以内，效果才稳定下来。这说明技能的精髓不在多，而在准。

3.5 创建自己的技能时，最容易踩的三个坑

自建技能不是写代码难，而是规范难。我把自己踩过的坑总结成三条，每条都付出了真金白银的时间代价。

• 提示词比脚本更重要：很多人写完脚本就收工，结果模型乱输出。脚本只是把手，提示词才是大脑，你不告诉模型该按什么顺序看数据、输出什么格式，它就会自由发挥。提示词越具体，技能越稳。
• 参数类型别偷懒：我一开始图方便，把日期参数定义成自由文本，结果模型传了各种奇怪的日期格式，脚本没法解析。后来我把参数类型定义为date，并在 prompt 里附加“日期格式必须是YYYY-MM-DD”，问题才解决。所有需要脚本处理的参数，类型写得越死越好。
• README 不是可有可无：写完技能过了两周再看，你大概率忘了这个技能当时为什么这么写。保持写说明的习惯，记录用途、依赖、权限要求、变通逻辑，下次维护时能救你。

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

4.1 技能注册失败，第一件事查名字

我遇到最多的技能问题就是注册失败。症状是扫描完成后，新技能没有出现在可用列表里。排查顺序我建议固定下来：

1. 先看技能目录名是否符合规范（小写字母、下划线、数字）。
2. 再看技能定义文件里的name字段，格式要求通常和目录名近似，大小写敏感。
3. 最后才看YAML语法，很多人的问题是定义文件里混入了Tab空格，YAML解析直接报错。

我自己的一个教训是：给技能起了个中文名周报助手，注册时直接被跳过。改成英文名后一切正常。不是说中文名完全不行，但兼容性最好的做法永远是英文小写。

4.2 技能运行超时的三个常见原因

技能跑一半直接报超时，先别急着抱怨代理，先看这几个地方：

• 脚本有没有卡在死循环里：比如读取一个大文件没有限制行数，几十万行一直跑。
• 外部API响应太慢：技能里如果调用了某个外部服务，对方超时你这里就会跟着拖垮。
• 模型生成了错误参数：一旦参数类型不对，脚本可能进入异常重试逻辑。

我的处理习惯是给脚本统一设置内部超时和资源限制，比如文件读取最大10万行、单次请求超时5秒、脚本总执行上限30秒。这样就算出错，也不会把整个任务的预算全耗光。

4.3 意图路由冲突，怎么发现和解决

技能多了以后，代理偶尔会“选错技能”。比如我说“帮我总结一下最近的邮件”，它却调用了“邮件备份”技能。这是因为两个技能的描述太相似，路由模型分不清。排查方法简单：

把类似描述找出来对照，改改写得更具区分度。例如“邮件摘要”强调“阅读并提炼要点”，而“邮件备份”强调“复制保存到归档目录”。描述里把输入输出讲得更具体，路由准确率会明显上升。如果同一类任务总被错误路由到一个不相关技能，就先把这个迷惑项临时禁用，观察是否恢复正常。

4.4 权限和凭证错误排查速查

权限问题有个很典型的现场：技能能跑，但跑完没有结果，日志里显示“凭证缺失”。我整理了一个简表，自己排查时直接对照：

我曾经因为图省事，把所有凭证都绑到同一个主账号下，结果一个技能写日志把主账号的存储空间写爆了，牵连了一批技能不可用。后来痛定思痛，按技能职责拆分凭证，才把风险降下来。

5. 把技能做成体系：目录设计、复用与扩展

5.1 个人技能库的目录设计建议

随着技能数量持续增长，目录结构不能只按“业务域”分了，还要按“维护层级”分。我现在的做法是三层结构。

• 基础层：通用、低风险技能，比如“文件格式转换”“文本清洗”“日期解析”，全代理共享。
• 业务层：面向具体场景的技能，比如“周报生成”“邮件摘要”，只给特定工作流使用。
• 实验层：新写的、还没完全跑顺的技能，标记为“beta”，先小范围试用，跑稳了再升级到业务层。

这套结构的好处是：实验层技能可以大胆试错，不会影响已有稳定流程。很多新技能还没等它稳定就被当成正式技能部署，结果“翻车”还得回滚，很没必要。

5.2 技能之间怎么组合复用

自建技能积累到一定数量后，我开始发现“组合”远比“新增”有意义。比如“邮件摘要”技能的输出，可以作为“每日晨报”技能的输入；而“每日晨报”会同时拉取邮件摘要、日程提醒和待办任务，整理成一份早报。

组合时有个关键设计：技能之间最好通过“标准文件格式”衔接，而不是靠模型传递自然语言。比如A技能输出一个daily_notes.md，B技能直接读取这个文件再处理。这样每个技能都可以独立测试，组合时也方便排查是哪个环节出了问题。

我在做组合时，会给组合链套上一层“编排配置”，用轻量的方式写明链路顺序和依赖。后续扩展时可以随时在链条中间插入一个新技能，而不影响两端。

5.3 后续可以往哪些方向扩展

技能体系维护到现在，我给自己留了三个扩展方向，你也可以参考：

• 更多联动型技能：把代理接入日常工作系统的机会还很多，比如自动生成报表后发送到指定位置、定时抓取行业信息并生成简报。
• 更细的任务反馈闭环：让技能跑完后自动记录运行日志和效果评分，帮助迭代技能质量，而不是跑完就完事。
• 技能模板化：把高频技能（读文件、统计、生成报告）做成模板，每次只需要改一下参数和提示词就能生成新技能，速度会快很多。

从我目前的使用效果看，技能体系已经是我个人工作台里跑得最稳的部分。它的价值从来不是“看起来厉害”，而是每天真正替我节省了时间，让我不用反复重复那些低价值劳动。

最后分享一个实用的小建议：造技能不要急于求成，先把一个最小可用的版本跑起来，再用真实数据慢慢打磨。我几乎每个技能都经历了好几轮迭代，第一版能用，第二版好用，第三版才稳定。先是装技能，再是造技能，最后形成自己的技能体系，这个过程本身就是和OpenClaw磨合的过程。你先试着给代理写一个最简单的技能，跑通过一次之后，后面就停不下来了。