四台机器加健康巡检：大项目的并行玩法

有人把"大项目的 agentic 编码工作流"简化成五步：花 10–30 分钟写设计文档 → 交给一个协调者 Agent（前沿模型、推理拉满）→ 让协调者把活通过 SSH 并行铺到 4 台独立机器（他做浏览器项目，构建与测试极吃 CPU 和内存）→ 让协调者定期对所有 worker 做健康巡检（谁卡死、谁在崩溃循环）→ 然后放手让它们跑。

两条很实在的观察：项目动辄跑几天，不是几小时；他基本不指挥，只是隔段时间出于好奇去看进度——等待期间他处理邮件、开会、几分钟就能收掉的小 bug。这套流程跑起来的前提也得说清：设计文档要写到"完成"有明确标准，四台机器的沙箱与权限彼此隔离，否则巡检能救卡死、救不了方向性错误。

我的看法：这份流程最值得抄的是"协调者 + 健康巡检"这一对。并行 worker 最怕的不是慢，而是悄悄死掉或者陷入崩溃循环——由一个推理拉满的 Agent 专门负责巡检和救场，等于把"运维"这件事也 agent 化了。

而"只写设计文档、不微操"正是当下人该站的位置：你负责定义完成，系统负责跑完，中间的调度、重试、资源分配交给协调者。

他那句收尾也算一个时代注脚：AI 之前他就热爱开发，现在更爱——因为任何人如今都能站上过去要"大型软件组织负责人才有的高度"。

想抄这套流程，起步只需要三样东西：一页设计文档（写清目标、完成标准、不能碰的边界）、一个协调者的系统提示（并行拆分、定期巡检、卡死即换人并把结论回传）、以及各自隔离的执行环境。剩下的就是等——这也是这套玩法和"盯着聊天框等生成"最大的区别：人从监工变成了验收方，时间从分钟级的等待换成了天级的推进。