1. 为什么我要把周报这件事彻底交给 WorkBuddy
每周五下午三点，我都要干一件极其消耗意志力的事：翻聊天记录、翻会议文档、翻任务看板，把散落在七八个地方的信息拼成一份团队周报。这件事我干了三年，每次耗时四十分钟到一个小时，写完还总觉得漏了什么。直到我把 WorkBuddy 接进工作流，整个链路才真正跑通——一周的任务变更、三场会议的纪要，自动收成一份结构清晰的团队周报，我只需要最后过一遍。
WorkBuddy 在这套流程里扮演的角色，可以理解成一个云端助理：它不替你开会，也不替你写代码，但它能把你在各个工具里留下的痕迹收集起来，按你定义的规则整理成文。核心关键词就三个——WorkBuddy、云端助理、周报、自动化。这篇文章面向的是每周需要产出团队周报的人，不管你是技术负责人、项目经理还是普通团队成员，只要你有“信息散落、汇总靠手”的痛点，这套方案都能直接抄。
我先把结论摆出来：这套方案的本质不是让 AI 替你写周报，而是把“信息采集”和“格式整理”这两步自动化，把人的精力留给“判断哪些事值得写进去”这个真正需要脑子的环节。很多人对自动化的误解就在这儿，以为一键生成就完事了，实际上自动化解决的是重复劳动，不是判断劳动。想清楚这一点，后面的配置思路就顺了。
2. 整体方案设计与工具选型思路
2.1 周报自动化的核心链路拆解
一份团队周报的信息来源，拆开来看无非四类：任务系统的状态变更、会议纪要里的决策和待办、聊天工具里的关键讨论、以及个人补充的备注。这四类信息的结构化程度完全不同——任务系统本身就是结构化的，会议纪要半结构化，聊天记录几乎是非结构化的。所以自动化方案不能一刀切，得按信息类型分层处理。
我的设计思路是这样的：任务数据走接口拉取，会议纪要走文档解析，聊天记录走关键词提取，最后统一交给 WorkBuddy 做汇总和格式化。WorkBuddy 在这里承担的是“汇总层”的角色，它不直接去连你的任务系统，而是接收前面几步处理好的中间数据，按模板生成周报。这样设计的好处是解耦——哪天你换了任务管理工具，只需要改采集层，汇总层不用动。
为什么不让 WorkBuddy 直接连所有数据源？因为实际用下来，直接连的问题在于权限和稳定性。任务系统的接口权限往往需要单独申请，会议文档的格式各家不一样，聊天工具的数据导出更麻烦。分层之后，每一层可以用最适合的工具处理，WorkBuddy 只负责它最擅长的事：把结构化数据按规则组装成自然语言。
2.2 为什么选 WorkBuddy 而不是自己写脚本
我一开始确实想过自己写个 Python 脚本，拉数据、拼字符串、生成 Markdown。写是能写，但维护成本高得离谱。任务系统的接口字段一改，脚本就挂；会议纪要的格式一变，解析逻辑就得重写。更麻烦的是，周报的措辞和结构经常要调整，每次调整都得改代码，改完还得测试。
WorkBuddy 的价值在于它把“规则配置”和“代码实现”分开了。我用自然语言描述周报的结构和措辞要求，它来执行。想调整格式，改指令就行，不用碰代码。这一点在自定义指令功能上体现得特别明显——你可以把周报的模板、语气、分段规则写成一段指令，WorkBuddy 每次按这个指令生成，风格稳定。
另外，WorkBuddy 的云端助理属性意味着它不依赖你本地电脑开着。我试过周五下午在外面开会，手机上看一眼生成的周报草稿，改两处措辞就发出去了。这种灵活性是本地脚本给不了的。
2.3 三场会议纪要的采集策略
一周三场会议，通常是周一的规划会、周三的同步会、周五的复盘会。这三场会议的纪要来源可能不一样：有的在在线文档里，有的在会议工具的自动转录里，有的就是我自己记的笔记。采集策略得区分对待。
在线文档类的纪要，我统一导出成 Markdown 格式，放到一个固定目录。会议工具自动转录的，导出成纯文本，同样放固定目录。我自己记的笔记，用统一的模板记，保证结构一致。这三类文件汇总到一个“会议纪要”文件夹，WorkBuddy 按文件名里的日期排序读取。
这里有个关键细节：会议纪要里真正对周报有用的，是决策和待办，不是讨论过程。所以我在指令里明确要求 WorkBuddy 只提取“决定了什么”和“谁要做什么”，讨论细节一律略过。这个过滤规则如果不写清楚，生成的周报会又臭又长，没人看。
3. 核心配置细节与实操要点
3.1 WorkBuddy 自定义指令的写法
自定义指令是这套方案的核心。我前后改了七八版，才找到比较稳定的写法。指令的结构分三块：角色定义、数据来源说明、输出格式要求。
角色定义部分，我写的是“你是一个团队周报生成助理，负责把任务数据和会议纪要整理成简洁的周报”。这句话看着简单，但它决定了 WorkBuddy 的语气和详略程度。如果不写，它可能会生成一篇很啰嗦的报告。
数据来源说明部分，要明确告诉它去哪里读数据、按什么顺序读、遇到缺失怎么处理。比如“任务数据从 tasks.md 读取，会议纪要按日期顺序读取 meetings 目录下的文件，如果某天没有纪要则跳过”。
输出格式要求部分，我用了固定的模板：
## 本周完成 - [任务名]：[状态] [负责人] ## 进行中 - [任务名]：[进度] [负责人] ## 下周计划 - [任务名]：[计划] [负责人] ## 会议决策 - [决策内容]（来源：[会议日期]）这个模板不是拍脑袋定的，是试出来的。最早我用的是纯段落式，结果每次生成的格式都不一样，还得手动调。改成固定模板后，输出稳定多了。
提示：自定义指令里一定要写“如果数据缺失，标注‘待补充’而不是编造”。我踩过这个坑，有一次任务数据没拉全，WorkBuddy 自己脑补了几条不存在的任务，差点闹笑话。
3.2 任务数据的采集与清洗
任务数据我从任务管理系统的接口拉，拉下来是 JSON 格式。直接丢给 WorkBuddy 不行，字段太多太杂，它会被干扰。所以我先做一步清洗：只保留任务名、状态、负责人、截止日期四个字段，转成 Markdown 表格。
清洗这一步我用的是简单的脚本，逻辑不复杂：读 JSON，遍历每个任务，按状态分组，输出表格。这里的关键是状态映射——任务系统里的状态可能是“in progress”“doing”“进行中”各种写法，得统一映射成“进行中”“已完成”“待开始”三类。映射表我放在脚本里，改起来方便。
清洗后的数据长这样：
| 任务名 | 状态 | 负责人 | 截止日期 |
|---|---|---|---|
| 登录模块重构 | 已完成 | 张三 | 03-15 |
| 支付接口联调 | 进行中 | 李四 | 03-20 |
| 性能测试方案 | 待开始 | 王五 | 03-25 |
这个表格直接喂给 WorkBuddy，它就能按模板生成周报的“本周完成”和“进行中”部分。
3.3 会议纪要的提取规则
会议纪要的提取比任务数据麻烦，因为它是非结构化的。我的做法是给会议纪要定一个半结构化模板，每次记录时按这个模板来：
## 会议主题 ## 参会人 ## 决策事项 - 决策1 - 决策2 ## 待办事项 - [ ] 待办1 @负责人 - [ ] 待办2 @负责人有了这个模板，WorkBuddy 提取起来就简单了——它只需要找“决策事项”和“待办事项”两个标题下的内容。如果会议是别人记录的，格式不统一，我会先手动整理成这个模板，再放进 meetings 目录。这一步手动整理大概花五分钟，但换来的是后续全自动，值。
注意：待办事项的负责人一定要用 @ 标注，WorkBuddy 靠这个符号识别负责人。不标的话，它会把整条待办当成一句话，分不清谁负责。
3.4 触发时机与运行频率
这套流程我设的是每周五下午两点自动跑一次。为什么是两点而不是五点？因为两点跑完，我还有时间在三点前过一遍、改几处，然后发出去。如果设成五点，万一生成有问题，就来不及改了。
触发方式我用的是定时任务，WorkBuddy 支持按 cron 表达式配置。我的配置是0 14 * * 5，意思是每周五 14:00 执行。执行内容就是读取 tasks.md 和 meetings 目录，按指令生成周报，输出到 weekly-report.md。
如果你不想用定时，也可以手动触发。我有时候周三想看看进度，就手动跑一次，生成一份“中期版”周报，看看这周完成了多少。这个用法是意外发现的，但挺实用。
4. 完整实操流程与关键环节实现
4.1 环境准备与 WorkBuddy 接入
先把 WorkBuddy 接进来。我用的是网页版，登录后在“工作台”里新建一个助理，命名成“周报助理”。然后在助理设置里找到“自定义指令”，把前面写好的指令粘进去。
接入过程中有几个配置项要注意：
- 数据目录：指定 WorkBuddy 能读取的目录范围。我把 tasks.md 和 meetings 目录放在一个专门的“周报数据”文件夹里，只把这个文件夹的读取权限给 WorkBuddy，避免它读到无关文件。
- 输出目录：指定周报生成后存哪里。我设的是同一个文件夹下的 weekly-report.md，方便查看。
- 缓存目录：WorkBuddy 默认的缓存目录在系统盘，我改到了 D 盘，因为缓存文件有时候挺大，放系统盘占空间。改的方法是在设置里找到“缓存路径”，手动指定一个新目录。
提示：缓存目录改到 D 盘后，第一次运行会重新建缓存，速度会慢一点，之后就正常了。别以为改坏了。
4.2 任务数据脚本的编写与调试
任务数据清洗脚本我用 Python 写，逻辑不复杂，但有几个细节要注意。先看代码：
import json STATUS_MAP = { "done": "已完成", "in progress": "进行中", "doing": "进行中", "todo": "待开始", "backlog": "待开始" } def clean_tasks(raw_json_path, output_path): with open(raw_json_path, "r", encoding="utf-8") as f: tasks = json.load(f) rows = [] for task in tasks: name = task.get("title", "未命名任务") status = STATUS_MAP.get(task.get("status", "").lower(), "未知") owner = task.get("assignee", {}).get("name", "未分配") due = task.get("due_date", "无截止日期") rows.append(f"| {name} | {status} | {owner} | {due} |") header = "| 任务名 | 状态 | 负责人 | 截止日期 |\n|--------|------|--------|----------|\n" with open(output_path, "w", encoding="utf-8") as f: f.write(header + "\n".join(rows)) if __name__ == "__main__": clean_tasks("raw_tasks.json", "tasks.md")这段代码的关键在STATUS_MAP，它把各种状态写法统一成三类。我一开始没做映射，结果周报里出现了“in progress”“doing”“进行中”三种写法，看起来特别乱。加上映射后，输出干净多了。
调试的时候，我建议先拿几条假数据跑一遍，确认输出格式对，再接真实数据。真实数据往往有缺失字段，比如有的任务没有负责人，有的没有截止日期，代码里得做兜底处理，不然会报错。
4.3 会议纪要的整理与归档
会议纪要的整理我定了个规矩：每场会议结束后半小时内，把纪要整理成模板格式，存到 meetings 目录，文件名用YYYY-MM-DD-会议主题.md。这个命名规则很重要，WorkBuddy 靠文件名里的日期排序，日期格式不对会乱序。
整理的时候，我只记三样东西：决策、待办、关键数据。讨论过程一律不记，因为周报不需要。这个习惯养成后，整理一场会议的纪要大概花三到五分钟，比以前记流水账快多了。
归档后，meetings 目录大概长这样：
meetings/ 2024-03-11-周会.md 2024-03-13-同步会.md 2024-03-15-复盘会.mdWorkBuddy 按文件名排序读取，顺序不会乱。
4.4 周报生成与人工润色
前面几步准备好后，周报生成就是一句话的事：触发 WorkBuddy，等它输出。生成时间大概十几秒，取决于数据量。
生成的周报草稿我会过一遍，主要看三处：任务状态对不对、会议决策有没有漏、措辞顺不顺。任务状态一般没问题，因为是从接口拉的；会议决策偶尔会漏，因为纪要格式不统一；措辞需要微调，因为 WorkBuddy 有时候会用比较生硬的表达。
润色这一步我控制在五分钟以内，只改必要的，不追求完美。毕竟周报的目的是同步信息，不是写作文。
注意：润色时如果发现某条任务状态不对，别直接改周报，去改任务系统里的状态，然后重新生成。这样保证周报和任务系统一致，避免两边对不上。
5. 常见问题与排查技巧实录
5.1 生成内容遗漏或错位
最常见的问题是会议决策漏了，或者任务状态错位。排查思路是这样的：先看原始数据对不对，再看 WorkBuddy 的读取顺序对不对，最后看指令里的提取规则有没有问题。
有一次周报里少了一条重要决策，我查了半天，发现是那场会议的纪要文件名日期写错了，导致排序时排到了最后，WorkBuddy 读取时可能截断了。改文件名后就好了。所以文件名规范这件事，看着小，实际影响很大。
任务状态错位通常是映射表没覆盖到新状态。比如任务系统新增了一个“blocked”状态，映射表里没有，就会显示“未知”。解决办法是定期检查映射表，把新状态加进去。
5.2 格式不统一的问题
格式不统一的表现是：有时候周报用列表，有时候用表格，有时候分段。原因是自定义指令里的格式要求不够明确。我的解决办法是把模板写死，明确要求“必须按以下模板输出，不得更改格式”。
如果还是不稳定，可以在指令里加一句“输出前先检查格式是否符合模板，不符合则重新生成”。这句话能明显提升格式稳定性。
5.3 数据权限与读取失败
读取失败通常是权限问题。WorkBuddy 只能读你授权目录下的文件，如果文件放在授权目录外，就会读不到。排查时先确认文件路径在授权范围内，再确认文件编码是 UTF-8，最后确认文件没有被其他程序占用。
编码问题我遇到过，有一次会议纪要用 GBK 编码保存，WorkBuddy 读出来是乱码。统一改成 UTF-8 后就正常了。所以所有数据文件统一用 UTF-8 编码，这个规矩得定死。
5.4 常见问题速查表
| 问题现象 | 可能原因 | 解决办法 |
|---|---|---|
| 会议决策遗漏 | 纪要文件名日期错误 | 检查文件名日期格式 |
| 任务状态显示“未知” | 状态映射表未覆盖 | 补充映射表 |
| 格式不统一 | 指令格式要求不明确 | 写死模板并加检查语句 |
| 读取失败 | 文件不在授权目录 | 移动文件到授权目录 |
| 输出乱码 | 文件编码非 UTF-8 | 统一转成 UTF-8 |
| 生成速度慢 | 缓存目录在系统盘 | 改缓存目录到其他盘 |
5.5 几个我踩过的坑
第一个坑是指令写得太笼统。最早我写的是“帮我生成周报”，结果 WorkBuddy 生成的内容完全没法用。后来改成详细的角色、数据源、格式三块，才稳定下来。指令这东西，越具体越好。
第二个坑是数据没清洗直接喂。任务接口返回的 JSON 字段特别多，直接喂给 WorkBuddy，它会抓错重点。清洗后只留四个字段，输出质量明显提升。
第三个坑是忘了设兜底。有一次任务数据里有个任务没有负责人，脚本直接报错，整个流程断了。后来加了兜底逻辑，缺失字段用“未分配”“无截止日期”代替，流程就稳了。
6. 进阶玩法与效率提升技巧
6.1 用 Skill 扩展周报能力
WorkBuddy 的 Skill 功能可以让周报助理具备更多能力。我加了一个“数据校验”Skill，每次生成周报前先检查任务数据和会议纪要是否完整，不完整就提醒我补充。这个 Skill 帮我避免了好几次“周报发出去了才发现漏了数据”的尴尬。
另一个实用的 Skill 是“格式转换”，把生成的 Markdown 周报转成适合邮件发送的 HTML 格式。这样我不用手动转，直接复制粘贴就能发。
6.2 多项目周报的合并策略
如果你同时负责多个项目，可以给每个项目建一个数据目录，分别生成周报，最后用一个“合并”指令把几份周报拼成一份。合并时注意去重，同一个任务在多个项目里出现的话，只保留一次。
合并指令我写的是“读取所有项目周报，按项目分组，合并相同任务，输出总周报”。这个指令跑下来，多项目周报的生成时间从半小时压缩到两分钟。
6.3 周报数据的长期归档与检索
周报生成后别删，存到一个归档目录，按年份和月份分文件夹。时间长了，这些周报就是团队的工作记录，查历史决策特别方便。我现在的归档目录里存了两年多的周报，有时候查“某个功能是什么时候上线的”，翻周报比翻聊天记录快多了。
归档时我还会生成一个索引文件，记录每份周报的日期和关键词，方便检索。这个索引也是 WorkBuddy 生成的，指令是“读取归档目录下所有周报，提取日期和主要任务，生成索引表格”。
6.4 把周报自动化扩展到月报和季报
周报跑通后，月报和季报就是顺带的事。月报的指令是“读取本月所有周报，按任务汇总，输出月报”，季报同理。数据源一样，只是汇总粒度不同。
我现在的节奏是：周五自动生成周报，月底自动生成月报，季末自动生成季报。整个人从重复劳动里解放出来，精力都放在真正需要判断的事情上。这套流程跑了大半年，稳定性很好，偶尔出点小问题，按前面的排查表处理就行。
最后分享一个小心得：自动化的价值不在于省了多少时间，而在于让这件事变得不消耗意志力。以前每到周五下午我就犯怵，现在周报自动生成，我只需要花五分钟过一遍。这种心理负担的减轻，比省下来的那几十分钟值钱多了。
