尝试软件工厂模式

2026 年人工智能生态系统面临的有趣挑战之一是，新的、有效的模式出现的速度比我采用它们的速度要快。我会找到一些，然后回去工作，一个月后才意识到我又错过了四五个。今年 Imprint 的采用周期是这样的： 一月：让每个工程师每天都使用 Claude Code 三月：好吧，让我们也让其他人每天都使用 Claude Code 或 Claude Cowork 四月：本地开发在签出和工作树模型上遇到瓶颈，而是创建约 10 个本地工作区，每个工作区对每个存储库都有独立的签出，并在工作区级别而不是存储库级别进行操作，因此它可以跨前端、后端、跨存储库生成跨存储库拉取请求，基础设施和数据单一存储库 June：哦，天哪，代理驱动的开发受到了严重限制，因为缺乏比 Jira 具有更高可见性和更少权限复杂性的通用任务管理系统，所以让我们将整个公司迁移到 Linear 并在 Jira 上硬停止。 July：哎呀，现在我们可以看到所有这些票证，其中许多都是微不足道的，但通过本地开发管理它们并不能扩展，让我们推出一个精心策划的工具，我们在内部将其称为“Agent Fleet”，大致思路是： Stripe 的 Minions 对我来说最近的问题是弄清楚如何采用软件工厂模式。 （经过一些简单的研究，这个术语的具体 AI 上下文起源有点混乱，但我认为它可能是 Justin McCarthy 在 2026 年 2 月的《软件工厂和代理时刻》中。）软件工厂模式在一个广泛的目标上循环，然后依靠工具来推动实现该目标的进展。我们实施的第一步是相当基本的：代理技能/线性项目循环，读取线性项目，并首先在这些维度上审核该项目的目标定义：Notion 中的 RFC，描述项目的目标、如何衡量这些目标以及衡量这些目标进度的一般方法 Datadog 仪表板或 Snowflake 查询 如果缺少这些内容，或者整个线性项目缺少，它会与您一​​起迭代创建这些缺少的工具。然后它会审查项目的指标和问题的状态。如果发现新工作，则会将这些问题添加到项目中。它更新已移动的问题的状态。它根据项目的当前状态处理非阻塞任务。这通常是编写拉取请求、更新拉取请求、进行审查、提出澄清问题等。当任务完成时，如果项目描述是新的，它将承担下一个任务。如果描述一段时间没有更新，它将从第一步开始重新运行循环。现在，我正在本地线束中运行此功能，但它运行得足够好，我预计该行为将由我们分配一次性任务的同一个精心策划的线束驱动。我特别喜欢工厂模式的一点是，它与我在本地的工作方式非常相似，同时迫使我认识到我在项目目标方面不小心为自己占据了部分州的地方。我已经要求代理迭代特定的 Linear 项目，但他们没有能力评估他们是否朝着正确的方向前进，或者是否缺少必要的任务。现在确实如此。这对我非常有帮助的另一个地方是检查发布后的项目。例如，我在今年早些时候发布了密钥实现，但几个月过去了，我却没有检查它的进展情况。如果我们看到采用率激增，或者错误率开始下降，我可能会错过它，但以不太频繁的发布后模式运行工厂会立即捕获它。最后一个让我感兴趣的想法是，这里的所有部分只有在你拥有其他部分的情况下才能复合。例如，此工厂模式依赖于可用于管理目标跟踪的 Datadog MCP 和 Snowflake 访问权限，但它也依赖于 Linear 作为公司工作的单一状态源，以及可以独立于笔记本电脑执行工作的精心设计的工具。跟上如此多的迁移是一个令人着迷的行业时刻。