三个月前第一次打开 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 握住你的 CursorWorkBuddy 的价值很容易局限于“聊天框”但通过工具连接 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 条能让你少走我走过的弯路。