1. 先聊清楚WorkBuddy 到底是什么定位说实话我第一次看到“WorkBuddy”这个词第一反应是“又一个套壳聊天机器人”。但真正装上、用上之后才发现它的核心卖点压根不在“聊天”上而在于它把 AI 大模型的能力接到了你的本地文件系统里。你可以命令它“把这个目录下所有 PDF 按文件大小排序并复制到另一个文件夹”它真的会去做而不是只给你一段建议。这种“可操作本地文件”的能力才是它和普通聊天 AI 最本质的区别。我最早是被朋友安利的他说这是“会动手的 AI 助手”。当时我还在用各种网页版问答工具它们确实能写文案、能改代码但每次想让它处理电脑里的文件它就只能甩给我一串“你可以手动执行以下步骤”的废话。WorkBuddy 的逻辑完全不同它基于 MCP模型上下文协议打通了本地文件系统的读写通道AI 模型不仅能“看懂”你的文件内容还能按照指令执行新建、重命名、移动、批量修改等具体操作相当于给大模型装了一双手。这篇手记是《WorkBuddy 实战手记》系列的第一篇目标读者是两类人一是想把手头 AI 工具从“问答玩具”升级成“效率工具”的普通用户二是对 MCP 机制、本地文件权限模型感兴趣的开发者。我会把我这几周踩过的坑、验证过的用法、以及我自己的一套自定义指令整理出来尽量做到零基础也能跟着操作。我个人的结论先说在前面WorkBuddy 不是那种你装上之后马上就能“哇”一声的工具它更像一把瑞士军刀——能不能发挥作用取决于你会不会用。而“会用”的关键在于理解它和聊天 AI 的差异以及如何配置好它和本地文件的协作方式。接下来我会从整体设计讲起逐步拆解实操细节。2. 整体设计与思路拆解为什么说它是“执行者”而不是“应答者”2.1 从“说”到“做”桌面智能体的本质区别传统的聊天 AI交互链路是“用户提问—模型生成文本回答”。你问它“帮我整理桌面文件”它给你的是一段文字建议比如“你可以按类型创建文件夹然后手动拖拽文件”。WorkBuddy 这类桌面智能体的链路则是“用户发出指令—模型规划任务—调用工具执行—返回执行结果”中间多了一个“工具调用层”。这个工具调用层就是 MCP 协议在做的事情。MCP 的全称是 Model Context Protocol它定义了一套标准化的接口让 AI 模型可以安全地调用外部工具。在 WorkBuddy 的上下文里这个“外部工具”就是本地文件系统。你可以把 MCP 理解成 AI 与文件系统之间的一个翻译官兼执行者模型说“我想读取这个文件”MCP 负责把文件内容拿给模型看模型说“把这个文件重命名”MCP 负责实际执行重命名操作。没有这层协议模型就只是一个“纸上谈兵”的大脑有了它模型才真正拥有了对电脑的控制能力。很多人第一次用 WorkBuddy 时会犯一个认知错误把它当搜索引擎用问“今天天气怎么样”或者“推荐一部电影”。这类问题它当然也能答但那只是它的基础能力属于“副业”。它真正的胜任场景是那些需要反复操作文件、批量处理数据、按照规则整理内容的活儿。比如我有个使用场景是每周整理下载文件夹里堆积的文件用 WorkBuddy 设定规则后它会按扩展名分类、自动归档、清理重复文件整个过程不需要我动手。从产品设计角度看WorkBuddy 的思路是把“模型能力”和“本地资源”分开模型负责理解意图、拆解任务、生成决策本地文件系统则由一个独立的权限层控制。这样做的好处是安全——AI 即使被诱导去执行危险操作也只能在用户授权的范围内活动而不是裸奔在整台电脑上。理解了这个设计哲学你在使用它时就会更有意识地区分“该让 AI 自主操作”和“该手动处理”的边界。2.2 MCP 与文件操作模型WorkBuddy 是怎么“动手”的如果你用过浏览器插件、命令行工具或者看过一点配置文件的语法你很快就能理解 WorkBuddy 的操作模型。它本质上是一个事件驱动 指令映射的执行器你输入的自然语言指令会先经过大模型解析模型输出一组结构化指令再经由 MCP 转换成实际的文件系统调用。举个例子我对 WorkBuddy 说“把 D:\项目归档\里的 .tmp 文件全部删掉然后把剩下的文件名里带有‘草稿’的文件夹压缩成 zip。”它的处理流程大致是这样的先通过 MCP 列出该目录的完整文件列表模型分析这些文件识别出 .tmp 后缀的文件然后发起删除调用接着遍历目录筛选名称包含“草稿”的文件夹压缩并生成 zip 文件。整个过程中用户只需要给出一个自然语言的描述具体拆解由模型完成。这种设计的妙处在于模型不需要预先“知道”你的文件目录结构它是实时通过 MCP 来获取信息的。换句话说你电脑里有什么它就能看到什么不需要提前维护什么索引数据库。这也是它比那些“网盘 在线文档”类 AI 更贴近本地办公的原因——文件保存在你的电脑上处理也在你的电脑上完成。不过这里有一个容易被忽略的细节权限模型。WorkBuddy 默认情况下并不会允许 AI 无限制访问整个磁盘。你需要在配置里明确告诉它哪些目录是“工作区”它只能在这些白名单目录内执行文件操作。这个设计既保护了系统关键路径不被误操作也避免了 AI 在状态混乱时对个人文件造成破坏。我第一次配置时就把整个用户目录都放进了白名单虽然权限上是省事了但风险也更大后面我会专门讲怎么合理设置权限边界。2.3 为什么不用命令行而是用自然语言有人可能会问既然最终都是文件系统调用那为什么我不直接用 cmd 或 PowerShell这是很多人对桌面智能体的第一反应。答案其实在于“意图解析”的粒度不同。命令行的每一条指令必须精确到参数删除哪些文件、按什么规则筛选、文件名模式怎么写都需要用户自己掌握语法。而 WorkBuddy 允许你用“把最近一周没有打开过的文件移到备份文件夹”这种模糊但语义明确的句子来下达指令。模型会自动判断什么是“最近一周没有打开过”它可能会读取文件的访问时间属性然后按时间筛选。这种从“编程思维”到“意图思维”的转变才是 AI 桌面智能体真正的价值。当然这不意味着你可以完全不懂底层操作。恰恰相反理解文件系统的属性如修改时间、访问时间、扩展名、目录结构能让你更加精准地表达意图。我在实践中的体会是能用自然语言描述清楚的需求WorkBuddy 能帮我做掉 80% 的文件操作工作量但剩下的 20% 需要手动介入往往是因为需求本身包含了太多隐含规则模型无法从文件内容中推测出来。比如“把重要的文件挑出来”——“重要”这个属性就不存在于文件元数据中模型只能靠文件名、目录名、内容关键词去猜这种场景我会选择手工处理。3. 核心细节解析与实操要点安装、配置与权限模型3.1 WorkBuddy 安装与初始配置的完整步骤如果你还没装 WorkBuddy这里给出我实测的安装路径。第一步是去官网下载对应平台的安装包Windows、macOS、Linux 三个平台都有支持。安装过程基本是“下一步-下一步”没什么坑但有一个关键点要留意安装完成后首次启动它会引导你选择一个“工作目录”这个目录就是 AI 默认可以读写的文件夹。建议不要直接选整个用户目录而是单独建一个空的文件夹比如C:\WorkBuddySpace后续让它操作的文件都放里面这样你随时能看清楚 AI 动了什么。第二步是配置模型服务。WorkBuddy 本身不内置大模型它需要调用外部的大模型接口可能是 OpenAI 兼容接口、本地部署的模型也可以选择内置的默认服务商。这里需要填一个 API Key。我的建议是如果你有本地部署的显卡机器优先连本地模型比如用 Ollama 拉一个 14B 左右的模型速度和隐私都更有保障如果你更看重效果那用云端模型的旗舰版本效果会更好推荐先用云端模型跑通流程再考虑本地化部署。第三步是权限配置。在 WorkBuddy 的设置面板里有一个“工具权限”区域里面会列出 MCP 可用的工具清单比如“读取文件”“写入文件”“重命名文件”“删除文件”“列出目录”等。你需要逐个勾选允许 AI 使用的工具。我的经验是初期全部勾选方便体验完整能力但正式使用时一定要关闭“删除文件”或至少在特定目录下开放——因为自然语言指令在解释时很容易出现歧义一旦它理解了“删除”可能会连带删掉不该删的文件。设置完这三步就可以开始正常对话了。3.2 工作目录与文件范围安全与效率的平衡关于工作目录我再展开多说几句因为我一开始确实在这里吃过亏。WorkBuddy 默认会限制 AI 的操作范围只允许它在你设定的工作目录内执行读写。我把整个“下载”目录加入白名单觉得这很方便——所有下载的文件都能被 AI 直接访问。但问题也随之出现某天我让它“帮我清理下载文件夹里所有不到 1MB 的文件”它把我的安装包安装程序也当成垃圾文件删掉了而那些其实是我要保留的东西。后来我把工作目录改成了一个专用的WorkBuddySpace并在里面按项目建了子文件夹。这样做的两个好处第一AI 操作的范围越小误操作的影响面就越小心里有底第二工作目录里的文件都是“有意为之”的AI 处理时能通过目录结构更准确地理解你的意图。比如你在归档/合同目录下放的文件AI 就更容易判断哪些是重要文件哪些是临时文件。另外还要提醒一点如果你要在 WorkBuddy 中处理 Obsidian 笔记库之类的项目最好把整个知识库文件夹单独设置为工作目录并开启“可写权限”。这样你可以让 AI 帮你批量添加 frontmatter、整理标签、合并重复笔记效率提升非常明显。我在 Obsidian 的使用场景中验证过批量重命名和标签整理确实能省下大量手工时间。但注意知识库文件往往涉及你长期积累的内容建议操作前用 Git 或备份工具做个快照避免误操作后无法恢复。3.3 自定义指令与 Skill 脚本把常用操作变成一句话WorkBuddy 最有意思的地方是它支持通过“自定义指令”和“Skill 脚本”来扩展能力。通俗来说自定义指令就是你自己定义的一套“快捷指令”每次你只需要说“执行 XX 指令”AI 就会按照预设的步骤去执行而不用每次重复描述细节。我举一个实际例子。我每周都要把某个项目目录下的所有 Markdown 笔记整合成一个总览文件输出为一个新的文档。以前我每次都要说把 A 目录下的所有 .md 文件按创建时间排序合并到一个总览.md 中并且在开头生成一个目录索引。现在我把这整段描述保存为一个自定义指令名字叫“生成周报总览”。之后我只需要说“执行生成周报总览”它就会完全按照预设步骤操作。Skill 脚本更进一步它允许你写一段脚本支持 JSON 配置或代码片段来定义非常规操作比如自动签到、定时任务、批量下载等。打个比方自定义指令相当于给 AI 背下来了一本“操作手册”Skill 脚本则是给 AI 装上了一个“机械手臂”——可以跟外部程序接口对接执行复杂的多步骤任务。这里我建议新手先捣鼓清楚自定义指令的配置格式再考虑写 Skill否则一次引入过多概念反而容易搞混。下面是我常用的一个自定义指令配置片段YAML 格式供参考name: 生成周报总览 description: 将指定目录下所有 md 文件合并为一份周报文档 parameters: - name: source_dir description: 存放 md 文件的目录 required: true steps: - action: list_files directory: {{source_dir}} filter: *.md - action: sort_files by: created_time order: ascending - action: merge_files output: {{source_dir}}/周报总览.md with_index: true这个配置的核心逻辑就是三步先列出指定目录下所有 .md 文件再按创建时间排序最后合并输出并加上索引。我的经验是配置文件的语法不必死记每次需要时查一下官方文档的字段说明即可关键是理解流程的编排方式。3.4 与 Claude Code 等同类工具的横向对比既然热词里有人对比 Claude Code 和 WorkBuddy我也从实际使用角度说下差异。Claude Code 更偏向开发者场景它专注于代码仓库内的操作比如跨文件重构、测试生成、Git 操作等本质上是一个“编码智能体”。WorkBuddy 则更通用一些它面对的是普通文件和办公场景不局限于代码。两者底层都用了 MCP 协议连接外部工具但对于“文件操作”的精细度不同Claude Code 对代码语法和项目结构的理解更深WorkBuddy 对文件类型、元数据和批量操作的支持更广。如果你是程序员想让它帮你改代码、跑测试Claude Code 可能更顺手但如果你日常工作是处理文档、表格、多媒体资料WorkBuddy 会更贴合需求。当然两者也可以搭配使用我用 Claude Code 处理代码项目用 WorkBuddy 处理资料归档和文档整理互不冲突。另外关于热词里出现的“workbuddy 502 write eacces”这个报错我后面会专门在常见问题里讲这里先不展开。总之选型就一句话你的主要操作对象是什么就选对应工具链最成熟的。4. 实操过程与核心环节实现让 WorkBuddy 真正干一次活4.1 实战让 WorkBuddy 批量整理下载文件夹为了让你更直观地看到完整流程我记录了一次真实的操作。场景是这样的我的下载文件夹积压了三个月未整理的文件数量大概 200 多个里面有安装包、临时文件、图片、PDF 文档等。我决定交给 WorkBuddy 处理。操作开始前我先做了一次备份把下载目录里的所有内容复制到了移动硬盘避免出问题。然后我在 WorkBuddy 对话里输入指令“整理我的下载文件夹 E:\Downloads把所有文件按扩展名分类分别放入 安装包、图片、文档、压缩包、其他 这五个子文件夹所有 .tmp 或 0 字节的文件直接删掉整理完成后生成一个分类统计报告保存为 report.md。”这句话说完它就开始了。我观察了它的执行过程大概分几个阶段。第一阶段是“扫描目录”它通过 MCP 列出目录下所有文件包括文件名、类型、大小、修改时间第二阶段是“分类决策”它根据扩展名映射规则将每个文件映射到目标子文件夹第三阶段是“执行写入”它创建五个文件夹然后逐个复制或移动文件第四阶段是“清理”把 .tmp 和零字节文件删除最后是“生成报告”把分类统计结果写到 report.md。全程大约用了不到两分钟比我手动操作快多了。我特意检查了一下它生成的 report.md里面不仅有每个分类下的文件数量还有按大小排序的前十个大文件。虽然这些数据我也可以通过脚本获得但能用大白话说出“你的临时文件已经清理完毕最大的文件是三个视频压缩包”这种结论体验确实不一样。这让我更确信WorkBuddy 在“帮人做事”上的产品价值远大于“陪人聊天”。4.2 前置准备如何为 AI 指定一个清晰、可执行的目录规则从上面的实战过程可以看到指令的清晰度直接影响执行质量。如果你对 WorkBuddy 说“帮我把文件整理得干净一点”它大概率会按照它自己理解的“干净”去执行结果可能和你的预期不完全一样。所以我给它的指令都遵循一个模板范围 动作 过滤条件 输出要求。范围是指要操作哪个目录必须写绝对路径或明确符号动作是指要做什么比如“分类”“重命名”“删除”“移动”“压缩”过滤条件是关键比如按扩展名、按修改时间、按文件大小、按文件名关键词输出要求是指处理完之后的产出形式比如一个汇总报告、一个新文件夹结构或者一条成功消息。例子里就是完整的四要素模板。此外如果你希望 AI 处理过程中有更高的可追溯性可以在指令末尾加上一句“执行前先列出你计划执行的操作清单等我确认后再执行”。这个操作模式叫“确认模式”能有效避免因为指令理解偏差导致的批量误操作。我实际操作中大概有 3 成场景会开启确认模式比如批量重命名、批量删除这类不可逆操作而新建文件夹这类低风险操作我会直接让它执行不浪费时间。如果你处理的是非常多文件的批量任务比如一次处理上万个文件遇到性能问题时可以考虑分批次执行先让它处理一个子目录验证没问题后再处理剩下的。不要试图让它一次性理解全部需求很多时候分步骤比一次到位更可靠。4.3 参数选择逻辑与文件路径解析的经验说到参数选择有一个容易踩坑的点是路径格式。Windows 用户要用反斜杠E:\DownloadsmacOS 和 Linux 用户要用/Users/name/Downloads。WorkBuddy 里的 MCP 工具对这两种路径格式的兼容性不同一个常见的报错就是“找不到路径”排查下来往往是路径分隔符写反了。我在 Windows 上习惯在指令里写正斜杠E:/DownloadsWorkBuddy 也能正确解析但如果你调用了脚本或 Skill脚本内部的路径解析可能就会出问题。建议在配置和指令中统一用一种分隔符避免混用。另外一个参数是“文件属性判断”的选择。比如“最近一周没有打开的”这个需求涉及文件元数据的atime字段但很多文件系统在挂载时并没有开启 atime 更新导致“访问时间”并不准确。我在几台机器上测试过默认情况下读取到的访问时间往往是文件创建时间或读取缓存的时间跟实际操作不一定一致。如果你的需求对时间属性很敏感建议用“修改时间” mtime 而不是“访问时间” atime 作为判断依据两者在 MCP 文件工具中都有支持但语义差别很大。如果你处理的是网络同步盘比如 OneDrive 或 iCloud 的本地同步目录我还要多提醒一句本地文件指针可能只是占位符实际内容在云端MCP 读取到的文件大小可能不准确甚至文件内容未下载AI 无法读取。这种情况下操作前最好先让同步盘把文件完全同步到本地再进行文件整理或批量处理。这是很多人在网盘同步目录上操作失败的主要原因。4.4 可复现的模板一套我每天在用的 WorkBuddy 工作流前面讲了很多下面提供一个我每天实际在用的完整工作流模板你可以直接套用或改成自己的场景。这个模板解决的是“日常收件箱归零”问题一天中产生的临时文件、截屏、下载的文档我希望每天结束前自动归档。第一步创建一个工作目录例如E:/WorkBuddySpace/每日收件箱把电脑的截屏目录和浏览器下载目录的“自动整理入口”指向这里具体设置因系统而异但本质是把散落的文件汇聚到一个目录。第二步在 WorkBuddy 中定义一条自定义指令“整理今日收件箱”它的逻辑是列出工作目录内所有文件按扩展名映射到归档目录图片进“图片”、文档进“文档”、压缩包进“压缩包”按日期生成归档子目录比如文档/2025-06-10然后对每个文件做归档移动删除 .tmp 文件最后生成一份归档清单.md。第三步每天下班前打开 WorkBuddy 说一句“执行整理今日收件箱”。如果当天有不确定分类的文件它会留下一个“待分类”文件列表我花两分钟手动过一遍。整套流程运行下来 5 分钟搞定比我以前每周花一小时清理桌面省时太多。一个值得注意的细节归档清单.md 记录的是“文件从哪里移动到哪里”这个日志非常有用。如果你某天发现文件不见了打开日志就能追踪到具体路径不用抓瞎。如果你愿意折腾也可以把这个日志文件放到 Obsidian 库中跟笔记打通形成“日常操作日志”这算是我比较推荐的一个扩展用法。5. 常见问题与排查技巧实录从 502 到权限拒绝5.1 “write eacces”权限报错最常遇到的坑热词里出现了一个典型的报错“workbuddy 502 write eacces”。我第一次遇到时也是一头雾水排查了一会儿才搞明白。这个报错翻译过来就是“写入失败权限不足”本质上是操作系统层面的文件权限拒绝WorkBuddy 进程没有权限在目标目录中创建或修改文件。最常见的触发场景有三个第一工作目录设置在系统保护路径下比如C:\Program Files或/System/Volumes/Data下的某些目录普通用户权限不够第二目标目录的 ACL 权限设置不当或者目录被其他进程锁定比如杀毒软件正在扫描第三WorkBuddy 是以普通用户权限启动的而目标文件属于管理员或另一个用户所有。排查思路也很直接先看报错日志里提示的目录路径确认它在不在你的工作目录白名单里再用系统的文件管理器手动尝试在该目录下新建一个文件如果手动也无法创建那就是系统权限问题需要调整目录所有者或权限最后检查有没有杀毒软件或安全策略拦截了 WorkBuddy 的进程。经过这三步绝大多数 502 write eacces 都能解决。注意如果你运行的是 Linux 版本还要考虑 SELinux 或 AppArmor 对进程访问的限制这类强制访问控制往往不会在普通权限排查中显示出来需要额外检查。5.2 文件操作“看着执行了但实际没变化”路径误区另一个让我困惑过的问题是它对我说“已完成”但我去看目标文件夹发现文件根本没动。后来我才发现问题出在“逻辑路径”和“实际路径”不一致。比如在 macOS 上用户目录的中文名可能跟英文路径有别名映射关系在 Windows 上如果工作目录用了网络映射盘MCP 解析到的路径可能跟你资源管理器里看到的不一致。还有一个常见误区是符号链接。如果你的工作目录里存在符号链接指向了工作目录之外的位置WorkBuddy 操作这个链接时实际上是在操作链接指向的目录而这个目录可能不在白名单内。这样一来操作要么被拒绝要么执行结果跟预期不一样。我的建议是工作目录里尽量少放符号链接或者明确告诉 AI“符号链接目标视为工作目录的一部分”。排查办法很简单让 AI 先把“当前目录结构树”列出来你比对一下它看到的路径和你看到的路径是否一致。如果不一致手动调整配置中的工作目录路径直到完全对齐再继续操作。另一招是直接在对话里问它“你刚才把文件移到了哪里”它能给出它自己的完整操作日志对着日志找文件位置是最快的。5.3 中文文件名和特殊字符编码处理建议如果你跟我一样主要在中文环境使用那必须说说中文文件名的问题。大部分情况下 WorkBuddy 能正确读写中文文件名但偶尔会出现乱码尤其是文件名里有全角括号、中文空格或特殊符号如、【】、的时候。这种问题出现的根源是不同工具对文件名的编码处理不一致——模型内部处理的是 Unicode但底层的某些脚本库可能默认使用了其它编码。我摸索出的一个非常实用的规避方法在批量重命名时尽量让 AI 把目标文件名改为【英文字母、数字和下划线】的组合避免特殊字符。如果必须保留中文名也可以让它用中文但文件名里不要带全角空格、全角括号这类容易出问题的字符。这个做法能省去大量排查乱码的时间。如果已经出现了乱码文件名不要慌最常见的修复方式是用系统自带的文件管理器手动重命名一次或者让 WorkBuddy 读取该文件名的 Unicode 码点再用十六进制方式重建文件名。虽然不是每次都能完全恢复但对绝大多数场景足够用了。5.4 排查问题速查表最后我把实践中遇到的高频问题汇总成一张速查表方便你以后对照排查。问题现象可能原因快速处理方案写入文件时报 write eacces进程无写入权限检查目录权限、换到用户可写目录、关闭杀毒拦截AI 说执行完成但文件没变化逻辑路径与实际路径不一致让它列出目录树比对路径并修正配置中文文件名显示乱码编码不一致 / 特殊字符重命名为纯英文数字组合避免全角符号502 错误上游模型服务不可用 / 权限失败检查网络和 API Key再查看错误码具体含义文件被误删自然语言指令歧义开启确认模式或备份后再执行同步盘文件读取失败文件未完全同步到本地先强制完全同步再让 AI 操作这张表只是入口实际使用时我建议你养成一个习惯开启任务日志功能。WorkBuddy 每次操作都会生成一份结构化日志包含调用的工具、参数、返回结果。遇到问题先看日志比凭空猜测高效得多。6. 从工具到习惯我对 WorkBuddy 的实战体会用了几周之后我现在很少把 WorkBuddy 当成“另一个 AI 聊天框”来用而是把它当成一套“能听懂人话的文件批处理系统”。这个定位的转变对我来说意义很大——以前我写一个 Python 脚本处理文件通常要花 10 分钟写代码、调试、处理边界情况现在用自然语言描述需求它 1 分钟就能跑完虽然偶尔会有小偏差但整体收益非常可观。我个人的核心体会是用好 WorkBuddy 的关键不在于背熟它的功能列表而在于你愿意花多少心思去拆解自己的需求。一条指令写清楚“范围 动作 过滤条件 输出要求”它基本上就能按要求完成如果你连自己都不知道想要什么结果AI 再强大也无从下手。这种“先想清楚再吩咐”的思维方式本身就是 AI 时代很重要的生产力习惯。另外一个我越来越依赖的功能是它和 Obsidian 知识库的联动。我把工作日志、项目笔记放在 Obsidian 里通过 WorkBuddy 的自定义指令批量整理标签、建立索引、生成每日回顾相当于给知识库配备了一个私人整理助手。我甚至试过让它根据笔记内容自动生成“今日待办”效果超出预期。这就是我计划在后续手记里详细展开的方向WorkBuddy 与知识管理系统的深度整合。最后分享一个小技巧如果你希望 AI 整理文件更聪明可以在工作目录里放一个 README.md用自然语言描述这个目录的命名规则和归档策略。WorkBuddy 在执行任务时能主动读取这个文件并遵循里面的约定相当于给 AI 一本“现场操作手册”。这个做法不需要写任何代码但能显著提升操作的一致性。下一篇手记我打算写一写 WorkBuddy 的 Skill 脚本实战包括如何编写一个定时整理脚本、如何让它在后台自动监听文件变化。如果你在实操中遇到了别的坑也欢迎在评论区留言我这边已经踩过的坑都会一一整理出来。