尝试软件工厂模式

# 尝试软件工厂模式 来源：https://lethain.com/software-factory-experiment/ 2026年AI生态中一个有趣的挑战是，新且高效的模式出现的速度远超我的采用速度。我会发现几种模式，重新投入工作，然后在一个月后意识到又错过了四五种。今年采用Imprint模式的历程大致如下： 1. 一月：让每位工程师每天使用Claude Code 2. 三月：好的，我们也要让其他所有人每天使用Claude Code或Claude Cowork 3. 四月：本地开发受限于检出和工作树模型，因此创建约10个本地工作区，每个工作区独立检出所有仓库，并在工作区级别而非仓库级别操作，从而能够跨前端、后端、基础设施和数据单体仓库生成跨仓库拉取请求 4. 六月：天哪，代理驱动开发因缺乏通用任务管理系统而受到严重限制，该系统需要比Jira更高可见性和更低权限复杂度，因此我们将整个公司迁移到Linear，并完全停止使用Jira 5. 七月：糟糕，现在我们可以看到所有这些工单，其中许多都是琐碎的，但通过本地开发管理它们无法扩展，我们推出编排式工具，内部称之为“代理舰队”，类似于Stripe的Minions（https://stripe.dev/blog/minions-stripes-one-shot-end-to-end-coding-agents） 我最近一直在思考如何采用软件工厂模式（经过简单研究，这个术语在AI领域的具体起源归属稍显混乱，但我认为可能是Justin McCarthy在2026年2月发表的《软件工厂与代理时刻》（https://factory.strongdm.ai/）中提出的）。 软件工厂模式的核心是围绕一个广泛目标循环工作，然后依赖工具来推动朝该目标的进展。我们的第一轮实现相当基础： 1. 一个代理技能`/linear-project-loop`读取Linear项目，首先从以下维度审核该项目的目标定义：1. 描述项目目标、衡量方式和总体方案的RFC文档（在Notion中）；2. 衡量目标进展的Datadog仪表板或Snowflake查询。如果这些缺失，或者Linear项目完全缺失，它会与你协作创建这些缺失的工具。 2. 然后它审查项目的指标和问题状态。如果发现新工作，它会将这些问题添加到项目中。它更新已推进问题的状态。 3. 它基于项目当前状态处理非阻塞任务。这通常包括编写拉取请求、更新拉取请求、提醒审核、提出澄清问题等。 4. 当任务完成时，如果项目描述是最新的，它会接手下一个任务。如果描述已有一段时间未更新，它会从第一步开始重新运行循环。 目前我在本地工具中运行此模式，但它运行良好，我预计会将此行为转移到与我们分配临时任务相同的编排式工具中。 我特别喜欢工厂模式的一点是，它与我之前本地工作方式非常相似，同时迫使我认识到那些我无意中独占项目目标相关状态的地方。我之前已经让代理在特定Linear项目上迭代，但它们无法评估自己是否走在正确方向，或是否遗漏了必要任务。现在它们可以了。另一个对此极其有用的场景是发布后跟踪项目进展。例如，今年早些时候我发布了我们的密钥实现，但几个月过去我没有检查进展。如果采用率突然激增或错误率开始上升，我可能会错过，但以较低频率在发布后运行工厂模式能立即捕捉到这些变化。 最后让我感兴趣的是，这里所有组件的复合效应只有在你拥有其他组件时才会显现。例如，这种工厂模式依赖Datadog MCP和Snowflake访问来管理目标跟踪，但也依赖Linear作为公司工作的单一状态源，以及能够独立于你笔记本电脑执行工作的编排式工具。跟进如此多的迁移（https://lethain.com/migrations/）是一个引人入胜的行业时刻。