> ## Content Index > Fetch the complete content index at: https://www.hubwiz.com/blog/llms.txt > Use this file to discover other available public pages before exploring further. # StrongDM：软件黑灯工厂 - URL: https://www.hubwiz.com/blog/strongdm-build-a-lights-out-software-factory/ - Published: 2026-02-15T23:42:07.000Z - Updated: 2026-02-15T23:42:07.000Z - Description: 我看到一个团队实施了 Dan Shapiro 所称的黑暗工厂（Dark Factory）级别的 AI 采用，其中甚至没有人类查看编码代理正在生成的代码。 - Author: admin - Tags: AI, CODING AGENT, STRONGDM, #Import 2026-10-14 14:41 上周，[我曾暗示](https://simonwillison.net/2026/Jan/28/the-five-levels/?ref=hubwiz.com)我看到一个团队实施了 Dan Shapiro 所称的[黑暗工厂（Dark Factory）](https://www.danshapiro.com/blog/2026/01/the-five-levels-from-spicy-autocomplete-to-the-software-factory/?ref=hubwiz.com)级别的 AI 采用，其中甚至没有人类查看编码代理正在生成的代码。该团队是 StrongDM 的一部分，他们刚刚在[软件工厂和代理时刻（Software Factories and Agentic Moment）](https://factory.strongdm.ai/?ref=hubwiz.com)中分享了他们如何工作的第一个公开描述： > 我们构建了一个**软件工厂**：非交互式开发，其中规范 + 场景驱动编写代码、运行测试线束并在无人审查的情况下收敛。 \[...\] 在口头禅或咒语形式中： - 我为什么要这样做？（隐含：模型应该这样做） 在规则形式中： - 代码**不得由**人类编写 - 代码**不得由**人类审查 最后，在实际形式中： - 如果你今天每个工程师在令牌上至少没有花费$1,000，你的软件工厂就有改进的空间 我认为其中最有趣的毫无疑问是"代码**不得由**人类审查"。当我们都知道 LLM 有多么容易犯[非人类的错误](https://simonwillison.net/2025/Mar/2/kellan-elliott-mccrea/?ref=hubwiz.com)时，这怎么可能是一个明智的策略？ --- 我看到许多开发人员最近承认了[2025 年 11 月的拐点](https://simonwillison.net/2026/Jan/4/inflection/?ref=hubwiz.com)，其中 Claude Opus 4.5 和 GPT 5.2 似乎在编码代理可以可靠地遵循指令并承担复杂编码任务方面发生了转折。StrongDM 的 AI 团队于 2025 年 7 月成立，基于与 Claude Sonnet 3.5 相关的较早拐点： > 催化剂是 2024 年底观察到的一个转变：随着 Claude 3.5 的第二次修订（2024 年 10 月），长期代理编码工作流程开始复合正确性而不是错误。 到 2024 年 12 月，该模型的长期编码性能通过 Cursor 的[YOLO 模式](https://forum.cursor.com/t/yolo-mode-is-amazing/36262?ref=hubwiz.com)不可否认。 他们新团队以"无手写软件"规则开始——对于 2025 年 7 月来说很激进，但我看到截至 2026 年 1 月，大量经验丰富的开发人员开始采用。 他们很快遇到了一个明显的问题：如果你不手动编写任何东西，如何确保代码实际有效？让代理编写测试只有当他们不作弊和`断言为真`时才有帮助。 --- 这感觉像是现在软件开发中最重要的问题：如果实现和测试都是由编码代理为你编写的，你如何[证明你正在生产的软件有效](https://simonwillison.net/2025/Dec/18/code-proven-to-work/?ref=hubwiz.com)？ StrongDM 的答案受到[场景测试（Cem Kaner，2003）](https://en.wikipedia.org/wiki/Scenario%5Ftesting?ref=hubwiz.com)的启发。正如 StrongDM 所描述的： > 我们重新利用**场景**一词来代表端到端的"用户故事"，通常存储在代码库之外（类似于模型训练中的"保留"集），LLM 可以直观地理解和灵活地验证。 由于我们增长的软件的大部分具有代理组件，我们从成功的布尔定义（"测试套件是绿色的"）转变为概率性的和经验性的定义。我们使用**满意度**一词来量化这种验证：在所有观察到的轨迹中，其中有多大比例可能满足用户？ 这种将场景视为保留集的想法——用于评估软件但不存储在编码代理可以看到的地方——*非常迷人*。它模仿了外部 QA 团队的激进测试——这是传统软件中确保质量的昂贵但非常有效的方法。 --- 这引出了 StrongDM 的 **数字孪生宇宙（Digital Twin Universe）**概念——我看到的演示中给我留下最深刻印象的部分。 他们正在构建的软件帮助管理套连接服务的用户权限。这本身就值得注意——安全软件是你期望使用未经审查的 LLM 代码构建的最后一件事！ > \[数字孪生宇宙（Digital Twin Universe）是\]我们软件所依赖的第三方服务的行为克隆。我们构建了 Okta、Jira、Slack、Google 文档、Google 云端硬盘和 Google 表格的孪生，复制它们的 API、边缘情况和可观察行为。 有了 DTU，我们可以以远超生产限制的容量和速率进行验证。我们可以测试对实时服务危险或不可能的失败模式。我们可以每小时运行数千个场景，而不会达到速率限制、触发滥用检测或累积 API 成本。 --- 你如何使用编码代理克隆 Okta、Jira、Slack 等的重要部分？ 据我了解，这个技巧实际上是其中一个服务的完整公共 API 文档转储到他们的代理线束中，并让它构建该 API 的模仿，作为一个独立的 Go 二进制文件。然后他们可以让它在顶部构建一个简化的 UI 来帮助完成模拟。 **更新**：DTU 创建者 Jay Taylor 在[Hacker News](https://news.ycombinator.com/item?id=46924426&ref=hubwiz.com#46931812)上发布了一些额外的上下文，分享了一个关键的提示策略： > 我确实有一个初步的见解，导致了一个可重复的策略，以确保 DTU 与官方规范 SaaS 服务之间的高保真度： `始终使用最流行的公开可用参考 SDK 客户端库作为兼容性目标，目标始终是 100% 兼容性。` --- 有了他们自己的独立服务克隆——免于速率限制或使用配额——他们的模拟测试人员大军可以*疯狂*。他们的场景测试变成了代理脚本，在构建新系统时不断执行它们。 这张 Slack 孪生的截图也有助于说明测试过程如何工作，显示了一股模拟的 Okta 用户即将需要访问不同模拟系统的流程。 ![Slack 界面截图](https://www.hubwiz.com/blog/content/images/2026/02/strong-dm-slack.jpg) --- 这种快速旋转 Slack 子集的有用克隆的能力有助于演示这一新一代编码代理工具可能多么具有颠覆性： > 创建重要 SaaS 应用程序的高保真克隆始终是可能的，但在经济上从未可行。一代工程师可能*想要*一个完整的内存中 CRM 副本进行测试，但自我审查的建议是构建它。 [技术页面](https://factory.strongdm.ai/techniques?ref=hubwiz.com)也值得一看。除了数字孪生宇宙外，他们还引入了诸如[基因移植（Gene Transfusion）](https://factory.strongdm.ai/techniques/gene-transfusion?ref=hubwiz.com)之类的术语，用于让代理从现有系统中提取模式并在其他地方重用，[语义移植（Semport）](https://factory.strongdm.ai/techniques/semport?ref=hubwiz.com)用于直接将代码从一种语言移植到另一种语言，以及[金字塔摘要（Pyramid Summaries）](https://factory.strongdm.ai/techniques/pyramid-summaries?ref=hubwiz.com)用于提供多个摘要级别，以便代理可以快速枚举简短的摘要并根据需要深入查看更详细的信息。 --- StrongDM AI 还以一种相当不传统的方式发布了一些软件。 [github.com/strongdm/attractor](https://github.com/strongdm/attractor?ref=hubwiz.com)是**Attractor**，位于其软件工厂核心的非交互式编码代理。除了存储库本身根本不包含任何代码——只有三个 markdown 文件，详细描述了软件的规范，以及 README 中的一个注释，你应该将这些规范输入到你选择的编码代理中！ [github.com/strongdm/cxdb](https://github.com/strongdm/cxdb?ref=hubwiz.com)是一个更传统的发布，包含 16,000 行 Rust、9,500 行 Go 和 6,700 行 TypeScript。这是他们的"AI 上下文存储"——一个用于在不可变 DAG 中存储对话历史和工具输出的系统。 它类似于我的 LLM 工具的[SQLite 日志记录机制](https://llm.datasette.io/en/stable/logging.html?ref=hubwiz.com#sql-schema)，但更加复杂。我可能需要从这个项目基因移植一些想法！ ## 未来的一瞥？ 10 月份，作为受邀客人小组的一部分，我访问了 StrongDM AI 团队。 Justin McCarthy、Jay Taylor 和 Navan Chauhan 三人团队在三个月前才刚刚成立，他们已经有了他们的编码代理线束、他们的数字孪生宇宙半打服务的克隆以及运行场景的模拟测试代理大军的工作演示。这是在 Opus 4.5/GPT 5.2 发布一个月之后使代理编码显著更可靠的演示。 这感觉像是软件开发潜在未来的一个 glimpse，软件工程师从编写代码转变为构建然后半监视构建代码的系统。黑暗工厂。 ## 等等，每个工程师每天 $1,000？ 我在第一次发布的这篇文章中忽略了这个细节，但它值得一些严肃的关注。 如果这些模式确实将每个工程师每月 $20,000 添加到你的预算，对我来说就远没有那么有趣。在这一点上，它更多地成为一个商业模式练习：你能创造一条足够有利可图的产品线来负担得起以这种方式开发软件的巨大开销吗？ 构建可持续的软件业务看起来也完全不同，当任何竞争对手都可能只需要几个小时的编码代理工作就可以克隆你的最新功能。 我希望这些模式可以以低得多的投入投入使用。我个人发现每月 $200 的 Claude Max 计划给了我足够的空间来尝试不同的代理模式，但我也没有 24/7 运行 QA 测试人员大军！ 我认为即使对于不打算在令牌成本上花费数千美元的团队和个人，也有很多值得从 StrongDM 学习的地方。我特别感兴趣的问题是什么让代理能够在不需要审查他们生成的每一行代码的情况下证明他们的代码有效。 --- **原文链接：** [How StrongDM's AI team build serious software without even looking at code](https://simonwillison.net/2026/Feb/7/software-factory/?ref=hubwiz.com) **汇智网翻译整理，转载请标明出处**