从 25 年下半年开始，我的工作重心开始有意识地从项目交付往产品化方向切换。过去在金融和制造两个行业交付了 20 多个企业大模型落地项目，品类上覆盖了知识库、合同审查、报价 Agent、隐患识别等。部分方案已经有了可复制的交付模板，比如知识库的入库预检工具、报价 Agent 的 LangGraph 工作流脚手架，切换客户的时候不用从零开始。

但数据治理这一环始终是瓶颈，每个新客户进来，历史报价单的清洗、行业术语的整理、业务规则的提炼，这些活儿还是要重来一遍，约摸占了 70% 的工程量。我一直在梳理一个产品化的判别框架，哪些是行业共性、哪些是客户个性、两者之间的边界怎么界定，但一直缺一个足够好的外部参照来做对比验证。

为了更广泛地了解全球范围内的产品化实践，我用 OpenClaw 搭了一套定时监测的工作流，每天自动抓取海外的创投融资动态、Reddit 和 Medium 上垂直领域的讨论帖，然后定期做一轮筛选和 review，看有没有值得深入拆解的工程参考。上周通过这个渠道注意到一家叫 Rebar 的美国初创公司，11 人团队，专门给暖通空调行业做 AI 报价，3 月份刚拿了 1400 万美元的 A 轮融资。之所以特别关注，是因为它做的事情和我之前做过的两个项目，水处理设备的售前报价 Agent和全屋定制家居的 CAD 图纸解析，在业务链路上高度相似，都是看图纸、提参数、出 BOM、匹配价格。把它的产品化路径和我自己的项目放在一起对比，能看到一些很有参考价值的差异，值得展开聊聊，所以就有了这篇文章。

这篇试图说清楚：

Rebar 这个案例背后的工程逻辑和商业模式、暖通行业为什么能跑通产品化而其他行业不行、我做过的水处理报价和家居 CAD 两个项目踩了哪些坑、三个项目放在一起能提炼出什么样的产品化判别框架、这个赛道的竞品格局和真实壁垒在哪里，以及作为 ToB AI 从业者，行业 Know-How 和全球视野为什么可能比技术本身更重要。

以下，enjoy:

1、Rebar 是谁，做了什么

为了把这个案例拆解清楚，我过去两天做了一遍深入的暖通行业的 Deep Research。除了翻官网和演示视频，也去查了海外的创投数据库，还跑去 Reddit 等一些专业论坛里翻了翻同行吐槽。所以老规矩，在正式开始介绍案例前，先和各位快速对齐一下行业背景，这样后面聊它的产品化抽象和工程逻辑时，才会有更好的阅读体感。

官网：https://www.withrebar.ai/

1.1、暖通报价这活到底有多累

不熟悉暖通工程的盆友可能觉得装空调很简单，但大型商场和写字楼里的暖通（也就是供暖、通风和空调系统，简称 HVAC），实际上是整个建筑机电管道系统里的核心一环。一栋写字楼的暖通系统涉及冷热源设备（冷水机组、锅炉）、管道网络（冷冻水管、风管）、末端设备（风口、风机盘管、VAV 变风量箱）和控制系统，复杂度不低。

注：AI 自动识别房间区域。粉色高亮区域为 AI 自动框选的房间边界，蓝色标注为已识别的暖通设备（送风口、排风口等）。左侧为无障碍双床房，右侧为标准双床房——即便是同一种房型，设备配置也有差异，人工清点容易遗漏。（图源：Rebar 官网）

在真实的业务链条里，从定项目到买空调，图纸需要经过一套层层下发的流转过程：

设计院出的原始图纸是 CAD（.dwg）格式，发到供应商手上的时候通常已经转成了 PDF。暖通供应商拿到的是整套建筑施工图里属于机械/暖通的那部分（Mechanical Sheets），一般包含各层平面图、设备明细表（Equipment Schedule，列出所有设备的型号、参数和数量）、图例和规格书。

拿到这一摞图纸之后，供应商要做的第一件事就是图纸算量，行业黑话叫 Takeoff。我在 Reddit 的 r/estimators（建筑估算师）版块翻了不少帖子，结合公开资料，传统的 Takeoff 大致分这么几步：

步骤	内容	说明
1. 页面分类	从整套图纸（50-200 页）里挑出暖通相关的页面	建筑图、结构图、电气图跳过
2. 设备识别	在暖通页面上逐个识别和标记设备	Takeoff 核心，最耗时。记录设备类型（风口、管道、阀门等）、参数（尺寸、风量）和数量
3. 交叉核对	把图纸上数出来的设备和设备明细表（Equipment Schedule）比对	数量和参数不一致需找设计院确认
4. 汇总 BOM	把所有设备、管道、配件整理成结构化物料清单	—
5. 匹配报价	查自家价格表，加上人工费、管理费、利润	生成最终报价单

整个过程基本靠肉眼和手工操作。据 Reddit 上一些一线估算师的说法，一个大型商场项目，光是趴在图纸上数设备就能花掉报价员差不多一周。而且更重要的是，这活容错空间很小，漏看一个角落的冷水机组，项目就算拿下来公司也得自己补差价。再结合公开数据，暖通行业的平均中标率大概在 5% 到 10%，十个项目的报价最终能拿下来的可能只有一个，大量的人力成本沉在了拿不到结果的报价工作上。

不过这个行业的核心痛点倒不是说堆人就干不了，而是从概率角度看，在有限的人力条件下，报价速度直接决定了能投多少标。如果能借助工具把单次报价的时间压下来，同样规模的团队就能覆盖更多项目，中标的绝对数量自然就上去了。

1.2、Rebar 怎么做的

Rebar 就是瞄准了这个痛点。这家目前只有 11 个人规模的初创公司，用数百万张真实暖通图纸训练了一个专门针对暖通图纸的视觉 AI 模型，直接把传统流程的前四步（看图算量）给机器化了。

注：Rebar 产品界面。左侧为图纸目录导航，中间为 AI 识别后的设备分布图（不同颜色代表不同设备类型），弹窗 Page Summary 显示该页识别出 21 台风机盘管、113 个线性散流器等设备，底部自动生成设备明细表（含厂商、型号、尺寸、风量等参数）。（图源：Rebar 官网）

AI 算完之后出来什么

AI 解析完几十页图纸后，最终产出的是一份结构化的物料清单（BOM）。里面包含设备类型（比如散流器、冷水机组）、设备的物理参数（比如管径、CFM 风量）、数量以及空间位置（在哪个楼层、哪个房间）。简单说就是把前面 Step 2 到 Step 4 的人工活，用模型自动跑了一遍。

算量和核价的拆分

这里面有一个设计上的取舍值得拆开来看。Rebar 只做算量，不做核价。

注：AI 设备参数提取示例。红框标出了 AI 从图纸中自动提取的三项关键参数：设备型号 SD-1（送风散流器）、额定风量 275 CFM、接管管径 10 英寸。这就是算量的核心，不是简单地数个数，而是把每个设备的工程参数结构化提取出来。（图源：Rebar 官网）

图纸上有几个风口、多粗的管子，这些信息不会因为你是哪家供应商就发生变化。所以 Rebar 把这部分做成了通用的模型能力，训练一次，所有客户共享。但一台空调你要卖 1 万还是 8 千，给大客户打几折，这些是每家供应商自己的事情，差异很大。

Rebar 的做法是不碰客户的定价逻辑。客户要出报价单的时候，只需要把自家的 Excel 价格表上传进来，或者对接 ERP。AI 这边算出来的设备数量和参数，直接匹配客户价格表里的单价，生成报价单。整个核价环节用的是最传统的结构化数据匹配，不涉及任何模型推理。

这个拆分的好处后面会详细讲，先说融资和商业数据。

1.3、融资和商业数据

融资与业务数据

Rebar 在今年 3 月拿到了 1400 万美元的 A 轮融资，领投方是专注建筑地产科技的 Prudence，跟投方包括 Founder Collective 等。

根据 Crunchbase News 的报道，这支 11 人的团队在 2026 年的前六周就实现了 ARR（年度经常性收入）翻倍，拿下了 40 家企业客户。其中有 7 家客户试用之后直接变成了投资人，这个转化本身就说明了产品的粘性。

为什么边际成本能降下来

私以为资本看的是这个结构，算量这一层被通用视觉模型标准化了，核价这一层被客户自己的 Excel 或 ERP 解决了，Rebar 每接一个新客户，不需要派工程师去现场清洗历史报价单，也不需要理顺客户的利润审批流。新客户接入的成本很低，接近 SaaS 的扩展逻辑。

这个案例的工程逻辑和商业模式拆解到这里，我的第一反应是对照自己做过的两个业务链路高度相似的项目。一个是给非标水处理设备厂商做的售前报价 Agent，另一个是全屋定制家居的 CAD 拆单 POC。切入点和 Rebar 差不多，都是看图纸、提参数、出 BOM、匹配价格。但 Rebar 把这套流程做成了边际成本递减的标准产品，而我之前的两个项目确实在同类型客户复制上，在数据治理的环节上一直很费劲。这之间的异同值得展开说说。

2、三个项目放在一起看

2.1、水处理报价：70% 时间在做数据治理

这个项目我之前写过两篇博客详细记录了工程细节，这里只说和这次对比相关的部分。

售前报价Agent落地案例拆解

从"找案例"到"出报价"

客户是一家做了十几年水处理设备集成的小工厂，十来个人的规模，老板本人就是用户。他的日常工作流程里，甲方通过微信或者招标文件提一个需求（比如“28 吨流量、85 米扬程的恒压供水泵组”），老板凭经验从电脑里 7000 多份历史报价单中找到最相似的几份，对比参数差异，手动调整设备选型和数量，再打电话问供应商拿最新价格，最后出一份 Excel 报价单。

这个项目我分了两期做。一期只做检索，用向量相似度加关键词的混合检索方案，让老板输入一段需求描述，系统几秒钟就能从 7000 多份历史报价里找到最相似的 3-5 份参考案例。这个功能本身效果很好，老板原来翻十几分钟才能找到的东西，现在几秒钟搞定。

二期才开始做生成。但这里有一个关键的设计选择：系统并不直接生成最终价格。我用 HDBSCAN 聚类算法对 7000 多份历史报价做了分析，从中提炼出了 20 个典型业务场景、110 个常用 SKU，再用关联规则挖出类似“格兰富泵 + ABB 变频器共现率 87%”这种搭配惯例。系统生成的报价草稿里，价格部分只给出历史中位数作为参考，最终定价还是由老板自己来定。因为这家企业本身就没有标准价格表，定价全靠老板的经验和判断。

这个项目本身跑下来效果是不错的，检索加生成两期的解耦也验证了一个有价值的工程路径。但问题出在跨客户复用上。水处理设备的报价本质上是一个推理问题，也就是 LLM 要做的不是看图数数，而是理解需求参数、推算工艺路线、选择设备型号。

这些选型规则没有任何行业标准可以兜底，完全依赖每家集成商自己十几年积累下来的经验。我从这家客户的 7000 份报价单里提炼出的 20 个场景和 110 个 SKU，换到下一家水处理集成商可能完全不同，数据治理工作得从头再来。结果就是约 70% 的工程量花在了数据治理上，每换一个客户就要重复一次。

2.2、家居 CAD 拆单：技术走通了但产品化走不通

这个项目的 POC 过程也写过一篇博客（链接），同样只说和对比相关的部分。一个全屋定制AI拆单POC的复盘

这个客户是一家全屋定制家居的工厂，全屋定制行业有个专门的环节叫拆单，简单说就是把设计师画的 2D 效果图转换成工厂能用的生产数据，也就是每一块板子的厚度、孔位、连接方式都要精确到毫米。这个转换目前主要靠拆单员人肉完成，据这个客户介绍，一个拆单员一天大概只能处理 100 平米，一个 300 平米的别墅项目光拆单就要两三天。

这个场景和暖通报价有一个相似点，输入都是 CAD 图纸，AI 要做的也是感知类任务，从图纸里识别结构、提取参数，所以最初我判断技术链路是可以走通的。

POC 的做法是先用多模态大模型解析 2D 设计图纸，提取结构化参数，生成 OpenSCAD（一个开源的代码驱动 3D 建模工具，可以通过写脚本来生成三维几何体）脚本，渲染出 3D 模型，最后导出 STL 文件。从技术验证的角度来看，90% 的链路都走通了，多模态解析能准确识别柜体结构，参数化建模能正确生成三维几何体，STL 文件也能正常输出。

卡点出现在最后一步。STL 导进客户的拆单软件后，软件只能把它当成一个几何形状来显示，没法识别出这是由哪些板件组合而成的，后面的 BOM 自动导出和 CNC 加工代码生成全走不下去。

这里要说一下为什么拆单软件会成为堵点，其实拆单软件的核心价值不在于 3D 建模本身，而在于它背后那套行业规则引擎，就是哪些几何体是板件、哪些是五金，18mm 多层板对应什么 SKU，哪些边需要封边、封边规格多少，铰链打在哪个位置，CNC 代码怎么生成。这些规则是软件厂商多年服务家居工厂积累下来的行业 Know-How，也是它收费的核心卖点。换句话说，这类软件主观上就不会轻易开放接口让外部工具绕过它。

这和暖通报价的差别就很明显了。暖通供应商原来的下游工具就是 Excel 加人工，没有一个封闭的行业软件卡在中间。Rebar 的 AI 算完量之后可以直接匹配客户的价格表出报价单，流程是通畅的。而家居场景里，就算 AI 把图纸解析得再准确，产出进不了客户的生产软件，价值就大打折扣。

2.3、Rebar 为什么能跑通

三个项目放在一起看，差异就比较清楚了：

维度	暖通报价	家居拆单	水处理报价
输入物料	标准 CAD 图纸	也是 CAD 图纸	Word / 微信消息
AI 的核心任务	感知：识别符号、计数	感知：识别结构、提参数	推理：理解需求、选型
行业标准覆盖	ASHRAE 统一符号体系	CAD 有惯例但不规范	无统一标准
行业软件生态	开放（Excel + 人工）	封闭（拆单软件黑盒）	开放（Excel / 微信 / 人工）
产品化结果	$14M 融资，40 家客户	POC 未推进	70% 时间做数据治理

行业标准层

Rebar 能做到训练一次，通吃所有客户，根基在于暖通行业有一套相当完整的标准体系。

最表层的是正式标准，ASHRAE（美国暖通空调制冷工程师协会）发布了一系列暖通图纸的图形符号标准，规定了图纸上各类设备的图形符号，全美国的暖通施工图上，一个供风口的符号长什么样是统一的。AIA 的制图标准规定了图层、线型和标注方式，ASHRAE 90.1 等标准规定了设备明细表的格式。

往下一层是行业惯例，虽然没写成国标，但设计院之间实际遵循的规矩差异不大。比如 CAD 图层的命名规则、设备明细表的表头格式（Tag、Model、Capacity、Manufacturer）、BOM 清单的行项结构，这些在行业内已经是半标准化的了。

最底层是物理共识，暖通系统的对象空间本身就是有限的，全球的暖通体系核心设备就那么几大类——风口、管道、冷水机组、风机盘管、阀门。不会像自然语言那样有无穷的变体。而且这些设备在图纸上的符号从 CAD 时代就固定下来了，几十年没变。

这三层叠在一起，“正式标准、行业惯例、物理共识”构成了一个很坚实的行业标准层。Rebar 的视觉模型只需要在这个标准层上做感知（识别符号、计数），不需要做推理（选什么品牌、什么型号）。毕竟，感知问题天然比推理问题更容易标准化和产品化。

反观水处理报价，AI 要做的不是看图数数，而是理解需求、推理选型、生成方案。这是一个推理问题，而推理所依赖的选型规则和品牌偏好，在每家集成商之间差异很大，没有行业标准可以兜底。所以只能从每个客户自己的历史数据里去提炼，提炼出来的底座也是绑在一家客户身上的。

生态开放度

Rebar 过的第二关是生态开放度。暖通供应商原来的报价流程就是 Excel + 人工，没有一个封闭的行业软件挡在中间。AI 算完量之后，直接匹配客户的价格表就能出报价单，整个流程是通畅的。

家居 CAD 项目恰好卡在这一关，技术上多模态解析和参数化建模都跑通了，标准层也不算太弱（CAD 图纸有基本的结构惯例）。但行业软件生态是封闭的，拆单软件不接受外部输入，AI 做出来的东西进不了客户的生产流程，但技术可行不等于产品可行。

当然这里面可能也有中美软件生态的差异。海外 SaaS 的垂直分工比较充分，各环节之间通过 API 连接，AI 工具更容易切入。国内的行业软件，尤其是像全屋定制这种前端设计和后端生产由不同厂商把持的领域，往往各自为政，接口不开放，中间的衔接长期靠人工。这不完全是技术问题，更多是行业利益分配的结果。Rebar 能顺畅地嵌入美国暖通供应商的现有流程，这一点放在国内某些行业里未必能直接复制。

如果把这两个维度画成一个简单的四象限，三个项目恰好落在不同的格子里：

如果把“AI 任务类型”和“行业标准层厚度”画成一个四象限，三个项目恰好落在不同的位置：

左上角是产品化条件最好的象限，行业标准层厚、AI 只需要做感知，Rebar 就在这里。右上角的家居 CAD 标准层偏薄，虽然 AI 任务也是感知类的，技术链路走通了，但额外受制于封闭的行业软件生态。右下角是最难的象限，标准层薄、AI 又要做推理决策，水处理报价就卡在这里，每换一个客户都要重新治理数据。

左下角比较有意思，标准层厚、AI 做推理，这个组合在海外已经有不少成熟案例，比如法律领域的 Harvey（合同分析、尽调、法律研究，依托成熟的法律法规体系）、保险核保领域的 Shift Technology（风险评估和反欺诈，依托标准化的保单结构和监管框架）。这些场景的共同点是，虽然 AI 要做推理决策，但行业本身有成熟的法规或标准体系兜底，推理所依赖的规则是相对收敛的。这也进一步说明：行业标准层的厚度，可能是决定 AI 能不能从感知走向推理、从工具走向产品的关键变量。

3、给 ToB AI 从业者的一些参考

3.1、进入一个新行业前先问六个问题

从这三个项目的对比里，我尝试提炼了一组快速判别的问题。在评估一个新的垂直场景是否适合做 AI 产品化时，可以先过一遍：

第一，输入物料是否标准化。标准 CAD 图纸、合同这类结构化程度高的输入，和微信消息、口头描述这类非结构化输入，对 AI 的要求完全不同。暖通报价的输入是标准施工图，水处理报价的输入很多时候是一段微信消息。

第二，对象空间是否收敛。暖通设备就那么几大类，SKU 虽然多但类型有限。水处理设备的组合理论上有 10 的 17 次方（按X个品类×Y种规格×Z种组合估算）种可能，对象空间要发散得多。

第三，有没有正式或事实标准覆盖。有 ASHRAE 这种行业标准兜底的场景，模型训练一次就能通吃。没有标准的场景，每家客户的规则都要单独提炼。

第四，AI 做的是感知还是推理。感知类任务（识别符号、计数）比推理类任务（选型决策）更容易标准化和产品化。

第五，技术决策是谁做的。暖通场景里，设计院已经做完了设备选型，供应商只需按图报价。水处理场景里，供应商自己要做选型决策。上游已经定好的，AI 做起来轻松很多。

第六，行业软件生态是否开放。下游工具是 Excel 加人工的，AI 可以直接切入。下游有封闭黑盒软件挡着的，技术走通了也不一定能产品化。

用这六个问题快速打分的话，暖通算量大概能得 6/6，家居 CAD 得分不低但第六问判负，水处理报价可能只有 1-2 分。

3.2、三层架构的视角

换一个角度来看，如果要做行业 AI 产品，可以把架构分成三层来思考。

最底下是行业共性模型层，一次训练全行业通用，比如暖通图纸的符号识别；中间是行业知识工程层，设备类型库、工艺规则库这些行业 Know-How 的结构化沉淀；最上面是客户配置层，价格表、利润率、品牌偏好这些客户个性化的东西。

Rebar 在第一层投入最重，第三层最轻（一张 Excel 搞定），这也是它能做到边际成本递减的关键。我之前做的水处理项目恰好反过来，第三层最重。

3.3、这个赛道不只有 Rebar 一家

竞品格局

最后补充点这个案例场景的竞品分析信息，以免有盆友读到这里误会只有 Rebar 想到了这件事，在一个蓝海里独占鳌头的错觉。

根据公开信息，暖通 AI 算量这个赛道上已经有好几个玩家。Togal.AI 做的是通用建筑 AI 算量，偏建筑平面图，宣称精度 98% 但不是 HVAC 专用。PlanSwift 是传统的数字化算量工具，点击式手动操作，没有 AI 自动识别。Beam AI 走“Done-for-you”模式，人机结合做多工种算量，覆盖面广但在暖通这个垂直领域未必最深。STACK 是云端估算平台，有 AI 辅助计数但更像综合工具。TaksoAI 做管道和机械算量，和 Rebar 在 HVAC 领域有直接竞争关系。

所以这个赛道不是蓝海，Rebar 的差异化在于它只磕 HVAC 这一个垂直领域，用数百万张真实暖通图纸训练了专用模型。而且这个数据是在持续增长的，每个新客户使用系统处理项目时，都在贡献新的图纸数据和人工校正反馈，模型越用越准，形成了数据飞轮。

壁垒不在逻辑，在执行深度

那既然竞品不少，逻辑也不复杂，壁垒到底在哪？我觉得这个问题对评估其他垂直场景的企业大模型应用机会也有参考价值。其实壁垒不在逻辑本身，产品化的逻辑确实不难理解。壁垒在执行层面，我梳理了下大概可以从四个维度来看。

第一是生产级精度的数据积累。虽然有 ASHRAE 标准，但实际图纸里存在大量不规范的画法，不同设计院的习惯差异、手改标注、老图纸质量参差不齐，通用多模态模型在简单场景下能做，但在复杂的多页图纸和密集标注面前精度远远不够。Rebar 宣称用了数百万张真实图纸训练，这个数据规模本身就是门槛，新进入者短时间内很难获取同等规模的高质量标注数据。

第二是开箱即用的行业 Know-How 深度。暖通算量不仅仅是数设备，还需要理解设备之间的逻辑关系（一个 VAV 箱下游通常接几个风口）、处理甲方在投标过程中的变更单、把规格书中的文字描述和图纸上的符号做交叉验证、处理多页之间的跨引用关系。这些看起来简单，但要做到生产级的稳定性，需要大量真实项目的打磨。

第三是工作流嵌入带来的切换成本。Rebar 不是一个试试看的工具，它嵌入了客户的核心报价流程。一旦报价团队适应了它的操作方式，建立了价格表映射和团队协作流程，切换到竞品的成本就很高。40 个客户里有 7 个直接变成了投资人，这件事本身就说明了嵌入的深度。

第四是垂直聚焦的资源集中效应。Rebar 只做 HVAC 一件事，所有工程资源、产品迭代、客户反馈都集中在一个点上。而竞品如 Togal.AI 和 Beam AI 试图覆盖多个工种，资源不可避免地被分散了。在垂直领域里，专注本身就是一种壁垒。

海外从业者怎么看

在 Reddit 的 r/estimators 版块里也能看到类似的判断。海外一线的建筑估算师对通用大模型做 Takeoff 普遍不看好，认为 GPT-4o 这类通用模型在复杂的多页图纸面前基本是文盲。但同时，他们对能解决“数头、圈面积”这些体力活的垂直 AI 工具有很强的需求，Rebar、Togal 这些产品都已经被讨论过，大家主要在观望准确率和实际可用性。

4、写在最后

4.1、行业 Know-How 才是最大的认知资产

这篇文章的分析框架是从我作为企业大模型应用创业者，或者说技术服务方的视角出发的，选行业、定路线、评估产品化可行性。这种视角的好处是可以横向对比不同场景，但也难免带着拿着锤子找钉子的心态，总想着用一套通用框架去套所有行业。

实际上这个案例让我感触最深的一点是，Rebar 的创始人 Evan Brown 并不是什么硅谷程序员，他从小在叔叔的空调公司打工，大学毕业后做了整整五年的报价工程师，每天的工作就是对着图纸算报价。他声称试遍了市面上所有的办公软件，发现没有一个是专门为空调行业设计的，后来接触到 AI 技术才创办了 Rebar。他对 AI 工程的理解未必比一线的算法工程师更深，但他对需求场景的洞察是以解决问题为导向积累出来的，不是为了精通某个技术框架而学的。说到底，模型再强，终归更多是认知的放大器，真正决定成败的是对需求场景洞察的深刻程度。

而且 Rebar 的路径也说明了一个有意思的先收敛再发散逻辑，他先在自己有最深体感的 HVAC 这一个垂直领域里，基于行业标准跑通了一整套模型和方法论，然后再横向扩展到同样依赖图纸算量的管道水暖和电气设备领域。反过来，像我这样做 ToB 企业大模型应用的站位，接触了几十种垂直场景之后再去聚焦，走的是先发散再收敛的路线。看得足够多之后会有些触类旁通的体感，更容易识别出哪些场景有产品化的可能，哪些只能做一次性交付。两种路径殊途同归，更多取决于自己的站位和资源禀赋。

4.2、不要闭门造车

与其追求一个抽象的产品化框架，我觉得更实在的一件事是，在各位所处的垂直领域里，主动去看全球范围内有没有人在做类似的事，他们走到了什么阶段，踩了什么坑。

这篇文章本身就是这个思路的一个演示，在我写这篇文章之前，搜索了一圈发现，除了少量的营销号的自动翻译和搬运视频外，Rebar 这个案例的深度拆解信息在中文互联网上非常之少，但它解决的问题和国内很多 ToB 场景的痛点高度相似。海外的公开信息披露相对更充分，融资动态、产品路径、用户反馈都更容易找到。谁先看到这些最佳实践、谁先理解别人的路径选择，谁就多了一个参照系。不管你是在选方向的创业者，还是在公司里推进 AI 落地的一线从业者，这个习惯可能比任何评估框架都管用。

4.3、内容推荐

文章看到这里，推荐了解下我的书、视频课程和知识星球。无论你是在一线做企业大模型应用的实践者，还是 Java 工程师、产品经理、项目经理想要转型，或者希望从入门到进阶，这些内容都可以提供些增量信息。视频课程包含了 15 个我过去两年实施或咨询的高业务价值场景案例，涵盖 4 个知识库、4 个工作流和 7 个 Agent，每个案例都提供从需求背景拆解、手把手复现到工程逻辑提炼的完整过程，适合新手盆友入门使用。配套书籍《RAG 落地之道：从工作流到企业 Agent》收录了其中 10 个精选案例，做了更详实和系统的论述，与视频课程搭配更佳。