AI Agent 夜里写代码，我睡醒再审：一个开发者的自动化分级实践

一名独立开发者在 Hacker News 上分享了自己的工作流：白天把想法拆解成可执行工单，夜间让 Claude Code 自主完成编码与测试，自己第二天早晨再统一审查合并到生产环境。这套系统最值得讨论的设计，是给每个工单新增了一个「autonomy」字段来决定它能否被无人值守完成。

工作流：白天规划、夜间构建、早晨审查

整个循环被压缩进一天：

• 白天：把想法转成规格、写验收标准、做出只有人能做的决定（产品方向、定价、品牌文案、安全策略等）。
• 夜间：一个后台 Agent 拣出「可构建」的工单，端到端完成开发、跑测试、部署到 dev 环境，完成就标 done，缺信息就挂起并留问题。
• 早晨：开发者只审查从 dev 合并到 prod 的那一个 PR，这是代码进入生产的唯一入口。

所有工单都存在本地的一个 markdown 文件夹里，由一个小型本地服务渲染成看板。Agent 直接读写这些 markdown。开发者在原文里贴出了 SET-175 这张工单的完整 YAML 字段，可以看到它从 IDEA-40 自动晋升而来，唯一标识是「autonomy: auto」，并且说明这是纯重构、所有需求可被测试验证。

核心机制：autonomy 字段决定谁能「自动下班」

每张工单都有一个字段：

• auto：Agent 可以一路做到 done，全程无人参与。
• needs-input：无论测试多绿，必须等开发者拍板。
• blocked：缺前置条件，不进入队列。

字段缺失默认是 needs-input，因此默认状态下没有任何工单会被自动完成。作者把这个机制概括为一句话：「可被测试证明的工作交给 Agent，需要人判断的工作留给我。」

文中给出两个对照案例：

• SET-175：四个 EventBridge cron 重复同一段扫描逻辑，Agent 抽成 scanActiveDeals(statuses) 公共函数、补 6 个单测、跑完 2282 个测试、部署 dev、关单。还顺手发现并关闭了一张描述同样重复问题的工单。
• SET-184：调用房源数据 API 评估待成交订单的估价风险。代码同样写完、测试通过、安全回退也做好了，但「上线」意味着付费开通数据订阅，这笔钱该不该花没有测试能回答，因此停在 needs-input 等人决定。

代码写得是否正确、是否行为一致，可由测试覆盖；但是否值得花钱、是否符合产品方向、是否触达不可逆的边界，这些只能由人拍板。

为什么不做逐行 code review

作者把当下关于 Agent 自主性的争论归纳为两个极端：

• YOLO 模式：权限全开，Agent 自由跑，出问题就 revert。问题在于 revert 不能「反悔」错发的客户数据或流失的信任。
• 逐行审查：在 Agent 产出远超人能读完之前有效，之后一定崩。

他引用数据指出，仅约 8% 的从业者对 Agent 全自主感到舒适，大量使用 AI 的工程师表示几乎没有任何工作可以真正无人值守。折中方案是用分类器自动放行「看起来安全」的动作，其余的拦截下来报警。但他认为这些方案都在问错问题——真正该问的是「这件事能不能被测试证明」。

此外，dev 与 prod 之间存在一道硬隔离：Agent 只对 dev 分支和 dev 数据有写权限，prod 分支只由开发者本人通过每日 PR 合并。所谓「无人审查」仅在 dev 范围内成立，prod 仍由人把关。

与图工程的呼应：把 Agent 编排写成 markdown

如果熟悉 LangGraph，会发现整套实践和「图工程（graph engineering）」高度同构：

• 类型化状态：工单的 frontmatter 就是 typed state。
• 条件路由：autonomy 字段决定下一步走向。
• 中断门：needs-input 即 interrupt gate。
• 检查点：活动日志就是 checkpoint，可在中断后恢复。

区别在于，这些组件不是由图运行时强制执行，而是写在 markdown 规则里——作者明确指出他放弃的是「执行层面的强约束」，换来的是整套工作流透明、可审计、可手动覆盖。

一个仍待回答的问题

文章原文在结尾被截断，作者正要展开「我放弃的是什么」以及「执行强制缺失的代价」。在现有篇幅里，最值得带走的不是「让 Agent 替你写代码」，而是给团队内部引入一个明确的形式化字段，逼着每个人在写工单时就想清楚：这件事的成功标准，是写在测试里，还是写在人脑里。