九个月，五次组织改造

工程管理者 Will Larson 在 9 月 20 日的一篇复盘里，把团队今年的 AI 化过程列成了时间线：1 月让每位工程师每天使用 Claude Code；3 月把范围扩到非工程岗位；4 月发现本地开发卡在代码检出与工作树上，于是给每人开 10 个互相独立的工作区，按工作区而不是仓库来组织改动，一次就能跨前后端、基础设施、数据几个仓库生成合并请求；6 月把 Jira 换成 Linear，因为 agent 驱动开发缺一套可见、权限又简单的任务系统；7 月任务可见了却管不过来，于是自建了一套内部编排框架。

汽车工厂总装线

这串动作里真正有意思的不是工具名字，而是每一步的动因都来自上一个环节被打通后暴露出的新瓶颈。

「软件工厂」到底在做什么

他最近在尝试的模式叫软件工厂：不再逐条给人派活，而是围绕一个宽泛的目标循环，靠编排层自己推动进展。第一版实现只有四个动作——先审计项目目标的定义是否完整，项目里有没有一份写清目标、衡量方式和整体思路的文档，有没有能度量进展的看板或数据查询，缺什么就和人对齐补齐；再复核指标与任务状态，把新出现的工作补进项目，同步已经推进的任务；然后挑非阻塞的任务开工，多数时候就是写合并请求、改请求、催评审、提澄清问题；任务完成后做一次判断，项目描述还新鲜就接着做下一个，描述很久没更新就回到第一步重跑循环。

前提是目标能被度量

这套模式的成败不在模型能力，而在第一步。没有可度量的目标定义，自动化只会以更快的速度制造熵增：任务清单越长，返工越多，最后仍然要人来收拾。换个说法，软件工厂是把「把话说清楚」这件事的权重推到了最高——目标、指标、验收标准写不清楚的团队，先别急着上编排。

对小型交付团队的启示

对三五个人、同时服务多个客户的交付团队来说，这个思路可以降维使用，不必自建编排框架：把每个客户项目写成一份可度量的目标说明——要什么、怎么算做到、谁验收——再让 AI 在任务层循环推进。值得复制的不是那套内部框架，而是「先定义目标、再看指标、然后动手、定期重审」这个循环本身。