#职场社畜日常
面试复盘：
面的海尔客服数字化方向的岗位
Q1:客服人员是怎么减少的
通过产品功能，比如机器人功能 知识库功能上线后和原有产品的差距，进而客服的效率有所提升
Q2：解决率是怎么计算的
解决工单数/总工单数
正确的应该是：解决会话数/有效会话数
Q3：解决工单数口径是啥
不太会，瞎说来着
正确的应该是：未转人工且未评价不满意且情绪未识别为不满意的会话数
Q4：公司将来要改变现有的客服流程，如果是我我会怎么开展工作
1了解现有的流程，看有哪些优化的点
2调研客服，了解他们的需求
3看竞品，有哪些借鉴的点
Q5：你是怎么做竞品调研的
1看阿里 百度这些好的竞品 找到试用账号，再有可以联系竞品售前进行讲解
2从功能 页面设计 数据指标几个维度分析
（这题回答的不好，应该从用户体验五要素回答来着，那时候一时没有想出来）
Q6:你平时做汇报是怎么开展的，怎么写ppt
1首先对于不了解的领域要做调研
2可以从现有业务 业务痛点 解决方案 几个方面来列大纲
Q7:对客服数字化产品岗位的理解
1相比于传统产品经理，这个岗位肯定要懂算法，懂机器人相关的算法知识，比如自然语言理解
2产品肯定是和机器人 人工智能相关
Q8:最快到岗时间？
半个月左右
整场面试最大的bug就是我的网络不好，面试官听的断断续续的，再加上我对这个客服的业务产品不熟悉。还有就是基本功问题，连竞品分析这块都没有搞好！
所以今后就要提升业务能力和基本功啦。
面试复盘：
面的海尔客服数字化方向的岗位
Q1:客服人员是怎么减少的
通过产品功能，比如机器人功能 知识库功能上线后和原有产品的差距，进而客服的效率有所提升
Q2：解决率是怎么计算的
解决工单数/总工单数
正确的应该是：解决会话数/有效会话数
Q3：解决工单数口径是啥
不太会，瞎说来着
正确的应该是：未转人工且未评价不满意且情绪未识别为不满意的会话数
Q4：公司将来要改变现有的客服流程，如果是我我会怎么开展工作
1了解现有的流程，看有哪些优化的点
2调研客服，了解他们的需求
3看竞品，有哪些借鉴的点
Q5：你是怎么做竞品调研的
1看阿里 百度这些好的竞品 找到试用账号，再有可以联系竞品售前进行讲解
2从功能 页面设计 数据指标几个维度分析
（这题回答的不好，应该从用户体验五要素回答来着，那时候一时没有想出来）
Q6:你平时做汇报是怎么开展的，怎么写ppt
1首先对于不了解的领域要做调研
2可以从现有业务 业务痛点 解决方案 几个方面来列大纲
Q7:对客服数字化产品岗位的理解
1相比于传统产品经理，这个岗位肯定要懂算法，懂机器人相关的算法知识，比如自然语言理解
2产品肯定是和机器人 人工智能相关
Q8:最快到岗时间？
半个月左右
整场面试最大的bug就是我的网络不好，面试官听的断断续续的，再加上我对这个客服的业务产品不熟悉。还有就是基本功问题，连竞品分析这块都没有搞好！
所以今后就要提升业务能力和基本功啦。
#互联网工具，推荐一个临时邮箱工具 Temp Mail temp-mail.org ，很适合用于不想泄露自己真实邮箱的临时注册、收各种验证码、一次性场景使用，省去了经常收到垃圾、广告、机器人邮件的烦恼，测试了一下收消息很快，使用简单，此外还提供了App版本可控使用。
#工程师工具 最近发现了一个在线的支持各类编程语言的 Playground，叫做 riju.codes ，很适合写一些简单的代码，也可以用于快速验证效果，无需配置任何环境，很是方便。
#工程师工具，今天推荐一个浏览器自动化工作流的扩展叫 Automa automa.site
使用连接块来编排你的逻辑，有自动填充表单、截图、取数据、定时触发、操作浏览器、Web 交互等能力。
可以将你重复的操作很好的交给这个工具，好比快捷指令，很易使用，有需求场景的同学可以来折腾玩玩。
使用连接块来编排你的逻辑，有自动填充表单、截图、取数据、定时触发、操作浏览器、Web 交互等能力。
可以将你重复的操作很好的交给这个工具，好比快捷指令，很易使用，有需求场景的同学可以来折腾玩玩。
#职场社畜日常
saas产品的七种增长模式
1.销售驱动型增长（SLG：Sales-led Growth）
销售驱动增长主要指在一个典型的客户购买旅程中，客户通过市场渠道联系销售看demo，销售一步步跟进直到产品实施。产品只有在销售决策完成后才能开始发放到用户手中开始使用。
2.产品驱动型增长（PLG：Product-led Growth）
PLG 是一种商业策略。开发逻辑、设计理念、品牌营销、客户销售、续购增购都由用户手中的产品浓缩，并通过出色的用户体验传递给用户：产品棱镜。
这需要公司层面多团队的合作（工程师、销售、市场等）把产品当做最大的可持续、可规模化的增长渠道。
这种商业策略有着如下逻辑前提：终端用户价值的崛起已经成为企业服务领域决定性的力量。PLG 商业策略根本上是寻求一种 C 端低成本驱动增长的规模化获客体系。其底层逻辑是：把产品自身作为增长载体，前期通过免费版或者免费试用的方式，让产品自己“说服”客户，推动获客、留存、拓展的飞轮运转。
3.市场驱动增长（MLG：Market-led Growth）
营销主导的增长，意味着依靠通过网站上的内容、社交媒体营销或广告的内容营销来获取新客户。在以营销为主导的增长中，关键是尽早吸引你的客户并让他们记住你的服务。
营销主导增长的目标是让人们了解公司的产品，让他们访问公司的网站，提供独特的内容并向他们展示你们提供的价值。
4.体验驱动增长（XLG：eXperience-Led Growth）
目前业界还首次提出了体验驱动增长（XLG，eXperience-Led Growth）概念，相较于目前行业热议的三种增长模式（PLG 产品驱动增长、MLG市场驱动增长、SLG 销售驱动增长），体验驱动增长会涉及企业更多的组织部门，是对整个企业的战略调整，甚至会重塑企业的商业模式，带来第二条增长曲线。
5.客服驱动增长（CS-LG：Customer Service-Led Growth）
客户服务是贯穿整个客户生命周期中的连接和互动触点，以往的客服，定位于一个依靠知识库，对客户的问题，提供标准的解答。现在，智能客服已经代表了客户的全周期参与和长期的客户关系。客服这一业务角色，也从后台走向前台。
高质量的客服，能为企业带来巨大的经济效益。比如，从发现线索，到建立私域流量，再到帮助客户选择和达成交易，最后到复购和交叉销售，都可以靠智能客服完成。
6.社区驱动增长（CLG：Community-led Growth）
CLG面向的是积极支持用户之间的互动，并提供超越产品边界的社区价值来发展业务"朋友"。用社区驱动增长（CLG, Community-led Growth)助力PLG和SLG，用KOL和典型客户的口碑驱动SaaS产品的增长。
CLG专注于为saas产品社区创造一个安全的空间，让他们聚集在一起、分享价值、建立关系，并最好地利用他们的产品/服务来解决问题或帮助实现目标：进入市场的方式，中心是通过利用社区进行销售。
7.事件驱动增长（ELG：Event-led Growth）
事件驱动saas产品增长的模式目前适用性还有待考证，主要对于合规类、安全类SaaS产品，产品增长与国家发布的重要合规条款、要求、标准等，以及社会安全、国家安全、网络安全、设备安全等重要政策导向与业务需求相关。
对于强政策相关性saas类产品，事件驱动增长模式(ELG)也值得关注。
https://cdnv2.ruguoapp.com/Fqil-zp9Ew1ntbTvGuJbcVnPqdpFv3.png
saas产品的七种增长模式
1.销售驱动型增长（SLG：Sales-led Growth）
销售驱动增长主要指在一个典型的客户购买旅程中，客户通过市场渠道联系销售看demo，销售一步步跟进直到产品实施。产品只有在销售决策完成后才能开始发放到用户手中开始使用。
2.产品驱动型增长（PLG：Product-led Growth）
PLG 是一种商业策略。开发逻辑、设计理念、品牌营销、客户销售、续购增购都由用户手中的产品浓缩，并通过出色的用户体验传递给用户：产品棱镜。
这需要公司层面多团队的合作（工程师、销售、市场等）把产品当做最大的可持续、可规模化的增长渠道。
这种商业策略有着如下逻辑前提：终端用户价值的崛起已经成为企业服务领域决定性的力量。PLG 商业策略根本上是寻求一种 C 端低成本驱动增长的规模化获客体系。其底层逻辑是：把产品自身作为增长载体，前期通过免费版或者免费试用的方式，让产品自己“说服”客户，推动获客、留存、拓展的飞轮运转。
3.市场驱动增长（MLG：Market-led Growth）
营销主导的增长，意味着依靠通过网站上的内容、社交媒体营销或广告的内容营销来获取新客户。在以营销为主导的增长中，关键是尽早吸引你的客户并让他们记住你的服务。
营销主导增长的目标是让人们了解公司的产品，让他们访问公司的网站，提供独特的内容并向他们展示你们提供的价值。
4.体验驱动增长（XLG：eXperience-Led Growth）
目前业界还首次提出了体验驱动增长（XLG，eXperience-Led Growth）概念，相较于目前行业热议的三种增长模式（PLG 产品驱动增长、MLG市场驱动增长、SLG 销售驱动增长），体验驱动增长会涉及企业更多的组织部门，是对整个企业的战略调整，甚至会重塑企业的商业模式，带来第二条增长曲线。
5.客服驱动增长（CS-LG：Customer Service-Led Growth）
客户服务是贯穿整个客户生命周期中的连接和互动触点，以往的客服，定位于一个依靠知识库，对客户的问题，提供标准的解答。现在，智能客服已经代表了客户的全周期参与和长期的客户关系。客服这一业务角色，也从后台走向前台。
高质量的客服，能为企业带来巨大的经济效益。比如，从发现线索，到建立私域流量，再到帮助客户选择和达成交易，最后到复购和交叉销售，都可以靠智能客服完成。
6.社区驱动增长（CLG：Community-led Growth）
CLG面向的是积极支持用户之间的互动，并提供超越产品边界的社区价值来发展业务"朋友"。用社区驱动增长（CLG, Community-led Growth)助力PLG和SLG，用KOL和典型客户的口碑驱动SaaS产品的增长。
CLG专注于为saas产品社区创造一个安全的空间，让他们聚集在一起、分享价值、建立关系，并最好地利用他们的产品/服务来解决问题或帮助实现目标：进入市场的方式，中心是通过利用社区进行销售。
7.事件驱动增长（ELG：Event-led Growth）
事件驱动saas产品增长的模式目前适用性还有待考证，主要对于合规类、安全类SaaS产品，产品增长与国家发布的重要合规条款、要求、标准等，以及社会安全、国家安全、网络安全、设备安全等重要政策导向与业务需求相关。
对于强政策相关性saas类产品，事件驱动增长模式(ELG)也值得关注。
https://cdnv2.ruguoapp.com/Fqil-zp9Ew1ntbTvGuJbcVnPqdpFv3.png
两个批量工具网站，挺实用的，功能很多，你想要的批量功能基本上这两个网站都有。怎么用自行研究，用的好能节省很多时间精力，工作效率飞起。
mycointool.com
cointool.app/dashboard
mycointool.com
cointool.app/dashboard
Apple Power User是一份由网友根据自己整理记录macOS/iOS的使用经验而制作的macOS/iOS软件推荐和使用经验分享，此系列内容主要基于作者长期使用macOS系统发现时间机器也比不上直接格盘重装，于是在多次尝试之后逐步梳理出现在这些内容。正好也为自己平时积累但相关知识找个地方展示。指南涉及到macOS重装、macOS/iOS使用技巧、应用插件软件推荐使用、快捷键使用等等，而且还配图文，感兴趣的可以学习。
链接：https://kuanhsiaokuo.github.io/apple_power_user/
链接：https://kuanhsiaokuo.github.io/apple_power_user/
#职场社畜日常
被同事问过一个问题：方案成功率太低，AB实验过多消耗研发资源，怎么办？
刚开始做业务时，问题显著，不太需要AB。但随着业务成熟，方案更难、AB测试成功率也越来越低。怎么办呢？
先讲个故事。
金融行业，有一段时间，流行做预授信。
咋做呢？
就是本来，用户来申请贷款，先得提交身份证、手机号。
对用户有了基本的了解，再给用户展示额度，告诉用户可以借给他多少钱。
这是常规的贷款流程。
但是，预授信就不是这样了。
不需要用户提交身份证、手机号。
用户来了，点一下授权按钮。
授权后，我把你在我这个网站上此前的数据拿来，不用再提交材料，先给个授信额度。
满意就可以直接借款。
减少了一开始的用户操作。
正常来说，用户转化率肯定会提升。
竞品们普遍反馈，做了预授信，转化率都有显著提升。
但是，到我们这儿，做了个预授信，实际上线AB测试了一下，发现转化率不仅没提升，反而下降了。
为啥呢？
后来分析了半天原因。
才发现，是预授信给的额度太低了。
也不难理解。
用户原先给我身份证、手机号，我能给他2万的额度。
现在，用户不给身份证了，我对用户了解更少了，可能只能预授信给3000。
可是用户想借1万5。
3000都不能满足用户的需求，他当然就不会转化！
于是，预授信项目加了个策略——只对额度足够高的用户，展示预授信，其他用户老老实实提交材料。
转化率的变化，才从降低转为提升。
预授信上线之后，过了一段时间，review最近的相关AB测试时，发现好几个AB测试的效果都不好。
乍一看，是个新问题。
运营逼着风控，给一部分用户提高预授信额度。
但是风控实在看不清楚用户好坏。
提高额度的时候，很担心风险跟着增加。
于是，把给用户的利息也提高了……
预授信的利息，比用户本来能享受到的利息高。
对用户涨了价。
转化率当然也会降低！
两次的问题，乍一看不太一样，一次额度、一次利息。
但是背后，其实都违背了同一个基本认知——
“用户是奔着额度、利息这样的核心权益来的，每个项目，得让用户拿到更好的权益，转化率才会提升！”
那段时间，我们的AB测试成功率很低。
后来复盘大量失败的AB测试，发现绝大多数项目根本就不该进研发，在测试之前就应该叫停。
这些失败的项目，都至少违背了某一条早被验证过多次的基本认知。
这些项目为啥会诞生呢？
常常是团队看到了某个问题，觉得解决起来有可能带来增长。
但是设计方案时顾此失彼。
在方案的其他地方违背了基本认知，于是注定不可能实现好效果。
背后的原因是——
业务越来越成熟，每个方案需要考虑的东西越来越多。
但是，团队的成熟程度没跟上业务，考虑不到，于是总在同样的认知上犯错。
后来，我和团队做了个工作，才解决了这个问题。
我们把被反复验证过的基本认知，整理了出来，发现其实也不多，一共就十几条。
比如：
1、给用户更好的权益，才会提高转化。
2、用户始终在与竞品比较，权益的展示越方便用户比较越好。
3、复杂操作尽可能后置，让用户一开始的流程越简单越好。
4、差用户急，好用户挑。
5、比起短信，用户主动访问时，是转化更好的时机。
等等。
此后的评审会上，加了个流程。
每个方案，要先拉出这几条基本认知，对一遍，有没有与基本认知矛盾的地方。
没有矛盾，那好，可以上线AB测试。
AB测试如果验证了某条新认知，更新到认知库里。
与已有认知矛盾？
也没关系，说明理由，为什么你觉得效果可能会好？
是你觉得已有认知可能有问题？
还是你提出了一条新假设？
大家达成一致，觉得值得测试，也可以进AB。
所有人维护同一套“认知”，针对“认知”做方案、做测试，AB测试的成功率才开始快速提升。
这个工作方法，也适合大多数业务。
这个方法的本质是什么呢？
通过测试、工作，对业务形成的认知，才是一个团队最大的财富。
对于已有的认知，只有让所有人都理解、遵循，才能少走弯路。
而对认知的补充和更新，才是每个人最有价值的产出。
被同事问过一个问题：方案成功率太低，AB实验过多消耗研发资源，怎么办？
刚开始做业务时，问题显著，不太需要AB。但随着业务成熟，方案更难、AB测试成功率也越来越低。怎么办呢？
先讲个故事。
金融行业，有一段时间，流行做预授信。
咋做呢？
就是本来，用户来申请贷款，先得提交身份证、手机号。
对用户有了基本的了解，再给用户展示额度，告诉用户可以借给他多少钱。
这是常规的贷款流程。
但是，预授信就不是这样了。
不需要用户提交身份证、手机号。
用户来了，点一下授权按钮。
授权后，我把你在我这个网站上此前的数据拿来，不用再提交材料，先给个授信额度。
满意就可以直接借款。
减少了一开始的用户操作。
正常来说，用户转化率肯定会提升。
竞品们普遍反馈，做了预授信，转化率都有显著提升。
但是，到我们这儿，做了个预授信，实际上线AB测试了一下，发现转化率不仅没提升，反而下降了。
为啥呢？
后来分析了半天原因。
才发现，是预授信给的额度太低了。
也不难理解。
用户原先给我身份证、手机号，我能给他2万的额度。
现在，用户不给身份证了，我对用户了解更少了，可能只能预授信给3000。
可是用户想借1万5。
3000都不能满足用户的需求，他当然就不会转化！
于是，预授信项目加了个策略——只对额度足够高的用户，展示预授信，其他用户老老实实提交材料。
转化率的变化，才从降低转为提升。
预授信上线之后，过了一段时间，review最近的相关AB测试时，发现好几个AB测试的效果都不好。
乍一看，是个新问题。
运营逼着风控，给一部分用户提高预授信额度。
但是风控实在看不清楚用户好坏。
提高额度的时候，很担心风险跟着增加。
于是，把给用户的利息也提高了……
预授信的利息，比用户本来能享受到的利息高。
对用户涨了价。
转化率当然也会降低！
两次的问题，乍一看不太一样，一次额度、一次利息。
但是背后，其实都违背了同一个基本认知——
“用户是奔着额度、利息这样的核心权益来的，每个项目，得让用户拿到更好的权益，转化率才会提升！”
那段时间，我们的AB测试成功率很低。
后来复盘大量失败的AB测试，发现绝大多数项目根本就不该进研发，在测试之前就应该叫停。
这些失败的项目，都至少违背了某一条早被验证过多次的基本认知。
这些项目为啥会诞生呢？
常常是团队看到了某个问题，觉得解决起来有可能带来增长。
但是设计方案时顾此失彼。
在方案的其他地方违背了基本认知，于是注定不可能实现好效果。
背后的原因是——
业务越来越成熟，每个方案需要考虑的东西越来越多。
但是，团队的成熟程度没跟上业务，考虑不到，于是总在同样的认知上犯错。
后来，我和团队做了个工作，才解决了这个问题。
我们把被反复验证过的基本认知，整理了出来，发现其实也不多，一共就十几条。
比如：
1、给用户更好的权益，才会提高转化。
2、用户始终在与竞品比较，权益的展示越方便用户比较越好。
3、复杂操作尽可能后置，让用户一开始的流程越简单越好。
4、差用户急，好用户挑。
5、比起短信，用户主动访问时，是转化更好的时机。
等等。
此后的评审会上，加了个流程。
每个方案，要先拉出这几条基本认知，对一遍，有没有与基本认知矛盾的地方。
没有矛盾，那好，可以上线AB测试。
AB测试如果验证了某条新认知，更新到认知库里。
与已有认知矛盾？
也没关系，说明理由，为什么你觉得效果可能会好？
是你觉得已有认知可能有问题？
还是你提出了一条新假设？
大家达成一致，觉得值得测试，也可以进AB。
所有人维护同一套“认知”，针对“认知”做方案、做测试，AB测试的成功率才开始快速提升。
这个工作方法，也适合大多数业务。
这个方法的本质是什么呢？
通过测试、工作，对业务形成的认知，才是一个团队最大的财富。
对于已有的认知，只有让所有人都理解、遵循，才能少走弯路。
而对认知的补充和更新，才是每个人最有价值的产出。
#职场社畜日常
分享个干货：我遇到的厉害的人都是怎样解决问题的？
我发现他们常常都有类似的简化问题的思路，帮他们解决了大量的难题。
但是大多数人，却意识不到还能这么做。
先讲个故事。
曾经有个C2C的电商，很愁一个问题——
怎么知道用户卖的到底是什么商品？
为啥这会是个难题呢。
因为他上面，不光有专业卖家。
还有好多偶然卖卖二手物品的小卖家。
对于专业卖家，你只要告诉他：“你发布商品时，还得勾选一下品类，选出来你这个卖的是男装女装，卖的是手机还是电脑，如果是手机，是什么型号。”
专业卖家们肯定会照着做。
再麻烦他们也能做。
但是，对小卖家们，都不是专业卖货的。
好多时候连张图都懒得发，就更别说在几百个品类里完成勾选了。
最懒的卖家，常常就发几个字。
“果4 9新 3000元”。
你说你咋知道这卖的是个啥？
你都不知道卖的是啥，怎么匹配给买家？
没有买家，怎么卖得掉？
于是，为了提高成交率，留住卖家，有一天，他们立了一个专项：
不管用户发的内容多简单，系统都要识别出来，这到底是个啥，帮他找到买家。
正常来说，这是个算法的工作。
得做自然语言识别。
但是，那会儿技术也没那么成熟，公司的研发更不成熟，憋了几个月，没憋出来一个达标的解决方案。
后来，项目负责人提了个方案——
商品品类虽然多，毕竟是有限的嘛，咱们不等算法了！
用词表来吧！
具体干起来是这么几步：
1、
每天，研发跑一批用户发出来的商品。
这些商品，拿现有的词表匹配一遍。
2、
匹配结果，人工看一眼。
—— 匹配对的，不去理会。
—— 匹配错的，修改词表。
—— 没匹配出来的，看看有哪些关键词，更新到词表里。
不做这个项目。
还真不知道，iPhone4有这么多种不同的叫法。
有拼错的，“iPone4”。
有简写的，“ip4”“p4”“果4”。
好在，毕竟可能性是有限的。
周而复始。
准确匹配出来的商品，从一开始的40%，慢慢涨到了90%多。
词表里面的词，一共6万多个。
剩下的，匹配不出来，太长尾了。
但是，好在也没那么重要。
因为90%的问题已经解决了，比起一无所有时，已经好太多了！
项目上限，圆满收工。
这个项目果然也是公司当年的明星项目。
这个解决问题的思路是什么呢？
我把它叫做“将无限问题，转化成有限问题”。
最难解决的问题，常常是个“无限问题”。
看起来可能性众多，无比复杂。
但是，只要你不追求解决到100%——世上有几个100%的解决方案嘛！
大可以把其中90%以上的问题，转化成一种可能性有限的问题来解决掉。
有限问题，就可以上人工了。
解决无限问题，是个谁也不知道能不能搞定的技术难题。
解决有限问题，则是个只要你乐意投入精力，必然一分耕耘一分收获的辛苦活！
“将无限问题，转化成有限问题”，也是我认识的很多厉害的人解决难题的思路。
比如：
百度是怎么实现更好的搜索体验的呢？
一个关键解决办法，就是人工配制。
用户搜得多的结果，咱别技术及算了，直接上人工吧！
于是，的确实现了搜索体验的大大提升。
这个项目，在百度被叫做“阿拉丁”。
比如：
有个语音交互项目。
他们需要机器听语音，快速给出反馈，实现交互。
这个反馈时间越短，用户感受越好。
但是用户可能下发的指令，也是无限的呀。
不过常见的可能就200种，每种有10个表达方式。
完全可以上词表解决。
比如，这个机器叫“香蕉”吧。
你其实不需要听完“香蕉香蕉，开空调”再开空调。
你只要听完“香蕉香蕉，开空”，其实就足够做出判断了。
就节省了一个字的时间。
当竞品还在坑哧吭哧等着语义识别的结果时，
这个机器已经会抢答了。
当你遇到一个难题时，你也可以向他们学习。
问问自己：这是个无限问题，还是个有限问题？
如果是无限问题，我只解决它的90%，能不能转化成可能性有限的问题？
很多时候，难题也就不再是难题！
分享个干货：我遇到的厉害的人都是怎样解决问题的？
我发现他们常常都有类似的简化问题的思路，帮他们解决了大量的难题。
但是大多数人，却意识不到还能这么做。
先讲个故事。
曾经有个C2C的电商，很愁一个问题——
怎么知道用户卖的到底是什么商品？
为啥这会是个难题呢。
因为他上面，不光有专业卖家。
还有好多偶然卖卖二手物品的小卖家。
对于专业卖家，你只要告诉他：“你发布商品时，还得勾选一下品类，选出来你这个卖的是男装女装，卖的是手机还是电脑，如果是手机，是什么型号。”
专业卖家们肯定会照着做。
再麻烦他们也能做。
但是，对小卖家们，都不是专业卖货的。
好多时候连张图都懒得发，就更别说在几百个品类里完成勾选了。
最懒的卖家，常常就发几个字。
“果4 9新 3000元”。
你说你咋知道这卖的是个啥？
你都不知道卖的是啥，怎么匹配给买家？
没有买家，怎么卖得掉？
于是，为了提高成交率，留住卖家，有一天，他们立了一个专项：
不管用户发的内容多简单，系统都要识别出来，这到底是个啥，帮他找到买家。
正常来说，这是个算法的工作。
得做自然语言识别。
但是，那会儿技术也没那么成熟，公司的研发更不成熟，憋了几个月，没憋出来一个达标的解决方案。
后来，项目负责人提了个方案——
商品品类虽然多，毕竟是有限的嘛，咱们不等算法了！
用词表来吧！
具体干起来是这么几步：
1、
每天，研发跑一批用户发出来的商品。
这些商品，拿现有的词表匹配一遍。
2、
匹配结果，人工看一眼。
—— 匹配对的，不去理会。
—— 匹配错的，修改词表。
—— 没匹配出来的，看看有哪些关键词，更新到词表里。
不做这个项目。
还真不知道，iPhone4有这么多种不同的叫法。
有拼错的，“iPone4”。
有简写的，“ip4”“p4”“果4”。
好在，毕竟可能性是有限的。
周而复始。
准确匹配出来的商品，从一开始的40%，慢慢涨到了90%多。
词表里面的词，一共6万多个。
剩下的，匹配不出来，太长尾了。
但是，好在也没那么重要。
因为90%的问题已经解决了，比起一无所有时，已经好太多了！
项目上限，圆满收工。
这个项目果然也是公司当年的明星项目。
这个解决问题的思路是什么呢？
我把它叫做“将无限问题，转化成有限问题”。
最难解决的问题，常常是个“无限问题”。
看起来可能性众多，无比复杂。
但是，只要你不追求解决到100%——世上有几个100%的解决方案嘛！
大可以把其中90%以上的问题，转化成一种可能性有限的问题来解决掉。
有限问题，就可以上人工了。
解决无限问题，是个谁也不知道能不能搞定的技术难题。
解决有限问题，则是个只要你乐意投入精力，必然一分耕耘一分收获的辛苦活！
“将无限问题，转化成有限问题”，也是我认识的很多厉害的人解决难题的思路。
比如：
百度是怎么实现更好的搜索体验的呢？
一个关键解决办法，就是人工配制。
用户搜得多的结果，咱别技术及算了，直接上人工吧！
于是，的确实现了搜索体验的大大提升。
这个项目，在百度被叫做“阿拉丁”。
比如：
有个语音交互项目。
他们需要机器听语音，快速给出反馈，实现交互。
这个反馈时间越短，用户感受越好。
但是用户可能下发的指令，也是无限的呀。
不过常见的可能就200种，每种有10个表达方式。
完全可以上词表解决。
比如，这个机器叫“香蕉”吧。
你其实不需要听完“香蕉香蕉，开空调”再开空调。
你只要听完“香蕉香蕉，开空”，其实就足够做出判断了。
就节省了一个字的时间。
当竞品还在坑哧吭哧等着语义识别的结果时，
这个机器已经会抢答了。
当你遇到一个难题时，你也可以向他们学习。
问问自己：这是个无限问题，还是个有限问题？
如果是无限问题，我只解决它的90%，能不能转化成可能性有限的问题？
很多时候，难题也就不再是难题！