去年双十一前一家华东区域的零售客户上线了客服 Agent。演示时问答流畅知识库检索也跑得通业务方当时挺满意。可试运行接入部分真实渠道后问题陆续冒头用户咨询高峰期系统扛不住并发业务方想调整一句对话逻辑发现改起来牵一发而动全身。企业提了一轮又一轮修改需求供应商也配合调整但每次改完都是隔靴搔痒——核心问题始终没解决。折腾了大半年系统还是接不进核心业务流程最后不了了之。这种项目我见过不少。复盘时很多人把锅甩给方案选错了或需求没对齐但根子往往在团队能力结构上。供应商演示做得漂亮不代表交付团队真有把 AI 能力嵌进业务的工程素养和项目管控力。但 demo 能跑不代表交付能落地。演示是供应商在理想条件下搭出来的接手你真实业务时的表现才是真考验。作为技术管理者我的习惯是先看人再看方案。下面三个维度是我这些年筛团队的真实标准。一、团队的能力分层是否清晰AI 人才天然分层。能做 demo 的人不一定扛得住生产环境能写业务代码的人不一定懂场景。跟供应商谈合作我会直接问你们派过来的人大部分是什么水平如果对方含糊其辞或者只强调我们技术很强却不谈具体分工我就要警惕了。一个靠谱的交付团队应该能清楚告诉你谁做业务分析、谁做模型调优、谁做系统集成、谁对最终结果负责。我最怕的是碰到那种全栈型人设——一个人号称从需求分析到上线运维全包。这种人也许有但凤毛麟角。多数情况下这意味着团队没有成熟的分工体系出事了我都找不到该钉谁。二、有没有人才培养和梯队AI 项目周期通常不短中途换人对甲方是灾难。所以我会专门盯供应商有没有自己的人才培养机制。我一般会直接甩三个问题过去核心人员要是离职有没有替补、多久能补上团队内部有没有知识沉淀还是全压在个别关键人身上新人进来有没有系统的培训路径能把这些说清楚的基本差不了要是只回一句我们核心人员很稳定或者这个你放心那基本等于没有。真正做过大规模交付的团队会主动跟你聊人员备份、知识转移和梯队建设——因为这些坑他们自己早踩过。三、交付过程透明吗很多项目后期扯皮不是目标没对齐是过程不透明。甲方不知道进展到哪等发现问题已经积重难返。我通常会在合同里咬死几条定期同步机制不能只报喜不报忧风险和阻塞点必须摊开关键里程碑要有能演示的交付物而不是永远还在开发中质量要有量化指标比如交付达标率、问题响应时效别拿感觉还不错糊弄。过程透明最大的好处是问题早发现早解决。前面那家零售客户如果试运行阶段就能识别出来——改来改去改不好的本质是团队能力断层而不是需求没想清楚——也许能少走几个月弯路。最后企业做 AI 转型选团队比选技术路线更关键。技术路线能调团队能力一旦选错沉没成本太大。签合同前把上面这些维度的问题抛给候选团队让他们逐条接招。能接住的交付质量通常不会太差接不住的建议再想想。