WorkBuddy 这名字第一次看到的时候，我心里是打个问号的：这不就是一个把聊天框塞进 IDE 的套壳产品吗？3 个月后用回头来看，这个判断错得离谱。从装好那天到现在，我已经把它从“偶尔玩一下的玩具”用成了“每天敢交实战任务的同事”，中间踩过不少坑，也攒了一堆文档里查不到的细节。这篇文章就是我这 3 个月的实战笔记，30 个技巧，按使用阶段排好，从安装配置讲到团队协作，再讲到各种疑难杂症，希望让刚接触的人少走弯路，也让已经用起来的人敢把更重要的活儿交给它。
先说结论：WorkBuddy 和 CodeBuddy 这类工具，本质是“模型能力 + 工程化封装”。模型大家都能调到，真正拉开体验差距的，是你会不会用它那套技能系统、上下文管理、自定义指令。很多人的体感是“这东西也就这样”，多半是没把它当成一个可以调教的工具，而是当成了一个聊天框。下面我按自己实际使用的顺序，把这 30 个技巧一条一条拆开讲。
1. 从安装到初始配置：前 30 分钟决定后面 3 个月的体验
WorkBuddy 的安装本身没什么门槛，官网下载对应系统版本，双击下一步就行。但安装完之后的前 30 分钟，大部分人都会犯同一个错误：不调设置直接开聊。结果就是生成风格不对、上下文老是丢、缓存把 C 盘塞满，然后转头骂工具不好用。其实这 30 分钟花得值不值，直接决定了你后面 3 个月是“能用”还是“好用”。
1.1 版本选择和安装时的 3 个关键判断
技巧 1：优先选稳定版，不要追新
WorkBuddy 的版本更新很勤，但我的经验是：主力机器装 stable 版本，尝鲜功能放到测试机。新版本经常伴随插件兼容问题，比如某个版本的 SSH 连接器失效，或者 Skill 加载变慢，这种问题在稳定版上基本不会遇到。我见过同事为了一个新功能升级，结果白屏两天，最后回滚才救回来。
技巧 2：安装路径和缓存目录，一开始就分盘
默认情况下，WorkBuddy 的缓存和模型临时文件会写在系统盘。如果你 C 盘本身紧张，用两周就能多出十几个 GB。这个后面会专门讲怎么改，但更聪明的做法是安装的时候就选自定义路径，把整个应用和缓存都放在一个空间充裕的盘里。不要觉得这是小事，缓存满了之后工具会变得异常迟钝，而且很难排查。
技巧 3：登录方式和账号体系要确认清楚
WorkBuddy 有官方版和国际版的说法，不同版本的账号体系不互通。你在这个版本里积累的 Skill、自定义指令、会话记忆，换到另一个版本是带不过去的。所以装之前先想清楚自己长期用哪个环境，别来回横跳。我的建议是：如果你日常使用的网络环境访问官方服务比较顺畅，就直接用官方版，省心。登录之后第一时间看一下设置里的账号信息，确认没有登错。
技巧 4：插件装精不装多
WorkBuddy 的插件市场里东西不少，但装多了会拖慢启动速度，而且插件之间的 Skill 可能互相干扰。我实际用下来，保留这几类就够：代码补全增强、PDF 解析、SSH 连接器、代码审查。其余用到再装，不用就禁用。插件这事跟手机 App 一样，装的时候觉得以后能用上，实际上 90% 不会打开。
1.2 安装后必须先改的 5 个设置
技巧 5：把输出长度和温度参数调到你舒服的区间
WorkBuddy 默认的参数偏“保守”，生成的代码风格比较平。如果你希望它写得更有倾向性，可以在设置里调温度参数。做业务代码我建议温度低一点，输出稳定；做文案、润色这类创造性内容，温度可以适当调高。这不是玄学，温度直接影响 token 的采样随机性，调高了天马行空，调低了千篇一律。
技巧 6：自动补全的触发方式改成手动
很多人觉得自动补全很爽，但实际干活的时候，它频繁弹提示会打断思路。我设置了快捷键手动触发补全，需要的时候按一下，不需要的时候就安静待着。尤其在写业务逻辑比较复杂的文件时，手动触发能避免 AI 往你的代码里塞一些你没想清楚的设计。
技巧 7：自定义指令模板写起来，越早越好
WorkBuddy 支持自定义指令，相当于给你一个“全局人设”。我第一时间就把自己的指令模板写好了：我是谁、我在做什么项目、代码风格是什么、禁止做什么。别嫌这一步麻烦，这相当于给 AI 做入职培训，培训完了它才能直接上手。后面我会专门拆解一套减少 AI 味的指令写法。
技巧 8：关掉和你无关的遥测和数据收集
在隐私设置里，把非必要的诊断数据开关关掉。这既是为了信息安全，也是为了让工具更纯粹地做本地任务。尤其是公司项目，代码片段会不会被发送到远端，一定要看清楚设置项。别觉得这是小题大做，数据合规这件事，越早养成习惯越好。
技巧 9：改快捷键，把高频操作放到手边
WorkBuddy 的默认快捷键跟很多 IDE 不一样，刚上手时总按错。我花了一个小时把常用操作改了：唤起对话、触发补全、打开 Skill 面板、切换会话。这几个键位改好之后，效率提升是肉眼可见的。工具用得快不快，很多时候不是工具的问题，是快捷键顺不顺手的问题。
经过这 9 个技巧的沉淀，你已经有了一个“像样”的环境。接下来才是重头戏——怎么把对话能力从“乱问”变成“会问”。这一步做不好，后面所有技巧都白搭。
2. 对话和上下文管理：从“能聊”到“聊出能用的代码”
很多用户对 AI 编程助手的失望，源于一个误会：以为它真的能听懂人话。实际上大模型是在做概率预测，它需要的是结构清晰、上下文充分的输入。同一个任务，问法不同，结果可能天差地别。这章我整理了 9 个关于对话的技巧，全部是我自己反复试出来的。
2.1 提问的结构化：把模糊需求变成清晰指令
技巧 10：用“背景—任务—约束”三段式组织你的需求
我刚用 WorkBuddy 的时候，习惯直接说“帮我写一个登录功能”，结果它给我生成一个通用得不能再通用的模板。后来我改成：“背景：我们是一个电商后台系统，用户数据在 MySQL 里；任务：写一个手机号加验证码的登录接口；约束：用 Python FastAPI，异常处理要完整，禁止使用全局变量。”同一个模型，输出完全不一样。这就是背景—任务—约束三段式的力量——它给模型提供了决策所需的全部信息，模型就不用瞎猜。
技巧 11：给代码上下文，而不是给截图
很多人问代码问题，喜欢贴一张截图。WorkBuddy 本身有视觉能力，但截图会损失代码结构信息，而且模型经常会“看错”缩进。正确做法是把相关代码直接粘贴进对话，或者用 @文件引用功能让它直接读文件。截图只能用来描述界面问题，代码问题一律贴原文。
技巧 12：复杂任务拆成多轮对话，不要想一口吃成胖子
我最早犯的错，是让它一口气“帮我重构整个订单模块”。这种任务放在一个对话里，结果必然是写到一半开始胡编。现在我的做法是：先让它分析现状，再分步执行，每一步确认后再往下走。比如重构一个模块，我会先问“这个模块里有哪些坏味道”，然后让它列出重构计划，确认后再一步步改。WorkBuddy 本身有很长的上下文窗口，但长上下文不等于高质量输出，拆开做反而更稳。
技巧 13：把“不要做什么”写进指令，比只写“要做什么”更管用
大模型有个特点：你不说不要什么，它就按自己的偏好来。写代码的时候我通常会加一句“不要重写无关代码”“不要优化不需要优化的部分”“不要加注释以外的日志”。这些负面约束能极大减少它的“自由发挥”。尤其是在改别人代码的时候，没有约束它就是脱缰的野马。
2.2 上下文引用的熟练使用
技巧 14：@文件、@目录和 @代码块，是 WorkBuddy 最被低估的功能
很多人跟 AI 对话，全靠粘贴代码，粘贴不完就说“还有几个文件没贴”。WorkBuddy 支持直接引用工作区里的文件和目录，你只要 @一个文件，它就能读到完整内容。我处理多文件项目时，会把相关的几个文件全部 @进来，然后告诉它“这三个文件是一个模块，现在要改的是……”这样它就具备了完整上下文，而不是只看你截取的那一段。
技巧 15：会话的开启和重新开启，要像写代码一样有“生命周期”
WorkBuddy 的会话是有上下文的，但上下文越堆越长，干扰越大。我的经验是：一个任务开一个会话，任务结束就关掉；如果中途换任务，不要在原会话里继续，新建一个会话反而更快。这跟人一样，脑子里装着一堆上一个任务的事情，处理新任务容易串线。会话开多了还能按项目维度管理，找历史记录也方便。
2.3 跨会话记忆与个性化的进阶操作
技巧 16：把常用的规范写成规则文件，在对话开头引用
团队有代码规范、命名规范、接口规范，这些内容如果每个对话都重复一遍，太累。我把规范写成 markdown 文件放在项目里，用的时候第一句就说“先读一下 docs/coding-rules.md 里的规则，后续回答都基于这个文件”。这是短期记忆的“外挂”，相当于每次对话开始前，先给它做一次定向培训。
技巧 17：更换账号后，如何继承原来账号的记忆
这是一个高频问题。WorkBuddy 的会话记录默认绑定账号，换账号之后旧记忆不会自动带过来。我的做法是：重要的规范、常用指令、调好的 Skill 配置，统统导出成一个“配置包”放在本地或团队公共盘里。换账号后，先把自定义指令文件重新导入，再把 Skill 安装包装回来，最后把关键项目的历史会话通过导出功能保存成文本。这样虽然需要十几分钟重新熟悉，但不会“失忆”。如果你在团队里，可以把这个配置包放到公共仓库里，新成员入职直接导入一套现成的环境，非常省事。
技巧 18：善用“虚拟环境”，同一个项目可以开多个独立上下文
WorkBuddy 支持按项目或目录划分工作台，我理解这就是“虚拟环境”。同样的代码，在不同工作台里可以保持不同的对话上下文，互不干扰。我通常按“开发”“代码审查”“技术调研”拆成三个工作台，切来切去不会混淆。这也是它比单纯网页版聊天好用得多的原因。
到这一步，你已经可以跟它顺畅沟通了。但真正让它从“聊天助手”变成“干活主力”的，是它的 Skill 体系。这也是热词里大家最关注的部分。
3. Skill 实战：让它学会“成套地干活”，而不是一问一答
如果说对话是“手把手教”，那 Skill 就是“你只要说出触发词，它就启动一套完整的流程”。打个比方：你不需要跟一个实习生解释什么是“代码审查”，你只要说“帮我 review 这个模块”，他就知道要看哪些方面。Skill 就是让 AI 掌握这种“成套能力”的核心机制。
3.1 哪些 Skill 最值得装，我心中的前三名
技巧 19：代码审查类 Skill——装好后你的代码质量会提升一个档次
我用的最多的 Skill 是代码审查类的。触发后，它会按我指定的维度逐个文件过一遍：bug 风险、边界条件、命名规范、潜在性能问题。以前人工 review 可能要 40 分钟一个文件，现在它先跑一遍，我再重点看它标记的高风险项，10 分钟结束。更关键的是，它给出的 review 意见我可以直接以评论形式导出，发给同事参考，比我干巴巴地写几条要有说服力得多。
技巧 20：测试生成类 Skill——让团队从“不写测试”变成“先跑测试”
我以前也很讨厌写单测，自从用了一个测试生成 Skill，流程变成：选中函数，触发 Skill，它生成测试用例和边界条件，我再手动补一两个特殊情况。这个 Skill 的价值不只是省时间，更大的作用是改变团队习惯——生成测试的成本变低了，大家才更愿意写测试。
技巧 21：文档生成类 Skill——把“写文档”从负担变成顺手的事
接口文档、模块说明、变更记录，这类工作最枯燥，但 AI 做这种结构化输出比写代码还稳。我触发文档生成 Skill 后，它会读代码自动生成文档框架，我再补充业务背景。以前写一个模块文档要两小时，现在十分钟出初稿。
3.2 自己调教 Skill：一套能复制的通用套路
技巧 22：先搞清楚 Skill 的“职能边界”，再写描述
很多人自己创建 Skill 时，恨不得让一个 Skill 干所有事，结果就是什么都干不好。我的建议是一个 Skill 只负责一件事：代码审查就只审查，测试生成就只生成测试，文档生成就只写文档。Skill 的触发描述决定了它什么时候被唤起，描述越精确越好。你写“检查代码有没有问题”，它会在奇怪的时候被触发；你写“当用户要求对当前代码做架构层面分析时使用”，它就会只在合适的场景出现。
技巧 23：把团队规范内嵌到 Skill 里，效果翻倍
创建一个 Skill 时，不要只写“生成测试”，要把团队用的测试框架、断言风格、数据库 mock 方式都写进去。这样 Skill 的产出才是团队可用的，而不是一个通用模板。我重写了一下测试生成 Skill，加入了公司的 pytest 规范和工厂函数用法，生成出来的测试基本可以直接提交 CI。
技巧 24：Skill 也要版本管理，改一次就迭代一版
Skill 本质上是“人设 + 流程 + 模板”的组合体，它需要持续调教。我每次用 Skill 发现问题，都会顺手把优化点记下来，等攒到 3-5 条就更新一次 Skill 描述。Skill 的说明要写上版本号和本次改动内容，方便回滚。这不是程序员强迫症，Skill 迭代到第 4 版和第 1 版的产出质量，差距是肉眼可见的。
Skill 是 WorkBuddy 的“肌肉”，而记忆和上下文是它的“大脑”。但光有肌肉和大脑还不够，还要让它输出得更自然——比如怎么减少 AI 味，怎么让生成的内容不像机器写的。这是接下来要说的核心技术。
4. 消除 AI 味：从“一看就是 AI 写的”到“像是老同事的手笔”
“AI 味”这个词，应该每一个深度用户都体会过。最典型的就是：回答开篇就是“首先……其次……最后”，代码注释全是“// 初始化 xxx”，文档永远用“随着……的发展”。在 WorkBuddy 里，这个问题可以通过指令技巧大幅改善，甚至能做到和资深同事的口吻一致。
4.1 用指令压制“AI 腔”
技巧 25：在自定义指令里明确写下“不要做什么”
我在全局自定义指令里加了一条：禁止使用“首先、其次、最后、综上、通过以上方法”等句式；禁止在代码块外添加多余解释；禁止使用感叹号和过于礼貌的用语。这几条一加，输出风格立刻变了。你会发现，大模型不是不会说人话，而是没有被告知“这里要说人话”。
技巧 26：给出范例，比反复说“不要 AI 味”有用得多
“口语化一点”“自然一点”这种抽象要求，远不如给一个范例来得直接。我会在指令里写：“参考这样的风格：xx 功能已上线，主要改了三处，其中 xx 模块的改动影响面最大，需要注意回归测试。”它看到具体样例，输出的风格就会被这个样例锚定。要纠正 AI 的文本风格，最好的办法是给它一块“靶子”。
技巧 27：在文档和注释场景，要求它站在“人”的视角写
写注释时，我要求它说“为什么这么做”而不是“这段代码做了什么”。因为“做了什么”从代码里就能看到，无需注释；“为什么”才是人留下的经验。比如让它写注释时用“这里不能直接用 xx，因为会引入循环依赖”这种句式，代码的可读性会提升很多。这不仅是风格问题，更是注释价值的本质问题。
4.2 用工作流减少“返工”：让 AI 先说思路，再动手
技巧 28：让 AI 先给方案，你确认后再让它写代码，减少 70% 的返工
以前我一上来就让它“写”，写完发现方向不对，又让它“改”，一来二去浪费大量时间。现在我要求它必须先说方案，我确认后再动手。比如让它“重构这个函数”，它先给重构点分析；我看了方案，有不同意的地方提前说。这样虽然多了一轮对话，但实际上是最省时间的方式，因为方向错了写多少都是白写。
技巧 29：区分“快任务”和“慢任务”，不同任务用不同会话策略
简单问题，比如“这个报错什么意思”，直接快问快答；复杂重构，比如“优化这个模块的架构”，要走慢流程：方案确认、逐步执行、代码审查。WorkBuddy 的会话模式支持这种区分。快任务用普通对话就好，慢任务就该配合 Skill 和规范文件反复校验。有的人觉得 AI 不靠谱，就是把慢任务当快任务问，拿到的浅层答案自然不靠谱。
4.3 从“生成代码”到“生成合格交付物”
技巧 30：用“交付物检查清单”来验收 AI 的产出，没有清单不验收
最后一个技巧，也是最容易被忽视的：AI 生成代码之后，你要有一套验收清单，而不是“看着差不多”就收。我的清单包括：是否有异常处理、是否有边界条件、是否有输入校验、是否遵循团队命名规范、是否有不必要的重复代码、是否引入了不相关改动。这个清单不是我拍的，而是我踩了无数次坑后总结出来的。没有清单的时候，AI“看起来没问题”的代码，上线两天就出幺蛾子；有了清单之后，它生成的东西我会先过一遍清单，不合规的直接丢回去改。敢不敢把活交给它，取决于你是否有能力验收它的活。
5. 面向真实场景的进阶玩法：远程连接、双人协作和典型行业落地
当你掌握了前面这些基础技巧，WorkBuddy 就不再是“代码片段生成器”了。它开始变成一个能进到具体业务场景里干活的角色。这一章我挑了几个使用频率最高的场景展开讲，包括远程开发、团队协作，以及非程序员怎么用它。
5.1 SSH 连接器和远程开发场景
技巧 31：SSH 连接器配好后，本地和服务器代码能无缝操作
WorkBuddy 支持 SSH 连接器，可以直接打开远程服务器上的代码，就像本地文件一样对话处理。我日常开发是在云服务器上，以前要在本地编辑器里改完再上传，现在直接在连接器里改，改完让 WorkBuddy 顺手跑一下测试。这个功能对服务器不在本地的场景非常实用，省去了来回同步文件的烦恼。配置时需要注意：SSH 的密钥路径要写对，连接超时时间建议设置长一些，避免大项目加载到一半断连。
5.2 团队协作：记忆共享、统一模板和规范落地
技巧 32：把团队的“AI 使用规范”沉淀到文档里，新人入职直接复制
我在团队里推行过一件事：把 WorkBuddy 的自定义指令、Skill 清单、常用会话模板整理成一个文档，放到团队知识库里。新同事入职，照着文档配置一遍，出来的代码风格和老员工基本一致。有人担心 AI 会让代码风格更乱，其实只要团队统一了 AI 的指令规范，风格反而比以前更整齐。
5.3 非程序员的使用方式：客服、科研、产品、运营都在用它
技巧 33：客服负责人可以用它搭“话术知识库”和“工单摘要器”
热词里有人问“作为客服负责人怎么快速使用 WorkBuddy”，我的答案是：别把它当编程工具，把它当“文本处理器”。你可以把历史优秀工单导入，让它总结出常见问题和标准答复模板；也可以让它每天自动摘要当天的工单，按紧急程度排序。它的核心能力是“从大量文本中提取结构”，这恰恰是客服管理最需要的。
技巧 34：科研和 PDF 场景：论文总结、术语解释、公式推导都很顺手
WorkBuddy 的 PDF 解析能力比很多通用阅读器好。我帮一个做科研的朋友配置过：把 PDF 论文拖进去，它自动总结摘要、提取关键方法、对比结论，还能把不理解的公式拆开解释。科研人群最需要的是“陪伴式阅读”——哪里不懂点哪里，它能把论文嚼碎了喂给你。如果你是在校学生，用它读文献、写综述初稿，效率能翻倍。
6. 常见问题排查：安装后白屏、缓存目录修改、Skill 不生效
最后一部分，是老用户最关心的问题。我在网上搜 WorkBuddy 教程的时候，看到最多的就是“安装后白屏怎么办”“怎么更改系统缓存目录”“Skill 不生效是什么原因”。这些问题我全遇到过，把排查思路和解决办法整理出来，给你当速查表用。
6.1 安装后白屏和打不开的排查思路
技巧 35：白屏八成不是产品坏了，而是显卡渲染和缓存冲突
WorkBuddy 安装后白屏，最常见的三个原因：显卡驱动与 WebView 渲染不兼容、旧版本缓存残留、权限不足。排查步骤我建议从简到繁：第一步重启应用，确认是不是偶发问题；第二步关闭硬件加速，在设置里找到渲染选项，改软件渲染；第三步清除应用缓存目录，注意先备份；第四步卸载重装，装之前确认旧版本的配置文件也清干净了。按这个顺序，九成白屏问题都能解决。
6.2 系统缓存目录换位置的完整操作流程
技巧 36：缓存目录换位置，其实改个配置就能解决，不用重新安装
很多 Windows 用户 C 盘空间不够，这时候需要把 WorkBuddy 的缓存目录改到其他盘。我的做法是：先找到当前缓存目录确认数据量，关闭应用后用管理员权限打开命令行，把默认缓存目录迁移到新位置，然后在新位置建立一个符号链接，指向原路径。这样应用本身不用重新安装，所有的缓存数据就“迁移”到新盘了。操作完之后再打开应用，你会发现它不仅启动更快，而且 C 盘空间一下子释放出好几个 GB。
6.3 Skill 不生效和加载变慢的排查方向
技巧 37：Skill 不生效，先检查触发描述和当前会话的上下文是否匹配
Skill 不生效通常不是 bug，而是触发条件没满足。WorkBuddy 判断是否启用某个 Skill，是看用户描述和 Skill 触发描述的匹配度。如果你的 Skill 描述写得太泛，它可能在错误的时候不触发；写得太细，又容易一个都匹配不上。我的建议是：触发描述设置成中等粒度，包含核心场景关键词就好，同时确保当前会话里确实给出了足够上下文。
6.4 日常卡顿和“越用越慢”的处理办法
技巧 38：定期清理会话历史和临时文件，比重启应用更管用
WorkBuddy 用久了，会话历史会非常占内存，尤其是那些加载了大量文件的长会话。我每周都会做一次“大扫除”：删掉不需要的旧会话，清理临时文件，必要时重建一次索引。保持应用处于“轻盈”状态，它响应速度会快很多。工具越用越慢，很多都是数据积累导致的，而不是产品本身劣化。
6.5 数据安全与隐私：本地代码会不会被传到外部
技巧 39：动手之前先确认数据流向，敏感代码不要让 AI 处理
实话实说，这类 AI 编程工具的代码处理通常会上云，那就有数据隐私问题。我处理公司核心业务代码时，会先确认这个项目代码是否涉密，如果是，我不会把完整代码抛给它，而是抽取无关紧要的伪代码片段来问。大模型的能力在于通用规律，你不给它完整代码，只给它问题和关键逻辑，一样能得到有用的答案。这是使用 AI 工具时必须有的职业敏感。
写在最后：我对 WorkBuddy 的长期使用体会
这 39 个技巧看起来多，用起来其实是一个习惯养成的过程。最让我惊讶的不是它能写多少代码，而是当我把规范、Skill、记忆都配置好之后，它像一个真正懂我的同事，知道我们这个项目的代码风格、知道哪些地方容易踩坑、知道我不喜欢什么样的注释风格。这种“并肩作战”的感觉，和最初“一问一答”的体验是完全两回事。
如果你现在还在“能用但不敢用”的阶段，我的建议是：从技巧 10 的“三段式提问”开始练，再装一个代码审查类 Skill，然后把“交付物检查清单”抄到你自己的笔记里。这三步做完，你就会第一次体会到“敢把活儿交给它”是什么感觉。剩下的技巧，等你需要的时候再看，但它们一定会让你越用越顺。
