用 WorkBuddy 有段时间了，从一开始“聊天窗里问问题”，到后来把整条活儿交给它跑——中间最关键的转折点，是搞明白Skill 到底是什么。

这篇不讲概念宣传，只讲我这段时间摸索出来的用法：怎么用 Skill 做网页、怎么让它写代码而不写歪、怎么走通小程序那条链。三类场景不同，但底层方法其实是同一套。

一、先把 Skill 说清楚：它不是插件，也不是模型

我一开始也有误解。Skill 不是“更多功能的开关”，本质上是一份可复用的工作流说明书：里面写着这类任务该怎么做、有哪些坑、需要调用什么脚本或工具、什么条件下该触发。

它有三个来源：

• 内置：官方写好的，覆盖文档、表格、PPT、PDF、网页部署、云服务、小程序、浏览器操作这些高频场景
• 市场安装：可以一句话搜装，比如让它“帮我找个安装 SKILL 的工具”，走的是 find-skills 那类能力
• 自己写：有 skill-creator，可以把一套成型做法固化成你自己的 Skill

触发有两种：拿斜杠 / 直接点名，或者用自然语言说需求，由它自己路由。后者才是真正的价值所在——你不需要记住有哪些 Skill，只需要把需求说到位。

所以我给自己的第一条原则是：同类任务做过第二次，就把它固化成 Skill，而不是每次重新讲一遍提示词。 一次性对话产出结果，Skill 产出的是产能。

二、做网页：cloud-service 和 sites 是一对搭档

做网站这件事，我踩过的最大弯路是“什么都自己写”。现在的分工很清晰：

• cloud-service 管后端：云数据库、用户登录（邮箱/手机验证码/微信）、文件存储、免密钥的模型调用
• sites 管上线：把本地项目发布成一个可以分享的链接，也能一键下线

我的建议流程是这样，别一上来就接数据库：

先做静态骨架，把页面和交互跑通，本地预览看一眼

确认数据模型：要不要登录、数据谁能看、需要几张表——这一步含糊，后面全返工

接 cloud-service，把权限（谁能读写哪条数据）当场说清

发布上线，把链接打开自己手动点一遍

有个细节值得记：发布时会拿到一个 applicationId，后续迭代复用它，别每次都新建，否则会散出一堆重复应用，管理起来很麻烦。

还有个小技巧：开发阶段的本地预览（127.0.0.1 那种）比发布后再改高效得多。我现在的习惯是先让它在本地起服务、我看一眼，确认视觉没问题再点发布。

三、写代码：把“别乱改”写进流程里

让 AI 写代码，最大的风险不是它不会写，而是它写出看起来对的东西。我的应对办法是把流程约束紧一点：

第一，先勘察再动手。 让它用探索型子代理把相关文件读一遍、把调用链理出来，再开始改。直接上手改的后果通常是：修好了 A，悄悄弄坏了 B。

第二，模式分清楚。 小改动（补个字段、修个样式）直接动手最快；涉及多文件、有架构影响的需求，先让它出方案（Plan），我看完再批准执行。多花三分钟做规划，省掉半小时返工。

第三，验收标准要写成可执行的。 别写“确保功能正常”，要写“跑一遍测试全绿”“打开页面确认图片能加载”“对比修改前后的输出一致”。能被执行验证的才算标准。

举个自己的例子。我这个博客的发布脚本 typecho.py 是个小工具：Markdown 转 HTML、走 XML-RPC 发到博客。今天写新文章时我给它加了个功能——非首图自动加懒加载，避免页面打开时一次性拉满所有图片。

改动只有几行，但真正的工作量在验证：

• 本地转换一遍，确认 <img> 标签属性加对了位置
• 发布之后，用命令行把线上 HTML 抓下来 grep 一遍，确认第一张图没有 lazy（它要被主页抓成 banner，不能推迟加载）、其余图都有
• 再打开首页看 banner 有没有正确取到第一张图

如果只看“我觉得改对了”，这事八成会翻车。说到底，速度不是 AI 带来的，验证才是。

四、小程序：这条链路最“工程化”

小程序是所有场景里流程最长的一条，但分工反而最清楚。

mini-program-development 负责开发侧的整条链：脚手架、编译、预览、托管发布。纯静态的小程序可以直接做；一旦需要存数据、登录、传文件、调模型，才引入 cloud-service（微信登录、手机号验证码这些都在里面）。

这里有个特别容易搞错的地方，我单独提醒一句：

“生成应用预览卡”不等于“发布上线”。 开发完、验证完，会创建一个带 applicationId 的预览卡给自己和家人朋友先看效果；真正的上传、审核、发布，是在分享面板里主动点的那一步。搞清楚这个边界，就不会出现“我以为已经上线了”的误会。

另外真机调试还是要装微信开发者工具，模拟器里跑通不等于手机上没问题——尤其是布局和手势相关的部分。

五、三条跨场景的通用经验

1）记忆要分层，别什么都靠“上下文”。

WorkBuddy 的记忆分三层：云端记住你的长期画像，用户级文件记住跨项目的个人偏好，工作区记忆记住这个项目的约定。我用得最多的是第三条。

2）重复劳动交给定时任务，外部系统交给连接器。

需要每天固定时间做的事（比如按主题写稿、抓数据、生成日报），交给自动化任务，比每天自己开口强。需要读写腾讯文档、飞书、TAPD 这些外部系统，走连接器，别想着让 AI 手动模拟点击——那是最脆弱的方案。

3）浏览器操作是兜底手段，不是首选。

需要真的登录、点按钮、填表单的时候才用浏览器控制。能用接口解决的，永远优先用接口。

结语

Skill 真正的收益，不是“多了一个功能”，而是把一次性的对话变成了可复用的产能——你花一次精力讲清规则，之后同类任务都能跑在这条轨道上。

我现在的判断很简单：不会写 Skill 也没关系，但一定要养成“把做对过一次的事记下来”的习惯。 记在记忆文件里，或者固化成 Skill，都比下次重新教一遍划算。

工具不会替你变强，但流程会。