三个月前我把 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 用最小模板名、描述、输入、步骤、输出降低上手门槛14Skill 描述写具体触发才准提高调用命中率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 目录起一个能看懂的名字重启会话就能用。等跑熟了再往里面加“特殊情况处理”“质量检查清单”这些高级内容不用一次到位。技巧 14Skill 描述写得越具体触发越准。很多人建了 Skill 但运行时没被调用多半是 description 写得太泛。“处理日志”和“输入 nginx error.log提取时间、级别、请求路径按时间排序输出表格”后者的触发成功率要高得多。把触发条件、输入格式、限定范围都写进 descriptionWorkBuddy 的判断就会准很多。技巧 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多步骤任务、规则驱动、批量文件处理编辑器内联体验一般适合当成“任务助理”来用CursorIDE 内联写代码、改代码完成任务闭环弱一些写代码的主战场可以选它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 写第一条规则开始。我自己的体会是规则先行的价值远大于换个贵价模型。