软件“暗工厂”不是无人车间，而是可控流水线
第一性原理 佛学觉照

软件“暗工厂”不是无人车间，而是可控流水线

| 阅读 9 分钟

北京时间 2026 年 7 月 21 日，Sequoia Capital 发布了一期对 Factory 联合创始人兼 CEO Matan Grinberg 的访谈，标题叫《Factory’s Matan Grinberg: The Coming ‘Dark Factory’ Where Software Builds Itself》。

“暗工厂”这个词很容易让人想象一个没有工程师的未来：需求进去，代码出来，灯不用开，人也不用在场。

但这期访谈真正有价值的地方，恰恰不是这种想象。Matan 讲的第一件事，是 Factory 早到了两年，踩过坑，甚至把已经收到的钱退给客户重新来过。

这说明软件暗工厂的关键，不是让人消失，而是先把软件生产线变得可控。

自主性太早，也会变成产品错误

Factory 做的是面向软件开发的 Droids，也就是能承担工程任务的 autonomous agents。Matan 在访谈里回忆，公司大约三年半前开始做这件事，前两年像在沙漠里走。

原因不是他们不相信 autonomous agents，而是企业和开发者当时还没有准备好用这种方式工作。

这点很重要。很多 AI 产品的幻觉，不是模型幻觉，而是交互方式幻觉：因为技术上可以让 agent 独立行动，就以为用户已经愿意把任务交出去；因为 demo 可以跑完一段流程，就以为组织已经准备好改变责任链。

Factory 的早期经历提供了一个反例。他们一度接近 200 万美元收入，但后来意识到产品还不够好，开发者并没有真正喜欢它。Matan 说团队选择把钱退给客户，保住信任，再回去重做。

这比“我们增长很快”更值得看。

因为它承认了一件朴素的事：自主程度本身不是价值。只有当自主性落在正确入口、正确信任边界和正确反馈循环里，它才会变成产品价值。

终端入口，是把愿景降落到工程现场

后来 Factory 推出 Droid CLI，把产品放回开发者熟悉的终端入口。

这一步看起来比“完全自主开发者”保守，实际更接近成熟路线。工程师每天工作的地方不是抽象的 AI 愿景，而是代码库、终端、issue、PR、测试、CI、Slack、Linear、Jira、Sentry 和内部文档。

一个 agent 如果不能在这些现场里稳定工作，就很难变成生产力。它不只是要会写代码，还要知道项目规则、文件结构、测试命令、权限边界、失败以后怎么恢复，以及什么时候需要人确认。

所以，软件暗工厂不是一个聊天框的升级版。它更像一条工程流水线。

需求、上下文、代码、测试、审查、发布、监控，每个环节都要有接口，每个接口都要有边界，每个边界都要能被回放和追责。

护城河可能不在模型，而在运行架构

访谈里另一个关键点，是 Matan 对 model-agnostic harness 的强调。

harness 可以理解为围绕模型的运行架构：它负责把模型接进代码库、工具、权限、状态和审查流程。Matan 反对把软件生产线绑死在某一个模型供应商上。原因不难理解：如果 harness 只适配一个模型的脾气，它短期可能表现很好，长期却会被模型版本、价格、限额和供应商策略牵着走。

真正有复利的，是围绕模型搭起来的运行架构：如何读代码库，如何拆任务，如何调用工具，如何保持状态，如何记录过程，如何把失败变成下一轮输入，如何把结果交给人审查。

模型会换，harness 会沉淀。

这也是为什么 Factory 公开材料会强调跨 CLI、Web、Slack/Teams、Linear/Jira、Mobile 等入口，第三方比较也把它放在企业后台自动化、工程任务执行和多系统集成的位置上。它不是只在争“谁的补全更快”，而是在争谁能成为工程组织里的 agent 运行层。

如果这个判断成立，未来 AI coding 的竞争就不会只看哪个模型单次 benchmark 更强，还要看谁能把上下文、工具、权限、测试和审查组织成可重复生产线。

不是所有 token 都该给最贵模型

Matan 还谈到动态模型路由：简单任务可以交给更快、更便宜的模型，复杂推理才交给 frontier models。

这听起来像成本优化，实际也是系统设计。

在一条软件生产线上，不同步骤需要的智能密度不同。改一批格式、跑一组检查、补一段重复代码，和做架构判断、定位复杂 bug、设计迁移方案，不应该消耗同样的模型资源。

如果所有任务都丢给最强模型，系统会贵到难以扩展；如果所有任务都丢给便宜模型，关键判断又会变脆。

所以 model routing 会变成软件工厂的调度能力：什么任务用什么模型，什么时候切换，什么时候重试，什么时候让人接管。

open-weight 模型也在这个逻辑里变得重要。Matan 说 Factory 内部已经有超过一半 tokens 使用 open models，因为它们更快、更便宜，也能降低 token limit 对工程师的束缚。这个说法不需要被解读成“开放模型全面胜利”。它更准确地说明，模型供给正在变成可调度资源。

未来的工程组织不会只买一个最聪明的模型。它会维护一组模型、一套路由策略和一套成本边界。

暗工厂真正需要的是停止权

访谈结尾，Matan 预测未来 12 到 24 个月，90% coding tokens 会变成异步使用。也就是说，越来越多代码工作不会发生在人盯着屏幕的时候，而是在后台排队、执行、检查和提交。

这就是“dark factory”的诱惑。

但暗工厂越有诱惑，越不能只问它能不能自动运行。真正要问的是：它什么时候停下来？

如果一个 agent 从工单里读需求，自己改代码，自己跑测试，自己修 CI，自己开 PR，甚至自己触发部署，那么每一步都必须有边界。

它能读哪些仓库？能改哪些目录？能调用哪些凭据？能花多少 token？测试通过是否足够？安全扫描由谁看？高风险改动谁批准？生产发布前有没有人工确认？如果循环开始把坏假设写进更多文件，谁能立即中断？

没有这些问题，暗工厂只是把开发风险藏进后台。

有这些问题，暗工厂才可能变成软件组织的杠杆：人不再盯着每一次按键，而是设计任务、提供上下文、审查关键结果、处理异常，并保留最后的停止权。

未来的软件工厂，仍然需要人

Factory 这期访谈最值得带走的，不是“90% tokens 会异步运行”这个数字，也不是“暗工厂”这个词。

真正值得带走的是更冷静的判断：AI coding 的下一阶段，会把稀缺点从写代码的手，转移到组织软件生产线的能力。

谁能把需求入口、代码上下文、模型路由、工具权限、测试信号、审查流程和停止权连起来，谁就更接近真正的 agent-native engineering。

这条路上，模型当然重要。但模型不是全部。

暗工厂不是无人车间，而是一条可控流水线。灯可以变暗，人可以离开键盘，但责任、审计和停止按钮不能消失。

参考来源

💬 评论