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

简介：在支持蚂蚁几乎所有核心业务运行和发展的过程中，我们在平台建设、业务支持、平台运营、AI创新以及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。
• 第三级，数据训练：平台的模型符合需求，但需要提供自己的训练数据或者字典数据等，来解决具体场景需求。
• 第四级，模型定制：平台的现场模型不太符合要求，所以要对算法参数进行配置，然后训练出符合自己需求的新模型。
• 第五级，算法开发：最高级的情况，就是业务方懂算法、要开发新算法。平台则提供“算法开发、数据管理、模型训练、模型测试和发布”等一系列深层次的能力，来提升算法研发的效率。

上述“五级火箭”，由浅入深地满足了不同类型用户，以及同一个用户不同阶段的需求。

记得多年前，我参加了一个管理方面的高级培训班。培训有好几天，内容很多，不过几乎所有的培训内容我都忘记了——除了一位老师无意中介绍的一个“万能四步法”。
所谓四步法，就是“分类-排序-找规律-应用”这四个步骤。无论在学习新的领域知识、接手新的工作，还是来到新的环境时，都可以尝试这个万能四步法，相信再复杂的问题都能迎刃而解。
用户分层、五级火箭，就是“分类-排序”的一个应用。

谈完“需求/用户分层、五级火箭”了，那是否就是对用户需求360度、无死角地满足了呢？

答案是否定的，因为我们还没有做到“无我境界” 。

所谓“无我”的境界，就是满足用户需求的时候，不能只考虑“我是谁、我有什么”，而要忘掉自己，去看用户需要什么，什么东西对用户最有用。

比如，虽然你是做AI技术平台产品经理，但你眼里不能只有AI、算法、模型——要做到“无我”，就是要做到：如果有一种非算法、非AI的产品策略，若能切实帮到业务，那也应该去做。

在业务同学的眼里，有没有算法没关系，是不是高科技不重要——而有没有业务效果才关键。正所谓，不管白猫黑猫，抓到老鼠才是好猫。

比如，我们的智能文案平台，能够智能生成千人千面的营销文案。过去，一直在迭代产品、提升算法能力，力图生成更加智能、精准和个性化的文案。

然而，大家知道，算法的提升不可能一蹴而就，算法效果都是慢慢地打磨和优化的。

在这个过程中，产品经理同学不能干等。

于是，我们就在思考，不管多么高深的算法、多么智能的平台，我们生产的仍然是文案。而文案这个岗位，随着广告行业的发展已经存在了数百年，那么，一定有成熟的方法论和模式。

作为互联网从业者，我们崇尚创新和颠覆，但我们还必须对行业保留敬畏之心。

于是，我们的产品经理同学就去把一些市场营销、广告文案经典书籍研读了一番，总结出了所谓“18种优质文案句式/模板”，这里面既有文案从业者的经验总结，也有广告学、心理学等领域的科学原理。

将这些“优质句式”、“文案法则”产品化之后，配合算法和技术，就能给业务输出更有效果的文案。

我们相信，机器不能完全代替人，机器智能和行业知识、专家经验等人类智慧，一定会相得益彰、交相辉映。

二 平台设计：平台产品，也必须“秒懂”

讲完需求，再来说说设计。

在互联网行业，面向C端用户的产品不仅供给充裕、极大丰富，而且普遍都免费，获取成本基本为0。

没有付出，就不会“珍惜”。

所以，对用户来说，产品必须容易上手，即必须“秒懂”。如果用户几分钟甚至几十秒看不懂、不会用，那他基本就放弃了，产品就没有机会了。

对于中台、平台产品来说，其实也是这样的，只不过用户遇到不爽的体验只能忍忍，因为使用你的产品来解决他的业务需求，这是他的本质工作。

但是，这并不意味着产品随便搞搞就行，因为他还可以有别的选择。你要知道，公司内部往往也有类似的产品，更不用谈外部的、免费开源或者收费的解决方案了。

所以，你在平台设计上，也要下功夫，必须能快速抓住用户，让用户迅速上手、接入、上线，帮助业务拿到业务结果。

如何才能做到“秒懂”呢？可以从“产品框架、术语体系、帮助指引、产品demo、统一交互”等几个方面来考虑。

1 有清晰明了的产品框架

用户一打开平台的页面，就应该清晰地感知到平台能做什么，产品框架是什么样的，包含什么功能模块，模块之间的关系（包含、先后等），第一步做什么、第二步做什么，等等。

这一点看起来没什么深奥的，但常见的问题是，产品经理在产品设计前期，对框架的思考不够充分。经常是到了PRD、视觉评审阶段，才发现模块设计不合理、流程不清晰等等。这时，再返工、改动，成本就大了。

更为糟糕的是，频繁的返工和变更，会让产品经理个人的专业性和权威性丧失殆尽。以后，还怎么向技术提需求、磨资源？

为了避免这样悲惨的事情发生，产品经理要在台下多下功夫。

一个好的习惯，是先在脑中重建，再动笔绘制。很多产品经理习惯一上来就画demo，这是不对的——大脑的认知和计算资源是有限的，顾“此”就会失“彼”，当你陷入种种细节后，就不可能从根本上、框架上思考问题了。

那怎么办呢？可以用充分使用脑图这种工具。具体来说，你先不要考虑任何demo图，而是先把整个平台产品层级结构全部理出来，包括各级导航和模块、每个模块包含的页面及核心功能板块。画好脑图之后，站在用户的角度，反复梳理和模拟，直到横向、纵向的逻辑和流程都没有问题了，再动手做具体的demo、PRD。

2 有顾名思义的术语体系

产品的整体框架梳理清楚之后，还要重视“术语/概念体系”，即产品中的核心概念命名以及概念之间逻辑关系的设计。

这个之所以重要，那是因为，概念和术语体系是每一个领域知识沉淀的结果，也是人们学习新事物、进行沟通交流的介质。

概念复杂，产品必然复杂；概念简单，产品才能简单。

比如，同样是人机交互的指令和方式，微信的“摇一摇”就能让用户“顾名思义”，并立马有体感地照做，而我们支付宝的“咻一咻”，就比较难理解和付诸行动了。

又如，当年乔布斯发布iPod的时候，并没有直接抽象地说“存储空间高达4.8G”，而是说“把1000首歌装进口袋”。

可见，产品中的新概念命名不合理，或者将晦涩难懂的底层术语直接暴露出来，都会对用户造成很大的困扰。

再比如，在A/B实验平台中，最初的概念体系自顶而下分别是“业务域-业务线-产品-实验”。

我们发现，用户很难分清“业务域”与“业务线”的区别，里面的“产品”也不是大家所理解的“支付、借呗、花呗、余额宝”这样的产品，所以存在很多困扰。

后来，我们借助大家熟知的“物理实验室、化学实验室”这些事物，将概念体系改造成这样：达尔文是一个“实验平台”，里面可以创建“xxxx实验室”“yyyy实验室”，在每一个实验室当中，可以做各种各样的“实验”。这样，就好理解多了。

除此之外，我们还对实验室中的角色命名进行了修改。

之前实验权限管理里面，有“管理员”、“成员”这两种常见的角色设置，我们同样参照现实生活中实验室工作人员的岗位名称，将其改成了“实验室主任”和“研究员”。

有趣的是，“研究员”在阿里体系有“高P/组织部”的层级含义，这样小小的一个文案的修改，也包含着平台设计者的“人文关怀”——对那些用A/B实验来践行数据驱动创新的、追求科学严谨做事方式的同学们，给予一点点温情和荣耀。

而且，日后的运营活动也好做了，比如可以评比“十大研究员、十佳实验室”等等。

总之，在设计产品的术语体系，首先是“如无必要，勿增实体”，其次，要尽量借助大家脑海中已有的概念，而不是直接照搬技术实现，或者生造新的概念。

3 有恰到好处的帮助指引

即使你在概念设计上下了功夫，也不能保证用户不会产生任何疑问。

因此，就需要设计“帮助体系”，做进一步的解释和阐述。

这里，并不是说让你写一份冗长的产品文档。文档应该写，但它不是重点，因为大部分人并不会仔细把产品文档读完才动手操作——他只有遇到问题，才有可能去查查手册。

这里说的“帮助体系”，指的是产品化的帮助体系，即 “文档产品化”。具体来说，就是把帮助文档中的要点尽量嵌入到产品页面当中，让产品实现“自解释”，而不是放到产品体外、仅仅存到帮助文档中。

“文档产品化”，具体的措施包括如下几个方面：

页面上有辅助说明

常见的情况，是我们的页面太干净、太空了，舍不得放一句解释的话，当用户遇到问题，就不知所措了。所以，可以在标题下面做小字解释、在概念上面出tip气泡提示。对于复杂的情况，在帮助文字后面还可以加上“了解更多”链接——直接跳转到帮助文档的相应地方，而不是要用户从头查找。

新功能上线，有提示和告知

平台不断做迭代改进，但经常发现用户并不知道上了新功能。所以，可以对此做适度的提示和告知：大迭代可以蒙层弹窗、小的改动可以出小红点，等等。

4 有简单直观的全流程demo

只看教学视频学不会游泳，光学“科目一”是学不会开车的。

天花乱坠说半天，不如动手玩一遍。

现状是，很多技术平台完全没有demo和体验能力。那么，用户就很难上手。

因此，平台一定要搭建一套“全流程、有体感、简便易行”的demo，让用户亲手体验一下。

全流程，指的是你的demo要涵盖平台的全部环节和步骤。有体感，指的是要有直观的结果（而不是只显示抽象的数值、json代码输出之类）。简便易行，指的是要足够简单、几分钟就能完成（因此你需要内置几组demo的语料、图谱、数据集等等）。

举个例子，在NLP平台和金融视觉平台当中，用户可以很便捷地在线体验金融NER/文本分类、身份证/银行卡OCR的效果。

也可以全流程地完成“项目创建、数据上传、数据打标、模型训练、模型测试”等环节。

值得指出的是，对于平台的demo，一定要越简单越好，千万不要高估了人的耐心。

记得在金融视觉平台第一版全流程demo上线后，当项目组成员在具体体验时，才发现还是很繁琐，甚至要放弃。

要完成demo，你仍然需要写一堆表单，比如项目名称/简介、模型名称/简介、数据集名称/简介，而且，还要自己准备训练数据，不得不去网上搜索、下载几十/上百张图片……

后来，我们就对此做了大幅度的简化，能点鼠标的就不要让用户输字，比如自动填充各种名称和简介。此外，平台还内置一些测试数据集供用户使用等等。

经过一番简化之后，用户才能在几分钟之内，完成全流程、非常有体感的demo了。

5 有标准/统一的交互体验

在做好每一个平台的设计之外，还需要考虑不同平台的体验一致性，即平台的统一。

做好这件事情，既能让用户降低学习成本、在不同平台之间平滑切换，也能减少UED、产品经理、技术同学们的重复劳动。

首先，可以将平台通用的框架和模块，抽象出来、统一起来，包括Portal页、项目管理、权限管理、数据管理、任务管理、发布管理等等。

其次，将细节的体验也统一一下，具体到组件的设计、命名、颜色、位置等等。

当我们沉淀出一套经典的产品框架和交互标准，那产品迭代速度和用户体验，都会大幅提升。

三 产品验证：用不“深”，就做不好

1 要深度验证，而不是蜻蜓点水

产品经理要真正做好一个产品，必须要自己多用。

这个道理很简单，但这里要谈的是使用的“深度”——随便点点、看看，跟深度使用的差别是很大的。

举个例子，如果让你设计导航产品中的路口转弯提示语，你可能觉得设计成类似“前方500米路口右转”这样就没问题了。

你看，既包含距离，又说清了方向，感觉已经很完美了吧。然而，当你深入使用产品时、当你自己驾车的时候，才会发现情况并非如此——你很难精确地把握是否到了500米处，很可能在300米处的一个路口就错误地提前右转了。

所以，现在的导航提示不仅会说“前方500米第N个路口右转”，并且会在不该右转的路口提示“正在经过第N-1个路口”，只有做到这样精细，才能保证用户不会走错路。

对于我们的标注平台来说，深度使用体现在做数据标注的次数——标注几次与几十、几百次，你的感知是完全不同的。

标注页面中的一些设计的细节问题，在你做一两次标注的时候感觉不明显，当你做上几十次、上百次之后，再小的问题也都会暴露出来、被放大了。

比如，有一种图像分类任务，你只需要标注“对”还是“错”。

之前的设计，是每页展示一张大图，答完题后就切换到下一页。当我们自己亲自标注了几十张之后，就感觉这样的效率很低。

于是，我们就改成了一页展示一二十张图片，标注人员只需要扫一眼，把其中“对”或者“错”的勾选出来，然后整体提交就好了（同时也减少了每一页刷新页面、加载图片的等待时间）。这样简单的一个改动，其实并没有什么技术难度，但标注效率直接提升了好多倍。

2 自己“做业务”，结果大不同

真正要把一个平台做好，不仅要像上面说的，自己多当“标注员”，更应该做做 “业务方”。支持业务、赋能业务，跟自己做业务，还是有很大差别的。

下面，用我们做的垃圾智能分类的项目“分类宝”这个案例来说明下。

在2019年7月份，全国很多城市开始推行垃圾分类。

我们的同学基于沉淀的图像、NLP和图谱等AI技术能力，迅速开发出了智能垃圾分类的技术和产品，项目命名为“分类宝”。用户可以通过“拍照片、语音搜索”等便捷的交互方式，在支付宝小程序以及智能垃圾回收箱IoT设备上，来体验AI垃圾分类了。

这个项目，并不是各个业务BU给我们提需求而开始做的。这一次，我们有了双重身份，我们自己既是平台方，也第一次做了“业务方”。

做起业务方之后，我们才发现，垃圾分类这个事情看似简单，实际上却包含很多复杂的环节，从“训练数据的获取、物品类目的整理、垃圾分类标准的维护、线上回流数据的订正”，到“物品类目权重和优先级的调整、标注结果的确认”，再到与内部各个部门的协同、与外包ISV的对接、节假日与特殊物品的应对，等等。

经过一番手忙脚乱的折腾，总算是把项目磕磕绊绊地做了起来。

在这个过程中，我们遇到了很多之前不知道的问题，其中既有平台设计不合理的产品问题，也有训练时间过长之类的技术问题。

更重要的是，让我们看到了不同流程、不同系统以及不同团队之间衔接的“真空地带”——这正是大公司由于分工、边界带来的，常说的“三不管、踢皮球”的问题。而这些衔接上的问题，正是隐蔽的、极大影响效率的问题，需要被发现，通过产品和流程等机制进行解决。

“自己做业务”的这一次实践，让我们平台同学换了一个视角，深刻体会到了业务同学的不易，也直接推动了平台的迭代改进，以及团队配合、流程设置的完善。

四 平台协同：连接，产生价值

前面讲了很多，但大部分还是聚焦在某一个平台的个体上。

孤立存在的平台，就可能会降级成一个工具，其价值和能量就变得非常有限。

因此，要做好、做大平台，需要跳出平台本身，以连接、全局、生态的思维来看。

如果让不同平台产生协同和连接，会产生“1+1>2”的效果。如果把封闭在平台内的“控制流、数据流”延伸出去，变成闭环，就会迸发出很多创新。

下面，介绍几个方法和案例。

交叉链接，带曝光带流量

这是最简单的一种平台协同的方法。每一个平台不仅要完成自己的使命，还应该考虑为兄弟平台做点什么，比如带带曝光、带带流量什么的。所以，我们在每个平台产品的导航栏都增加一个“AI产品矩阵”的菜单，把七八个产品的logo、名称、链接都列了上去。数据表明，这个小小的菜单，每天都能为其他平台带来可观的曝光和转化，做这个菜单的ROI非常高。

平台能力复用，杜绝浪费

平台在不断迭代升级的过程中，对于一个新需求，不要一上来就自己做，而要先看看其他平台有没有可以复用的现成的能力，哪怕是“曲线救国”或者“权宜之计”。

比如，知识图谱平台的知识更新和智能文案平台的文案发布，都需要走打标和确认流程，我们发现标注平台的标注能力就够用了。所以，我们就没有重新开发，而是在平台之间打通连接，快速解决了这个问题。

反哺和闭环，实现共同发展

如果一个平台只是单向的输出能力，而没有从下游获得反哺，没有形成闭环，那也不是个完善的系统和平台。

举个例子，我们的标注平台已经累计对上亿条数据进行了打标，这些标注数据使得各类模型的训练变成了可能。正所谓，没有人工，就没有智能。

在这个过程中，标注平台只是输出价值、为智能化助力，自己并没有从智能化中获益。

后来，我们就考虑把这个链条形成闭环，即让打标数据训练出的模型反哺回标注平台，从而实现“智能辅助标注”。

这样，将整个平台从“纯人工标注”，转变为了“智能辅助标注”，大大提升了标注效率、降低了标注成本。

沉淀数据资产，创造更大的价值

如果一个平台有数据的沉淀，那么这些数据就需要深度挖掘，从而产生更多、更大的价值。

比如，每个业务最开始接入知识图谱平台，为了解决自己的业务问题，就得从头建Schema、导数据。但随着平台的发展，沉淀的知识越来越丰富。那么，后续的平台就能直接受益于之前沉淀的知识，而不一定要自己重新建设了。这就是，平台数据沉淀出的价值。

再比如，标注平台里的标注数据，在完成模型训练之后，生命周期就终结了，躺在那里没有人管了，这是很可惜的。

现在我们计划将这些数据沉淀下来、开放出去，让数据产生更大的价值。

首先，标注数据对内开放。在业务刚接入AI平台，存在一个冷启动的阶段，最缺的是打标的数据。所以，可以将标注平台中海量标注数据梳理和开放出来，让业务可以先到平台里面搜索下，看看有没有已有的数据，有的话，就可以复用。如果没有，再考虑重新建数据。

其次，标注数据对外开放。我们可以把一些不涉及隐私、不牵扯我们核心技术能力的部分数据开放出去，为社会创造更大的价值。

比如，在智能垃圾分类“分类宝”项目中，沉淀了数十万打标的垃圾图像数据。在我们开放了相关模型API之外，再把其中一部分数据开放出去，就会对整个社会的垃圾智能化处理，贡献蚂蚁的一份力量。

接入开放平台，实现强强联合

这里，再说说开放的具体做法。如果自己直接对外开放，做起来就比较麻烦，有很多对接和维护的事情。应该考虑将自己的能力接入到现成的、大的平台，比如支付宝小程序平台/开放平台、阿里云平台等等。借助这些大的平台，很多获客、对接、运维的事情，就有兜底了。

这里，再分享一个考虑平台协同创新的思路，那就是“图解法和穷举法”。

一开始，平台协同创新都是散点发生的，想到一个就做一个，很不系统和体系化。
后来，为了把所有“连接”和“协同”的可能性都穷尽，我们就画了一张系统协同大图和矩阵图，把所有的平台都放进去，全方位地思考平台之间有什么没有打通的，有什么协同创新的可能性。

这个方法，大家在做其他工作时也可以参考。

五 平台中的人性对抗

大家常说，有人的地方就有江湖。一个平台，也是一个江湖。

不同角色、诉求的人参与其中，人性就展示出来了。

因此，就需要思考人的事情，就需要对平台进行运营和治理。

1 平台的误用

首先，要纠正平台上出现的不正确的用法。

为什么会存在这种情况呢？

原因在于，尽管产品经理在产品设计的时候，本身就会尽力杜绝大部分错误的发生，在平台的玩法中也有相应的规则告知到用户，但大家并不会像你想象的那样“守规矩”，他们会有意无意地“妙用”、“错用”甚至“滥用”。

比如，在我去年负责A/B实验平台的时候，我们曾经对平台中所有实验进行深入分析，结果就发现了很多惊人的现象。

• 数百个实验只有一个版本：正常来说，需要两个或者更多的版本来进行对照实验，但很多实验竟然只有一个版本，其中一个很大的“妙用”或者“误用”，是用户仅仅把平台当作灰度平台来使用了。
• 数百个实验内流量为0：有的用户并没有使用平台的分流能力，而是自己做分流，这也是我们没有料想到的。
• 数百个实验运行时间小于3天或者大于30天：正常来讲，实验需要运行一周左右。但很多同学将实验运行一两天，一看到数据有变化就把实验推全或者下线了，这其实是不科学的。有的实验运行了好几十天，原因竟然是有人忘记处理了，可能实验场景都不存在了。
• ……

可见，大家对A/B实验的了解还是很不够的，导致在平台上出现了各种“奇特”的用法。那么，需要在平台培训和产品设计等方面，做更多的工作。

除了A/B实验这样的平台，在我们的金融知识图谱等平台上，也发现很多问题。

我们知道，在知识图谱的Schema规范当中，同样一种实体只能有一种类型。

比如，对于“公司”这个金融领域最常见的实体类型来说，全局定义一个名为“Company”之类的类型就可以了。不同的业务域，可以有不同的业务场景，但类型应该共享一个。

然而，现实情况是，业务同学为了简单、好把控，往往都想自己创建一个类型。于是，在平台上就出现了类似Company1、Company2这样重复的类型。

在图谱平台上，除了Schema重复，数据也存在重复、不一致的情况，这些都需要一个一个进行治理。

然而，平台治理这件事，既是科学也是艺术——既不能放任自由，也不能卡的太严。尤其是在平台建设的初期，如果限制得太死，业务方是很难理解和配合的，甚至会丢掉客户。

所以，要把握好力度。

2 “滥用”与“违规”

上面提到的这些平台治理的问题，其实还不算太糟糕。

接下来，给大家介绍一些需要高度重视和严肃处理的“滥用、违规”的行为。

分别是标注平台中的两个真实案例：“任务释放”和“串通磨洋工”。

先说第一个，“任务释放”功能的滥用。

考虑到外包标注人员变更比较多，所以产品经理在标注页面上设计了一个“任务释放”的按钮，用于防止任务卡在一个人手中。

然而，后来标注小组长们反馈“希望取消这个按钮”，说这个按钮被不少标注人员用来“挑活”：当遇到难度较大的标注题目，他们就点击“任务释放”给跳过了。

于是，我们就把这个功能从一线的标注人员那里收回，只给小组长开放了（这个问题也是去外包公司实地调研时发现的，之前团队同学们都没有料想到）。

第二个是违规行为，说的是人员串通起来“磨洋工”。

有一段时间，算法同学反馈标注速度下降了。我们分析了下报表，发现个别小组的多个标注人员的标注速度都降低了，包括之前做的比较快的人员。

经过调查发现，原来是有个别害群之马不光自己偷懒，还教唆、串通其他人，一起降低标注速度，来集体“磨洋工”。

当然，“串通磨洋工”这个问题最根本的原因，在这些标注人员的绩效管理方案上——之前采用的是月薪制而非计件制，有绩效奖金但微乎其微。

最近，我们在专项建立任务难度分级标准，并在完善外包人员的整体管理方案。

3 “太智能”了，也不行

最后，再说一个非常有趣的事情。

我们知道，如果一个产品不够贴心，不够聪明和智能，那用户肯定不喜欢，但反过来，如果“太智能”了，那有时候也不行。

人是不安的、焦虑的，如果让他感到“太过于神奇、不知道里面发生了很么”，他就不敢用。

举个例子，在模型服务平台的产品当中，有同学设计了“模型一键部署”功能，即把离线模型部署到在线过程中的复杂、繁琐的特征处理等工作自动化了。

然而，当大家花几个月开发出来后，却发现根本找不到一个业务方，因为大家都说不敢用。最后，这个“智能”的一键部署功能只能无奈地下线了。

（要说明的是，并不是说“简化模型部署”这个产品方向有问题，而是上述“黑盒的、让用户心里没有底”的方案，需要多斟酌，要多站在用户的角度来思考）

六 跨界、跨界、跨界

所谓跨界，就是突破原有行业惯例和常规，通过嫁接其他行业的理念和技术，从而实现创新和突破的行为。

世界著名投资家、沃伦·巴菲特的黄金搭档查理芒格，是一个极具智慧的人，他非常推崇跨界的思考方式，他指出：

• 你必须以跨学科的方式思考。
• 你必须经常使用所有可以从各个学科的大一课程中学到的概念。
• 如果能够熟练地掌握这些基本概念，你解决问题的方法将不会受到限制。

要做好技术平台的设计、运营和推广工作，你也需要跨界的思维和打法——比如，你可以把营销思维与产品、技术跨界地结合起来。

所谓营销思维，简单来说，包含“认知规律、品牌体系、素材载体、传播路径”等几个关键点：首先，要服从人们对新事物的认识规律（简单、直观），搭建起一套品牌识别和记忆的体系（logo、命名），不断策划出有创意的活动和素材，并在合适的地方进行曝光和传播。

那么，对于技术平台的运营和推广，也可以跨界地使用上述营销领域的理论和方法。

具体来说，可以从以下几个方面着手：

平台产品需要品牌

我们对所有的平台的品牌识别体系进行了梳理，参照“阿里动物园”的惯例，分别命名为知蛛金融知识图谱平台、鲸语NLP平台、图鹰金融视觉平台、千鲟搜索平台、灵犀机器人平台，每种动物的选择都尽量体现了该平台产品的特点（毕加索智能文案平台、AlphaQ智能标注平台的名称已经有一定认知度，就未做修改）。

除了名称之外，我们给力的UED同学们还设计出了非常有区隔度、记忆度，异常精美的logo。有了名称和logo，交流、传播和推广的时候，就好办多了。

产品体系需要品牌

不光要给予每一个平台以记忆度和识别度，还要考虑多个平台作为一个整体，如何记忆和传播。同样是考虑到阿里的武侠文化，我们就包装出了“AI中台天龙八部”的整体品牌概念，来传播八大AI技术平台产品。后来发现，这个“天龙八部”的在内部的影响力很高，很多人都用“天龙八部”来整体指代AI技术平台家族。

运营活动需要品牌

做运营、做推广，也需要有一个品牌的体系。所以，我们构造出了一个“AI特派员”的形象。对于我们对内发布的所有文章、视频和海报，都纳入到这个体系当中。比如，所有的内网文章标题、文章的首尾都统一格式，加入“AI特派员”的名称和形象，这样既方便形成统一认知，也方便大家日后检索信息。

此外，在运营活动和物料的设计中，也有品牌营销思维，技术和平台再高深，传播的时候也必须考虑互动、创意和趣味。

为此，我们定制了印有平台名称和slogan的有趣的可乐瓶，为标注产品体验的同学颁发“聘书”等等。

由此可见，将营销与技术、产品跨界融合，站在用户角度进行产品品牌体系和运营活动、素材的设计，就会收到较好的效果。

七 平台产品经理的挑战和成长

读到这里，你可能觉得做平台挺有趣、挺容易。

其实不然，大家都难。

对于技术平台的产品经理来说，会面临“心、脑、体”全方位的挑战。

在专业技能方面，除了要有产品经理岗位必须的“需求管理、产品设计、项目推动”等能力之外，还需要“懂技术”。要懂研发流程，要懂各种算法、模型的术语和原理，因为你不仅要与平台的开发团队对话，你还要跟平台的用户进行对话——这些用户大部分也是技术同学。

这并不是要求你比技术同学更懂技术、代替技术同学去做技术的事情，而是要求你要理解技术点的本质，要知道这个技术能做什么、不能做什么，这项技术与其他技术的区别是什么，这个技术大的发展脉络是什么。

当你下功夫搞清楚了这些问题之后，才不至于处于太过被动的局面。

但是，“缺乏主动权、成就感不强”，还是困扰着技术平台的产品经理同学。

要解决这个问题，可以从如下几个方面来考虑。

深入了解业务需求，提升业务sense

平台最终是为业务服务的，平台再牛逼，对业务没有帮助，也是不能立足的。因此，当你对业务需求有十足的把握，就能有理有据地规划平台建设的方向，就有成就感。

考虑自己能为团队带来什么独特价值

一个项目的成功、一个平台的成功，除了专业能力之外，还需要有足够沟通、协调、推动、BD、销售的能力。毫不夸张地说，要做好产品，产品经理不只是产品经理，更要有产品的“小CEO”的角色。当你通过自己的多方努力，把一件事情做成，自己就会很开心，也会赢得团队的认可。

任何一件事情，都有创新和提升的空间

对于标注平台，你可以沿着“人工标注”的老路子去做，也可以朝着“智能辅助标注”的方向去创新。对于智能文案平台，你可以只依赖算法提升的路径，也可以主动创新，把领域知识和行业经验产品化，来实现产品经理驱动。对于用户反馈的获取和产品的迭代进化，你可以使用“当面交谈、问卷调查”的传统方式，也可以尝试“分析用户日志，使用大数据+AI”的新手段。要相信，只要以终为始，从业务出发，从用户出发，就能找到产品创新的机会。

时刻敬畏产品、敬畏用户，认真做每一件事

我们曾经用这样一句话，来鼓励自己团队的同学：我们要用做几亿DAU产品的心态，来打磨几百、几千DAU的技术平台。认真的人不会吃亏，你今天的每一个付出，都会产生价值，都会提高自己。人生没有白走的路，每一个“需求”都算数。

八 结语

总算到结尾了，在这里，再对文章的内容做一个小结：

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

越基本、越简单的问题，却越难回答，也越容易被有意、无意地忽略。做产品第一步，就是要回答这些基本问题：搞清用户是谁，搞清楚用户的真实需求是什么。要深度满足用户需求，要多问为什么，了解用户真实的目的。还要忘掉自己，多从用户角度去思考。

产品设计：平台产品，也必须“秒懂”

如果一个产品一眼看过去，都乱七八糟的，搞不清楚怎么回事，那基本上就很失败了。因此，要从“产品框架、概念体系、帮助体系、demo体验、交互统一”等多个方面着手，来实现“秒懂”。

产品验证：用不“深”，就做不好

想做好产品，就要做好产品验证，产品经理要想方设法去高频、深度地使用自己的产品。有机会的话，还要自己“做点小业务”，你才会惊叹“啊，原来还有这么多问题”。在这个过程中，你自己还会有很多意想不到的收获。

平台协同：连接，产生价值

单个平台的价值和能量是有限的，当你突破平台的界限，创造更多的连接和闭环，你就会打造出一个欣欣向荣的系统和生态。

平台中的人性对抗

有人的地方，就有人性。对于多种角色参与的平台来说，要做运营、引导和治理，这样才能让整个平台平稳、健康发展。

跨界、跨界、跨界

面对复杂多变的环境，需要多元化的人才、互补的技能，需要不同行业和领域进行跨界融合。跨界会产生化学反应，跨界会产生创新。

平台产品经理的挑战和成长

成年人的字典里，没有容易二字。有问题有困难，平台、团队和个体才能提升和发展。产品经理岗位是个复合体，不是单个技能就能立足，产品经理同学需要不断迎接挑战，不断修炼自己。

相信平台的力量，相信产品的力量。

我们刚刚起步，我们继续前行。

原文链接：https://developer.aliyun.com/article/782313?

版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。