1. 认识 WorkBuddy它凭什么从“聊天框”升级成“干活同事”这两年 AI 工具遍地开花我身边不少朋友一开始都是拿 ChatGPT 这类产品当“聊天工具”用——翻译个句子、写个周报、问个概念然后再手动把答案复制到自己的文档里。这么用不能说错但效率提升非常有限因为每次对话都是“一次性买卖”AI 记不住你的项目背景也不会主动去调用工具、查资料、跑流程。真正想让它像同事一样干活需要一套能把“对话”变成“任务执行”的载体WorkBuddy 这个 AI 工作台就是在解决这个问题。我第一次接触 WorkBuddy 时印象最深的是它的核心定位不是“另一个聊天机器人”而是“智能工作台”。它把大模型、本地工具、自定义技能Skill、任务流整合在一起让 AI 能够根据你的目标去拆解步骤、调用插件、检索文件甚至生成可以直接用的代码和方案。换句话说别人用 AI 是在“问问题”用 WorkBuddy 是在“派活”。这篇教程就是围绕这个转变展开的我会从环境搭建、Skill 机制、实战工作流到问题排查完整演示怎么把 WorkBuddy 从安装到落地变成真正能帮你抢时间的干活搭子。这篇内容适合几类人一是想把 AI 编程、资料检索、文档生成落地的开发者二是专利、科研、咨询这类需要大量信息筛选和比对的从业者三是工业自动化、电气设计领域想用 AI 辅助生成 PLC 逻辑代码的工程师四是单纯受够了网页版对话限制、想本地化部署一套私有 AI 工作台的人。不管你是哪一类看完应该都能少走不少弯路。1.1 WorkBuddy 与普通 AI 聊天工具的本质区别先直说结论WorkBuddy 和普通聊天工具最大的区别在于它不是一个“回答器”而是一个“执行器”。普通聊天工具的工作方式是“你问一句它答一句”所有思考都停留在文本层面它不会真的去读你电脑里的文件不会去调用外部接口也不会把一个复杂的任务拆成多步执行后再汇总结果。WorkBuddy 引入了一套任务化和技能化的机制。你给它一个目标它可以自行规划比如“帮我整理这份专利交底书的查新思路”它会先读取你上传的资料再按你预设的检索流程去比对关键词、生成对比表、输出初稿。整个过程不是一次性吐一段文字而是像同事一样分步骤完成中间还可以问你确认方向。这种“把任务接住并拆解”的能力就是它从聊天工具变成干活同事的关键。另一个关键差异是隐私和部署方式。很多人对网页版 AI 的顾虑是数据不在自己手里WorkBuddy 支持本地部署模型底座、对话记录、技能脚本都可以完全放在本机或内网服务器上。对于企业场景尤其是专利、代码、工艺这类敏感资料这一点几乎决定了它能不能真正进到生产环节。1.2 这三年我踩过的 AI 工具坑正好被它补上了我算是比较早的一批 AI 深度用户。早先我用各种大模型写方案最头疼的问题有三个。第一上下文割裂。上午让它写了项目背景下午再问细节它已经“忘了”每次都要重新贴一大堆背景资料。WorkBuddy 的工作区模式可以保持长时间的任务上下文围绕一个项目聚合多轮对话、文件和输出结果这就很像跟同一个同事连续协作。第二输出不可复用。普通的对话工具生成一段文本你还得自己复制到 Word、Excel、代码仓库里再加工。WorkBuddy 的技能可以定义结构化输出比如直接生成 Markdown 报告、CSV 对比表、标准代码文件省掉了“搬运工”环节。第三无法处理真实世界的任务。早前 AI 只能“说”不能“做”WorkBuddy 通过插件和技能让 AI 能去读本地文件、执行脚本、调用外部 API这就把 AI 从“嘴皮子选手”变成了“手脚并用”的干活同事。1.3 WorkBuddy 与 CodeBuddy、Spring AI 这类工具怎么选很多人在社区里问 CodeBuddy 和 WorkBuddy 的区别。我自己的理解是CodeBuddy 更偏向代码辅助主要面向 IDE 场景帮你补全、解释、审查代码WorkBuddy 则是一个更通用的工作台它不限制在编程领域文档处理、专利检索、工业逻辑生成、流程编排都能跑。如果你的需求就是写代码CodeBuddy 很顺手如果想让 AI 同时接管资料整理、方案输出、代码生成等多种活计那就该上 WorkBuddy。至于 Spring AI那是 Java 生态里做 AI 应用开发的一套框架面向的是开发者你需要自己写代码去集成大模型。WorkBuddy 对普通用户更友好大部分能力通过界面配置和技能文件就能完成不必从零开发。反过来如果你本来就在做企业级应用想在自己的系统里嵌入 AI 能力那 Spring AI 这类框架是更合适的底座。简单说WorkBuddy 是给“用 AI 干活的人”用的Spring AI 是给“做 AI 产品的人”用的两者不在一个层级上。2. 环境准备从下载安装到本地模型配置全流程2.1 部署方式选择本地部署还是直接用网页版WorkBuddy 提供多种使用方式最常见的是网页版和本地部署。我的建议是如果你只是体验一下用网页版最快打开浏览器注册即用如果你要处理敏感资料、需要高频长期使用、或者希望在断网环境也能工作那就必须走本地部署。本地部署的核心优势有几个数据不出门、不限对话次数、可以自由选模型底座、还能深度定制技能。缺点是需要一台配置还行的机器至少 16GB 内存有独立显卡更好——显存越大能跑的模型越大响应质量越高。没有 GPU 也不是不能用可以用量化后的小模型跑 CPU 推理速度慢一些但小任务完全够用。官网默认提供整合好的安装包支持 Windows、macOS 和 Linux。各平台的安装方式略有差异后面我会以 Ubuntu 和 Windows 为例分别讲一下。如果你之前看过相关讨论会发现很多人问“WorkBuddy 网页版”和“WorkBuddy 安装”两种方案实际上安装版功能更完整网页版适合临时预览最终干活还是建议装一套本地版。2.2 在 Ubuntu 上从零安装 WorkBuddyLinux 用户通常是要把它当服务来用的所以我先从 Ubuntu 环境讲起。假设你手头是一台干净的 Ubuntu 22.04 或者 24.04连终端都不需要太多基础照着步骤来就行。第一步更新系统并安装基础依赖。打开终端执行sudo apt update sudo apt upgrade -y sudo apt install -y curl git build-essential python3 python3-pip第二步安装 Node.js 运行环境。因为 WorkBuddy 的桌面端和服务端都是基于 Node 技术栈构建的没有 Node 跑不起来。推荐用 nvm 安装方便后续切换版本curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash source ~/.bashrc nvm install 20第三步获取 WorkBuddy 项目代码。可以下载官方发行包也可以用 git 拉取。这里以源码方式为例git clone https://github.com/workbuddy-app/workbuddy.git cd workbuddy npm install第四步启动服务。如果你只是本地单机使用默认配置可以满足直接运行npm run start启动后终端会输出 Web 服务地址一般是http://localhost:3000浏览器打开就能看到工作台界面。这里补充一句如果你要把 WorkBuddy 共享给局域网内其他人用需要在配置里修改监听地址为0.0.0.0并且注意设置访问令牌否则别人也能连上来。2.3 Windows 与 macOS 安装避坑指南Windows 用户相对简单去官网下载 Windows 安装包双击安装按向导点下一步即可。不过有两个坑我得提醒一下。一是安装路径尽量不要选带空格的目录有些内置脚本对路径解析不友好二是 Windows Defender 偶尔会拦截首次运行时的本地服务进程如果启动后页面打不开去“病毒和威胁防护”里看一下隔离记录把 WorkBuddy 相关目录加为排除项。macOS 用户同样下载对应安装包。首次打开如果提示“已损坏无法打开”不用慌这是系统 Gatekeeper 对未签名应用的拦截在“系统设置 - 隐私与安全性”里选择“仍要打开”即可。M 系列芯片的 Mac 建议下载 arm64 版本运行更流畅。安装完之后第一次启动会引导你配置模型服务。这里很多人卡住我单独说一下。2.4 模型底座配置本地模型与在线大模型 API 的选择WorkBuddy 本身不内置大模型它像一个“调度中心”需要对接一个模型服务才能开始对话。目前主流的对接方式有两种。一种是对接本地模型服务首选 Ollama。Ollama 是一个本地模型运行工具支持 Llama、Qwen、DeepSeek 等一系列开源模型。先按照 Ollama 官网文档装好然后拉取模型ollama pull qwen2.5:14b14B 的模型在 16GB 内存的机器上基本可用效果也够日常使用。如果机器配置较低可以换qwen2.5:7b或llama3.2:3b。然后在 WorkBuddy 的模型设置里接口地址填http://localhost:11434模型名称填qwen2.5:14b即可。另一种是对接在线大模型 API。WorkBuddy 支持 OpenAI 兼容协议你只需要有一个 API Key在设置里填接口地址和密钥。用在线 API 的好处是模型能力强、响应快代价是数据会经过第三方服务敏感内容要注意规避。我个人的实践是涉密或敏感项目一律走本地模型普通文档和代码工作走在线 API两套配置可以共存随时切换。注意模型底座的选择会直接影响后面所有技能的效果。我的建议是第一优先级看硬件第二优先级看任务类型。纯文本处理 7B 模型就够代码生成建议至少 14B复杂逻辑推理和长文档分析尽量上 32B 以上或在线 API。3. Skill 技能系统让 WorkBuddy 学会“你的干法”3.1 把 Skill 想象成给新同事写的标准作业流程如果你和我一样带过新人就一定明白一个道理想让新人干活靠谱光靠嘴巴交代是不够的最好把步骤写下来让他照着执行。Skill 在 WorkBuddy 里就扮演了“标准作业流程”的角色。Skill 本质上是一个结构化的指令文件里面包含了角色设定、执行步骤、输入输出要求和参考规则。当你把一个 Skill 加载到对话中WorkBuddy 就不再是自由发挥地聊天而是严格按照你定义的流程来处理任务。这意味着结果更加可控、可复用——同一套流程今天用、明天用换个项目还能用。我见过很多人把 Skill 理解为“更长的 Prompt”其实不完全对。Prompt 只是“一段话”而 Skill 是“一套完整的任务说明书”它不光告诉 AI 该怎么做还可以挂载参考文件、设置输出模板、规定判断标准甚至串联多个动作。你可以把它理解为 Prompt 的工程化升级版。3.2 Skill 与自定义指令什么时候用哪个刚接触 WorkBuddy 的人经常会混淆“自定义指令”和“Skill”。根据我实操的经验两者最本质的区别在于通用性和专一性。自定义指令适合全局性的偏好设置。比如你希望所有回答都用中文、输出格式要带小结、代码要附注释这类“贯穿所有任务”的要求写在自定义指令里就行每个对话都会默认遵守。Skill 适合高度场景化的专项任务。比如“专利查新报告生成”“PLC 定时器程序生成”“代码审查报告输出”——这些都是特定场景下的完整工作流需要专门的步骤和输出模板。如果你把这类复杂流程塞进自定义指令不仅会让普通对话变慢还会干扰其他任务的执行效果。我的习惯是全局偏好用自定义指令专项工作全部拆成单独的 Skill。这样做的好处是每个 Skill 都能单独维护、版本迭代换机器换环境也不用重新调教。3.3 手把手编写一个最简单的 Skill写 Skill 并不神秘它通常是一个包含 YAML 或 JSON 元信息、系统提示词和执行逻辑的脚本文件。我以一个“专利查新检索辅助”技能为例演示完整过程。先创建技能目录mkdir -p workbuddy-skills/patent-assistant cd workbuddy-skills/patent-assistant然后创建元信息文件skill.yamlname: patent-assistant description: 辅助专利查新检索与交底书初稿生成 version: 1.0.0 author: your-name triggers: - 专利查新 - 交底书 - 检索对比接着创建技能主体SKILL.md# 专利查新检索辅助技能 ## 角色 你是一名经验丰富的专利检索分析师擅长拆解技术方案、构建关键词式、判断新颖性。 ## 执行步骤 1. 阅读用户提供的技术交底内容或专利草案。 2. 提取核心技术特征拆分为独立技术点。 3. 为每个技术点构建中文、英文检索关键词包含同义词和上下位词。 4. 列出推荐检索式注明 IPC 分类号建议。 5. 根据用户给出的对比文件逐条比对技术特征生成对比表。 6. 输出检索结论标注高风险项和补充建议。 ## 输出格式 - 检索式以代码块给出便于复制到专利数据库。 - 对比表使用表格列出技术特征、对比文件公开内容、结论。 - 结论明确署名“新颖性较高”或“建议修改后再提交”。 ## 注意事项 - 不要编造不存在的对比文件。 - 对不确定的内容明确标注“需要人工核验”。 - 关键词式的构建要兼顾精确和扩展避免漏检。保存文件后回到 WorkBuddy 界面在技能管理里导入这个目录。之后新建对话时选择patent-assistant技能把你的技术交底材料粘贴进去它就会按照上述流程帮你出检索方案。你会发现这样的技能比“帮我写专利检索报告”这种一句话指令可靠得多。因为它规定了分析框架和输出格式AI 不会东扯西扯每次产出结构一致你只需要做最后的校对和判断。3.4 常用的 Skill 搭配推荐检索、代码生成与内容总结组合拳技能可以单独用也可以组合使用。我目前的主力搭配是三套技能协同。第一套是信息检索类。除了上面的专利查新技能我还配了“技术调研报告生成”技能专门用来跟踪竞品动态和前沿技术。设定好后我会把搜集到的论文摘要、官网介绍、新闻资料丢进去让 AI 生成结构化综述省去大量整理时间。第二套是代码生成类。我配了“PLC 代码生成助手”“Python 脚本开发助手”“代码审查员”三个技能。PLC 那个比较有意思我给它输入了 I/O 分配表和工艺时序要求它能直接生成结构化文本形式的梯形图描述或 SFC 流程说明电气工程师再据此在编程软件里实现效率提升非常明显。代码审查员技能则会在每次提交前自动过一遍我的代码帮我找出明显的逻辑问题和安全漏洞。第三套是内容总结类。比如“会议纪要生成”“项目周报生成”用来处理日常事务性工作。这些技能配置很简单核心就是把输出模板定义好AI 按模板填空就行。用熟练之后你会发现Skill 的价值不是单个技能有多炫酷而是它们能拼成一个“虚拟团队”检索员、写手、程序员、审查员都在你的工作台里待命。你要做的就是像项目经理一样把任务分派下去把结果收回来做决策。4. 实战部署把 WorkBuddy 放进真实工作流4.1 专利辅助场景从交底材料到查新对比表专利相关的写案和查新是我日常使用频率最高的场景之一尤其适合 WorkBuddy 来承接。以前我写查新报告先要自己通读技术交底书再手动拆技术特征然后去数据库试各种检索式一天时间就耗进去了。现在流程完全变了。我先把技术交底书丢进开启了“专利查新检索辅助”技能的对话里AI 会先输出拆解好的技术特征点。比如一个“基于边缘计算的设备故障预测方法”它会拆成“边缘侧数据采集”“轻量化模型部署”“故障特征提取”“预警规则生成”等几个技术点每个点列出中英文关键词和扩展词还有 IPC 分类建议。然后我把数据库检索到的对比文件摘要返回给它让它逐条比对。这样生成出来的对比表会非常清晰每一列分别是“技术特征”“对比文件公开内容”“是否存在一致”“风险判断”。最后它的结论部分会直接告诉我哪些点需要修改描述才能绕开现有专利。这些活儿过去全凭人工经验现在等于有了一个不会累的检索助手。实操提醒AI 生成的检索式和对比结论只能作为辅助参考专利审查严格依赖法律判断和数据源权威性最终递交前一定要由专业代理人或审查员把关。我的用法是让 AI 先把 80% 的重复整理工作做完把时间和精力省下来留给 20% 需要人工判断的关键环节。4.2 PLC 代码生成场景让 AI 接手重复逻辑编写PLC 编程和普通 IT 编程不一样很多逻辑是高度套路化的电机启停、定时器连锁、报警复位、手动自动切换翻来覆去就那么几种结构。我最初尝试用 AI 写 PLC 代码时用的是普通聊天工具发现它对工业现场的半懂不懂给出的程序经常缺少连锁保护根本没法直接用。后来我在 WorkBuddy 里专门做了一个“PLC 代码生成助手”技能把常见的编程规范、安全互锁逻辑和输出格式全部固化进去效果立刻不一样了。这个技能的执行逻辑是先接收 I/O 分配表包括输入点、输出点、中间继电器地址再接收控制时序要求然后按照 ST 语言或结构化文本输出程序框架并附带注释。对于电机正反转这种典型场景它还会主动补充互锁逻辑防止上下电同时导通。虽然生成结果不能直接灌进西门子或三菱软件里跑但作为逻辑设计和编程草稿已经相当够用工程师在基础上改几分钟就能落地。实际用下来我发现最有价值的是它能把“用户需求描述”翻译成“逻辑设计说明”。以前我跟机械工程师对接经常要花大量时间理解他们的工艺流程再转译成控制逻辑现在直接把流程描述粘贴给 WorkBuddy它会输出结构化的动作时序表和对应的程序伪代码双方沟通效率高了很多。这个小工具也推荐给自动化集成工程师和电气设计同行试试。4.3 AI 辅助编程场景不只是写代码更是写对代码我在代码类任务上对 WorkBuddy 的用法分了三个层次。第一层次是生成代码比如写一个处理 Excel 数据的 Python 脚本或者一个 REST API 的 Flask 服务。这个层次跟普通聊天工具差异不大只要模型够强就行。第二层次是代码理解和解释。接手别人的旧项目时我会把关键文件丢给它让它输出模块结构分析、数据流说明和潜在风险提示。这个用法对维护老旧设备的工艺代码特别有用那些没有注释的梯形图和 ST 程序由 AI 先读一遍并输出人话版解释我再对照实物验证效率翻倍。第三层次也是我最看重的是代码审查和测试用例生成。我会把刚写完的函数交给“代码审查员”技能让它从空指针、边界条件、资源泄漏、并发安全几个维度检查并给出修改建议。再让“测试用例生成”技能输出单元测试用例覆盖正常路径、异常路径和边界值。有了这两步代码质量明显上了一个台阶提交后被打回重改的次数大幅减少。4.4 把零散任务编排成完整工作流WorkBuddy 有一个很实用的功能支持把多个技能按顺序串成一条工作流。比如我做一个“项目启动辅助”工作流就串联了四个步骤第一步用“项目背景分析”技能拆解需求第二步用“技术选型建议”技能输出方案对比第三步用“风险评估”技能列出潜在问题第四步用“周报生成”技能产出计划文档。实际配置的时候我可以把前一步的输出自动传给后一步作为输入形成自动化流水线。这就像把一个项目分包给几个不同专长的同事上一环节做完下一环节自动开始。虽然目前还做不到全自动无人值守但至少把 HR 经常提到的“减少机械性重复工作”落地了一部分。让我这种不太喜欢做流程管理的人也愿意主动去搭流程因为它真的能省下不少时间。5. 常见问题与排查技巧实录5.1 安装启动失败的典型原因我见过最多的问题集中在安装启动阶段而且翻来覆去就那么几个原因。端口被占用是头号问题。安装后启动发现地址打不开十有八九是 3000 端口被其他程序占用了。排查方法很简单Linux 下执行lsof -i:3000Windows 下执行netstat -ano | findstr :3000找到占用进程后杀掉或者修改 WorkBuddy 配置里的端口号重启。依赖安装失败也很常见尤其在国内网络环境下npm 下载依赖经常半路超时。解决办法是把 npm 源切到国内镜像npm config set registry https://registry.npmmirror.com然后删除node_modules重新安装。另外Node 版本太老也会导致安装报错建议至少使用 Node 18 以上我实测 Node 20 最稳。5.2 模型连不上或响应慢的排查思路模型服务配置错误是另一大类问题。典型表现是对话界面能打开但发消息后一直转圈或直接报错。第一步先确认模型服务本身是否正常。如果用的是 Ollama在终端执行ollama list查看模型是否已经拉取成功再执行ollama serve确认服务启动状态。如果 Ollama 没有启动WorkBuddy 当然连不上。第二步检查 WorkBuddy 设置里的接口地址和模型名称是否完全一致。很多版本对模型名称大小写敏感填错一个字符都会失败。我推荐先把模型服务用 curl 单独测试一遍curl http://localhost:11434/api/generate -d {model: qwen2.5:14b, prompt: 你好}如果能返回内容说明模型端没问题问题大概率出在 WorkBuddy 的配置上。响应慢的问题一般有两个方向一是模型太大设备性能跟不上。比如在 8GB 内存机器上跑 14B 模型慢是必然的换个 7B 模型立刻改善。二是首次加载模型需要时间尤其本地模型要一次性载入显存启动后的第一轮对话慢是正常现象等一轮之后就会流畅很多。5.3 Skill 不生效的检查清单很多人导入了 Skill 后发现 AI 根本不按套路出牌我总结了一下基本都是这三个原因。第一个是技能没有正确加载。新建对话时要确认在技能选择区勾选了对应技能。如果只打开普通对话模式Skill 不会自动生效。第二个是技能文件格式写错。YAML 对缩进极敏感一个空格错误就可能导致解析失败。我的经验是用支持 YAML 语法高亮的编辑器编写比如 VS Code写完后先本地解析验证一遍再导入。如果导入时提示错误优先检查引号、冒号、缩进。第三个是触发词冲突。多个技能都定义了相同的触发词时WorkBuddy 可能选择了错误的一个。解决办法是在技能描述里把触发条件写得更具体避免和其他技能交叉。5.4 高频问题速查表问题现象可能原因处理方案安装后页面打不开3000 端口被占用释放端口或修改配置端口npm 安装依赖超时网络源较慢切换到国内镜像源重装对话发送后一直转圈模型服务未启动或地址配置错误用 curl 测试模型服务检查 API 地址和模型名本地模型响应很慢模型参数量与硬件不匹配更换更小的量化模型或升级硬件Skill 导入报错YAML 格式不合法检查缩进、引号、编码格式Skill 对话不按流程来未勾选技能或触发词冲突确认技能已加载调整触发词唯一性局域网内别人无法访问默认监听 127.0.0.1改为监听 0.0.0.0 并设置访问令牌这张表基本覆盖了我自己踩过的坑和帮朋友排查过的绝大多数问题。如果你遇到表格之外的情况还有一个通用的笨办法把 WorkBuddy 的日志级别调到 debug重启后看终端输出大部分错误原因都会直接打在日志里比自己瞎猜高效得多。6. 更进一步从会用 WorkBuddy 到会调教 WorkBuddy6.1 观察你自己的使用习惯沉淀成专属技能我见过太多人用 AI 工具停留在“每次重新描述需求”的阶段。今天让它写周报你打一大段背景明天让它写周报又打一大段背景。这种用法既累效率又低而且效果还不稳定。真正的进阶用法是把你反复做的事情沉淀成技能。连续两周记录下来自己都在用 AI 做什么你会发现规律每周五写周报、每月底做月度复盘、每个新项目启动时要写调研报告、每次写代码前要做方案设计。把这些高频任务各配一个 Skill把固定流程固定下来把变量部分留成参数。一次调教长期收益这才是 WorkBuddy 的正确打开方式。我自己的经验是不要一上来就追求做“超级复杂”的技能先做最小可用版本跑通流程再根据实际使用效果迭代。比如周报技能第一版只有三行指令后续才逐渐加入数据汇总、亮点提炼、下周计划等模块。渐进式打磨比一口吃成胖子成功率高得多。6.2 用版本管理思路维护你的技能库既然技能是你工作方法论的沉淀那它和代码一样需要版本管理。我的技能目录全都用 Git 管理每次优化技能内容后都会提交一次备注里写明改动原因。这样做的好处是哪天把技能改坏了随时可以回滚到之前能用的版本。换新电脑时git clone一下就把整套路子带过去了不用重新配置。技能命名也值得花点心思。我见过很多人的技能文件叫新建文档.yaml三个月后自己都认不出里面是什么。我的推荐命名规则是“场景-功能-版本”比如patent-search-v1、plc-generator-v2。一眼看到就能判断这个技能是干什么用的不会混乱。6.3 我的四点深度使用体会第一条体会AI 工具的上限由你的任务拆解能力决定。同样的 WorkBuddy有人觉得它是神器有人觉得跟普通聊天工具没区别差别就在于有没有把任务想清楚。你越能把业务拆成清晰、可执行的步骤AI 的发挥就越稳定。这跟带新人是一样的道理。第二条体会技能要持续迭代没有一步到位的完美配置。我最初写的专利技能输出格式和后来迭代的版本差距很大。不必追求一开始就完美先让流程跑起来再根据结果反馈修正每次优化一点点一段时间后就会发现质变。第三条体会AI 适合做量不适合做质适合做初稿不适合做终稿。这里说的“质”和“终稿”是指那些需要行业判断力和责任承担的环节。AI 帮你把检索、整理、初稿这些耗时耗力的环节跑完最后的关键判断必须由你自己来。遇到过好几个朋友把 AI 生成的结果直接递交结果出了纰漏这不是工具的错是对工具期待错了。第四条体会把 WorkBuddy 当成团队里的新同事去培养而不是当成搜索引擎去使用。搜索引擎给答案同事帮你解决问题。你给同事交代背景、提要求、给反馈他也逐步摸清你的偏好越来越好用。WorkBuddy 的技能机制本质上就是这个逻辑。多花点心思调教它它会以超出预期的效率回报你。