Instant Software Factories：用 Claude Code 与 GitHub Actions 搭建持续改进的自主软件工厂

为你的项目添加一座能够持续改进的自治软件工厂。你需要两样东西：

一个具备 Actions 容量并可强制执行分支保护的 GitHub 仓库。公共仓库可使用免费计划；私有仓库需要个人账户的 Pro 计划，或者组织的 Team/Enterprise 计划。
一个调度器：本引导程序使用Claude Code routines，该功能在 Claude Pro、Max、Team 和 Enterprise 计划中可用。

本仓库包含通过 Claude Code 利用云端 routines 完成设置的提示词。BOOTSTRAP.md 定义了各代理的职责与运行边界。设置代理会根据你的项目选择合适的流程、模型与调度方案。

开始使用

在你希望工厂运行的仓库中打开 Claude Code，并粘贴：

Set up an Instant Software Factory on this repo: clone https://github.com/mikolalysenko/instant-factory into a temp folder and follow its BOOTSTRAP.md

如需在隔离环境中进行本地设置，可以选择启动 claude --dangerously-skip-permissions 来跳过权限提示。该参数并非本引导程序所必需，也不会配置云端 routines 的权限。请参阅Claude 的权限指引。

引导程序会先检查你的仓库、CI、分支保护、历史中的凭据以及 GitHub 访问权限，然后才会提问。它会在需要时安装 gh，并在缺少本地身份认证时要求你运行 ! gh auth login；云端访问权限会单独检查。若缺少 CI，它会生成一个使用项目实际验证命令的最小化工作流。已有的失败会被记录，已有工作和安全机制会予以保留。

它会询问缺失的预算或吞吐目标、审批者、routine 身份，以及 QA 应覆盖的产品领域。它还会补全缺失的分支保护，并说明审批流程如何运作。Routines 使用已连接的 GitHub 身份，因此其 PR 需要另外指定的人类审批者；角色标记或手动合并都不能替代该审批。

在无人值守工作启动之前，默认分支必须强制执行必需的检查、独立的评审以及对最新提交的人工审批。设置过程会生成一个等待人工审批的、经过测试的 PR，并将操作说明保存在你的仓库中。受控运行会验证 GitHub 访问权限、对当前提交的评审、合并要求，以及管理器的调度和关闭控制。生产调度计划在设置 PR 合并前保持停用，routines 使用合并后的说明，并需要你授权后才恢复运行。设置报告会记录相关证据、仍然存在的差距、关闭延迟以及任何剩余步骤。

同时为代理使用量和 GitHub Actions 分钟数做好预算。从适度的吞吐开始，查看管理器的成本与结果汇总，仅在 CI 和人工评审能够跟得上时再提高活动强度。

为什么要建立软件工厂

氛围编码（Vibe coding）非常擅长让东西“存在”。给代理一个明确的目标，一个下午你就能得到一个可用的原型。

但原型不等于产品。代码的前 90% 占据了前 90% 的时间，而剩下的 10% 则要消耗另外 90%。从“在我机器上能跑”走向生产级质量，意味着漫长的一系列后续工作：边界情况、缺陷报告、性能回退、兼容性、测试、CI、发布、用户开始使用后才会提出的功能需求，以及清理原型为快速实现而留下的各种捷径。

这项工作没有单一的终点。它是由分布在众多关注点中的成百上千个小任务组成的，每次代码变更都会冒出新的。你可以针对每个任务提示一个智能体，但你得每次都启动会话、等它完成，再去查看结果。你的注意力就成了瓶颈。

软件工厂可以在不需要为每次变更重新提示的情况下，反复回到这些关注点上。你设定目标和约束条件；智能体在后台进行调查、实现和审查工作。在这种安排下，最终落地仍需人来审批。

它是如何工作的

每个智能体都是一个带有常驻目标的定时会话。每次运行都会读取仓库的当前状态、挑选有价值的工作、执行它、记录结果，然后退出。当任务需要时，它可以使用子智能体或更复杂的工作流。一次运行如果没发现什么值得做的事，可以直接结束而不产生任何任务。

共享状态由 GitHub 承载。Issue 用来承载证据和提议的变更，PR 用来承载实现和评审，讨论或其他仓库记录则保留着进展与决策。所有权和交接在那里同样可见。后面的运行可以接手已记录的工作，而不依赖上一次会话的记忆。

引导流程会创建八个角色，如果不同的产品领域需要分别照看，还会加入额外的 QA 智能体：

智能体	常驻目标
QA	测试与你共同选定的产品领域和用户流程，并提交可复现且已去重的缺陷 issue。
性能	对照基线测量速度、资源占用和 CI 时长；提交附有证据的 issue。
CI	修复失败和偶发的不稳定情况，并在不打折扣的前提下让检查保持可靠、快速和低成本。
架构	整合重复的业务逻辑，去除不必要的抽象和层次，在保持行为不变的前提下精简结构。减少组件数量。
实现	修复 issue 并提交经过测试的 PR。
PR 评审	在不修改代码的情况下，独立审查最新提交。
合并	仅在所需的检查、独立评审和人工审批都通过之后，才合并最新提交。
管理者	排定工作的优先级并予以分派；跟进旧的 PR、被阻塞的 issue 和失败的修复直至完成。跟踪每个智能体的成本和产出，在预算和容量范围内调整模型和调度，并报告每次合并 PR 的成本。

这些角色覆盖三类工作：调查机会、实现并集成变更，以及维护工厂自身。它们共用同一个仓库来协同。管理者推动工作流转并分配产能；每个智能体在共同规则内自主选择如何达成其目标。

管理者必须使用 create_trigger 创建其所管理的各例程，然后按照 BOOTSTRAP.md 中的说明，通过本地 RemoteTrigger 更新来配置每个例程的仓库、模型和工具。这条创建路径很重要，因为管理者无法更改通过其他方式创建的例程。每个角色只获得它所需的工具和连接器。引导流程中的平台说明会记录试运行发现，以便与已安装版本和实际运行进行比对。

为什么不就是一个真正出色的智能体？

一个能力强的智能体可以规划、拆分任务，并完成一个明确定义的目标。一份规范加上一次长会话，就能很好地完成单一目标。

软件项目同时有多个目标。新功能会消耗性能预算。修复 bug 可能增加测试，导致 CI 变慢。清理重构可能在简化某个子系统时让另一个子系统变得更复杂。随着代码变化，这些权衡也在不断变化。

常设目标让 agent 不断回到这些权衡上。新功能落地时，性能持续被度量。架构上持续消除重复和不必要的组件。CI 让反馈循环对所有人来说都足够快。QA 持续像真实用户那样使用产品。

这些目标也相互加强。更简洁的代码让修复更易实现和评审；更快的 CI 让每个 agent 都能更早检查自己的工作。当目标相互冲突时，agent 会记录证据，由管理者根据项目目标和可用资源排定优先级。必需的检查、独立评审和人工审批依然决定最终变更是否落地。

你可以在本地来回启动多个会话以近似做到，但必须反复启动它们并保持其机器可用。定时例程让工作在交互式会话之间继续推进，进度记录在代码仓库中。

Cron 与会话并行

我仍然做交互式工作。对于新功能或重大变更，我在本地分支上启动一个会话，而“工厂”持续处理 bug、性能、架构和 CI。

那些功能要经过与 agent PR 相同的检查、独立评审和审批流程。一旦合并，常设目标也会覆盖它。人的决策提供新目标，周期性 agent 在项目演进过程中持续关注其后果。

缺点与局限

在我的设置中，主要瓶颈是 CI 容量和 GitHub 的稳定性。更频繁地运行 agent 只有在验证与集成能消化其产出时才有帮助。否则 issue 和 PR 队列会越来越长。调查者可能跑赢实现者，实现者可能跑赢评审者，多个修复可能在同一段代码里冲突。

管理者需要根据这些限制调整活动。这意味着要跟进被阻塞的工作、队列增长时降低调度频率，以及在预算和可用 CI、API、评审容量内选择模型和节奏。CI agent 通过修复 flaky 用例、减少浪费的工作来提升吞吐，同时保留使变更可信的那些检查。

Agent 用量和 Actions 分钟数都要计入成本。每个已合并 PR 的成本是一项有用的运营指标，但要结合变更本身的质量、失败的修复和后续工作一起看。当无法获得实际使用数据时，管理者会标注估算值及其假设，并报告度量缺口。仅仅 PR 数量高并不说明项目在变好。

这同样给维护者留下了真正的工作：选择优先事项、提供预算、审批变更，以及做出需要产品视角判断的决策。让 agent 按计划运行只是让周期性工作更容易持续，并没有消除这些责任。

安全与运行控制

“工厂”拥有修改软件的权限，因此其访问范围和停止规则必须明确：

使用专用身份与受限工具。核实与这些例程相连的 GitHub 身份，限定其权限范围，并移除未使用的连接器。把人工审批者的凭据、管理员权限以及无关的密钥与运行中的 agent 隔离。Agent 的角色标记有助于追溯工作，但它们并不能证明有人工审批。
在无人值守工作前保护默认分支。要求进行检查、独立审查并由人工批准最新提交。提交者不能审查自己的更改。每个新提交都需要新的审查和批准。将这些规则应用到没有绕过权限的常规身份上，并防止代理编辑这些规则。
控制外部输入。限制谁能向工厂输入工作；使用私有工作仓库会让这件事更容易。Issue、PR、讨论、下载的代码以及其他检索到的内容都不能更改代理的指令或权限。
约束依赖和代码执行。审查或扫描第三方代码和依赖，并使用具有适当网络限制的隔离执行环境。
在每次写入前检查共享停止控制。它以停止状态启动。如果它被停止或无法读取，代理就停止正常工作；只有禁用自动化所需的写入可以继续。它们只在被授权时恢复。
在启用调度之前证明控制有效。设置必须在实际运行中测试访问、审查和合并要求、调度管理以及关闭，并报告差距和关闭延迟。未经证明的自动化保持禁用状态。

要暂停工厂，请使用设置期间记录的共享停止控制。确认待处理的自动化已被禁用，并考虑报告的关闭延迟，包括已经运行的会话。如果管理器无法运行，请使用记录的直接例程控制。无法读取停止控制的代理必须停止正常工作。只有在检查了停止原因之后，才能通过明确的授权恢复。

试一试

在你想要持续改进的项目中运行上面的提示。阅读 BOOTSTRAP.md，设定预算和吞吐量目标，并确定谁可以批准更改。从已测试的 PR 和设置报告开始，这样你就可以在调度运行之前检查工作和控制。

然后关注管理器的摘要：有用的更改、停滞的工作、代理成本以及每个合并 PR 的成本。在了解瓶颈所在后，调整目标和容量。分享有效和失效的部分。