1. 先说2025年的全局创业公司都挤在哪几条赛道上1.1 模型竞赛已经降温落地效率成为主场2025年聊大模型创业会发现一个很明显的变化没人再拿参数规模和榜单分数当第一卖点了。两年前出门见客户不先报一遍模型版本、刷一遍分数好像就不好意思谈合作。现在再这么干客户往往会回一句“分数很漂亮然后呢你能帮我解决哪条业务线的实际问题”这种变化的背后是基础模型的能力红利期正在收窄。各家底座模型在中文理解、逻辑推理、多模态识别上的差距在快速缩小真正拉开业务效果的已经变成知识库质量、Agent任务编排、反馈闭环、部署运维这些工程层面的东西。对创业公司来说这意味着两条路分化得非常明显。一类继续往上游走做前沿模型和底层能力押注的是长期技术壁垒和生态卡位。另一类开始往下游沉深入具体行业场景把模型能力包装成客户看得懂、用得上的产品和方案。这两类公司的逻辑、估值方式、合作模式都不一样完全不建议放到同一个池子里比较。做选型第一步不是看排名而是先搞清楚对方属于哪种打法否则后面所有的评估维度都会错位。1.2 今天活跃的五类公司画像结合我自己做技术尽调和项目对接的经验2025年还在市场上活跃的大模型应用创业公司大致能分成五类。第一类是基础模型研发型。重资产、高投入团队规模大擅长模型预训练、对齐、多模态拓展通常拿的是大额融资商业化路径以API开放和行业联合为主。这类公司数量最少但声量最大。第二类是模型中间工具型。做评测平台、微调工具链、推理加速、数据合成与清洗、Agent编排框架。这类公司一般不直接面向最终用户而是给上层应用和内部IT团队提供“弹药”估值逻辑接近基础设施。它们的客户往往不是终端企业而是其他创业公司。第三类是垂直行业应用型。这是目前数量最多、融资最密集的一类聚焦在金融、医疗、法律、制造、零售、教育等领域。客户付费意愿比较强落地路径清晰团队通常同时具备行业know-how和技术能力。第四类是AI原生产品型。直接面向C端用户或中小企业做知识管理、内容创作、代码助手、营销自动化这类标准化产品特点是产品体验驱动依赖口碑传播和订阅制付费。第五类是交付实施型。本质上是方案集成商或服务商承接大厂和垂直公司不愿做的脏活累活在具体客户现场完成稳定交付。这类团队不一定有很强的模型研发能力但胜在工程化落地经验和客户关系。这五类之间不是完全隔离的。很多公司一边对外说自己是垂直应用厂商一边悄悄自研模型微调工具链也有不少AI原生产品公司做着做着开始接企业私有化部署的单子。但不管它们怎么跨界底层的能力重心决定了它们适合什么样的客户、能扛多大的项目复杂度。选型时先给标的公司归类能少走很多弯路。2. 今年的选型逻辑和两年前有什么不同2.1 好事是选择多了难事是决策更难了两年前做企业AI选型基本是道单选题用哪家海外模型还是用哪家国产模型用闭源API还是开源私有化。今天完全不是这样。国产开源模型的能力已经能覆盖绝大多数行业应用需求商用API服务也相当成熟创业公司可以在开源底座上做微调和私有化选择空间和组合方式多到令人眼花缭乱。但选择多并不代表选型更容易。因为每一层都有多个供应商、多种替代方案决策者需要评估的变量变多了底座模型的迭代速度、中间层的兼容性、应用层的交付深度、数据合规的边界、未来迁移的代价。我见过不少团队花了一个季度做选型最后选了某个底座模型却发现核心应用依赖了它独有的工具调用方式想换掉必须重写大片业务逻辑。这种锁定问题比“选错模型”更隐蔽因为当时做技术选型时所有评估都只盯着单点能力没人从整个系统链路的角度看依赖关系。2.2 不同体量客户对“好产品”的定义完全不同选型逻辑变化的另一面是客户视角在分化。对小微企业来说一个好的大模型产品应该是打开就能用、按年订阅、出了问题有人远程处理。它们要的是确定性和效率不是定制化。对中大型企业来说情况复杂得多。它们通常有明确的安全边界、历史系统和复杂的权限体系希望引入AI不是“加一个玩具”而是真正嵌入到现有业务流程中。这类客户看重私有化部署能力、合规框架、售后响应速度和团队规模。一套方案通吃所有客群的日子已经过去了所以同一家创业公司在中小企业眼里可能是好产品在大企业眼里可能连投标资格都没有反过来也是一样。先把自身需求类型定清楚再对照市场的产品类型去找才不会有“所有人都说好我用起来全是问题”的错位感。3. 评估一家大模型创业公司我看九个维度3.1 技术硬实力工程能力比模型能力更值钱面一家大模型应用创业公司我最先看的就是工程团队能不能把“模型调用”变成“稳定服务”。具体来说有三层。第一层是模型层能力包括是否掌握微调、对齐技术、提示词优化第二层是数据层知识库清洗、向量化、索引策略、更新机制都要有清晰方案第三层是系统层包括检索增强生成RAG效果调优、Agent多步任务执行的可控性、异常降级、日志、监控与告警。判断工程能力有一个比较实用的办法让对方做一个现场演示不是那种提前录好的视频而是从零开始一边讲一边做并且特意追问几个反常规的问题比如知识库内容过期了怎么办、模型输出格式不稳定时怎么兜底、系统压力上来时延迟会怎样变化。一个工程体系完整的团队对这些问题的回答通常是具体到某个模块某个配置项的。只会反复讲平台方法论、追问细节就开始含糊其词的团队大概率还停留在Demo水平。这里我也给一条特别实在的建议让对方的研发负责人而不是售前解决方案专家来参加技术交流两者的信息密度完全不同。3.2 商业化健康度投入产出比和续费率才是试金石评估一家创业公司的商业化能力不要只盯着它融资融到第几轮要重点看三组数据。第一主营业务收入规模以及收入来自多少个客户。如果收入高度集中在少数几个大客户身上经营风险就比较突出。第二老客户续费率。这是最能说明产品长期价值的指标续费率高意味着产品真正嵌入了客户业务而不只是一个一次性项目。第三客单价和交付成本之间的关系。如果交付成本长期高于客单价说明产品标准化程度不够这样的公司规模越大亏损越严重。我在实际尽调时还会做一件小事请对方提供两个老客户的联系方式主动打电话聊一聊。不用问太商业化的敏感数据就问使用频率、系统稳定性、售后响应以及“如果再选一次还会不会选它”。这种来自用户侧的真实反馈经常比合同数据和融资新闻更能说明问题。有一回我从客户电话里听出对方语气犹豫本来合同的签章都很齐全但那个犹豫让我决定再补一轮POC验证最后果然在项目推进过程中暴露了不少交付能力问题提前规避了更大的坑。3.3 数据与合规选型评估表里的第一页数据合规已经不是后台问题而是大模型应用能不能上线的前置条件尤其对金融、医疗、政务等强监管行业。选型前必须逐项确认训练数据来源是否可追溯、客户业务数据会不会被用于模型再训练、私有化部署是否支持数据完全不出域、日志脱敏与审计保留机制是否健全、系统输出是否具备审核过滤能力。这五项里任何一项不满足项目到了上线阶段一定会被卡住到时候返工成本远超选型阶段多花的那几天。创业公司里的合规能力参差不齐是一个普遍现象。小团队通常没有专职合规人员常常全靠云厂商平台自带的能力撑场面。更常见的问题是销售在商务阶段口头承诺一些合规能力但到交付阶段技术体系根本实现不了。所以我现在的习惯是把合规问题做成一张Do-List放到评估表格第一页并且在商务阶段就要求对方提供合规相关的说明材料。宁可在这个环节多花时间也不要到验收阶段才发现承诺和实现存在巨大落差。3.4 团队、资本与服务半径看这家公司能陪你走多久大模型应用项目的实施周期通常在三到十二个月。选型表面上是选产品实质上是在选一个能够陪你跑完全程的合作伙伴。因此至少要评估三方面第一资金储备和融资节奏账上现金能撑多少个月有没有大额不确定的支出第二核心团队的构成技术创始人懂不懂行业行业合伙人有没有真实业务操盘经验第三公司的服务半径本地有没有实施团队出了问题多久能响应是否有远程支持的能力储备。这里面最容易出现的认知偏差是只看公司名气。名气大的公司不一定服务好反而因为客户太多响应速度会变慢。反而一些专注某个细分赛道的小团队因为服务客户数量少反而可以做到深度支持。选型不是找最有名的而是找适配自己项目节奏的。3.5 生态位与供应商依赖它是不是随时可能被上游吃掉还要看一家创业公司在产业链上的位置。底座模型厂商、云厂商、行业ISV、应用层公司各环节互相依赖同时也互相挤压。好的创业公司通常会尽量减少对单一上游的依赖。比如做垂直应用的团队在架构上同时兼容多个国产开源模型和多家云的部署环境这样即便某个模型商调整价格或策略它也能快速替换。反过来说如果一家公司的核心能力完全依附于某家上游价格、服务、路线图都被人卡着那你选择它就等于把命运交给了它上游的不确定性。选型时可以做一个小测试问对方“如果你们现在的主打模型出现问题业务能不能在两周内切到备用模型”。真正生态位健康的团队会告诉你它们的架构早就做好了抽象和兼容并给出具体的切换方案。如果对方一脸茫然说明系统是深度耦合的后续风险就要记到评估列表里。4. 从POC到采购的实操全流程哪些细节最容易被忽略4.1 立项前先做三件事边界、基线、ROI很多项目烂尾不是技术不行而是业务需求从一开始就没立住。进入选型阶段前先回答三个问题。第一要解决的业务问题到底是什么是降低客服人力成本还是提升销售人员人效或者减少文档处理时间边界一定要具体。第二目前的基线数据是多少比如当前客户问题解决率、平均处理时长、人力成本基线越清楚后面验证效果才有参照。第三希望通过AI获得什么程度的提升以及这个提升折算成钱有多少。不要用“显著提升”这种没有任何约束的词要落到可量化的指标上。ROI估算我习惯用最保守的算法把AI带来的效率提升打折一半再减去部署、运营、模型调用、人力投入等显性成本如果算下来还有正收益这个项目才值得推进。很多项目之所以做到一半被叫停就是因为ROI从一开始就从来没有真正算清楚上线测试看着热闹复盘时发现对业务指标没有实质改善。4.2 POC测试方案的设计与评分表POC阶段最怕的就是让供应商自己出一个演示方案自由发挥。正确做法是甲方主动控制测试范围。我一般会设计三组测试集。第一组用真实业务数据做准确率测试数据要先脱敏但保留真实的业务复杂度和干扰项。第二组做复杂任务流测试把多个子任务串起来考察Agent在跨步骤执行、异常恢复上的表现。第三组做稳定性测试在接近真实负载和弱网环境下连续运行观察延迟、报错率、资源占用。每一组测试都要有明确的评分项和通过线并且提前设成文档发给供应商。评分表不建议太复杂挑四五个关键项就够回答准确率、任务完成率、系统稳定性、知识更新时效。POC期间发现的问题不要忍一条一条记录下来在评审环节要求供应商给出改进计划和时间表。如果对方在POC阶段就没有改进意愿或者改不动那正式项目里大概率更糟糕这时换供应商比项目中途换人要轻松得多。4.3 合同评审最容易漏掉的六件事技术讨论热火朝天的时候合同反而是最容易出问题的地方。结合我的经验建议重点核六项。第一数据使用权限。客户在平台上产生的所有数据产权归谁供应商能否用于训练。第二SLA与违约责任。系统可用性承诺多少、故障响应时限、赔偿上限是什么。第三安全与审计。日志保留期限、审计接口开放、数据跨域传输限制。第四知识产权归属。定制开发的代码、模型微调产物、提示词模板归属要写清楚。第五迁移与解约。合同期满或终止时模型、数据、知识库如何迁移回客户环境供应商是否有义务配合。第六售后级别。售后响应L1/L2/L3分别多久是否包含驻场服务。这六项里最容易“谈崩”的是数据使用权和迁移权。前者是因为供应商通常希望用客户数据提升模型哪怕只是匿名化处理也需要在合同里明确授权边界。后者则关乎长期被套牢的风险。我会在技术选型阶段就把这两点作为硬性门槛写进需求文档凡是这两点含糊的供应商直接排除可以省去后面大量扯皮。5. 真实项目复盘三个典型的坑和对应的解法5.1 被Demo迷惑低估长尾问题的处理成本这个案例是某零售企业采购智能客服系统对方在POC阶段表现得近乎完美演示数据里问什么答什么。但上线后才暴露真实问题POC数据是供应商精心整理的测试集真实业务里的长尾问题、口语化表达、特殊情况占比非常高系统一开始完全扛不住。团队花了近三个月重新清洗知识库把历史工单重新分类标注又做了好几轮微调投入成本远超当初测算。复盘这个问题原因出在POC设计时用了供应商提供的数据而不是客户真实脱敏数据也没有充分模拟真实对话的分布。这之后我做POC有一条铁律测试数据必须由甲方提供并且覆盖典型场景和大量边缘情况否则测试结果不能作为选型依据。5.2 私有化部署网络环境被严重低估另一个项目是某制造企业选择私有化部署。POC和商务阶段都挺顺利结果到了部署现场才发现客户网络环境极其复杂业务系统分布在多个安全域GPU集群和业务网之间还有严格的访问控制策略。供应商原计划一周完成的部署硬是搞了一个多月中间还因为端口策略反复调整耽误了大量时间。后来我把部署前的环境调研上升为必做项采购方在选型阶段就要配合供应商提供一份详细的基础设施说明包括网络拓扑、安全域划分、资源配额、外联限制。技术团队提前介入做预检远比到了现场再解决问题高效得多。5.3 合规审查拖垮项目周期教训惨痛第三个案例是金融场景。项目合同都签了实施团队也进场了结果在合规审查阶段发现供应商没有完整的审计日志机制输出内容事后抽查的体系也没搭好无法满足金融机构的审计要求。整改持续了两个多月项目上线被硬生生推迟客户高层非常不满。这件事发生后我把合规Do-List放到选型评估的首位。每次项目启动前先同步一份最新版的合规检查项清单给供应商让它逐条盖章确认。不是不信任对方而是让双方在最早阶段就对齐预期避免商务、技术、合规三个角色到最后才发现彼此理解完全不同。6. 按你的需求类型给一套快速选型建议6.1 中小企业买标准化产品不要养项目如果你是一家中小企业没有专职AI技术团队选型的第一原则就是买成熟标准化产品而不是找团队做定制开发。优先看三点上线周期是不是在一两周内、按年订阅价格是否清晰透明、是否提供标准客服。这类产品不必追求大而全聚焦某个具体痛点即可。你真正需要的是快速见效和确定性不要被“AI时代必须自建”的观念绑架。6.2 中大型企业POC验证不可省中大型企业选型要复杂得多。建议组成跨部门选型小组包含业务、技术、合规三个角色至少预留一个月做完整POC。重点看私有化与部署能力、合规体系完备度、团队交付规模、系统集成能力。如果有条件同时选两家不同赛道的公司做背靠背POC内容和评分口径保持一致横向对比比单家验证更有价值。6.3 创业者从具体场景下手别从模型下手如果你自己正在考虑进入这个赛道我的建议是别把“做一个大模型”当出发点。大模型基础赛道的窗口期已经关闭剩下的是资本密集和技术密集的战场。真正值得做的是找到一个足够具体、付费意愿强的垂直场景把模型能力、行业认知和交付流程整合成一个可规模化的产品。2025年创业公司的机会不在于能训练多大的模型而在于能把多窄的场景做穿做透。7. 常见问题速查选型中反复被问到的五个问题7.1 大厂平台和创业公司方案到底怎么选很多客户一上来就会问这个问题。我的判断标准很简单如果你的需求是标准化的通用能力比如通用的对话问答、内容摘要、文本分类大厂平台通常性价比更高生态也更完善。但如果你的业务高度垂直有独特的流程和知识体系创业公司的深度定制能力反而更值得投入。大厂的优势是稳定和规模劣势是需求和响应速度创业公司优势是灵活和专注劣势是抗风险能力。先问清楚自己的需求是“通用”还是“专用”答案基本就出来了。7.2 API调用还是私有化部署用什么标准判断这取决于三个因素数据敏感度、业务频次、改造意愿。数据敏感的行业没得选基本只能私有化。业务频次高的场景要精细算账因为API按量计费跑起来长期成本未必比一次性私有化投入便宜。如果团队有技术能力、愿意持续优化私有化会越用越顺手如果只是想快速验证API是最务实的起点。我见过有客户一开始就选私有化结果因为内部缺乏维护能力GPU集群利用率不到三成反而是个很大的浪费。7.3 初创公司会不会很快倒下这个担心很真实但也不是完全没有应对方式。看两个指标就够现金流和服务合同。现金流看它账上的钱能不能撑过十二个月服务合同看它的收入是不是来自多个行业、多个客户。另外尽早约定数据迁移权和解约条款本质上就是为“万一倒下”准备的保险机制。真正需要警惕的不是对方会黄而是它黄了你无法脱离那才是问题。7.4 要不要一开始就自己微调模型我的态度是大多数企业不需要从第一天开始微调模型。先用好通用模型的能力搭好知识库和业务流程跑起来之后你会发现很多问题其实不需要微调通过提示词和检索优化就能解决。只有当你明确知道模型在哪类任务上持续拉胯并且积累了足够的训练数据才值得考虑微调。一上来就微调大概率是在错误的方向上浪费算力。7.5 多模态能力在业务场景中到底有多重要多模态确实是2025年的热点但要分清是伪需求还是真需求。如果业务里有单据识别、图片审核、视频内容理解多模态能力能直接缩短流程、降低人力成本这就是真需求。如果只是为了上新品而强行加一个多模态入口用户体验反而可能变差。选型时不要让“支持多模态”成为一个纯加分项要实际准备一批业务样本让供应商验证看识别精度和响应延迟能否达到可用线。8. 最后聊几句个人体会我自己这几年做过不少选型辅助工作一个很深的体会是大模型项目做得好坏往往在合同签字之前就已经决定了。需求边界是否清晰、POC测试是否真实、合规条款是否对齐、供应商技术底子是否扎实这些环节里任何一个疏忽都会在后面的交付阶段以数倍代价偿还。选型不是找“最强”的公司而是找“最匹配当前项目阶段”的团队。比技术细节更重要的永远是双方的信任、承诺和对现实问题的共同理解。如果再让我补充一个实操小技巧无论选哪家一定在正式合作前和这家公司的核心研发负责人做一次开放交流聊透业务的痛点和落地的具体路径。对方的眼神、语气、在这个问题上是否真正有热情往往比任何评分表都更能说明问题。祝所有正在选型的团队都能找到那个真正能陪你一起把业务跑通的伙伴。