三个月前第一次打开 WorkBuddy，我的第一反应是“又一个把聊天框包装成工作台的东西”。那会儿我拿它做的事也很初级：写写邮件草稿、改改周报措辞，属于典型的“能用但不敢用”。真正让我改观的，是某天我试着给它立了三条规则，让它去整理一份三十页的接口文档——它居然自己维护上下文、主动列出冲突点，还顺手补了两个我在需求文档里漏掉的接口参数。从那一刻起我才意识到，WorkBuddy 能不能扛活，大部分不取决于它本身，而取决于我怎么布置它、喂它什么规则、选哪些 Skill。
这篇内容不是官方手册的翻译，而是我用了三个月、踩了十几回坑之后，整理出来的 30 个实战技巧，覆盖安装配置、规则编写、Skill 挑选、防翻车和安全审核。适合两类人：刚下载还一头雾水的新手，和已经用了半个月、但总觉得“也就那样”的老手。
1. 把 WorkBuddy 的地基收拾干净：安装、缓存与版本控制
新手最容易犯的错，是跳过基础配置直接冲到 Skill 市场里一顿装。其实这跟搭工作台一样，地基没扫干净，上面摆多少高级工具都白搭。
1.1 安装与启动：Windows、Linux、Docker 三条路线
先说 Windows。我看很多人图省事下载“绿色便携版”，能少一步安装，代价是右键菜单集成没了、不能自动识别项目根目录，部分文件关联也失效。我踩过这个坑，便携版跑了一周，最后发现它连最基本的“从文件夹打开工作区”都识别错，只好卸了重装官方安装包。如果你在 Linux 上跑，优先选 AppImage 或 Flatpak 包；但要注意，有些精简桌面环境没做系统托盘，WorkBuddy 的常驻快捷键会失效，装完第一件事就是确认托盘图标能正常显示。
Windows 7 用户我劝你彻底死心，当前版本已经放弃支持，即便是老版本装上也会出现各种稀奇古怪的崩溃。至于 Docker 方案，适合在服务器上跑无人值守任务，普通办公电脑没必要多套一层容器。我试过一次，文件挂载和窗口交互都变得很别扭，日常用完全没必要。
1.2 系统缓存目录非改不可的两个理由
这是典型的“没人教但迟早会踩”的问题。WorkBuddy 默认把缓存塞在用户目录下的.workbuddy_cache里，平时不起眼，但你要是跟我一样拿它跑长文档、文献整理、大仓库代码分析，这目录会以肉眼可见的速度膨胀。我有一次清理，发现里面攒了将近 8GB 的中间结果和临时文件。
第二个理由和性能有关。缓存目录落在机械硬盘上时，一旦文件数量上去了，每次启动扫描都会明显变慢，体感就是“开个工作台要转半天圈”。改法很简单：打开设置，在“缓存管理”里把路径指向其他分区；或者更直接，用环境变量WORKBUDDY_CACHE_DIR指定目录，不同版本的变量名可能略有差异，设置里直接搜“cache”也能找到入口。改完记得重启应用，再顺手点一次“清理孤儿缓存”。我自己的方案是把它挪到一块独立 SSD 上，设置每两周自动清理一次，之后再也没有出现过启动卡顿。
1.3 锁版本：我处理 WorkBuddy 升级的方式
很多人习惯把“自动更新”开到最大，觉得新版本一定更好。WorkBuddy 更新频率不低，但新版本未必全是好事——我就遇到过更新后 Skill 格式变化、自定义规则优先级被重置的情况，之前沉淀的配置一夜之间全乱了。
所以我现在锁版本，策略是：每个月挑一个周末手动更新，更新前先把规则和 Skill 配置导出成文件备份；大版本发布后不马上进正式项目，先在临时沙盒项目里跑通一整套流程，再决定要不要切过去。这套流程帮我避过两次“升级即返工”的坑，花的时间少，省的心可不少。
2. 给 WorkBuddy 立规矩：自定义指令的作用域与写法
如果你只打算做一件事，那就给 WorkBuddy 写规则。我在三个月里试过很多种调教方式，最终发现：与其每次任务现场打一大堆字，不如把高频偏好写进规则，让它每次都自动带上来。
2.1 全局规则、项目规则、临时指令：优先级与生命周期
WorkBuddy 的自定义指令分三档：全局规则、项目规则、临时指令。全局规则对所有对话和所有项目生效，适合放“你永远要假定以下条件”这类底层约定；项目规则只对当前工作区生效，适合团队内部的技术栈、代码风格、仓库地址；临时指令只在你当前这条消息里生效，适合一次性要求。
生效优先级是临时指令 > 项目规则 > 全局规则。这个顺序坑过我一回：有一次我在项目规则里写了“所有回复使用英文”，结果覆盖了全局规则里的“中文交流”，而且我没有注意到优先级，硬是跑了两天英文回复，直到验收时才被领导投诉。这个教训让我养成了习惯：每次调整项目规则时，都必须先想清楚“它会不会覆盖我希望全局生效的东西”。
2.2 长期挂着才有效的 5 条规则
我用下来，有五条规则的价值最高，写出来给你抄作业：
- “先复述任务，再执行任务。”它会把我的问题转述成一句明确的话，防止理解偏差。这招特别适合指令比较长、或者我脑子里其实也没理清楚的情况。
- “观察新项目时，先扫描 README 和根目录结构，再回复。”逼它建立全局观再开口，否则它很可能只根据你给的只言片语就开答。
- “给出代码建议时，必须附带副作用说明。”避免它为了顺应我的表述而掩盖风险。技术上这个规则能大大减少“看起来对、实际上有毒”的建议。
- “技术名称保留英文，解释用中文。”适合中文团队写英文代码混搭的语境，既保持术语准确，又让阅读者不费劲。
- “如果指令可能影响数据，先请求确认。”这是防翻车的最后一道闸，后面第 5 章还会展开。
这些不是看一遍就完，而是要长期挂着。规则的价值在于复用，临时写一次和长期挂着，效果完全不在一个量级。
2.3 规则有没有生效，用三步验证
很多朋友写完规则就以为“万事大吉”，结果发现 AI 根本没按规则来。我的验证方法有三步：
- 直接问一句“请简述你的工作规则”，看它能不能把关键规则完整复述出来。如果它复述不全，证明规则没进长期上下文，检查是不是写错层级。
- 设计一条小样本测试，比如你写了“先复述任务”规则，就故意发一句含糊的任务描述，看它有没有先复述再执行。
- 规则冲突排查。如果发现 AI 行为不像预期，按优先级从高往低捋：先看临时指令，再看项目规则，最后看全局规则，基本都能定位到是谁把谁覆盖了。
这套三步验证法，我基本上是每加一条规则就跑一遍，从不偷懒。
3. Skill 不是越多越好：我留下这 6 类
Skill 这个功能特别容易让人上瘾，最开始我装了满满一屏，结果用到的没几个，还拖慢了启动速度。后来我做了一次减负，只留 6 类，每一类都对应我实际工作里高频出现的场景。
3.1 代码审查 Skill：把“评审人”带进工作台
WorkBuddy 最常用的技能之一就是代码审查。我配置了一个全局挂载的 Code Review Skill，默认在代码变更后自动触发，重点检查脆弱点、异常路径和副作用。它能输出类似“这里有个并发修改的隐患”这种建议，而不是停留在“变量命名不规范”的层面。
我最满意的是它会附带修改建议和风险等级，相当于一个随时在线的初级评审人。对于个人项目非常够用，对于团队项目则能帮你把评审会的讨论质量拉高一个档次。
3.2 文献综述 Skill：能整理材料，但别让它替你读原文
这个 Skill 我只能说又爱又恨。爱的是它整理效率惊人：你喂给它本地 PDF 和文摘数据，它会自动抽取研究方法、对比结论差异、生成综述骨架。恨的是，如果我没先做人工校对，它会把论文的年份、作者顺序搞混，甚至出现“这篇论文提出了某结论”但在原文里根本没提的情况。
所以我的使用姿势是：它能帮你整理和对比，但不能替你读原文。所有文献综述的输出我都得拉回原始 PDF 里逐条核对，Skill 的价值在于把“两小时的整理工作”压缩成“二十分钟的核对工作”。对于写文献综述这个场景，这已经是质变了。
3.3 客服场景 Skill：客服负责人最快上手的路径
如果你是客服负责人，想快速用 WorkBuddy，别从技术文档开始，直接从你的客服工单模板切入。把你们已有的高频问题、话术模板、升级链路喂给它，让它生成一套结构化的工作台。比如我帮一位朋友搭的客服 Skill，能自动完成“情绪安抚 → 方案说明 → 结束语”这个 SOP 流程，还能在回复里自动避开品牌禁区词。
这里的核心不是让 AI 替你回复客户，而是让它在“草稿生成”环节把标准动作做完，你把关终稿。客服负责人训练 WorkBuddy 的时间，通常两小时就能换来团队每天省下的大量重复劳动。
3.4 工具连接 Skill：让 WorkBuddy 握住你的 Cursor
WorkBuddy 的价值很容易局限于“聊天框”，但通过工具连接 Skill，它能真正摸到你的编辑器、命令行和文件系统。我用得最多的是和 Cursor 的联动场景：让 WorkBuddy 读取我在编辑器里当前选中的代码，再基于那段代码回答问题和给出修改方案。
这里要提醒一句：工具连接 Skill 的授权边界很重要。它一旦能操作你的本地环境，“能不能删文件”就不再是选择题，而是一道安全底线。我给工具类 Skill 的规则是“执行任何写操作前必须询问确认”，至今没有因为联动翻过车。
3.5 文档整理 Skill：口述草稿变结构化文档
我记性不算好，经常对着录音笔说一通，最后完全不想整理。文档整理 Skill 帮我解决了这个问题：把口述内容丢进去，它自动生成带标题层级、待办事项和风险标注的结构化文档。用起来特别像“有个实习生帮你把备忘录整理成会议纪要”。技术含量不算高，但日常提效非常明显。
3.6 自我提问链 Skill：成本最低但受益最大的一个
这个 Skill 我强烈建议每个人都要配。它的名字有点抽象，实际干的事是：每次给出建议之前，先列出 3 个可能反对它建议的理由，再输出最终结论。
为什么这招对我极其有用？因为大模型默认会顺着用户说，你越相信，它越迎合。自我提问链逼它在输出前反转视角，把容易被忽视的边界条件和副作用暴露出来。装上之后，我从“收到答案马上信”，变成“收到答案先看它自问自答的内容”，决策质量上了一个台阶，而且完全免费。
4. 30 条技巧清单：日常、工程、防翻车三档
下面是这篇文章的“硬货”部分。这 30 条是我三个月里一边用一边记下来的，不是从哪份手册里抄出来的。我按“日常提效、项目工程、防翻车”分成三组，每条控制在两句话内，方便你直接抄。
4.1 日常提效 10 条
- 把高频会议结构做成轻量 Skill，而不是每次现场手打大纲。
- 草稿面板和执行面板分开用：先让 AI 给草稿，确认后才知道能不能动正式文件。
- 用对照模式让 AI 同时给出两个方案，避免被单一答案带偏。
- 长对话进行到一半时，阶段性让它输出“信息摘要”，防止上下文漂移。
- 让它处理多个小任务时，先给总清单再逐项打钩，比一条条追问省一半时间。
- 批量文件改名、归类时直接描述命名规则，用它比用图形工具灵活得多。
- 把项目根目录、仓库地址、常合作的评审人写进全局规则，省得每次重复交代。
- 涉及事实判断时，先让它联网搜索再回答，别靠模型记忆硬答。
- 遇到特别复杂的指令，第一句话先问它“你能不能做到”，比直接开跑更稳妥。
- 每天下班前让 AI 输出一份“今日变更清单”，第二天恢复工作上下文几乎零成本。
4.2 项目和工程 10 条
- 新项目第一步，先让它扫描目录，写一份“项目假设清单”把不确定的点列出来。
- 让它动手改代码前，先输出“文件列表 + 改动理由”，确认之后再执行。
- 多文件改动时，要求它每改一个文件就跑一次 lint 或编译。
- 用 diff 预览逐条检查，不要全选“接受所有更改”。
- 测试失败日志原样贴给它，并要求“先解释根因再改”，别让它跳过分析直接出补丁。
- 执行批量修改前，先建 git 分支或备份，保证一条命令就能回滚。
- 涉及跨 Skill 调用时，用 @SkillName 显式指路，不要让它自动猜。
- 让它自己给自己提三个反对意见，再产出最终方案，效果相当明显。
- 凡是 AI 执行过的关键操作，在 commit 信息里标注来源，里外里都好追责。
- 大版本升级后别急进正式项目，先在沙盒项目里跑一整套流程，没问题再切。
4.3 防翻车 10 条
- 不要把 API 密钥、访问令牌直接粘贴进对话，一律用占位符替换。
- 敏感信息（人名、手机号、内部项目代号）先做脱敏，再用通用词代替。
- 涉及文献引用、统计数据时，强制要求它给出可点击来源，输出后逐个核对。
- 凡是对外发布的文案，先让它自查品牌禁区词和禁用词清单。
- 涉及数字结论时，要求它把计算公式写出来，光看结论容易踩坑。
- 不让它直接删文件，统一改成“移动到待删目录”，二次确认后再清空。
- 当它开始反复给出一模一样的答案时，中断对话、清空会话，不要继续在同一个上下文里追问。
- 安全审核弹红条警告时，先查原因再决定是否忽略，别随手点掉。
- 定期导出规则和 Skill 配置备份，升级后立刻比对，避免配置悄悄丢失。
- 授予执行权限之前，先问自己“最坏结果是啥”，答不上来就不授权。
这 30 条不建议一次性全用。你第一周挑 5 条用，比如“先清单再执行”“脱敏再发送”“diff 预览认真看”，等养成习惯之后再慢慢加。一下子塞太多，反而会让自己和 AI 都无所适从。
5. 安全审核与判断：哪些活真的不能交给它
最后这部分可能是最不酷但最关键的。我在三个月里见过太多“AI 干活干出大新闻”的场景，大多数不是 AI 不够聪明，而是使用者没有提前判断“哪些活能交、哪些活不能交”。
5.1 安全审核到底在审什么：三种信号的含义
WorkBuddy 自带的安全审核模块，我的理解是它主要盯三件事：敏感信息（密钥、身份证号、手机号）、越权请求（比如让它删除文件或修改全局配置）、对外输出的合规性。界面上会分三种信号：绿色代表通过，黄色代表存在风险但可以继续，红色代表高风险拦截。
黄色事件通常是“请求超出当前上下文范围”，红色事件则往往是“潜在的高风险操作”。我刚开始很讨厌弹窗，后来仔细看了几次红条警告的原因，发现绝大多数都是我自己指令写得不清不楚，或者确实触碰了敏感信息。现在我把黄色当成“需要复核”，把红色当成“必须停”，用下来整体反而更省心。
5.2 我亲历过的三次翻车现场
说三个我真实经历过的翻车场景，都不严重，但很有代表性。
第一次是外发公告里出现了一个内网 IP 地址。原因是我把内网文档直接丢给 AI 润色，它原封不动保留了这个地址。事后想，这根本不是 AI 的错，而是我没做脱敏。
第二次是文献综述的年份错乱。我让 AI 基于一批未核对原文的文献生成综述骨架，它把一个经典论文的年份和作者顺序搞反了。提交之前如果每篇都核对了，就不会出这个事。我后来给这条定成铁律：AI 引用文献，必须给出来源链接，人工逐条核。
第三次是客服工单批量处理时，它把同姓名的两个客户合并成了一个人。我当时太信任批量结果，没有抽样检查，差点造成后续服务事故。从那以后，凡是涉及“把多条数据做合并、归类、去重”的操作，我都会加一步人工抽检。
5.3 能不能交任务的三个判断标准
经历这些之后，我总结了一套简单的判断标准，每次给 AI 分活之前都会过一遍：
- 可回滚吗？如果任务不可回滚，就让它只产出方案，不执行。比如发送邮件、删除文件、修改线上配置，我都只让它生成草稿，人工来点按钮。
- 有明确验收标准吗？能列出“对/错”的活才敢交。比如代码报错修复，有测试通过与否作为标准；但“写一段品牌文案”这种没边界的活，要给足约束条件，否则它发挥起来容易出格。
- 出错会波及别人吗？只要会波及别人，就必须加人工审核节点。对外文案、客户沟通、跨部门资料整理，这些场景我不允许它“全自动直接执行”，至少安排一步抽查。
这三个标准看起来很简单，但值得写在全局规则里。很多时候，人不是不知道风险，而是懒得判断，结果出事之后才发现当初多想一步就能避开。
6. 写在最后：三个月后我还留着的一些习惯
6.1 每周做一次“规则瘦身”
规则写多了也会变成负担。我现在每周五下午会花十分钟，把这一周挂过的规则和 Skill 列表拉出来，删掉已经不需要的、合并重复的、修正过时的。规则不是越多越好，而是越精准越好。定期瘦身之后，AI 的输出稳定性和规则遵循率都有明显提升。
6.2 权限不是越高越好
还有一件事我从没松懈过：重要任务开始时，先把权限降一档，先让它以“只读”身份把方案跑两遍，确定没有大问题，再决定要不要提权执行。这个习惯帮我避免了好几次因为权限开得太大而差点闹出的麻烦。三个月用下来，我最大的感受是：WorkBuddy 的成长曲线不是由版本号决定的，而是由使用习惯决定的。工具还是那个工具，可当我开始用规则管住它、用清单审核它、给每条指令设计验收边界时，“敢不敢把活儿交给它”这个问题就有了明确的答案。希望这 30 条，能让你少走我走过的弯路。
