边界就一句话:PM 定义问题,算法定义方案
我见过协作最顺的团队,分工都非常干净:PM 负责把业务问题翻译成算法问题,并且给出可验证的验收标准;算法工程师负责选模型、调参、做实验。PM 不该碰的是方案层——"你用 BERT 还是用 GPT"、"要不要上 RAG",这不是 PM 该拍的板,你拍了也没人为结果负责。反过来,算法也不该替 PM 决定"这个需求不重要"。两边越界,项目一定吵架。
拿一个真实场景说:业务方说"客服机器人答得太烂了"。差的 PM 会把这句话原样转给算法;合格的 PM 会先自己拆——抽 200 条真实对话让人工标注,发现 60% 的差评集中在"退换货政策"这一个意图上,其中又有一半是知识库文档过期。于是需求变成:"退换货意图的答复正确率从现在的 65% 提到 90%,先更新知识库,再看要不要换检索方案"。算法拿到这种东西,是愿意跟你干的。
提需求用"数据 + 场景",别用形容词
AI 团队里最有效的沟通货币是 badcase。你说"模型不准",工程师没法接;你说"这 50 条 case 全错了,其中 30 条是用户用口语缩写提问,期望输出是这个,实际输出是那个",工程师眼睛会亮。我自己的习惯是维护一个 badcase 表格,字段就四列:输入、期望输出、实际输出、错误类型。每周和算法过一遍,错误类型的分布本身就是排期依据——哪类错误占大头,下个迭代就攻哪类。
验收标准也一样,要提前量化。在项目启动时就把评测集和通过线写清楚:比如"在 500 条标注好的测试集上,意图识别准确率 ≥ 92%,拒识率 ≤ 5%"。这句话写出来,后面 90% 的扯皮都不会发生。最怕的是验收时大家才发现,PM 心里的"好"和算法心里的"好"根本不是一回事。
尊重实验节奏,别拿功能开发那套催进度
功能开发的进度是线性的,十个页面做掉七个就是 70%。算法工作是阶跃的:可能两周没进展,某个实验突然通了,指标一夜涨 15 个点。所以"这周进展如何"这种问题,对算法团队要换个问法:"这周跑了几组实验?排除了哪些假设?下一步的假设是什么?"实验数和假设收敛速度,才是算法项目的真实进度条。
催进度当然也有用,但要催对地方。数据清洗慢、评测集没建、GPU 资源排队,这些是工程问题,可以催、该催。模型效果不达标就去催工程师"加加班",没用,还会把人逼去调测试集——指标是好看了,上线就翻车。
最常见的三个坑
第一个坑:PM 不碰数据。你不需要会写训练代码,但必须会看数据分布、会抽 case 标注、会算准确率和召回率,否则你和算法之间永远隔着一层翻译。第二个坑:把算法的乐观估计当承诺。工程师说"理论上可行"的意思是三成把握,写进项目计划前自己心里打个折。第三个坑:只找算法聊,不找工程聊。模型效果好不等于能上线,推理延迟、并发、成本这些是工程侧的问题,很多项目死在"demo 惊艳、上线瘫痪"。