Blacksmith 获 4500 万美元 B 轮融资：AI 代码验证能否跟上生成速度？

当 AI 编程代理开始以几倍于过去的速度提交 pull request，开发团队最先感到疼痛的往往不是代码写得不够快，而是这些代码在合并前无法被及时验证。模型能力提升让代码生产突然过剩，但构建、测试和审查环节仍然建立在为人类书写速度设计的流水线上。Blacksmith 正试图把验证环节变成一条专用通道。这家总部位于旧金山的公司成立于 2024 年，最初做的是为 GitHub Actions 工作负载优化的持续集成（CI）云平台，后来推出名为 codesmith 的云端编程代理，用于诊断和自动修复 CI 失败。2026 年 8 月，Blacksmith 宣布完成 4500 万美元 B 轮融资，由 Peak XV Partners 领投，Y Combinator 和 GV 参与。公司博客披露，本轮实际在 2026 年 3 月关闭，拖到 8 月才公布——这中间的几个月，恰是 AI 编程工具被批量采用以及 Blacksmith 每周 CI 任务量持续增长的时间窗口。

这是资金用途几乎全部指向“买算力”的一轮融资。联合创始人兼 CEO Aditya “JP” Jayaprakash 给出的判断是：“写代码已经变得非常容易，验证代码还没有。”这个判断构成了理解 Blacksmith 商业模式、竞争位置和风险的关键。本轮融资后公司估值达到 5.5 亿美元，较不到一年前 A 轮时的 6000 万美元估值上涨近 10 倍。加上本轮，Blacksmith 的累计融资额达到 5850 万美元。现有投资者 Y Combinator 和 GV 也参与了本轮。公司在 2026 年 3 月已经关闭本轮，但直到 8 月才公布，官方声明没有解释这一时间差。这段静默期内的周 CI 任务量增长，可能让公司有更充分的筹码来讲述验证层需求的故事。

AI 代码生成把瓶颈从“写”挪到“验”，CI 队列成了新的生产事故源

Blacksmith 称，自 2026 年初以来，平台上每周运行的 CI 任务量环比增长 5% 至 10%，原因是更多工程师开始使用 AI 代码生成工具。这个增速对应的可能不是新客户发布会，而是既有工程团队行为的变化：当模型每一次迭代都能让编程代理写出更多代码，验证层承接的负载就会同步放大。Jayaprakash 在公开访谈中直言：“验证代码仍然是一个瓶颈，而且因为人们写得更多，它成为更大的瓶颈。”

公司给出的客户结构也支持这种解释。Blacksmith 称目前有超过 6000 家公司在其平台上运行 CI，包括 Supabase、Clerk、Ashby 和 Mercury；TechCrunch 还把 Expensify 列为客户。按 PR Newswire 的数据，客户数量从 2025 年 9 月 A 轮宣布时的大约 800 家增长至超过 6000 家。不过，TechCrunch 独家采访给出的口径是超过 5000 家，从不到一年前的 700 多家增长。两个数字都指向同一趋势，但差异本身说明公开披露仍存在未对齐之处。如果把客户数量的增长与每周 CI 任务量 5% 至 10% 的环比增长放在一起，Blacksmith 增长的主要来源可能不是单纯的销售扩张，而是已采用 AI 编程工具的团队主动寻找更快的验证基础设施。

这一点可能很关键。它意味着 Blacksmith 的产品需求并非静态的开发者工具需求，而是一个被上游 AI 代码生成工具放大的派生需求。这种需求结构具备弹性，也有依赖风险：一旦 AI 代码生成的采用速度放缓，或者验证方式被更早地嵌入生成工具内部，Blacksmith 的 CI 负载增长可能随之降速。目前公开材料没有提供客户留存、净收入留存或客户集中度数据，因此还不能判断这层增长的粘性。

融资时间差与客户数量口径：一个 5 个月窗口里的需求爬坡

Blacksmith 在 2026 年 3 月关闭 B 轮，却选择在 8 月公布。这中间的窗口期，公司公开材料中唯一可以连续观察的指标是每周 CI 任务量以 5% 至 10% 的幅度周环比增长。如果这一数据自 3 月到 8 月一直保持，那么公司等待公开的时间，恰好填充了一个由 AI 代码生成工具驱动使用量上升的证据链。这或许意味着，Blacksmith 公布融资时并不急于宣告资本到位，而是更想等到一个更强的需求叙事：当 AI 编程工具让代码产量激增，验证层开始出现排队和积压，Blacksmith 作为专用验证基础设施的位置会显得更清晰。

客户数量的两个口径也值得放在这个窗口里看。PR Newswire 称客户从约 800 家增至超过 6000 家，TechCrunch 则称从超过 700 家增至超过 5000 家。两个来源本身都可能反映了公司对不同场合提供的不同统计口径：付费客户、活跃客户或者注册客户的边界并不一致。未披露具体定义之前，外部无法判断哪一个数字更接近收入可转换的客户基数。这种口径差异不是对增长的否定，而是提出一个更实际的观察问题：如果客户数量增长与 CI 任务量增长同时发生，单个客户的任务量是否也在上升，还是增量主要来自新客户涌入？

从客户名单来看，Supabase、Clerk、Ashby、Mercury 和 Expensify 基本都是工程密集、持续交付频次较高的软件公司。这类公司通常对 CI 速度、缓存命中率和构建队列延迟更敏感，也更可能成为早期采用者。它们的共同特征可能意味着 Blacksmith 最初的市场并不在企业级遗留系统，而是在已经大量使用 AI 编程工具、对验证速度有直接痛感的成长型科技公司里。这个定位能解释部分增长的来源，但尚未回答这种增长能否跨出同类客户群。

一年融资两轮、估值跳升近十倍，但增长质量仍有未解项

本轮令 Blacksmith 的估值从 A 轮的约 6000 万美元升至 5.5 亿美元，不到一年上涨近 10 倍。TechCrunch 报道称，联合创始人兼 CEO Aditya Jayaprakash 表示公司年营收已达到数千万美元，部分大客户年支出超过 100 万美元。公司曾在仅有 10 名员工时达到 1000 万美元 ARR，目前员工约 30 人。这些数字放在一起，意味着 Blacksmith 的人均收入贡献和客户支出规模已经明显偏离传统订阅型 SaaS 的曲线。

客户数量方面，官方新闻稿与 TechCrunch 采访存在差异：前者称从约 800 家增至超过 6000 家，后者称从超过 700 家增至超过 5000 家。这个差异未披露原因，可能源于统计口径、免费与付费划分或不同统计时间点，但两家均未提供明细。这一缺口意味着外部观察者无法准确计算客户年均支出，也无法判断客户结构是否高度集中在少数大型账户。

一年接近十倍的估值扩张，建立在客户数量数倍增长、收入从千万美元级别进入数千万美元级别、以及验证层需求被 AI 代码生成放大的叙事上。不过，估值跃进是否能够被后续经营数据证真，仍需关注未披露的净收入留存、流失率和客户获取成本。目前公开材料没有提供这些指标，因此估值更多反映的是市场对验证层需求的定价，而不是对单位盈利能力的确认。

从“一行更改”到专用算力，产品壁垒不在软件界面而在物理核心

Blacksmith 最早的产品形态并不复杂：它提供专门运行 GitHub Actions 工作负载的 CI 云，使用专用计算资源，并对缓存和存储进行针对 CI 场景的优化。迁移成本被压缩到“一行更改”工作流文件。公司声称，这套基础设施可以把 GitHub Actions 的运行速度提高一倍，缓存下载速度快 4 倍，Docker 镜像构建速度快 40 倍，并消除排队时间。这些性能数字全部来自公司单方面表述，公开材料中没有第三方基准测试或客户独立验证。

真正具有结构性意义的可能不是“速度快多少”，而是 Blacksmith 改造的对象。它不是重新发明 CI 编排逻辑，而是替换 GitHub Actions 下面的一般计算层。换句话说，Blacksmith 仍然依赖 GitHub Actions 的控制平面和工作流定义，但在 runner、缓存和存储层建立了专用替代。这意味着它的产品壁垒接近于一项物理算力布局，而不是纯软件功能。

这种依赖性是一把双刃剑。一方面，Blacksmith 能够利用 GitHub Actions 既有的工作流定义和生态，降低用户迁移成本；另一方面，GitHub 若在自身 runners 上做足够的性能优化，或者把同类专用计算能力直接捆绑到现有产品中，Blacksmith 的物理替代价值可能被压缩。当前 Blacksmith 的迁移成本低，可能反过来也意味着用户的离开成本并不高，除非客户已经深度依赖其缓存、存储或后续代理能力。

codesmith 把 Blacksmith 从“跑得快”推向“修得快”，但可靠性未经验证

2026 年推出的 codesmith 代理让 Blacksmith 离“验证”更近了一步。官方博客描述，codesmith 是一个可以委派任务的云端编程代理，除构建功能和修复 bug 外，它深度嵌入验证循环：诊断 CI 失败、自动修复、保持 PR 绿色。公司还计划推出 codesmith QA，在合并前自主测试更改。这种从“快速跑 CI”延伸到“自动修 CI”的路径，可能降低开发者介入频率，但也把产品拉入 AI 代理的可靠性问题。

如果 autofix 本身不够可靠，它可能把验证瓶颈转化为一种新的信任瓶颈：开发者从“跑不完的构建队列”转向“不知该不该信的自动修复结果”。目前 Blacksmith 没有公布 codesmith 的修复准确率、误报率或人工复核比例，因此这个代理带来的净效率增益仍需验证。在部署前，工程团队可能仍然需要人工检查自动修复的 diff，这可能在新的位置上重现旧的验证成本。

从产品路径看，codesmith 的深层意图可能是把验证从一次性流水线作业变成持续闭环：生成代码、运行 CI、自动修复、再测试，直到满足合并条件。这个闭环若跑通，Blacksmith 就不再是单纯的 CI 算力供应商，而成为代码合并前的一段自动驾驶区。但闭环能否成立，取决于代理对测试失败根因的理解是否足够稳定，以及它在复杂代码库中的行动边界是否足够安全。目前公开材料未披露这些能力细节。

收入更像云服务而不是 SaaS，单位经济性可能比估值更值得盯

Blacksmith 没有在官方融资公告中披露具体定价或收入模式。TechCrunch 报道称，公司年营收已达到数千万美元，部分大客户年支出超过 100 万美元。如果这个数字准确，Blacksmith 的商业模型显然不是按订阅座位收费的传统 SaaS，而是更接近计算资源消耗型云服务。客户花得越多，通常意味着他们消耗的核心、缓存和存储越多。

这与公司对资金用途的表述一致。Blacksmith 官方博客明确说，这轮融资的主要原因是扩大计算足迹。公司目前管理着数十万核的计算规模，并计划在未来几个月将这个规模扩大一个数量级。这意味着收入增长的前置条件是持续投入算力资本。一旦收入增速落后于算力扩张速度，毛利率就会被闲置核心和折旧摊薄。

目前公开材料没有披露 Blacksmith 的毛利率、单位经济性、客户平均成本或算力利用率。TechCrunch 报告的年营收和大客户支出只能说明收入体量，不能说明这些收入在扣除算力成本后还剩多少。对于一家估值 5.5 亿美元、资金主要投向物理基础设施的公司而言，单位经济性比收入规模更早暴露商业模式的脆弱性。Blacksmith 是否能在扩大核心规模的同时维持或改善毛利，是后续验证的关键。一种可能的风险是，算力扩张的资本开支先于客户消耗增长落地，形成短期闲置；另一种可能是需求增长快于扩张，导致排队或性能下降。无论哪种方向，Blacksmith 都需要在收入、核心数与利用率之间保持比普通 SaaS 更严格的匹配。

在 GitHub、Cursor、Codex 与云厂商之间，Blacksmith 卡在生态依赖和替代竞争的窄缝里

Blacksmith 的竞争对手名单几乎覆盖了开发流程的上游和下游。TechCrunch 将 GitHub Actions、Cursor Automations 以及内建在 Codex 和 Claude Code 中的验证功能列为其竞争对手。AWS、Microsoft Azure 和 Google Cloud 的 AI 代码测试服务也在争夺同一工作流。

这些竞争者的逻辑并不相同。GitHub Actions 以及 AWS、Microsoft Azure、Google Cloud 的 AI 代码测试服务主要在计算资源和平台层面与 Blacksmith 竞争；Cursor Automations、Codex 和 Claude Code 的验证功能则从更上游切入，它们希望在生成代码的同时完成一部分本地验证，减少代码进入 CI 的问题量。Blacksmith 的位置是夹在中间的：向上游，生成工具可能把验证能力做进默认工作流，降低团队对独立 CI 验证层的依赖；向下游，云厂商有算力规模、渠道和价格优势。Blacksmith 必须证明专用 CI 叠加代理修复能形成足够强的逃逸速度，而不是在一个双边挤压的窄缝里持续付算力账单。

需要警惕的是，Blacksmith 目前依赖 GitHub Actions 的控制平面，这使其与 GitHub 之间的关系既是合作伙伴又是潜在威胁。如果 GitHub 决定将更快的 runner、缓存或自动修复功能直接捆绑到 Actions 的免费或低层级套餐中，Blacksmith 的产品价值可能被稀释。同样，Cursor 或 Codex 若把本地验证作为默认能力，也会减少进入 Blacksmith 的 CI 任务量。这种生态依赖是 Blacksmith 商业模式中最难被自身控制的部分。

B 轮之后，Blacksmith 仍需回答的三个问题

第一个问题是净收入留存与客户集中度。公开材料显示客户数量增长很快，但没有披露付费客户净收入留存、流失率或前十大客户收入占比。部分大客户年支出超过 100 万美元，可能意味着收入并非均匀分布；如果这些大客户减少用量或迁移，整体收入可能受到较大影响。净收入留存未披露，外部无法判断既有客户是否在持续扩量，还是增长主要依靠新客户流入。

第二个问题是算力扩张与收入增速的匹配度。Blacksmith 计划将计算规模扩大一个数量级，这需要大额资本投入。如果周 CI 任务量的 5% 至 10% 环比增长能持续，算力扩张可能被消化；但如果 AI 代码生成的采用速度放缓，或者生成工具开始把验证能力内化，新增核心可能成为闲置资产。算力利用率、折旧与毛利数据未披露，这增加了判断的不确定性。

第三个问题是验证层是否能长期作为独立类别存在。Blacksmith 的估值故事假设验证与生成在 AI 编程时代会分化成不同的基础设施层。但这个假设尚未被头部平台验证：GitHub、Cursor、Anthropic 或 OpenAI 完全可能把更快的验证能力直接打包进自己的产品。若验证层被上游吸收，Blacksmith 目前的物理算力优势可能无法持续。这并不意味着 Blacksmith 没有机会，而是意味着它需要在代理能力、验证深度或成本效率上建立比对手更快的学习曲线。

验证边界与可复核指标

本文涉及的“首个、唯一、最大、领先”、订单、出货、性能等表述，如无另行说明，均是公司、创始人或投资方在现有公开材料中的披露口径；RecodeX未在本次采集材料中找到独立审计或第三方测试结论，因而不将其视为已经独立确认的事实。文中的产业协同、竞争位置和商业路径属于基于已披露产品与融资用途的编辑分析，不代表相关结果已经实现。

• 技术侧应核验第三方测试条件、样本规模、良率、稳定性及与可比方案一致口径的结果；
• 商业侧应核验去重后的付费客户、可执行合同、收入确认、复购率以及订单转化；
• 资本与产业协同应以工商股权、关联交易、联合开发、采购或量产文件为准。

RecodeX 极客视：Blacksmith 的 4500 万美元 B 轮买的是算力，赌的是 AI 代码生成之后验证层仍会独立存在。周 CI 任务量 5% 至 10% 的环比增长是当前最硬的证据，但客户数量 5000 与 6000 的口径差异、净收入留存与毛利率的缺失，让 5.5 亿美元估值更像一张需要后续数据填充的期权。如果 GitHub 或 Codex 把验证能力做成默认开关，Blacksmith 的专用 runner 可能只是一块昂贵的缓存。相反，如果 codesmith 的自动修复能在真实代码库中持续保持高可信度，这家公司有可能从 CI 服务商转变成合并前的验证闸门。在那之前，只能说验证瓶颈正在被看到，但尚未被证明值得用 10 倍估值去拥有。