让 AI 24 小时替你干活?——从场景到落地的完整操作手册

很多博主在喊让 AI 24 小时工作，但几乎没人告诉你：哪些活儿适合让它 24 小时干？干到什么程度该停？怎么防止它半夜把你的代码库搞崩？

这篇文章，把 AI 自主工作这件事从头到尾讲透。

一、先泼一盆冷水：不是所有工作都适合 AI 24 小时干

在讨论怎么设置之前，先搞清楚一个前提——AI 24 小时工作 ≠ AI 什么都能干 24 小时。

AI 自主工作的本质

AI 24 小时工作的核心，是把人类从等待型任务中解放出来。你睡觉的时候，AI 在跑；你开会的时候，AI 在改。但前提是：这个任务必须是可验证、可回滚、边界清晰的。

适用场景 vs 不适用场景

适用场景：

Bug 修复：有明确的失败测试用例，修好=测试通过。典型工具：Claude Code、Codex。

依赖升级：package.json 改版本→跑测试→提 PR。典型工具：Google Jules。

代码迁移：把 class component 改成 hooks，规则明确。典型工具：Claude Code Headless。

测试生成：给已有函数写单元测试，可自动验证覆盖率。典型工具：Codex。

文档生成：扫描代码生成 API 文档，格式可校验。典型工具：Claude Routines。

日志分析：扫描日志提取异常模式，输出报告。典型工具：定时任务。

安全扫描：扫描依赖漏洞+生成修复 PR。典型工具：Codex Security。

不适用场景：

架构设计：需要权衡取舍，没有对错只有好坏。

产品需求分析：需要理解业务上下文和用户意图。

核心业务逻辑开发：错误成本极高，需要领域专家判断。

性能优化：需要理解系统全局，局部优化可能引入全局问题。

数据库 Schema 变更：不可逆操作，一旦搞砸恢复成本极高。

核心判断标准：这个任务，能不能写出一组自动化测试来验证。如果能，就适合让 AI 自主干。如果不能，就需要人在环。

二、让 AI 24 小时工作，需要具备什么条件？

条件一：完善的自动化测试体系

这是最重要的前提，没有之一。没有测试的 AI 自主开发 = 让一个实习生半夜独自改生产代码。

AI 需要一个对错信号。测试就是这个信号：
单元测试：验证函数级别的正确性
集成测试：验证模块间交互
E2E 测试：验证用户场景
Lint/Type Check：验证代码规范

关键原则：AI 可以跑测试，但绝不能改测试。测试是真相源，如果 AI 能修改测试来让自己通过，整个验证体系就失效了。

条件二：版本控制 + 分支隔离

AI 工作流程（标准模式）：

从 main 创建 feature branch
在 feature branch 上工作
跑测试，全部通过
创建 Pull Request
等待人类 Review
人类决定是否合并

绝对禁止：AI 直接 push 到 main/master

条件三：沙箱化执行环境

AI 应该在隔离环境中运行，而不是直接操作你的本地开发环境：

云端 VM：隔离级别最高，独立虚拟机，与本地完全隔离。代表产品：Google Jules（Cloud VM）。
容器沙箱：高，Docker 容器内执行。代表产品：OpenAI Codex（沙箱环境）。
Git Worktree：中，文件系统隔离，共享 Git 历史。代表产品：Claude Code（claude -w）。
本地进程：低，与你共享文件系统。代表产品：本地 CLI 模式（需谨慎）。

条件四：持久化的项目上下文

AI 需要知道自己在干什么。三大厂商的方案：

Anthropic：上下文文件 CLAUDE.md，作用：项目规范、架构约定、编码风格、常用命令。
OpenAI：上下文文件 AGENTS.md，作用：Agent 职责定义、工具权限、任务边界。
Google：上下文形式 GitHub Issue + 标签，作用：任务描述、验收标准、优先级。

以 CLAUDE.md 为例，一个生产级的配置长这样：

项目：电商后台 API技术栈- Node.js 20 + TypeScript 5.x- PostgreSQL 16 + Prisma ORM- Jest 测试框架编码规范- 所有函数必须有 JSDoc 注释- 错误处理使用 Result 模式，禁止裸 throw- API 响应格式：{ success: boolean, data?: T, error?: string }常用命令- 测试：npm test- 类型检查：npx tsc --noEmit- Lint：npm run lint禁止操作- 不要修改 prisma/schema.prisma- 不要修改 tests/ 目录下的已有测试文件- 不要直接 push 到 main 分支- 不要删除任何现有 API 端点

三、三大厂商的 24 小时工作方案

方案一：Claude Code — Headless + Routines + Cloud Tasks

Claude Code 提供三种自主运行模式：

Cloud Scheduled Tasks（云端定时任务）：不需要本机开机，在 Anthropic 云端执行，适合每日代码审查、依赖检查、安全扫描。
Headless Mode（无头模式：claude -p）：非交互式执行，适合 CI/CD 和 cron，输出到 stdout，支持管道操作，适合 GitHub Action 集成、自动化脚本。
Desktop Scheduled Tasks（桌面定时任务）：需要本机开机 + Desktop App 运行，可访问本地文件和工具，适合本地仓库的日常维护。

Headless 模式实战示例：

# 每晚 2 点自动修复 lint 错误0 2 * * * claude -p '修复所有 ESLint 错误，跑 npm test 确认无回归' \--max-turns 20 \--allowedTools 'Edit,Bash(npm test),Bash(npm run lint)' \2>&1 >> /var/log/claude-nightly.log# 每周一自动检查依赖更新0 9 * * 1 claude -p '检查 package.json 中的过期依赖，\对 minor/patch 版本自动升级并跑测试，\major 版本只列出但不升级' \--max-turns 30 \--allowedTools 'Edit,Bash(npm *),Bash(git *)'

方案二：OpenAI Codex — 云端沙箱 + 多 Agent 管线

Codex 的核心理念：每个任务在独立沙箱中执行。

开发者提交任务后，流程为：

Planning Agent（分解任务） → Implement Agent（写代码） → Security Agent（安全审查） → Testing Agent（跑测试） → 创建 Pull Request

特色功能：

Worktrees：多任务并行，文件隔离。
SKILL.md：自定义技能，复用工作流。
自动触发：基于 GitHub Event 自动启动 Agent。

方案三：Google Jules — 异步任务队列

Jules 的设计哲学最接近 24 小时工作：你提交任务，它在云端 VM 里干完，给你一个 PR。

工作流程：

开发者在 Jules 界面提交任务（或给 GitHub Issue 打 jules 标签）
Jules 克隆仓库到云端 VM
生成执行计划，等待开发者确认
执行：编码 → 测试 → 迭代
输出：标准 Pull Request + 变更说明 + 推理过程

内部架构（四个子 Agent）：

Planning（任务分解） → Execution（代码实现） → Critique（质量审查） → Testing（测试验证）

最大优势：完全不占用本地资源，真正的后台执行。

四、停止工作的边界条件：什么时候该让 AI 停下来？

这是最容易被忽略、也是最危险的问题。AI 不知疲倦，但如果没有明确的停止条件，它会陷入无限循环或越改越烂。

六大停止边界：

成功完成：测试全部通过 → 提交 PR → 停止。
测试失败 N 次：连续 3 次修复失败 → 停止，记录失败原因到 BLOCKED.md，等待人工介入。
超过最大轮次：--max-turns 20 → 强制停止，防止无限循环消耗 Token。
Token 预算耗尽：设置 Token 上限，超过预算自动终止。
触发禁止操作：尝试修改被保护的文件，Pre-Tool Hook 拦截 → 立即停止。
遇到需要决策的分叉：不确定该选 A 还是 B，记录选项和分析 → 暂停等待人类决策。

实战配置（以 Claude Code 为例）：

claude -p '修复 issue#42' \--max-turns 20 \          # 边界3：最多20轮--allowedTools 'Edit,Bash(npm test)'   # 边界5：只允许编辑和测试

在 CLAUDE.md 中补充：

停止规则- 如果测试连续失败 3 次且你无法定位根因，停止工作并将分析写入 BLOCKED.md- 如果需要修改数据库 Schema，停止并说明原因- 如果修改影响超过 5 个文件，先输出影响分析等待确认- 如果不确定两种实现方案哪个更好，列出 pros/cons 等待决策

五、权限设置：给 AI 画一个安全围栏

权限的三个维度：

工具权限（能用什么工具）：

允许：文件读取、文件编辑、npm test / npm run lint
禁止：npm install（可能引入恶意包）、git push（必须通过 PR）、rm -rf / git reset --hard

文件权限（能动哪些文件）：

允许：src/ 目录（业务代码）、docs/ 目录（文档）
禁止：tests/ 目录（已有测试，只读）、.env* 文件（敏感配置）、prisma/schema.prisma、CI/CD 配置文件

操作权限（能做什么动作）：

允许：创建新文件、修改已有文件、创建分支、创建 PR
禁止：合并 PR、删除分支、发布 Release、部署到生产环境

Claude Code 的 Hook 机制：

// .claude/hooks/pre-tool-use.js// 在 Agent 执行任何工具之前触发module.exports = function(toolCall) {  // 拦截危险的 shell 命令  if (toolCall.tool === 'Bash') {    const dangerous = ['rm -rf', 'git push', 'git reset', 'DROP TABLE'];    for (const cmd of dangerous) {      if (toolCall.args.includes(cmd)) {        return { action: 'BLOCK', reason: `禁止执行: ${cmd}` };      }    }  }  // 拦截对受保护文件的编辑  if (toolCall.tool === 'Edit') {    const protectedFiles = ['schema.prisma', '.env', 'jest.config'];    for (const file of protectedFiles) {      if (toolCall.args.includes(file)) {        return { action: 'BLOCK', reason: `${file} 是受保护文件` };      }    }  }  return { action: 'ALLOW' };};

六、开发范式：如何避免 AI 24 小时低效空转

范式一：Plan → Approve → Execute → Verify

错误范式：

帮我优化整个项目的性能 → AI 开始漫无目的地改代码

正确范式：

Step 1: 分析 src/api/ 目录，列出所有性能瓶颈点 → AI 输出分析报告，人类审核

Step 2: 针对第 3 点（N+1 查询），生成修复方案 → AI 输出方案，人类选择

Step 3: 执行方案 A，修改后跑性能测试对比 → AI 执行，测试验证

Step 4: 提交 PR，附上性能对比数据 → AI 提交，人类 Review

范式二：小批量 + 高频验证

错误模式（大批量）：

重构整个用户模块 → 改了 50 个文件 → 测试爆了 → 不知道哪里出了问题

正确模式（小批量）：

Task 1: 重构 UserService.create() 方法 → 测试 → PR

Task 2: 重构 UserService.update() 方法 → 测试 → PR

Task 3: 重构 UserService.delete() 方法 → 测试 → PR

...

每个 PR 只改 2-3 个文件，出问题立刻定位

核心原则：限制每个任务的爆炸半径。一个任务最多影响 5 个文件，超过就应该拆分。

范式三：不可变测试 + 可变代码

项目结构：├── src/           ← AI 可以自由修改├── tests/         ← AI 只能读取和执行，不能修改├── CLAUDE.md      ← 人类维护，AI 读取└── BLOCKED.md     ← AI 记录阻塞问题，人类处理

测试是裁判，代码是选手。选手不能同时当裁判。

范式四：异步任务队列模式

这是最接近 24 小时工作的模式：

任务队列示例：

Priority 1: 修复#42登录Bug → Agent A 执行中
Priority 2: 升级 React 18 → 19 → Agent B 执行中
Priority 3: 给 UserAPI 写测试 → 等待中
Priority 4: 生成 API 文档 → 等待中
Priority 5: 清理未使用的 imports → 等待中

每个任务独立分支 → 独立验证 → 独立 PR

人类每天早上 Review 一批 PR

七、实战清单：一步步设置 AI 24 小时工作

Step 1：准备基础设施

# 确保测试覆盖率达到基本要求npm test -- --coverage# 核心模块 > 70%# 确保 CI/CD 管线正常git push → GitHub Actions 自动跑测试

Step 2：编写项目上下文文件

创建 CLAUDE.md（或 AGENTS.md），包含：技术栈、编码规范、禁止操作、常用命令。

Step 3：配置权限和 Hook

设置允许的工具列表

配置 Pre-Tool-Use Hook 拦截危险操作

设置 --max-turns 和 Token 预算

Step 4：从低风险任务开始

先让 AI 干这些：

修复 lint 错误
补充代码注释
生成单元测试

观察产出质量，逐步放开更复杂的任务

Step 5：建立 Review 节奏

每天早上 30 分钟：

检查 AI 昨晚提交的 PR（通常 3-5 个）
快速 Review：测试通过？改动合理？
合并好的 PR，对有问题的 PR 留评论
检查 BLOCKED.md，处理 AI 遇到的阻塞
向任务队列添加新任务

写在最后

让 AI 24 小时工作不是一个噱头，它正在成为现实——但前提是你理解它的适用边界。

三个核心认知：

AI 24 小时工作的本质不是无人值守，而是异步协作。人类定义目标和约束，AI 执行和验证，人类审核和决策。

测试是 AI 自主工作的操作系统。没有测试，AI 就是无头苍蝇。测试覆盖率决定了 AI 自主权的上限。

最大的风险不是 AI 写错代码，而是你不知道它写错了。所以：小批量、高频验证、不可变测试、强制 PR Review。

Google Jules 的设计哲学说得好：AI 应该像一个优秀的初级工程师——能干活，但每个重要决策都要经过 Senior 的确认。