三个月前，我把 WorkBuddy 装进工作流，那时它在我的认知里就是个“高级一点的问答工具”，能解释代码、能查资料、能润色文字，但离“把活儿交给它”还差着十万八千里。真正让我改观的不是某个版本更新，而是自己在三个月里踩出来的 30 条实战技巧。从最开始的“能用”，到现在的“敢把跨文件夹的批量处理、周报汇总、甚至文献综述初稿都交给它”，中间隔着的不是信任玄学，而是一套明确的规则、几个好用的 Skill 和一份固定下来的验收标准。
这篇文章我打算写给三种人：正在用 WorkBuddy 但总觉得“差点意思”的你；在 WorkBuddy、Trae、Cursor 之间反复横跳的选型困难户；以及想把 AI 工作台引进团队、又怕失控的负责人。我会把三个月里沉淀下来的 30 条技巧按使用顺序拆开讲，每条都带具体场景和操作细节，你可以直接照着抄。
1. 三个月时间，我是怎么把 WorkBuddy 从“能聊”养成“能干活”的
1.1 从“能用”到“敢把活儿交给它”，差的是哪几步
第一周，我把它当高级检索工具用：丢一段代码让它解释，丢一篇文档让它总结。它完成得不错，但也仅此而已。第二周我开始尝试小任务——整理一个文件夹里的文件名、把散落的笔记合并成一篇纪要。这些任务我是全程盯着的，哪怕它只是稍微改动了一下文件结构，我心里都会咯噔一下。第三周发生了一件小事：我让它把一份几百行工单数据按问题类型归类，它不但分好了类，还在输出末尾附了一句“原始数据未改动，全部结果写在 result/ 目录”。那一刻我意识到，安全感不是来自“它是大模型所以可信”，而是来自它遵守了我定的规则。
从那天起，我把三个月用下来的技巧归纳成一句话：先让它学会守规矩，再让它去干大事。这个“规矩”分两层，一层写在规则文件里，另一层通过 Skill 和操作流程固化下来。整篇文章没有魔法，每一步都可以复现：建目录、写规则、做 Skill、设验收标准，仅此而已。
1.2 我对“靠谱交付”的定义，以及 30 条技巧速查表
很多人说“AI 不靠谱”，我后来复盘发现，大部分“不靠谱”其实是验收标准没定清楚。我现在对 WorkBuddy 的交付只问四个问题：它有没有在任务范围内操作？每一步有没有留下痕迹？结果能不能复现？有没有把假设和没做完的事写出来？四条全满足，我就认这个结果。
下面先把 30 条技巧的整体框架列出来，方便你收藏。后面章节会按“搭环境—建 Skill—跑场景—查问题—做迭代”的顺序逐条拆解。
| 编号 | 技巧 | 解决什么问题 |
|---|---|---|
| 1 | 模型档位按任务切换，别全程顶配 | 成本和响应速度失控 |
| 2 | 工作目录固定到项目根 | 避免它满盘乱翻 |
| 3 | 第一条规则先写“禁区” | 防止误改关键文件 |
| 4 | 一个任务一个会话 | 防止上下文串扰 |
| 5 | 上下文快满就开新会话，先读 MEMO | 防止长任务失忆 |
| 6 | 长期规矩写进用户级全局规则 | 所有对话统一生效 |
| 7 | 项目规则写明目标、禁区、交付格式 | 让单项目有专属约束 |
| 8 | 系统缓存目录挪到独立磁盘 | 防止系统盘爆掉 |
| 9 | 临时目录加自动清理规则 | 防止垃圾文件堆积 |
| 10 | 升级前先备份配置目录 | 防止配置丢失 |
| 11 | 重复三次以上的操作沉淀成 Skill | 把经验固化成能力 |
| 12 | 优先做四类 Skill：审代码、查日志、结构化、测用例 | 覆盖多数高价值场景 |
| 13 | 创建 Skill 用最小模板：名、描述、输入、步骤、输出 | 降低上手门槛 |
| 14 | Skill 描述写具体，触发才准 | 提高调用命中率 |
| 15 | 每月清理一次 Skill | 防止技能仓库腐化 |
| 16 | 大任务先出执行计划，确认再跑 | 防止跑偏返工 |
| 17 | 用检查点实现断点续跑 | 长任务不怕中断 |
| 18 | 任务结束必须有完成清单 | 防止“做了但没做完” |
| 19 | 危险操作一律二次确认 | 防止误删误改 |
| 20 | 开运行日志，全程留痕 | 出事能回溯每一步 |
| 21 | 敏感文件单独目录并加禁读规则 | 守住安全边界 |
| 22 | 中间结果写缓存复用 | 长任务不重复计算 |
| 23 | 客服负责人先做问题分类，再做 Skill | 让团队快速复用知识 |
| 24 | 文献综述按四段式分段生成 | 控制上下文和引用质量 |
| 25 | 规则和 Skill 纳入版本管理 | 团队一致迭代 |
| 26 | 配置“质检员”角色先自审 | 给交付质量兜底 |
| 27 | 选型对比重点看任务闭环能力 | 避免被单点功能迷惑 |
| 28 | 多人共享环境优先考虑容器化部署 | 统一版本和环境 |
| 29 | 外部依赖重、需要判断的任务留人工节点 | 控制风险 |
| 30 | 每周复盘失败对话，补规则缺口 | 让工具越用越懂你 |
这张表正好 30 条，接下来的内容就是围绕它展开的。
2. 搭建工作台：10 条配置与规则技巧，先把地基打稳
2.1 模型档位、固定工作目录和缓存路径（技巧 1、2、8、9）
技巧 1：模型档位按任务类型切换，别全程顶着满血版。我一开始习惯把所有任务都丢给性能最强的模型档位，结果等一个简单的日志分析都要两分钟。后来我定了条规则：简单问答、格式转换、文档总结用标准档；代码生成、多文件改造、复杂数据分析才切到高性能档。用生活里的类比，买菜开皮卡就够，没必要把跑车开出来。实测下来，日常平均响应时间降了一半，成本也好看很多。
技巧 2：把工作目录固定到项目根。WorkBuddy 默认的工作路径往往是你当前的目录，这对零散聊天没问题，但一旦跑批量任务就危险了——它可能顺手在你的用户目录下创建一堆文件。我的做法是把work_dir固定到项目根目录，并在白名单里写明允许访问的目录：
work_dir: D:\projects\workbuddy-work allowed_dirs: - D:\projects\workbuddy-work这样它所有读写都被圈在项目范围内，就算执行过程跑偏，也不会祸害到别的目录。如果只设work_dir而不设allowed_dirs，很多 Skill 在运行时还是会到用户目录下找配置文件，白名单的作用就是把这条路彻底堵死。
技巧 8：把系统缓存目录挪到空间充足的磁盘。用着用着你会发现，模型下载、运行日志、中间结果都在悄悄吃磁盘。默认缓存往往放在用户主目录，日积月累系统盘就告急。我做完首次配置后的第一件事，就是找到配置文件里的cache_dir字段，把它改到数据盘的独立目录：
cache_dir: D:\workbuddy-cache改完以后，把旧的缓存文件夹整体搬过去，再重启所有会话。这个动作能一次性解决两个问题：系统盘被写爆，以及重装系统时缓存被清空导致第一次跑任务又慢又卡。
技巧 9：给临时目录加一条自动清理规则。缓存搬完不代表万事大吉。WorkBuddy 跑任务会产生大量临时文件，尤其是反复解析文档、生成中间结果的时候。我在全局规则里加了一条“临时目录中超过 7 天的文件自动清理，但不得进入项目文件目录”，它每次会话开始时会自动执行一次清理策略。这条规则比手动删文件强太多，因为我总记不住那些临时目录到底散落在哪里。
2.2 全局规则、项目规则和禁区（技巧 3、6、7、10）
技巧 6：把长期要用的规矩写进用户级全局规则。全局规则的价值在于“一次写入，所有会话自动生效”。我在用户级规则文件（位置一般在~/.workbuddy/rules.md或user_rules.md）里放了几条基础规则：
- 所有回答使用中文，专业术语保留英文对照。 - 修改任何现有文件之前，先展示将要修改的内容和理由。 - 不在任务要求范围内新增、删除或重命名文件。 - 输出文件必须明确保存路径，不能只丢内容。 - 涉及数据备份时，先备份再操作。这些规则看起来简单，但它们恰好补齐了大模型最容易犯的“自作主张”问题。打个比方，全局规则是在给它立公司制度，制度先于能力。
技巧 7：项目级规则单独放一份，写清目标、禁区、交付格式。全局规则管所有任务，项目规则管特定项目。我在每个项目根目录下建一个.workbuddy/rules.md，内容固定为三块：目标、禁止事项、交付格式。模板长这样：
目标：整理 2025 年 Q1 用户反馈，输出问题清单 禁止事项：不得修改原始工单文件；不得访问 docs 目录以外的资料 交付格式：Markdown 表格，保存到 result/Q1-feedback.md新建项目第一天先把这份文件写好，后面一整周的活都会顺很多。因为每次从聊天界面下达任务时，WorkBuddy 会同时加载项目规则，把操作限制在框架里。
技巧 3：规则里第一条先写“禁区”。全局规则里的通用约束能防住大部分问题，但真正能救命的还是禁区。我会把原始数据源、密钥文件、合同扫描件这类“碰了就要出事”的路径单独列一个禁止列表，明确写“不得读取、不得修改、不得引用”。有一次我让它整理客户数据，它就因为规则里缺少这一条，差点把源文件改掉。从那以后，我永远把禁区写在规则最前面，而不是藏在文件末尾。
技巧 10：升级之前先备份配置目录。WorkBuddy 迭代很快，升级本身没什么风险，但规则文件、Skill、自定义配置都是我们自己攒出来的资产。我每次升级前会把~/.workbuddy/整个目录复制一份，命名带上日期；升级完跑一遍“读规则、触发 Skill、执行简单任务”的冒烟测试，确认没问题才把旧备份清掉。这一步花十分钟，能少掉很多次“配置怎么没了”的折腾。
2.3 会话管理：一个任务一个会话，上下文别贪杯（技巧 4、5）
技巧 4：一个任务一个会话。我见过很多人把聊天窗口当成记事本，早上聊需求、下午写代码、晚上让它写周报，全程都在同一个会话里。结果就是上下文互相污染——它写着写着把下午的需求带进了晚上的周报。我的习惯是每开一个任务就新建一个会话，会话名用“日期+任务名”命名，比如“0421-日志分析”。这个简单动作，让定位问题、翻历史记录、复用上下文都变得极其轻松。
技巧 5：上下文快满时，把结论写进 MEMO 再开新会话。上下文不是无限的，长任务跑到后面，它很容易忘掉开头的要求。我现在的做法是：遇到比较长的任务（比如处理几十个文件、写一份长文档），先在项目根目录维护一份MEMO.md，里面记录任务目标、已完成步骤、下一步计划、关键结论。然后配一条规则，要求每个会话一开始先读 MEMO，任务推进时同步更新。这样即使上下文被切断，新会话也能无缝接上，不会从头再来。
3. Skill 与 Agent 实操：12 条技巧让复杂任务自动跑完
3.1 Skill 是把经验固化下来的最好方式（技巧 11、12、13、14、15）
技巧 11：重复超过三次的操作，就沉淀成 Skill。连续三周做同一件事之后，我彻底理解了为什么要搞 Skill。那件事本身不复杂，但每次都要重新描述一遍“把聊天记录里的问题提取出来、按模块分类、标注负责人和优先级、输出成表格”。做到第三周，我花二十分钟把它写成一个 Skill，之后每次只要丢进聊天记录文件，它就能跑出一张合格表格。判断标准很简单：同一件事手动重复第三次，就值得做 Skill。
技巧 12：优先做这四类 Skill。如果你不知道从哪儿开始，我建议先做下面四类，它们几乎覆盖了多数办公和技术场景：
- 代码审查：输入变更文件，输出问题清单、风险级别、修改建议。
- 日志排查：输入日志文件，按时间线输出异常点、错误码、可能原因。
- 文档结构化：把杂乱文字整理成标题、列表、表格和摘要。
- 测试生成：根据函数签名或接口文档，生成含边界条件的用例。
这四类 Skill 的共同点是输入输出都很明确，天然适合让 Agent 批量执行，而不是你来来回回给提示词。
技巧 13：创建 Skill 用最小模板。不需要一开始就追求复杂，Skill 本质是纯文本规则。最小模板五段就够了：
name: 技能名称 description: 一句话说明用途和触发条件 input: 需要外部提供什么 steps: 1. 读取输入 2. 按规则处理 3. 生成输出 output: 输出格式和保存路径按这个模板把内容填完，保存到 Skill 目录，起一个能看懂的名字，重启会话就能用。等跑熟了，再往里面加“特殊情况处理”“质量检查清单”这些高级内容，不用一次到位。
技巧 14：Skill 描述写得越具体，触发越准。很多人建了 Skill 但运行时没被调用，多半是 description 写得太泛。“处理日志”和“输入 nginx error.log，提取时间、级别、请求路径，按时间排序输出表格”，后者的触发成功率要高得多。把触发条件、输入格式、限定范围都写进 description，WorkBuddy 的判断就会准很多。
技巧 15：每月清理一次 Skill。Skill 会越攒越多，我三个月攒了二十多个，真正高频使用的不到一半。现在每月底会看一眼使用记录：连续三十天零调用的先归档，高频使用的继续迭代描述和步骤。清理不是单纯删除，而是把不再用的 Skill 移到 archive 目录，留着以后参考，避免仓库里全是僵尸技能。
3.2 给 Agent 定执行纪律：计划、检查点与二次确认（技巧 16、17、18、19）
技巧 16：大任务先让它输出执行计划，确认后再执行。Agent 会自己往前走，但也正因为这样，方向错了它还会继续错。我现在下大任务时会在提示词里加一句：
先给出不超过 500 字的执行计划，包含步骤、涉及文件、预计产出物，等我确认后再开始执行。人的确认只需要十几秒，但它跑偏后再拉回来可能要半小时。这条规矩帮我节约了大量返工时间，尤其是那种涉及十几个文件的任务。
技巧 17：用检查点实现断点续跑。长任务最怕中断。WorkBuddy 跑一个几十页文档的整理时，中途断掉的话，从头再来的成本非常高。我的做法是让它在规则层面维护一个progress.md：每完成一个重要阶段，就往里面写一条“已完成 X、下一步要做 Y、当前状态 Z”。任务中断后，新会话先读 progress.md 再继续。这个思路和代码里的断点续传一模一样，只是没有按钮，要靠规则来约定。
技巧 18：任务结束必须有完成清单。没有终态约定的 Agent 会说“做完了”，然后真的只给你一句“做完了”。我现在要求的交付物固定包含三部分：完成了什么、哪些没做、有哪些假设。比如整理完文件后的输出是：
- 已完成：12 个文件的标题规范化 - 未完成：3 个文件因格式不标准无法处理 - 假设：文件名里的日期统一按 YYYY-MM-DD 处理这个习惯让“交付”变成了“可验收”，而不是一个模糊的“它搞定了”。
技巧 19：危险操作一律二次确认。批量重命名、覆盖文件、删除文件，这些操作我会在规则里明确要求“先展示操作清单，等待确认”。真实原因是第三周我吃过一次亏：让它批量重命名一批照片，正则表达式写偏了，一部分文件名被改得面目全非。如果当时有二次确认，我在确认界面就能看到那些奇怪的新文件名，就不会发生这种事。
3.3 日志、敏感数据和缓存复用（技巧 20、21、22）
技巧 20：开运行日志，出事能回溯。我一开始认为日志只有程序员才需要，后来发现它对普通人也特别有用。每次会话都会把执行步骤、文件操作、报错信息写入运行日志，位置一般在配置目录下的 log 文件夹。遇到异常结果，把日志按时间段筛出来，就能看到它每一步做了什么。这个功能就是“验收证据”，也是我敢把重要任务交给它的底气来源。
技巧 21：敏感文件单独放，加禁读规则。涉及合同、工资表、个人信息的文件，我的习惯是放在项目里一个叫sensitive/的目录，并在规则中写“此目录默认禁止访问”。如果某个任务确实需要读取其中一个文件，我会在提示词里临时授权一次，任务结束后立刻把权限收回去。这个动作多花十秒，但能避免很多不必要的风险。规则模板可以这样写：
禁止访问目录：sensitive/ 例外：当用户在任务中明确指定 reading 单个文件时，仅授权该文件。技巧 22：中间结果写缓存，长任务不重复算。处理大量 PDF、解析大量表格时，第一次解析结果会让它写到缓存目录，之后同类任务直接复用，而不是重新跑一遍。需要注意缓存要有失效条件：源文件一旦变化，旧缓存就不能再用了。我通常在缓存文件里附带源文件的哈希值来判断，这个做法让原本要跑几分钟的批量任务缩短到几十秒。
4. 场景实战：客服负责人、文献综述、团队共享怎么用
4.1 客服负责人三天上手：先把问题分类，再做成 Skill（技巧 23）
有客服负责人问我怎么快速用起来，我给的方案不是让客服和 WorkBuddy 一对一聊天，而是先做一次“知识整理”。具体分三步走：第一步，把过去三个月的工单导出来，让 WorkBuddy 按问题类型聚类，类似“退款流程、物流查询、产品使用、投诉升级”这四类；第二步，为每个高频类型做一个 Skill，输入是“客户原话”，输出是“标准回复+引用文档位置”；第三步，让客服在实际回复时先看 WorkBuddy 给出的候选答案，人工确认后再发送。
这套流程跑顺之后，普通客服处理常规问题的响应速度会明显提升。但我也会强调：涉及退款金额、情绪化投诉、特殊个案，依然要人工判断，不能全自动。最值钱的不是“写回话”本身，而是把团队积累的知识结构化、沉淀为可复用的资产。
4.2 拿 WorkBuddy 写文献综述：四段式分段推进（技巧 24）
最近我用它写文献综述，方法可以给你们参考。核心是不要把“写综述”直接丢给它，而是拆成四段：提出问题、分类整理、对比分析、结论建议。每一段都单独开会话，先让它根据特定问题检索和整理文献，生成初稿后再由我逐段核对。这样做的原因有两个：一是上下文不会因为一次塞太多资料而过载；二是每一段都能控制质量。
需要特别注意：综述里的引用信息一定要人工核对原文页码和期刊名，别盲信它给出的引用条目，尤其是年代和卷号容易出错。四段式的本质是把大任务拆成四个小任务，和前面技巧 16 是同一个逻辑——让 Agent 分步交付，而不是一把梭哈。
4.3 团队共享与部署选择：版本管理、容器化、选型对比（技巧 25、27、28、29）
技巧 25：把规则和 Skill 纳入版本管理。一个人用 WorkBuddy，规则写在本地就够了；团队如果要统一，我会建议把~/.workbuddy/里的 rules、skills 配置放进一个 Git 仓库，团队成员各自同步。这样每一次规则更新都有记录，哪条规则让交付质量下降也能回滚。团队里比较顺的做法是：常用规则由一个人维护，其他人提建议，每周合并一次。
技巧 28：多人共享环境优先考虑容器化部署。如果想让小组共用同一套版本和配置，各装各的客户端会很痛苦。这时候可以考虑用官方容器镜像部署一个共享服务，把模型访问、缓存目录、规则库都放进容器里，团队成员通过客户端连接同一个服务。好处是版本一致、缓存共享、配置统一管理，代价是需要有人维护一台机器。适合三五人以上、任务类型固定的团队。
技巧 27：选型对比重点看“任务闭环能力”。我也经常被问 WorkBuddy、Trae、Cursor 哪个好。实话实说，这几个工具不是一个思路。Cursor 强在编辑器内联体验，写代码时改起来舒服；Trae 类似地偏向 IDE 交互；WorkBuddy 更像一个能跑的“任务助理”，强调多步骤任务的计划、执行、日志和结果归档。所以选型不是看谁的功能列表长，而是看你交给它的活儿是不是“需要跑好几个步骤、要产出文件”的类型。要写代码，Cursor 这类可能更顺手；要跑批量任务、沉淀流程，WorkBuddy 的闭环能力更有价值。
技巧 29：外部依赖重、需要人工判断的任务，保留人工节点。我给自己定了三条筛选原则：任务是否依赖实时外部系统（比如调接口查库存）？是否涉及账号或支付操作？结果是否需要主观决策？只要满足其中任意一条，我就会在流程里留一个人工节点，让 WorkBuddy 先把候选结果列好，由人做最后判断。这不是不信任它，而是风险控制的基本常识。
5. 三个月翻车实录：这些问题我也踩过
5.1 它“自由发挥”，责任其实在我
三个月里最让我印象深刻的一次翻车，是让它整理整个文件夹的文档，它没征求同意就开始动手，把几个不在任务范围内的文件也给整理了。我当时很生气，后来冷静下来看日志才发现：它把“整理文件夹”理解成了“整理文件夹里所有文档”，而我的规则里刚好没写“只处理任务中明确列出的文件”。修复办法是补一条规则：
任务范围外的文件一律只读；需要修改必须单独确认。从那以后，“自由发挥”的次数降到几乎为零。这件事让我明白，Agent 的“自由发挥”背后，往往不是模型笨，而是规则地图里有一块空白。
5.2 Skill 不触发和配置不生效的排查顺序
这套排查顺序我反复用过，能解决 80% 的“它怎么不听话”问题。核心思路就是：先看规则有没有被加载，再看触发条件有没有对上，最后看配置是不是旧的。
| 现象 | 排查思路 |
|---|---|
| Skill 没被触发 | 检查 description 里有没有明确输入格式；确认会话里是否提到 Skill 名；重启会话后再试 |
| 新规则不生效 | 确认规则文件路径正确；确认文件编码不是带 BOM 的 UTF-8；新开一个会话让它重新加载 |
| 缓存目录改了没用 | 检查是否重启全部会话；旧缓存是否还在占用空间；确认配置文件指向的是同一个目录 |
| 规则互相冲突 | 项目规则优先级高于全局规则；查项目.workbuddy/rules.md是否覆盖了全局内容 |
5.3 横向对比后的选型结论，别照抄但要参考
下面这个对比是我三个工具都实际跑过一轮后的感觉，不是参数表罗列。
| 工具 | 最擅长的场景 | 相对短板 | 使用建议 |
|---|---|---|---|
| WorkBuddy | 多步骤任务、规则驱动、批量文件处理 | 编辑器内联体验一般 | 适合当成“任务助理”来用 |
| Cursor | IDE 内联写代码、改代码 | 完成任务闭环弱一些 | 写代码的主战场可以选它 |
| Trae | 界面简单、快速上手 | 长任务和流程沉淀较弱 | 轻量试用可以 |
选型不要迷信“哪个更强”，要问自己：我最多的活儿是哪种形态？如果你一周有八个小时花在整理文件、汇总数据、生成报告上，那 WorkBuddy 的规则和 Skill 体系会帮到你；如果你整天泡在代码编辑器里，那另外两个更合适。
6. 越用越懂你：自审机制与持续迭代
6.1 配置一个“质检员”角色，让每份交付先过自己这关（技巧 26）
技巧 26 的核心是让 WorkBuddy 每份交付前都过一遍质量检查清单。我在全局规则里加了一段：
输出之前，按以下清单自查： 1. 是否完整覆盖任务要求？ 2. 输出格式是否符合交付格式？ 3. 有无未说明的假设？ 4. 有无敏感信息混入？ 5. 文件保存路径是否明确？刚开始我会嫌它多此一举，但两周后我发现交付物里漏项、格式错乱的问题明显变少。你甚至可以给它指定一个“质检员”角色，让它在交付前用另一个视角重新审视自己的输出。这比直接让它在一次生成中力求完美更可靠。
6.2 每周复盘失败对话，把规则缺口补进去（技巧 30）
技巧 30 是我认为最容易被忽略的一条。每周五我会花二十分钟翻一遍这一周里 WorkBuddy 做得不对的对话，找到规则缺口，然后更新全局规则。举个例子：它有段时间经常不保存输出文件，只在对话框里给结果。复盘后发现我的规则里确实没有要求“必须写明输出路径”，于是补上约定。现在它每份交付都会写清楚文件保存位置。这一个动作，让我和它之间的配合越来越顺。
6.3 三个月后我自己的一天是怎么用的
最后说说我现在每天的用法。接到一个新任务，先花五分钟建规则文件和 MEMO，把任务拆成三步，每步设定明确的验收标准，然后才让 WorkBuddy 上场。它负责执行，我负责验收。这个流程听起来传统，但在 AI 工具身上反而最管用。如果你也正在经历“它能用，但我不敢把活儿交给它”的阶段，我建议你先别急着换更强的模型，从给 WorkBuddy 写第一条规则开始。我自己的体会是：规则先行的价值，远大于换个贵价模型。
