工作数据自动化：我用 WorkBuddy 落地的 4 个真实项目复盘

一名基层信息人员的"零代码自动化"实践：从表格搬运工，到把重复劳动交给工作流。

写在前面

我在信息化岗位上工作，日常打交道的是一套业务管理系统。工作被三件事反复消耗：从系统里捞数、把捞出来的数据整理成能交差的台账、给不用技术的同事发一个"双击就能用"的工具。

这三件事的共同点是：技术含量不高，但极其耗时，且每个月都要重来一遍。过去我靠手工点击、复制粘贴、肉眼比图，一个月能填满好几本台账；现在我把其中大部分交给了 WorkBuddy，同类工作从"几天"压到"几十分钟"。

本文不讲虚的，只复盘 4 个真实落地的项目，以及踩过的坑。文中涉及具体系统与业务的部分已做脱敏（去掉地址、账号、真实姓名与业务编码），但技术细节与坑点都是原样保留的——因为它们才是真正可迁移的部分。

项目一：把业务系统的数据"搬"出来

需求：业务系统的统计页面只提供网页查看，历史明细要导出成 Excel，官方导出按钮产出的文件常常是坏的。

做法：不是硬啃导出按钮，而是先摸清页面背后的接口。

• 系统走 CAS 单点登录。与其模拟登录流程，不如登录一次后把会话凭据（cookie + 应用基址）落盘成一个 session 文件，后续脚本直接复用，省掉每次重登。
• 页面上的"下载 Excel"按钮产出的其实是损坏的 OLE2 文件——中文被错误地按另一种编码解释过，产生了一批不可逆的私有区字符，脏数据已经在那一步丢失了。正确做法是绕开它：真正的数据在页面 HTML 的表格里，结构清晰、中文正常，直接解析 HTML 表比修复二进制文件可靠得多。
• 明细数据藏在两级下拉框（先选大类，再按大类查子项）里，需要两步请求才能拿到目标列表，不能一次性拉全。
• 生成的成品不是简单复制系统数据，而是双 Sheet 工作簿：一张是汇总台账（表头着色、结论列、底部说明），另一张把附件图片按行横排嵌入，做到"打开就能看、看完就能签"。

结果：原来要手工比对半天的月度汇总，现在脚本跑完直接出可交差的 Excel。

项目二：给同事做一个"双击就能用"的免安装工具

需求：给不装开发环境的同事发一个填报/汇总小工具，要求：一个文件、双击运行、会自己填表、结果自动上传到共享目录。

做法：把 PowerShell 脚本以 Base64 内嵌进一个纯 ASCII 的 .bat 里，双击时先解码成临时脚本再执行。

这里有个非常反直觉但必须遵守的坑：.bat 里只要出现中文，就可能出现"吃字节"现象——命令行解释器按代码页分块预读批处理文件，编码不匹配时会连带吃掉后面 ASCII 行的行首字符，症状是 powershell 被读成 owershell、报"不是内部或外部命令"。把文件存成 GBK、在第二行改代码页都救不回来（预读已经发生了）。唯一的稳妥做法是 BAT 本体纯 ASCII，中文界面全部交给 PowerShell 输出。

其他几条血泪经验：

• 上传成功要"读回来校验"。网络共享路径在慢链路上极慢，写完马上列目录常常返回空（陈旧缓存），会误判成失败。正确做法是把文件读回内存、比对字节数和校验和，一致才算成功。这一点上，"校验靠读文件本体，不靠列目录"。
• 工具要留静默开关。任何情况下都不要让无人值守的运行被一个弹窗永久挂住——脚本里要预留跳过界面、跳过上传的开关。
• 快捷方式而不是 exe。给同事用的工具别打包成 exe，容易被杀软误报；用带图标的快捷方式更安全，而且快捷方式放同目录时会自动存相对路径，整个文件夹拷给别人还能用。

顺带说一句：这个工具我迭代了四个版本，每一版都是被上一版的坑逼出来的（v1 命令行问答 → v1.1 强制弹窗填表 + 自动上传 + 失败重试 → v1.2 成功静默关闭 + 桌面图标 → v1.3 检测并自动安装办公软件）。小工具的生命力在于"使用者反馈驱动迭代"，而不是第一版做多全。

项目三：做一个只读的查询门户（数据安全是第一位）

需求：业务系统本身的功能不满足按分组、按区域汇总查看，需要给授权人员一个网页，能筛选、分组统计、导出 Excel。

最关键的不是开发，而是这一条：先问"现有平台能不能满足"。

我先花时间把现有平台的菜单和权限模型摸了一遍，结论是：平台能做"按人一个一个查"，但做不到"一次看全整组、按区域汇总"（多选筛选参数在后端被整体等值匹配，永远命中不了——这是平台缺陷，不是操作问题）。确认真有缺口，才动手自建。

自建时的两条红线：

1. 只读账号 + SQL 白名单双重保护。连接只用只读账号，且代码层强制只放行查询语句。之所以要双保险，是因为实测发现那个"只读"账号在个别表上其实带了写权限——不能想当然地说"数据库层会拒绝写操作"。
2. 数据口径要写清楚。页面展示的数据来自"每日同步表 + 主库实时增量"的合并，同步表只在固定时间刷新，所以必须两边合并、按单号去重、以实时数据优先。同时起查点要往前回溯一天，兜住最后一批可能不完整的同步数据。

部署上还有一条重要认知：对方给的"数据库账号"不等于"服务器登录权限"。前者是数据身份，能读写数据；后者才能启动进程、占用端口、对外提供网页。这两件事必须分清楚，否则会白忙一场。

性能上有个便宜可占：主表有八百万行，用没索引的列做关联要跑四十多秒；换成有索引的时间列做条件，零点二秒就出来了。同样的结果，只差一个索引。

项目四：本地、免费的视频重新配音

最后一个项目和主业无关，但很能说明"工作流"的价值。

需求：一段口播视频里口头禅太多，想重配一遍、换一个更沉稳的音色。

做法：完全本地、零成本的三件套——

• 转写：本地语音识别模型（中等规模），不要贪小，小模型在专业名词上错得离谱（把行业里的专用术语听成同音词是常事）。关键技巧是喂一份领域词表，把猜到的专有名词、业务术语作为提示词传进去，准确率提升非常明显。
• 清洗：去口头禅、去重复、合并碎句。顺序不能乱，且去重要限定在高频虚词上，否则"谢谢""慢慢"会被破坏。
• 配音：用免费的在线语音合成，注意要处理限流（请求之间留间隔、失败指数退避、断点续跑）。
• 对位：这是全流程最大的难点，也是唯一需要"设计"的地方。清洗掉口头禅后，新旁白天生比原声短（原声覆盖 93%，清洗后自然语速只覆盖约 55%）。不要试图用极慢的语速填满整条时间轴，那样听起来会发飘；正确做法是"变速贴合 + 接受空档"，覆盖率落在七八成是正常的。

沉淀：把每次踩坑变成"下次不用再踩"

这四个项目里，我认为真正产生复利的不是代码，而是"把踩过的坑写成文档"这件事。

每做完一个项目，我都会把过程整理成一份结构化的操作手册：适用场景、标准步骤、关键接口、坑点清单、验收标准。这份手册有两个作用：

1. 下次同类任务直接调用，不用重新摸索（尤其是那些反直觉的坑，比如"编码不匹配会吃字节""口径差一天结论偏四成""只读账号其实不全只读"）。
2. 它本身就是交付物的一部分。当一件事要交接给别人，一份写清"坑在哪、为什么这么绕"的手册，比一堆脚本有用得多。

我把它总结成一条原则：跑通一次不算会，能稳定复现第二次才算会。

一点使用感受

作为非专职开发人员，我对 WorkBuddy 最满意的地方，是它允许我用"说人话"的方式提出需求，然后把技术细节留给它。我不需要先想清楚用什么语言、什么框架、什么数据库，只需要说清"我要什么、约束是什么"——比如"不要动原有数据库的结构和数据""必须部署在能连数据库的服务器上，不要拿我的电脑当入口"——它会照这个边界去找方案。

第二个感受是它对"环境"的处理比我预期得扎实。上面那些代理劫持、编码吞字节、会话进程被回收的问题，都不是业务逻辑问题，而是"这台机器/这个网络就是这么怪"。这类问题最耗人，而它能自己排查、自己绕开，还顺手记下来下次不重犯。

第三个是它的产出可以直接用。不是给一段示例代码让我再改，而是直接给我一个能打开的工作簿、一个能双击的工具、一个能交付的文档。对我这种"做完就要交"的岗位来说，这一点比功能多少更重要。