平台建设的7大问题：蚂蚁AI平台实践深度总结

本文作者：蚂蚁集团资深产品专家栢柠，先后负责蚂蚁AI平台、风控平台产品工作。

过去几年，我和团队一直在负责蚂蚁集团内部相关平台产品的设计和运营工作。

这些平台产品包括人工智能部的A/B测试平台、机器学习平台、金融知识图谱平台、NLP平台、智能文案平台、金融视觉(CV)平台、搜索平台、机器人平台、标注平台等，以及风控团队的相关平台产品。这些平台产品，在背后支持了蚂蚁几乎所有核心业务的运行和发展。

整个过程当中，我们在平台建设、业务支持、平台运营、AI创新以及AI整体运营等各个方面做了很多尝试，有了不少的收获和感悟。

最近，我花了一些时间，将其初步梳理出来，写成了这篇文章。

文章的内容涵盖了“需求管理、平台设计、产品验证、平台协同、人性对抗、跨界思维、挑战/成长”等7个方面，既有一些抽象的、方法层面的总结，也有很多真实的、有体感的案例。

篇幅比较长，约1.5万字。感兴趣的话，可以收藏下后面慢慢看。

希望本文对你有所启发，更期待能抛砖引玉，跟大家做深入的探讨和交流。

一 需求管理：“角色错位”与“无我境界”

1 挖掘需求，警惕“角色错位”，杜绝“闭门造车”。

做好产品的第一步，就是把握好需求，必须搞清楚每一个产品和功能的真正用户是谁。

对于C端产品，这个问题比较好解决，因为设计者和使用者往往是重合的。但对于技术平台类产品、B端产品，这两者经常是错位的，即设计者可能并不是真正的用户。

举个例子，支付宝的产品经理在日常生活当中天天用支付宝付款、理财，他就是个典型的支付宝用户，所以设计者与使用者就是同一个人。而在技术平台、B端产品当中，产品的设计者可以用自己的产品，但基本上仅限于做测试、做验证，真正的用户却是其他的人。

因此，设计者对于产品需求的一些推理判断，可能会与真实情况有差别，即使他用了，那个以测试为目的的使用和真实的使用，还是有区别的。

由此可见，正是由于技术平台类产品中这种角色的错位，就容易导致需求把控出问题。

下面，先从我们标注平台的一个小故事开始讲起。

去年12月的一天，我们标注平台的相关同学开会，进行产品设计评审。

其间，针对一个标注页面的产品设计细节问题，在坐的产品经理、UED、前端、后端各个岗位的同学各抒己见、争论得不可开交。

突然间，我意识到一个严重的问题——那就是会议室的所有同学，并不是这个feature的用户。

因为具体的标注工作，都是外包公司的数百个标注人员做的，他们才是标注页面的真正用户。

不是真正的用户、没有处在那个场景，就很难了解真实的情况。于是，大家就只能根据自己的经验和专业能力，进行判断和推演。

做产品不能闭门造车。于是，我们就随即安排相关同学去了标注外包公司做现场调研。

一开始，我们与几个标注团队的小组长进行小范围的初步沟通。当时，随口问了下产品使用情况，他们一致反馈“没什么问题，挺好用的”。

这样的回答很正常，毕竟这么简单、直接的问法，是很难获取到有价值的信息、了解到用户的需求。

在产品经理的行业，我们经常说的一句话是，在汽车被发明之前，如果你直接问用户要什么，他只能说“我要一匹更快的马”。
钉钉原负责人无招同学来蚂蚁做“钉钉创业之路”的分享时，也谈到这个问题。
他的观点是，见到用户不能只是“就事论事”，只问产品使用相关的浅层次的问题。（即使问这样的问题，也不能问“你有什么需求”之类很难获得真实需求的直白的问题）。
正确的方式是，先把具体的产品抛下，多了解客户的背景、业务、状态等整体的、背景的、来龙去脉的信息，要表现出对客户“感兴趣”，要想成为客户的朋友。
只有这样，客户才愿意跟你多聊、深聊，只有这样，你才能捕获到有价值的信息。再加上，观察客户的具体行为和操作，就能捕捉到真实的需求，才能做到有所洞察。

于是，结束会议后，我们要求上楼到标注员工的办公区，具体看看情况。

当我们站在标注人员身后，仔细观察他们的操作、与他们深入交谈后，就有了新的发现。

很多原来没有想象到的使用方法和场景、产品设计的细节问题，在标注人员的不断操作中，就显现出来了。之前产品评审会上大家争论的问题，自然就有了答案。

半天下来，我们总共记录下数十个有价值的反馈和发现，并在后续工作中，一一做了处理和跟进。

可见，如果你不是真正的用户，你没有亲眼观察真正用户的操作，很多问题你是无法预料到的。

大家IQ都不差，遇到问题，我们往往习惯于谈方法、讲逻辑，经常在会议室里面唇枪舌战甚至拍桌子瞪眼睛，最后谁也说服不了谁，得不到有效的结论。

在这时，不妨先问下自己“真正的用户是谁？”，再试试“笨办法”，走出办公室，走到客户那里，去问问他们、跟他们聊聊天，看看他们怎么用我们的产品。

那时候，很多问题便豁然开朗了。

2 满足需求，不断“由浅入深”，修炼“无我境界”。

接着，让我们的思考再深入一些。

现在，假设你已经明确了用户是谁、摸到了需求的大概脉络，那也要考量“对需求理解是否深入”的问题，即浅层需求和深层需求的问题。

换句话，也是手段和目的的问题——“浅层需求”往往只是手段，而“深层需求”才是目的。

举个例子，对于我们负责的金融视觉平台，有用户反馈“我需要模型报告”，即模型训练出来后，将一些“准确率、召回率、AUC之类”的指标，用图表的方式展示出来。

如果你只是将这个需求做了，那是不够的。

为什么呢？因为用户要的模型报告，只是“浅层需求”——他的确需要看各种指标，但他最想要的是，在新模型训练出来后，他要对不同版本的模型效果进行对比——不仅要知道指标是多少，更想知道指标的具体变化，哪些升了、哪些降了以及具体数值是多少。

只有这样，才算是满足了深层需求。

道理是相通的，类似问题在C端产品中也会碰到。

如果你留意的话，你会发现很多电商网站、汽车导购产品的产品经理已经摸到了深层需求。

比如，汽车网站里面基本都有一个“车型对比”功能：不仅能将不同车型的各项配置、参数，用表格逐项列出来，而且还提供了“高亮不同配置、隐藏相同配置”等贴心功能。这就是深层次地满足了用户的需求。

因此，对于一个需求，多问几个为什么，多问自己“这是用户的真实目的吗？他用这个功能到底想干什么”等。只有这样，才有可能触及到用户深层次的需求，才有可能做出让用户感到很贴心的功能。

对于深入满足用户需求，除了做浅层、深层的分析之外，还可以采用“分而治之”的思路，将产品从模块和功能上分层，即分出“N级火箭”，每一级“火箭”用来满足不同类型的用户需求，或者同一用户在不同阶段的需求。

举个例子，尽管我们的图谱、NLP、CV、搜索、机器人、标注等几个平台产品的功能各不相同，但我们还是找到了共性，即抽象出了需求分级和业务赋能的“五级火箭”，包括“功能嵌入、API调用、数据训练、模型定制、算法开发”等五级。业务方可以根据具体情况，来选择不同的接入方式。

• 第一级，功能嵌入：通过iframe等实现成本最低的手段，将平台的某个功能模块嵌入到自己的系统当中。
• 第二级，API调用：直接调用平台提供的成熟API，比如调用身份证、驾驶证之类的OCR识别的API。
• 第三级，数据训练：平台的模型符合需求，但需要提供自己的训练数据或者字典数据等，来解决具体场景需求。
• 第四级，模型定制：平台的现场模型不太符合要求，所以要对算法参数进行配置，然后训练出符合自己