WorkBuddy高效进阶：全局规则与Skill实战指南

1. 先搞清楚 WorkBuddy 到底是什么

1.1 WorkBuddy 和 CodeBuddy 是不是一回事

这是我被问得最多的问题，没有之一。用了三个月之后我可以负责任地说：它俩绝对不是同一款产品，但确实是同一个家族的东西。

CodeBuddy 是腾讯旗下偏 AI 编程方向的工具，核心场景是辅助开发者写代码、补全、解释。WorkBuddy 则更像是从 CodeBuddy 升级、泛化出来的“工作代理”形态。简单理解：CodeBuddy 是那个帮你把手放在键盘上的副驾，WorkBuddy 是要把整条工作流都接过去自己跑的代理。

我从实际体感上说一下差异。在 CodeBuddy 里，你发出指令后，它给你补全代码、改 bug，交互节奏是“你问一句，它答一句”。WorkBuddy 不一样，你可以一次性把一个复杂任务砸过去，比如“帮我把这 20 份客服对话记录做分类统计，输出一个带问题标签的汇总表”，它会拆解步骤、逐步执行、中途有不确定的地方会回来问你，最后给你一份成品。

这个差异看似只是交互方式的不同，实际上背后是产品定位的转变：WorkBuddy 的目标不是“更聪明的对话工具”，而是“能跑任务的工作平台”。理解不了这一点，后面所有技巧都会用错方向。

1.2 它适合谁，解决了什么问题

我先说一个反直觉的结论：WorkBuddy 其实不太适合那种只写代码的程序员。因为纯代码场景下，IDE 自带的 AI 能力和更轻量的工具已经够用了。WorkBuddy 真正有价值的地方，是处理那些“代码 + 文档 + 业务逻辑”混合在一起的脏活累活。

我身边用得最顺手的人，画像是这样的：

• 技术负责人，要写周报、做技术方案、审代码，还经常要给非技术人员解释需求。
• 客服负责人，每天面对大量用户反馈，需要分类、分析、出报表、写改进建议。
• 科研人员或学生，需要读一堆文献，做综述，整理资料。
• 产品经理，需要把模糊的想法拆成需求文档，还要跟进项目进度。

这些人有一个共同点：工作时间被大量重复性任务蚕食，真正需要人判断的部分反而没时间做。WorkBuddy 解决的就是这个问题——把重复劳动接过去，让你只做“定标准和做决策”这两件事。

所以下面所有内容，我都会围绕这两件事展开：怎么把标准定清楚，怎么把决策留给自己。

2. 装好、配置好：从安装到环境适配

2.1 安装前先做一次“安全审核”

这个问题我在使用初期差点吃了大亏。有一次我直接把一份含客户手机号的表格丢进去让它做统计，做到一半才反应过来，赶紧撤回。虽然本地工具的数据处理方式相对可控，但习惯一旦养成，后面就会越来越随意。

所以我的建议是，安装之前先给自己立三条规矩：

1. 工作区里绝对不放客户隐私、密钥、密码。如果你的项目文件会进入 AI 的处理上下文，那它们就不是“本地私有”这么简单了。
2. 按敏感程度给内容分级：可以直接输入，脱敏后可以输入，禁止输入。允许输入的内容，也要养成脱敏的习惯。
3. 在全局规则里写明禁止输出密钥等敏感信息，让它形成条件反射。

听起来麻烦，但处理过真实事故的人都知道，这条防线比任何效率技巧都值钱。

2.2 Windows / Win7 / Linux 安装要点

先说说我实际安装的三个环境：Windows 11 主力机、Linux 服务器、一台被我翻出来的 Win7 老机器。

Windows 10/11：直接下载官方安装包，一路下一步就行。注意两个细节：一是装到固态盘，因为 WorkBuddy 的本地索引和缓存读写频率不低，机械盘会拖慢整体响应；二是安装目录不要带中文，某些版本对中文路径的处理有兼容性问题，别给自己找麻烦。

Win7：老实说，官方客户端在 Win7 上是有兼容性风险的。我试过在 Win7 上装新版本，界面能起来，但部分渲染和快捷键会失灵。如果你必须用 Win7，我的建议是直接用 Web 端，或者干脆用 Docker 跑一个隔离环境，别跟原生客户端死磕。这个问题不值得浪费半天时间。

Linux：官方有对应的安装包，依赖并不复杂。常见的坑是字体渲染和显卡驱动，装完之后如果界面发虚、字体模糊，优先查显卡驱动和字体配置，而不是重装。

2.3 Docker 部署方式

Docker 是我在 Linux 服务器上最常用的方式，好处是环境干净、迁移方便、不污染宿主机。我把配置目录挂载到宿主机，这样重装容器不会丢数据和规则配置。

# 拉取基础镜像 docker pull workbuddy:latest # 启动容器，把配置目录挂载到宿主机 docker run -d --name workbuddy \ -v /data/workbuddy:/root/.workbuddy \ -p 8080:8080 workbuddy:latest

挂载目录有个副作用：缓存会越滚越大。我之前没管它，跑了两个月，一看占了好几个 GB。后来加了条定时任务，清理 30 天以上的中间产物，磁盘空间才恢复正常。如果你用 Docker 部署，这个坑一定要提前踩。

2.4 把系统缓存目录挪走

WorkBuddy 默认把缓存放在用户主目录下的 .workbuddy 文件夹里。要是你的 C 盘或者系统盘比较紧张，这个目录会变成一个隐形杀手。

Windows 上的改法：

1. 找到安装目录下的配置文件（一般在 config 目录下，YAML 或 JSON 格式）。
2. 找到cacheDir字段，改成新路径，比如D:\workbuddy_cache。
3. 保存后重启程序。

Linux 上更直接，用环境变量控制：

export WORKBUDDY_CACHE_DIR=/data/workbuddy_cache

换路径不只是为了省空间，还有一个隐藏好处：重装系统或重装客户端时，缓存和模型索引能保留下来，不用重新下一遍。我重装过一次系统，之前每次启动都要重建索引，换了路径之后省了至少半小时。

3. 立规矩：用全局规则管住 AI

3.1 为什么必须写全局规则

我见过太多人把 WorkBuddy 当百度用：临时打开，临时提问，用完就关。这样做不是不行，而是非常浪费。

你每天要处理的任务，本质上是在重复执行类似的标准和流程。比如你的周报格式、你的分析框架、你的交付规范，这些是基本固定的。既然固定，为什么不一次性告诉 WorkBuddy，让它每次自动遵守？

全局规则的本质就是：把话语权从“每次碰运气”变成“一次定义，永久生效”。它的价值不在当下，而在一个月后——当你不需要从头解释你的工作标准时，你就知道什么叫复利效应了。

3.2 给 WorkBuddy 定几条通用规则

我自己用的全局规则，是从 6 条核心规则开始的，你可以直接抄：

1. 所有输出内容一律使用简体中文，结构清晰，逻辑分层。
2. 代码类任务必须先分析需求、再写代码、最后给出测试步骤。
3. 遇到信息缺失或表述模糊，先提问澄清，不要擅自假设。
4. 涉及数字和事实，必须标注来源或说明估算逻辑，禁止凭空编造。
5. 生成文件前，先说明文件用途与结构，再输出内容。
6. 任务完成后，必须给出总结摘要，包含完成内容和遗留问题。

这 6 条覆盖了 80% 的日常场景。你不用一次写很多条，关键是让它成为你的“职业规范”，而不是花哨的装饰。

3.3 针对客服负责人场景的规则模板

如果你是客服负责人，或者做运营、用户支持类工作，第一种规则模板可能需要调整。我帮朋友配置过一个客服场景，规则是这样的：

1. 角色定位：资深客服运营顾问，所有回答必须基于客服场景，给可落地的建议。
2. 情绪处理：遇到客户情绪激烈的对话，先处理情绪，再解释原因，绝不推卸责任。
3. 输出格式：汇报类内容用表格输出，字段包含问题分类、原因分析、处理建议、改进措施。
4. 排班与调度：给结果时必须附带关键约束条件，说明排班逻辑。
5. 数据安全：涉及客户数据的案例一律脱敏，禁止出现真实姓名、电话、地址等信息。

这套规则的效果立竿见影。之前她需要花一下午整理客服日报，现在描述需求 + 丢原始数据（已脱敏），半小时内拿到表格和初步分析。她要做的事情变成了“核对结论和调整建议”，而不是从零开始做分类。

3.4 让规则对后续所有任务生效

搜索热词里有“给 WorkBuddy 定几条规则，后续对所有任务都生效”，这个需求很真实。你当然希望规则是全局的，而不是每开一个新对话就要重新说一遍。

实际操作上，关键点是把规则写进全局设置，而不是对话里。写进对话里的规则只对当前对话生效，关掉窗口就没了；写进全局设置的规则，才会对所有新任务自动生效。

我的习惯是：先在全局设置里放通用规则，然后针对特定场景（比如客服、写综述、做代码审查）再写专用的 Skill 或子规则。通用规则管底，专用规则管场景。

4. Skills 才是效率的分水岭

4.1 Skill 和普通提示词的差别

Skill 是 WorkBuddy 最被低估的功能，也是拉开普通用户和进阶用户差距的关键。

普通提示词是“一次性指令”，你让它做什么它就做什么，做完就结束。Skill 则是一套可复用的流程包，里面包含了步骤、输入格式、输出规范、判断标准。

举个例子。你直接跟 WorkBuddy 说“帮我写一份竞品分析”，它大概率给你一篇泛泛而谈的文章。但如果你加载了一个“竞品分析”Skill，它会先要求你确认竞品范围，然后按产品功能、定价策略、用户评价、市场表现多个维度逐项分析，最后输出一张汇总表。步骤是固定的，输出是标准化的，不会跑偏。

4.2 哪些 Skill 最好用

三个月实践下来，我自己最常用的Skill有这几个：

有一点要提醒所有人：Skill 不是装得越多越好。我一开始装了十几个 Skill，结果任务执行时它频繁切换上下文，输出又慢又杂。后来精简到 5 个核心 Skill，效果反而好了。安装 Skill 前先问自己一个问题：这个 Skill 我过去两周用过几次？如果答案是零，删掉。

4.3 实战：让 WorkBuddy 写文献综述

把“用 WorkBuddy 写文献综述”单独拿出来讲，是因为这是学术场景里很多人真实需要的功能，而且操作路径很有代表性。

我的做法分三步：

1. 建一个文件夹，把需要综述的文献 PDF 全部丢进去，命名规范一些，比如作者_年份_主题.pdf。
2. 给 WorkBuddy 下发任务：通读文献，按研究问题、研究方法、数据来源、核心结论四个维度提取关键信息。
3. 指定输出格式：按主题分组（不是按时间流水账），每组做横向对比。

实测下来的体会是：文献综述的质量，取决于输入文献的质量，而不是 AI 的总结能力。如果文件夹里混进了不相关的 PDF，或者文件名不规范，输出的综述质量会明显下降。所以前置整理工作很重要。

另外我建议先让 WorkBuddy 列一个“综述大纲”，确认结构方向后再让它填充内容。这样比直接让它从头写到尾，可控性高很多。

5. 三个月攒下来的 30 个实战技巧

这部分我按使用周期分成三个阶段：上手期、进阶期、避坑期。每个阶段 10 条，都是我没在官方文档里见过、但实际用下来很管用的经验。

5.1 上手期：先用起来，别想太远

1. 第一次打开 WorkBuddy，先花 10 分钟配全局规则，不要急着跑第一个任务。规则是地基，地基没打好，后面都是返工。
2. 把高频任务做成 Skill。如果你发现自己第三次用同样的方式描述一项任务，就应该考虑让它固化成 Skill 了。
3. 遇到复杂任务，先让它列执行计划。它把步骤列出来之后，你看一眼方向对不对，再让它执行。这一步能避免大量无效输出。
4. 敏感数据一律在外部脱敏后再喂给它。养成这个习惯要趁早，别等出事了再改。
5. 本地文件命名要规范。WorkBuddy 会从文件名和目录结构中理解上下文，乱命名等于让它蒙着眼睛干活。
6. 上下文窗口是有限的，长文档要分段处理。我见过有人一次塞了几百页 PDF，结果后半段的质量明显下滑。
7. 让 WorkBuddy 用 Markdown 输出。无论是代码、表格，还是文档结构，Markdown 格式既清晰又方便复制到笔记软件里。
8. 每次任务结束前，让它输出一段摘要。这个摘要能帮你快速回顾，也能作为后续任务的上下文衔接。
9. 注意语言环境的设置，让它输出的语言保持一致。我在中英文混用环境中踩过坑，输出一会儿中文一会儿英文，很影响阅读效率。
10. 及时清理历史会话。不清理的话，缓存和索引会越积越多，拖慢整体响应速度。

5.2 进阶期：开始养“自己的系统”

11. 写规则时，多用“必须”“禁止”这类确定性词，少用“尽量”“可能”这种模糊词。AI 对模糊词的执行效果，远没有确定词好。
12. 如果你是客服或运营岗，可以在规则里加一个“话术库”，把你们团队的常用话术丢给它，让回答更贴近业务口吻。
13. 用工作台把不同角色的 Skill 组合起来。比如“客服数据整理 Skill + 周报生成 Skill”，形成一条从数据到汇报的完整链路。
14. 让 WorkBuddy 先写测试方案，再写实现。需求不明确时，这个方法尤其好用，因为测试方案本身就是对需求的一次澄清。
15. Docker 部署时给容器加资源上限。用--memory和--cpus参数限制资源占用，防止它在处理大任务时把服务器内存吃满。
16. 数据类任务开始前，让它先做“数据质量检查”再计算。我吃过亏，数据里有重复项和缺失值，没检查直接算，结论自然不靠谱。
17. 用 WorkBuddy 整理内部文档时，先让它出大纲，再填充细节。结构对了，内容才有意义。
18. 善用“例外规则”。全局规则管 95% 的情况，但总有些任务需要特殊处理。例外规则能避免你用临时指令覆盖全局规则时产生冲突。
19. 定期导出规则和 Skill 配置做备份。我吃过大亏，重装系统忘了备份，花了三天重建规则库。
20. 每周做一次复盘：这周有没有重复描述的任务？把它们转换成 Skill 或规则。这个动作是复利效应真正的来源。

5.3 避坑期：这些坑我都替你踩过了

21. 不要一次丢超过 5 个任务进去。任务线太多，上下文容易互相污染，输出质量直线下降。
22. 不要把密钥明文写进配置或对话里。真要用的场景，通过环境变量注入，别让它把这些信息记到上下文里。
23. 缓存目录只放临时文件，不要把项目源码也放进去。缓存清理时你就知道后果了。
24. Docker 部署要注意容器时间和宿主机时间的一致性。时间不同步，定时清理任务会失效，数据最后还是堆成山。
25. 别在收到新版本提示后立刻升级。我升级过一次测试版，遇到一堆奇怪的 bug，后来等稳定版才恢复。如果你是生产力用户，稳定优先。
26. 输出质量下滑时，先检查上下文是否被无关内容污染了。很多时候不是产品变笨了，是你喂了太多无关注入进去。
27. Win7 和旧 Linux 系统上，直接用 Web 端，别折腾原生客户端。时间成本不划算。
28. 代码类任务的最终把关人是你自己。AI 写的测试不一定覆盖边界情况，逻辑审查必须人工复核。
29. Skill 更新后，重新跑一遍验证任务。不要默认“更新只会更好”，更新也可能引入兼容性问题。
30. 最后一条，也是最重要的一条：把 WorkBuddy 当实习生，而不是专家。它速度快、态度好、知识面广，但不是所有输出都可靠。你的判断必须一直在场。

6. WorkBuddy、Trae、zcode 怎么选

6.1 三者的定位差异

这个对比我经常被问到，尤其是刚从 IDE 自带的 AI 功能迁移过来的人。我把三个工具放在同一个维度上比，可能比网上那些“谁的代码写得好”的评测更有参考价值。

一句话总结：如果你只需要一个很趁手的代码编辑器，zcode 和 Trae 都有优势；如果你的工作是“写代码 + 写文档 + 做分析”混合型，WorkBuddy 的天花板明显更高。

6.2 我的选择建议

我最终把 WorkBuddy 作为主力，不是因为它每个单项能力都最强，而是因为我的工作不只有代码。

我曾经算过一笔时间账：每周 40 小时工作里，真正在“写代码”的时间可能只有 12 到 15 小时，剩下的时间花在开会、看文档、写方案、回消息、做汇报上。WorkBuddy 在剩下那 25 小时里帮我的，比它在代码上帮我的要多得多。

但我也要诚实地说：它的学习成本确实比另外两个高。头两周我几乎想放弃，因为配置规则、调试 Skill、调整输出格式，每一项都要花时间。但过了这个坎之后，后面的效率提升是指数级的。

工具选型这件事，本质上是在选“你愿意为它投入多少前期成本”。如果你只有周末的两小时能折腾工具，那 Trae 更合适；如果你愿意花一星期把基础打牢，WorkBuddy 是更长远的选择。

7. 最后说几句实在话

三个月前，我给 WorkBuddy 的定位是“试用一下的玩具”。三个月后，它已经成了我日常工作里跑得最勤的环节之一。

这个转变，不是因为 WorkBuddy 在这三个月里突然变聪明了，而是我自己学会了怎么用规则和 Skill 圈住它的能力边界。我以前总想着“AI 应该什么都懂”，后来才明白，AI 的能力是上限，而你的定义能力决定了下限。写全局规则、建 Skill、清理上下文，这些看起来是在“调教”工具，实际上是在梳理自己的工作方式。

如果你刚拿到 WorkBuddy，不知道该从哪里开始，我的建议很简单：先花一个星期，只做两件事——写一套自己的全局规则，建 3 个真正贴合自己工作的 Skill。不要急着让它跑大项目，也不要在没有规则的情况下把核心任务交给它。

一个星期之后你再回头看，会发现之前那种“这工具到底能不能用”的怀疑，早就变成了“我之前没它的时候是怎么过来的”。那句话怎么说来着，真正好用的工具，不是你学习它的规则，而是它能适配你的规则。WorkBuddy 给了我这个空间，你的规则写得越清晰，它回给你的效率就越可观。