何时打开:你想做 B2B 垂直 AI / 想知道某个赛道融了多少 / 想看代表公司怎么做的。本 wiki 按 8 大赛道(销售/客服/招聘/法律/医疗/保险/HR/金融)分类整理深思圈 66+ 篇 B2B 垂直 AI 案例。
一句话核心:垂直 8 赛道各诞生独角兽(法律 7 亿 / 客服 15 亿 / 销售 5200 万 / 医疗 2400 万 / 保险 3000 万 / HR 1500 万 / 金融 5000 万)。关键模式:不再卖工具给律师,而是直接用 AI 重建律师事务所(红杉美国)。
0. 8 大赛道融资行情(2024-2026)
| 赛道 | 代表融资额 | 代表公司类型 |
|---|---|---|
| 销售 | 5000 万-3500 万-1 亿 | Salesforce 替代 / AI SDR / 销售操作系统 |
| 客服 | 2 亿+(估值 15 亿)/ 5000 万 / 2100 万 | 华人公司 / Intercom / Decagon / Cresta |
| 招聘 | 5000 万-2000 万-1500 万 | 招聘操作系统 / 一体化 / 通才 |
| 法律 | ~7 亿(独角兽)/ 6000 万 / 2000 万 | Harvey / Eve / Draftwise |
| 医疗 | 4200 万-2400 万-220 万 | Copilot / 家庭医生 / Shimmer 心理 |
| 保险 | 3000 万-1500 万 | 保险痛点 / Agent 保险 |
| HR | 1500 万 | AI HR 通才 + 垂直模型 |
| 金融 | 5000 万-4350 万 | 下一代基建 / 金融专用 AI |
1. 销售(Sales Agent)
1.1 旗舰案例:Peter Thiel 3500 万终结 Salesforce
"Peter Thiel 花 3500 万美金投了一个销售领域的 Claude Code,号称要终结 Salesforce 时代"
含义:Agent 终结 SaaS 工具时代 —— 不再是 CRM 工具给销售员用,而是销售员让 AI 代他工作。
1.2 红杉美国 5000 万
"红杉美国领投 5000 万美金,如何用 AI Agent 重新定义销售软件"
1.3 其他销售案例
| 公司 | 数据 |
|---|---|
| AI 销售公司(9 个月 2 轮) | 5200 万美金 |
| AI 销售培训(极度细分) | 5000 万美金 |
| AI 销售(Stripe 前高管) | 2200 万美金 |
| 40+ 硅谷大佬抢投 | 1000 万美金 / 全球首个销售人员 AI 操作系统 |
| 23 岁销售天才 | 0 → 8 亿美元(获客密码) |
| AI 销售 550 万 | 用 AI 帮助销售真的可行吗? |
| 两姐妹离 Meta 创业 | 1060 万 / 把社媒变销售渠道 |
1.4 a16z + 红杉 AI 销售大盘点
"深度|AI+销售类产品大盘点,红杉正在押注这个赛道"
2. 客服(Customer Service Agent)
2.1 华人巨头(估值 15 亿)
"融资 2 亿,估值 15 亿美金,这家华人 AI 客服公司太猛了"
2.2 5000 万巨额融资
"AI 客服赛道又一笔 5000 万美金的巨额融资,从工具到平台生态"
2.3 Intercom 自我重构
"深度分析|AI 客服崛起下,老牌巨头 Intercom 如何完成一场 AI-First 的自我重构" "客服软件巨头开始卖 AI 模型了,Intercom 这步棋意味着什么?"
2.4 其他客服案例
| 公司 | 数据 |
|---|---|
| 丹麦客服公司(Perplexity + Replit 用) | 2100 万美金 |
| 澳洲 AI 客服 | 3500 万 / 替你刷卡转账下单 |
| 6 天种子轮 → 1 年 B 轮 | 客服效率提升 300% |
| 欧洲语音客服(1 年 15x 增长) | 2000 万美金硅谷顶级 VC |
3. 招聘(Hiring / Talent Agent)
3.1 一体化招聘操作系统(5000 万)
"5000 万美元押注'一体化 AI 招聘',智能招聘操作系统让每个 HR 成为数据专家"
3.2 其他招聘案例
| 公司 | 数据 |
|---|---|
| 6 个月吸 5w 用户 | 2000 万种子轮 |
| 斯坦福华人辍学(领英 10w+ 粉) | 300 万美金 |
| Inflection + Anthropic 已经在用 | AI 原生招聘 |
| 华人创业者(申请量暴增 3 倍时代) | 2000 万美金 / 让每个候选人被看见 |
| 2000 万美金选择另一条路 | 不取代招聘官 |
3.3 行业战争视角
- "AI 初创公司如何打赢招聘这场战争"(深度长文)
4. 法律(Legal AI)
4.1 旗舰案例:25 岁电竞选手 7 亿独角兽
"AI+法律|25 岁电竞选手转身,打造近 7 亿美元法律 AI 独角兽"
4.2 红杉新打法:不卖工具,直接重建律师事务所
"红杉美国又投法律赛道,但这家公司不再卖工具给律师,而是直接用 AI 重建律师事务所"
关键转向:
- 旧模式:Harvey / Draftwise → 卖 SaaS 工具
- 新模式:直接做"AI-native 律师事务所" → 自己当律所
4.3 其他法律案例
| 公司 | 数据 |
|---|---|
| Draftwise(法律事务所智能系统) | 2000 万 A 轮 |
| 又一 AI 法律产品 | 6000 万美金 |
| 25 岁游戏少年退学 | 1 亿美金(正面挑战 OpenAI 系) |
5. 医疗(Healthcare AI)
5.1 案例
| 公司 | 数据 |
|---|---|
| AI Copilot for 医疗 | 2400 万 B 轮 |
| 家庭医生 AI | 4200 万美金 |
| Shimmer(YC / 心理健康) | 220 万美金 |
| 外科医生创立(2 百万医生用上瘾) | 18 个月 1 亿美金 |
| 三个月翻 4 倍 → 500 万(哈佛 MIT 学霸) | 撬动医疗最大痛点 |
| AI+医药 临床药物开发 | YC W24 |
6. 保险(Insurance AI)
6.1 旗舰:6 个月连融 3000 万
"6 个月完成两轮融资 3000 万美元,这家 AI 公司找到了保险业最值钱的痛点"
6.2 Agent 保险(为 AI 出错买单)
"当 AI Agent 出错时,谁来买单?融资 1500 万美金,一家为 Agent 而生的保险公司"
含义:AI Agent 大爆发 → 新型保险需求 → 新赛道。
7. HR
"融资 1500 万美金,打造了一个 AI HR 通才,还专门搞了一个垂直模型"
模式:通才 Agent + 垂直微调模型
8. 金融(Finance AI)
8.1 案例
| 公司 | 数据 |
|---|---|
| 金融专用 AI(前 Google/Meta 一线科学家) | 4350 万美金 |
| 金融下一代基建 | 5000 万美金 |
| AI 税务公司(Benchmark + YC) | 6 个月连融 2 轮 5300 万 |
| Anthropic 进军金融 | 战略转向 |
8.2 余子江式套壳警示
- "一款复刻 Cal AI 做金融分析的套壳应用,如何做到月入 4 万美金"
9. 跨赛道共性
9.1 旧 SaaS → 新 Agent 转型
| 旧 SaaS | 新 Agent 模式 |
|---|---|
| Salesforce(CRM) | Peter Thiel 3500 万 "销售 Claude Code" |
| 传统财务软件 | 红杉 2500 万 AI-native ERP |
| Harvey 工具 | 红杉直接"AI 重建律师事务所" |
| 招聘 ATS | 招聘操作系统(5000 万) |
| Intercom | 自己卖 AI 模型 |
9.2 关键判断
"除了代码和客服,AI agent 下一个爆发的场景会在哪?"(深思圈分析)
答案预测:
- 销售(已起飞)
- 法律(独角兽诞生)
- 医疗 Copilot
- HR / 招聘
- 金融基建
9.3 11x 暴雷教训
- AI SDR / 数字员工要解决 组织信任 / 权限(Jaya Gupta 论)
- 不能只是"自动化任务",必须能上生产
10. 怎么用 —— 按赛道的 B2B 路径
| 你想做 | 主用 | 起点 |
|---|---|---|
| 销售 Agent | Peter Thiel + 红杉 5000 万 | "终结 Salesforce" / 销售操作系统 |
| 客服 Agent | 华人 15 亿 / Intercom 转型 | "工具 → 平台生态" / 服务费替软件费 |
| 招聘 Agent | 一体化招聘 OS | 招聘操作系统 / 让 HR 成数据专家 |
| 法律 AI | 红杉新模式 | "不卖工具,直接重建律所" |
| 医疗 AI | Copilot 2400 万模式 | 临床场景 / 服务医生 |
| 保险 AI | Agent 保险 1500 万 | 为新型 Agent 风险买单 |
| 金融 AI | 金融专用 4350 万 | 前 Google/Meta 科学家创业 |
通用纪律:
- 8 赛道各诞生独角兽,赛道并不挤
- 关键转向:不卖工具,直接 AI-重建行业(红杉法律范本)
- 解决组织信任 + 权限(11x 教训)
- Agent + 垂直微调模型(HR 通才 + 垂直模型范式)
- 跨赛道共性:旧 SaaS → 新 Agent
11. 引用清单
- 深思圈作者全集入口 —— 全集入口
- 主要 source:
sources/learning/深思圈/含 "法律" / "医疗" / "保险" / "HR" / "招聘" / "销售" / "客服" / "金融" 等 ~66+ 篇 - AI 投资与估值(跨作者主题综合) —— 综合 VC 视角(本 wiki 补足垂直行业数据)
- 需求分析 / JTBD / 产品内核(跨作者主题综合) —— 需求分析(选垂直赛道的方法论)
- 深思圈 / AI Agent 公司案例库 —— Agent 公司案例(垂直 Agent 详情)
- 深思圈 / AI 一级市场 VC 视角(a16z + 红杉 + YC) —— VC 投资视角
来源与关联资料
2026-10-08 增补：硬件研发 Agent，先把变更影响变成可追踪的数据
依据深思圈 10/7 的 Flow Engineering 解读全文整理。来源引用公司材料、投资人对谈和二手研究；融资、估值、客户席位、效率与合规声明未在本次独立核验。以下保留工作机制与验收问题，不将公司自报数字当作实际收益。
垂直产品的切入点可以是跨工具协调
硬件研发中的一个参数变化，可能同时影响需求、设计、仿真、测试和认证。各专业工具分别记录其中一部分，团队却需要知道这些部分是否仍一致。Flow 案例描述的 systems graph（系统关系图），把需求、接口、预算、测试和证据之间的依赖显式连接起来，让变更能沿关系追踪。
这与在每个工具里加一个聊天框的产品方式不同。可评估的价值是减少人工寻找影响范围的时间，以及降低漏掉关联变更的风险。若关系本身没有记录或已过期，agent 再善于生成文字，也无法据此保证工程判断可靠。
先在独立版本里提出改动，再决定是否纳入正式方案
文中演示以电机扭矩变化带动壳体和下游需求调整。它可以启发一条审阅流程：提出需求变更 → 列受影响对象 → 生成候选修改与理由 → 专业人员检查 → 合入正式版本。演示中的几秒响应不等于所有设计都已通过物理验证。
| 检查什么 | 为什么需要 | 可要求的结果 |
|---|---|---|
| 依赖是否完整、资料是否为同一版本 | 漏掉关系会把局部正确误当整体正确 | 变更对象、受影响对象与未覆盖范围 |
| 建议是否能被追溯 | 工程师要理解为何修改，而非只接收新文件 | 原值、建议值、依据及生成时的输入版本 |
| 改动是否经过必要检查 | 能生成 CAD 文件不代表强度、热性能或安全合格 | 仿真、测试与人工审阅分别记录状态 |
| 工具集成变化后是否仍可用 | CAD、仿真或数据接口变化会使关系图失效 | 同步失败提示、停用条件与恢复验证 |
以上是由案例提炼的试点要求，不能当成 Flow 已具备全部能力的产品清单。
将采用规模与工程效果分开衡量
用户席位增加、调用量增加可以说明使用范围扩大，但不能独立说明设计周期缩短、测试更充分或错误减少。评估此类工具时，先定义一类实际变更，记录找到全部影响项所需时间、遗漏数、人工审阅时间和最终返工。前后样本的难度与验收条件需要接近，才有解释力。
成本也不只是一张订阅报价单。把关系数据整理出来、维护接口、处理失效、配合团队审阅都需要投入。若只节省生成文件的时间，却增加了更多验证和协调，整体收益可能有限。
人的职责集中到规格、约束和责任
当部分执行变得容易，团队更需要明确“必须满足什么、允许牺牲什么、由谁接受风险”。一个实用起点是问：改一条需求后，需要多久才知道它影响哪些对象？若总靠临时开会补齐，优先整理依赖与责任可能比增加生成能力更有效。
适合从范围清楚、可做对照的流程试点。物理测试、专业签署和认证不能因 agent 产出更快而省略；涉及国防等领域的部署和合规资格需单独核验。该案例的方法价值在于让协调过程可检查，不在于证明某家公司的估值合理或产品已实现全部承诺。
来源：本次参考文章。
October 8, 2026 addition: make hardware engineering change impacts traceable
Based on Shensiquan's October 7 analysis of Flow Engineering. It cites company materials, investor conversations and secondary research. Funding, valuation, customer seats, efficiency and compliance claims were not independently verified here. This addition retains mechanisms and acceptance questions, without treating company-reported numbers as demonstrated benefits.
A vertical product can start with coordination across tools
A hardware parameter change may affect requirements, design, simulation, testing and certification. Each specialist tool records only part of that picture, while the team needs to know whether the parts remain consistent. The described systems graph connects dependencies among requirements, interfaces, budgets, tests and evidence so that changes can be traced through them.
The potential value is reduced effort finding affected components and a lower risk of missed dependencies. If relationships are missing or outdated, fluent generated text cannot guarantee sound engineering judgment.
Propose changes in a separate version before accepting them
The article demonstrates a motor torque change affecting the housing and downstream requirements. It suggests a review process: propose a requirement change, identify affected objects, generate candidate changes with reasons, obtain specialist review and incorporate accepted changes into the official version. A response within seconds does not mean every design has passed physical validation.
| Check | Reason | Evidence to request |
|---|---|---|
| Dependency completeness and consistent input versions | Missing relationships can make a locally correct result appear globally correct | Changed objects, affected objects and uncovered scope |
| Traceability of suggestions | Engineers need reasons, not just new files | Original value, proposed value, supporting evidence and input versions |
| Required verification | A generated CAD file does not establish strength, thermal or safety performance | Separate simulation, test and human-review states |
| Reliability after integrations change | CAD, simulation and data-interface changes can invalidate the graph | Sync failure alerts, stop conditions and recovery validation |
These are pilot requirements derived from the case, not a list of capabilities already confirmed in Flow.
Measure adoption separately from engineering results
More seats or calls can indicate wider use but do not independently establish shorter design cycles, better testing or fewer errors. Define a real class of changes and measure the time needed to find all affected items, omissions, human review effort and eventual rework. Before-and-after samples should have comparable difficulty and acceptance conditions.
Cost includes organizing dependency data, maintaining integrations, handling failures and supporting team reviews. Saving file-generation time may provide limited overall benefit if it creates more verification and coordination work.
Focus human responsibility on specifications, constraints and accountability
As execution becomes easier, teams need clearer agreement on requirements, acceptable trade-offs and who may accept risk. Ask how long it takes to identify everything affected by one requirement change. If repeated ad hoc meetings fill that gap, documenting dependencies and responsibilities may help more than additional generation capability.
Begin with a bounded process that supports comparison. Faster agent output does not remove physical testing, professional sign-off or certification. Deployment and compliance eligibility in areas such as defense require separate verification. The useful method is making coordination inspectable, not proving a valuation or every product promise.
Source: Article used for this addition.