如何搭建端到端 AI 团队
2026年 4月 25号过去十年，中国几乎每一家头部互联网公司都建过一个 AI 研究院，然后又以各自不同的方式，悄悄地把它拆掉了。这不是偶然。研究和产品之间有一道结构性的鸿沟，单靠招来顶级人才填不平它。这篇文章试图讲清楚这道鸿沟从哪里来，以及什么样的团队结构能真正跨越它。
引言：打破”全栈”的错觉
腾讯 AI Lab 是最典型的例子。2016 年成立，翌年从百度挖来学术大牛张潼出任主任，50 余位 AI 科学家加上 200 名工程师，阵容豪华。但不到两年，张潼以”回归学界”为由离职。继任者张正友接手，创始成员姚星后来也相继出走，整个 AI Lab 在 2026 年 3 月以”撤销”告终。
为什么？问题不出在人身上。张潼的学术地位毋庸置疑，团队的技术能力也有目共睹。问题出在结构上：研究院的成果要进入产品，需要经过漫长的产品化链条。而这条链条中，有一道几乎没人能跨过的鸿沟。研究院能完成从立项到发论文的全部动作，但产品化那一步始终落不了地。”过去很长一段时间，AI Lab 的人员也感觉比较模糊”——这句话道出了真正的病灶：不是能力模糊，是方向模糊，是定位模糊，是研究与产品之间的连接，从一开始就没有建起来。
百度更早一步演示了同一个剧本。吴恩达以首席科学家身份主持”百度大脑”计划三年后出走，张潼本人也是从那一轮离职潮中流出的。两家公司、两批顶级人才、两个几乎相同的结局。
但如果你觉得这只是中国互联网公司特有的病，Yann LeCun 的故事应该能打消这个念头。
2013 年，LeCun 加入 Meta，亲手创立了 FAIR（基础人工智能研究实验室），把它建成全球顶尖的 AI 学术机构之一。此后十二年，FAIR 发表了大量奠基性论文，吸引了全球最优秀的 AI 研究者。从外部看，这是硅谷版的”研究院成功故事”。
但 FAIR 内部的重力，一直在悄悄改变方向。
2022 年，Meta 全面转向元宇宙，FAIR 被并入 Reality Labs。两年后又被划归产品部门，与 GenAI 团队共同推进产品化工作。原先承诺的自由研究氛围，被自上而下的项目目标与 KPI 所取代。矛盾在 2025 年彻底激化：扎克伯格任命 Alexandr Wang 主导新的”超级智能”部门，主打激进的 LLM 产品化路线。新政策规定，FAIR 研究人员发表任何论文之前，必须先提交给新部门审查；如果该研究被认为具有”重大商业价值”，论文将被禁止发表，研究者将被要求先帮助将成果在 Meta 产品中落地——之后才能回归日常研究。
这道命令，彻底终结了 FAIR 作为纯粹学术机构的属性。
2025 年 11 月，图灵奖得主、Meta AI 首席科学家 LeCun 正式宣布离开工作了 12 年的 Meta。他在巴黎创立的 AMI Labs 于 2026 年 1 月启动，种子轮融资超过 10 亿美元，目标是构建”世界模型”——让 AI 从理解真实物理世界入手，而非仅仅预测下一个词。
LeCun 的离开和张潼的离开，表面上看是两个人做了个人职业选择。但背后的结构几乎一模一样：一个顶级研究者被请进来，被赋予”做出伟大研究”的使命；然后产品压力进来，研究开始服务于季度目标；研究者的议程被边缘化；最终，人走了，研究院或关掉，或变成另一种东西。
这个故事每隔几年就会在某家大公司里重演一次，而且几乎每一次，都以研究院的失败告终。
失败的根本不是人，而是一种结构性的错误假设：以为把顶级研究者放进公司，研究就能自然流向产品。
它从来没有自然发生过。
研究之所以无法自然流向产品，是因为两者之间隔着的不是一堵墙，而是两套完全不同的时间观、语言体系和成功标准。研究员用 benchmark 说话，产品团队用 DAU 说话；研究的探索周期是以季度计，产品的迭代 sprint 是以两周计；研究员眼中的”突破”，在产品经理看来可能意味着”还要再等六个月”。
这不是沟通问题。沟通问题可以靠周会解决。这是一个结构问题——两种逻辑从起点就在往不同方向运行，没有任何机制让它们在中途汇合。
所谓”全栈 AI 团队”的错觉，正是在这里诞生的。一个团队同时拥有研究员和工程师，就以为自己拥有了端到端的能力。但如果研究和产品之间没有真正的信息回路，这个团队不过是两种孤立能力的物理叠加，而不是一个有机的整体。
真正的端到端，不是”什么都有”，而是”让研究和产品互相定义”。
两种残缺的团队
同一个失败时刻
某家为银行提供 AI 服务的公司，核心产品是一套面向信贷审批的智能辅助系统。客户经理上传借款人的财务材料，系统自动分析偿债能力、识别潜在风险信号、生成结构化的审批建议。产品上线将近一年，几家城商行已经在用，续约率不错。
然后一家合作银行的风控负责人发来了一条消息。
他们遇到了一个问题：一批小微企业主的贷款申请，系统一律给出了”风险偏高，建议谨慎”的结论。但风控团队人工复核后发现，其中相当一部分其实是优质客户——他们的财务报表看起来不稳定，是因为这类客户普遍存在季节性现金流波动，旺季回款集中、淡季账面难看，这是行业特性，不是风险信号。
系统没有识别出这个模式。它看到的是低谷期的现金流数字，然后给出了它认为合理的结论。
风控负责人在消息末尾加了一句：”这类客户我们行本来是重点扶持方向，但系统一直在误伤他们。”
产品经理把这条反馈记在了表格里，标注为”高优先级”。
然后，这个失败时刻在两种不同的团队结构里，走向了两种截然不同的命运。
Research 侧：失败样本永远到不了研究员手中
在纯 Research 导向的团队里，这条反馈的旅程大概是这样的：
产品经理把它整理进月度用户反馈汇总。汇总发给产品负责人，产品负责人在下周的产品会上提了一句”小微信贷场景有个准确率的问题”。这句话被记进会议纪要，然后沉入了协作文档的历史版本。
研究员们不在那个会上。他们正在处理另一件事：团队在推进一个信用风险建模的新方向，基于公开的上市公司财报数据训练了一个改进版模型，在标准信用评估 benchmark 上的 AUC 比上一版提升了 0.03，正在整理结果准备投稿。
没有人刻意隐瞒什么。只是那家银行的反馈，和研究员正在做的事情，活在两个完全不同的世界里。
产品里真实发生的失败，携带着极其珍贵的信息：系统在哪类客群上出现了系统性偏差？偏差的根源是特征工程的问题，还是训练数据本身的分布偏移？季节性现金流这个模式，在现有特征体系里根本没有被表达，还是被表达了但权重设置有问题？这些问题，只有拿到真实 badcase 的研究员才能回答。
但 badcase 停在 PM 的表格里。研究员永远看不到它。
他们的论文顺利投出去了，benchmark 指标漂亮。产品里那批小微企业主，在下一个版本里依然被误伤。
Dev 侧：只能在已知选项里穷举
在纯 Dev 导向的团队里，同一条反馈的旅程是另一种样子。
工程师拿到了这个问题。他们动手很快：先把那批被误判客户的财务数据单独拉出来看，发现现金流波动确实很大，于是在 prompt 里加了一条引导：”如果借款人属于季节性行业，请结合全年平均现金流而非单月数据进行判断”。重新跑了一遍，部分案例的结论有所改善。接着又在特征层面做了调整，加入了现金流的季度环比标准差作为辅助指标，测试集表现进一步提升。
问题表面上被压住了一些。
但没有人知道这个方案的边界在哪里。加进去的那个季度环比指标，是拍脑袋选的，还是真的捕捉到了季节性波动的本质？prompt 里那句行业引导，覆盖了哪些行业、漏掉了哪些行业，有没有人系统梳理过？工程师们知道怎么调，但调完之后心里并没有底——因为从一开始就没有人真正搞清楚，这个偏差是怎么产生的。
解空间的边界就在那里。在边界以内，工程师可以穷举所有已知的调优手段；但边界之外的那个解——比如重新设计针对非标准财务结构的特征体系，或者引入行业基准数据对齐客群分布——没有人看见，也没有人有能力去够到它。
下一个季度，类似的客诉又来了，这次换了一类客群：个体工商户，收入流水和个人账户混在一起，系统同样给出了不准的结论。工程师又开始了新一轮穷举。
合并收口：断掉的是同一条信息链
两个团队，两种失败，看起来性质不同。Research 侧的问题是”脱离现实”，Dev 侧的问题是”缺乏纵深”。但如果沿着信息流动的路径往回追，会发现断掉的是同一条链：
产品里的真实失败，没有变成研究的下一个问题。
Research 不知道产品在哪里卡住——那条银行反馈永远停在 PM 表格里，没有流向研究员的问题清单。Dev 不知道卡住的地方其实有解——季节性现金流的行业分布是可以被系统建模的，只是需要研究侧的能力才能触碰到这个问题。
这不是能力问题。研究员有能力处理这个问题，工程师也有能力实现解决方案。问题是，两者之间缺少一条让知识双向流动的通道。
那么，什么样的团队结构，能让这条通道真正存在？
联动的本质——知识飞轮而非流水线
回到那个失败时刻。同一条银行反馈，同一批被误判的小微企业主，但这次换一种团队结构。
结构不同，命运不同。
飞轮转一圈
反馈进来的第三天，研究员看到了它。
不是因为有人特意转达，而是因为这个团队有一套固定机制：所有被标记为”高优先级”的产品 badcase，会在 72 小时内同步到研究侧的问题看板，附上原始数据和客户描述，不做任何过滤和摘要。研究员可以直接认领，也可以标注”暂不处理”并说明原因。
一位做风险建模的研究员认领了这个问题。
她拿到数据之后，第一步不是跑模型，而是看分布。把那批被误判客户的月度现金流数据画出来，模式立刻出现了：餐饮、零售、农资——这三个行业的客户，全都呈现出高度一致的季节性波动曲线，旺季流入是淡季的三到五倍。系统用来判断偿债能力的核心特征，是近三个月的平均现金流，恰好截取在淡季，所以一律报警。
这不是噪声，这是一个有规律的系统性偏差。她提出了一个可检验的假设：如果在特征体系里引入行业基准对齐，用同行业同规模的客群中位数做相对化处理，误判率应该会显著下降。
假设提出之后，她没有等实验跑完再告诉工程师。实验进行到第三天，她把一个未完成的中间结论发给了工程师：行业对齐在餐饮类客户上效果非常明显，但在农资类客户上改善有限——原因未知，可能是农资客户的季节性更复杂，也可能是样本量不够。
工程师拿到这个结论，当天就把餐饮类的行业对齐逻辑部署进了测试环境，针对新进来的同类申请做 A/B 分流。
两周后，测试结论回来了：餐饮类误判率下降了 41%，但有一个意外发现——系统在处理”餐饮+电商双渠道”的客户时，行业对齐反而让结论变差了，因为这类客户的收入结构本身就是混合的，单一行业基准无法对齐。
这个发现改变了研究员对问题的分类方式。她意识到，问题的核心不是”季节性”，而是”收入结构的同质性”——季节性只是其中一种表现形式，多渠道混合收入是另一种，还有更多种类等待被识别。
飞轮完成了一圈。下一圈，从”收入结构分类”这个新问题出发。
飞轮为什么经常卡死
上面那个故事，现实中并不常见。它之所以能转起来，依赖三个条件同时成立——而这三个条件，在大多数团队里，至少有一个是缺失的。
第一，信息没有流动的物理通道。 badcase 停在 PM 的表格里，研究员永远看不到真实失败样本。这不是态度问题，而是机制问题。产品侧和研究侧的信息系统往往是两套独立的工具链：Jira 上的 bug ticket、飞书里的用户反馈文档、研究员的 Notion 实验记录——这三者之间没有任何自动的连接。信息要流动，需要有人手动搬运，而手动搬运这件事，在没有明确归属的情况下，总是会被优先级更高的事情挤掉。
第二，时间粒度不匹配。 产品侧的节奏是两周一个 sprint，有明确的交付节点和验收标准。研究侧的探索周期是以月为单位，一个假设从提出到验证，快则三周，慢则三个月。两条时间轴永远错位：当研究员终于有了可用的中间结论，工程师那边早已进入了下一个 sprint，手头的优先级已经排满。结论等不来窗口，窗口等不来结论，飞轮卡在两个齿轮之间。
第三，语言不互通。 研究员说”行业对齐之后 AUC 提升了 0.04”，工程师问”那误判率能降多少”，产品经理问”这个客群的通过率会变化吗”，风控负责人问”监管口径上怎么解释这个调整”。同一个实验结论，在四个角色眼里需要被翻译成四种语言。翻译的成本被低估了——它不只是措辞的问题，而是思维框架的问题。研究员习惯于在模型层面描述改进，产品团队习惯于在用户行为层面衡量价值，两者之间没有共同的度量衡，沟通就只能停留在表面。
联动是什么
联动不是让研究员参加产品周会，也不是让工程师抽空读论文。
联动是一套让知识双向流动的基础设施：产品里的每一次真实失败，都有可能在 72 小时内出现在研究员的问题看板上；研究里的每一个可用的中间结论，都有可能在两周内进入产品的测试环境——不需要等论文发表，不需要等完整方案。
它需要的不是更多沟通，而是三样东西：让失败样本自动流向研究侧的信息机制，让研究中间产物能快速进入产品测试的工程接口，以及一套让两侧都能读懂彼此结论的共同度量体系。
联动需要三个”共同”
飞轮能转起来，靠的不是人的自觉，而是结构的保障。具体来说，是三个层面的对齐——共同语言、共同目标、共同节奏。缺任何一个，飞轮都会在某个环节重新卡死。
共同语言
研究员和工程师之间，有一道隐形的语言边界。越过这道边界，需要双向的努力。
研究员需要理解产品运行的基本约束。P99 延迟意味着什么——如果一个新模型把推理时间从 200ms 拉到 800ms，它在信贷审批场景里几乎不可能上线，因为客户经理等不了；cost-per-token 意味着什么——一个需要调用十次模型才能给出结论的方案，即便准确率更高，在规模化部署时也可能让单笔成本超出业务可接受范围；fallback 逻辑意味着什么——当模型置信度低于阈值，系统会降级到规则引擎，研究员的改进如果只在高置信度样本上生效，实际覆盖率可能远比 benchmark 显示的低。
这些不是工程细节，而是判断一个研究方向是否真的有产品价值的基本坐标。研究员如果不理解这些约束，提出的方案很可能在实验室里漂亮，进了产品就熄火。
反过来，工程师需要能读懂实验结论的基本结构。一份 ablation study 在说什么——哪个组件被移除之后性能下降最多，意味着哪个设计选择是真正有效的；loss curve 在说什么——训练损失和验证损失的走势分叉，意味着模型在过拟合，继续训练没有意义；置信区间在说什么——一个”提升 3%”的结论如果置信区间跨越零点，它在统计上等于没有提升。
不是要求工程师变成研究员。而是要求他们能识别一个结论是否可信，能问出”这个改进在我们的真实数据分布上验证过吗”这样的问题——而不是拿到一个漂亮数字就直接去排期。
共同语言的建立，不靠培训课，靠的是长期在同一个问题上协作。研究员和工程师如果从来不坐在一起看同一份数据，语言边界就永远存在。
共同目标
最容易制造割裂的，是度量体系的分裂。
研究团队用 benchmark 说话：AUC、F1、BLEU、MMLU 分数。这些指标有其价值——它们是跨团队、跨时间可比较的标准化度量，能让研究进展有据可查。但它们和产品里真实发生的事情之间，往往隔着一层不透明的转换关系。AUC 提升 0.03，对应的是哪类客群的误判率下降，下降幅度够不够大到让银行愿意调整审批策略——这个问题，benchmark 本身回答不了。
产品团队用业务指标说话：DAU、转化率、客诉率、续约率。这些指标捕捉的是用户行为的结果，但它们对模型改进极度不敏感——一个误判率下降 10% 的模型改进，在 DAU 曲线上可能完全看不出来，因为影响 DAU 的变量太多，信号被噪声淹没了。产品团队如果只看业务指标，很难判断一个研究方向是否值得投入。
割裂的度量体系会制造一种奇怪的局面：研究员觉得自己一直在进步，产品团队觉得研究一直没有产出，双方都有数据支撑自己的判断，但两套数据描述的根本不是同一件事。
打破这个局面，需要一套对齐的评估体系——不是把 benchmark 废掉，也不是把业务指标废掉，而是在两者之间建立一条可追溯的换算链：这个模型改进对应的是哪个子场景的准确率提升，这个准确率提升对应的是多少客诉减少，这个客诉减少对应的是多少续约率改善。链条不需要每次都走完，但它需要存在，让两侧的人在需要的时候能相互翻译。
更重要的是，研究和产品需要共同认定某些”中间指标”作为双方都认可的短期锚点。在信贷审查场景里，这个中间指标可能是”特定客群的召回率”——它比 AUC 更接近真实业务问题，又比续约率更直接反映模型能力。当研究员说”召回率提升了 8 个点”，产品经理能直接理解这意味着什么，双方的对话才能真正发生在同一个频道里。
共同节奏
时间粒度的错位，是飞轮最常见的卡死位置。
产品侧的 sprint 是两周，有固定的交付节点：功能上线、A/B 测试启动、数据回收、下一轮排期。节奏是刚性的，插入一个”等研究结论”的环节，意味着整条排期链都要推迟，这在大多数产品团队里是不可接受的。
研究侧的探索没有固定节奏。一个假设从提出到验证，取决于数据获取的难度、实验设计的复杂程度、中间遇到的意外发现。给研究设定两周交付期，结果往往是：要么研究员硬凑一个不成熟的结论，要么两周到了什么都没有，工程师只能自己先填坑。
解决这个错位，不是要求研究员按 sprint 交付，而是要重新定义”研究的交付物”是什么。
研究的交付物不必是完整结论，可以是可用的中间结论。”行业对齐在餐饮类客户上有效，置信度足够高，可以进测试环境”——这是一个中间结论，不是最终答案，但它已经足够工程师在一个受控范围内部署和验证。中间结论的颗粒度更小，产出频率更高，能嵌入产品的迭代节奏，而不是横亘在两个 sprint 之间等待。
与此同时，产品侧的 sprint 规划需要为”接收研究中间结论”预留接口。不是每个 sprint 都必须有研究输入，但 sprint 的设计需要有能力在两天内响应一个意外到来的中间结论——快速评估、决定是否部署进测试环境、安排数据回收。如果 sprint 排得密不透风，这个响应能力就不存在，研究结论来了也用不上。
共同节奏的本质，是把研究的探索周期和产品的迭代周期，从两条平行时间轴，变成一套嵌套结构：产品的每个 sprint 是外层节拍，研究的中间结论是可以随时插入这个节拍的内层信号。两者不需要同频，但需要有接口。
重新定义”全栈 AI 团队”
回到最初那个问题：什么是真正的端到端 AI 团队？
不是”什么都有”。不是同时雇了研究员和工程师，就拥有了端到端的能力。腾讯 AI Lab 雇了最好的研究员，Meta FAIR 建了全球顶尖的研究机构——他们都”什么都有”，但研究和产品之间的通道，从来没有真正打通过。
真正的端到端，是让研究和产品互相定义。产品里的失败定义研究的下一个问题，研究的中间结论定义产品的下一个测试。这个循环持续运转，每转一圈，团队对自己所在领域的理解就深一层，竞争对手用相同的基础模型调出来的产品永远追不上这种积累。
在 AI 时代，模型调用能力已经是商品。任何一个团队，花同样的钱，都能调用同样的基础模型。真正拉开差距的，是两件事：你的产品问题能不能变成你的研究优势，你的研究突破能不能第一时间变成你的产品差异。
这两件事，都需要 Research 和 Development 之间有真正流动的知识回路。
共同语言、共同目标、共同节奏——这三样东西建起来的不是一套管理制度，而是一个持续进化的学习系统。系统每运转一圈，积累的不只是模型参数，而是对真实业务问题的深层理解，是竞争对手很难在短时间内复制的认知壁垒。
这才是在 AI 时代真正可持续的竞争优势。不是谁的模型更大，不是谁的工程师更多，而是谁的研究和产品之间，有一条真正跑通了的知识飞轮。