Instant Software Factory：用 Claude Code 定时例程搭建自主软件工厂

带声音观看。

添加一个自主软件工厂，持续改进你的项目。你需要两个要素：

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

此仓库包含通过 Claude Code 使用云例程进行设置的提示词。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 以跳过权限提示。此引导不需要该标志，也不会配置云例程的权限。请参阅 Claude 的权限指南。

引导会在提问之前检查你的仓库、CI、分支保护、历史记录中的凭据以及 GitHub 访问权限。如果需要，它会安装 gh，并在缺少本地身份验证时要求你运行 ! gh auth login；云访问权限会单独检查。缺少 CI 时，会使用项目实际的验证命令生成一个最小工作流。现有故障会被记录，现有工作和保护措施会被保留。

它会询问缺失的预算或吞吐量目标、审批人、例程身份以及 QA 应覆盖的产品领域。它还会解决任何缺失的分支保护，并说明审批将如何进行。例程使用连接的 GitHub 身份，因此它们的 PR 需要单独的人工审批人；角色标记或手动合并不能替代该审批。

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

为代理使用量和 GitHub Actions 分钟数都做好预算。从适度的吞吐量开始，检查管理器的成本和结果摘要，只有在 CI 和人工审查能够跟上时才增加活动。

为什么需要软件工厂

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

但原型不是产品。代码的前 90% 花费前 90% 的时间，而后 10% 花费另外 90% 的时间。从“在我的机器上能运行”到生产质量意味着漫长的后续工作：边缘情况、错误报告、性能回归、兼容性、测试、CI、发布、用户使用后提出的功能，以及清理原型为达到目的而采取的捷径。

这项工作没有唯一的终点线。它是分散在许多关注点上的数百个小任务，而且每当代码发生变化时就会出现新的任务。你可以通过提示让智能体完成每个任务，但那样你就要启动每个会话、等待它、检查结果。你的注意力成了瓶颈。

软件工厂会不断回到这些关注点，而无需为每次变更重新提示。你设定目标和约束；智能体在后台调查、实现和审查工作。在这种设置下，人类仍然批准最终落地的内容。

工作原理

每个智能体都是一个带有常设目标的计划会话。每次运行都会读取仓库的当前状态，选择有用的工作，执行它，记录结果，然后退出。当任务需要时，它可以使用子智能体或更复杂的工作流。如果一次运行没有发现值得做的工作，它可以在不创建工作的情况下结束。

GitHub 保存共享状态。Issue 承载证据和提议的变更，PR 承载实现和审查，讨论或其他仓库记录保存进展和决策。所有权和交接在那里也可见。后续运行可以接续已记录的工作，而不依赖上一个会话的记忆。

引导过程会创建八个角色，如果不同的产品领域需要单独关注，还会增加额外的 QA 智能体：

这些涵盖三类工作：调查机会、实现和集成变更，以及维护工厂本身。它们使用同一个仓库进行协调。经理保持工作推进并分配容量；每个智能体在共同规则内选择如何追求其目标。

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

为什么不用一个非常优秀的智能体？

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

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

常设目标让智能体不断回到这些权衡上。性能在功能落地时持续测量。架构持续减少重复和不必要的组件。CI 保持反馈循环对其他所有人足够快。QA 持续像用户那样使用产品。

这些目标还会相互强化。更简单的代码让修复更容易实现和审查；更快的 CI 让每个智能体更早检查自己的工作。当目标冲突时，智能体记录证据，管理者根据项目目标和可用容量确定优先级。必需的检查、独立审查和人工批准仍然管辖最终变更。

你可以通过同时管理多个本地会话来近似实现这一点，但那样你就得不断启动它们并保持机器可用。定时例程让工作在交互式会话之间继续进行，进度记录在仓库中。

定时任务与会话结合

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

该功能要经过与智能体 PR 相同的检查、独立审查和批准流程。一旦落地，常设目标也会覆盖它。人类指导提供新目标，而周期性运行的智能体在项目演进过程中持续关注其后果。

缺点与局限

我的设置中的主要瓶颈一直是 CI 容量和 GitHub 可靠性。更频繁地运行智能体只有在验证和集成能吸收其产出时才有帮助。否则你会积累一堆问题和 PR。调查者可能跑得比实现者快，实现者可能跑得比审查者快，多个修复可能在同一处代码中冲突。

管理者需要根据这些约束调整活动。这意味着跟踪被阻塞的工作，在队列增长时减少调度，并在预算以及可用的 CI、API 和审查容量内选择模型和调度。CI 智能体通过修复不稳定测试和减少浪费的工作来提高吞吐量，同时保留让变更可信的检查。

智能体使用量和 Actions 分钟数都计入。每个已合并 PR 的成本是一个有用的运营指标，同时还要看变更的实质内容、失败的修复和后续工作。当实际使用量不可用时，管理者会标注估算值及其假设，并报告测量缺口。仅凭高 PR 数量并不能说明项目是否在改进。

这也给维护者留下了实际工作：选择优先级、提供预算、批准变更，以及解决需要产品判断的决策。调度智能体让重复性工作更容易持续；它并不会消除这些责任。

安全与操作控制

工厂有权更改软件，因此其访问权限和停止规则需要明确：

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

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

相关工作

Gas Town 通过编排工具包和 Beads 工作账本，在多个编码代理之间追求自主工作。Instant Software Factory 使用计划例程和 GitHub 现有的议题、PR 和讨论进行协调。

Stripe 的 Minions 在隔离的开发环境中无人值守地运行编码任务，并生成 PR 供人工审查。这里的重点在于长期目标，即持续产生并完成有用的工作。

StrongDM 的 Software Factory 使用指定的意图和场景验证来驱动实现，无需人工代码审查。此引导流程在合并前保留对每项更改的独立审查和人工批准。

试一试

在您希望持续改进的项目中运行上述提示。阅读 BOOTSTRAP.md，设定预算和吞吐量目标，并确定谁可以批准更改。从经过测试的 PR 和设置报告开始，这样您就可以在计划运行之前检查工作和控制措施。

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