三个月前我把 WorkBuddy 装好的那一刻它在我眼里就是一个“带记忆的补全工具”。代码写一半它能接下去贴一段需求它能给你拟个初稿但也仅此而已——我压根不敢把完整的活儿交给它。真正改变我态度的是后来给它定规则、写 Skill、逐步放开权限的这三个月。这篇东西不聊玄乎的概念只聊我从“能用”到“敢把活儿交给它”过程中实际练出来的 30 个技巧有配置、有写法、有场景拆解也有我踩过的坑。如果你刚装上 WorkBuddy 想把它变成工作台的核心节点或者用了一段时间总觉得它“差点意思”这篇文章应该能帮你省掉不少摸索时间。1. 从“能用”到“敢用”我先纠正了对 WorkBuddy 的定位1.1 别把它当补全插件它在等你给“上下文”刚开始用 WorkBuddy 的时候我的操作习惯和用搜索引擎一样丢一句话等答案。比如“帮我优化一下这段代码”然后它就真给你优化了但优化出来的东西常常脱离了项目约束变量名换了一套调用的内部函数不对测试还过不了。问题出在哪不是它不够聪明是我没给它项目上下文。一个刚进组的实习生你让他“把那个表改一下”他连是哪个表都不知道自然只能靠猜。WorkBuddy 也这样它拿到的是当前会话里的碎片信息所有关于项目结构、代码规范、历史决策的细节都需要你主动喂给它。能记住上下文恰恰是它的优势前提是你要先给它足够的背景。所以我的第一个技巧很朴素把它当“可培训的实习生”而不是“字典”。愿景是我愿意花时间培训它它就能稳定分担重复劳动如果我只是当搜索引擎用那还不如直接 Google。第二个技巧随之而来先建一个隔离的测试项目把所有尝试都放进去。我刚上手时担心它乱改代码就在本地建了一个临时仓库专门扔给它一些“可以出错”的任务。比如让它重命名模块、批量加注释、生成单元测试。前两周里它在测试项目里把目录结构改得乱七八糟过也把某个函数重构得性能更差了但因为隔离开真实项目一点没受影响。这背后其实是个信任建设策略“敢用”不是靠胆子大而是靠试错成本足够低。等你确认了它的行为模式符合预期再逐步让它接触真实代码风险就完全可控了。这也是我后来跟团队分享时反复强调的一点——别一上来就把它接进生产仓库那是给自己找麻烦。1.2 每次交代任务先写清“完成定义”第三个技巧我称之为“孤立任务原则”前两周只让它跑不依赖核心业务的独立任务。写单元测试、整理 TODO 列表、生成接口文档、把零散的代码片段拼成可运行脚本——这类任务做坏了也不影响大局刚好用来摸清它的脾气。等到我开始给它派“正经活”又发现一个高频问题它经常“看似做完了但其实没按我的意思做”。我让它“给 utils/date.py 补几个测试”它给我补了五个假想的用例连函数都不存在。后来我意识到问题出在我对“完成”的定义太模糊。从那时起我养成了一个习惯——任务开始前先写“完成定义”。这句话直接落在提示词里比任何参数都管用。比如我现在让它写测试会这样说请为 utils/date.py 补充 6 个单元测试覆盖闰年、时区偏移、非法输入三种情况。 输出要求可直接运行的 pytest 代码并在每个用例旁用注释说明断言了什么。 完成标准pytest 执行后全部通过且不新增或修改 utils/date.py 的任何逻辑。这就是我的第四个技巧每次让它做事之前先交代“完成标准、输出格式、验收条件”。给得越具体它越不会自由发挥。我观察过一个有意思的现象凡是给了完成定义的任务返工率明显低于那些只有一句话要求的任务。原因不复杂——它不是不听话而是没有边界的时候只能按自己的概率分布去猜猜的范围一大偏离你意图的可能性就跟着变大。如果你觉得每次都手打太长可以把常见的完成定义存成模板片段比如“测试类任务”“文档类任务”“代码评审类任务”各存一份。三个月下来我存了十几条模板现在分配任务的速度反而比刚开始快了不少。2. 环境准备决定后 90 天的幸福感缓存、版本与部署方式2.1 缓存目录别留在默认盘先解决磁盘焦虑很多人在意的是 WorkBuddy 好不好用却忽略了它的本地存储习惯。这个工具会把模型上下文、历史会话、文件索引都落在本地用久了体积比我预想的大得多。有段时间我的系统盘从 50GB 可用直接掉到 12GB查了一圈才发现是它的缓存目录在“默默膨胀”。所以第五个技巧是安装完成之后第一件事就是迁移系统缓存目录。我的做法是在配置里把缓存路径指到一块空间充裕的独立磁盘。以我使用的版本为例可以在配置文件里设置缓存路径也可以通过环境变量的方式指定# Linux/macOS 设置缓存目录示例 export WORKBUDDY_CACHE_DIR/data/workbuddy_cache# Windows PowerShell 设置缓存目录示例 $env:WORKBUDDY_CACHE_DIR D:\WorkBuddyCache如果你用的是 Docker 部署那更简单也更重要——见下文 2.3 的持久化挂载。迁移完之后记得重启应用确认新路径已经生效再开始用否则历史索引还在旧位置等于白迁。别小看这个操作我这三个月里见过不止一次因为磁盘写满导致索引失效、历史记录丢失的情况绝大多数是缓存目录默认放在系统盘导致的。2.2 版本渠道稳定正式版优先老环境先做最小验证第六个技巧和版本选择有关从官方渠道下载安装包优先用稳定正式版。有一阵我贪新鲜用了某个预发布版本结果一连几次看到它更新后规则配置的解析格式变了我自定义的全局规则莫名失效。后来老老实实换回正式版才消停。需要说明的是WorkBuddy 不同版本渠道比如国内版和国际版在账号体系、更新节奏上会有差异具体以官方文档和官网指引为准。如果是为了长期稳定使用别追新追得太激进。第七个技巧专门给容器用户Docker 部署时一定要挂载持久化目录。我最早的部署方式非常简单直接docker run拉起来就跑等到某次容器重建后发现所有的 Skill 配置和历史会话全丢了相当于白忙了两天。后来换成 docker compose把配置和缓存目录显式挂载出来services: workbuddy: image: workbuddy/workbuddy:stable volumes: - ./workbuddy_data:/data - ./workbuddy_config:/config restart: unless-stopped这样之后容器随便重建配置和缓存都还在。对需要长期维护工作台的人来说这一步非常重要。第八个技巧写给还在用老环境的读者如果你在 Win7 这类老系统或者精简版 Linux 上跑先做一次最小验证再上真实任务。这里容易遇到的问题多半是运行依赖、系统组件版本太旧表现是安装完打不开或者能打开但一加载模型就闪退。别急着重装先看日志日志里会明确提示缺哪个库或哪个组件版本过低。通常补上对应依赖就能解决如果确实系统太老那就老实换机器或改用容器方案硬折腾只是在消耗自己的耐心。3. 规则是 WorkBuddy 的“长期记忆”全局规则、项目级规则与禁止事项3.1 全局规则定一次对所有任务生效用过一段时间后你就知道靠每次对话重复交代“请用中文”“请按公司规范”“别动测试文件”是不现实的。先说三句能记住说三十句自己也嫌烦。WorkBuddy 的全局规则机制就是为了解决这个问题——只要设定一次后续所有任务都会带上这套约束。我的第九个技巧就是认真写一份全局规则把手边所有项目的通用约束放进去。我自己的规则文件类似这个结构# Global Rules for WorkBuddy - 所有回答和代码注释使用简体中文代码中的命名保持英文。 - 修改代码前先输出将要改动的 diff等待确认后再写入。 - 禁止删除或重命名 tests/ 目录下的文件除非用户明确要求。 - 输出代码时附带简要变更说明说明不超过 5 行。 - 遇到不确定的信息明确回复“不确定”不要编造。 - 生成文档时先输出目录结构和摘要再展开正文。写完之后在 WorkBuddy 的设置里把它配置为全局规则。之后你再开新会话它都会带着这套规则运行。这个机制被很多人忽略但它恰恰是“从能用走向敢用”的分水岭——规则定得好它的行为就稳定规则不定它就每次都是新员工水平。第十个技巧是项目级规则覆盖全局规则。全局规则照顾的是所有项目的共性但每个项目有自己的特例。比如我在一个 Python 项目里要求它优先用类型注解在另一个前端项目里又要求它不要动 package.json 的依赖版本。这种差异如果也写进全局规则全局规则很快就会变得庞大又互相冲突。我的做法是在项目根目录放一份.workbuddy/rules.md里面写这个项目的专属约束。WorkBuddy 会把项目规则和全局规则叠加读取我的实际使用感受是项目级规则优先于全局规则而当前对话里的临时指令优先于项目级规则。按这个优先级去设计规则你基本不会遇到“它不知道听谁的”的情况。3.2 禁止事项比希望事项更有效第十一个技巧来自我踩过的一个坑规则里光写“希望它做什么”不够要多写“禁止它做什么”。从一个反面例子讲起。我曾经在规则里写“请认真负责地处理所有任务”结果呢它确实“认真负责”地帮我删掉了一个目录里的 TODO 注释理由是“保持代码整洁”。我哭笑不得——它根本无法量化“认真负责”这种词只能按自己的理解去执行。后来我把这类规则全部改成具体禁令不要删除代码中的 TODO 注释。不要直接覆盖原文件先输出 diff。不要修改 src/core 目录下的文件。不确定命令结果时不要执行先请求确认。效果立竿见影。原因也好理解“应该”类描述给了它自行解读的空间“禁止”类描述给出了明确的边界约束。任何 AI 工具都一样你划的边界越具体它越不会自由发挥。第十二个技巧是关于报错处理的。很多人在 WorkBuddy 执行任务报错时顺手贴一句“运行失败了帮我看看”。这差不多是它最没法回答的问题——只有“失败”这个结论没有日志、没有上下文、没有它上一步做了什么。我在三个月里逐渐养成了一个习惯报错时贴完整上下文最好是让它在执行过程中保留中间输出。比如我会说重新执行上一步但这次每执行一个命令就输出完整日志不要中断最后把失败点和你判断的原因给我。这样它就能在同一个上下文中定位问题而不是对着一个孤零零的错误码瞎猜。这个技巧尤其适合 WorkBuddy 这种需要多步骤执行的场景上下文连贯性就是它的命根子。4. Skill 是灵魂六个高频场景和高效写法4.1 Skill 与提示词的区别封装操作流程用 WorkBuddy 三个月最让我觉得“值回票价”的功能是 Skill。简单说提示词是一次性的你这次写一段话它这次按这段话执行下次还得重新写。而 Skill 是把“任务定义、输入要求、执行步骤、输出格式、边界条件”打包成一个可复用的模块。比如我只需要在对话里说“帮我 review 一下 src/utils 目录”它就会按之前定义好的步骤执行而不是每次都从零理解“review 是什么意思”。打个比方提示词像是你临时教一个新人“这次要这样做”Skill 则是把整套操作流程写成了标准作业手册新人照着手册走就行不会东一榔头西一棒子。我的第十三个技巧因此很简单把高频操作封装成 Skill别再反复改提示词。真实代码里我用的一个 Skill 长这样name: code-review description: 对指定目录的代码执行一轮 Code Review输出问题清单和改进建议 input: target_dir: 需要 review 的目录 steps: - 读取 target_dir 下的所有源码文件 - 按性能、安全、可读性三个维度分析 - 生成逐个问题的修改建议 output: markdown 表格问题级别、文件名、行号、问题描述、修改建议 guardrail: - 只输出检查报告不修改任何文件第十四个技巧是先使用官方推荐的 Skill再考虑第三方社区 Skill。官方 Skill 至少经过基础验证行为边界相对清晰。第三方 Skill 看起来功能更炫但你很难确认它是否会请求文件写入权限、会不会执行额外命令。我见过一个社区 Skill 的描述里写着“自动收集系统信息”实际上它会尝试读取用户目录下的各种配置文件。不是说所有第三方 Skill 都有问题但在安全审核机制还不够成熟的阶段谨慎一点不亏。第十五个技巧为每个 Skill 写清触发词和适用边界。很多人抱怨“这个 Skill 怎么总乱跑”我看了他们的配置发现 Skill 描述里只写了“分析文件并生成报告”既没说清输入是什么也没说清不负责什么。于是它能跑偏到什么程度取决于它那天的心情。我后来在每个 Skill 里都加一句边界说明比如“此 Skill 只接受代码目录作为输入不处理 PDF、不处理数据库文件”问题立刻减少。4.2 实测后我认为最值得用的六类 Skill第十六个技巧是学会组合 Skill但在组合之前你得先有可靠的底座。我筛选到最后的常用 Skill 一共六类code-review代码评审在合并 PR 之前让它输出问题清单。这个 Skill 最成熟帮我抓出过很多隐藏的异常处理缺失和资源泄漏点。test-generator测试生成给它一个函数或文件让它生成 pytest 用例。配合第一章说的“完成定义”能稳定补出新功能的测试覆盖。doc-writer文档生成从代码里生成 README、接口说明、变更日志。对维护老项目特别有用能快速补上欠了很久的文档债。literature-review文献综述给它一个主题和一批 PDF它会按“研究问题、方法、结果、局限”生成摘要卡片。我后面单独写一节讲这个。customer-service-kb客服知识库问答导入 FAQ、历史工单、话术模板让它严格按知识库口径回答超出范围转人工。todo-manager任务拆解把一个需求拆成可执行事项并输出每项完成标准。每一类我都用了至少一个月。如果让我给优先级排序code-review 和 test-generator 是最先值得试的因为它们的输入输出边界都清楚又直接踩在开发痛点上。至于文献综述和客服场景更适合你的工作流里确实有这类需求时再引入否则容易变成让 WorkBuddy 学了一堆用不上的技能。4.3 组合 Skill 的顺序和兜底逻辑第十六个技巧我在上一节提到一半这里展开多个 Skill 组合时指定执行顺序和输出结构。比如我常让它做这样一个流程“先用 code-review 扫描问题再用 doc-writer 把问题整理成一篇改进说明最后用 todo-manager 把改进说明拆成整改任务。”如果没有指定顺序它经常会把结果混在一起前一个 Skill 的输出变成后一个的输入时字段对不上格式也乱。所以我在组合时会明确说依次执行代码评审、文档生成、任务拆解三个 Skill。 每一步的输入以上一步的输出为准最终输出一份 markdown 文档 第一部分是问题清单第二部分是改进说明第三部分是整改任务表。第十七个技巧是关于淘汰的定期复盘 Skill 的使用效果持续淘汰。3 个月里我把 20 多个官方 Skill 砍到 8 个又自己写了 5 个。淘汰标准很简单——两周内没用过的移出常用列表用了但每次都要额外纠正的说明 Skill 本身设计有问题要么改要么扔。这个筛选过程本身就是对工作流的梳理你频繁用哪些能力其实是另一个信号告诉你哪些重复劳动最值得交给它。第十八个技巧是兜底设计给 Skill 增加“输入不足时先反问”的规则。这个是防止它在信息缺失时瞎猜的保险。我在 Skill 描述里加过一句话“如果 target_dir 不存在先请用户确认不要自行假设路径。”就这么一句让它避免了很多低级错误。没有这条兜底它会在你少给一个参数时自己脑补一个默认值结果就是“做完了给你看时文件在另一个路径下躺了十分钟”的闹剧。5. 敢把活儿交给它的底层逻辑安全审核、执行边界与结果验证5.1 给权限分级文件写入先确认命令执行限定白名单“敢把活儿交给它”和“让它随便跑”是两回事。我见过不少人把 WorkBuddy 的权限开到最大结果它执行rm命令时毫不含糊删完了才跟主人说“已清理”。这不是工具的错是授权方式太粗糙了。第十九个技巧文件写入类操作先开确认模式。在 WorkBuddy 里做文件修改时我一般会明确要求它“先输出将要修改的 diff我确认后再写入”。你可能会觉得这样很慢实际用下来它生成 diff 的速度远比你手动改文件快你只需要扫一眼有没有越界改动就行。这一步防的是它“顺手”改错细节。第二十个技巧是关于命令执行的为 WorkBuddy 限定工作目录和允许命令白名单。我自己的配置大概是这样{ permissions: { command_whitelist: [git, python, pytest, node, docker compose], path_allowed: [/workspace/myproject], confirm_on_write: true } }设置白名单之后它能执行的命令少得多了但刚好覆盖了日常开发里最常用的那几类。它一旦尝试执行白名单之外的命令系统会拦截并要求我确认。这样做的结果是它做“正事”的效率一点没降但乱来空间被大幅压缩。很多安全事件其实都不是它“恶意”而是它对某个不常见命令的副作用判断不准白名单相当于给它加了一层安全网。第二十一个技巧每次代码改动必须附带变更说明。我要求 WorkBuddy 每次修改后输出三样东西改动文件清单、改动原因、影响范围。没有这三样的改动我一律打回重做。这不是形式主义而是为了让我在 review 时能在几十秒内判断它的改动是否合理。时间长了它甚至会自动在输出末尾挂上说明块已经变成了它执行任务时的一种稳定习惯。5.2 “干完了”不等于“干对了”结果先看结构再看细节第二十二个技巧是关于结果验收的先看结构再看细节。我踩过这种坑它生成了三千字的分析报告逻辑看起来很完整但真正关键的数据表格里有一处引用错误。原因是我全程盯着那三千字看眼睛已经被长篇大论带着走了反而忽略了最重要的问题。后来我的验收习惯变成拿到结果先让它给我“结论摘要和证据列表”然后只看结论部分再顺着结论抽查几个关键细节。比如让它写测试我先看它列了哪几个测试场景再看断言写得对不对最后才看代码细节。结构对了细节基本不会差太多结构不对细节再怎么漂亮都是白费。第二十三个技巧关键改动保留 diff 备份随时可回滚。我在让 WorkBuddy 处理重要改动之前会先确保当前代码在 Git 里处于一个干净提交点。它每做完一轮改动我把改动生成一份 diff 日志git diff /data/changelogs/$(date %F).diff一旦后续测试发现问题回滚只需要git checkout .一条命令。这个习惯帮我救过一次大麻烦它自作主张“修复”了一个依赖版本导致 CI 直接挂了。因为我保留了 diff 和之前的提交点十分钟内全量回滚没有造成任何数据损失。信任不是某个开关而是一整套“可以犯错但犯错了也不慌”的基础设施。5.3 给它一个隔离工作区如果条件允许我会建议给 WorkBuddy 配置一个隔离工作区。比如 Docker 容器里跑一个专用用户把生产目录设为只读挂载让它接触不到的边界尽量多。它需要执行高风险操作时只能在容器内的工作目录里完成改坏了直接重置容器即可。这段话听起来像是在说技术细节但本质上是心态问题你敢不敢把活儿交给它取决于你预设它可能会出错并且已经为出错准备了退路。有了退路你才敢放心大胆地用没有退路你会一直小心翼翼慢慢它就变成摆设了。6. 三个月场景复盘写代码、文献综述、客服工作台与多工具配合6.1 开发场景WorkBuddy Cursor 怎么分工聊到 WorkBuddy很多人会顺口问它和 CodeBuddy、ZCode、Trae Work 这些工具有什么区别。我自己的使用感受是CodeBuddy 更贴近“结对编程助手”坐在你旁边陪你一行行写代码ZCode 偏云 IDE 协同Trae Work 更侧重一体化对话式开发而 WorkBuddy 的特性在于可编程的 Skill 和规则体系它更像一个“工作台”能承担跨项目的多步骤任务。我目前最顺手的配合方式是编辑器里用 Cursor 做实时补全WorkBuddy 做跨项目的活儿和高强度重复劳动。示例就是接一个遗留 Node 项目时我会先让 WorkBuddy 做全项目扫描生成模块依赖关系文本再让它对高危模块做重构建议最后我自己在 Cursor 里手工微调关键逻辑。它负责的是“全局视角的重复劳动”我负责的是“需要手感和小范围精确判断的活”。这算第二十四个技巧别让它做所有事给它分一个清晰的工位。选择工具之前不妨先梳理自己的工作流在哪一环最痛。如果痛点是你每天要改十几个文件、重复劳动多WorkBuddy 这种工作台型工具比较对症如果你只需要编辑器里即时补全那轻量插件就够了。工具之间不是对立关系组合起来往往比单独拉两个“全家桶”更舒服。6.2 写文献综述从一堆 PDF 到结构化初稿这块我要单独讲因为很多人问“WorkBuddy 写文献综述到底靠不靠谱”。我的答案是靠谱的前提是你给它搭好“文献管理流程”否则它就是个大号摘要工具。第二十五个技巧先让它制定文献纳入/排除标准再开始整理资料。比如我会这样交代主题边缘计算中的任务卸载 纳入标准2019 年以后发表、核心期刊或会议、包含真实实验数据 排除标准纯综述文章、没有明确实验设置的论文 请先扫描 /data/papers 下的 PDF按照这个标准输出一份候选论文清单标注每篇符合/不符合的理由。这一步看起来多花了两分钟但它让 WorkBuddy 从一开始就和你站在同一套评价体系里后面整理出来的东西才不至于跑偏。第二十六个技巧摘要卡片法比“让它直接写整篇综述”可靠得多。我第一次犯的错就是让它“直接写一篇 8000 字综述”结果它写得倒是挺顺但文献引用混杂、论证逻辑跳跃通篇看起来像那么回事仔细一读全是虚空建设。后来我改成让 WorkBuddy 为每篇入选论文生成一张摘要卡片内容包括研究问题、方法、主要结果、局限我基于这些卡片手动搭综述框架让 WorkBuddy 按框架把相关卡片组合成段落再补上引用的衔接句。这样综述的质量由我的框架兜底它的优势“快速精读大量 PDF”也发挥出来了效率至少翻了一倍。它不会取代我判断哪些文献重要但它帮我省掉了最耗时的“读几十篇论文并提取要点”环节。6.3 客服负责人的视角快速把知识库变成工作台如果你是个客服负责人刚听说 WorkBuddy 想快点用起来我的建议是别一上来就让它在真实对话里回复客户。系统不成熟时冒充专家去接待客户砸的是你的口碑。第二十七个技巧先导入标准 FAQ、历史工单、话术模板再让它开始产出。我在帮一个朋友搭客服工作台时做了三步把公司现有的 FAQ、产品手册、历史工单整理成一个知识库目录配置一个 customer-service-kb Skill让它只基于知识库内容回答在输出规则里明确写“知识库找不到答案时回复‘需要转人工’不要自行编造。”三天时间搭出来的东西已经可以当新人培训机器人用把新人回答客户的口径统一问题解决了大半。第二十八个技巧是配套的用任务拆解 Skill 持续生成知识库补充清单。每天让 WorkBuddy 把遇到的高频客户问题分类整理输出一份“待补充知识库清单”然后你抽空补内容进去知识库就会滚动增长而不是一开始做完了就丢在角落里吃灰。6.4 多任务并行别贪多我最后想提醒的是WorkBuddy 能多任务并行但这不代表你应该让任务疯狂并行。有一阵我贪快一次挂五个任务让它同时跑结果出现了非常尴尬的局面——它把一个项目的文件路径用到了另一个项目里任务 A 的中间结果被任务 B 的上下文覆盖我花了一整天收拾残局。第二十九个技巧因此很朴素同一时间最多挂 2-3 个任务高复杂度任务保持单线程。更具体一点低复杂度杂事查一个 API 用法、格式化一份文档可以排队高复杂度任务重构模块、生成整套测试、写综述初稿一次只跑一个不同项目的任务坚决分到不同会话窗口避免上下文互相污染。三个月里我做出的最大优化不是调它的参数而是控制并发。给它的上下文保持干净它的输出质量会稳定很多。7. 30 个技巧速查表从“能用”到“敢把活儿交给它”前六章已经把这些技巧拆开讲完了但我知道看长文的人最容易忘记前面讲了什么。所以放一份完整速查表按主题分组方便你收藏之后一条条对照执行。7.1 定位与信任建设技巧 1-4编号技巧一句话说明1把它当“可培训的实习生”不是搜索引擎需要你喂上下文和边界2先建独立测试项目用隔离环境试错降低风险3前两周只跑孤立任务写入单测、文档这类不伤核心的活4每次任务先写“完成定义”完成标准、输出格式、验收条件都要写清7.2 环境与部署技巧 5-8编号技巧一句话说明5安装后迁移系统缓存目录避免默认盘被索引和历史记录挤爆6官方渠道、稳定正式版优先预发布版的配置格式容易变动7Docker 部署挂载持久化目录防止容器重建丢 Skill 和配置8老环境先做最小验证Win7 等旧系统先跑通最小示例再上活7.3 规则与指令技巧 9-12编号技巧一句话说明9写全局规则语言、风格、禁忌都放进全局设置10用项目级规则覆盖全局每个项目的特例放到项目根目录11多写“禁止事项”比“认真负责”这类希望更管用12报错贴完整上下文保留中间输出别只贴失败结论7.4 Skill 体系技巧 13-18编号技巧一句话说明13高频操作封装成 Skill别再反复改提示词14先官方后第三方第三方 Skill 要检查权限描述15写清触发词和边界防止 Skill 跑偏16多 Skill 指定执行顺序避免输出格式混乱17定期复盘、持续淘汰两周没用或总被纠正的 Skill 就换掉18输入不足时先反问防止它在信息缺失时瞎猜7.5 安全与验证技巧 19-23编号技巧一句话说明19文件写入先开确认模式先出 diff 再落地20命令执行设白名单和目录只允许必要的命令21每次修改附变更说明文件清单、原因、影响范围22先看结构再看细节用结论摘要引导验证23关键改动保留 diff 备份随时能回滚7.6 场景实践与长期运营技巧 24-30编号技巧一句话说明24与 Cursor 等工具分工工作台负责多步骤重复劳动25文献综述先定纳入/排除标准先对齐评价体系再整理资料26文献综述用摘要卡片法先生成卡片再搭框架组合27客服场景先导入知识库严格按库中口径回答28用任务拆解持续补充知识库每天生成高频问题清单滚动迭代29同一时间最多 2-3 个任务高复杂度任务保持单线程30允许它说“不确定”每周复盘给它诚实边界也给自己纠错机会这三十条不是一次性全都用上才有效。我自己也是从第 1、4、5、9 条开始慢慢把规则和 Skill 建起来的。你可以先挑最扎眼的几条用起来再逐步铺开。8. 我最想提醒的三件事信任不是一次建成的8.1 每周花十分钟复盘它的“坏习惯”技巧 30 值得再展开一点。所谓“敢把活儿交给它”不是某一天突然下定的决心而是每周复盘的累积结果。我每周五会花大概十分钟把这一周里 WorkBuddy 做错的、让我返工的事列出来。不是骂它而是把这些错误填回规则和 Skill 的边界里去。举个例子它曾连续三次把“删除测试文件里的临时变量”理解成“删除整个测试文件”原因就是我当时的规则里写的是“清理测试文件中的临时内容”而不是“不要删除测试文件”。复盘之后我把这条规则改成了更明确的禁止项之后再也没有出现过同类错误。这种错误模式会不断变化所以每周固定一个复盘时间很有必要。当你发现连续几周都没有新的坏习惯冒出来你对它的信任才是真正建立起来了。8.2 最后一道检查永远是人的检查再强调一遍上述技巧没有一条是让你完全放手。我敢把活儿交给 WorkBuddy正是因为我保留了最后一道人工检查。检查的顺序就三条先看结构再看关键数据最后看细节。它生成过一个看起来没问题的 docker-compose 配置端口映射、卷挂载都正确但漏了restart: unless-stopped。这个漏掉的结果是某次容器意外退出后没有自动恢复好在是个测试环境。但这个例子说明了它产出的东西可能“看起来很完整”而人的眼睛就是来抓那些“看起来对但不完整”的部分。日常里我会把 WorkBuddy 的输出当同事的产出看待我可以快速给意见、让它返工但最终签字确认的人是我。检查不是不信任而是成熟的协作方式之一。8.3 我现在的状态三个月下来WorkBuddy 在我这儿早就不是“能用的玩具”了。它管着代码评审预检、测试生成、文档维护、文献卡片整理还有一部分客服知识库的日常运营。我发现最有价值的不是它帮我省了多少小时而是它把那些重复劳动压得足够实让我能腾出精力去处理真正需要人判断的事。如果你也想把它变成“敢把活儿交给它”的成员我的答案就一句话先给自己定一套规则和验证流程让它在边界内跑跑错了也不慌然后慢慢扩大它的地盘。信任是一点点试出来的不是某个参数一调就能获得的。最后分享一个我最近形成的习惯每周一我会把本周想交给它的任务清单先写出来标注每个任务的“完成定义”和“验收方式”然后才把任务分配给它。这个习惯看起来有点死板但它让我和 WorkBuddy 之间的协作越来越顺。工具在变熟其实人也在变熟——你用它的方式决定了它能走到哪一步。