使用 Claude Code 和 Linear 构建 AI 软件工厂

软件工厂最近几周火得一塌糊涂。所以我自己也搭了一个。

下面是我学到的经验、它的运作方式，以及如何在一个下午就把它搭起来。

我的目标

它必须非常简单，能直接跑起来，不需要太多人工盯梢。理想情况下，完全基于我现有的 Claude 订阅就能运行。

听起来很天真，但本质上，除非它能轻松融入我现有的工作流程，否则它不会是一个能长久使用的东西。我不想为了用这个新系统而改变自己所有的习惯。根据经验，如果发生这种情况，它长期来看对我就行不通，最终会被遗忘。

所以我没有把它当作一个庞大的工程来攻坚，而是分成了两个清晰的阶段：

预分诊——确定“要做的”事情
实施——实际“做”事情

中间是 Linear，它是所有待办工作的真相来源。

每个软件工厂都必须有这样一个集中的工作存储库，无论是 GitHub issues、Linear 还是其他什么。它应该就是你已经在用的工具，这样任何系统都能轻松扩展，把工作加进去，供后续的 Agent 或人类来领取和完成。

Linear 上通过系统健康检查循环自动生成的 issue

整个流水线有刻意划分的接口，让构建软件工厂的过程变得可控：

创建工作（循环 + MCP）
存储工作（Linear）
完成工作（SDLC Agent）

通过拆分，你不需要同时构建预分诊和实施两部分（我实际上建议不要这样做，以避免过度工程化）。Linear 让“要做的”和“正在做的”之间的接口变得清晰、易于扩展。

预分诊步骤

在上图中，工作从左向右推进。左侧是创建工作的地方，包含任意数量的系统（无论是人类、Agent 还是 API），它们会把需要做的事情添加进来。所有在这个预分诊步骤中产生的输出都会被放入 Linear。

在 Claude 云环境中运行的几个循环

在这个步骤中，我们有三个主要的循环：

系统健康检查循环（即 bug 发现器）——每天凌晨 5 点运行，连接到几个 MCP 服务器：Posthog 用于错误追踪；Vercel 用于系统诊断；Linear 用于创建 issue。
用户体验改进与客户反馈循环——每周一上午 9 点运行，扫描所有新反馈、所有来自 Intercom/Fin 的客户支持聊天记录以及所有 Posthog 会话回放。会话回放是一座金矿。你可以看到用户在哪里愤怒点击，或者在哪里感到困惑和迷茫。
流失分析循环——每天凌晨 6 点运行，调查过去 24 小时内所有点击取消的客户。它会从 Stripe 拉取支付和用户数据（包括电子邮件/位置），然后在 Posthog 中查看该用户的会话回放，了解他们在取消前做了什么。我们从 Supabase 拉取使用数据，判断他们是否属于错误的 ICP、是否从未体验过那个“哇”时刻、或者是否遇到了 bug。报告会发送到 Slack，如果问题与客户流失相关，Agent 会创建（或评论）issue 以提高优先级。

为了实际持续运行这些 Agent，我保持简单，使用了 Claude Code Cloud Routines。

没有过度工程化——不用 Hetzner VPS，不用喝咖啡的 Mac mini 等等。这是目前我发现的最简单的方法，可以利用你现有的 Claude Code 订阅，创建始终在线的 Agent，通过定时任务或 Webhook 事件触发。至于那些说“供应商锁定怎么办”的人——这只是一些文本而已。你完全可以把这个提示复制到任何地方，我只是想要一个设置最简单、最便宜、又稳定可靠的东西。

另一个使用 Claude Code Cloud Routines 的原因是，Anthropic 的云环境与本地运行 Claude 高度一致。

Cloud Claude Routines

显然，它们没有你的环境变量（如果需要，可以在云环境设置中添加），但如果你通过桌面应用的连接器设置了 MCP 连接，那么无论是本地 Claude CLI 还是远程 Claude 都能使用它们，这与 Codex 不同。这对我来说是个杀手级特性，也是这些预分诊 Agent 循环能如此顺利运行的关键。它还让你可以轻松并行运行多个会话，而不用担心笔记本的内存。

如果你只实现这个预分诊步骤，即使不构建下一步来完成工作，你也能获得很大的效率提升。

从小处着手，先做一个循环，试试看，优化它，然后再添加更多。找出你今天就能创建的、能为你的现有 issue 追踪器带来高质量新工作的常规流程，然后沿用你目前实施工作的方法。

实施步骤

第二步最基本的版本是：给你的 Agent 一个 issue ID，让它去完成。这就是现在大多数人使用 Agent 时已经在做的事情。然而，如果你正在读这篇文章，这很可能不是你想要的，因为你成了循环中的瓶颈——你需要直接在一个会话中手动启动 Agent。

相反，我构建了一种从 Linear 直接触发远程 Claude Code 会话的方式。

从 Linear issue 到 Claude

它的工作流程是这样的：

首先，确定如何触发新的 Claude 会话。对我们来说，我们在 Linear issue 上添加一个“auto”标签，从而启动新任务。
然后，Linear 向我们的内部 Webhook API 服务（一个新建的内部 Hono 应用）发送 Webhook 事件，该服务解析事件，然后将正确的信息转发给 Claude Routine。
最后，这个轻量级 API 服务向 Anthropic 发起 POST 请求，用初始提示触发 Claude routine。

使用“auto”标签作为触发器，让我们能够控制新 Claude 会话的自动执行。

默认情况下，预分诊步骤不会包含这些“auto”标签，需要人工添加标签来触发 Agent 开始工作（保持人在回路中）。这就是为什么我们把第一步称为预分诊步骤——因为仍然需要某些东西来决定实际做什么工作，无论是通过人工参与，还是通过某个 Agent 循环监视新 issue 并启动新的实施会话。

然而，由于添加标签也可以由 Agent 轻松完成，我们可以让预分诊循环默认创建带有“auto”标签的新 issue，从而自动启动新的 Claude 会话。使用标签成为一种非常灵活的方式，既可以由 Agent 自动开始新的实施工作，也可以由我们人类来启动。

一个用于启动 Claude 会话的轻量级路由服务

由于 Linear 支持 Webhook，整个“添加标签时推送”的机制是可行的。唯一的缺点是我们需要一个公共 API 来接收这些 Webhook，并格式化事件和负载数据以触发 Claude Code。这个新服务还添加了正确的认证头，这就是为什么你不能让 Linear 直接触发 routine。

或者，你也可以设置一个定时运行的 routine，每隔一段时间检查一下，尝试实施任何带有 auto 标签且尚未开始进行的新 issue。

对于实际的 routine 提示，我建议构建一个可复用的技能，它涵盖整个 SDLC，命名为类似于 /implement 或 /do 的东西，这样你就可以轻松地输入 */do ISSUE-NNN*。这个技能文档化了如何正确完成获取 issue 上下文、实施工作、在浏览器中验证、创建 PR 以及监控评论的步骤。

然后，由 Linear 事件触发的 Claude routine 提示可以非常简单。以下是我的提示：

获取提供的 issue，并使用 /do 技能来实施请求的变更并创建一个拉取请求。只获取确切提供的 issue。如果它已经完成或正在处理中，则停止。
issue 引用不会出现在本消息中——它会作为单独的后续消息，包裹在 \<routine-fire-payload>\ 标签中，在本消息之后立即发送到同一会话中。在检查 \<routine-fire-payload>\ 消息并确认引用的 issue 确实不存在之前，先不要下结论说 issue 不存在或没有提供。
当你开始工作时，请评论该 issue，将其状态设置为“进行中”，并在进展过程中用任何有意义的信息更新 issue。始终为 Linear issue 评论添加 [Claude] 前缀。

所以现在，你有了通过 API 触发的并行 Claude Remotion 会话，它们正在实施 issue、创建 PR（并希望通过 Playwright 或 Agent Browser 验证它们的工作）。

这基本上就是一个完整的软件工厂——完全可观测，在你睡觉时运行，并且完全依赖你的 Claude Code 订阅。