[AI书房] 第18章 让大工作在夜里完成
把工作交给AI，然后离开座位 - YOLO模式完全入门
第18章 让大工作在夜里完成
金京镇律师
案例 17) 睡觉时重构 100 个文件的代码结构
场景
周三晚上 11 点。开发团队负责人张瑞俊先生正对着显示器发愁。公司的 Web 服务代码已经过时了。100 个文件中重复着相同的模式，需要将其更改为新结构。如果由人工完成，需要打开每个文件、修改代码、进行测试，整个过程需要耗时一周。
张瑞俊先生决定采用另一种方法：交给 AI 处理，然后去睡觉。
指令
首先，在 Git 中创建一个新分支 (branch)。
git checkout -b refactor-structure
这意味着不改动原始代码，而是通过创建一个分支来进行操作。如果出了问题，直接删除这个分支即可。
启动 Claude Code。
"请将 src 文件夹中所有 .ts 文件的旧版 import 语句更改为新版。具体来说，将 'import { X } from '../utils/helpers'' 更改为 'import { X } from '@/utils/helpers''。更改后，请检查每个文件是否能无误地编译。如果有无法编译的文件，请将其还原并告知列表。"
执行过程
Claude Code 开始扫描 src 文件夹。共有 112 个 .ts 文件。它逐个打开文件，查找对应模式并进行替换。替换完成后，运行 TypeScript 编译器以检查是否存在错误。
如果出现错误，它会将该文件还原，并在列表中注明“此文件需要手动检查”。
处理这 112 个文件耗时 45 分钟到 1 小时。张瑞俊先生把任务交给 Claude Code 后便去睡觉了。
结果
周四早上 8 点。张瑞俊先生上班后查看终端，显示着一条消息：“112 个文件中有 108 个已完成转换，4 个文件需要手动检查”。
输入 git diff 查看更改内容。108 个文件的 import 语句已更改为新模式。对于那 4 个文件，附带了说明，称由于转换后会导致其他地方报错，因此保持原样。
张瑞俊先生只需亲自检查并修改这 4 个文件，30 分钟就完成了。原本需要一周的工作量，竟然在一夜之间结束了。
成本
时间 1 小时（AI 工作的时间），费用 15,000 到 25,000 韩元。如果由人工工作一周，人力成本将高达数百万元。
风险
让 AI 在夜间大规模修改代码存在很大风险。因此，张瑞俊先生采取了三个关键措施。
创建了分支。没有触动原始代码。如果出错，只需删除分支即可。
要求进行编译检查。指令不是“只管改”，而是“改完并检查”。
要求将失败的文件还原。以防止 AI 强行进行不恰当的修改。
如果这三点中缺少了任何一项，你早上上班时可能会看到一团糟的代码。
如果我们也要效仿的话
如果要将大规模代码修改交给深夜处理，请务必在新的分支上进行工作。在指令中包含“确认”和“失败时回滚”。早上通过 git diff 检查变更内容，运行测试后，再合并到原分支。
案例 18) 凌晨故障时的自动检测、自动修复及提交 PR
场景
凌晨 3:17。Web 服务发生了故障。服务器监控工具 Datadog 检测到错误率激增，并向 Slack 发送了通知。如果是平时，值班开发人员需要在凌晨起床，打开笔记本电脑，检查日志，修改代码并进行部署，整个过程需要 1 小时。在此期间，用户们正在发送“网站无法访问”的消息。
这家公司采用了另一种方法。他们构建了一个流水线 (pipeline)，一旦收到 Slack 通知，就会自动启动 Claude Code。
指令
这并不是由人在实时下达指令，而是预先设置好的自动化流程。当 Slack 收到故障通知时，webhook 会触发脚本，脚本随后启动 Claude Code。
传递给 Claude Code 的指令如下：
"请分析错误日志。从错误信息中寻找原因，并检查相关的代码文件。如果可以修复，请创建新分支进行修改，并在 GitHub 上提交 PR (Pull Request)。在 PR 标题中加上 '[自动修复]'。如果无法修复，请在 Slack 上发布错误分析报告。"
进行过程
凌晨 3:17，Claude Code 自动启动。它正在读取错误日志。反复出现 "TypeError: Cannot read property 'email' of null" 错误。情况是在获取用户数据时返回了 null（空值）。
查找相关代码文件。在 user-profile.ts 文件的第 42 行读取用户邮箱时，没有处理用户信息不存在的情况。
Claude Code 创建了新分支，并在第 42 行添加了 null 检查（检查是否为空的代码）。检查编译。运行测试。通过。
在 GitHub 上提交 PR。PR 标题："[自动修复] user-profile.ts 添加 null 检查"
向 Slack 发送消息："凌晨 3:17 检测到故障。原因：user-profile.ts 未处理 null。已提交修复 PR。请确认后合并。"
凌晨 3:32。从检测到提交 PR 用时 15 分钟。
结果
值班开发人员早上上班后检查 PR。评审代码是否正确，然后进行合并 (merge)。故障处理在 15 分钟内完成，且人员无需在凌晨被吵醒。
成本
耗时 15 分钟（自动），成本 3,000 到 5,000 韩元。考虑到值班开发人员的凌晨加班费，这种方式要便宜得多。
风险
自动修复的代码可能会出错。因此，这家公司设置了两道安全保障。
只提交 PR，但不自动部署。需要人工确认并合并后才会进行部署。
在 PR 标题中加上 "[自动修正]"，以便与人工创建的 PR 进行区分。对于自动修正的 PR，需要进行更仔细的审查。
如果设置了自动部署会怎样？AI 可能会进行错误的修改并自动部署，从而导致故障进一步扩大。
我们也想效仿的话
这个案例适用于开发团队具有一定规模，且正在使用 Slack 和 GitHub 的情况。需要预先构建好这样的流水线：监控工具（Datadog、Sentry 等）→ Slack 通知 → Webhook → 运行 Claude → 创建 PR。你甚至可以让 Claude Code 来构建这个过程，只需说：“请帮我创建一个凌晨故障自动响应的流水线”。
案例 19) 同时运行 20 个子代理进行代码检查
场景
周五下午 6 点。计划下周一发布重大更新，想对整个代码库进行一次检查。这是一个拥有超过 2,000 个文件的项目。如果由一个人来检查，需要耗时 2 周。
指令
Claude Code 拥有名为子代理（sub-agent，子代理，下级工作者）的功能。一个 Claude Code 可以创建多个小的 Claude Code 并让它们同时工作。
"将此项目的 src 文件夹分成 20 个区域，并为每个区域运行一个子代理。每个子代理负责检查其区域内的文件，并查找以下内容：未使用的变量、缺失错误处理的地方、存在安全隐患的模式（硬编码的密码、SQL 注入风险）。请将结果汇总到 code_review_结果.txt 中。"
进行过程
Claude Code 将 src 文件夹分为 20 个区域，并均匀分配文件数量。20 个子代理同时启动。
每个子代理读取负责的文件并查找问题。子代理之间是独立工作的。即使其中一个代理变慢，也不会影响其他代理。
由于 20 个代理同时工作，原本需要 5 分钟完成的任务可以快 20 倍。整个检查过程耗时 15 到 25 分钟。
结果
code_review_结果.txt 文件。其中整理了各区域发现的问题。例如：“文件 auth.ts 第 23 行：密码硬编码”、“文件 db-query.ts 第 55 行：存在 SQL 注入风险”、“文件 utils.ts：有 3 个未使用的变量”。这类条目会有几十条。
费用
耗时 25 分钟，费用在 40,000 到 70,000 韩元之间。由于 20 个子代理同时调用 API，费用比其他案例更高。但与雇佣 20 个人进行代码审查的费用相比，这微不足道。
风险
如果 20 个子代理同时修改文件，可能会发生冲突。因此，在这个案例中，我要求它们“只检查，不要修改”。仅读取文件的操作没有冲突风险。
如果想要让它们执行修改，则需要让每个子代理在不同的分支上工作。
请注意费用管理。随着子代理数量的增加，费用会成比例上升。如果运行 50 个而不是 20 个，费用也会变为 2.5 倍。最好设置 API 使用量限制。
我们也想效仿的话
子代理（Sub-agent）功能从 Claude Code 2026 版本开始可以使用。当项目规模较大（文件 500 个以上）时，该功能非常有效。如果是小项目，仅使用一个 Claude 就足够了。建议起初尝试使用 3 到 5 个子代理，如果效果良好，再增加数量。
失败案例：代理在夜间重复了 300 次相同的错误
一位开发者在晚上把代码重构（refactoring，即改善代码结构）交给 AI 后便睡下了。早晨醒来时，发现终端里打印了超过 300 行错误信息。同样的错误信息重复出现了 300 次。
事情的经过是这样的：AI 修改了代码，但测试失败了。AI 说“正在修改”，然后再次修改，结果还是失败。接着继续修改，再次失败。如此循环了 300 次。
如果是人类，在第三次左右就会意识到“我的方法不对”并停下来。但 AI 没有停下。它以同样的模式进行修改，以同样的原因导致失败，然后再次以同样的模式进行修改。无休无止。
问题在于成本。300 次尝试耗费了 12 万韩元的 API 费用。就在一个晚上。代码没有任何进展，钱却白花了。
预防方法有两种。
设置重复次数限制。在指令中加入“如果出现 3 次相同的错误，请停止并向我报告”。这一行指令本可以节省 12 万韩元。
设置 API 费用上限。可以在 Anthropic 控制面板中设置每日使用限额。如果设置为每天 2 万韩元，一旦超过 2 万韩元，API 就会停止。这样即使 AI 在夜间运行，也会在 2 万韩元处停止。
[第五部分结束] 应用案例一览
案例 1. 50 封邮件回复草稿。耗时 3 分钟，费用 500 韩元。
案例 2. 将会议录音转换为会议纪要。耗时 10 分钟，费用 2,000 韩元。
案例 3. 10 篇论文的摘要报告。耗时 30 分钟，费用 6,000 韩元。
案例 4. 将 Markdown 转换为出版级 PDF。耗时 8 分钟，费用 1,200 韩元。
案例 5. 12 个月的销售额汇总。耗时 2 分钟，费用 400 韩元。
案例 6. 识别供应商重复项。耗时 1 分钟，费用 500 韩元。
案例 7. 将 200 张收据转换为 Excel。耗时 40 分钟，费用 5,000 韩元。
案例 8. YouTube 评论情感分析。耗时 8 分钟，费用 2,000 韩元。
案例 9. 创建个人博客。耗时 30 分钟，费用 4,000 韩元。
案例 10. 社区聚会日程表。耗时 10 分钟，费用 500 韩元。
案例 11. 花店预约系统。耗时 1 小时，费用 6,500 韩元。
案例 12. 浏览器自动化测试。耗时 10 分钟，费用 1,500 韩元。
案例 13. Gmail 分类与回复草稿。耗时 5 分钟，费用 2,000 韩元。
案例 14. Slack 每周摘要。耗时 3 分钟，费用 800 韩元。
案例 15. Notion 页面自动更新。设置时间 10 分钟，之后自动执行。
案例 16. 竞品网站追踪。设置时间 15 分钟，之后自动执行。
案例 17. 更改 100 个文件的代码结构。耗时 1 小时，费用 20,000 韩元。
案例 18. 凌晨故障自动应对。耗时 15 分钟（自动），费用 4,000 韩元。
案例 19. 20 个子代理的代码检查。耗时 25 分钟，费用 55,000 韩元。
所有案例的共同点：先使用 Git 保存，然后开始运行，最后通过肉眼确认结果。
第六部分：发生事故时的生存之道