基于Bash与Cron的自动化系统检查任务实践

在之前的文章中，我分享了如何用特定工具搭建写作环境和建立招聘工作流。今天，我们来聊一个更贴近日常研发与运维的场景：如何构建一个自动化系统检查任务。

我的需求背景很简单：手头管理着多个项目，文件分散在不同目录。经常需要手动检查哪些文件有更新、哪些脚本还能跑、哪些任务完成了——这种重复劳动不仅耗时，还特别容易遗漏细节。于是，我决定让工具来帮忙，建立一个能自动运行、全面检查并生成报告的系统。

需求梳理

在动手之前，我首先明确了几个核心需求：

1. 定期检查：系统需要能每天自动运行，无需手动触发。
2. 全面覆盖：检查范围应包括Git仓库状态、文件执行权限、近期修改记录等。
3. 生成报告：每次检查都要生成一份清晰、可追溯的详细报告。
4. 归档管理：历史报告需要按日期妥善归档，方便日后查阅。

当被问及“你想多久检查一次？”时，我设定了 “每天早上8点” 这个时间点。一个自动化检查系统的蓝图就此展开。

创建核心检查脚本

首先，需要创建一个综合性的检查脚本 system_check.sh。这个脚本整合了多项检查功能。

1. Git状态检查

通过 git status --short 可以快速了解工作区的变更情况，包括未提交的修改和未被跟踪的新文件。

git status --short

2. 文件权限检查

对于项目中的Shell脚本，确保它们具有可执行权限至关重要。以下循环检查当前目录下所有 .sh 文件的权限状态。

for script in *.sh; do
    if [ -f "$script" ]; then
        if [ -x "$script" ]; then
            echo "✅ $script (可执行)"
        else
            echo "❌ $script (不可执行)"
        fi
    fi
done

3. 查找最近修改的文件

使用 find 命令定位过去24小时内被修改过的文件，同时排除 .git 目录，并按时间倒序排列，让你一眼看清最新的变动。

find . -type f -mtime -1 ! -path './.git/*' -printf '%T+ %p\n' | sort -r

4. 工作区统计

对项目整体规模有个数据化的认识总是好的。这个部分统计了总文件数、目录数以及Markdown文件的数量。

echo "- 总文件数: $(find . -type f ! -path './.git/*' | wc -l)"
echo "- 目录数: $(find . -type d ! -path './.git/*' | wc -l)"
echo "- Markdown 文件: $(find . -name '*.md' | wc -l)"

报告生成与归档

脚本每次运行后，都会生成一份带有时间戳的详细报告，并自动保存到 memory/ 目录下，结构如下：

memory/
├── system-check-2026-02-04.md
├── system-check-2026-02-05.md
└── ...

报告内容模块化，通常包含：

• 工作区文件状态：Git状态概览、未跟踪文件列表。
• 脚本文件权限：逐一列出每个脚本的可执行状态，快速定位问题。
• 最近修改记录：过去24小时内所有变动的文件清单。
• 工作区统计：文件、目录、特定类型文件的计数。

配置定时任务 (Cron)

有了检查脚本，下一步就是让它能够“自觉”地每天运行。这里我使用了经典的Cron定时任务。

目标是每天上午8点整自动执行检查，对应的Cron表达式和命令如下：

0 8 * * * cd /home/bttb/.openclaw/workspace && ./system_check.sh

简单解释一下这个表达式：0 8 * * * 代表“每天的第8小时的第0分钟”，也就是早上8点整。后面跟着的是切换到工作目录并执行脚本的命令。第一次配置时我才发现，Cron表达式并没有想象中那么复杂！

首次运行与效果

配置完成后，我迫不及待地手动执行了一次脚本 ./system_check.sh，看看效果。部分输出示例如下：

========================================
系统文件更新检查 - 2026-02-04 08:53:46
========================================

## 工作区文件状态

### Git 状态
?? AGENTS.md
?? BOOTSTRAP.md
?? HEARTBEAT.md
?? check_extensions.sh
...

### 未跟踪文件 (18 个)
AGENTS.md
BOOTSTRAP.md
...

## 脚本文件权限

✅ check_extensions.sh (可执行)
✅ install_vscode_extensions.sh (可执行)
✅ system_check.sh (可执行)

## 工作区统计
- 总文件数: 18
- 目录数: 3
- Markdown 文件: 14
- Shell 脚本: 4

检查完成: 2026-02-04 08:53:49

同时，一份完整的报告已经生成：memory/system-check-2026-02-04.md。一切井然有序。

建立档案管理体系

随着检查任务日复一日地运行，历史报告会越来越多。为了避免 memory/ 目录变得杂乱无章，我建立了一个归档系统，将不再活跃但仍有保留价值的项目或文件移入 archive/ 目录。

archive/
├── README.md           # 档案库总索引
└── vscode-plugins/     # VS Code插件档案
    ├── README.md       # 详细索引
    ├── check_extensions.sh
    ├── install_vscode_extensions.sh
    └── ...

归档遵循明确的规则：按项目或类型分类、每个档案夹都有独立的README说明文件、记录归档日期和原因。这样，历史资料既不会干扰当前工作，在需要时又能被迅速定位。

工作流的整合价值

这个自动检查系统可以轻松嵌入到日常的工作流中，发挥更大价值：

• 📊 每日晨检：每天早上，报告已准备就绪。花几分钟浏览，就能对所有项目的健康状况了如指掌，快速处理待办事项。
• 🔄 项目进度跟踪：通过“最近修改文件”清单，可以直观地回顾工作进展；Git状态则清晰地反映了代码提交纪律。
• 📁 知识积累：连续的历史报告构成了一份项目日志，便于进行不同时期的对比分析，为项目复盘和总结提供了扎实的数据依据。

效率提升：数字说话

我们来做一道简单的算术题：

检查任务	手动耗时	自动化耗时	提升
检查Git状态	1分钟	自动	-
检查文件权限	2分钟	自动	-
查找最近修改文件	3分钟	自动	-
统计工作区	1分钟	自动	-
生成报告	5分钟	自动	-
每日总计	12分钟	0分钟	∞ (无限)

每天节省12分钟，一年下来就是惊人的73个小时！更重要的是，自动化检查永不会遗忘或懈怠，每一次都保质保量地完成。

实践后的思考

搭建起这套系统后，我的工作模式发生了几个积极的转变：

1. 从被动到主动：不再依赖记忆去“想起来检查”，而是由系统在固定时间主动提供全景视图。
2. 从零散到系统：告别凭感觉抽查，转变为覆盖关键维度的标准化、系统化检查。
3. 从模糊到清晰：项目状态不再是一个“黑盒”或模糊的感觉，而是由一份份数据报告清晰地呈现出来。

适用场景与扩展思路

这种自动化检查的思路具有普适性，非常适合以下场景：

• 开发项目：自动化代码质量检查、测试覆盖率统计。
• 运维监控：基础服务状态、日志错误关键字扫描。
• 内容/知识库管理：跟踪文档更新、检查内部链接有效性。
• 数据备份验证：定期检查备份任务是否成功、备份文件完整性。

此外，这个基础的脚本框架还有很大的扩展空间：

1. 增加检查项：集成磁盘空间、系统负载、特定进程状态、日志文件大小监控等。
2. 智能告警：当检查发现严重问题（如磁盘将满、服务宕机）时，自动发送邮件、短信或即时消息通知。
3. 数据可视化：将每日报告中的数据（如文件增长趋势、修改频率）抽取出来，生成趋势图表，更直观地展现项目演变。

最后的感想

回顾这次从明确需求、编写脚本到配置自动化的全过程，最大的收获是意识到：许多重复性劳动并非无法避免，关键在于是否愿意投入一次性的精力去构建一个“自动驾驶系统”。一旦建成，它便会持续不断地为你创造价值，释放出宝贵的时间和注意力。

如果你也在为某些重复的检查、统计工作烦恼，不妨也尝试用自动化的思维去解决它。从一个小脚本开始，你会发现效率提升的空间远超想象。欢迎在云栈社区分享你的自动化实践心得或遇到的挑战。