不写、不看、不审查：这家安全公司决定不再让人类碰代码，还把这套模式开源了
没人写代码，也没人看代码，软件照样交付？
2026 年 2 月，一家专注于基础设施安全的公司 StrongDM 公开了一套“软件黑灯工厂”式的生产线成果。
在这个生产线里，人类不再直接写代码、也不承担代码审查；开发从交互式协作变成“把 spec 和场景喂给系统”。随后由 Agent 自动生成代码、运行测试 / 评测 harness，并在反馈回路里反复迭代，直到结果收敛、可以交付为止。团队把这套玩法写进章程，最重要的只有一句话——No hand-coded software。
StrongDM AI 还不寻常的开源了它们：
其中一个仓库是：https://github.com/strongdm/attractor。
这是他们“软件工厂”体系中最核心的非交互式编码 Agent。不过，这个仓库本身一行代码都没有：里面只有三份 Markdown 文件，极其细致地描述了软件的完整规格说明（spec），以及 README 里的一句提示——把这些规格说明交给你选择的编码 Agent 去执行即可。
另一个仓库 https://github.com/strongdm/cxdb。
这个则更接近传统意义上的软件发布：包含 1.6 万行 Rust、9500 行 Go，以及 6700 行 TypeScript。这是他们的 “AI Context Store”——一个用于存储对话历史和工具输出的系统，数据以不可变 DAG 的形式组织。
在 Hacker News 的讨论中，很快就有开发者按图索骥，实际跑了一遍这套流程。他表示，自己仔细阅读了 Attractor 仓库中的文档，并严格按照 StrongDM 提供的规范，让 Claude 基于 spec 构建了一个完整应用。最终生成的是一个可以直接使用 Claude API Key 的 AI 代理，其整体质量“明显好于让模型自由发挥时生成的结果”。
让他印象最深的，是这套规格说明的体量和细节程度：整套 spec 大约 6000–7000 行，覆盖了行为约束、接口语义以及系统边界。“我以前给代理布置项目时，规格说明最多也就一页纸，这次的细节密度让我非常震惊。”
当然，这次开源并不是一个“打磨完毕”的展示版本。代码一经放出，Hacker News 上就有开发者迅速上手检查，指出其中存在疑似 bug、Rust 反模式，以及相对宽松的错误处理方式。对此，StrongDM AI 团队成员 Jay Taylor 在评论区回应称，这批项目“是最近几天才决定开源的”，尚未经过充分的技术优化，目前已经安排代理继续对 CXDB 进行清理和改进。
这套实践也很快得到了学界的点名。沃顿商学院研究 AI 与组织变革的教授 Ethan Mollick 在转发 StrongDM 的公开内容时直言，这是一次“真正激进的软件开发方式”：“几乎没有任何人类介入。即便这种方式未必适用于大多数场景，我们也需要更多这样的跳级式设想，去重新设计流程，而不是只把 AI 塞进旧流程里。”
在他看来，真正有价值的进步，不是在原有流程上“多加一点 AI”，而是 围绕 AI，把流程本身重做一遍。
一条“禁止手写代码”的内部实验线
StrongDM 是一家专注于基础设施访问与身份安全的公司，核心工作是管理人类与非人类身份如何安全地连接到数据库、云资源和各类内部系统。
而他们的 AI 团队成立于半年前， 2025 年 7 月 14 日这天，Jay Taylor、Navan Chauhan 与 StrongDM 的联合创始人兼首席技术官 Justin McCarthy 一起，正式把一条原本分散在内部的探索工作，独立成一个专门的团队。
新团队成立后，第一天的工作并不是写代码，而是写一份章程。Justin McCarthy 在回顾中提到，在团队成立的第一个小时，他们就先明确了一组接下来必须遵守的约束条件。
代码不得由人类编写。
代码不得由人类审查。
如果你今天在每位人类工程师身上花费的 token 成本还不到 1000 美元，那么你的软件工厂还有很大的改进空间。
在 StrongDM 自己的回顾里，这个决定并不是一时冲动。其背景要追溯到 2024 年末。随着 Claude 3.5 在 2024 年 10 月的第二次修订发布，团队开始观察到一个此前并不常见的变化：在长时序的 Agentic 编程任务中，结果开始叠加正确性，而不再只是不断叠加错误。
到了 2024 年 12 月，这一变化已经可以通过 Cursor 的 YOLO 模式清晰地观察到。
StrongDM 在博客中写道，在此之前，将 LLM 反复用于编码任务，往往会累积误解、幻觉、语法错误、依赖不兼容等问题，最终让系统“慢慢坏掉”；而结合 YOLO 模式，Anthropic 的更新模型第一次展现出他们后来在内部称之为“非交互式开发”或“成长型软件”的雏形。
在这样的背景下，新成立的团队从一开始就确立了一条极端的实验前提：不允许任何手写代码。在 2025 年 7 月，这听起来依然相当激进。
其中最耐人寻味的，是第二条规则：代码不得由人类审查。毕竟大家都很清楚，大语言模型极其容易犯下一些“非人类式”的错误；在这样的前提下，彻底放弃人工 code review，本身就显得反直觉。
更何况，安全软件向来是最不愿意交给“未经人工审查的 LLM 代码”去支撑的一类系统。
规则落地后，问题也随之出现：如果什么都不手写，怎么确保代码真的能跑？让 Agent 自己写测试，只在一个前提下有用——它们不会“作弊”，比如直接写个 assert true。
这也迅速被他们提炼成一个更根本的问题：当实现和测试都由编码 Agent 生成时，你要如何证明自己交付的软件是可工作的？StrongDM 的答案，受到了场景测试（Scenario Testing，Cem Kaner，2003） 的启发。他们是这样描述的：
我们重新定义了“场景（scenario）”这个词，用它来表示一个端到端的“用户故事”。这些场景通常存放在代码库之外（类似模型训练中的“留出集”），既能被 LLM 直观理解，又可以灵活地进行验证。
由于他们构建的软件本身往往就包含 Agentic 组件，StrongDM 也随之放弃了“测试全绿”这种布尔式成功定义，转而采用一种更接近真实体验的度量方式。他们引入了“满意度（satisfaction）”这个概念，用来量化验证结果：在所有场景中观察到的执行轨迹里，有多大比例可能令用户满意？
他们把这些场景当作“隔离集”，不存放在编码 Agent 能直接访问的地方，用来评估系统整体行为。这个设计本身就很有意思，它在某种程度上，模拟的是传统软件工程中一种极其昂贵、但也极其有效的做法——由外部 QA 团队执行的强力端到端测试。
合成场景策划与塑造界面
从软件工厂的整体原则来看，StrongDM 把这一切总结为一条清晰的流程：“种子 → 验证 → 反馈回路”。系统先接收一个最小起点——几句话、截图，或一个已有代码库；然后在尽量贴近真实世界的验证环境中跑场景，把输出持续反馈回输入，让系统在闭环中自我纠错、不断叠加正确性；循环会一直运行，直到所有被隔离出来的场景不仅通过，而且能持续通过。token 被他们形容为这条生产线的燃料。
将“验收”交给 spec？
在 StrongDM 的软件工厂里，spec 并不是用来给人看的设计说明书，而是整个系统能够启动、纠偏和收敛的核心输入。
在传统开发流程中，spec 更多是一种“对齐工具”：它帮助工程师理解要做什么，但真正的实现细节、权衡和妥协，往往发生在代码和 code review 过程中。而在 StrongDM 的设定下，当“人不写代码、人不看代码”成为前提，spec 的角色被彻底前移——它不再是参考材料，而是事实上的控制面。
团队要求系统能够“从层层递进的自然语言规范中生长”，并且必须能够在“不对源代码做语义层面检查的情况下完成验证”。在这种设定下，“验收”本身也被重写了。spec 与场景（scenario）一起，构成一个不断运行的评测基准：模型生成的行为是否符合规范，不是靠人去读代码判断，而是靠它在这些场景中跑出来的结果是否持续满足预期。
换句话说，StrongDM 的方法把覆盖率从“人为写了多少测试”这一维度转向了“规范 / 场景是否足够多与足够准确”＋“验证生态能否在闭环中捕获异常”这一维度。
基于这一理念，StrongDM 还进一步提出了他们的另一个关键概念：数字孪生宇宙（Digital Twin Universe, DTU）。
StrongDM 的定义是：数字孪生宇宙是一组对第三方服务的 行为级克隆体。他们构建了 Okta、Jira、Slack、Google Docs、Google Drive 和 Google Sheets 的孪生系统，复刻这些服务的 API、边界情况以及可观察到的行为。
有了 DTU，他们就能在远超生产环境限制的规模和速率下做验证：既能测试那些在真实服务上危险、甚至根本不可能尝试的失败模式，也能每小时运行成千上万个场景，而不必担心触及限流、触发滥用检测，或累积 API 成本。
那这些 Okta、Jira、Slack 的关键行为是怎么“克隆”出来的？答案是：用编码 Agent。
有人将这套做法概括为一条可复用流水线：把某个服务的完整公开 API 文档直接喂进 Agent harness，让它生成一个自包含的 Go 二进制程序去模拟这些 API；然后在此基础上再快速搭一个简化 UI，方便把整套仿真跑通、跑顺。
随后，DTU 的创建者 Jay Taylor 在 Hacker News 上补充了一些背景，分享了一条关键的提示策略：
我最初有一个关键洞察，最终形成了一套可重复的方法，用来确保 DTU 与官方 SaaS 服务之间具有高度一致性：以最流行、公开可用的官方 SDK 客户端库作为兼容性目标，始终追求 100% 兼容。
当这些不受限流和配额约束的服务克隆体跑起来后，一整支“模拟测试 Agent”队伍也就能彻底放开手脚。场景测试不再是一锤子买卖的验收环节，而是变成了 Agent 会反复、持续执行的脚本：系统一边搭建，一边就被不停拉出来跑场景、做验证。
他们的 Slack 孪生系统截图也直观展示了这种测试方式：一批模拟的 Okta 用户不断出现，并分别去申请访问不同的模拟系统。
问题依然是：太烧钱了？
在惊艳之外，这次实验也迅速暴露出一个无法回避的现实问题：成本。
在 Hacker News 的实操反馈中，有开发者提到，按照 StrongDM 提供的 spec，让 Claude 构建完整应用时，TypeScript 路线的 token 消耗极高，不得不中途给账户充值，才能在一个晚上把流程跑完。他甚至计划改用 Rust 或 Go 再试一次，只是为了看看是否能把成本压下来。
这个反馈并非个例，也不是枝节问题。StrongDM 团队在内部曾提出过一个颇具冲击力的衡量标准：如果你今天在每位人类工程师身上花费的 token 成本还不到 1000 美元，那么你的软件工厂还有很大的改进空间。
这句话一旦落到现实，就更像是一个商业模式的探讨：你能否打造出一条足够盈利的产品线，从而负担得起以这种方式开发软件所带来的巨大成本？当任何竞争对手只需几个小时的编码代理工作就能克隆你的最新功能时，构建可持续的软件业务也变得截然不同。
另外，正如 StrongDM 团队在回顾中所说，其实这一切技术上是可行的，只是以前从经济上来说不划算：
“构建一个高保真 SaaS 应用的克隆在技术上一直可行，但在经济上从未现实过。几代工程师都可能想过，做一个完整、内存级的 CRM 副本来测试，但最终往往会在心里把这个提案按下去——‘算了，太不划算了’。
即使对于那些不打算在 token 成本上一次性投入数千美元的团队和个人来说，StrongDM 这种做法依然有很多值得思考的地方，尤其是在人力成本和个人投入回报这一层面。对程序员个人而言，真正的问题或许不只是“现在贵不贵”，而是：当算力成本持续下降几乎成为共识时，你是否已经开始为新的角色和分工做技能投资——还是仍然把全部价值押在“写代码本身”上。
这是个很有意思的观点，不过我想从另一个角度补充一下：如果按每个月 20 个工作日来算，那就是 2 万 × 12 = 24 万美元一年，差不多等于一个 FANG 新毕业生的总包（TC）。我和不少初级到中初级的软件工程师（SDE）共事过，说实话，其中 80% 的表现并不比 Claude 好。（我也见过一些 staff 级别的工程师写出的代码比 AI 还差，但他们通常会用领域知识和技术负责人职责把短板补回来。）
我确实看到，AI 正在把软件工程进一步推向一种 金字塔结构：顶层只有极少数人类，其余大量工作由 AI 承担。
虽然从按现在的成本算，AI“还没便宜到值得完全替代人”，但有网友认为成本下降也许能够预期：“我在想，这会不会只是软件工厂还处在非常早期、效率极低阶段的副产品。Yegge 和 Huntley 都承认，他们在做的自治工厂实验既昂贵又浪费。从制造业的历史经验来看，我反而会预期：随着方法逐渐成熟、流程被不断优化，成本会慢慢降下来。”
而在博客中的最后，他们给出的结论，也为这条实验线画上了一个颇具警示意义的注脚：“我们这些构建软件工厂的人，必须刻意保持一种天真：主动识别并移除软件 1.0 时代留下的习惯、惯例和限制。数字孪生宇宙（DTU）就是最好的证明——六个月前还不可想象的事情，如今已经成了日常。”
参考链接：
https://factory.strongdm.ai/
https://simonwillison.net/2026/Feb/7/software-factory/
https://news.ycombinator.com/item?id=46924426#46931812
本文来自微信公众号 “InfoQ”（ID：infoqchina），作者：Tina，36氪经授权发布。
