#WorkBuddy# 实战复盘：我用 3 个自动化任务，把日常运营的重复劳动砍掉 90%

副标题：一个没写过前端、也不懂运维的普通运营者，是怎么把 WorkBuddy 用成"半个人力"的 适用读者：个人开发者 / 小团队运营 / 被重复劳动拖着走的人 前置条件：已安装 WorkBuddy 桌面客户端（Windows 10+ 或 macOS 12.0+），会基本的复制粘贴

一、痛点：不是没工具，是每天的时间和积分都漏在了同一个地方

我做的事情很杂——维护一个小网站、整理资料、写通知文案、偶尔处理一堆文档。这些活单看都不难，但每天都要重做一遍。

最典型的三个消耗：

1. 资料打包：要给不同的受众准备成套文档，一写就是十几份，格式还得统一；
2. 网站巡检：每天手动点开页面看能不能开、有没有 502，然后手工记一句"今天正常"；
3. 电脑清理：C 盘满了我才发现，之前一直是"红了才想起来删"。

更糟的是，我一开始的做法是"每个动作建一个定时任务"，结果后台挂了 13 个自动化，一天跑 51 次，大部分还是空转——积分没赚到，反而被后台任务吃掉了一大截。

下面记录我怎么把这三件事重整成 3 个真正有用的自动化任务，以及最后怎么把无效开销砍掉约 94%。

二、环境与配置说明

我全程没写一行前端代码、没搭过服务器。这也是我推荐它的原因：门槛不在技术，在于你有没有把"重复的事"描述清楚。

三、实操步骤

案例一：一次对话生成 36 份成套文档（资料打包）

输入材料：三个主题、每个主题 12 个细分选题的清单，纯文字写在对话里。

我的指令（可直接抄）：

我在做一个资料包合集，主题有三个：【租房避坑】【劳动维权】【预付式消费退款】。
每个主题下 12 个细分选题我列在下面。
要求：
1. 每个选题生成一份独立的 Word 文档，标题用选题名；
2. 正文按「场景说明 → 关键要点（5~8 条）→ 行动清单」结构写，语气实用、不啰嗦；
3. 每个主题的 12 份打包成一个 zip，文件名用英文拼音；
4. 全部放在 工作区/资料包 目录下，完成后给我一份文件清单。
选题清单：
（略）

实施过程：它先把目录建好，然后逐份生成，最后打包、输出清单。我中间只做了一件事——挑出两份内容偏水的让它重写。

产出物：3 个 zip 包 + 36 份 Word 文件，一次对话完成。

36份Word文档目录树（真实产出）

效果：这件事以前我估计要两三个晚上，实际交付时间不到一小时，其中大部分时间是我在检查内容。

案例二：网站巡检 + 每日日报（最省心的一个）

背景：我的小站在外部托管，最怕"挂了三天才发现"。

做法：每天固定时间自动跑一次，检查首页能不能正常打开，把结果写成一份 Markdown 日报。

巡检逻辑（示意）：

import requests, datetime

SITES = ["https://example-a.app.workbuddy.host/", "https://example-b.app.workbuddy.host/"]

rows = []
for url in SITES:
    try:
        r = requests.get(url, timeout=15)
        rows.append((url, r.status_code, "正常" if r.status_code == 200 else "异常"))
    except Exception as e:
        rows.append((url, "-", f"打不开：{type(e).__name__}"))

today = datetime.date.today().isoformat()
with open(f"日报/日报-{today}.md", "w", encoding="utf-8") as f:
    f.write(f"# 站点巡检日报 {today}\n\n")
    f.write("| 站点 | 状态码 | 结论 |\n|---|---|---|\n")
    for url, code, msg in rows:
        f.write(f"| {url} | {code} | {msg} |\n")

关键一步：把这件事挂成每天一次的自动化任务，而不是每小时一次。理由见第四节。

产出物：日报/日报-2026-10-12.md 这类按天落盘的文件，打开就知道昨天正不正常。

自动生成的站点巡检日报

效果：从"靠记性"变成"有台账"。而且异常当天就能看到，不用等用户来告诉你。

案例三：磁盘清理，3.7GB → 40GB

背景：C 盘只剩 3.7GB（96% 占用），系统开始卡。

我的指令：

帮我分析 C 盘占用，找出可清理的内容。
要求：
1. 先扫描、只出报告，不要删任何东西；
2. 分类列出：可安全清理的缓存/临时文件、大文件、重复文件；
3. 每一项标注绝对路径和体积，按体积排序；
4. 我确认后再执行删除，删之前先备份到指定目录。

实施过程：它先出了一份扫描报告，我逐条看了一遍，确认哪些能删。执行时它是先备份、后清理、按批次做，每批做完核对一次，全程我都能看到动了哪些文件。

结果：清理后可用空间从 3.7GB 涨到约 40GB。

C盘清理前后对比：3.7GB → 40GB

这里我想强调一句："先只读扫描、我确认后再动手" 这个约束一定要写进指令里。它确实照做了——这一点让我敢把这类系统级操作交给它。

四、效果验证与成本控制（这一段最值钱）

三个任务跑起来之后，我做了第二件更重要的事：把无效开销关掉。

做法很朴素：

• 凡是"结果不会变"的就停掉。比如每小时查一次备案进度，但进度一天也就变一次——改成每天一次，信息量完全一样。
• 只留真正产出东西的任务：签到、巡检、进度盯梢。
• 停掉的任务不是删掉，是暂停，条件恢复了随时能再开。

很多人以为"积分是被聊天吃掉的"，我的实际体验是：后台任务空转才是大头。先把自动化清单看一遍，收益比什么都快。

五、总结与延伸

回头看，这三次改造有个共同点：我没有让 WorkBuddy 做更聪明的事，我只是把"重复"这件事描述清楚了。

给准备上手的人三条经验：

1. 先写"输入、步骤、产出物"三件事，再开对话。指令越像一个任务说明书，交付越稳。
2. 危险操作一定要加"先只读、后确认"。这不是不信任，是流程设计。
3. 定时任务越少越好。能被"一天一次"满足的，就不要"一小时一次"。

还能延伸的方向：把资料生产接到公众号/知乎的内容排期上；把巡检结果做成一张图表页；把清理报告按季度归档做容量趋势。这些我打算接下来一个个试。

*本文为个人实操记录，文中域名与数据已做脱敏处