I/O 2026 发了 100 条，我还是把 WorkBuddy 的模板写死

刷完 Google I/O 2026 那一百条公告，我有点手痒。Gemini 3.5、Antigravity 2.0、Chrome DevTools for agents，方向都指向同一件事，让 agent 自己看、自己调、自己规划。听着挺猛。

I/O 上有个东西叫 Modern Web Guidance，官方说法是 expert-vetted skills，专家审过的技能。翻译成人话就是，别让模型现场发挥。

我用了 WorkBuddy 大约 1 个月，越用越确定，办公场景里 agent 的自主规划不是第一步，素材入口才是。输入没收干净，模型越强，越会一本正经地读错文件。

先说问题。我们是后端，需求变更散在飞书文档的评论、邮件、还有群里的截图。之前手动整理一份变更台账，一次大概四十分钟，还容易漏。

我试过让 WorkBuddy 自己看着办，把项目目录整个丢进去，只写一句“整理本周需求变更”。结果它转了一圈，把客户合同里的条款也读进去了，输出表里混了几条不该出现的行。问题出在我没框边界。

后来我把顺序改了，先收素材，再跑任务。

先在本地建一个专用目录，比如 D:\wb-inbox\changelog，只往里放允许它看的文件，其余一律不放。这个目录就是个素材池。打开 WorkBuddy，新建任务，模式选 Craft。这里解释一下，Craft 是它的执行模式，会真的读写文件；另有 Ask 模式只回答不动文件，Plan 只出步骤不落盘。新手最容易在这儿混用，我第一周就踩过，选 Plan 写完描述，等了半天只有一份步骤清单，文件一个没动。

任务描述我写成固定一段，不带任何形容词。读取 D:\wb-inbox\changelog 下所有文件，提取需求编号、提出人、变更内容、影响模块、提出日期，输出 xlsx 到 D:\wb-out，表头固定为这五列，缺字段留空，不要推断。

关键在最后四个字。你不写，它就会自己补，补出来的东西看着合理，其实全是幻觉。这一句是我从一次跑偏里换来的。但它只保证输出格式稳，台账能比对，靠的是前面那个只进干净文件的目录。

输出的 xlsx 放在共享盘一个固定目录。权限上我只开了两个可写，我和测试那边的接口人，其他人只读。模板文件单独存一份，只有我能改。这个分工很重要，模板一旦被第二个人动过，下次跑出来的表头就不一致，历史数据没法比。之前我觉得这套限制有点过度，现在想法变了，权限收得越紧，越省事。

运维上我固定每周五下午跑一次。跑之前先清空 inbox，跑完把输出文件重命名成 changelog-20260919.xlsx 这种带日期的格式，模板版本号写在文件名末尾。模板要改就新建一个版本，别直接覆盖，先拿历史数据跑一遍比对，对得上再切。

还有个坑。WorkBuddy 处理 xlsx 时对合并单元格不太友好，我一开始的输出模板带了合并表头，读回来全是空值。后来改成一行纯表头，问题就没了。这是 xlsx 的老毛病，跟工具本身关系不大，但第一次遇到会很懵。

我的环境是 Windows 本地文件加共享盘，飞书那边只是素材来源，不一定适用所有人。如果你是全云端的协作流程，权限那套得重新设计。

趋势我看很简单，I/O 那一百条里真正能落到日常办公的没几条，但 agent 只会越来越多，它们会越来越会规划，也会越来越敢猜。与其追每一条公告，不如先把素材入口收成可枚举、可复现的一小撮文件。模型会换，目录不会。