硅基团队 S1E10: 人什么时候该介入

凌晨两点，OPC loop（我的 AI 自动化工程流水线）已经跑了 21 个 tick（执行轮次）。44 个 subagent（AI 子代理）各司其职，103 个测试全绿，tsc 零报错。我打开浏览器看了一眼成果——

一个精美的 Google Calendar 翻版。

我说了一句话：“主界面应该是 agent feed，不是日历。”

整个方向推翻了。之前 21 个 tick 做的东西，Calendar 从主界面降级成了 /calendar 子页面。

这不是一个”AI 不行”的故事。恰恰相反——AI 执行得非常好，好到 23 小时、$92（Claude Opus，95% cache hit）全花在了错误的方向上。这是一个关于”人什么时候该出手”的故事。

S0 的书里我讲过 OPC loop 的设计原理（ch04）。但直到连跑了三个项目、烧了 $589、积累了 125 小时的 loop 数据，我才真正理解一件事：loop 最大的风险不是执行质量，而是方向——而 loop 对方向完全是盲的。

信号一：方向错了，loop 不会告诉你

家庭日历项目是我的第一次 overnight OPC loop。23 小时，$92，44 个 subagent，35 个 git commit。数字很漂亮。

但有一个根本问题：OPC loop 执行计划，不生成计划。plan 是我写的，loop 只负责照着做。

上一轮 loop 产出了一个 Google Calendar clone——月视图、周视图、事件弹窗，很专业。但我一打开就知道不对。家庭日历的核心问题不是”事件存在哪里”，而是”家人凭什么每天打开它”。一个需要你主动去查的 Calendar，跟纸质墙历没区别。真正的价值是 agent 主动帮你记、提醒你、跨渠道通知你。

触发信号：产出物完美但方向错误。所有测试通过，所有代码 clean，但解决的不是真正的问题。

最小干预：一句话。“主界面应该是 agent feed。” 不需要写 spec，不需要画原型。一句话就够。

这里有一个反直觉的发现：loop 越高效，方向错误的代价越大。如果 loop 每小时只能做一点点，你有足够的时间发现问题。但当 44 个 subagent 全力冲刺时，你眨一下眼它已经在错误方向上跑了 21 个 tick。

但这也意味着一个隐性成本：你不知道什么时候 loop 会跑偏，所以你得保持关注。“一句话就扳回来”听起来轻松，但发现这个时机需要你在凌晨两点还看了一眼浏览器。autonomous 不等于 unattended。

信号二：Context 爆了，系统降级但没死

Pi-Math 项目是一次更长的 OPC loop。47 小时，40 个 tick，76 个 subagent，$347。中间发生了三次 context blowout（对话上下文溢出）。

什么叫 context blowout？就是 Claude 的对话窗口满了。130 个 chunks，1189 条消息，37M input tokens 塞不下了。触发自动 compaction——之前的对话历史全部压缩，代码细节、决策原因、哪些 test 已经 fail 过，全部丢失。

相当于每隔十几个小时，换一个新人接手你的项目。

触发信号：loop 的行为从”有目标地推进”变成”反复尝试已经失败的方案”。

有一个关键设计救了它：loop-state.json + plan.md 是持久化的 ground truth。每个新 tick 不依赖对话历史——它重新读这两个文件，知道自己该做什么、怎么验证。这不算”自愈”——更准确地说是 degraded mode（降级运行），丢了细节但没丢骨架。

最小干预：通常不需要。但要注意：这是因为 loop-state 和 plan 写得足够详细。如果你的 plan 只有一句话”实现用户认证”，那 context blowout 之后 loop 就真的瞎了。

信号三：Harness 说不行，就是不行

639 个测试的那个 session，55 小时，$150，20 个 tick 全部完成。最关键的干预发生在 tick 16。

Tick 16 是一个 review 轮次，harness（机械化质量检查点，S0 书里叫 Mechanical Gate）要求提交至少 2 个评审文件，每个必须带严重度标记。AI 提交了 1 个文件，没有标记。Harness 直接 reject。

这不是 AI 偷懒——它是在 55 小时连续运行后，review 质量自然下降的结果。但 harness 不关心为什么。不满足 protocol 就打回。这是 S0 书里讲的 Mechanical Gate 的核心原则——机器检查比人类 reviewer 更严格，因为它不接受”差不多就行”。

触发信号：harness reject。看到 reject log 就知道 AI 在 satisficing（凑合交差）。

最小干预：检查 reject 原因，通常不需要你动手——AI 被打回后会自己重做。但它暴露了一个现象：AI 的输出质量不是恒定的，会随 session 时长下降。

信号四：环境崩了，人来砍范围

同一个 639 测试的 session 里，还有两次人工干预值得单独讲。

第一次：flaky test。test_billing_defaults.py 单独跑通过，混合跑随机 fail。Root cause 是 importlib.reload 污染了全局 import state。AI 想把它标成低优先级等批量处理。我判定这是 P0——flaky test 是信任根基的裂缝，哪怕只有一个。单独 commit 修掉（891afe27）。

第二次：L2 integration tests 全军覆没，pydantic 版本不兼容。AI 想修依赖。我说：跳过 L2，专注 L1 + L3。修依赖版本超出 test coverage sprint 的范围——这不是逃避问题，是范围管理。

还有一次 rate limit：GitHub Enterprise token quota 被 55 小时高强度调用打穿了。429 错误。解法？等。没有 workaround。

触发信号：环境问题（依赖冲突、rate limit、外部服务挂）导致 loop 卡住。

最小干预：一个范围决策。“P0，现在修。” 或者 “跳过，不在范围内。” 或者 “等。” 人类的价值不在于技术能力，而在于判断什么重要、什么可以等。

信号五：Loop 不会自己停

Pi-Math 那个 session 还有一个教训。Pipeline 跑完后，loop-state.json 已经标记 status: pipeline_complete。但 loop 没停——它进入了 idle polling，每 20 分钟空轮询一次，狂吃 270M cache_read tokens（约 $81），零产出。

我试了所有能想到的办法取消它：CronList 返回空，CronDelete 没有 job ID，cancel 命令全部无效。Dynamic mode 下，Claude 无法终止自己的 loop。

唯一解法：Ctrl+C。人工拉闸。

这是一个架构 bug，不是一个”信号”——但它暴露了 autonomous loop 的一个硬限制：目前的实现没有 graceful shutdown 机制。$81 的纯浪费是学费。

触发信号：pipeline 完成但 token 消耗不降。

最小干预：拉闸。但前提是你得在那儿。

至少五种信号

三个项目，125 小时的 autonomous loop，$589 的 token 成本。我遇到了至少五种”人该出手”的信号：

说”至少”，是因为三个项目不可能覆盖所有情况。也许还有信号六、七、八——但我还没遇到。这个框架是从实战中长出来的，不是从理论推导出来的。

这五个信号有一个共同特点：它们都不是 AI 能力问题——至少目前不是。方向判断、范围管理、系统终止，这些是人类的工作。但有些（比如信号五的 graceful shutdown）明确是工具缺陷，未来应该被修掉。

但别忽略隐性成本：autonomous loop 需要人保持 on-call 状态。你不知道什么时候会触发这些信号。“一句话就扳回来”的前提，是你凌晨两点还在看浏览器。如果你不在，loop 会继续高效地往错误方向冲刺，或者空烧 $81 的 tokens。

EP05 说过，“一句话反馈让质量分从 0.487 跳到 0.68”（那个分数是 OPC 内部 review agent 的评分，满分 1，不是人类评分——信号本身有参考价值，但别过度解读绝对值）。现在你知道为什么了。不是因为那句话有多聪明，而是因为它出现在了对的时间——方向信号触发的那一刻。

硅基团队 S1: AI 能写代码，凭什么信它？ ← S1E09: 让坏结果变小 | S1E11: 翻车之后怎么办 →

注：S1E09 及之前的集使用 opc-s1- 前缀。从 E10 起统一使用 st-s1- 前缀（Silicon Team），旧链接保持不变。