WorkBuddy 智能体实战手册：自定义技能开发、知识库对接与多场景 AI 自动化落地拆解

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

先说结论。办公智能体和你手机里那个聊天窗口最大的差别，不是"模型更聪明"，而是它交付的是文件，不是回答。 你把一件事丢进去，它会自己拆步骤、自己去读你电脑上的文件夹、自己调工具，最后给你一个能双击打开的东西——一张整理好的表、一份报告、一段视频、一个网页。

第二个结论：这类工具真正拉开差距的地方，从来不是模型，而是三样东西——技能（把重复流程固化下来）、连接器（让它能碰到外部的文档和表格）、知识库（让它的记忆不随着缓存被清空而消失）。 这三样东西搞明白，剩下的事都是熟练度问题。

第三个结论：新手最容易死在一个特别不起眼的环节——没把任务交代清楚。 尤其是"口径"这一项。同一份订单数据，退款算不算销售额、外币要不要折算、折扣率的分母是谁，你不说，它就自己猜；它一猜，后面所有结论全歪，而表面上看还特别漂亮。

第四个结论：验收必须自己做。 至少要能回答三个问题：这个数字能不能在你给的原始文件里找到出处？已完成和待确认有没有被分开？你的原始文件有没有被改过？这三条过不去，交付就是废的。

第五个结论：合规要提前想。 AI 生成内容要按《人工智能生成合成内容标识办法》做显式与隐式标识；声音克隆、形象克隆必须先拿到本人书面授权；素材、字体、音乐商用要取得正版授权。这几条不是"以后再说"的事，是动手前就该摆到桌面上的事。

本文会按"先认清工具，再把事说清楚，接着让智能体长出技能、手脚和记忆，然后进五个具体场景，最后落到验收与合规"的顺序，把整套流程拆一遍。想看完整拆解，往下翻。

一、先认清对手：办公智能体和聊天窗里的 AI 差在哪

我第一次打开 WorkBuddy 的时候，心里的判断挺敷衍的——"又是一个套壳聊天窗"。用了三天之后我改了看法，但改的也不是"它多聪明"，而是"它愿意去碰我的文件"。

这件事听起来平平无奇，实际上是分水岭。

一次对话和一次交付，是两回事

聊天型 AI 的运转方式是：你问一句，它答一句；你不问，它就停。你给它一份表格，得先手动上传或者复制粘贴；它看完给你一段分析建议，这段建议对不对、怎么落地，全归你自己管。

办公智能体的运转方式不一样。你把目标丢给它，它自己拆解、自己规划、自己调用工具，最后落一个文件出来。这个区别用一张图说最清楚：

flowchart LR
    A[理解目标] --> B[拆解任务]
    B --> C[调用工具与技能]
    C --> D[交付可验收的产物]
    D -.发现问题.-> A

拆开看，就是四步：

1. 理解目标：它要先搞明白你究竟要解决什么问题，包括你前面给过的限制条件、上下文里出现过的文件。
2. 拆解任务：把一个大目标切成若干可执行的小步骤，排出先后顺序。
3. 调用工具：到某一步需要读表格、跑脚本、联网查资料、调外部接口的时候，它去用技能、连接器、MCP 这些东西完成任务。
4. 交付产物：把结果落成文件交给你，同时把中间过程保留下来，你能看到它每一步干了什么，跑偏了可以直接打断它。

这四步不是 WorkBuddy 独有的，市面上叫得上名字的智能体基本都是这个骨架。区别在于第三步"能碰到什么"，这一项决定了它到底是个吉祥物还是真能干活的。

我自己的体感是：临时问一句的事，别用它，聊天窗口更快；一周要做三次以上的事，赶紧用它，并且要逼自己把它固化成技能。 这句话后面会反复出现，因为它几乎是整套方法论的地基。

三块拼图：技能、专家、连接器

WorkBuddy 的能力入口可以粗暴地归成三块，理解了这三块，界面上那些按钮就不再是乱码。

• 技能（Skill）：说人话就是"把一套流程写成一个说明文档，丢进一个文件夹，以后一句话就能调起来"。你可以把它当成手机上的应用，也可以当成给新同事看的操作手册。区别在于，这份手册是给 AI 看的。
• 专家：可以理解成"已经把多个技能搭好、还配好了角色设定的一整套方案"。你不用自己去拼技能，直接找一个专家来干活。缺点是额度消耗比单个技能快。
• 连接器：让智能体能够碰到外部系统的东西。飞书文档、多维表格、腾讯文档、邮箱、知识库，基本都在这个范畴里。

这三块之外还有两个容易被忽略的东西。一个是自动化，让任务按周期自己跑；一个是工作空间，决定它的对话和产物落在哪个文件夹下面。工作空间这一项特别容易踩坑——你不选，对话就散落在默认列表里；你选了，它才在一个固定的上下文里干活。

它在哪里跑，你要清楚

这里有个很多人一开始想不明白的点：智能体可以跑在云端，也可以跑在你本机。

区别是这样的：如果任务不需要碰你电脑里的任何文件，走云端就够了，手机发指令、云端跑完、结果回传，你电脑开着关着都不影响。如果任务要读你本地的文件夹、要改你本地的东西，那必须让本机在线，而且不能让电脑进入睡眠——电脑一睡，手机那头就彻底联系不上了。

所以稳定的做法是：把本机的屏幕锁定远程唤醒、远程连接这类开关打开，让机器在你需要的时候能被叫醒。

装之前先看一眼环境

这部分没什么技术含量，但装完才发现不兼容，会白白浪费一个下午。

装完之后先做一件事：进设置，把默认存储路径从系统盘改到别的位置。这一步花你两分钟，能省掉以后电脑变卡时的很多麻烦。

额度这件事，早点建立概念

这类工具的消耗单位各家叫法不一样，有的叫积分，有的叫额度，本质是同一个东西：你调用模型、生成图片、合成视频，都要扣。

有一点要提前说清楚：额度通常是时效性的，平台经常会发一些限时额度、每日签到额度、完成任务送的额度。日常的轻量任务用这些基本够，重度的生成类任务（长视频、批量出图）就明显不够了。

我不太建议一上来就研究怎么把额度用满，那不解决根本问题。真正值得花时间的是：把高频流程固化成技能之后，单次消耗反而会降下来——因为它不用再反复试错，不用再让你来回确认十几轮。

至于各家具体怎么算、单价多少，写稿的时候我看到的数字只能算个近似行情，这类定价变动非常快，请以官方定价页面的实时数据为准。

二、新手最容易死在哪：把一件事交代清楚

写这篇文章之前我回头翻了几个翻车现场，发现原因高度集中在同一个地方：不是 AI 不行，是话没说明白。

有个特别典型的例子。我让智能体整理一份订单数据，出营业额汇总。它跑得飞快，三十秒给了一份漂亮的报告。我一开始还挺满意，越看越不对劲——订单条数比实际多了七条，渠道统计多算了一笔，还有两个金额明显是外币没折算。

问题出在哪儿？出在我说的那句话：「帮我统计一下这份订单数据的销售额。」

"销售额"这三个字，在我看来是常识，在它看来是个填空题。

一条完整的任务，要包含五样东西

我把这几年自己用得最顺的结构整理成五个要素。不用每次都写全，但重要的任务最好都过一遍。

1. 目标：你到底要什么结果。是"给我一份能直接发出去的周报"，还是"给我一份待确认的草稿"，这两种说法产出的东西完全不是一个东西。
2. 输入：数据从哪来。是工作空间里某个文件夹，是某个知识库里的某篇文档，还是你打算后面再贴一段文字进去。
3. 口径：这是最关键、最容易被忽略的一项。指标怎么定义的、时间范围多大、特殊情况怎么处理。
4. 约束：硬性的边界。不能改原始文件、时间窗只能取近 90 天、来源必须优先官方文档、页数不能超过 8 页。
5. 产出：交付什么形态。Markdown 报告、Excel 表格、HTML 网页、演示文稿文件，还是同时要几份。

这里还可以补一层更细的说明：产出要说清楚格式、命名、存放位置三件事。格式决定它怎么组织内容，命名决定你以后找不找得到，存放位置决定它会不会覆盖掉你原来的东西。我吃过一次亏，让它生成"一份报告"，它把文件命名成 report.md，放在工作目录根下，然后第二天又生成一份同名的，直接把前一份覆盖了。从那以后我的产出要求里固定加一句：文件名带上日期和序号，不要覆盖已存在的文件。

把这五样拼起来，就是一份能直接复制去用的模板：

# 角色与目标
你是我的数据处理助手。目标：把【订单原始表】整理成一份可用于内部汇报的销售汇总。

# 输入
- 数据源：工作空间 /data 目录下的 order_raw.xlsx
- 若文件缺失，先告诉我缺什么，不要自己造数据

# 口径（必须严格遵守）
- 时间范围：2026-01-01 到 2026-03-31
- 销售额：仅统计"已完成"状态订单；"已退款"和"已取消"不计入
- 币种：统一按人民币口径，外币按当日中间价折算，折算明细单独列出
- 折扣率分母：使用原价，不使用折后价
- 金额单位：元，保留两位小数

# 约束
- 不要修改任何原始文件
- 重复行、无效日期、必填字段缺失的行，必须单独出一张"排除清单"，注明排除原因
- 报告中所有数字必须标注来源列名

# 产出
1. 汇总表（Markdown 表格）
2. 排除清单（Markdown 表格）
3. 一页结论，事实与推论分开写

看起来啰嗦，但这份啰嗦是有回报的。同一份数据，加了口径约束之后重跑，订单数对上了，渠道分类也对了，多出来的那七条异常行老老实实出现在排除清单里。前后两次的差别，就是我多写的那十几行字。

口径为什么要说死

数据类任务上，口径是唯一不能偷懒的地方。因为它有个特别阴险的性质：口径错了，输出依然好看。

还是用刚才那个例子。它给我的那份报告里，柱状图高度合理、百分比加总正常、文字描述通顺，从视觉上完全挑不出问题。我当时甚至还截了图准备直接用。真正让我起疑的是"订单条数比实际多了七条"这个细节——因为我恰好记得原始表大概有多少行。如果没有这个巧合，我大概率会带着一份错的数据去汇报，而且不会有人发现。所以我在所有数据类提示词里都固定加两条：

• 所有汇总数字必须能回溯到原始表的具体列；
• 任何被排除的记录都要单独列出并注明原因。

这两条加进去之后，它的"猜"就会被逼到台面上来。

顺手给一张我自己常用的检查表，交付前对着过一遍，能拦掉大部分返工：

什么时候让它先给计划

这类工具一般提供两种干活姿态：一种是你问它答，它只回答不替你动手；另一种是先出计划、你点头了它再执行。

我的习惯是分场景：

• 探索性任务——比如"这份数据能看出什么"，用问答姿态，成本低、试错便宜。
• 破坏性任务——涉及写文件、改文件、批量操作，一律先要计划。看它的计划里有没有你不想要的步骤，比如"删除重复行"这件事，有些场景下你其实不想删，只想标记。
• 重复性任务——已经跑顺了的流程，直接全权交给它，甚至封装成技能，不用再看着。

还有一个权限档位的问题。有的工具会给你"只读""可写""完全访问"这种分级。日常我建议先给可写就够了，完全访问留给已经验证过的流程。 不是不信任它，是范围越大，一次误操作的代价越大。

截图，比打字描述省时间

这一条不属于"交代任务"，但特别实用，我放在这里。

程序报错的时候，你花五分钟写一段文字描述错误信息，效果往往不如直接截一张图丢过去。因为它就在你本机，它能看到你屏幕上应该看到什么，也知道你当前环境里缺什么。 我遇到环境相关的报错之后基本不再自己查，截图、发过去、等它判断。

顺带说一句：遇到问题时优先问手边的 AI，比在网上搜答案靠谱。原因很简单，网上的答案是别人的环境，你的环境可能缺了别人有的东西，照抄往往在另一处卡住；而手边的 AI 是在你的机器上，它知道你这台电脑到底装了什么。

一句话总结这一章：它不是读心术，它是执行器。你说得多清楚，它就能干得多准。

三、技能到底是个什么：一个文件夹怎么长成一项能力

"技能"这个词被用得太泛了，很多人第一次听到会以为是插件，以为是会员功能，以为是某种高级提示词。都不是。

技能的本质是一个文件夹，入口文件叫 SKILL.md。 就这么简单。

你可以把它想成一盒药的说明书。药盒本身不重要，重要的是里面那张纸——写清楚这盒药治什么、什么时候吃、一次几粒、有什么禁忌。技能也一样：SKILL.md 里写清楚"这个技能干什么、什么时候用、按什么步骤做、有哪些禁止事项"。

为什么一个文件夹就够

因为这套东西的加载方式是渐进的，这一点如果不理解，后面会踩很多坑。

• 启动阶段：它只读每个技能的"名称 + 描述"。这部分非常短，一个技能大约只占百来个 token 的量级。
• 对话阶段：它拿你的需求去和每个技能的描述做匹配，判断哪些可能相关。
• 激活阶段：真的命中之后，才把 SKILL.md 的正文完整读进来。
• 按需阶段：正文里如果引用了参考文档、脚本、模板，用到的时候再去读。

这个设计的直接好处是：你装几十个技能也不会把上下文挤爆。间接的好处是，它把写技能的要求也定下来了——描述写不好，技能就不会被触发；正文写太长，加载成本就上去了。 这两条基本就是技能能不能用好的一半。

一份最小的 SKILL.md 长这样：

---
name: article-summarizer
description: 对长文做三层总结：一句话概括、分段要点、文章结构梳理。当用户要求"总结文章""概括长文""提取要点""分析文章结构"时使用此技能。
---

## 执行步骤
1. 先输出一句话总结，控制在 50 字以内，让用户能一眼判断要不要继续看。
2. 再按段落输出要点，每段保留原有逻辑顺序，不合并、不重排。
3. 最后输出文章结构，说明它用的是哪种组织方式（提出问题到解决问题、时间线、并列论证等）。
4. 结尾附上处理方式说明：本次输入来自链接、本地文件还是粘贴文本。

## 禁止事项
- 不要添加原文中不存在的数据或案例。
- 不要因为篇幅长就省略中间段落。
- 不要在总结里加入个人评价。

头部的两行是必须的：name 只用小写字母、数字和连字符；description 要把"做什么"和"什么时候用"都写进去，后者尤其重要——它决定触发率。

技能装在哪里，决定了它的适用范围

这是新手最容易搞混的一层。同样是技能，放在不同目录，生效范围完全不同。

我自己的用法是：通用流程放个人级，跟某个具体项目绑死的放项目级。 比如"周报整理"这种我每周都要做的事，放个人级；某个客户的报价规则，放项目级。

有一个现象值得提前知道：项目级技能是"隐藏"的。 你在全局技能列表里搜不到它，只有在打开那个项目的时候它才出现。我一开始以为是自己没创建成功，翻来覆去折腾了几轮才反应过来——它就是只在那一个文件夹下面生效。

从零手工建一个技能，命令行里是这样：

# 个人级技能
mkdir -p ~/.skills/article-summarizer

# 项目级技能（在项目根目录执行）
mkdir -p .skills/article-summarizer

# 然后把 SKILL.md 放进对应目录

目录结构通常会用到三层，都很直白：

article-summarizer/
├── SKILL.md          # 入口：名称 + 描述 + 正文步骤
├── references/       # 参考文档：领域知识、字段说明、接口文档
├── scripts/          # 脚本：需要执行的代码
└── assets/           # 素材：模板、字体、图片、示例文件

除了 SKILL.md，另外三样都是可选的。一个只能做文本总结的技能，可能就只有 SKILL.md 一个文件，完全够用。 涉及调用外部接口的，才需要 references 放接口说明、scripts 放调用脚本。

技能和提示词，到底差在哪

很多人会问：我直接把提示词存成一段文本，用的时候复制一下，不也一样吗？部分场景下确实一样。差别在这几个地方：

用一句话概括这套东西的价值：它不是替代你的思考，而是把你已经想明白的事固化下来。

临时的一次性任务，继续写提示词就行，没必要为它专门建技能。但如果一件事你一周要做三次，或者你今天写了明天还要写、后天还要写，那它就该变成技能。

描述写不好，技能就是死文件

这里必须单独强调一下。技能不被触发，九成问题出在 description 上。

我见过的失败写法是：「用于处理文章。」

这句话没有信息量。它不知道"处理"是什么，"文章"又是什么范围。所以我一般会在描述里做三件事：

1. 说清楚做什么："对长文做三层总结"；
2. 说清楚输出什么："一句话概括、分段要点、结构梳理"；
3. 列一串触发词：把用户可能说出口的说法尽量都列上——"总结文章""概括长文""提取要点""分析结构"。

第三条最容易被漏，但效果最明显。真实使用里，用户的说法千奇百怪，你列的触发词越贴近日常表达，命中率越高。

另一个反面是正文太啰嗦。SKILL.md 正文应该短，长的东西挪到 references 里去。 因为正文是每次命中都要加载的，而 references 是按需读取的。这个成本账如果不算，装十几个技能之后你会明显感觉到响应变慢。

四、动手写第一个技能：从一次成功交付到可复用工作流

写技能最忌讳的一件事，是先想"我要做个什么技能"，再去想它能干嘛。这条路走到最后通常得到一个功能列表很漂亮、实际没人用的东西。

我的做法反过来：先手动跑通一次，把过程抄下来，再固化成技能。

五步法

整个过程大概是这样的：

1. 手动跑一次：用自然语言把这件事完整做一遍，中途哪里卡住、你补了什么条件、它猜错了什么，全部记下来。
2. 复盘过程：把这次实际发生的步骤按顺序列出来。注意是"实际发生"的，不是你设想中的。
3. 写成 SKILL.md：步骤、输入输出格式、禁止事项三段写清楚。
4. 放对位置：个人级还是项目级，按前面的表判断。
5. 双向测试：一次用自然语言描述需求，看它会不会自动触发；一次直接点名技能，看步骤走得对不对。

第五步不能省。我见过太多人只测了自动触发，结果在某台机器上换了个描述方式就不触发了，回头又去改正文，改了半天发现问题其实在第一行描述。

一个完整例子：文章配图技能

下面这份是我实际用过的结构，做了通用化处理。场景是：给一篇长文规划并生成配图，包含一张封面和若干张解释图。

---
name: article-visual-planner
description: 为一篇文章规划并生成配图方案，输出一张封面与若干张章节解释图。当用户提到"给文章配图""做封面""生成小红书配图""文章卡片"时使用此技能。
---

## 前置判断
1. 先完整读一遍文章，不要只看开头和标题。
2. 判断哪些章节真的需要配图。简单列表、过渡段落、纯引用段落通常不需要。
3. 不要机械地给每个小标题都配一张图，那是浪费。

## 执行顺序
1. 先输出完整的配图方案，包含：每张图的用途、核心信息、视觉风格、尺寸比例。
2. 等用户确认方案后，再开始生成图片。方案未确认前不要生成，避免白白消耗额度。
3. 逐张生成，每张生成后回报进度。

## 设计原则
- 封面围绕文章核心观点，只保留一个视觉焦点。
- 章节图一张只解释一个核心问题，不要在一张图里塞多个概念。
- 文中已有真实截图的位置，优先使用真实截图，不要用生成图替代。
- 全部图片保持统一的视觉风格、配色与字体，不要一张一个风格。

## 输出规范
- 所有图片统一输出到当前工作目录下的 output/images 文件夹。
- 文件名格式：01-cover.png、02-section-01.png，按文中出现顺序编号。
- 输出完成后，把文件清单和每张图的用途列成表格回报。

## 禁止事项
- 不要修改文章原文。
- 不要在方案确认前生成图片。
- 不要使用有版权风险的字库和素材，涉及商用的字体必须提示用户自行取得正版授权。

这份文件里有几个地方是踩过坑之后才加上去的，值得单独说。

第一，"先出方案再生成"。 生成类任务烧额度特别快。如果不加这一步，它可能一口气生成十几张图，等你发现风格全跑偏，额度已经花完了。

第二，"优先使用真实截图"。 这是个很实际的取舍。真实截图有说服力，生成图好看但可能失真。混搭的时候，让真实截图承担信息、生成图承担氛围，效果最好。

第三，整个流程要有统一的视觉约束。 这个坑我印象最深：有一次做一组八段的内容，前后风格完全不统一——前两段是写实风，中间两段变成卡通，后面又变成水墨。原因就是我描述画面的时候没给统一约束，它每一段各自发挥了。后来我加了一条硬约束：整组图统一为同一种视觉风格，从第一段到第八段不许跳。

第四，"不要修改原文"。 这一条在数据处理类技能里尤其重要，后面还会反复提到。

另一个例子：把长流程变成一条命令

再说一个更"重"的例子。有一套流程是这样：给定一个人物名字，先查资料定标题，再生成八段生平字幕，再给每段写画面描述，再批量生图，再把八张图做成图生视频，最后把这些片段拼成一条可以打开的剪辑草稿。

这套流程如果手动做，每一步都要重新交代一次，中间任何一步出问题都要回退重来。固化成技能之后，使用者只需要说一句"用某某技能做一个某某人物"，剩下的自动跑完。

技能里我写进去的关键约束是这样的：

把这张表写进技能，价值不在"它能自动跑"，而在"它每次跑的方式一样"。稳定比聪明重要得多。

技能里的"禁止事项"，比步骤更重要

大部分教程只教你写步骤，但实际用下来，禁止事项才是决定技能能不能长期用的那一半。

我几乎每个技能里都有这么几条固定内容：

• 不要修改、覆盖、删除我的原始文件；
• 不要在我确认之前执行不可逆的操作；
• 数据缺失时停下来问我，不要自己补；
• 涉及金额、日期的字段，处理规则以我给的为准，不要自己推断；
• 涉商用素材时提醒授权要求。

这几条的作用是给不确定性划边界。AI 有幻觉这件事是事实，你没法消除它，但可以把它关进笼子里——让它猜错的时候最多是"停下来问你"，而不是"直接改了你的文件"。

手工创建还是让它帮你创建

这类工具里一般会内置一个"创建技能"的技能。你可以直接跟它说"帮我做一个什么什么技能"，它会按标准结构把文件建好。

我建议初次上手先让它建，然后你自己打开文件回读一遍。我自己的做法是在无忆研习社（www.wuyi.wiki）上做完一轮实践之后，把跑得顺的技能统一回读一遍，把里面"我随手补的条件"提炼成正式条款——这一步做完，技能的稳定性会有明显提升，因为很多条款当时是临场想起来的，不写进去下次就忘了。

原因是我发现很多人写了半天没触发，问题不是内容不好，是格式错了——文件名不对、frontmatter 少了字段、目录层级多了一层。让它建，等于把格式这一步交给规范去保证；你自己回读，等于把内容这一步握在手里。

这算是整套流程里最省钱的一个习惯：格式交给它，判断留给自己。

五、技能从哪来、往哪去：找技能的三种方式与发布

第一周我基本没用上技能，因为不知道从哪儿找。后来摸清楚，其实就三条路，从"最省事"到"最省心"排一下。

三种找法，各有各的适用场景

第一种：在工具自带的技能区里搜。

这是最常规的路径。打开技能面板，上面一般是精选和推荐，下面按大类分——办公类、开发类、数据类、内容创作类、安全合规类。你可以把它当成应用商店用，只不过里面装的都是"别人写好的工作流程"。

这里有一个很多人没注意到的细节：只有你先标记了"去完成"这类任务状态，后面的安装和使用才会正常生效。 顺序反了，怎么对话都调不起来。

第二种：去专门的技能社区搜。

平台内搜索有个天然的限制——中文关键词覆盖不全的时候，搜出来的结果会很少，甚至搜不到。这时候换个地方搜，结果往往多好几倍。

以国内用户使用比较多的技能社区为例，它做的事情其实很明确：做海外技能生态的本土镜像，加一层中文索引，再加一层安全审核。 我看到的公开数据是收录了上万级别的技能，覆盖面比平台内搜索宽很多。

这类社区更实用的地方是筛选维度。它能按下载量、收藏量、最近上新排序。我个人最看重"最近上新"和"下载量"两个维度的交叉——刚上的东西往往针对的是近期的新需求，下载量高的说明别人已经帮你验证过了。

第三种：装一个"专门帮你找技能"的技能。

这一条是我最推荐的，因为它把前两种方式都变成了自动化流程。

做法很简单：先搜一个官方的技能查找器装上，之后你就不用自己去翻列表了，直接说需求——"帮我找一个能把公众号文章导出的技能"，它会自己去搜，把候选列出来，按契合度排序，你确认一个，它直接在当前对话里帮你装完。

这里有个必须提醒的点：这类"查找器"要认准官方作者。 我见过同名的第三方版本，功能描述看着差不多，但底层调的是哪家的接口、脚本里干了什么，你并不清楚。装技能和装软件是一个道理，来源比功能重要。

三种方式对比一下：

技能是怎么被审核上架的

如果你打算把自己的技能发布出去，了解一下审核机制有必要——它会直接影响你怎么写描述。

公开资料里能看到，国内这类技能社区大致走这么一条流程：

• 实名认证：发布前要完成身份核验，目的是建立可信的发布者身份；
• 内容审核：关键词过滤加语义理解，识别违规和低质内容；
• 安全准入：上架前要通过并行的几条安全检查，覆盖内容合规、代码漏洞扫描、模型安全评估，全过才上架，任意一条不过直接拒；
• 版本管理：发布全程有版本记录，可以回滚。

这套机制对我这种只想安心用技能的人是好消息。它意味着从公开渠道装到的技能，至少经过了一轮代码层面的检查，不至于在你机器上随便跑东西。

对想要发布的人也一样是约束：别想着写点投机取巧的东西上去，审核那一关基本拦得住。

发布自己的技能：六步

流程本身不复杂，走一遍就知道：

1. 先登录并完成实名认证。没认证发布不了。
2. 给技能起一个唯一标识。这个标识只在平台上唯一，以后别人靠它找到你。命名建议用能表达功能的英文短名。
3. 填好版本号。第一次发填个初始版本号，后面改动往上加。别觉得这东西可有可无，回滚全靠它。
4. 上传技能文件夹。注意用网页上传的时候，以点开头的隐藏目录默认不显示，你得先让它显示出来，或者换个方式传。
5. 等安全扫描。这一步的时间不确定，第一次发我印象中等了几分钟。
6. 收到通知后安装验证。装完之后自己用一遍，确认行为和本地一致。

发布之前我建议先做一件事：把自己的技能在另一台没装过的机器上试一遍。 很多技能在作者本机能跑，是因为作者机器上已经装好了各种依赖，换台机器就缺东西。这类问题只有换环境才暴露得出来。

装别人的技能，先看三件事

最后这一段算是安全提醒。用技能社区的东西，本质上是在自己的电脑上运行别人写的流程，有几个东西必须看：

"功能描述很干净、代码权限很大"是典型的危险信号。 这类东西装上去不一定立刻出事，但你不知道自己机器上多了什么。

装之前花两分钟看一眼详情页，比出问题之后再排查划算得多。

六、连接器与 MCP：让智能体长出能调用的手脚

技能解决的是"怎么做"，连接器解决的是"能碰到什么"。这两件事分清楚之后，整套工具的结构就清楚了。

用电器和插座来理解 MCP

MCP 这三个字母看起来唬人，其实用插座打个比方就懂了。

MCP 是一个标准插座规范。 它规定了插头长什么样、零线火线在哪、插上去之后怎么通信。任何一个服务方，只要按这个规范做一个"插头"，AI 就能通过它调这个服务；任何一个 AI 工具，只要实现了"插座"，就能接所有按规范做的服务。

在 MCP 出现之前，每接一个外部系统都要单独写一套对接代码，服务方和工具方的组合数量一多就爆炸。有了标准之后，接一次就行。

而连接器，可以理解成已经帮你接好线、插好插头的插座。 你不需要写代码、不需要部署服务，点一下加号、完成授权，就能用。这就是为什么连接器里能看到一堆常见的办公系统——它们已经被适配好了。

分类大致是这么几摊子：

最后一行是这套东西最有想象力的地方。只要你们公司的系统能对外提供 MCP 服务，就能接到工作台上来，让它替你操作内部系统。 这一步对个人用户意义不大，对团队用户是质变。

一个完整的接入过程：以飞书为例

配置类的操作光看文字很虚，我把它拆成一个完整流程。飞书这套东西在国内办公场景用得最多，也最有代表性。

前提是你得有一个飞书账号，并且能进开放平台创建应用。

第一步：创建企业自建应用。 在开放平台点"创建企业自建应用"，填名称、描述、图标。名称随便起，反正是你自己用的。

第二步：添加机器人能力。 在应用能力里找到机器人，点添加就行，不用额外配置。

第三步：批量导入权限。 权限是这一步最麻烦但也最关键的地方。一般流程是先清空默认权限，再把准备好的权限清单批量导入，然后提交申请。权限给多了是安全隐患，给少了功能跑不通，所以在导入之前最好先想清楚这个应用要干什么。

第四步：拿应用凭证。 到"凭证与基础信息"页面，复制 App ID 和 App Secret。这两个东西等同于你家的钥匙，尤其 Secret，泄露了别人就能以你的身份调用接口。

第五步：把凭证配置到工作台。 在工作台的助理设置里选择连接方式，把两个值填进去，注册。填完之后建议重启一次应用——我自己遇到过一次不重启就连不上的情况。

第六步：发布版本。 应用配置改动之后要发一个版本才会生效。版本号随便填，说明也不用写，点保存、确认发布。发布成功后状态会显示为已发布。

第七步：配置事件接收。 这一步是为了让机器人能收到别人发给它的消息。到事件管理里配置订阅方式，选长连接接收事件，点验证，验证通过后保存。

第八步：添加"接收消息"事件。 在上一步的配置里添加具体的事件类型，找到"接收消息"这一项加上。

第九步：配置卡片回调。 这一步是为了让按钮、卡片上的点击操作能被接收。同样是验证长连接、保存，然后添加"卡片回传交互"这个回调。

第十步：再发布一次版本。 第八、第九步的改动同样需要发版才生效。

跑完这十步，回到飞书里给这个机器人发一条消息，如果消息能被正确处理并在工作台里看到，链路就通了。

我把这套流程里最容易卡住的几个点单独拎出来：

MCP 的配置文件长这样

如果你想接的不是内置连接器，而是自己找的 MCP 服务，通常是在配置文件里加一段。结构很统一：

{
  "mcpServers": {
    "feishu": {
      "command": "npx",
      "args": ["-y", "feishu-mcp@latest", "--stdio"],
      "env": {
        "FEISHU_APP_ID": "cli_你的应用ID",
        "FEISHU_APP_SECRET": "你的应用密钥"
      }
    }
  }
}

关键就三样：启动命令、启动参数、环境变量。环境变量里放的就是凭证，所以这个文件本身要当敏感文件对待，不要提交到公开仓库，不要贴到聊天记录里。

大多数平台也提供复制粘贴服务地址的方式，对于托管型的 MCP，直接粘一个地址比手写配置省事。

关于密钥的三条硬规矩

这一段我想单独说，因为它是这套东西里唯一"出事之后不可挽回"的部分。

第一条：密钥不要明文发给任何人，包括 AI。 演示的时候我一般用占位符，不会把真实密钥贴过去。有些教程图省事直接贴，你照着做，密钥就散落在对话记录里了。使用的时候让 AI 直接从环境变量文件里读，不经过对话。

第二条：密钥一旦泄露，马上换。 换的成本很低，不换的后果不低——别人可以拿着你的额度去调用。

第三条：能用白名单就用。 如果服务方支持 IP 白名单，配上。这样即使密钥泄露，别人从别的机器也调不动。

顺带说一句关于境外服务的事。有些第三方 MCP 服务部署在境外，接入之前要弄清楚两件事：一是数据会不会出境、传到什么地方去；二是服务的可用性有没有保障。境外模型与服务的使用需要遵守国内网络与内容管理相关规定，涉及用户数据、商业数据的场景，更要谨慎评估。能用境内合规服务解决的，优先用境内的。

连接器的价值其实在"免配置"

最后说个观点。

市面上做智能体的工具不算少，能把连接器生态做起来的却没几个。原因不在技术，在生态——要让一堆第三方系统愿意为你的标准做适配，这活儿只有生态够大的公司干得动。

所以对使用者来说，这东西的价值不是"功能多"，而是"我不用自己配"。自己想接一个外部系统，从读文档、写代码、调权限、处理异常，到跑通，一个下午就没了。而现在点一个加号的事。

这也是我判断一个智能体工具值不值得学的核心标准之一：看它连接器列表有多长、更新有多勤。 技能可以自己写，知识库可以自己建，但连接器生态这块，个人是补不上的。

七、知识库对接：把记忆从浏览器缓存搬到长期资产

有个细节我观察了很久：大多数人搭工作台的第一次尝试，都是让 AI 生成一个单文件的网页。

它确实很快，一两分钟出一个漂亮的仪表盘，能做增删改查，能出图表。然后过两周你再打开，发现数据没了。

原因很简单——数据存在浏览器本地存储里。 你清了缓存，数据就没了；你换个浏览器，数据就不见了；你换台设备，那里是空的。

这不是工具的锅，是方案选错了。要理解这件事，得先把"数据存在哪儿"这个问题想清楚。

数据放在哪儿，决定它能活多久

看这张表就很清楚了：如果这个东西你打算用超过一周，就别用第一行。

我自己现在的做法是分两层：能随手导出备份的用本地，需要长期累积的放云端。

还有一个隐蔽的坑值得单独提。有些人搭完工作台之后，会误以为"数据存在本地"只是个小瑕疵，反正有导出功能。但真正的麻烦在于你不知道数据在哪。你只是想清理一下系统空间，随手点了清理缓存，几个月的记录就跟着没了，而你可能过了好几天才发现。

三类云端落点，按需求选

第一类：云端多维表格。 这是目前最好上手的方案。表格是结构化的，天然适合放"账号清单""采集记录""任务列表"这类东西。好处是不用管域名、不用管服务器、不用管部署，而且手机端和桌面端天然同步。

这也是我特别推荐的一个组合用法：用工作台负责生成，用多维表格负责沉淀。 你在这边让它干活，产物直接写进云端表格，手机上打开就能看。

第二类：个人知识库。 适合放非结构化的东西——文章、公众号内容、随手记的想法、需要长期参考的资料。它的特点是"你收藏什么它就知道什么"，反过来也成立：你没收藏进去的东西，它就真的不知道。

第三类：企业级知识库。 适合团队场景，支持多源资料纳管和分类治理，可以做成组织级的资产。个人用户用不上，但如果你在意"知识怎么在团队里流动"这件事，值得了解一下它的设计思路。

一套能长期活着（而不是搭完就荒）的目录结构

这是踩坑最多的地方。大部分人建知识库的失败方式都一样：建了一堆文件夹，然后不知道往哪儿放。

我摸索出来一套还算好用的结构，一共六个目录：

知识库根目录/
├── 00-收集箱/        # 临时的、还没分类的，随手往里扔
├── 01-项目/          # 有明确目标和交付时间的任务
├── 02-主题知识/      # 长期积累的领域知识，按主题分
├── 03-原始资料/      # 从外部拿到的原文，只读不改
├── 04-成果输出/      # 知识库产出的成品：报告、文章、方案
└── 05-归档/          # 已经结束、暂时不用再看的东西

每个目录的职责，最好写清楚：

"收集箱"这个设计是整个结构里最值钱的一环。 因为它把人从"我现在得想清楚这东西该放哪儿"这个负担里解放出来了——随手扔进去，回头让 AI 统一整理。人做自己擅长的事（记录），AI 做它擅长的事（归类）。

顺手记，比整理整齐更重要

还有一条经验，看起来跟工具没关系，其实关系最大：知识库能不能用起来，取决于你往里放了什么，而不是它建得多漂亮。

我踩过一段时间这种坑：资料这边放一点，手机上记一点，聊天记录里留一点。结果要用的时候，AI 只知道知识库那一部分，另外两部分的上下文它是空白的，回答自然不贴你的实际情况。这种感觉特别像"巧妇难为无米之炊"——不是它不行，是它没米。

所以我现在有一条很粗的规则：跟长期工作相关的信息，第一落点就是知识库；手机端的随手记，尽量也直接进知识库。

手机上收藏的路径其实不复杂，大致是：

1. 在手机上先打开一次知识库的小程序，这一步是为了让它在系统的分享入口里出现；
2. 看到值得存的内容，用系统分享菜单里的"更多打开方式"，找到知识库；
3. 选择要存放的库，确认，它会自动解析入库；
4. 到工作台里，通过连接器选中这个库，就能精准调用这篇文章了。

第 1 步容易被跳过，然后就会遇到"分享菜单里找不到它"这种事。打开一次，是为了让系统认出它。

知识库里的东西怎么被用起来

两种用法，一种是检索，一种是回传。

检索：通过连接器挂上知识库，然后让 AI 从里面找资料。这里我建议用法上尽量具体——不要笼统地说"从我知识库里找点相关资料"，而要说"从某某知识库里，找那篇关于什么什么的内容"。范围越小，它找得越准。

回传：让它把生成的产物写回知识库。这一步很多人不做，结果就是每次都要从零开始。做了之后，你下次调用的时候，它就知道"上次已经出过一版"，而不是重新造一遍。

一句总结

知识库这件事，本质上是在回答一个问题：你希望三个月后，AI 还记得什么？

你希望它记得的，就得让它能被读到的形式存在那儿。做不到这一点，它每次都从零开始，你也就永远在重复输入同一批背景信息。

八、场景实战：文档、表格与数据分析里那些对不上的数字

这一章讲我踩过最狠的一类坑。

数据类任务是这类工具最高频的使用场景，也是最容易"看起来做完了、其实全错"的场景。原因前面提过一次：错误的数据往往比错误的分析更难看穿，因为它看着特别正常。

脏数据通常就三类

我从原始表里见过的脏数据，基本都能归到三类：

1. 重复行：同一条记录出现两次甚至三次，来源通常是多次导入同一批数据。
2. 异常日期：日期字段是空的、格式不一致的、或者落在一个明显不合理的年份上。
3. 必填字段缺失：比如客户名、渠道、金额某一列为空。

这三类问题的处理方式完全不同。重复行有时候该合并，有时候该保留（比如那本来就是两笔独立订单）；异常日期有时候该排除，有时候该按规则补全；字段缺失的处理更依赖业务判断。

所以我不建议用一句"帮我清理一下数据"这种指令。该做的是：让它先把问题列出来，你判断怎么处理，再让它执行。

口径不清会具体造成什么后果

我用一个虚构的、但结构真实的例子说明。假设有一份原始订单表，一共 142 条记录，我要的是有效订单数、销售额、渠道分布三个指标。

跑完第一版，出来的数字是这样：

这里有个数字上的细节容易被忽略，我特意标一下，因为读者最容易在这里犯嘀咕：原始表是 142 条，最终算出来的有效订单是 116 条，中间差的这 26 条去哪儿了？答案是全部进了排除清单，一条都没有凭空消失。拆开看是这样的：

• 第一版漏掉的 5 条：已退款、已取消的订单被它悄悄算进了有效订单，所以第一版报出来是 121 条（121 − 116 = 5）；
• 剩下的 21 条：日期为空或格式无法解析、必填字段（客户名、渠道、金额）缺失、以及完全重复的行，从一开始就该被排除；
• 5 + 21 = 26，正好对上 142 − 116。

换句话说，"142 条扣掉 116 条"这个差额不是损耗，而是一份可逐条追溯的排除清单。 如果它只给你一个 116，却不告诉你那 26 条为什么被拿走、分别是什么原因，那这个数字你就不该信——因为你没法判断它是不是把不该排除的也一起扔了。

第二版我补了口径约束之后，数字对上了，同时它多输出了一张"排除清单"，列出被排除的记录和原因，上面这 26 条一条不落地都能在上面找到。

前后两次的差别不是我改了什么技术细节，而是我把口径说死了。

那张排除清单才是真正有价值的东西。因为它把"它猜了什么"摆到了台面上，我可以逐条检查：这条该排除，那条其实不该排除，反馈回去再跑一遍。没有这张清单，我只能对着汇总数字发呆。

一份可以直接抄的口径约束模板

# 口径声明（严格执行，不得自行推断）

## 统计范围
- 时间字段：order_time，区间 2026-01-01 到 2026-03-31（含首尾）
- 只统计 status 为"已完成"的记录
- "已退款""已取消""待支付"一律排除，并单独列出

## 金额处理
- 币种：若 currency 字段非 CNY，按 order_time 当日中间价折算为 CNY
- 折算后的记录必须标注"已折算"
- 金额保留两位小数，不做四舍五入到整数

## 比率计算
- 折扣率 = （原价 - 实付）/ 原价
- 分母一律使用原价，不使用折后价
- 比率保留两位小数，以百分数形式呈现

## 异常处理
- 完全重复的行：标记后排除，不出现在任何汇总中
- 日期为空或格式无法解析：排除，计入异常清单
- 必填字段（客户名、渠道、金额）缺失：排除，计入异常清单

## 输出要求
1. 汇总表：指标 | 数值 | 来源列名 | 计算说明
2. 排除清单：记录行号 | 排除原因 | 原始内容
3. 结论：事实部分与推论部分分开写，推论必须标注"此为推断"

最后一条"事实与推论分开写"特别值得单独拎出来。我见过不少报告，前面几行是数字，后面就滑到因果判断上去了——"某渠道订单量最高，说明我们的运营策略更有效"。订单量高和策略有效之间，最多只能说存在关联，不能说存在因果。 让它把推论单独标注，这类越界的表述会少很多。

验收三个问题

跑完之后，别急着用。对着这三个问题过一遍：

第一，每个关键数字能不能回溯？ 随便挑一个数字，回原始表里查。查得到，说明它不是编的；查不到，整份东西都要重看。

第二，状态有没有被分开？ "已完成""进行中""待确认"必须分列。尤其是做周报这类东西，本周没做完的任务被写成"已完成"，那就是在给后面挖坑。

第三，原始文件被改了吗？ 看文件的最后修改时间。如果不是你预期的时间点，说明它动过你的原始文件——这时候先找回备份，再去看技能里的"禁止修改原文件"那条是不是没写。

图表好看，不代表数字对

最后说一句得罪人的话。

这类任务最大的风险，是被"漂亮"骗过去。 一张配色舒服、标注清晰的图表，会让人本能地降低警惕。而数据类任务恰恰是幻觉代价最高的地方——它后面接着的是汇报、是决策、是跟钱有关的事。

所以我对数据类任务的态度是：宁可多花五分钟做随机抽检，也不要省这五分钟。

具体做法也很笨：随机挑三到五条记录，手工核对；再挑一到两个汇总数字，手工加一遍。这几分钟花下去，你会对最终结果有完全不同的信心。

九、场景实战：从零搭一个自媒体创作工作台

前面几章都是零件，这一章开始装整机。第一个完整场景是搭一个创作工作台——它把技能、连接器、知识库三样东西全用上了，特别适合当综合练习。

先决定两件事：数据放哪、页面怎么来

这个场景的最终形态是"一个能在浏览器或手机上打开的页面，用来管理账号、采集对标数据、记录创作进度"。

但一上来不要想页面。先决定数据放哪，因为它决定了后面所有设计。

我的建议直接是第三条。 不是为了炫技，是因为第一条路走到第三天你就会开始担心数据。

页面是怎么被"说"出来的

整个过程其实不写代码，用自然语言说需求。但说法有讲究。

第一步，先要结构图，别要代码。

我一开始犯的错是：一句话让它"做一个创作管理后台"，然后它哗啦啦写了一大堆代码，生成一个页面。打开一看，菜单是它自己想的，字段是它自己猜的，跟