MiniMax 闫俊杰:AI 创业者该重算模型、Agent 和工程成本1×0:0017:590:08开场问题1:16第一层:M 三的指标,不是榜单分数,而是用量和场景选择2:47第二层:模型和 Agent 不是二选一,它们互相抬高天花板4:15第三层:十 T 模型不是豪赌,先承认两代差距5:49第四层:AI Coding 的拐点,是从写代码回到工程7:56第五层:数据观转向,专家不是顾问,是训练系统的一部分9:31第六层:垂直应用的价值,是把信息变成行动路径10:57第七层:下一个问题,可能是用 AI 理解 AI12:20给创始人的检查清单0:08主持人今天这期,我们处理一场不到四十分钟、信息密度很高的圆桌。主角是 MiniMax 的闫俊杰,也就是 IO。场景是 MiniMax Developer Meetup,旁边还有 Multica、DeerFlow 和金融行业的一线实践者。听完之后,我想把问题改成一句:AI 创业者到底该把钱和时间,压在模型、Agent,还是工程体系上?0:35分析师我会先给素材边界:没有找到公众号完整文字版,公众号账号和近期文章列表已经查过;本期放行依据是公开完整音频的 ASR。我们不剪入原节目原声,只把可核验的时间线和转录语境,转译成创业决策语言。0:54主持人这期最值得听的,不是 MiniMax 的宣传口径,而是几组很硬的取舍:M 三怎么衡量,十 T 模型为什么不能跳级,Agent 和基模是不是会互相吞掉,AI Coding 为什么从写代码回到工程,以及数据为什么从标注工厂变成专家网络。1:16分析师先从 M 三说起。IO 在开头讲,衡量一代模型是否真的行,他看一个相对客观的指标:token 消耗量。他回顾 M 一时,模型效果并不好,但团队第一次跑通 coding 相关链路,已经感受到「后背发凉」的时刻。到 M 二点七,原本一天一万亿 token 就满意,后来冲到十万亿,超过目标十倍。1:43主持人这对创业者有一个直接提醒:不要只问模型在榜单上排第几,也不要只看发布会里说了多少能力。更应该问:哪类用户,在哪个真实工作流里,愿意持续消耗算力?这才接近商业答案。2:00分析师还有一个取舍被他说得很清楚。M 二阶段,团队没有去追所有对话场景,而是明确只做 coding。国内当时有质疑,为什么不管其它场景,但他们选择先把一个方向打穿。创业团队也一样,如果资源有限,早期指标不能叫「我们什么都能做」,指标要能逼你放弃东西。2:26主持人所以第一张行动卡是:你现在有没有一个比点击率、演示效果更硬的用量指标?比如任务完成后的复用次数、每周自动化掉的人工步骤、客户愿意承担的 token 成本。没有这个指标,你可能只是在优化样片。2:47分析师第二个问题,是基模和 Agent 的关系。主持人问:未来还会有 Agent 吗,还是只剩基模?IO 的回答很谨慎。他说,去年这个时候,他也想不到今天的模型会变成这样;模型进步和 harness 进步,不是互斥关系,而是相互促进。3:09主持人这里的例子很有意思。他提到,没有 Claude Code,某些模型可能也没那么火;反过来,没有更强的模型,Codex 这类产品也起不来。换句话说,Agent 不是模型之外的装饰,模型也不是 Agent 的替代品。两者合在一起,才形成用户眼里的智能。3:33分析师给创业者的判断是:不要把路线争论变成宗教站队。做应用的人要问的是,你控制的是哪一段反馈回路。你是更懂用户任务,能把模型接进环境?还是更懂验证和交付,能让 Agent 长期稳定?如果只是套一个聊天框,模型一升级,你的空间会被压缩。3:55主持人这一层也解释了 Multica 创始人的分享。他们在工作流里不只用单一模型,而是把不同模型、不同 Agent 组合起来,在成本和质量之间找平衡。对创业团队来说,模型编排不是炫技,而是成本结构。4:15分析师第三层,进入十 T 模型。IO 被问到最大卡点是什么,他没有说某一个神秘算法,而是说需要时间,需要积累。他把 AI 类比成半导体:这是一个产业,障碍不是一堵墙,而是一代一代把工程、数据、算法、算力都往上推。4:38主持人他还有一个具体判断:美国模型基本大十倍,而十倍意味着两代差距。国内模型要先把三 T 做好,再做十 T。这里的 T 可以理解为模型规模量级,不是一个营销数字。更大的模型还带来数据问题,十 T 模型按经验需要二百 T 数据,但全世界没有那么多高质量数据。5:03分析师这一段对应用创业者特别重要。很多商业计划默认大模型能力会线性变好、价格会线性下降,然后自己只要等风来。IO 提醒的是,规模外推有边界,跳太远就像开盲盒。你不能把公司活下去的前提,放在一个还没被工程证明的外推上。5:26主持人创始人要把这句话翻成预算表:如果模型两代之后才满足你的产品假设,你现在靠什么服务客户?如果十倍算力差距短期不会消失,你的产品是不是必须避开正面算力战?如果数据质量比数量还难,你有没有自己的高质量场景数据?5:49分析师这期最适合产品团队反复听的,是 AI Coding 部分。嘉宾先说,人人都能 vibe coding 之后,人人都像产品经理。但好产品经理的标准,从来不是提了一百个需求,而是知道什么不做。6:07主持人何涛的表达更直接:大家热衷讲 vibe coding,却很少讲工程责任。代码不是一次性吐出一个结果,工程要能长期维护、持续交付,还要能被下一个人接手。这个判断会击中很多 AI 产品团队,因为生成速度变快之后,验证、review 和上线证据反而掉队。6:31分析师他还说,最讨厌别人讲「这是 Agent 做的,别怪我」。只要代码用你的账号提交,背后表达的就是你的责任心。这句话可以直接贴在每个 AI Coding 团队的代码审查页面上。6:48主持人这里还有一个更细的产品启发:今天的 benchmark 多数在测一次性解决问题,模型会拼命使命必达。但真实软件工程要看长程维护,要看代码库会不会越来越烂,要看下一次迭代能不能接得上。创业者如果卖 AI Coding 工具,只做生成端,会很快卷进模型能力;做验证、治理、上下文和责任链,才可能变成工作流。7:14分析师MiniMax 内部也有相似体感:生成能力已经大幅提高,一个人能改十几个仓库、开很大的 PR,但没人敢上线,因为验证没有跟上。这个信号比「生成更快」更值钱。下一个机会可能在测试生成、风险定位、代码库体检、上线前证据链,而不只是再做一个写代码入口。7:39主持人第四张行动卡很简单:把你团队的 AI 研发预算分成两栏,一栏叫生产,一栏叫验证。如果验证投入不到生产投入的一半,你可能只是在堆未来的技术债。7:56分析师接下来是数据观。IO 说,一年前很多人理解数据就是标注;现在他们开始找经济学家、哲学家,甚至核物理学家。为什么?因为模型想进入行业,真实问题、评测框架和 taste,往往不在算法同学手里。8:18主持人他用 coding 举例:开发工程师比算法同学更懂什么叫好代码。算法同学能做模型框架,但如何评测、如何归类、如何构造任务环境,真正的软件工程师更懂。把这个逻辑扩到金融、法律、网安、医学,专家就不再是「来开会提建议」的人,而是训练和评测系统的一环。8:44分析师这会改变创业公司的组织设计。过去很多 AI 公司把专家当外部顾问,偶尔访谈,做几条标注规范。现在要问得更重:专家能不能定义任务?能不能挑出坏答案?能不能给出可反复执行的评分标准?能不能把自己的判断拆成模型可学习的样本和环境?9:10主持人十 X 专家合作项目,放在这个背景下更好理解。它不是简单招募大咖背书,而是补模型在高价值领域里的评测和 taste。AI 创业者要意识到,未来的数据护城河不只是「我有多少条数据」,还包括「谁能判断这些数据有没有用」。9:31分析师圆桌里金融行业嘉宾讲了一个朴素但重要的点。很多用户不会表达需求,只会说「帮我选几只个股」。AI 的第一步是筛选信息,第二步是降低门槛,让用户理解术语和数字。但更难的是,当市场变化真的发生时,系统能不能告诉用户下一步怎么做。9:56主持人这对所有垂直 AI 产品都有启发。用户买的不是信息罗列,而是决策路径。很多产品停在「我把资料列给你」,结果用户还是不知道怎么行动。金融场景只是更极端,因为实时性、合规和风险都很高。10:15分析师如果你做行业 Agent,应该少问「我能不能回答用户问题」,多问「我能不能在高频变化里,持续降低用户行动门槛」。这需要个人画像、行业语境、合规边界、实时反馈和下一步建议。它更像服务系统,不像单次问答。10:37主持人这也解释了为什么「陪伴」被提到。陪伴不是温柔话术,而是在用户压力很高、信息很多、行动不确定时,系统仍然能保持上下文,给出下一步。创业者可以把陪伴理解成长期任务管理,不要只理解成情绪聊天。10:57分析师最后,IO 说自己特别关心的一件事:什么时候 AI 能帮助人类理解 AI。他承认,现在的 AI 对从业者来说也是黑盒,人类现有数学工具很难解释复杂网络。随着模型越来越强,可解释性、安全和对齐会变得更关键。11:19主持人他还提到生命科学里的类比,比如大脑机制和深度网络之间的相似性。这些内容在圆桌里讲得不长,但方向很明确:当模型规模继续变大,单靠人类直觉理解模型,可能不够。要用 AI 去分析 AI,用工具去解释工具。11:40分析师创业者不一定要马上做可解释性公司,但应该把这个问题放进路线图:你的产品如何证明它可靠?当客户问「为什么是这个答案」时,你能不能给出比日志更强的证据?当模型出错时,你能不能定位是数据、提示、工具、上下文还是权限问题?12:05主持人这不是学术洁癖。ToB 客户、金融客户、医疗客户、代码客户,都需要解释和责任链。越是高价值场景,越不能只说「模型觉得」。12:20分析师我们把本期压成六个检查问题。第一,你有没有一个真实用量指标,而不是发布会指标?第二,你的产品有没有明确说不做什么?第三,你是在押单一模型能力,还是在设计模型和 Agent 的组合系统?12:41主持人第四,你的验证能力是否跟得上生成能力?第五,你有没有把行业专家放进评测和数据闭环,而不是只放进顾问名单?第六,如果模型十倍变强、十倍变便宜,你的壁垒会变厚,还是会消失?13:03分析师如果六个问题里有三个答不上来,这期节目建议你回去先改路线图。MiniMax 这场圆桌给出的不是一个确定答案,而是一组现实约束:规模要时间,工程要责任,数据要专家,Agent 要反馈回路,垂直应用要行动路径。13:25主持人收尾之前,再补一段更具体的用法。如果你是 AI 产品创始人,听完这场圆桌,不要只在脑子里留下「MiniMax 要训十 T」这个新闻点。更有价值的,是把自己公司的路线图拆成三张图:模型能力图、Agent 工作流图、验证责任图。13:45分析师模型能力图回答一个问题:哪些能力必须等下一代基模,哪些能力今天已经够用。很多团队会把所有失败都归因于模型不够强,这样很安全,也很危险。安全在于没人能反驳,危险在于你会错过工作流、数据、评测和交付里的真实问题。14:10主持人Agent 工作流图回答第二个问题:用户从意图到结果,中间有多少步需要环境、权限、工具和上下文。圆桌里反复出现的词,不只是模型,还有 harness、context、review、交付。应用公司如果只盯模型回答,会漏掉用户真正卡住的地方。14:32分析师验证责任图回答第三个问题:谁为结果负责。AI Coding 里,这个问题最尖锐;但它也适用于金融、法律、医疗、企业流程。用户不会因为「这是 Agent 做的」就免除损失。你的产品必须能说明,模型做了什么,人审了什么,系统拦了什么,哪些场景不能自动化。15:00主持人再看成本。Multica 提到的多模型组合,对早期团队很实用。不要把所有任务都交给最贵模型,也不要为了省钱牺牲关键步骤。比较好的设计是:便宜模型处理可批量、低风险的部分,强模型处理高不确定任务,再用独立检查者做 review。成本结构本身会变成产品体验。15:26分析师再看专家。IO 对专家数据的判断,意味着很多行业 AI 公司要重写招聘画像。你需要的专家,不是只会给客户背书的人,而是愿意和工程团队一起定义坏案例、改评测集、写边界条件的人。专家如果不能进入生产系统,只停在销售材料里,就不是护城河。15:49主持人再看融资叙事。投资人听过太多「模型更强以后我们就起飞」。这期给出一个更可信的讲法:哪些价值随模型进步释放,哪些价值来自你自己的工作流、数据和专家网络。前者说明你站在趋势上,后者说明你不是被模型升级顺手带走的那一层。16:11分析师对产品负责人,我会加一个小测试:把你的产品交给一个更强、更便宜、更长上下文的模型,问自己,客户为什么还要用你。如果答案只剩「界面更好看」,就要警惕。如果答案是「我有更稳定的任务环境、更准的行业评测、更低的上线风险」,那才接近本期反复出现的工程语言。16:38主持人对团队管理者,还有一个提醒:AI 把每个人都推向产品经理位置,不代表每个人都有产品判断。相反,判断会更稀缺。你要训练团队说清楚为什么不做某件事,为什么这个 PR 不能上线,为什么这个行业需求要先拆成评测,而不是马上丢给 Agent。17:00分析师最后,把这期内容落成一个明天能开的会:第一,列出本周最消耗 token 的三个工作流;第二,找出最缺验证的一个环节;第三,选一个行业专家,把他拉进评测设计,而不是只拉去客户访谈;第四,给每个 Agent 输出加一条责任链。17:23主持人本期就到这里。来源包括「十字路口Crossing」小宇宙单集页面、公开完整音频和本轮完整 ASR。由于没有取得公众号完整文字版,我们没有剪入原节目嘉宾原声。建议你把原集从十七分五十三秒的 AI Coding 段落开始回听,再跳到二十七分十二秒的数据观转向;如果你正在做 AI 产品,那两段最值得带回团队讨论。
Añade más opiniones o contexto en torno a este contenido.