我在办公电脑上把这 15 个 Skill 跑了一遍, AI 才真正开始像个同事

摘要 · SUMMARY

15 个 Skill 都不错，但真正有用的不是把它们全部装上，而是让它们分别站到读、做、管、写、发五个工位上。

我刚把上一篇 Agent 生产线的文章写完，脑子里还卡着一件事。

生产线有了，然后呢？

正好，程序员小灰之前整理过一篇 WorkBuddy Skill 长文，里面这 15 个 Skill，我在自己的办公电脑上也都调用过，整体感受是真的不错。

但先把边界摊开。这不是我在当前电脑上做的复测。本文也不把这 15 项写成同机、同任务、同版本的正式横评。我没有为这篇文章提供逐项耗时、成功率、具体文件和报错记录，没有证据的数据，我就不编了。

我能确定的只有一件事，这 15 个值得拿出来聊。

可把它们全部摆到桌上以后，我突然觉得，继续从第 1 个讲到第 15 个，意义不大。你看完可能只是多了一份收藏，等工作真的砸过来，还是不知道先叫谁，谁又该把什么交给下一个。

— 脑子提供能力，管线组织协作，工位 SOP 决定具体动作。

模型会思考，Harness 能接工具、会话和工作流。可 PDF 进来先提取什么，Excel 最后交什么格式，项目结束后哪些文档要更新，这些琐碎但要命的事，谁来告诉 Agent？

总不能每次开工，都让人重新站在旁边念一遍操作手册吧。

问题不是还缺不缺第 16 个 Skill。

是眼前这 15 个，有没有站到正确的工位上。

所以今天，我想把它们从墙上全部拿下来，重新装成 5 个工位。

读进来，做出来，管得住，写出去，发出去。

— 15 个名字重新站队以后，才看得见一条完整办公流水线。

先聊聊 Skill 到底是什么。

很多人会把它理解成一段更长、更专业的 Prompt。毕竟打开一个 Skill，最先看到的往往就是一份写给 Agent 的说明。

再往里看一层，就不太一样了。

Agent Skills 的基础格式是一整个目录。里面有必须的 SKILL.md，也可以带脚本、参考资料和素材。先做什么，能调用什么，最后交什么，遇到风险在哪里停，这些都能装进去。

这很像新同事入职。

人可以聪明，但入职第一天，不会凭空知道公司的合同模板、报销目录、汇报版式和删除权限。你也不会因为他脑子好，就让他自己猜完整套规矩。

Skill 不是给聪明人补智商，它是在把老员工反复交代的那套规矩，写成机器能执行、人也能检查的 SOP。

当然，偶尔才做一次的小事，直接跟 Claude Code、Codex 或 WorkBuddy 聊往往更快。不是每件事都值得工程化。可一旦某项工作高频、重复、还总返工，操作手册的价值就出来了。

这里还有个很容易踩的坑。

同一个 Skill 目录可以在支持 Agent Skills 的产品之间迁移，不等于搬过去就能原样运行。Claude Code、Codex、WorkBuddy 的安装位置、点名方式、权限、工具和依赖都不完全相同。有的要 Python，有的要浏览器扩展，有的还要图像生成后端。

格式兼容，只说明门的尺寸差不多。

不说明水电和机器已经全部接好。

需要它时，在指令里点名 Skill，把输入、输出和边界讲清楚。具体用什么语法，看宿主自己的规则，别把一个产品里的斜杠命令当成全行业通行证。

— 不是只把 Skill 装上，而是带着输入、产物和边界去叫它。

还有，这 15 个来自不同项目和仓库，许可也不一样。Anthropic 的 xlsx、docx、pptx、pdf 参考 Skill 采用源代码可见的专有许可，不能一股脑都叫开源。

仓库里堆满扳手，不叫工厂。

扳手出现在正确的工位上，才有机会变成生产线。

很多工作最早的卡点，不是 Agent 不会写，而是原料进来的时候已经乱了。PDF 有扫描页和表格，网页挂着登录态，热点还在不停变化。入口没处理好，后面写得越快，错得也可能越快。

它像拆箱工，不只复制文字，还把表格提取、OCR、拆分合并、表单处理和页面视觉核验放到一条流程里。

但它不是透视眼。扫描件糊了，OCR 就可能看错。文件有密码，也得先有合法密码。重要内容仍然要回原页面核。

文件读完，再往外走一步，就是已经登录账号的浏览器。BrowserSkill 通过命令行、本地守护进程和扩展，把 Agent 接到 Chrome 或 Edge 里。

看到「控制浏览器」，别立刻脑补成全网无人驾驶。验证码、登录、支付和敏感确认，该让人接管就得接管。组件要安装，浏览器要授权，网站自己的规则也得守。

再往前，输入变成了每天变化的信息流。aihot 用匿名只读接口查询中文 AI 精选、热点和日报，不需要额外配置 API Key 或 MCP。

我更愿意把它当雷达，不当裁判。

雷达告诉你今天先看哪里，哪些事件正在升温，不替你宣布全网真相。涉及数字、政策和原话，还是回到原始来源。它的策展范围也不等于整个互联网，对外商业使用还要看数据服务自己的条款。

文件、网页、实时信息，三个入口一路往外推，但你今天不用全接。

先挑一个每周都会读的输入源，把取资料、提重点、留出处写清楚。

原料进不来，后面 12 个 Skill 再强，也是在空转。

Agent 在聊天框里回了一段 Markdown，算交付了吗？

如果同事最后要的是 Excel、Word、PPT，或者一个能打开的网页，那当然还没有。总不能把一段「你可以复制到表格里」的建议转给同事，然后宣布自己下班了吧。。。

xlsx 先把这件事拉回真正的表格文件。读取、创建、清洗、公式、格式、图表和错误检查，交出去的是能继续编辑和核验的表格，不是一段长得像表格的文字。

官方还专门要求检查公式错误。

你想想看，既然要检查，就不能闭眼信。宏、外部数据连接、复杂模板和已有工作簿的细节，正式交付前都得核。

到了 docx，问题变成了一页纸到底像不像真的 Word。标题层级、目录、页码、页眉、图片、批注、修订，做完以后还得看渲染出来的页面。

不过它会做 Word，不代表它会替法务判断合同。文件格式和内容责任是两回事，碰到合同、制度和正式通知，专业复核不能省。

pptx 又多了一层，内容不只要装进去，还要能讲出来。它把大纲推进成可编辑的演示文件，把模板、布局、素材、备注和渲染检查一起纳入流程。

正式汇报还是得一页一页看。有没有溢出，品牌色对不对，引用有没有来源，逻辑能不能讲通。Skill 能把起点抬高，不能给你发免审通行证。

表格、文档、演示，走到这里变成页面。frontend-design 不只是让 Agent 多写几个组件，它会逼着 Agent 围绕主题、受众、字体、色彩、版式和交互，做一套有理由的选择。

别上来又是紫色渐变、超大圆角、三张卡片。。。熟悉得像同一个模具里倒出来的。

一份设计规则当然不会自动长成专业设计师。品牌系统、真实用户、不同设备和最终审美，依然要有人判断。

所以这个工位开工前，先把交付物写死。

要 .xlsx、.docx、.pptx，还是可运行页面。公式要不要保留，是否需要批注，谁来逐页检查。聊天框里说得再漂亮，没变成可验收的东西，工位就还没下班。

这话听着有点反常识。

大多数 Agent 演示都停在生成成功。表格出来了，网页打开了，代码跑通了，彩带一放，结束。

可公司里的工作，很多时候从这里才开始。

任务边界有没有写清，文档有没有跟上变化，文件敢不敢删，票据能不能归档。这些事不炫，却决定了一条生产线能不能长期跑下去。

leader 像开工前的项目经理，把一句模糊的「你帮我把这个搞好」，整理成带调研、边界、验收、防作弊和断点续跑要求的目标任务书。

它有个特别重要的动作，把不能做什么也写进去。

Agent 很擅长完成字面目标，有时候甚至擅长得让人有点害怕。红线没写清，它就可能找一条你根本没想到的捷径。

但 leader 自己不负责执行。它交的是任务书，不是结果。后面跑得怎样，依然取决于执行 Agent、环境和目标质量。

如果 leader 管开工，neat-freak 管的就是收工以后，那些没人爱看但迟早要还的后账。

代码已经走到第 8 版，README 还停在第 1 版。运行状态变了，规则文件没变。项目已经结束，工作区里还躺着一堆不知道该不该留的东西。

neat-freak 会去对齐代码、运行状态、README、docs、规则、获准维护的记忆和工作区残留，再把已验证、已修改、待处理和不适用说清楚。

我很在意它对删除的态度。

删除候选先报告，真正清场前再确认。不是一看见残留就兴奋地挥起扫把。收尾最怕的不是手慢，是它动了什么，你还不知道。

另一本后账，藏在电脑空间里。

storage-analyzer 先在 macOS 或 Windows 上做只读扫描，再把占用分成绿色、黄色和红色，生成 HTML 报告。大白话就是，可清的，要判断的，别乱动的。

这套分级我是真的喜欢。

因为磁盘清理最怕的不是没删干净，是删得太干净。。。

但这块得说准确。扫描阶段只读，不代表后续处置永远不写入。真要移动到废纸篓或删除，仍然需要用户点击并再次确认，报告里的可释放空间也只是估算。

还有一本后账，直接连着钱。

invoice-organizer 会从 PDF 和图片里提取供应商、日期、金额等字段，先拟定统一命名和目录。计划获批后默认复制归档并保留原件，看不清的地方单独标出，也能生成 CSV 汇总。

顺序别反了。

读取，拟方案，确认，再归档。

发票不会因为被 OCR 读出来，就自动获得税务正确性。金额、类别、隐私和最终判断，必须由人或会计复核。

这 4 个 Skill 没有一秒造出网页，也没生成一张炫酷图片。

可我反而觉得，它们最接近真实办公室。

因为它们都在回答同一个问题。

Agent 什么时候必须把决定交还给人？

删除、移动、登录、支付、合同、发票、外部发布，我自己的建议是默认都留一个预览和确认口。不是不相信 Agent，是责任不能跟着自动化一起消失。

生产线成熟以后，不该只会往前冲。

它也得知道，哪里必须停。

它给中文公众号长文放进一套明确的口吻、节奏、结构和四层自检规则，也能从 PDF、链接、语音转写进入写作。

这一篇，正在按这套规则往下写。

但有句话很容易被文风盖过去。

风格可以被 Skill 约束，人生不能被 Skill 补写。

我在办公电脑上调用过这 15 个，整体觉得不错，这是我能说的真实体验。至于某个 Skill 帮我省了多少时间，哪一次报了什么错，我没有提供记录，写作模型就不能靠文风把它们演出来。

khazix-writer 管的是怎么说，不负责替你决定什么是真的。动态事实还得研究，引用还得核，第一手经历必须来自真的发生过。

所以写作这条线，我更建议把事实来源和表达风格拆成两道工序。动笔前锁住证据边界，写完以后再做一次事实核查。

文风越像活人，越不能拿来遮事实的空。

公众号这条线，最容易在最后 10 米翻车。

封面少一个字，图片里多一只手，排版粘进编辑器突然掉样式。前面几千字都写好了，临门一脚却像从碎纸机里捞出来的。。。真的就是一声叹息。

它会把「做张封面」拆成画幅、色彩、渲染、文字和氛围几个可控决定，再交给宿主里可用的位图生成后端。

这比只丢一句「给我做得高级一点」靠谱得多。高级这两个字，差不多等于把审美问题重新扔回空气里。

但图像模型会写错字，它也需要真正可用的图像后端。生成不对就重来，别把错字当成一点点瑕疵直接发出去。

它先判断这段为什么需要图，再从类型、风格和色板去组织配图方案，不会机械地给每个小标题塞一张图。

这个顺序挺重要。

一张图应该解释、转场，或者让读者停一下，不是为了证明作者会调用生图模型。

不过会判断配图位置，不代表结果可以无人检查。它需要偏好配置、确认和图像后端，图中文字、数字和事实性结构都得看。

最后，gzh-design-skill 把 Markdown 映射成样式内联的公众号 HTML，套入预设主题和通用组件，再用校验脚本和复制预览页，把交付风险往下压。

它只负责排版，不替你写文章，也不能替微信编辑器做最终担保。

这一篇的正文继续用小黑，封面柔和一点，排版用摸鱼绿。配图、封面、HTML，各自在自己的工位上干一件清楚的事。

发布前，我会固定看三遍。

封面标题有没有错字，正文图片有没有事实性错误，HTML 粘贴后的手机预览是不是正常。

内容写完不叫发布。

真的被读者看到，而且没在最后一步翻车，才算从最后一个工位交出去。

到这里，15 个 Skill 全部上桌了。

然后我要给一个可能有点扫兴的建议。

— 好工具全开，也可能把最简单的门堵住。

WorkBuddy Enterprise 官方文档支持把已安装的 Skill 关闭后再启用，也建议只启用当前任务需要的那些，减少无关干扰和误调用。Agent Skills 的规范本身采用渐进式加载，不是所有 Skill 的全文一开局就塞进上下文，但开得太多，仍会增加发现和选择的噪声。

15 个都不错，不代表 15 个要同时站在生产线上。

你可以先挑一件每周都会重复、而且特别容易返工的工作。

再从 5 个工位里，只选 2 到 4 个必要的 Skill。写清上一个工位交什么，下一个工位接什么，哪里必须停下来找人。

跑完以后，也别急着继续安装。

问自己三个问题。

哪一步还要反复解释？

哪一个产物交到下一站就乱了？

哪一种高频动作，值得沉淀成自己的 Skill？

这里说的「跑一条线」，是组装方法，不是我声称已经把这 15 个在同一个真实任务里从头串到尾。不同任务会跳过一些工位，也会来回经过同一站。

做内容，可以从 aihot 或 BrowserSkill 进来，核完原文，再接写作、配图和排版。做长项目，可以让 leader 先把目标写清楚，收工后再让 neat-freak 对齐后账。处理文件和票据，可以先让 storage-analyzer 或 invoice-organizer 出方案，中间故意停一下，让人确认。

这些只是可尝试的组装路径，不是我拿虚构经历拼出来的成功故事。

第三方 Skill 还可能读取本地文件、账号凭证或访问外部服务。安装前看看来源、脚本和权限，别把安全审计也外包给推荐者。

我有时候觉得，Agent 这波最容易被低估的变化，不是模型又多会一道题。

是人的经验，开始有机会被写成机器能读、人也能审的东西。

工业化改变生产，从来不只是机器变大。工位、交接和质量标准写清楚以后，个人经验才有机会被一遍遍用下去。

Skill 最让我兴奋的地方也在这里。

一家公司真正难复制的东西，往往不是模型 API，而是藏在老员工脑子里的判断顺序、红线、模板、复核动作和交接习惯。

以前这些东西经常只剩一句话。

我们一直都是这么做的。

现在，它们可以慢慢变成一份份能执行、能验证、还能继续修改的岗位说明书。

当然，不是每个习惯都值得做成 Skill。低频任务直接聊可能更快，高风险动作仍然要人确认，这 15 个也不一定适合所有人。

把更多真实工作写成稳定的 SOP，本来就需要持续摸索。这里肯定有学习成本，一开始甚至可能比直接动手更慢。

但我还是觉得，这件事值得开始。

第 21 篇，我们解决的是 Agent 怎样才算真的交卷。

第 22 篇，我们打开了生产线。

到了第 23 篇，终于轮到把人的工作方法，放进每一个工位。

所以今天不用装 15 个。

就找出你最痛的那一站。

读不进来，做不出来，管不住，写不出去，还是发不出去？

把那份你已经对 Agent 反复解释过的工作，先写成一份 SOP。

回到最开始那 15 把扳手。

仓库里堆满扳手，不叫工厂。

工位被写清楚以后，Skill 才真的开始工作。

以上。

如果这篇对你有点用，欢迎点个赞、在看，也可以转给那个一直在收集 Skill，却还没把自己的工作流接起来的朋友。

也想问问你。

你现在最想补的是哪个工位，读进来、做出来、管得住、写出去，还是发出去？

我是 35号底牌，持续记录企业 AI 的真实落地过程。