我睡觉时，AI在替我加班
凌晨三点，你的GitHub在自动提交代码。
不是黑客入侵，也不是你忘了关电脑。而是一个Agent正在执行你睡前布置的任务：写登录页面、跑测试、截图验证、生成报告。等你早上醒来，邮箱里只有一份"失败项清单"——如果有的话。
这听起来像科幻片，但已经在发生。
Claude Code Camp最近的一篇文章《I'm Building Agents That Run While I Sleep》把这件事摊开了讲。作者不是在炫技，而是在解决一个让程序员夜不能寐的痛点：你怎么敢相信AI写的代码？
答案很残酷：先写标准，再写代码
作者拿"邮箱密码登录"功能举例。没让Agent直接开干，而是先列出四条铁律：
AC-1：有效凭证必须跳转到/dashboard，且设置session cookie
AC-2：密码错误必须显示"Invalid email or password"，且留在/login
AC-3：空字段必须禁用提交或显示内联错误
AC-4：5次失败尝试后锁定60秒，并显示等待时间
每条标准都必须是可观测、可验证的。Agent写完后，Playwright浏览器Agent上场，像真人一样点击、输入、截图，最后生成一份"判决书"：哪条过了，哪条挂了，屏幕当时长什么样。
你只 review 失败项，而不是 diff 里的每一行代码。
这套流程叫opslane/verify，开源在GitHub上。技术栈很干净：Claude Code的headless模式（claude -p）+ Playwright MCP，不需要额外后端，也不需要新的API key。
四个阶段像流水线：
Pre-flight（纯bash）：服务起没起？文件在不在？别浪费token。
Planner（Opus模型）：读代码、找选择器、规划验证路径。
Browser agents（Sonnet并行）：每条AC一个Agent，五个标准五个Agent同时跑。Sonnet比Opus便宜3-4倍，干这种点击活足够。
Judge（Opus终审）：汇总所有证据，给出最终裁决：pass、fail、或需要人工介入。
"You can't trust what an agent produces unless you told it what 'done' looks like before it started."
老实说，这句话戳中了现在AI编程的软肋。 大多数人写prompt像许愿："给我做个登录页，要好看，要安全"。然后祈祷出来的东西能用。作者说，写验收标准比写prompt更难，因为它逼你在看到代码之前，就想清楚所有边界情况。
就像当年大家抵制TDD（测试驱动开发）一样——"太慢了"、"太麻烦了"。
但没有标准，你只能盯着AI的输出干瞪眼，然后假装相信它。
等等，这真的是在"验证"，还是在"演戏"？
有意思的是，评论区没一边倒叫好。
有人抛出个刺耳的概念："Test Theatre"（测试剧场）。意思是，你写的测试只是在确认"代码确实做了代码做的事"，而不是"代码做了应该做的事"。如果需求本身写错了，Agent会完美实现错误的需求，然后测试全绿，你睡得很香，用户醒来发现灾难。
另一位开发者说得更狠：
"At some point you're not reviewing diffs at all, just watching deploys and hoping something doesn't break."
这简直是给管理层递刀子。 你的终极目标如果是"自动化到不需要人"，那恭喜，你正在训练自己的替代品。从"审查每一行代码"到"只看失败报告"，再到"只看部署状态"，最后变成"希望别崩"——这是一条滑向深渊的斜坡。
还有人在实践更激进的方案：红绿重构三队制。一个Agent专门写代码（绿队），一个专门写测试找茬（红队），一个负责重构协调（裁判）。关键是上下文隔离——不同Agent实例之间不共享记忆，模拟" clean room"环境。
听起来很酷，但也有人泼冷水：
"Am I supposed to be impressed by this? I'm perfectly happy running two simple agents... I'm doing 5-7x productivity easily, and don't need more than that."
说白了，不要为了用Agent而用Agent。 如果你只是想要个登录框，搞个四阶段验证流水线可能纯粹是过度工程。
那个没人敢说的真相
最扎心的评论藏在第9条：
"现在的目标是用Agent提高速度同时保持质量。但如果目标是提高质量同时保持速度呢？"
我们太沉迷于"让AI跑得更快"，却忘了问自己：这样跑出来的代码，真的更好吗？还是只是"足够好，好到能骗过自动化测试"？
作者自己也承认：这抓不住需求理解错误。如果验收标准本身有漏洞，Agent会像尽职的律师一样，在合同漏洞上签字画押。Playwright能抓集成故障、渲染bug、浏览器兼容性问题，但它抓不到"你根本不该做这个功能"的战略失误。
审查疲劳是真实的。 当Agent一晚上给你提交50个PR，人类Reviewer要么变成麻木的"盖章机器"，要么干脆放弃抵抗直接merge。有人提议按风险分级：低风险代码让LLM自己审自己merge，高风险必须人工介入。
但问题是，谁来判断什么是"高风险"？ 让另一个Agent来判断吗？
结语
所以，"睡觉时运行的Agent"到底是福音还是诅咒？
它确实把程序员从机械劳动中解放出来，但也可能让我们变成"自动化流水线的看守者"，看着部署仪表盘发呆，祈祷别出乱子。
或许真正的分水岭在于： 当你早上醒来，打开那份"失败报告"时，你是否还记得这个功能最初要解决什么用户问题？还是只关心AC-1到AC-4有没有全绿？
如果我们都变成了验收标准的奴隶，那和代码有什么区别？
【kimi-k2.5锐评】：用AI验证AI写的代码，本质上是用魔法对抗魔法，但魔法说明书（验收标准）还是得人类先写对——而写对说明书，往往比写代码更难。
参考链接：
https://www.claudecodecamp.com/p/i-m-building-agents-that-run-while-i-sleep