title: " AI排查Cron没跑 | 时区环境和日志" category: 人工智能 tags:

定时任务是很多自动化系统的心脏。

比如：

每天生成日报。
每小时同步数据。
每 5 分钟检查工单。
凌晨跑内容抓取。
定时分析 4SAPI 调用成本。

最烦的是：

它没跑。

或者：

它跑了，但没产生结果。

这类问题非常适合 AI 排查。

因为它涉及：

时区。
环境变量。
工作目录。
权限。
日志。
容器生命周期。
任务锁。

1. 定时任务先问三件事

有没有触发？
有没有执行？
有没有成功？

这三件事不一样。

问题 说明
没触发 cron 表达式、时区、服务没启动
执行失败 命令路径、权限、环境变量
成功但没结果 业务逻辑、输出路径、数据条件

AI 排查时要先分层。

2. 给 AI 的 Cron 排错包

【任务】
- 任务名称：
- 期望执行时间：
- 实际现象：
- 运行方式：cron / systemd timer / GitHub Actions / 容器内 scheduler

【配置】
- cron 表达式：
- 执行命令：
- 工作目录：
- 用户：
- 时区：

【日志】
- 系统日志：
- 应用日志：
- stdout/stderr：
- 最近一次成功时间：

【环境】
- 是否 Docker：
- 环境变量是否可用：
- 文件权限：
- 任务锁：

【边界】
- 不删除数据
- 不重复触发生产任务
- 先给只读检查

3. 常见根因一：时区错

很多任务不是没跑。

是按 UTC 跑了。

你以为北京时间 9 点，实际上它在 UTC 9 点跑。

给 AI：

服务器时区。
容器时区。
应用时区。
cron 表达式。
期望业务时区。

只读命令：

date
timedatectl

Docker：

docker compose exec app date

4. 常见根因二：环境变量没有加载

交互式 shell 能跑：

python sync.py

cron 里失败。

常见原因：

cron 环境很干净。
PATH 不同。
.env 没加载。
工作目录不同。

修复方向：

用绝对路径。
显式加载 .env。
记录 stdout/stderr。
在脚本里检查必要变量。

但不要把真实 Key 输出到日志。

5. 常见根因三：任务还在锁里

为了避免重复执行，很多任务会加锁。

如果上次崩了没释放锁，后续任务都跳过。

日志可能只有：

job skipped, lock exists

AI 要看：

锁文件。
锁表。
上次执行状态。
超时策略。

不要让 AI 直接删锁。

先确认任务是否还在运行。

6. 常见根因四：容器重启导致 scheduler 停了

如果定时任务跑在容器里，要看：

容器是否重启。
scheduler 进程是否还在。
日志是否被轮转。
任务是否应该拆成独立 worker。

很多项目把 Web 和 scheduler 放在一个容器里。

短期能用。

长期建议拆开：

app
worker
scheduler

Fable 5 可以帮你评估是否需要拆。

7. 4SAPI 场景

如果定时任务会调用模型，比如：

每天总结 4SAPI 调用日志。
每小时生成内容选题。
定时检查 API 失败率。

建议记录：

job_id
run_id
scheduled_at
started_at
finished_at
model
cost
status

这样任务没跑时，你能知道：

是 scheduler 没触发。
还是模型 API 失败。
还是结果写库失败。

8. 补跑任务要谨慎

定时任务没跑后，很多人第一反应是：

手动补跑。

这不一定安全。

补跑前要问：

任务是否幂等？
会不会重复发消息？
会不会重复扣款？
会不会重复生成报表？
会不会重复调用模型导致成本翻倍？

可以让 Fable 5 审查补跑方案：

请审查这个定时任务是否适合补跑。
重点检查幂等、重复发送、重复写库、重复调用 4SAPI、数据时间窗口和回滚方式。
如果不适合直接补跑，请给安全替代方案。

对于模型批量任务，补跑还要看预算。

不要因为补昨天的任务，把今天的 4SAPI 额度打爆。

9. 定时任务日报

如果你有很多自动任务，建议每天让 AI 生成一份任务日报。

字段：

job_name
scheduled_at
started_at
finished_at
duration
status
records_processed
model_cost
error_summary
needs_human

低成本模型就能整理。

Fable 5 只用来分析异常：

连续失败。
耗时突然变长。
模型成本异常。
处理数量异常。

这会让自动化系统从“没人知道跑没跑”变成“每天有账”。

10. 实战补充：补跑前先写一张风险单

Cron 没跑以后，真正危险的不是“少跑一次”。

真正危险的是：

为了补救，手动跑错时间窗口。
重复发送通知。
重复扣费。
重复调用 Fable 5。
重复写入报表。

所以补跑前可以让 AI 先生成一张风险单：

任务名称：
缺失时间窗口：
补跑范围：
是否幂等：
是否会发外部消息：
是否会写生产数据：
是否会调用 4SAPI：
预计模型成本：
是否需要暂停正常调度：
验证方式：
回滚方式：
人工确认人：

比如一个“每天凌晨生成客户报告”的任务没跑。

AI 应该提醒你：

不要直接补跑所有客户。
先选 1 个测试租户验证。
确认不会重复发送邮件。
确认 report_date 使用昨天而不是今天。
确认 4SAPI 预算足够。
确认失败后不会自动重试 10 次。

如果这个任务会调用模型，4SAPI 日志里要能按 run_id 查：

run_id
job_name
business_date
model
request_count
cost
status

这样即使补跑，也能把补跑成本和正常成本分开。

这一步很小，但非常救命。

很多线上事故不是因为定时任务没跑，而是因为补跑太猛。

11. AI Prompt

你是定时任务排查助手。

请根据 cron 表达式、时区、执行用户、工作目录、环境变量、系统日志和应用日志，判断任务没跑属于：
1. 没触发
2. 触发但命令失败
3. 环境变量缺失
4. 工作目录或 PATH 错
5. 权限问题
6. 任务锁未释放
7. 容器或 scheduler 进程停止
8. 业务逻辑没有产生结果

要求：
- 先给只读验证命令。
- 不建议直接重复执行生产任务。
- 涉及删除锁、补跑任务时标注人工确认。

12. 总结

定时任务没跑，不要只看 cron 表达式。

要看：

触发。
执行。
结果。
时区。
环境变量。
日志。
锁。
容器。

AI 最适合帮你把这些证据排成时间线。

4SAPI 可以记录模型任务的 run_id、成本和状态。

一句话：

定时任务排错，先证明它到底有没有被触发。