2026 年 AI 生态系统中一个有趣的挑战是，新的有效模式涌现的速度比我采纳它们的速度还要快。我会找到一些，回去继续工作，一个月后才发现自己又错过了四五个。今年 Imprint 的采纳周期大致是这样的：
一月：让每位工程师每天都使用 Claude Code
三月：好，那也让其他所有人每天都使用 Claude Code 或 Claude Cowork
四月：本地开发在 checkout 和 worktree 模型上遇到瓶颈，于是改为创建约 10 个本地工作区，每个工作区对每个仓库都有独立的 checkout，并在工作区层面而非仓库层面进行操作，这样就能跨前端、后端、基础设施和数据 monorepo 生成跨仓库的 pull request
六月：天哪，智能体驱动的开发严重受限于缺乏一个通用的任务管理系统——它需要比 Jira 更高的可见性和更低的权限复杂度，于是让整个公司迁移到 Linear，并彻底停用 Jira
七月：哎呀，现在我们能看到所有这些工单了，其中很多都是琐碎小事，但通过本地开发来管理它们无法扩展，于是推出一个编排式 harness，我们内部称之为“Agent（智能体） Fleet”，类似 Stripe 的 Minions
对我来说，最近的问题是如何采纳软件工厂模式。（经过一番简单调研，这个术语在 AI 语境下的具体起源有点难以归属，但我认为可能是 Justin McCarthy 在 2026 年 2 月的《Software Factories And The Agentic Moment》中提出的。）
软件工厂模式是围绕一个宽泛的目标进行循环，然后依靠 harness 推动朝该目标前进。我们的第一版实现相当基础：
一个智能体技能 /linear-project-loop，它读取一个 Linear 项目，并首先从以下维度审计该项目的目标定义：Notion 中描述项目目标、目标如何衡量以及总体方法的 RFC；衡量这些目标进展的 Datadog 仪表盘或 Snowflake 查询。如果这些缺失，或者 Linear 项目完全不存在，它会与你一起迭代创建这些缺失的工具。
然后它审查项目的指标和 issue 状态。如果识别出新工作，就将这些 issue 添加到项目中。它还会更新已变动 issue 的状态。
它根据项目当前状态处理未被阻塞的任务。这通常是编写 pull request、更新 pull request、请求审查、提出澄清性问题等。
当任务完成时，如果项目描述是最新的，它就接着处理下一个任务。如果描述已有一段时间未更新，它就从第一步重新运行循环。
目前我在本地 harness 中运行这个，但它运行得足够好，以至于我预计会将这一行为迁移到我们用来分配一次性任务的同一个编排式 harness 中驱动。
我特别喜欢工厂模式的一点是，它与我本地的工作方式非常相似，同时迫使我认识到那些我无意中把项目目标的部分状态据为己有的地方。我之前已经在让智能体针对特定的 Linear 项目进行迭代，但它们无法评估自己是否朝着正确方向前进，或者是否遗漏了必要的任务。现在它们可以了。这对我另一个极其有帮助的地方是发布后对项目的检查。例如，我今年早些时候发布了我们的 passkeys 实现，但几个月过去了我都没有检查它的进展。如果采用率激增，或者错误率开始转变，我可能会错过，但以较低频率的发布后模式运行工厂就能立即捕捉到。
最后让我觉得有趣的一点是，这里的所有环节只有在拥有其他环节的情况下才能产生复合效应。例如，这个工厂模式依赖于能够使用 Datadog MCP 和 Snowflake 访问来管理目标跟踪，但它也依赖于 Linear 作为公司工作的唯一状态来源，以及一个能够独立于你的笔记本电脑执行工作的编排式 harness。跟上这么多迁移是一个迷人的行业时刻。
转载声明：本文为转载整理，原文版权归原作者及原站点所有。
原文来源：Will Larson
原文作者：Will Larson；如有侵权，请联系管理员删除。
