资深 AI 产品创业者坐镇回答： AI 产品的技术边界、AI 产品经理的能力模型、实际项目落地会可能遇到的坑等十七个问题。
职人社 × 爱因互动联合主办的「 AI 时代的产品经理 」活动上，我们邀请了爱因互动创始人 CEO 王守崑，文因互联 CEO 鲍捷以及 S 先生创始人 Mingke 三位老师，分享交流了人工智能在怎样影响业态，真正的 AI 产品经理的角色与 JD，产品的对话式交互（ CUI，Conversation UI ）特性以及产品经理在 AI 时代下技能边界在哪里等话题。 文章首发于职人社 （公众号：zhirent）。
从我们预先收集、以及现场提问的几个问题里，我们选择了 17 个好问题。我们选择好问题的标准是：
紧扣主题：AI 时代的产品经理；
定义足够明确、不需要额外解释的问题；
不需要一本书来回答。有些问题过于巨大，有些问题可能更适合科技部部长来回答。
Q：问三位嘉宾，目前在做什么事情，为什么选这个方向？
鲍捷：
这两个问题也是我每天在思考的。
我们是一个典型的拿着锤子找钉子的团队，我们看了很多不同可能的钉子，最后选择了我们认为可能是失败率比较小的钉子。我觉得金融是一个特别适合我们做演化的，金融行业从小用户到大用户均存在，金融行业开放数据非常多，具备基础条件。跟医疗这种特别注意数据保密的行业很不一样。
王守崑：
我们目前做的是商用对话机器人服务提供商。我之前做过很多个性化推荐的项目，感觉用对话机器人做个性化推荐会很有趣。
领域选择上也是金融行业，因为这个行业具备容量和纵横，最大的公司也且尚未形成垄断。市场里数据丰富，交易频繁度高，会更好地落地。
Mingke：
我们做的是用对话式的 AI 解决重复脑力的事情。
我们希望可以帮助企业解决一些需要频繁去做判断和分析的问题，然后用对话来做交互。我们当前的方向是消费服务领域。我们比较擅长对终端消费者的体验的把握，以此帮助企业提供最好体验的对话式交互的服务。
Q：金融有哪些细分领域的岗位，即将被人工智能替代？
鲍捷：
在中国的历史上，曾有一份工作叫做「句读」，是帮助别人添加标点的工作，曾是一个专门的技术学科。后来标点符号慢慢融入进我们的日常生活中。我们能说标点符号消灭了读书人么？
对这个问题，我不能准确给出一个答案。曾经欧洲出现了很多审计自动化的公司，后来这些项目都失败了。为什么呢？审计很大程度上是要帮助公司去看账面上有哪些是虚假数据的，这件事没办法被机器来取代。
所以世界上会有很多东西会被机器干掉，尤其是机械化程度比较高的事，但很多领域本身具备的特征确定了，且这些特征不会替代，比如计算机不能消灭会计。
Q：人工智能会替代很多工作，哪些会出现新的岗位？
王守崑：
新的岗位已经出现了。比如说标注师。
（人工智能中的重复劳力的工作，机器学习的训练素材需要大量的人工做标注）
肯定会出现新的商业模式和新的组织。以工程师的岗位为例，现在工程师的岗位也是越来越细分。也未来随着 AI 的逐步深入，产品经理的岗位也会越来越细分。随着产业的壮大过程中本身会有很多职业被细分，变得更加专一化，比如做模型的，可能会偏向乙方，或者专门做优化。围绕产业链的重新分工，逐步细化和专业化是大的趋势。
Mingke：
我认为 AI 时代的产品经理就是新产生的岗位，因为 CUI （对话式交互）和 GUI （图形式交互）产品做的事是完全不同的。
随着机器帮我们把重复脑力的事情的基础判断做好后，人类就会开始做一些不那么「 重复脑力 」思考，或者思考一些建立在「 重复思考 」以上的新问题。这些新的思考就会带来新的工作岗位。
xklxkl：
产品经理如果会失业，肯定不会因为不会写代码而失业。一定是别的什么东西。
Q：产品经理应该了解的技术边界是什么？应该怎么了解？
王守崑：
在我分享中我有提到过产品经理该如何去处理 AI 产品中的技术黑盒。有一件事情，希望每个产品经理都能意识到，在技术/工程越不成熟的时候，产品经理需要了解的东西就越多。比如第一代汽车的产品经理，包括内燃机的机制等一些列问题都需要了解。
现在 AI 的技术不是那么成熟的情况下，可能需要产品经理稍微把那个技术黑盒打开一些。但无论如何，产品经理是要站在用户这一边的，把控需求，做用户和技术之间的桥梁。
鲍捷：
我司的产品经理就是很好的例子，她之前是学园林设计的，后来做了产品经理，后来跟我们的程序员写起来 JavaScript，现在我们有一些小程序就是她写的。
我今天有一个新的收获，产品经理本身应该具备综合性的能力，开发、设计、综合性能力非常重要。对技术本身也需要更多的理解，还要懂运营，至少从产品生产到运营所有过程中所涉及的工作都要了解些，便于沟通跟进。
Mingke：
需要比过去产品经理更了解的人性，同时比过去产品经理更了解技术。当行业越来越清晰的时候，包括产品经理在内的每个职能的分工也将会越来越清晰。在行业的交流中，互通有无，产品经理的 JD 也会越来越清晰。
虽然每家公司的产品不同，但是抽象上，产品经理的角色是大同小异的。要求产品经理需要了解公司的核心需求以及技术储备。公司 CTO 应该告诉你我们有哪些工具和资源，产品经理不需要自己去造工具，但要对工具的属性有充分的了解，学着用手中的工具去创造新的东西。
xklxkl：
想给大家补充一些更具体的建议分享。
大家可以找到一本讲人工智能的书《机器学习》，前面有涉及人工智能简史，后面的部分比较了目前市面上主流算法的优劣在哪里。读这本书是不需要看懂复杂公式的，但能从外部明白算法适合解决哪类问题，并且如何来评价它的效果的好坏。
Q：移动互联网产品经理的提前加入，是否能给 AI 行业带来显著的提升？
Mingke：
现在产品经理的加入已经不算是提前进场了。
我对这个问题的答案是：是的会有显著的提升。核心的逻辑是，技术有限就是说技术不能完全解决一些问题。但是大家对人工智能的公司产品的普遍期待是，AI 产品应该很聪明，可以帮助解决问题的。产品经理可以用产品的方式来解决技术不能解决的问题，这就是产品经理的价值所在。
鲍捷：
技术越不成熟的时候，越需要产品经理来解决技术不能完成的事。Put human in the loop（循坏、迭代），让人的因素更重要一些。
Q：如何绕过技术瓶颈设计有趣好玩的AI产品？
Mingke：
市面上还是有一些「 智障 」产品，都是想绕过技术瓶颈但又设计的不好的结果。比如说一些早教陪伴机器人。但令人遗憾的是，这种产品也不够智能也不够有趣好玩。我觉得这个问题是值得关注，但智能方面有趣又好玩的C端产品我还没有观察到。
Q：如何看到当下 NLP 成熟度下的智能助手？我的观点是在高频拥有 Killer app 的场景下，Chatbot 是很难突围的；会在传统人类无法实现规模化效益的长尾需求和有数据积累的场景。
王守崑：
Killer App 都是 GUI 产品。在这种图形界面的使用场景下，显然 GUI 产品是更合适的。CUI 产品没法从同样的场景去取代它。
基于现在的技术成熟度，很难很快出现一款对话式的 Killer app。但可能在原来没有用 GUI 进行设计的新场景出现机会，比如：10086 的电话语音场景下的智能语音助理。电话智能语音助手过去并不是用 GUI、CUI 设计的，而是需要按键盘、输密码。这个场景但短期内应该会有很好的 CUI 产品替代。
Q：如何绕过技术瓶颈设计有趣好玩的AI产品？
鲍捷：
看到这个问题，我觉得有点悲哀。
电子游戏就是一个 AI 产品呀，游戏里面的 NPC 们都是根据 Search（搜索）、Planning（规划） 做出来的，都是AI教科书头几章的内容。手机的指纹识别也是一个典型的 AI 产品。AI 产品的规律就是，当技术成果在消费级广泛应用，大家就不认为它是一款智能产品了。
只要脑洞够大，永远会有很好的 AI 的产品。最近一个日本研究二次元的宅男产品经理做了一自动生成漫画的 app，从 3D 渲染并生成 2D 的画面，这也是很高深的 AI 技术。所以现实中到处都有 AI 产品的身影。
Q：产品经理与算法工程师、科学家日常如何协作？
鲍捷：
我有时候会客串产品经理，而且我以前也做过科学家。
工程师从学校毕业会常常以纯算法的角度去思考问题。我之前有一个实习生，他把一种机器学习算法用得出神入化。当时我们有一个分类问题，只达到 40% 的正确率，我提出能不能用规则来补充解决这个问题。我们用了一个多月时间试图解决这个多方法融合，但是没有做到。直到一年以后才解决了这个问题。技术圈里是有鄙视链的，通常用统计的人会鄙视用规则方法论的人。
我认为，产品经理诱导算法工程师把思路拓宽是非常重要的技能，需要相互融合来解决相关问题。产品经理会非常熟悉 Lean Starup 方法论，做一个合适的 MVP （Minimum Viable Product，最小可实施模型）尽快拿到反馈，用数据去做产品的迭代。而大部分算法工程师的迭代周期往往以年为单位，产品经理需要想方设法和算法工程师进行沟通，不断缩短算法工程师的周期，让他们适应产品快速迭代的周期。
王守崑：
我很同意鲍捷老师的观点。
产品经理需要对算法工程师、科学家的迭代周期有预期、有管理。
另外一个建议是，产品经理要尝试去写测试用例。不是写代码而是要描述清楚测试用例。算法工程师与开发工程师在产出的结果上有很大的不同，算法工程师的产出往往不是 0 和 1 的，会实现预期效果的 70% 或 80% 等等不同程度。通过写测试用例，产品经理会更好地定义想要达到什么样的程度的结果，和算法工程师进行有效的沟通。
Mingke：
我的合伙人算是半个工程半个科学家，他经常做论文搬运工的事，他也不断从产品的角度上思考问题，但这不可强求。能跟科学家和工程师建立良好的沟通机制，是让团队产生好的产出的前提。产品经理本来就是一个综合角色扮演者，如果和技术沟通起来有问题，我认为产品经理不能期待对方的沟通方式发生变化，更多的是要考虑自己如何能让自家工程师和科学家能以他们舒适的方式释放他们的能量，而产品的同学来扮演引导的角色。
Q：交互设计师在对话式产品中扮演什么角色？
Mingke：
过去交互设计定义的是 UX，更偏向操作上的用户体验。现在的要求，就可能是对用户的感性体验，如注意力管理，心理价值预期的管理上做功夫。简单来说是做「 人性 」的设计，而不止是「 人性化 」的设计。
从用户体验的设计师定义来说，设计师的抽象思维和学习能力非常重要。鲍捷老师前面提到设计师转型为产品产品经理的案例非常典型，另外我觉得设计师还需要细致的洞察力。专业的设计师还需要了解结构，不止是表面不同，而是更清楚概念的结构，最终抽象出来做设计。
王守崑：
我们曾设立了一个岗位叫做对话设计师，不过这个岗位的名字叫 Script Designer ，需要写 Script。（大家笑）对话产品的交互设计师肯定跟 GUI 产品的设计师定义是不一样，交互设计师和产品经理的职责可能也会有一些重叠，目前其扮演的角色还不清晰，但很重要。
Q：有什么办法用小成本去开始实施人工智能？
鲍捷：
实际开始做了，很多问题都会有解决的办法。
之前我们做过一个预测银行贷款的小案子，是咱们一个非程序员姑娘自己拿了一个算法建模做起来的，测试之后正确率可以达到 80% 左右，非常好。
王守崑：
数据够的话，简单的用传统的模型做一下也能出不错的结果；但有些复杂些的需求就会很难做，主要就看自身拥有的资源、所能投入的精力和时间等和目标之间的平衡。
Q：AI在落地中有哪些容易出现的问题？
Mingke：
早期落地时到哪里都会出现问题，因为这是一个新产品有掉不完的坑，问题不限定于部分。
王守崑：
我们的对话机器人会经常被调戏。（笑）
主要问题是客户预期与实际产品效果之间存在很多差距，如何管理客户预期是最容易碰到的坑。其次还有成本和工期控制的问题，做人工智能很难做全栈，产品生产过程中需要集成其他人的一些服务，在集成的过程中可能会遇到拖延工期、超过成本。还有客户的各种不实际的要求，很多行业对数据精确度的高要求，这些都会带来很多的问题，到处都是坑。
鲍捷：
预期管理、团队结构等，坑非常之多。最大的坑是每过十年的技术迭代，火起来之后，中间会遗留很多的坑。
Q：Mingke 刚才提到，半年前写的文章《为什么现在的人工智能产品都像是人工智障》里有很多错误，具体有哪些？
Mingke：
当时写的时候我就写了两篇。一篇是问题、一篇是解答，后一篇解答还没有发就放弃了。其实在当时提了很多好的 CUI 产品的特性和今天分享的就已经很不同了。
比如当时我提到中文口语的逻辑、上下文等问题，但实际上我们后来在场景下解决了这两个问题，但产品跑出来之后并没有实现理想的效果，而且感觉要达到效果和这两个问题没太大关系。这意味着还远远不够，还有未知的板块要被找出来处理掉。这次分享的其实就有很多新的东西，也是迭代后的思考。保持在场内跑，不断掉坑迅速出来填坑还是很重要的。
Q：鲍捷老师过去对 Chatbot 的关注非常少，现在如何看待类似产品？
鲍捷：
通用问答机器人是非常不靠谱，但在垂直领域里做问答机器人还是可以的，不过前提是数据和团队的积累。如果作为一个问答机器人，领域深入后会有很多细分问题要做，是个十年都做不完的坑。最近出的健康导购客服机器人已经是标准化的产品，但完全不看好做陪伴机器人。
Q：现在只要会写 Excel 就是写人工智能，你怎么看？
王守崑：
所有的算法都能用 Excel + VBA 来做，只不过公式会非常非常长。
如果想要做一个实际落地的项目，的确要选更实际的解决方案。但不能永远停留在 Excel，以后有机会做核心的、高成长性的一些东西的时候只有 Excel 是完全不够的，你需要有更多的工具和更好的技术去实现。
现在的 AI 公司就应该需要用 Excel 和规则去接项目的能力，同时还要有能用更炫的算法和模型去做事的能力。
Q：做电商客服机器人的难点和风险在哪？
王守崑：
电商类客服机器人，我感觉有相对成熟的方法来做。可以简单售前售后，售前会更偏于咨询，售后会更偏向于查单、物流、退货对话方面的内容。可以用一些内容识别，用相对简单的 DST，后期加上深度学习的算法，效能上还会有所提升。
难点可能是做之前没考虑到电商高峰期的问题，工程上就会有压力。
另外一个难题可能在「 让系统有对话的能力 」上，在做系统时可能一些构想不够完善，可能需要后期提高。
Q：评判一个项目的标准，如何验证一个项目效果的好坏？
鲍捷：
如果是跟银行合作的话，银行会有很好的数据。企业的现金流分析和长期短期的资金需求是可以通过经验来预判的。金融系统，后期会有数据产生，所以先通过经验做预设的判断，再用系统的数据进行回测。
Mingke：
消费领域的产品，结果不是封闭的。不像围棋有输有赢，很明确，推荐是没有明确的好坏的。所以如何判断一个不封闭的结果的好坏呢？是监督还是不监督？怎么去增强效果？
有些 CUI 团队会用剑桥 DSTC 去评判对话的效果，对对话状态来进行跟踪。实时上仅以此标准作出的产品也没有什么效果，因为对话和处理任务本来就是两回事。所以现在还是需要优秀的产品经理来对效果做判断。
