让 WorkBuddy 稳定交付：从工作文件夹、Skills 到验收流程

WorkBuddy 工作体系架构：资料、执行、验证与交付

让 AI 完成一次任务并不难，难的是下一周、换一份材料、开启一个新会话，它仍然能交付可靠的结果。

Lauren Tan（@poteto）关于智能体工作流的分享给了我一个很有价值的启发：每次纠正 AI，都应该思考能否把这次经验落实到环境、工具或检查机制里，让下一次更不容易出错。本文基于该分享，结合 WorkBuddy 官方文档，把这一思路整理成一套面向日常办公的工作流程。

这是一套可实施的起步方案，实际落地，需要根据具体场景使用 WorkBuddy 进行验证，构建自动化系统。目标是减少重复返工，让结果更容易检查。

一、先建立闭环，再扩大自动执行

建议从一种高频工作开始，例如每周业务报告：

明确任务 → 检查输入 → 制作成果 → 实际验证 → 修订复查 → 人工验收 → 更新流程。

WorkBuddy 从任务到交付：验证、修订与人工验收

图：硬性检查通过后进入人工验收；失败项修订后复查，缺少检查证据时先补验。

衡量效果时，重点看人工返工时间、重大错误数量、未检查项目和每份合格成果的成本。输出文件越来越多，并不必然意味着工作完成得更好。

WorkBuddy 官方介绍列出了本地文件操作、文档与表格处理、Skills 扩展和 MCP 接入等能力。这些提供了流程落地的基础，但可靠性仍取决于具体任务中的资料、口径、工具和检查方法。

二、用文件夹建立清楚的工作环境

建议每类长期工作使用一个根目录，每次执行使用一个独立任务目录：

WorkBuddy工作台/
├── 00-规范/
│   ├── 工作地图.md
│   ├── 指标口径.md
│   └── 改进记录.md
├── 01-模板/
│   ├── 周报模板.md
│   └── 验收记录.md
├── 02-任务/
│   └── 2026-11-05-业务周报/
│       ├── 任务卡.md
│       ├── 输入/
│       ├── 过程/
│       ├── 交付/
│       └── 验收/
├── 03-归档/
└── skills/
    └── weekly-business-report/
        ├── SKILL.md
        └── references/
            └── acceptance.md

这些目录是工作约定，不是 WorkBuddy 的保留目录，也不自动提供只读权限。

“输入”保留原始资料；清洗数据、计算文件和中间稿写入“过程”；最终成果写入“交付”；检查记录、计算对照和页面预览放入“验收”。修改后的成果使用 v01、v02 等版本号，便于将检查证据对应到具体文件。

“工作地图”负责说明哪些材料有效、分别有什么用途、应该先读什么。例如：

当前任务以任务卡指定的输入文件为准。
指标定义见 00-规范/指标口径.md。
报告结构参考 01-模板/周报模板.md。
原始数据保留，清洗结果另存过程目录。
归档只在需要历史对比时读取，不作为默认模板。
任务卡与指标口径发生关键冲突时，列出冲突并确认。

不要把多个“最终版”同时留在默认参考范围。智能体会模仿它看到的内容，旧口径和临时补丁也可能被一起复制。

文件存在不代表新会话一定会读取。启动任务时，应明确指定工作根目录、任务目录以及必读文件；如果使用项目功能，也可以把这类入口约定放进项目指令。

三、用任务卡把需求变成可验收的约定

与其只说“帮我分析本周销售情况”，不如先写清楚：

涉及金额时，必须明确输入单位、输出单位、币种和舍入规则。缺失值不能自动当作零。没有上期数据就不能编造环比；上期为零时，也不应直接输出一个普通百分比。

允许误差应依据业务口径设定。逐笔舍入后求和，与先求和再舍入可能有差异，不能对所有任务统一套用“误差小于 0.01”。

四、技能要写清做法，也要写清验证方法

适合沉淀成 Skill 的，是反复出现的工作方法。每次变动的统计日期、文件名称和目标读者应放在任务卡里。

一个实用技能需要说明：什么时候使用、去哪里读资料、如何处理、如何检查、缺项怎么办、什么才算完成。以下是可以改写使用的最小示例：

---
name: weekly-business-report
description: 根据任务卡、业务口径和指定数据制作业务周报，交付报告、来源索引和验收记录。适用于重复周报任务。
---

# 业务周报制作与验收

## 输入
从用户指定的工作根目录读取工作地图、指标口径和本次任务卡。
只使用任务指定的资料；示例和历史报告只能作为结构参考。
关键路径不明确时先定位，不能唯一确定时询问用户。

## 执行
1. 说明实际读到的任务目标、输入文件和关键缺项。
2. 检查时间覆盖、字段、单位、重复与缺失值。
3. 将清洗和计算结果写入本任务的过程目录，保留输入原件。
4. 按模板制作报告，关键数字和外部事实标注证据编号。
5. 从源数据用独立汇总或另一种计算方式复核核心指标。
6. 按 references/acceptance.md 检查，修订后复查受影响项。
7. 交付报告、来源索引、验收记录及未解决问题。

## 异常处理
影响统计期间、金额单位或核心定义的缺项，先确认受影响部分。
普通缺项记录后，继续不受影响的工作。
同一问题两轮修订仍未解决，保留草稿和证据，说明阻碍。

## 完成条件
检查状态包括通过、失败、未检查、待人工判断、不适用。
工具不可用时标记未检查，不能声称验证通过。
全部适用硬性项通过后，标记待人工验收。
用户实际确认人工项后，才能记录已验收。

在配套的 references/acceptance.md 中写入下一节的验收清单。只有 SKILL.md，却没有它引用的文件，会留下执行缺口。

根据官方文档，可以在技能板块选择“添加技能 → 上传技能”导入本地技能包，也可以通过对话创建自定义技能。导入后应检查已安装列表和启用状态。仅把文件放在自定义的 skills 文件夹里，不应假定它已经安装成功。

五、验收必须留下可复查的证据

“我已经认真检查过了”不够。每项检查应记录预期结果、实际结果、检查方法和证据位置。

检查状态要区分清楚：

• 通过：已实际检查，并有证据支持。
• 失败：已检查，结果不符合要求。
• 未检查：没有执行，或工具能力不足。
• 待人工判断：需要业务、审美或语境判断。
• 不适用：当前任务无需此项，并说明理由。

只检查“文件存在”，不能证明文件可用；检查程序运行成功，也不能证明它没有覆盖的业务结论正确。

报告中的“销售额下降了多少”可以通过数据复算。“下降是不是某次营销活动导致的”往往还需要更多证据。“建议是否值得执行”则需要业务判断。不要把这三件事混成一个通过勾选框。

对于不同成果，可以增加针对性的检查：

• 调研报告：核对来源、发布日期和适用范围，区分事实与分析。
• 表格：实际重算，检查公式错误、合计、单位、重复键和缺失处理。
• PPT：逐页检查排版和图表可读性，核对关键数字，人工评审叙事。

这些检查依赖实际环境中的工具。无法渲染时应保留“未检查”，不能用文字推测替代页面检查。所有证据都应对应当前交付版本；成果修改后，重新检查受影响部分。

六、第一次运行可以这样下指令

创建好文件夹、填写任务卡并放入真实材料后，可以使用下面的启动指令：

请使用 weekly-business-report 技能，处理我选择的工作根目录中的本次业务周报任务。 先读取工作地图、指标口径和任务卡，简要说明实际读到的任务目标、输入文件名称和关键缺项，再开始执行。 普通缺项记录后继续不受影响的工作；影响统计期间、金额单位或核心定义的缺项，先向我确认。 请交付报告、来源索引和验收记录。关键数字从源数据复算，检查记录包含实际结果和证据位置。没有执行的检查标记未检查，业务判断标记待人工判断。 原始材料保持不变，中间结果放过程目录，成果放交付目录，检查证据放验收目录。

先跑通一次，再看哪些环节最需要改进。无需一开始就安装大量技能或安排很多并行任务。

七、让每次返工减少下一次出错的机会

发生重复错误时，优先检查数据结构、模板和验证方法，再补充技能文字。

改进记录可以只保留六项：发生了什么、影响是什么、原因是否已验证、修改了哪里、用什么失败例重试、以后是否复发。

不要把所有个别问题都追加成全局规则。优先修正原有规则，删除冲突或过时内容。技能源文件修改后，还应更新已安装副本，并在新会话中核对是否生效。

最后要分清两个层次：写在技能中的文字是行为引导；真正的硬约束需要检查程序或工作系统执行，并在条件不满足时阻止进入下一步。办公场景中的很多检查仍然需要工具与人共同完成。

先让一种重复工作稳定下来，再逐步扩大自动执行范围。理想的变化是：你越来越少重复纠正同一种问题，而每次交付都能清楚说明做了什么、依据是什么、哪些已经验证、哪些仍需判断。