重复性工作是效率的最大杀手。每天手动检查服务状态、逐台服务器执行更新、一个个文件重命名……这些机械操作不仅耗时，还容易出错。WorkBuddy 的自动化工作流能力让你用自然语言定义规则，一次配置永久生效。本文展示三大自动化场景的配置方法。
运营团队每天早上 9 点需要一份日报，包含昨日 DAU、收入、异常订单等数据。手动制作约 30 分钟，用 WorkBuddy 定时任务可以全自动完成。
# 配置定时任务
> 帮我创建一个定时任务：每天早上9点自动生成运营日报，
数据从数据库拉取，生成 Markdown 文件发到飞书群
# WorkBuddy 生成自动化配置：
📋 定时任务配置
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
名称：每日运营日报
触发：cron "0 9 * * *"（每天 09:00）
状态：已启用
执行流程：
Step 1: 连接数据库，查询昨日数据
SQL:
SELECT DATE(created_at) as date,
COUNT(DISTINCT user_id) as dau,
SUM(amount) as revenue
FROM orders
WHERE created_at >= DATE_SUB(CURDATE(), INTERVAL 1 DAY)
AND created_at < CURDATE()
GROUP BY DATE(created_at);
Step 2: 查询异常订单
SQL:
SELECT * FROM orders
WHERE status = 'error'
AND created_at >= DATE_SUB(CURDATE(), INTERVAL 1 DAY);
Step 3: 生成 Markdown 日报
模板：daily_report_template.md
Step 4: 发送到飞书群
Webhook: https://open.feishu.cn/open-apis/bot/v2/hook/xxx
格式：富文本消息卡片# 每周一生成周报
> 每周一早上10点，汇总上周的 Git 提交记录，
按项目分组，生成周报发到团队群
# 每月1号清理过期数据
> 每月1号凌晨3点，清理 logs 表中30天前的数据，
先备份再删除，清理完发通知
# 每15分钟检查证书过期
> 每15分钟检查一次SSL证书，距离过期不到30天的
自动发告警到运维群当监控系统检测到服务异常时，WorkBuddy 可以自动执行诊断流程，甚至在安全范围内自动修复。
# 配置告警响应工作流
> 配置一个告警响应：当收到"服务CPU超过80%"的告警时，
自动执行诊断流程：查进程→查日志→尝试重启→通知
# WorkBuddy 生成响应流程：
📋 告警响应配置
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
触发条件：CPU 使用率 > 80% 持续 5 分钟
响应级别：L2（自动诊断 + 人工确认修复）
自动诊断流程：
Step 1: 识别高 CPU 进程
$ top -b -n 1 | head -20
→ 记录 TOP 5 进程及 CPU 占用
Step 2: 检查最近错误日志
$ journalctl -u {service} --since "5 min ago" | grep -i error
→ 提取最近 5 分钟错误日志
Step 3: 检查内存和磁盘
$ free -h && df -h
→ 排除内存泄漏或磁盘满导致的问题
Step 4: 生成诊断报告
→ 汇总以上信息，附带建议操作
Step 5: 发送通知
→ 飞书/企业微信推送诊断报告
→ 包含一键重启按钮（需人工确认）# 配置自动修复（需明确授权）
> 对于"Redis连接超时"告警，授权自动执行：
1. 检查Redis哨兵状态
2. 如果主节点宕机，自动触发failover
3. 验证新主节点就绪
4. 重启受影响的服务
# 响应配置：
触发条件：Redis 连接超时连续 3 次
响应级别：L3（全自动修复）
授权范围：仅限 Redis 故障转移和服务重启
执行流程：
Step 1: redis-cli -h {sentinel} info sentinel
Step 2: redis-cli -h {sentinel} sentinel failover mymaster
Step 3: 等待 30 秒，验证新主节点
Step 4: systemctl restart {affected_service}
Step 5: 健康检查确认恢复
Step 6: 发送修复完成通知# 批量更新10台服务器上的Nginx配置
> 帮我批量更新所有Web服务器的Nginx配置，
服务器列表在 [上传 servers.csv]，
新配置文件在 [上传 nginx.conf.new]，
先备份再替换，逐台执行，每台执行后验证
# WorkBuddy 执行批量操作：
📋 批量操作计划
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
目标：10 台 Web 服务器
操作：更新 Nginx 配置
策略：逐台执行（非并行），每台验证后才继续下一台
执行进度：
[1/10] 10.0.1.10 → 备份 ✅ 替换 ✅ reload ✅ 验证 ✅
[2/10] 10.0.1.11 → 备份 ✅ 替换 ✅ reload ✅ 验证 ✅
[3/10] 10.0.1.12 → 备份 ✅ 替换 ✅ reload ❌ 配置语法错误
→ 自动回滚到备份版本 ✅
→ 跳过后续服务器，发送告警
→ 原因：该服务器 Nginx 版本不支持新指令
⚠️ 操作中断：第3台失败，已自动回滚
✅ 前2台更新成功，后7台未执行（安全策略）# 批量重命名和压缩图片
> 把 /assets/products/ 下的所有图片：
1. 按产品SKU重命名（从对应的CSV读取映射）
2. 压缩到 WebP 格式，质量85
3. 生成缩略图 300×300
# WorkBuddy 执行：
📋 批量文件处理
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
源文件：247 张产品图片
映射表：[上传 product_sku_map.csv]
处理进度：
✅ 重命名：247/247 完成
✅ WebP 压缩：247/247 完成（平均压缩率 62%）
✅ 缩略图生成：247/247 完成
原始总大小：384 MB
处理后总大小：146 MB（节省 238 MB）# 批量更新测试环境数据库
> 把测试环境所有用户的手机号脱敏，
替换为 1380000+原号后4位
# WorkBuddy 执行（自动分批）：
📋 批量数据更新
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
目标：test_db.users 表
影响行数：15,234 条
策略：分批执行，每批 1000 条，每批提交前验证
批次 1: 1-1000 ✅
批次 2: 1001-2000 ✅
...
批次 16: 15001-15234 ✅
全部完成，总耗时 23 秒
验证：抽样 100 条确认脱敏正确 ✅