估值 7.5 亿美金，美国红杉为什么押注一家“硬件版 GitHub”？

你有没有想过，造一架飞机最难的地方，可能根本不是设计，而是让成千上万个人手里的图保持一致？空客 A380 就遇到过这样的事。德国和西班牙的工程师用的是旧版 CAD（计算机辅助设计）软件 CATIA 4，法国和英国用的是 CATIA 5，两边的机身段在图卢兹对接时，线束对不上。据当时的报道，交付因此平均推迟了大约两年，额外成本估计在 60 亿到 70 亿美元。没有人画错某个零件，出问题的是两个团队手里的“真相”不一致。

9 月 30 日，旧金山的 Flow Engineering 宣布完成 5,000 万美元的 Series B（B 轮融资），估值 7.5 亿美元，由 Valor Equity Partners 的 Antonio Gracias 和 Atreides Management 的 Gavin Baker 联合领投。它做的是硬件研发的 agent（智能体）平台，客户包括 Rivian、Anduril、Joby Aviation。我把公司公告、创始人 Pari Singh 的文章，以及投资人 Roelof Botha 和 Singh 的对谈都读了一遍，想弄清楚三件事：硬件开发为什么比软件慢那么多，agent 能改变其中的哪一环，以及 Rivian 为什么能在七个月里从 40 个用户用到 1,500 个。我有不少自己的想法，整理出来和大家聊一聊。

硬件慢，慢在改一处牵动全局

Botha 在对谈里说了一句很朴素的话：软件里的 bug 可以很快打补丁，硬件里的错误往往要几个月才能拆回来。所以 Botha 认为，速度正在成为决定谁赢的关键，最好的团队会在不牺牲工程严谨的前提下，缩短决定与验证之间的学习周期。Botha 还给了一个判断：全球市值前 100 的上市公司里有 34 家科技公司，其中 22 家无疑是硬件公司。这组数字我没有核对，但方向很清楚，硬件正在回到舞台中央。

难点在于，硬件里每个决定都是连在一起的。Sequoia 在投资 Flow 的文章里举过一个例子：调整某个部件的热参数，会沿着整个系统传下去，牵动其他部件，需要跨团队不断手动协调。传统上用来追踪这些依赖关系的是需求管理工具，Sequoia 的评价很不客气，说这些工具是“上个时代的笨重遗物”，工程师不爱用，反而拖长了本来就很长的周期。Botha 还补了一个对比：一个大约 150 人的小公司之所以快，是因为信息流动顺畅，公司变大之后，机械、电子、软件、制造和合规各自成了孤岛，AI 真正的机会不在个人效率，而在组织对齐。

我觉得这段话抓住了硬件和软件的根本差别。软件的难点常在“写出来”，硬件的难点常在“协调好”。当实现越来越便宜，协调的成本反而更显眼了。A380 的教训也是这样，没有人偷懒，也没有人能力不够，是没有任何人能在早期看出，两边的模型已经悄悄对不上了。

一个造火箭发动机的人，为什么去做了需求管理

Flow 的创始人 Pari Singh 在伦敦长大，在 Imperial College London 读机械工程，大学期间做过混合式火箭发动机，毕业后先后在 BAE Systems 和 BP 工作。据 Contrary Research 的梳理，Singh 在这些大型工程项目里看到的，是依然靠几十年前的流程和表格来协调。于是 Singh 先开了一家做火箭发动机设计的咨询公司，为了验证另一种开发方式，自己写了内部软件，把需求、MATLAB 模型、CAD 设计和仿真连成闭环，改动能自动传导。Sequoia 的文章说，这个工具解决某个火箭设计问题只要两个小时，而竞争对手要十二周。Contrary 引用的说法是“12 周的活大约 2.5 小时完成”。这些都是 Flow 方面的说法，我没有看到独立验证。

之后的路径很清楚。2019 年，这家公司从咨询转向做软件，后来改名 Flow Engineering。2022 年 12 月，它完成了 850 万美元的种子轮，由 EQT Ventures 领投，当时的定位是“硬件工程的 GitHub”。2025 年 10 月，Series A 融了 2,300 万美元，由 Sequoia 领投，Stripe 的 Patrick Collison 和 John Collison 等人参与。那次接受 Fortune 采访时，Singh 说，设计硬件的工具、流程和工作方式，从太空竞赛以来基本没有变过。Botha 则说，硬件如今已经不再和软件分开，而是越来越由它们的交汇来定义。

我觉得这条路径里最值得记住的，是它的起点：不是先想了一个大市场，而是先在自己造火箭发动机的时候，被“改一个参数要等十二周”这件事折磨到，动手写了个工具。这种从自己最痛的地方长出来的产品，往往比从市场报告里推出来的更扎实，因为创始人至少知道，痛到底痛在哪一步。

Flow 的核心：把依赖关系写成一张图

Flow 的核心是一个叫 systems graph（系统图）的东西。按 Singh 的说法，它把需求、设计决策、接口、预算、测试和合规证据，放进同一个互相连接的模型里，依赖关系是显式的链接，不再藏在人脑子里。它不要求团队换掉现有工具，官网列出的集成包括 Dassault、Siemens NX、Autodesk Fusion 360 这些 CAD 工具，ANSYS、Abaqus、SolidWorks 这些仿真工具，LabVIEW、TestStand、dSPACE 这些测试工具，还有 GitHub、Slack 和 Outlook。工程师在自己熟悉的软件里干活，Flow 在后面把变化接起来。

在这张图上跑的是 agent。Flow 描述的有四类：做影响分析的，管质量、成本和功耗预算的，管安全与法规合规的，以及用户自己定义的。官方产品图里有一个演示，我觉得比任何概念解释都直观：工程师对 agent 说，峰值电机扭矩的需求改成了 420 牛米，请更新下游需求，并重新生成电机壳体，以适配新的热边界。agent 随即把峰值扭矩从 380 改到 420，生成了新的壳体 CAD 文件，写明定子孔径加大 2.4 毫米、冷却水道重新布线，并列出受影响的需求：轴功率要重算，相电流上限要提高，扭矩保持时长要按新的热模型重新评估。Flow 的说法是，这类传导以前要几周，现在几秒。

产品里还有一个我很喜欢的设计：分支和合并，类似软件的版本控制。工程师先在独立分支里提出变更，查看差异和影响分析，再合并进基线。对涉及国防的客户，Flow 还给出了合规配置，可部署在云端、GovCloud 或自托管环境，符合 ITAR 和 EAR 的要求，并称不会拿客户数据训练模型。这些是公司的自述，不是第三方审计结论。

我觉得这套设计的聪明之处，在于它没有去替代任何一个专业工具，而是做了它们中间那一层。CAD 知道几何，仿真知道物理，测试知道结果，但没有一个知道“它们之间的关系”。Flow 把这层关系变成了数据，agent 才有了可以读、可以改的对象。如果这一层是一堆表格和人脑里的默契，再聪明的 agent 也无从下手。

Rivian 的 1,500 个人，说明了什么，又没说明什么

这次公告里最具体的数字来自 Rivian：Flow 在这家电动车公司内部的用户，七个月里从 40 个涨到 1,500 个，工程师每周发出数百万次 API 调用。Rivian 的产品开发总监 Scott Mackenzie 说，他们评估了 30 种工具，没有一个能接近 Flow。Flow 还说，96% 的客户是主动上门的。公告列出的客户还有 Anduril、Joby Aviation、Stoke Space、Intuitive Machines、Pacific Fusion、通用汽车的 PPU、Rivian 和大众的合资公司 RV Tech、Astranis 和 Radiant Industries。

价格也值得一提。Flow 官网是按编辑席位收费：Basic 档每个编辑每月 150 美元，限 500 条需求；Pro 档每月 300 美元，限 5,000 条需求、五个项目；Enterprise 是定制价，包含 GovCloud 部署和自定义集成。这是很传统的 SaaS 席位模式。Contrary 的报告提到，公司打算随着 agent 干的活变多，转向按 token 用量计费，另外还有一组公司提供的数据：维护需求所花的时间减少了 79%，同样的工程时间里测试覆盖提高到三倍。

我觉得需要把这些数字分清楚。1,500 是用户席位，说明它被用起来了，而且是自下而上长出来的，这本身已经是很强的信号，因为工程师最容易抵触的就是被强推的工具。但席位数不等于迭代速度提高了多少。公告里“把硬件迭代从几个月缩短到几天”是目标，79% 和三倍也是公司自己的统计，没有独立验证。读这类融资稿，最值钱的往往不是最大的数字，而是最难造假的那一个：愿意自己用起来的人数。

投资人在押什么：为实体产品做“操作系统”

这轮融资的名单有些分量。Gracias 是 Tesla 的早期投资人，在 SpaceX 和 Neuralink 的董事会任职；Baker 是 Nvidia、Tesla、xAI 的早期投资人。Sequoia、Human Capital、Evantic、SV Angel、Odyssey 和 EQT 也跟投了，个人投资者里还有 Hugging Face 联合创始人 Thomas Wolf、Mercedes-Benz 的 CIO Jonas von Malottki，以及 F1 世界冠军 Nico Rosberg。两位领投人的话落在同一个方向：Gracias 说，来自有高标准的工程师的市场拉力很少见，这是他们支持 Flow 的原因；Baker 说，Flow 在为实体产品打造操作系统，用软件替代稀缺的工程能力。

钱的用途，公告写得很具体：打造面向硬件工程的 AI harness（让前沿模型能安全接触敏感工程数据的框架），扩充评审、分支和评测能力，扩大 AI 和系统工程团队，争取 FedRAMP（美国联邦政府云服务授权）等认证，并扩大销售团队。据 Contrary，到今年 6 月 Flow 只有约 25 名员工，计划年底前翻两番。这个品类并不新，老牌对手有 IBM DOORS、Siemens Polarion、Jama Connect，还有 Autodesk 和 Dassault 这样的大厂，新一些的有 Trace.Space 和被 Altium 收购的 Valispace。Flow 的差异，是面向新一代硬件公司，并把 agent 直接放进系统工程流程里。

我觉得这个对手名单说明一件事：需求管理早就存在，Flow 押的是另一件事，当 agent 成为工具的主要使用者，底层的数据模型就得从“文档”改成“图”，否则 agent 读不懂，也改不动。这和 Botha 的另一个判断也对得上：组织优势会复利，早用的团队会比晚用的多积累好几年的能力。这是投资人的叙事，不是已经发生的事实，但它解释了为什么他们愿意在一个看起来不性感的品类里下这么大的注。

工程师还剩什么：定义规格，设计约束

Singh 在 6 月发布 Flow v3 的文章里，把话说得很直接：硬件的复杂度已经超过了人类团队能持续审查的范围，“靠增加工程师来管理复杂性的时代已经结束”。Singh 描述的分工是：agent 负责更新需求、维护模型、改动之后重跑分析、追查改动弄坏了什么；工程师则从执行者变成整个项目的架构师，定义标准，编码意图，做权衡。最高杠杆的工作，Singh 叫它 harness engineering（搭建让 agent 能有效工作的标准、约束和系统）。Singh 还提出了一个说法，叫 context scaling laws（上下文规模定律）：agent 能读到的互相连接的工程数据越多，表现就越好。这是 Flow 的论断，不是已经被验证的规律。

Botha 在对谈里把这件事讲得更透：随着 AI 实现能力变强，“定义系统需要什么”反而比“生成解法”更难。硬件团队一直把规格当作关键产物，产出的质量取决于规格的质量，而不是实现的速度。我觉得这句话值得抄下来。它和不少 AI 产品的故事，指向同一个地方：模型能做的事越多，说清楚“要什么”和“怎么算对”就越成为瓶颈。硬件把这一点推到了极端，因为一次错误的代价不是重新部署，而是重新开模，或者重新取证。

我自己的一点思考

回到开头的问题。我对 Flow 的理解是，它卖的不是更快的画图，而是把“一件事和另一件事是否一致”变成机器可以持续检查的东西。A380 的教训，在于没有人能在早期看出两边模型不一致。Flow 的做法，是把依赖关系放进一张图里，让 agent 在每次改动后重新检查。这样的产品，我觉得抓住了硬件开发真正的痛点，而不是追着“AI”这个词去包装一个旧工具。

但这家公司的说法有几个边界要看清。大部分数字，包括 79%、三倍测试覆盖和“从几个月到几天”，都来自公司自己，没有第三方核实。Rivian 的 1,500 是席位数，不是效果。Contrary 指出的风险也很实在：Flow 的可靠性取决于它和不断变化的 CAD、仿真工具之间的集成，接口一变，图就可能过期，用户对它作为“记录系统”的信心就会下降。大型航空、汽车和国防企业有深厚的流程和认证链，替换系统很慢，Siemens、Dassault、Autodesk 这些老牌厂商也在给自己的平台加 AI。还有一点：agent 能发现冲突、重算预算，但物理测试和认证，不能靠它省掉。

如果要从这个故事里拿一个对任何团队都有用的检验，我会问一个很简单的问题：改一个需求，要多久才知道它会牵动哪些东西？如果答案是“要开几个会”，那么瓶颈大概不在写得慢，而在对不齐。实现可以交给 agent，对齐却需要被设计出来。这个问题的答案，可能比任何一次融资的估值，更能说明一个团队的真实速度。