把夜间 AI 任务写进 Git，供团队共同维护

让 AI 凌晨自己修测试，难点往往不在模型会不会写代码，而在任务怎么定时启动、同事怎么修改规则、产出由谁验收。作者把几条跑在 MacBook Air 上的 Claude 定时任务，逐步做成了公司 6 个团队使用的后台系统，再将通用部分开源为 Kombinat。

这套方案值得看的，是它如何把 AI 编程接进日常工作：任务进 git、每次只做小事、结果交给人审核。不过，文中的工单成绩来自作者团队自述，还不足以证明其他团队也能获得同样收益。

从个人定时任务到团队协作，差在哪一步

9 月团队重组后，作者同时承担值班和大量任务，家里还有刚出生的女儿。夜里照顾孩子时，他开始尝试让 Claude 按计划执行工作。

第一版完全跑在 MacBook Air 上，持续了约一个月。它验证了任务可以后台执行，也暴露出协作问题：规则藏在个人电脑的应用里，同事无法阅读、评审或修改。

作者随后把每个例行任务写成一个 Markdown 文件，放进 git 仓库。文件头记录调度和执行配置，正文就是提示词。下面这个例子用于查找并修复失败的端到端测试：

---
name: fix-e2e-tests
description: "Finds the failing e2e test and fixes it"
schedule: '30 11 * * *'
cwd: ~/projects/app
agent: claude
effort: high
---

1. Open the latest failed e2e run on GitHub ...

要看清 schedule: '30 11 * * *'：它设置的是每天 11:30，示例本身并非夜间任务；cwd 则指定 agent 从哪个项目目录开始工作。正文只有开头，不能把它当成完整可用的修复提示词。

后台守护进程每 30 秒检查一次到期任务，每 5 分钟拉取仓库，因此任务配置合入 PR 后就能自动生效。launchd 负责重启后的进程拉起，如今运行设备换成了常开的 Mac mini。

把提示词放进 git，才让个人自动化变成了团队可以维护的工作流程。

同事新增任务走 PR，也就有了评审入口和修改记录。任务如何执行，不再只有作者一个人知道。

真正适合后台运行的，是边界清楚的小任务

他们的任务并不只在夜里执行。每小时，agent 会初步排查新升级的支持工单，检查数据、日志和代码，把发现写回工单；遇到原因明确的 bug，再起草 PR。

每天早晨，其他任务会阅读前一天的支持聊天，把产品和销售需要的信息发到 Slack；还有任务检查监控面板，为真实问题创建工单。每周五，则根据 Linear、部署记录和 Slack 起草项目进展。

作者报告，一个月内，这些 agent 帮助关闭了 73 个升级支持工单和 10 个无障碍问题，并主动修复了 5 个 bug。这里的关键词是「帮助」：原文没有交代人工投入、失败次数和验收标准，不能据此计算自动解决率。

支撑这套流程的经验很具体：

• 每次只处理一个小目标，例如一个功能开关、一个无障碍问题或一个 PR。作者的观察是，小 PR 容易被评审，大 PR 容易积压。
• 提示词要按无人回应来写。凌晨 3 点没人补充需求，任务需要提前交代足够上下文。
• 没有发现就保持安静。监控任务只在有问题时发消息，避免频道逐渐失去读者。
• agent 创建草稿 PR 和工单，人负责评审与合并。

Kombinat 支持按计划或 webhook 触发任务，可调用 Claude Code、Codex 或其他 CLI agent，复用现有 skills、MCP servers 和 CLI 工具。作者团队还给 agent 提供了所需数据的只读访问权限。

安装命令只有两条：

pnpm add @danilqa/kombinat
pnpm kombinat install

要注意第一条是在存放任务配置的仓库中安装依赖。之后将任务放进 routines/，从 http://localhost:7433 打开仪表盘；也可以通过 Tailscale 用手机访问，或经 SSH 使用终端界面。

运行条件同样明确：目前仅支持 macOS，而且 Mac 必须保持唤醒，并有用户登录。作者使用普通 Claude 订阅，没有使用 API keys；原文未说明订阅额度和并发限制。

我的判断

我认同它把「容易验收」放在任务设计前面。对测试修复、无障碍问题和明确 bug，小范围修改更容易让评审者判断对错；把阅读支持聊天、整理项目进展交给后台任务，也比强行让所有任务产出代码更合理。

但「夜里运行」不等于「无人维护」。进程需要常驻，执行依赖本机环境，早晨还得有人消化工单和 PR。原文没有给出维护成本，也没有与人工处理、普通定时脚本或 CI 工作流做对照，收益判断仍属于经验之谈。

如果任务只是固定命令加明确判断，用脚本或 CI 更容易追踪执行过程。涉及日志、代码和聊天记录的综合判断时，agent 才更有发挥空间。至于复用订阅，能否适合一般团队，还要看实际额度和使用条件，不能直接理解为没有运行成本。

能拿来做什么

• 如果你经常处理前端 E2E 测试失败，可以先选一种问题明确的失败类型，让 agent 收集证据并起草小 PR，同时记录人工修改量和最终验收结果。
• 给后台任务写清工作目录、可读数据、完成条件和无法判断时的退出方式，尤其要避免把执行过程建立在随时有人答疑的前提上。
• 将团队共用提示词放进 git，通过 PR 修改，并让代码产出停留在草稿 PR，保留人工评审和合并环节。
• 若想直接试用 Kombinat，先确认有满足登录、唤醒条件的 Mac，再从一个定时任务开始，观察结果是否值得每天投入评审时间。