用WorkBuddy搭建周报自动化流水线，把3天压缩到4小时

先说结论：这条周报流水线，我用了大概三周搭完，又磨合了两期，才敢说它稳定。以前我每次做统计周报，从收集各科室上报的 Excel、清洗异常值、核对同比环比，再到组织语言写分析段落、按单位模板排版，正经要花差不多三天。现在跑一遍只要四个小时，其中大部分时间还是花在数据校验和格式微调上。工具是 WorkBuddy，但这个改观不是某个“神奇按钮”白送的，而是把流程拆对、知识库喂对、提示词写对之后的结果。下面把这套方案和踩过的坑完整写出来，给同样被重复性报表压着的朋友一个参考。

1. 先说说原来的周报流程：不是不想改，是真不好改

1.1 一条周报背后到底有多少工序

很多没做过统计类材料的人以为，周报就是把几个数字填进表格，再写几句话。实际完全不是这样。

我拿到手的原始材料通常包括：各科室按固定模板填的 Excel 表、业务系统导出的 CSV、上期周报的 PDF、还有口头汇报里提到的临时数据。这些材料的格式常年不统一，同一字段在不同表格里可能叫“完成数”“实际完成”“累计数”，日期格式有 20250106 也有 2025-01-06。我需要先把这些数据人工对齐到一个底表里，再核对历史数据算出同比、环比，然后按照固定的叙述套路写“总体情况、分项进展、存在问题、下一步安排”四段内容，最后套进红头模板。

这三天的时间分布大概是：一天用来收数据、开各种文件、转格式、手动对齐；半天用来核对异常数字，比如某单位数字明显翻倍、某项指标负增长但原因没写；还有一天多用来写文字、调格式、反复改样式。真正“写东西”这件事反而不耗时，耗时的是数据准备和格式还原。

这个工作难吗？单看每一步都不难，但每一步都很碎，很容易打断人的状态。我试过把流程写进操作手册交给别人接手，结果每期还是会因为数据口径、模板版本、特殊备注之类的问题卡住。这也是为什么我后来一直想找一种方案，能把这些零碎动作串成一条自动化的线。

1.2 以前尝试过的三种自动化思路和失败原因

在 WorkBuddy 之前，我试过三类方案，各有各的坑。

第一类是写 Python 脚本做数据清洗和报表生成。问题很明显：统计口径经常变，Excel 表头这个月和下个月就可能不一样，脚本写好没多久就要改正则、改映射关系；而且领导对文字部分的要求不是固定模板能覆盖的，脚本只能生成“填空式”的文本，分析味太淡。

第二类是用传统 RPA 模拟手工操作，录鼠标键盘动作。刚开始挺好用，但只要页面布局变一下、Excel 弹一个提示框，整个流程就断，维护成本极高，后期基本每天都在补异常分支。

第三类是直接用大模型对话，把材料丢进去让它写。这个方式最接近最终方案，但很快发现一个问题：聊天框没有“状态”，每次都要重新上传材料、重新描述背景、重新提醒格式规则。而且模型对数字的敏感度很差，四舍五入、单位换算、同比环比这些动作，它在闲聊模式下很容易算错，还特别自信。

所以我的结论是：必须有一个工具，能把“数据预处理 + 知识检索 + 生成文本 + 格式输出”这几个步骤固定下来，每一步可以单独调试，同时又保留大模型的灵活表达能力。这也是 WorkBuddy 能解决我问题的核心原因。

2. 为什么最终选了 WorkBuddy 而不是 Dify 或纯脚本

2.1 我要的是一个“能处理脏数据”的工作台，不是问答机器人

接触 WorkBuddy 之前，我同事先推荐了 Dify。Dify 做知识库问答、聊天应用确实很方便，但我的场景不是一个“问答机器人”，而是一条有明确输入、处理、输出约束的流水线。我需要把本周的 Excel 文件作为输入，经过多步处理，输出一份格式固定的 Word 文档。这个场景里，“流程”比“对话”重要，数据校验比生成文案重要。

WorkBuddy 给我的第一印象是它更像一个 Agent 工作台：我可以把不同环节拆成节点，节点之间有明确的数据传递关系。比如“读取上传文件”这个节点得到的结果，能作为变量传给“数据校验”节点；校验通过才进入“生成初稿”节点。这个机制让我能够把最不可控的大模型环节限制在特定区间内，而不是让它从头到尾自由发挥。

2.2 WorkBuddy 的几个关键能力对照

我实际用下来，对 WorkBuddy 的感受可以归纳成四点。

第一点是工作流编排能力。它能把“读取文件、解析表格、调用模型、渲染模板”这类步骤图形化连起来，单步失败可以看到具体报错。这对我这种要反复调整逻辑的人来说太重要了，不用每次从头跑。

第二点是知识库支持。我可以把过去一年的周报、常用统计口径说明、写作范式传进去，建立索引。生成阶段模型会先检索再回答，而不是空口写词。这一点保证了文本风格和术语用法的连续性。

第三点是比较灵活的模型接入方式。WorkBuddy 既支持调用 OpenAI 兼容接口，也支持本地模型部署。我实际测试过云端接口和本地模型，后面会详细说取舍。

第四点是 Skill 机制，类似一个可复用的“工具包”。我可以把数字校验规则、表格转置逻辑、单位换算这些功能封装成 Skill，在工作流里以特定方式调用。这比把全部逻辑塞给大模型要可靠得多。

2.3 我确定选型时的评估清单

这里顺便分享一下我当时的选择标准，未必全面，但比较实用。

• 是否支持在断网或内网环境部署？统计类数据比较敏感，不能完全依赖外网接口。
• 是否有明确的步骤编排界面？纯代码方案对非专业开发人员不够友好。
• 是否支持导入历史文档作为知识库？这决定生成内容的专业度。
• 是否能自定义提示词且在流程中复用？每期周报结构基本一致，提示词必须能保存和微调。
• 是否有清晰的日志和错误提示？流水线的价值就在于问题可定位。

对照这几点，WorkBuddy、Dify、n8n 这类工具各有侧重。Dify 长在知识库问答，n8n 长在系统集成，WorkBuddy 则更适合我这种“把文档处理 + 大模型生成 + 固定模板输出”揉在一起的场景。选择它的决定性因素是可以把知识库、Excel 解析、模型调用写进同一条工作流里。

3. 流水线设计：一步拆到位

3.1 我把周报拆成了四个子任务

在设计流水线之前，我先把原有的三天工作拆成最小步骤，最后归成四个大环节。

第一个环节是“取数”。把所有来源的 Excel、CSV、PDF 汇总后统一解析，转成标准结构。这个环节我明确要求模型不准做任何判断，只允许按既定的字段映射处理。

第二个环节是“校验”。检查必填项是否缺失、数值区间是否合理、同比环比是否能对上、单位是否正确。这个环节我不太依赖大模型，更多用规则脚本和计算公式。

第三个环节是“行文”。根据校验过的数字和历史知识库生成“总体情况、分项进展、存在问题、下一步安排”四段文字草稿。

第四个环节是“排版”。把生成的文字和原始数据表合并，套进单位要求的模板，输出 Word 文档。

四个环节之间层层传递，前一个环节产生的结果会作为后一个环节的输入。我刻意把大模型放在第三个环节，前后都用规则逻辑固定住，这样模型就算发挥离谱，也不会溢出到数据层和格式层。

3.2 知识库、自定义指令、Skill 到底怎么分工

这是整套方案里最值得琢磨的部分。很多人在用这类工具时容易把知识库、提示词、功能插件混在一起，其实边界很清楚。

知识库负责“知识”，解决的是模型不了解业务背景的问题。我导入了历史周报、统计工作手册、常用指标解释，让模型知道“固定资产投资”“社会消费品零售总额”这类词在我们单位代表什么口径，周报的固定叙述风格是什么样的。

自定义指令负责“行为规范”，解决的是模型输出不稳定问题。我在指令里明确写了“先回答问题，再给结论”“数据只引用用户提供或检索到的内容，不得自行计算”“总金额保留两位小数”这类约束。

Skill 负责“特定能力”，解决的是模型不擅长精确计算的问题。比如我写了一个“同比环比计算”Skill，不是让模型去算，而是让工作流调用封装好的函数去算，再把计算结果作为上下文传给模型。

简单说：知识库管“懂不懂”，指令管“怎么干”，Skill 管“干得准不准”。三者配合，才能把大模型的幻觉限制住。

3.3 数据流向和节点组织的实际顺序

整个工作流的节点顺序我调整过很多版，最终稳定下来的版本是：

• 第一组节点：上传文件解析。支持 Excel 和 CSV，统一表格结构，输出标准化数据集。
• 第二组节点：字段映射与清洗。把“完成数”“实际完成”这类别名映射到标准字段。
• 第三组节点：规则校验。检查空值、重复值、异常倍数、单位匹配，生成校验报告。
• 第四组节点：知识库检索。基于“本周数据 + 上周结论 + 本周关注点”检索历史周报相关段落。
• 第五组节点：模型生成。把校验报告、检索结果、自定义指令组合成完整上下文，生成四段初稿。
• 第六组节点：格式渲染。把初稿填入预设模板，转换为 Word。

前三个节点是纯规则和代码，后三个节点涉及模型。这种安排的意图是：数据清洗和校验能通过确定的逻辑完成；知识库检索和生成才利用模型的认知能力，避免模型在数值上做不可靠的推算。

4. 实操全记录：从空目录到第一条跑通的周报

4.1 安装、目录规划和 C 盘迁移

先讲一个最容易被忽略但非常影响体验的问题：WorkBuddy 默认会把运行产生的任务对话、缓存和历史记录放在用户目录下的 .workbuddy 文件夹里。如果安装盘是 C 盘且空间紧张，用不了几期就会把 C 盘塞满，运行速度明显下降。

我当时就遇到了这个问题，而且是在跑了十几条工作流之后才发现的。解决办法其实不难：WorkBuddy 提供了配置目录路径的方式，把 .workbuddy 整体迁移到其他盘。迁移步骤可以概括为三步：先关闭 WorkBuddy 所有进程；把 C 盘用户目录下的 .workbuddy 文件夹完整复制到 D 盘或其他数据盘；在 WorkBuddy 的配置文件中修改工作目录路径。改完重启后，新产生的任务记录和缓存就会写到新目录。

实际操作中我踩了一个坑：只改了配置文件里的路径，但旧目录里的历史知识库索引没有重新指向，导致知识库检索时频繁报错。后来我直接把旧目录中的 knowledge_base 子目录也复制到新位置，并在界面上重新触发了索引重建，问题才消失。所以这里提醒一句：迁移目录时，知识库索引和相关缓存目录要一并处理，不能只挪日志。

4.2 模型接入：OpenAI 接口与本地小模型的取舍

模型选择是这套方案里影响最直接的因素。我分别试过 OpenAI 兼容接口和自己内网的本地模型，两种都有使用场景。

用云端接口的优势很明显：理解能力强、长文本组织能力好，生成的四段式初稿几乎不需要大改。它对复杂句式和公文套话的掌握很到位，比如“下一步要持续加强监测预警”“重点关注数据波动较大的领域”这类表述，基本一次到位。

但它的风险也很直观：数据出内网。统计周报里哪怕是非敏感数据，在合规层面也让人不放心。所以我最后把生产环境切到了本地部署的小参数模型。效果上，本地模型对格式的服从性稍差，偶尔需要我在指令里额外强调“不要输出 Markdown，不要加多余修饰词”，但基本可用。

我个人的建议是：如果条件允许，做两套配置。日常调试和模板开发用云端接口，效率高；正式跑数用本地模型，求稳。工作流里模型地址和密钥做成变量，切换时只改配置，不用动流程结构。

4.3 知识库制作：历史周报怎么洗成“能被检索的素材”

知识库不是把一堆文档丢进去就行，至少要经过整理和切分。

我的做法是把过去十二个月的周报按周命名，每份文档只保留正文部分，去掉表格、页眉页脚和签批信息。然后按“总体情况、分项进展、存在问题、下一步安排”四个部分做段落切分。切分也要讲究：不能切得太碎，否则上下文不完整；也不能太整，否则检索命中后无法直接引用具体片段。我最终把每个切块控制在一到两个自然段，大约三百到五百字。

同时我还做了一个“统计口径说明”的知识文档，把常用指标的解释、统计范围和单位换算规则整理进去。这份文档在检索时权重最高。因为模型在生成周报时，经常需要知道“去年同期基数是怎么来的”“这个指标口径是否包含下属单位”，口径说明可以直接减少大量错误表述。

4.4 定义工作流步骤和关键提示词

在 WorkBuddy 里创建工作流时，我习惯先把输入变量定义好，再逐节点搭建。我的输入变量包括：本周数据文件路径、上周数据文件路径、周报期数、重点关注事项。这些变量会在提示词里被引用。

生成环节的提示词我迭代了很多版，最终稳定在一个很长的模板上。核心部分大致是：

• 角色设定：你是统计部门的资深分析人员，负责撰写本周期统计周报。
• 输入资料：将提供本周标准化数据、上周历史数据、校验结果、知识库检索片段。
• 输出要求：严格分为“总体情况、分项进展、存在问题、下一步安排”四个部分。
• 数值要求：只引用输入数据中出现的数值，不得自行计算或四舍五入；涉及增速、占比时使用校验工具输出的结果。
• 格式要求：使用纯文本，不要输出表格和 Markdown。

还有一条非常重要的指令：如果输入数据缺失或校验报告里有异常值，必须在对应部分明确标注，不能自己脑补解释。

4.5 首轮测试：从报错到跑通

第一次全流程测试，我预期半小时能跑完，实际上花了接近三个小时，大部分时间都在看日志、改配置。

第一个问题出现在文件解析节点。测试用的 Excel 里有一个合并单元格，解析后出现空行和字段错位。解决办法是在解析节点后加了一步“空行过滤 + 字段顺序校正”，再配合规则把错位的行踢出去。

第二个问题是知识库检索结果为空。调试发现是索引路径在目录迁移后失效，重建索引后恢复。

第三个问题是生成节点超时。我用的本地模型推理速度慢，生成较长文本时超过了默认超时时间。后来在节点配置里把超时时间从 60 秒调到 300 秒，问题解决。

跑通第一版之后，我拿最近一期的真实数据做了对比测试，生成了完整周报。文字部分质量超出预期，数据部分和人工核对的底表完全一致。那一刻我才确定这套方案可以正式接活。

5. 踩坑实录：五个最典型的翻车现场

5.1 数字不守恒：语言模型到底怎么把数据“润色”出的错

这大概是所有用大模型做报表的人最容易遇到的一类问题。某次测试中，源数据里有一项“本月累计完成 1234.56 万元”，模型生成的文案里变成了 1243.65 万元。不是四舍五入的问题，是模型在组织语言时凭语义联想“重写”了数字。

这类问题靠提示词很难根治，因为模型生成的本质就是概率性的。我的最终方案是三层防护：第一层，数字全部由上游数据节点注入提示词，不在文案里让模型凭记忆写；第二层，生成后用脚本做“数字血缘校验”，把文案中出现的所有数字和原数据做比对，出现未登记的数值就标记；第三层，对于同比增长、环比变化这类必须计算的场景，用 Skill 里的函数算好结果，作为变量直接插入文本模板，而不是让模型自己乘除。

5.2 检索不到“统计口径”这种概念词

一开始知识库里明明有口径说明文档，但模型写“城镇居民人均可支配收入”时，经常查不到具体口径，导致表述含糊。后来我看检索日志才发现，问题出在切分方式上：口径说明文档是一个整体，被切成了多个小块，但检索时用户查询是一个长句，系统返回的相关片段并不包含完整的指标解释。

解决办法有两步。第一步是把口径说明文档改为按指标名切块，一个指标对应一个块；第二步是把文档标题里加上“口径说明”这类固定前缀，提高检索命中权重。改完后，模型引用口径的准确性明显提高。

5.3 模板格式总是被 AI 自由发挥

WorkBuddy 的工作流里，生成文本的节点默认用 Markdown 输出。模型习惯性地在“总体情况”前加 ## 符号，在小标题下面加列表符号。如果后续环节直接把这段文字渲染到 Word 模板，就会出现一堆格式混乱。

这个问题的根治办法是不让生成节点直接输出最终文档。我改成生成节点只输出“内容 JSON”，把四个部分分别放到不同字段里，然后由格式化节点从 JSON 读取内容，填入 Word 模板的对应书签位置。这样模型管内容，模板管样式，互不干扰。

5.4 并发任务互相串上下文

有段时间我觉得流程跑通了，就让多个科室同时提交数据，并行跑几条工作流。结果发现两个任务生成的周报里出现了彼此的数据，A 科室的报告里出现了 B 科室的指标。

排查后确认问题出在全局变量和上下文缓存上。WorkBuddy 并行运行多个实例时，某些非显式指定的变量可能被复用。解决办法是给每个任务设置独立的会话标识，工作流内部所有变量名都带上这个标识前缀，同时把知识库检索结果绑定到本任务。这就避免了交叉污染。

5.5 一条藏得很深的环境变量问题

有次工作流突然从稳定状态变得频繁报错，指数级地消耗时间排查，最后发现是服务器上某个环境变量被其他程序修改了，导致模型服务地址解析异常。这个问题不是 WorkBuddy 本身的问题，但想提醒大家：流水线跑在服务器上，环境依赖最好写成一个固定的启动脚本，每次上线前检查关键环境变量和依赖版本，而不是依赖“上次还能用”的记忆。

6. 常见问题速查与避坑清单

6.1 问题速查表

为了方便团队里其他人排查，我整理了一张速查表，现在贴出来供参考。

6.2 哪些环节必须人审，哪些可以全自动

这套流水线跑顺之后，我在内部做了一个很清晰的区分：可以全自动的环节，和必须人工把关的环节。

全自动环节包括：文件格式转换、字段映射、基础空值检查、重复值检查、单位换算、固定格式渲染。这些环节都是确定性逻辑，机器比人可靠。

必须人工把关的环节主要是两处。第一处是政策性和高度敏感的表述，比如涉及异常波动原因分析时，模型写出来的原因可能不准确或不得体，需要人确认。第二处是最终发出的数字，即使有数字血缘校验，主管领导签字前也一定会要求人工再核对一遍。这不是技术问题，而是责任流程问题。

自动化不是取代人，而是把人的精力集中到那 20% 需要判断力的地方。

7. 一点经验体会

这套流水线从搭到用，给我最大的感触不是“AI 能写周报”，而是“把工作流程想明白之后，自动化水到渠成”。WorkBuddy 只是把我想清楚的东西固化下来，真正花时间的是拆解任务、梳理规则、整理历史数据、设计提示词边界。

如果你也想做类似的事情，我的建议是先别急着装软件，先把你的流程写在纸上：哪些步骤是确定性规则，哪些步骤需要理解能力。规则部分尽可能用脚本和 Skill 实现，理解部分才留给大模型。这条界限画得越清晰，你的流水线就越稳。

还有一个经验是，这类工具需要持续喂养。知识库不是一次建好就完事，每期周报跑完，我都会把最终确认版回填到知识库里，让模型长期学习我们单位最新的表述习惯。跑得越久，生成的初稿越接近可以直接使用的状态。

最后再分享一个小技巧：工作流里每一步都留一个“调试输出”，把中间数据保存下来。一开始我觉得这些文件占地方，后来发现排查问题全靠它们。机器能稳定跑通只是第一步，出了问题能快速定位，才敢真正把时间预算从三天压到四小时。