Honesty 
Typecho 用 Gemini 描述需求，Cursor 写原型，ChatGPT 画 logo，Claude Code 生成 iOS 前端和 Go 后端，Codex 跑测试，最后一条流水线自动出宣传物料和发布。
我盯着这条流水线看了很久，脑子里只有一个念头：那我能不能去睡觉了？
一、先把这个幻想夸一遍
人类最伟大的发明不是火，不是轮子，是"让别人替我干活"。从奴隶制到外包到 SaaS，本质都是同一件事的不同版本。AI 编程工具的出现，让这件事第一次有了"我躺着、它干活、还不要工资"的可能性。
所以我的终极幻想非常朴素：
- 早上拉屎的时候，描述一句"我想要个能记录拉屎时长的 App"；
- 中午吃饭的时候，原型已经跑起来了，logo 也画好了（一坨拟人化的便便，戴着秒表）；
- 下午开会摸鱼的时候，前后端代码生成完毕，测试在跑；
- 晚上睡觉的时候，CI 绿了，宣传图出好了，App Store 审核已提交；
- 第二天醒来，后台显示：恭喜，你的"拉屎计时器"已上线，首日下载 0。
听起来很美。流程图大概长这样——这也是 99% 的人现在脑子里那张图：
Gemini] --> B[原型
Cursor] B --> C[Logo
ChatGPT] C --> D[前端 iOS
Claude Code] D --> E[后端 Go
Claude Code] E --> F[测试
Codex] F --> G[宣传物料 + 发布
流水线] G --> H((上线)) style H fill:#86efac
漂亮。一条直线，AI 接 AI，人在哪？人在睡觉。
然后我真去睡了一觉。醒来发现：需求被 Gemini 理解偏了一点，Cursor 基于偏的需求写了原型，Claude Code 基于偏的原型写了代码，Codex 给偏的代码写了能通过的测试——整条流水线非常顺畅地、自动化地、高效率地，产出了一个错误的东西。
这就是问题所在。
二、泼盆冷水：你的瓶颈从来不是 AI 的速度
我们先把"加速"这个词拆开。你说要"进一步加速、减少人工干预"，潜台词是：当前流程里，人是瓶颈，把人去掉就快了。
这个假设是错的。在 AI 辅助开发里，人卡的不是"生成"这一步，是另外三件事：
1. 验证瓶颈（Verification Debt）
AI 生成代码的速度是人写的 10 倍、100 倍。但人审代码的速度并没有变快。你让 AI 一晚上生成 5000 行代码，第二天你得花一整天去读它、信它、找出它哪里在一本正经地胡说。
生成越快，未经验证的代码堆得越高。这玩意儿我管它叫"验证债"——和技术债一样，是要还利息的。你越想让 AI 在你睡觉时多产出，醒来要还的债就越多。
这是整篇文章最反直觉、也最重要的一句话：让 AI 无人值守地跑，瓶颈不在生成端，在验证端。
2. 上下文碎片化：你才是那个"人肉中间件"
回头看你那条流水线。Gemini 的需求，要你手动复制给 Cursor；Cursor 的原型，要你手动喂给 Claude Code；Claude Code 的接口定义，要你手动告诉 Codex 去测。
每一个箭头，都是一次"人肉搬运"。每一次搬运，都会丢上下文。你不是这条流水线的旁观者，你是它唯一的集成层（integration layer）。 五个工具各自只知道自己那一段，全局只在你脑子里。
你想去睡觉？整条流水线的连接件就断了。
3. 错误复利（Compounding Errors）
自动化循环最危险的特性是：没有人在中间踩刹车，小错会复利成大错。 第一步偏 5%，第二步基于偏 5% 的输入又偏 5%，三四步下来，产出和你想要的已经是两个东西了。
人在循环里时，你会在第二步就喊停。人不在时，AI 会非常自信地把错误一路传播到上线。
把这三点合起来看，真实的流程图其实长这样：
这是对的?} E -->|没人| F[自信地
上线了错的东西] E -->|你| G[醒来还验证债] style F fill:#fca5a5 style G fill:#fde68a style E fill:#fca5a5
所以"如何让 AI 在我吃饭睡觉时持续产出"这个问题，正确的问法不是"怎么让它生成更快"，而是：
怎么让一台机器替我验证产出对不对，这样我才敢让 AI 在我睡觉时一直跑下去？
三、第一性原理：什么样的工作才配让 AI 无人值守
想清楚上面那句话，解法就自己浮出来了。
人为什么必须在循环里？因为只有人能判断"这做得对不对"。那么，凡是能把"对不对"的判断权交给机器的工作，就能让 AI 无人值守地跑；凡是不能的，就必须留人。
判断权能交给机器的，有这些：
| 验证手段 | 能替你回答的问题 | 能不能自动判定 |
|---|---|---|
| 单元测试 / 集成测试 | 逻辑对不对 | ✅ 红绿一目了然 |
| 类型系统（Go / Swift / TS） | 接口对不对、字段对不对 | ✅ 编译即验证 |
| Lint / 静态分析 | 风格、空指针、安全隐患 | ✅ |
| 契约测试 / Schema 校验 | 接口和上游约定一不一致 | ✅（你做 pacs.002 XML 校验那套就是） |
| 截图 diff / E2E | UI 没崩 | ✅ 半自动 |
| "这个需求值不值得做" | …… | ❌ 永远是你 |
| "用户会不会喜欢" | …… | ❌ 永远是你 |
看出门道了吗？让 AI 通宵打工的前置条件，不是更强的 AI，是更强的验证护栏（verification harness）。 测试覆盖率、类型完备度、CI 严格度——这些平时被当成"工程素养"的无聊东西，恰恰是你能不能安心睡觉的唯一保险。
你的 App 测试做得越扎实，你睡得越香。这话听起来像测试布道，但它就是字面意思。
四、收敛工具链：先把"人肉中间件"裁掉
在谈 Claude Code 怎么压榨之前，先解决第二节那个"五个工具五段上下文"的问题。
手里的工具越多，你这个集成层就越无法离场。 真要减少人工干预，第一刀该砍向工具链本身，而不是砍向人。原则：用更少的工具，承载更厚的上下文。
具体到你的栈：
- 需求、前端、后端、测试，尽量收敛到一个有持久上下文的 agent 里（Claude Code 就行）。一个 agent 同时知道需求、知道接口、知道测试约定，它内部传上下文是不丢的——丢上下文的是工具之间的边界，而你正在消灭边界。
- 把全局上下文沉淀成文件，而不是留在你脑子里。 Claude Code 的
CLAUDE.md就是干这个的：项目背景、技术约定、目录结构、"别动 NPSS 那个证书续期逻辑"之类的禁区，全写进去。这样每个 session 不用你重新交代——你那套从一个系统学测试约定、迁移到新系统的 Skill 思路，本质就是把"人脑里的约定"外化成"机器能读的文件"，同一个方法论。 - Logo 这种一次性创意活，留给 ChatGPT/Gemini 没问题，它本来就不在主循环里，不影响你睡觉。别为了"统一"而强行收敛，那是另一种形式的折腾。
收敛之后，理想的循环里只剩一个主 agent + 一圈机器验证，人退到循环外面当"提需求的"和"拍板的"。
五、Claude Code 的 auto 模式，怎么压榨到极限
下面提到的具体 flag / 模式名以官方文档为准（https://docs.claude.com/en/docs/claude-code/overview），Anthropic 迭代很快，我写的时候对、你看的时候可能已经改名了。重要的是思路，不是参数。
你问"auto 模式怎么最大化效率"，我把它拆成几个递进的档位，按"放手程度"从小到大排：
档位 0：交互式（默认，最安全）
每个危险操作都问你一句"要不要执行"。这是默认行为。优点是稳，缺点是——你没法去睡觉，因为它每两分钟弹一次窗等你点确认。
档位 1：Auto-accept edits（这就是大家口里的"auto 模式"）
在交互界面里循环切换权限模式（通常是 Shift+Tab 那一档），切到"自动接受编辑"。这时 Claude Code 改文件、跑命令不再每步问你，自己一路往下做。这是单机能拿到的最大单任务加速。
适用场景：任务边界清楚、有测试兜底、错了也好回滚（在 git 分支里干）。
档位 2：Plan mode（先想后做，省得返工）
让它先出方案、你过一眼、再放它去执行。看起来"更慢"，但对复杂任务，一次想清楚 > 三次返工。尤其当你打算让它无人值守跑的时候，前面花 30 秒看个 plan，比醒来面对一坨跑偏的代码划算得多。
档位 3：Headless / 非交互模式（这才是"睡觉时产出"的关键）
claude -p "你的任务" 这种 print/headless 模式，让 Claude Code 不开交互界面、直接吃一句 prompt 跑完、吐结果。这一档的意义在于：它能被脚本调用、能进流水线、能被 cron 在凌晨三点拉起来。
到这一档，你才真正脱离了"必须坐在终端前"的状态。它可以被 &&、被 |、被 CI、被任务队列调度。
档位 4：YOLO 模式（跳过所有权限）
有个跳过全部权限确认的 flag（名字带 dangerously 字样，这命名本身就是警告）。它确实最快，也确实最容易让你醒来发现 home 目录少了点东西。 唯一可以接受它的场景是：跑在隔离的容器/沙箱里，输入受控、爆炸半径可控。永远别在你的主力开发机上对着真仓库开这玩意儿去睡觉。
真正放大效率的几个"力学结构"
档位是单点加速，下面这几个是杠杆：
- Hooks（PreToolUse / PostToolUse 等）：在它执行工具前后挂自己的 shell 命令。最香的用法——PostToolUse 自动跑测试和 lint。AI 每改完一轮，钩子自动验证，红了它自己接着修。这就是第三节说的"把验证权交给机器"的落地形态，也是无人值守循环的发动机。
- Subagents（子 agent）：把"写实现"和"写测试 / 审代码"拆成不同 agent。让写测试的那个用怀疑的眼光看写实现的那个的产出——相当于给你的无人车间配了个不睡觉的 QA。
- 自定义 slash command / Skill：把你重复的工作流（比如"按 NPSS 的约定给新系统补测试"）固化成一条命令。这正是你已经在做的 Skill 化，把它接进 Claude Code 就行。
- GitHub 集成（CI 里 @claude / Action）：把 AI 塞进 PR 流程。你睡前提个 issue，它在云端的 Action 里干活、开 PR、跑 CI，醒来你只 review。这才是字面意义上的"睡觉时产出"——活儿在别人的服务器上跑，不占你的电、不占你的机器、不需要你醒着。
六、把 AI 任务当成异步任务队列来调度
这里给你一个你最熟的心智模型。你在 platform 那个 Go monorepo 里用 Asynq 做异步任务队列对吧？——把 AI 任务也当成异步 job 来调度，整套调度学问你早就会了。
类比一一对上：
| Asynq 概念 | AI 流水线对应 |
|---|---|
| Task（任务） | 一个有明确验收标准的开发需求 |
| Queue（队列） | 你睡前堆进去的一批活 |
| Worker | headless 模式的 Claude Code 实例 / CI runner |
| 任务的 success 判定 | 测试 / CI 绿 ← 第三节的核心 |
| Retry（重试） | 失败了让 AI 读报错、自己再试 N 次 |
| Dead Letter Queue（死信队列） | 重试 N 次还红的，标记 需人工，留给醒来的你 |
调度流程：
拆成带验收标准的 task] --> B[(任务队列)] B --> C[Worker: headless Claude Code] C --> D[生成 / 修改代码] D --> E{自动验证
测试 + 类型 + lint} E -->|绿| F[自动开 PR / 合入分支] E -->|红| G{重试次数
< N?} G -->|是| H[读报错
自己修] --> C G -->|否| I[死信队列
标记: 等你醒来] F --> J[早上: 你 review 绿的 PR] I --> K[早上: 你处理啃不动的硬骨头] style E fill:#fde68a style F fill:#86efac style I fill:#fca5a5
这张图的精髓全在那个黄色的 自动验证 节点上。没有它，整张图就是第二节那个"自信地上线了错的东西"。有了它，AI 才敢在你睡觉时一遍遍重试，因为有台机器在替你说"还不行，重来"。
睡前的活该怎么拆，决定了这套能不能跑通：
- ✅ 适合通宵的活：写测试、补文档、按既定模式扩接口、修 lint、批量重构、根据明确 spec 实现 CRUD——判断标准清晰、错了能自动发现的。
- ❌ 别指望通宵的活：定核心架构、决定要不要做某个功能、判断 UI 体验、处理跨团队的歧义需求——需要品味和拍板的。这些你硬塞给 AI 通宵跑，醒来收获的是一份措辞自信的垃圾。
七、一条真正"睡觉时能产出"的流水线
把上面所有东西拼起来，你那条原始流水线该升级成这样——注意每个环节后面都多了一道机器验证闸门：
+ 写清验收标准] N2[review 绿 PR
+ 啃死信队列] end subgraph 机[AI · 含你睡觉时 · 自动循环] A[需求结构化] --> A1{Schema 校验} A1 --> B[实现代码] B --> B1{类型 + lint} B1 --> C[测试] C --> C1{CI 全绿?} C1 -->|红| B C1 -->|绿| D[出物料 + 开 PR] end N1 --> A D --> N2 style A1 fill:#fde68a style B1 fill:#fde68a style C1 fill:#fde68a style N1 fill:#bfdbfe style N2 fill:#bfdbfe
和你最初那条直线流水线的区别，就两点，但是是质变：
- 每段之间插了机器验证闸门，错误在本环节就被拦下，不再复利到下游。
- 人被挤到了循环外面，只剩"提需求"和"拍板"两个动作——而这俩恰好是机器做不了的。
八、从入门到放弃：环节
照例，到了系列签名的放弃环节。
你顺着这篇文章一路优化下来：收敛了工具链，配齐了测试护栏，开了 auto 模式，挂了 hooks，搭了任务队列，AI 真的能在你睡觉时不停产出了。然后你会发现一件细思极恐的事：
你把所有环节都自动化掉了，最后剩下两个怎么都自动不掉的——"决定做什么"和"判断做得对不对"。
而这两个，恰好是软件工程里从来就最难的部分。写代码从来不是瓶颈，想清楚要写什么、判断写出来的对不对，才是。AI 把"写"这个体力活的成本打到了接近零，于是把"想"和"判断"这两个真正的难点，赤裸裸地、无处可藏地，推回到了你面前。
所以这个系列叫"从入门到放弃"是有道理的。这次你放弃的不是某个工具，是"AI 能替我思考"这个幻觉。AI 能替你打字、替你查文档、替你跑测试、替你通宵搬砖——它唯一不能替你做的，是替你成为那个知道该往哪走的人。
吃饭睡觉上厕所的时候，AI 确实能替你产出。但它产出的方向、产出的质量底线，还得是你睡前定好的。你越想躺平，前期就得越清醒地把护栏和验收标准立好——躺平是有前置工作量的，而且那部分工作量，删不掉。
行吧，那我还是先去把测试补一补。毕竟，测试写得越好，我睡得越香——这大概是这篇文章唯一一句没有反转的实话。