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, encodingutf-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, encodingutf-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 把周报自动化扩展到月报和季报周报跑通后月报和季报就是顺带的事。月报的指令是“读取本月所有周报按任务汇总输出月报”季报同理。数据源一样只是汇总粒度不同。我现在的节奏是周五自动生成周报月底自动生成月报季末自动生成季报。整个人从重复劳动里解放出来精力都放在真正需要判断的事情上。这套流程跑了大半年稳定性很好偶尔出点小问题按前面的排查表处理就行。最后分享一个小心得自动化的价值不在于省了多少时间而在于让这件事变得不消耗意志力。以前每到周五下午我就犯怵现在周报自动生成我只需要花五分钟过一遍。这种心理负担的减轻比省下来的那几十分钟值钱多了。