我现在日常开发里最烦的不是写复杂逻辑而是那些重复的“小事情”改十几处日志格式、补接口文档、把A环境的配置复制到B环境再改几个字段。这些事不复杂但很占时间。后来我把WorkBuddy搭成了自己的AI工作台把这类流程逐步自动化才真正体会到什么叫“让AI干AI该干的活”。这篇内容不是官方手册而是我从零开始搭建WorkBuddy并把它用于流程自动化和多场景应用的一份实践记录。我会尽量把每一处配置和操作背后的原因讲清楚适合正在用AI编程助手、但还想更进一步把重复工作交给AI的开发者参考。1. 为什么我要搭一个WorkBuddy AI工作台1.1 聊天式AI和AI工作台的差距在哪里很多人习惯在浏览器里打开AI对话窗口写代码、问问题我也这么干过但很快发现一个很实际的瓶颈AI不知道你项目里到底有什么。你发一段代码过去它帮你改改完你再粘回编辑器来回几次上下文就乱了。更麻烦的是当问题牵扯到多个文件时你得把每个文件内容都贴进去AI才能“看见”全貌。这个过程中大量的时间其实不是花在思考而是花在搬运代码和描述项目背景上。WorkBuddy这类AI工作台不一样。它直接挂载在IDE里或者作为一个独立工作台运行能读取项目结构、识别文件依赖、调用项目里的工具链。同样是“把所有Controller里的接口日志统一加上耗时统计”这种跨文件任务聊天式AI需要你先解释项目结构、再逐个粘贴文件而工作台可以直接在项目范围内搜索、分析、修改。用一句话总结普通AI聊天窗口是客服你问一句它答一句WorkBuddy更像一个知道仓库全貌的实习生你把任务说清楚它自己知道该翻哪些文件、改哪些地方。我搭工作台的第一感受就是原来AI可以不用“唠嗑”式工作。它能够以项目为单位执行任务而不是以对话气泡为单位回答问题。对于手头有几十个文件的真实项目来说这个区别是决定性的。刚开始你会觉得“不就是换个入口嘛”但实际用一周之后你会发现自己越来越不想回到那种需要反复复制粘贴的对话框里。1.2 流水线思维从“问答”到“自动化”真正让我决定深入研究WorkBuddy的原因不是它单次回答多聪明而是它允许我把日常开发变成一条流水线。我举一个很常见的例子每周要写项目周报。以前我要翻git log、看完成的功能、整理遗留问题再组织语言。现在我把这个流程拆成三步读取本周git提交记录、按模块分类汇总、生成一份符合固定格式的周报。三步全部由WorkBuddy执行我只需要最后检查一遍数字和措辞。这就是流程自动化的起点。要做到这种自动化不能靠每个对话临时发挥而要把规则、指令和技能固化下来。WorkBuddy支持全局规则和项目级配置支持自定义指令还可以把多步骤任务封装成可复用的Skill。后面我会具体讲这三层怎么设计。这里先强调一个观念把AI工作台当成你的“流程底座”而不是“问答玩具”。你投入在规则和技能上的时间会在后续每一次重复劳动里赚回来。我自己的经验是先挑一件每周都要做、规则又相对固定的任务来尝试自动化比一开始就让它做一个大项目要稳妥得多。2. 安装与初始化先让工作台在电脑上跑起来2.1 安装方式和模型配置WorkBuddy的使用方式大致分两种IDE插件和独立客户端。我自己是两种都装IDE插件负责写代码、做重构、跑测试独立客户端负责处理文档、表格这类非代码任务偶尔也用来在不开IDE的时候快速问问题。安装过程不算难Windows有安装包macOS有dmgLinux下我有两个选择一个带图形界面的deb或tar.gz包一个纯命令行工具。如果你主要在远程服务器上跑可以考虑命令行版本资源占用更少也更容易嵌入到自动化脚本里。首次启动后会进入登录和模型配置环节。这里我建议认真做两件事先把默认模型配置好再配一个备用模型接口。很多人在这一步只填了一个默认模型结果遇到模型服务繁忙或网络波动时整个工作台直接没法用。我的习惯是在配置里同时指定两个模型来源并把优先级设为自动切换。还要特别提醒一点如果你的代码涉及企业内部数据或生产环境尽量使用私有化部署或企业版模型接口。公共模型通常会把对话内容用于服务改进虽然方便但对数据敏感的团队来说存在合规风险。这个问题宁可提前想清楚别等出了事再补救。2.2 系统缓存目录为什么我建议改到D盘WorkBuddy在运行过程中会在用户目录下建立缓存目录存放索引、会话记录、模型调度数据和日志。这个目录默认在系统盘用一段时间后体积会非常可观。我第一次遇到这个问题是在连续高强度使用两周之后C盘突然少了将近8GB一开始还怀疑是系统更新残留后来查来查去才发现是WorkBuddy的缓存。解决方式很简单把缓存目录迁移到非系统盘。以Windows为例我通过新增环境变量WORKBUDDY_CACHE_HOME把缓存路径改到了D:\workbuddy_cache。Linux和macOS用户则可以在配置文件中指定缓存路径或者在启动命令里通过参数传入。改完配置后重启工作台旧缓存可以复制过去也可以让它自己重新生成。我的建议是从第一天安装完就把这个路径改掉不要等系统盘飘红再折腾。另外缓存目录里会保存一定数量的会话快照如果你对隐私有要求还应该定期清理历史快照只保留需要留档的项目记录。2.3 项目级初始配置WorkBuddy除了全局设置还支持为每个项目单独定义配置。我习惯在项目根目录下创建一个隐藏配置目录名字是.workbuddy里面主要放三类文件rules.md放项目规则skills/放技能定义context.md放项目说明文档。有人可能会问为什么不全放在全局配置里原因是不同项目的技术栈和约定差异很大。全局规则适合管个人风格比如“回答先结论后原因”项目规则则要管这个仓库自己的规矩比如“Controller层必须返回统一响应体”“新模块必须放在features目录下”。把这两层分开工作台才能做到“见人说人话见鬼说鬼话”。配置目录创建好之后WorkBuddy在打开项目时会自动读取这些文件并把其中的内容作为执行任务的前置背景。这意味着你不用在每个新会话里重新解释一遍项目背景和代码规范。我见过不少同事用AI编程工具效果不稳定很大一部分原因是他们没有把规则文件建起来每个会话都靠即时输入提示词稍微换个说法AI输出就跑偏了。配置文件不是摆设它是保证输出稳定性的地基。2.4 第一次对话前要做的检查清单刚装完工作台先别急着让它写功能、做大重构我建议先跑一遍简单的检查清单。第一确认IDE的文件索引已经建立完整WorkBuddy依赖项目索引来定位文件和识别符号索引没建好后续操作容易找不到目标。第二确认模型接口可用发一句最简单的“你好”看看响应速度再让它读取当前项目的README文件验证项目上下文加载是否正常。第三检查.workbuddy配置目录里的规则文件是否生效可以在提问时故意问一个规则里已经写明的约束看看它能不能按规则回答。第四验证缓存目录迁移是否成功打开设置或者直接看目录生成位置。这套检查做完工作台才算真正进入了可用状态。3. 把规则写进工作台全局规则、自定义指令与Skill设计3.1 全局规则一句话省掉后面一万次重复我见过不少AI编程用户总是在对话里反复强调“代码风格统一”“不要用没引用的依赖”“注释别写废话”。这样的临时强调每次都能起一点作用但换个新会话就失效了等于每次都在重新调教AI。所以我把这些要求全部写进了全局规则文件一次性告诉WorkBuddy回答技术问题先给结论再解释原因。任何代码改动必须说明改动文件列表和影响范围。不要使用项目里没有引入的依赖。提交信息遵循Conventional Commits格式。涉及逻辑变更时同步补充或更新单元测试。这些规则看起来很简单但实际效果非常明显。AI生成的代码风格会逐渐贴近你自己的习惯不会再出现一会儿用单引号一会儿用双引号的混乱局面。规则文件最核心的价值是让AI的输出方差变小。你不会总在“很好用”和“怎么又跑偏”之间反复横跳。如果你还没有建过全局规则我建议现在就打开配置先定三条和自己工作最相关的规则别一口气写几十条否则AI反而不知道该优先遵循哪一条。3.2 自定义指令把常用操作变成“按钮”全局规则解决了风格问题但还不能解决“怎么让AI按固定流程干活”的问题。比如我想让WorkBuddy做一次代码审查如果每次都用自然语言描述审查标准表达难免有偏差。更好的做法是把它定义成一条自定义指令像按钮一样调用。我常用的自定义指令有三条/review审查当前分支未提交的改动按问题严重程度输出清单。/test根据现有改动生成补充测试用例。/docs更新与本次改动相关的文档。自定义指令的写法没有想象中复杂。核心是要写明三件事指令的作用范围、处理步骤、输出格式。以/review为例我的配置内容大致是指令名/review作用范围当前分支未提交的改动处理步骤读取git diff。按优先级列出问题bug风险、安全隐患、性能风险、风格问题。对每个问题给出修改建议并标注对应文件行号。输出格式表格列为文件、问题级别、问题描述、建议。这样配置完之后我随时输入/review它就能执行一套完全可预期的审查流程。这里有个很容易犯的误区自定义指令写得像聊天短语比如“帮我看看代码”AI并不知道“看看”代表什么。你越是把步骤和格式写清楚它执行起来越稳定。自定义指令本质上就是提示词模板模板质量高结果才稳定。3.3 Skill更进一步把流程封装成可复用技能自定义指令适合单次操作但如果你的任务需要多个环节衔接我更建议用Skill来封装。Skill和自定义指令的区别在于它是“多步骤流程”不只是“一句提示词模板”。举个例子我经常需要为前端页面生成基础代码。以前我都是让WorkBuddy直接生成页面但效果不稳定因为它不知道我要先建组件、再补样式、再生成Mock数据、最后注册路由。后来我把这套顺序写成了一个名为new-page的Skill输入项只有两个页面功能描述和数据字段说明。Skill内部定义好执行步骤每一步还附带了验收条件。比如“生成组件后必须检查该组件是否已在路由文件中注册”“Mock数据字段必须与需求文档一致”。这样每次调用产出的质量和流程顺序都是统一的。Skill的设计思路可以理解为把“一个熟练开发者会怎么完成这项任务”翻译成AI可执行的步骤清单。步骤越具体结果越可控。我见过有人把Skill理解成写复杂代码其实不是。Skill本质上是过程管理是让AI照着SOP干活。即使你完全不懂插件开发也能用Markdown描述步骤把它挂在.workbuddy/skills目录下WorkBuddy就能识别。3.4 一套可复用的配置模板说了这么多直接给一份我当前在用的基础配置模板。你不需要照抄但可以参考结构按自己的项目情况调整。# 全局规则示例 - 代码风格遵循项目已有ESLint/EditorConfig不要自行创造风格。 - 命名规范变量用camelCase常量用UPPER_SNAKE_CASE组件用PascalCase。 - 解释要求代码改动必须说明“为什么改”而不是只写“改了什么”。 - 测试要求涉及逻辑变更时同步生成或更新单元测试。 # 自定义指令示例 /review审查当前改动输出问题清单。 /test为当前新增功能生成测试用例。 /docs更新README和API文档。 # Skill示例new-page 输入页面功能描述和数据字段说明。 步骤 1. 创建页面组件文件位置遵循项目目录约定。 2. 生成基础样式使用项目设计变量。 3. 生成接口Mock数据。 4. 更新路由注册。 5. 输出实现说明。这份模板的核心思想是把“人怎么想”和“AI怎么做”对齐。规则管边界指令管单次动作Skill管完整流程。三层嵌套工作台才能从“你说一句它动一下”升级成“你交代一次它把链条走完”。4. 实战拆解三个能直接复用的自动化场景4.1 场景A批量给所有API接口增加耗时日志这个需求来自一个老项目几十个Controller所有对外接口方法都没有统一的耗时日志。排查接口性能时只能靠人工看日志很痛苦。人工修改的话我得打开每个Controller在方法入口记录开始时间在正常返回和异常出口记录结束时间工作量不小而且容易漏改。我把这个任务交给了WorkBuddy。我给它的指令包含几个关键信息目标目录是Controller包识别方式是通过注解和方法签名找到对外接口改动方式是在方法入口记录开始时间在结束时打印接口名、耗时和状态最后输出一份改动的文件清单。实际执行大约用了两分钟改动覆盖了我预期的所有Controller。我没有直接接受结果而是先看了git diff逐一确认没有误伤内部方法。其中有一个方法被它多加了日志我手动撤回其他都没问题。这个场景能成功关键在于任务边界非常清晰。什么文件需要改改成什么样结果怎么验收这些在动手前都定义好了。如果你也想让AI做批量重构建议先把这些边界写清楚尤其是输出改动清单这一点千万不要省。没有清单你连审查都无从下手。4.2 场景B从一句话需求到一个可发布的静态网站有一次要快速做一个活动落地页传统流程是写需求、切图、写HTML、调样式、起本地预览、打包、上传。我压缩成了三个环节让WorkBuddy在项目子目录下生成HTML/CSS/JS三件套加入表单校验和基础动画本地预览确认视觉效果构建静态文件后提交发布。这里有一个很关键的操作细节我没有让WorkBuddy“自由发挥设计”而是先给了它明确的页面区块结构、品牌色变量和文案要点。如果你只丢一句“帮我做个漂亮的落地页”它可能生成一个结构混乱、风格随意的页面。把输入约束好输出才可控。生成后我还让它检查了一次表单必填项校验逻辑和移动端适配。发布到静态托管平台只花了十几分钟。整个过程下来我最深的感受是生成网站本身不是难点难的是用同一套配置就完成生成、校验、发布这三个环节。这正好是AI工作台比单纯AI对话强的地方。4.3 场景C接口测试数据和前端Mock后端接口还没就绪前端又要联调这是团队开发里经常碰到的事。以前我手搓Mock数据既慢又不全尤其容易漏边界值。后来我把这个任务也交给了WorkBuddy前期已经封装过new-page这类Skill这次我只是在对话里要求根据接口字段定义生成完整的Mock数据文件字段类型要符合JSON Schema同时补充正常值、空值、超长字符串和异常枚举。它生成的Mock数据比我手写的完整得多。我把文件挂到本地接口代理工具的配置上前端页面立刻就能联调。等后端真实接口出来后我再让WorkBuddy把Mock数据切换成真实接口返回格式整个过程基本无缝。这个场景说明AI工作台不只能写业务代码还能大大降低联调阶段的重复劳动。前提是你得把接口字段定义给它而不是让它凭空猜。输入越明确Mock数据的可用性越高。4.4 自动化场景的共同特征做完这三个场景之后我总结出能被WorkBuddy稳定自动化的任务都有几个共性第一任务边界清晰明确知道“处理什么范围、不处理什么范围”第二有明确的输入和输出输入可以是一段需求描述输出可以是一份文件、一份清单或一段代码第三结果可以被验证能通过git diff、页面预览、测试运行等方式检查对错第四规则可以复用这次跑通的流程下次同类任务还能套用。反过来如果任务本身模糊比如“把项目完善一下”或者边界一直在变那AI工作台也帮不上忙。所以我现在的习惯是接到一个需求后先花几分钟拆任务、定边界再决定要不要交给WorkBuddy执行。另外有一点始终要牢记合规使用。我只在允许AI访问的代码范围内使用工作台不拿它生成违反项目规范或平台政策的文本、代码。边界清楚工具才值得长期依赖。5. 避坑记录我在WorkBuddy上踩过的几个坑5.1 缓存目录撑爆系统盘这是我在本文前面重点提过的一个坑也是我实际踩得最深的一个坑。最开始我没改缓存目录连续高强度使用两周后C盘少了接近8GB。当时还怀疑是系统更新残留用磁盘分析工具扫了一圈才发现是WorkBuddy的缓存和索引。从那以后我每装一台新机器第一件事就是改缓存目录。这不仅是“给C盘减负”也是为了避免后续索引损坏后的恢复麻烦。独立缓存目录还有一个好处重装系统或换电脑时可以直接把整个缓存目录迁移过去省去重新建立索引的时间。5.2 全局规则和项目规则冲突我在全局里规定“所有文件名使用小写”但某个项目的既有约定是“React组件文件用PascalCase”。一开始我以为是WorkBuddy没遵守规则差点把全局配置删掉。后来我查看了规则加载日志才发现项目级规则优先级高于全局规则组件文件名这类约定确实是按项目规则走的。这个机制本身是合理的因为不同项目有不同的老规矩强制统一反而会破坏现有代码结构。踩过这个坑之后我的建议是遇到规则冲突时先查配置生效顺序再决定怎么调整。如果不希望某些全局规则在特定项目里生效可以在项目配置里使用排除规则而不是把全局规则删掉。掌握优先级之后规则系统反而更灵活了。5.3 AI批量改文件前没备份回滚浪费时间有一次让WorkBuddy批量重构一个模块它连续改了十几个文件我在review时发现其中一个核心文件的逻辑被改错了。因为没有提前建分支我不得不手动重写那个文件的一部分浪费了不少时间。现在我的流程固定下来了让AI批量修改前先确保当前工作区是干净的至少提交一次或者直接新建一个临时分支。修改完成后再统一查看git diff确认没问题再合回主分支。这个过程多花不了两分钟但能让你在AI出错时不至于手忙脚乱。5.4 上下文太长导致效果下降WorkBuddy虽然能在一个会话里记住较长的上下文但并不是越长越好。有一次我在同一个会话里连续聊了项目背景、需求讨论、代码实现方案、部署细节五个话题越到后面它的回答越飘甚至开始重复前面说过的内容。后来我学会了一个很实用的习惯一个会话只做一个明确任务。需要背景信息时我让它去读项目里的文档而不是在对话里反复粘贴旧的结论。这和人工作很相似上下文一旦超过某个阈值注意力一定会被稀释。拆分任务反而更高效。5.5 Linux下的安装小坑与远程使用在Linux服务器上用WorkBuddy我不小心踩过一个坑装了图形客户端之后启动时提示缺少几个系统库原因是服务器本身没有安装图形相关依赖。如果你只是要在远程环境里跑自动化流程我更推荐用命令行版本启动快、依赖少也方便写进脚本。如果是公司内网环境模型服务的网络出口设置经常需要单独配置这个很容易被忽略。我的建议是在服务器上先跑一个最简单的任务确认模型接口和配置文件目录都正常再上正式任务。服务器环境不比本地排查问题会更费时间提前验证能省很多麻烦。6. 一个让工作台越用越懂你的习惯最后分享一个我长期使用的操作习惯每次跑完一个成功的自动化任务不要急着关掉会话花两分钟让WorkBuddy把这次任务的处理过程、关键指令、注意点整理成一份简短文档存到项目的.workbuddy/skills目录或自己的知识库里。下次遇到类似任务直接调用这份经验效率又会上一个台阶。我搭WorkBuddy这几个月最重要的体会是它不是一个聊天工具而是一个可以被你持续训练的工作流平台。你给它定的规则越多、运行的流程越多、沉淀的Skill越多它就越懂你的项目、你的风格、你踩过的坑。如果你也准备开始搭建我的建议是从最小的一件重复事开始比如“每天更新某个状态表”“每周整理一次TODO清单”跑通之后再逐步扩大自动化范围。别想着一口气覆盖所有工作先从一件小事开始你会发现这个工作台越用越顺手。