WorkBuddy 最值得装的 15 个技能推荐清单（9月版）

最近好多人在问 WorkBuddy 到底哪些技能值得装。市场上能搜到的 Skill 已经不少，社区推荐也有，但很多清单要么只给个名字，要么催着你全部装完，实际用起来反而拖慢速度，还容易让模型犯选择困难。我前后用 WorkBuddy 跑了两个多月，从入门到本地化部署都踩过一遍，这篇就按9月最新的使用体验，整理出我最常驻的15个技能。排名不分先后，重点是讲清楚每个技能解决什么问题、适合什么人、配置时要注意什么。如果你刚开始接触 WorkBuddy，或者装了十来个技能却觉得没什么区别，这篇应该能帮你省不少时间。

1. 先聊两句：WorkBuddy 的 Skill 到底是什么

1.1 为什么技能比模型本身更影响体验

WorkBuddy 本质上是一个 AI 工作台，它很擅长理解任务、拆解任务，然后调用各种工具去执行。但“擅长”是有条件的：模型本身能力再强，也不知道你项目的代码规范、不知道你的日志格式、不知道你们团队的文档结构。这些信息靠什么传给它？一部分靠对话里反复交代，另一部分就靠 Skill。

Skill 可以理解成“给模型的一份岗位说明书 + 操作SOP”。你装上某个技能，WorkBuddy 遇到相关任务时，会自动读取这份说明，按步骤执行。我习惯拿新人入职做类比：模型是那个脑子转得很快的实习生，Skill 就是入职手册。没有手册，实习生只能临场发挥，能力强但发挥不稳定；有了手册，套路明确了，输出质量就稳定了。

用一个很常见的例子说明差别。同样是给一段乱七八糟的日志，不装技能时模型可能会直接复制粘贴原文，最多加一句“这里有报错”；装上日志排查类技能后，它会先做时间排序、错误聚类、频率统计，再给出可能原因和建议动作。同一个模型，有没有技能，产出完全是两个水平。所以我才说，想让 WorkBuddy 真正好用，优先级不是换更大参数的模型，而是把技能体系搭起来。

1.2 技能选型原则：千万别贪多

很多人一上来就把市面上热门的技能全装了，结果发现模型反而变笨了。原因很简单：技能太多，模型不知道选哪个，可能在无关紧要的地方加载了一个不相关的技能，也可能多个相似技能同时命中导致行为混乱。我自己的经验是，先保持克制，核心保留 5 到 8 个，日常轮换 10 个左右，最多不要超过 15 个。

选型还要贴合自己的使用场景。写代码为主，就优先开发类技能；做产品和运营，就优先文档和内容类技能；维护服务器，就优先运维和日志类技能。不要看别人说好用就装，先问自己一周里会不会用到。还有个小原则：同类技能只留一个。比如代码审查类装一个就够了，装三个反而互相打架。下面这份清单，就是我从二十多个技能里不断做减法之后留下来的，算是相当克制的组合。

2. 最值得推荐的15个技能（9月版）

2.1 技能总览表

2.2 跨对话记忆：解决“转头就忘”的问题

这个技能排第一，因为绝大多数人最先遇到的痛点就是“换个会话，WorkBuddy 就不认识我了”。不装记忆类技能，新对话里就要重新讲项目背景、目录结构、技术栈，真的很烦。我的用法是让 Memo 技能维护一个项目记忆文件，路径固定在项目根目录下的.workbuddy/memory.md，每次会话开始先读，结束时把结论追加回去。

实操中我会把它和全局规则配合：全局规则负责“不变的约定”，记忆文件负责“会变化的事实”，比如最近用到哪个端口、哪个服务部署在哪、某个模块的负责人是谁。这样做的好处是新开对话也不用反复交代背景。有一点要特别注意：记忆文件不能无限膨胀，我只让它记录结论、不记录过程，超过 80 行就触发摘要重写，否则会反过来吃掉上下文窗口。

2.3 代码审查：给代码多一道安全闸

这个技能适合所有做开发的人，尤其是要负责 code review 的场景。它读 diff 和变更文件，能发现 bug、规范问题、安全隐患，还会给改代码建议。最值得说的是它不会只输出一句“代码写得不错”，而是按严重程度分级：严重问题、建议修改、疑问点，这样维护者可以优先处理真正影响上线的问题。

我的配置里专门写了一组规则：Python 检查有没有裸except，前端检查有没有把 key 写在循环子组件上，接口层检查有没有正确的参数校验。实际用下来，它能发现一些静态检查工具查不出的逻辑漏洞，比如边界条件和资源未释放。不过要注意，它偶尔会把个人风格偏好当错误，所以项目里最好先统一 lint 规则，否则误报率不低。

2.4 架构设计：写代码之前先想清楚

很多人上来就写代码，写到一半发现模块划分不对，再回头改成本很高。Architect Assistant 这个技能就是逼你在动手前先想清楚。它会根据一段需求描述，输出模块划分、数据流、接口清单、依赖关系，还能指出可能的风险点。

我一般把它用在两种场景：一是新项目启动时，把需求文档丢给它，先搭一个初版方案；二是遇到大重构时，让它对比旧架构和目标架构，列出需要改动的文件清单。使用这个技能有个技巧：需求描述越具体，方案越落地。只写“做一个用户系统”这种模糊描述，它只能给出很泛的内容；把角色权限、登录方式、第三方对接都写清楚，它给出的设计才真的能用。

2.5 依赖分析与升级：再也不怕升级依赖

Dependency Doctor 主要解决依赖管理里的“薛定谔状态”——升了怕坏，不升又担心漏洞。它能扫描项目的requirements.txt、package.json、pubspec.yaml等文件，检查过期版本、已知漏洞、依赖树冲突，并给出升级建议。

我通常会让它先生成一份分析报告，列出每个依赖的当前版本、最新版本、升级风险等级。风险高的依赖先读 changelog，看看有没有破坏性变更；风险低的直接升，然后跑一遍测试兜底。这个技能特别适合接手老项目，几个月没更新依赖，靠它先把家底盘清楚。但要注意，生产环境别让它自动升级，一定要先做兼容性验证，否则分分钟给你整出线上事故。

2.6 测试生成：自动补齐单测

Test Forge 适合项目里单测覆盖不足的团队。它能根据函数签名、业务规则和典型边界条件，生成 pytest、JUnit、Go test 等测试用例，还能直接输出可以直接落地的测试文件。最常见的使用方式是，让它先读被测代码，再生成对应测试，最后本地跑一遍验证。

但这个技能很容易被用歪。只给代码就让生成测试，它往往会照着实现反推测试用例，看起来覆盖率高，实际上什么也没验证。我的做法是把业务规则写清楚，比如“折扣不能为负数”“超时时间不能超过 30 秒”，再让 Test Forge 基于规则设计用例。因为 WorkBuddy 是生成式工具，喂进去的上下文越规范，测试越有实际意义。

2.7 数据库操作助手：自然语言查库

DB Navigator 是那种“用了就回不去”的技能。它通过 MCP 连接数据库，先读取表结构和字段注释，然后你直接用自然语言问“最近七天下单最多的用户有哪些”，它就会翻译成 SQL 去执行，返回结果。不用切到数据库客户端，也不用翻文档查表结构，太省时间了。

但这是高风险技能，安全规则必须严格。我只允许它自动执行只读语句，SELECT、SHOW、EXPLAIN可以直接跑，UPDATE、DELETE、DDL一律要二次确认。连接配置放在单独的.env文件里，不写进对话记录。给生产库配置时，我建议使用只读账号，连接超时设短一点，返回行数限制在 100 行以内，避免一条查询把数据库拖垮。

2.8 日志排查：快速定位线上问题

Log Detective 是我个人最常用的技能之一。线上出了问题，日志文件可能几万行，人工翻根本看不完。这个技能能按时间线整理日志、把同类型报错聚成一类、统计出现次数、定位最早出现的时间点，然后结合错误码和堆栈信息给出一份排查建议。

我有一次排查内存溢出，就是靠它把 GC 日志里的大量重复告警聚合后，发现是某个缓存没设过期时间，对象越堆越多。配置这个技能时，我会提前在规则里指定日志脱敏规则，比如手机号、token、密码字段必须打码，避免敏感信息被写进分析结果或会话缓存。另一个体会是，日志数据量大时它会被上下文限制，最好先做一次预处理，只把最近一小时、特定进程的日志喂给它。

2.9 API 文档编写：让文档跟上代码

接口文档不及时更新是团队协作里最常见的问题。API Doc Writer 能读取代码里的路由、请求参数、响应结构，自动生成或更新 OpenAPI 文档和 Markdown 文档。它还能比对线上文档和当前代码，把不一致的地方标出来，提醒你更新。

这个技能最怕老项目。代码注释不规范、接口逻辑混乱，它生成出来的文档质量也会打折扣。我的做法是先把主流程接口的注释规范补齐，再让技能批量生成。另外，在配置里把“文档必须包含示例请求和示例响应”写进去，生成的文档对前端联调才有实际价值。我还会让它同时生成 mock 数据，联调阶段可以省掉等后端的空闲时间。

2.10 批量文件整理：治愈混乱的文件系统

File Organizer 适合那些文件堆满桌面、下载目录一团乱的人。它支持按规则批量重命名、按类型或日期归类、清理临时文件，所有操作前会先生成一份“将要执行的操作清单”，确认后才真正执行。

我用它处理每周的报表文件和素材，比如把所有以“周报”开头的文件统一命名为“2025-W37-周报-v1”，再按月份归档。这个技能的有用之处在于它能识别文件内容，不只是看扩展名。一条 PDF 是合同还是发票，它能根据内容判断并移动到对应目录。安全方面要控制好权限：我从来不给它直接删除的权限，只允许移动和重命名，想清理文件时先移到一个待删除目录，过两周再手动清空。

2.11 本地知识库：把团队文档变成问答库

KB Assistant 是一个本地 RAG 技能。它可以读取团队 Wiki、产品手册、技术文档，做切分、向量化、索引，然后直接在对话里提问，让 WorkBuddy 基于本地资料回答。这比每次翻几十页文档找答案高效太多了。

配置它有门槛，主要是中文文本切分容易出错。如果按固定字符数硬切，一个句子的语义会被切断，检索出来的片段经常对不上。我调整成按标题和段落切分，先识别 Markdown 标题层级，再按二级标题分块。另一个经验是，向量数据库和索引最好放到独立磁盘，不然系统盘很快会被索引文件占满。有关缓存目录迁移的问题，我会在第 4 节专门讲，这个技能是最大的空间占用来源之一。

2.12 MCP 连接器：统一外部工具入口

MCP Toolkit 是用来统一管理外部工具连接的技能，可以连接 GitHub、Jira、数据库、内部 Wiki，甚至浏览器自动化。它把不同服务的能力封装成标准接口，WorkBuddy 调用工具时不需要为每个平台写不同的代码。

但连接器真的不必装太多。我见过有人一口气装十几个，结果 Agent 在“该用哪个工具”上反复犹豫，响应速度变慢。我自己只保留三个最常用的：GitHub 用于读仓库、提 Issue，内部 Wiki 用于查资料，数据库用于日常查询。每个连接器单独配置环境变量和权限说明，避免互相干扰。MCP 连接器是比较进阶的内容，新手建议先从记忆、文档类技能入手，熟悉 WorkBuddy 的交互方式之后再碰这个。

2.13 安全 Shell：危险命令先拦一道

SafeShell 属于“平时没啥存在感，关键时能救命”的技能。它会在 WorkBuddy 准备执行 Shell 命令前做分析，像rm -rf /、curl ... | bash、git push --force这类高风险操作都会被拦下来，要求你二次确认。

我之所以一直装着，是因为模型在跑自动化任务时，偶尔会生成看起来很合理但很危险的命令。有一次它想清理临时目录，命令写成了rm -rf /tmp/ workbuddy_cache，多一个空格，差点把我的用户目录清掉。这个技能还适合不熟悉命令行的朋友，它能解释每条命令是做什么的，降低误操作概率。当然，技能不能替代备份，重要目录该快照还得快照，否则再怎么拦也有漏网之鱼。

2.14 Git 工作流：提交信息不再靠憋

GitFlow Helper 主要解决提交规范这件事。它能根据代码 diff 自动生成符合 Conventional Commits 规范的 commit message，还能协助处理分支合并、rebase 和冲突解决。对个人项目来说，这个技能最大的价值是节省每次提交时憋消息的功夫；对团队项目来说，它能让提交历史变得一致且可读。

我的配置里指定了团队规范，比如 feat、fix、docs、refactor 各代表什么，scope 怎么写。它还会在提交前把变更按类型分组，整理成一个清晰的提交信息。不过我坚持半自动模式：它生成消息，我看一眼确认，再手动执行 commit 和 push，不让它自动推送远端。这样既享受效率，又保留对代码仓库的控制权。

2.15 中文润色：适合写方案和 PRD

中文润色大师是内容型技能里我最推荐的。它不只是简单地把句子改通顺，还会结合你提供的术语表，确保“接口”不会被改成“界面”，“缓冲”不会被改成“缓存”。它会保留技术含义，只优化表达。

我主要用它写周报、项目方案和对外说明文档。一个比较惊喜的功能是它能按读者切换语气：给开发团队看的文档，直接、简洁、少废话；给领导看的汇报，增加结果导向的表述和重点数据；给用户看的公告，语气更温和、解释更充分。实际操作中，我会先给技能提供一份项目术语表，再让它润色，效果比直接丢原文好得多。它不适合写需要极强原创性的内容，更适合在现有素材基础上做表达优化。

2.16 需求拆解：从会议纪要变成任务清单

Meeting Lens 这个技能适合产品经理、项目经理，还有那些经常收到“一句话需求”的开发。它能从会议纪要、聊天记录、需求描述中提取任务、优先级、验收标准，整理成结构化清单。

我用它接新项目时效率提升特别明显。扔进去一份两小时的会议录音转写，它会输出“需要开发的功能列表”“待确认的问题”“当前阻塞项”，并且给每个任务打上优先级标签。有一点我一直很注意：它提出来的理解不一定准确，我会让它先列出假设和推断，给相关人确认后再进入排期，而不是直接把整理结果当成最终需求。毕竟需求这件事，猜错比慢更可怕。

3. 安装、启用与让规则跨任务生效

3.1 Skill 装在哪里：目录与常用安装方式

WorkBuddy 的 Skill 本质上是一组指令文件，最常见的形式是SKILL.md加可选脚本。它默认从两个位置读取：全局目录~/.workbuddy/skills和项目目录.workbuddy/skills。项目目录优先级更高，适合放进 Git 仓库里做团队共享；全局目录适合放个人通用技能。

我的本机目录大概是这样的：

~/.workbuddy/ ├── skills/ │ ├── memo/ │ │ ├── SKILL.md │ │ └── scripts/ │ ├── code-review/ │ │ ├── SKILL.md │ │ └── rules/ │ └── db-nav/ │ ├── SKILL.md │ └── config.json ├── memory.md └── rules.md

安装方式一般有三种：一是直接在 WorkBuddy 界面里的技能市场搜索安装，会自动放进全局目录；二是从别人分享的仓库下载压缩包，手动解压到 skills 目录；三是自己新建目录，手写一个SKILL.md。不管哪种方式，装完最好重启会话，或者执行一次技能刷新命令让它重新扫描。目录路径里尽量不要有中文和空格，否则偶尔会有解析问题。

3.2 全局规则怎么定，才能对后续所有任务生效

这个问题很多人问过，也是 WorkBuddy 使用里很重要的一个习惯。全局规则的原理是：你在设置里写入的规则，会被拼接到之后每个新会话的系统提示里。它只对后续新开的任务生效，已经开始的旧会话不会补上，所以改完规则记得开新对话。

我自己的全局规则一般控制在 20 行以内，按三大类写：

[全局规则] - 语言：统一使用中文回复，代码和命令保留原样。 - 安全边界：删除操作、强制推送、生产环境写操作，必须先向用户确认。 - 代码风格：Python 遵循 PEP8；前端组件优先复用项目内已有组件库。 - 路径约定：项目根目录为 /data/app，所有相对路径基于此目录计算。 - 输出习惯：涉及步骤时用数字列表，方便对照执行。

写全局规则的关键是具体、可执行，不要写“请表现得专业一点”这种空话。规则越明确，模型越容易遵守。还有一点，如果某条规则只适用于某个项目，就放到项目级规则文件里，别塞进全局，否则换个项目还得手动忽略。

3.3 从零写一个自定义 Skill 的框架

当你觉得现有技能都不够贴手时，可以考虑自己写。别怕，SKILL.md就是普通文本，核心就三部分：触发条件、执行步骤、禁忌事项。我一般用这样的结构：

--- name: 日志摘要 description: 当用户提供日志或错误输出时，自动做摘要和归类。 --- ## 执行步骤 1. 先识别日志来源（应用、框架、数据库）。 2. 按时间排序，将相同错误聚合成一类，统计出现次数。 3. 输出三个部分：异常类型、可能原因、建议动作。 ## 禁忌 - 不要编造日志里没出现过的内容。 - 不要把堆栈信息一股脑全贴出来。

这里最需要注意的是描述字段。模型靠 description 判断什么时候加载技能，所以要把用户可能说的话写进去，比如“帮我看看日志”“这个报错怎么回事”。步骤尽量用数字编号，模型更容易按顺序执行。写完保存到 skills 目录，重启会话，用一句测试话术验证能不能触发。后续想优化就直接改文本，不需要重新编译，这一点非常方便。

4. 常见问题与调优实录

4.1 系统缓存目录怎么改到D盘

这个问题在社区里很常见，尤其是 Windows 用户。WorkBuddy 会把对话记录、运行缓存、临时文件默认放在系统盘用户目录，时间一长很容易占掉十几个 GB。改到 D 盘的方法不复杂。

先说一个容易踩的坑：只改配置不搬旧文件，等于让它重新建一遍索引，该占的地方还是会占。正确顺序是先退出 WorkBuddy，把原缓存目录完整移动到目标盘，比如移动到D:\workbuddy_cache，然后再改配置指向新路径。新版配置里一般有cache_dir字段，可以直接填路径；也可以用环境变量WORKBUDDY_CACHE_DIR来指定。Windows 下示例：

setx WORKBUDDY_CACHE_DIR "D:\workbuddy_cache"

Linux 或 macOS 类似，用export WORKBUDDY_CACHE_DIR=/data/workbuddy/cache，然后把它写进 shell 配置文件持久化。改完重启 WorkBuddy，在设置里看一下缓存路径是否已经变化。迁移完不要立刻删旧目录，先正常用两天，确认索引和会话记录都正常了再清理。

4.2 对话记录和临时文件占用高怎么办

我遇到过一次比较夸张的情况：高强度用了将近一个月，缓存目录总量超过 10GB。打开一看，主要来源是四块：会话快照、模型推理缓存、日志文件和向量数据库索引。不同文件的清理策略不一样。

临时文件可以放心定期清理，我写了一个简单脚本，每天清理三天前的临时内容：

find "$WORKBUDDY_CACHE_DIR/tmp" -type f -mtime +3 -delete

日志文件设置保留数量，比如最多保留 10 个，避免无限增长。会话快照和记忆文件不要随便删，尤其是.workbuddy/memory.md，里面是长期记忆，删了就真的失忆了。向量数据库索引如果重建成本很高，优先把它整个迁移到另一块磁盘，而不是删除。这里又回到 4.1 的话题：把缓存目录放到大容量磁盘，是治本的办法。

4.3 走 WorkBuddy 用 DeepSeek 和直接调 API，哪个更划算

很多人纠结要不要把 DeepSeek 模型接进 WorkBuddy。其实两者不是完全替代关系。直接调 API 灵活度高，代码里完全自己控制请求流程，适合做定制化开发；走 WorkBuddy 接模型，重点是省掉了上下文管理、工具调用、技能调度这些底层工作，适合日常使用和团队协作。

成本上不能一概而论。如果只是偶尔问答，直接调 API 更省事也更便宜；但如果你每天都要做代码审查、写文档、跑工作流，WorkBuddy 里有大量可复用的 Skill 和记忆机制，能显著减少重复的 prompt 消耗，综合成本可能更低。我给团队的建议是先各跑两周，统计 token 消耗和人工介入时间，再决定统一走哪条路。

4.4 技能不生效、互相冲突怎么排查

技能装得多了，难免遇到“技能不生效”或者“行为很奇怪”的情况。我总结了一下，最常见的原因有四个。

第一，技能根本没被加载。先看会话开头有没有出现已加载技能列表，没有就检查目录路径是否正确、是否重启了会话。第二，两个同类技能同时命中。模型随机挑一个，导致行为不稳定。解决办法是同类只留一个，或者在技能描述里写更明确的触发词。第三，技能里的脚本执行不了。Linux 下记得给脚本加执行权限，Windows 注意命令格式。第四，技能指令太长、前后矛盾，模型选择性地忽略了一部分。这时候就把指令精简成“必须、禁止、输出格式”三个板块，越短越好。

我的排查习惯是，每装一个新技能，先用一句典型测试话术验证，通过之后才保留。这样一旦出现异常，能快速判断是新技能的问题还是整体配置的问题。

5. 最后一点个人心得

5.1 真正好用的技能是自己改出来的

社区里的通用技能只能解决八成的问题，剩下两成要靠自己调。比如日志排查技能，我一开始装的版本不了解我们的技术栈，会给出一些不太适用的建议。后来我在SKILL.md里补上了公司内部的错误码对照表、常见的日志格式、服务名前缀，准确率立刻上来了。你完全不需要重写整个技能，只需要把你的项目经验、术语、规则加进去，它就会从“通用助手”变成“团队老员工”。这也是 WorkBuddy 这类工具最有意思的地方，技能不是死的，是可以持续生长的。

5.2 定期给技能库做减法

用久了以后，我的技能曾经膨胀到二十多个。表面看功能很全，实际上每个会话都会多花时间在“选技能”上，有时候还会选错。后来我养成了一个习惯：每两周看一次技能使用记录，把一次都没用过的技能禁用或删除。清理完之后，保留的基本就是这份清单里的 15 个。结果发现 WorkBuddy 的响应更稳定了，任务完成率也明显上升。技能库和衣柜一样，定期整理，才能真正留下有用的东西。