之前的文章，已经实现将商品摆上货架，已经指出了用户分析的方向和改进的策略，我们假设该过程已经有条不紊的进行中。 商品摆上货架后，最关键的就是如何匹配到对应的用户呢？ 1. 人货匹配商品和消费者的匹配，要么是商户将商品主动匹配给合适的消费者，要么是消费者主动寻找合适的商品。 1.1 商户主动推销给消费者商户如何推销给消费者哪？这里实际是信息扩散的拓扑路径问题： 销售直接联系客户 直接联系客户包括电话、陌拜等各种形式。该方式特点是直接，缺点是电话或陌拜因对客户的信息了解较少，对客户的需求洞察不够透彻，效率较低。且过于突然的拜访，会太冒昧。 商户通过其他平台间接触达客户 通过其他平台间接触达客户的好处是，根据用户的习惯不同，用户对某些平台会更亲切，有心理预期，且在其他平台推广商品消息，无需投入过多人力即可覆盖较大的客户群，客户可以受到潜移默化的影响。 商户通过客户朋友圈间接触达客户 通过客户朋友圈触达与通过其他平台触达本质一样。 客户触达最好的方式就是间接的“枕边风”模式，不要过度推销激起客户的防备心，最好让客户潜移默化的接受。如果商品够好，客户没理由不接受，如果有，那可能是没有给客户讲清楚商品的价值，或者某些原因激起了客户的逆反心理。 1.2 消费者主动找商户商户直接或间接的向客户推销时，客户可能未立即产生购买行为，后续产生需求时，商户要尽可能让客户快速的找到商户或商品。 消费者找商户会怎么办呢？ 最直接最常用的方案当然是问，问谁？问身边人、问商店的人、问App平台。 问人 问人是最直接的，问家人、问身边的朋友同事，但是身边人知道的信息不一定足够，肯定要继续扩大问的范围。 问商店 问商店，这里的问当然是广义的问，包括主动去实体店搜索、主动询问工作人员，随着范围的扩大，会提高找到合适商品的概率。 问App 问App，指的就是搜索互联网，包括各种电商平台、搜索引擎等。这里是最大的信息库，这里的信息最丰富。 互联网的重要优势就是可以提供巨大数量的商品信息供用户选择，这当然是优点。但是，用户在互联网上淘宝，如同在大海里捞针，如果不能提供合适的手段，虽然商品在那里，但是用户可能就是找不到。 2. 被动搜索方案问互联网，指的就是在互联网上搜索。 互联网上信息丰富，在互联网上搜索到想要的信息也需要丰富的搜索手段。 2.1 信息搜索方式如果信息是文本信息，会使用文本框接受文本信息，如各

一人难挑千斤担，众人能移万座山。很多场景下，一个人很难完成的任务，交给一个团队可以很容易的完成。程序算法也是同样的道理。 单台计算机一秒钟的计算量，人工可能要算几个月。虽然计算机比人的计算量已经大的非常多了，但是面对爆炸增长的大数据单台计算机也力不从心，也需要发挥集体的力量。 1. 计算机的组织方式计算机如何协作完成大量的计算任务的哪？ 1.1 计算机特征分析计算机如何协作首先取决于计算机本身的特征：计算机由控制器、运算器、存储器、输入设备、输出设备五部分组成。 控制器：控制器是计算机五大部分的领导者，控制器负责协调其余四个部分的任务，指令的下发都是由控制器完成。 运算器：运算器是运算的执行者，是硬件化的运算程序。每个CPU都有硬件编程的运算器。 存储器：存储器是存储数据的地方，存储器包括CPU的寄存器、内存、外存、网络（网络也可以抽象为存储器，也可以认为是输入输出设备）。并且各存储器的访问速度是依次下降的。虽然外存从普通的机械硬盘可以升级成固态硬盘，但是整个存储器的访问速度的递减规律并未改变。 输入输出设备：输入输出设备包括键盘、显示器等。 1.2 协作模式分析我们接着考察下计算机的协作模式： 1.2.1 单枪匹马-单内核模式从计算机的五大组成部分的描述可知，单内核的计算机也是控制器、运算器、存储器、输入输出设备五大角色、五大组件协作的结果。 这五大组件是计算机不可分割的部分，此处将他们作为一个整体看待，故称呼此模式为单枪匹马模式。 1.2.2 上阵父子兵-多内核模式一般多内核的计算机是有多个独享的控制器和运算器，共享存储器和输入输出设备。 与单内核模式相比，多个控制器和运算器可以同一时间同时执行指令，实际运行的速度可以逼近单内核模式的N倍。 1.2.3 规范化组织-集群模式该模式是多个多内核或单内核设备的集群，设备之间通过互联网相联系。 在存储设备中，与寄存器、内存、外存相比，网络连接数据传输的速度是较慢的，因此与多内核模式相比，该模式的主要卡点就是网络的速度。 网络是共享的通道，如果网络中的设备比较多，每个设备访问同样的数据花费的时间会更长。 道理也很简单，虽然现实世界，修了很多高速公路，但是节假日高速上还是会堵车，所以使用集群一定要注意尽可能减少数据传输的量。 2. 任务分割上文的三种协作模式，都需要做业务的分割，在数据量很大的情况下，不分割是无法完成任务的

计算思维是将生活中的问题编码成计算机可执行的程序，可以由计算机自动执行并得到结果。 编码成计算机程序本质就是抽象成数学模型。 系统自动执行就是实现自动化。 抽象和自动化正是计算思维的本质。实现计算机自动执行，必然需要使用算法，那么算法从哪里来，如何优化算法呢？ 1. 算法概述1.1. 算法从哪里来算法从生活中，从已积累的各个学科的知识中来。虽然我们学习算法都是从算法书上直接学习，我们是学习前人已经发明的算法，前人通过生活或其他学科在相同特征场景下，大自然或人类采取的策略获得启发，经过小心推理和验证而发明出新的算法。 比如：“退火算法”、“遗传算法”、“爬山算法”、“贪心算法”、“动态规划”从这些流行算法的名称可以看出这些算法的都受到其他学科的启发。 我们生活在三维世界中，身边相同算法的事物分布相对稀疏。而如果把三维世界的各种要素放在N维的特征空间观察，同样场景会很多相似的对象。这些对象在特征空间里运动，通过观察相似特征空间的其他对象的运动可以获得策略启发。 比如，飞机和小鸟，从三维空间里观察，两者差异巨大，“距离”很远，从特征空间里看，他们相似度要近的多。人敢于想象飞向天空，就是受到鸟类的启发，虽然现在很多飞机并未直接使用仿生学，但是如果没有鸟类的启发，人类可能不会有翱翔天空的梦想。 1.2. 算法如何优化以一维排序算法为例： N个元素，理论上有N×（N-1）×（N-2）× *** ×2×1种组合，排序无论是正序或者倒序就是从N！个组合中选择唯一的组合。 排序动作抽象为计算机语句就是：循环、判断、交换。 算法的优化就是用尽可能少的循环次数、判断次数和交换次数，完成从N！中选出指定序列的任务。 不同算法的复杂度可以用大O函数描述，该函数可以刻画算法的时间和空间复杂度。在不引入分组优化的场景下，大O函数，可以用多项式函数f(x)=axn-1+…+cx+d模拟。 如果仅有一次循环，很可能算法的复杂度为O(N) 如果有两个嵌套循环，很可能算法的复杂度为O(N²) 如果有三个嵌套循环，很可能算法的复杂度是O(N³) 我们知道指数函数增长的非常快，所以如果使用复杂度为指数函数的算法，数据量增长后，算法很快就不堪重负。 指数函数增长快，那么指数函数的反函数对数函数自然增长就慢。如果对多项式函数的x或x^n可以用x=logN的对数函数作为子函数就可以降低函数的复杂度。x=logN作

简单的问题容易解决，复杂的问题难解决。 解决复杂问题的常用方式就是将复杂问题转换为简单问题再解决。 我们从研究查字典开始，研究下查询算法的特征要点。 1.查字典简单问题和复杂问题如何区分呢？我们以查字典为例考察下。 新华字典是陪伴我们学习汉字常用的工具书，据网上资料，最新版本的新华字典收录汉字11700个(为了简化场景，仅关注收录的单字，不包括对字的解释)。 新华字典使用了多种编码方式，常用的有页码编码、拼音首字母编码。我们计算下这两个索引维度和汉字的信息量。 信息熵是度量信息量的概念，我们使用信息熵计算结果如下： 类型集合特征信息熵拼音26个拼音字母4.7页码689页9.42汉字11700个单字13.5 我们的最终目标是找到某个汉字，如果直接通过汉字查找，就是在11700个汉字中查找，信息复杂度为13.5，直观上我们就知道这个复杂度很高。 我们最常用的是用拼音查找，知道第一个首字母就能将汉字搜索范围降下来，第二个字母继续下降，最终通过拼音可以高效的找到需要的汉字。 我们参照使用字典的过程，可以推演查询算法的主要步骤。 2.编码原始信息需要经过分类才能更高效的取用，此处编码不是简单的替换符号，还要更高效的凝聚信息。 2.1.编码的作用非加密场景编码的重要作用是：信息压缩。 编码前信息如果是用11700个元素组成，添加编码信息后使用的信息元素要下降，比如用拼音排序就可以将这11700个元素分成26个组，每次筛选时，就可以快速定位到组内查询，可以极大降低查询的动作数量。 这里新增的信息压缩维度的数据类似于字典索引的功能。设想给你一本没有编码的字典，字典的11700个汉字随机的分布，使用这样的字典查找数据效率是何等的低，简直就是一个噩梦。 2.2.编码原则字典编码的重要原则包括： 正交化 顺序化 2.2.1.正交化正交化就是多个维度的信息不能有交叉，只有将数据维度拆分成，完全正交的特征空间才符合最优的编码原则。 我们使用的直角坐标系、经纬度坐标系就符合正交化的原则。 正交化与奥卡姆剃刀原则的“如无必要，勿增实体”的要求是一致的。 2.2.2.顺序化顺序化的特征就是多个元素之间前后属性是确定的，局部中隐含着全局的信息。比如： 1-10的序列，4一定在5的左边，6一定在5的右边。 a-z的序列，g一定在h的左边，i一定在h的右边。 顺序化的信息，计算机都可以编码成数字，通过序

产品经理是干什么的？ 一个比喻形象说明下，产品经理就是互联网行业的“粮食育种专家”，产品经理和技术团队协作通过“基因编码”技术编写某种植物种子各阶段生长的主信息，然后移植到土中培育，经过人工选择和优化最终培育出健壮高产的作物。 1. 概述种子要生长第一步是播种，不丢到土里或其他适宜生长的环境里是无法长出来，无法验证该品种是否优良。 1.1. 自动化对于交通系统而言，无论是地铁、高铁、汽车，销售的车票都是标准化的产品，车票本身的包含的信息属性较少，可以由计算机程序自动完成车票的上架和下架，无需人工干预。 对于搜索引擎，特别是不主导内容创作的业务模块，由自动化程序将互联网存在的各种内容爬取过来，在用户搜索的时候返回，信息的爬取也是自动化完成，无需人工干预。 1.2. 人工对于商品系统，无论是衣服、食品、家电甚至房源，这些都是非标的产品，商品摆上货架，需要人工完成，并且在商品无法销售时，还需要主动下架。 对于内容平台，知乎、小红书等，平台上提供的知识内容也是非标产品，内容的创作和上架都需要作者主动完成。 1.3. 人工辅助人工辅助是对人工上架的补充，虽然由于行业的限制，无法完全交给机器自动化完成，但是其中部分的流程是可以交给机器的。 比如： 商品信息可以构建词典，协助填充部分商品的属性信息，包括自动生成宣传标题、自动美化风格等。 商品的智能客服、物流追踪、自动下架可以由信息系统自动协助完成。 2. 电商商品上货架本文主要展开电商商品的上货架分析，期望通过分析商品上架的效率现状，制定合理的指标，并一步步实现商品上架环节的高效进行。 2.1. 物理世界的商品上架行为在互联网以前的货架主要是物理货架，包括商场摆货、菜场摆菜等，销售方需要花费大量的时间安排专人理货，并需要定期下架不新鲜的货源。 笔者调研小区的菜篮子工程商贩，他们每次来小区摆摊七八个小时，摆货、收货环节就要花掉四个小时不止，可见商品上架占据日常工作的很大一部分时间。 2.2. 互联网世界的商品上架行为互联网兴起后，线上商城包括淘宝、京东等成为最新型的货架，在这些平台上的商户需要花费大量的时间处理商品上架的工作，包括文本信息录入、图片制作上传、视频内容上传等。 商品上架效率的高低由两个参与方决定的：商户的信息录入人员和平台的软件产品及配套服务人员。 如果信息录入员思路清晰，业务熟练，有耐心，在体验差的平台上也可以完

之前发表了一篇文章，《产品经理谈一谈：水果店应该怎么开》，文章仅做了文字的分析，本文用软件架构的方式构建一下果园管理系统的部分功能。 概论 本构建使用plantuml工具完成，主要拆分为果园业务、物流业务、销售业务三个子系统。本设计主要提供UML类图，采用面向接口设计思路，使用抽象类标识各对象之间的关系，即：面向抽象设计，符合面向对象的设计模式原则。 由于整个业务涉及面非常广，图中并未标注完整的信息交互，缺失部分需要读者自行脑补。 作者对该图的定位是将主要的类和类间关系表达出来，可以通过丰富该类间关系，使用JAVA、Python等任意面向对象的开发语言便捷的完成类的构建，并能指导对应业务的可使用的软件系统设计。如果读者按照本文思路可以将《产品经理谈一谈:水果店应该怎么开》中已经描述到的场景基于本类图便捷的写出程序代码，即表示本文达到了目的。 本文仅是作者预设的业务场景构建计算机模拟系统，不保证完备性，与实际运转的业务在细节上也可能会有出入，这都是符合预期的。 果园管理 预设场景：供应商要实现以下目标 1. 对全部的果树，通过传感器、遥感等技术手段实现数字化监控，监控每颗果树全生命周期的状态变化。 2. 根据果树的健康状况，通过自动灌溉系统、无人机施肥系统、无人机喷药系统自动干预，矫正植物生长状态。 3. 系统自动监控水果成熟情况，自动计算，自动上报或自动触发矫正流程。 4. 系统自动对所有智能设备智能化监控和管理，自动监控设备状态，控制设备行为。 5. 系统自动预测植物生长和设备运行中存在的各种潜在风险，自动干预和上报。 6. 系统无法自动干预的风险，及时上报相应权限的角色。 果树管理 运行中的系统，会在内存中对每一棵果树都模拟一个对象。 前期实施阶段会将果树和各种监控传感器绑定，由监控传感器负责驱动系统中果树状态的变换。 比如：土壤传感器监测到某元素的含量偏低，会自动将该果树的状态，置为“缺肥”状态。同时自动触发通知事件，通知果树大脑，启用施肥流程。该流程会自动驱动无人机到指定位置施肥。 此场景下果树管理仅监控果树状态即可，果树的种类是静态属性，无需特殊处理。 设备管理 使用果树管理系统前，施肥、浇水、观测果树生长状态都是靠人工完成的，即使使用机械也是在人工干预下完成。 本系统上线后，这些功能全部由自动化设备完成，所以需要对设备

日常生活中我们会坐高铁、地铁、公交、大巴，这些交通系统为我们的生活带来了极大的便利，车辆时刻表是如何动态维护的？购票逻辑如何处理的？本文展开谈一谈。 1. 概述本文从产品经理的视角展开内部的实现逻辑，并用Python Pandas实现实时生成列车时刻表、并实现购票的核心逻辑，基于本代码逻辑可以实现其他拓展功能。 输出内容为两张表格： 2. 架构逻辑 架构分为三部分 2.1 前期准备道路情况、营运资质、前期建设等不是本文关注的点，我们不展开，本文主要关注以下内容 2.1.1 路线路线就是哪里是出发站，经过哪些站，哪里是终点站。高铁、地铁、公交、专线大巴的运营都是固定路线的运营，都有固定的入站和出站口。都有正方向和反方向的运营。出租和私家车虽然不会有固定的路线，但是每次出行也有出发站、终点站，实际上也适用本模型。路线主要包括：站点编号、站点名称、距离上一个站点的距离三个信息。 2.1.2车辆交通靠车辆承载，不同的车辆的成本造价、功率、载客量、速度各有不同，同时车辆也是交通运营的主要成本之一。车辆主要关注以下信息： 车辆编号：唯一识别车辆的编号，如果是汽车可以是车牌，如果是高铁和地铁可以是其他自定义标识。 座位：是整个运输过程中任意时间点，最大可承载的客户数量，客户中途有上有下，原则上同一时间可运载的客户不能超员。 功率：功率是指单位距离所做的功，高铁、地铁、油动力汽车、电动力汽车功率各有不同，根据功率和车辆的能量转化率和能量价格，很容易计算每公里花费的金额。车辆成本的计算，本文并未展开，但是留下了钩子。 速度：距离/速度=时间，根据速度可以计算列车运营时间表。 2.1.3 排班表排班表指的每条路线安排的车辆、发车时间。 始发站/方向：确定车辆行驶经过的车站，用来计算车辆到站的时间。 车次：指的是某个时间点发出的车。高铁因为距离远，车次少，比较容易注意到车次的概念。地铁、公交因为距离近，周期短，所以感知略弱，但是这两者也是有车次的概念。 发车时间：根据发车时间，和每个站的距离和速度可以计算到达每个站的时刻表。实际运营时，一般只有高铁、地铁这些有独立车道的运载工具能做到比较准时，而汽车、大巴这些使用共享车道的车辆，由于道路情况复杂，难以做到准时。不过这些特点不影响本文的分析。 2.2 实际运营实际运营指的是，基于前期准备产生列车运营时刻表。实际运营主要

以往数据分析常使用的工具是excel和sql，用这两个工具做过大数据分析的网友都能感受到那种痛苦，本文对Python的Pandas大数据分析工具做架构分析，以方便掌握该强大的工具。 本文的架构分析是通过阅读pandas中文出版物教程、互联网搜索、代码验证的基础上得到的结构猜想，并没有深入源代码分析，实际架构与本分析可能略有出入，请知悉。 1. 结构概览 数组容器：就是这本书只有页码。如果书本不超过几百页，或者使用的很少，使用起来并没有问题，如果书本有十万页，频繁找东西时肯定就麻烦了。数据分析就像在几十万、几百万页的书本里，找数据，只有页码是不够用的。 Index容器：Index是对数组容器页码的拓展，在原页码的基础上增加了文本描述，读者对频繁使用的章节可以夹个标签。Index容器有很多子类型，可以简化索引的使用，如：DatetimeIndex、PeriodIndex、IntervalIndex等 MultiIndex容器：是对Index容器的组合，不仅支持一层便签，可以支持任意层便签，通过该容器可以实现目录管理。 Series是一列数据值，DataFrame是N列数据是，是N个Series的组合。 2. Series Series是对数组的封装，比普通数组新增index的属性。不考虑MultIndex的场景该图是准确的，考虑MultiIndex，书签信息可以有无数列数据。 2.1 数据初始化Series的两列位置信息，页码信息是系统自动编码，无法人工介入。书签信息是手动编码，可以指定也可以不指定。 2.2 通过Index定位值数组支持按位置访问，比如s[1] Series支持按位置和按index访问两种方式。 Series传入的标签参数可以换算为位置信息。 loc和iloc返回值是向量 at和iat返回值为标量 位置信息的使用，用SQL表达就是： 2.3 通过值定位Index 函数返回值为bool类型的Series 要得到index值或者数据向量，需要再调用一次se.loc[] 此处函数的使用，用SQL表达就是: 2.4 MultiIndex构建Index和MultiIndex都是数组，数组的个数=数据的行数。 对于Series由于只有一列数据，所有列的层级就没有建目录的功能，DataFrame有此功能。 2.5 时间构建目录时间可以按年、月

很多人都想将来不做本职工作了，可以去开店做个小生意，但是小生意也要大智慧，有些人小生意可以越做越大，有些人小生意会越做越小，本质就是对影响用户决策的触点理解不透彻，太懵懂。生意越做越大的前提就是正确识别影响用户决策的所有触点，并将这些触点按照一定的规则组织，组织地好才能盈利，组织的差生存都难以维持。 昨天我去附近菜场的超市买水果，经历了一次很糟糕的水果购买体验。本人从自身做产品的思路出发，探讨下水果店应该怎么开。 1. 用户研究 水果是日常生活实用很多的食品。水果的种类十分丰富，应该每个人都吃过水果。比如有的人喜欢苹果、有的人喜欢葡萄、有的人讨厌榴莲等等不一而足。 和水果相关的所有属性包括：品类、品种、品质、价格。我们依次考察下用户对这些属性的认知和期待。 1.1 消费者对水果品类、品种的预期 水果分类及其丰富，水果分为苹果、梨子、葡萄、橙子等，苹果又可以细分为红富士、红肉、洛川等这是非常丰富的。有必要将所有品种收集齐全摆上货架吗？如果种类不全消费者会嫌弃种类不全吗？用户对品类和品种的预期是如何的哪？ 1.1.1 水果的季节性 消费者清楚水果具有季节性，所以对水果的种类期待不会那么高。 因为大部分消费者对季节并不敏感，大家虽然知道水果是时令的，但是具体什么时间开始成熟、什么时候上市、什么时候吃口感好，大部分是不敏感的。 我们城市生活中能见到的果树很少，而水果的种类又很多，要搞清每个水果的上市时间这是个及其复杂的事情，除非用户对水果有非常深入的研究，否则大部分都是靠水果店上架的水果来判断水果是否上市的。 所以，水果店的水果无需品种非常全，用户对水果品种是不敏感的，在你的店里看不到某个水果，用户未必会认为是门店的原因，用户会猜测可能是因为水果还没上市。如果附近店里都没有，客户更会这么认为了。 这个归因可能是错误的，如果打开百度可以很快就能发现这个错误的归因，但是“谁在意呢？”，如果不是非吃不可的东西，去了解他没必要。错误的归因就错误嘛，无需改进，因为没影响。客户不在意，商家自然也无需在意。 1.1.2 水果的区域性 水果的区域性，主要影响的是可获得水果的品质，区域性实际就是水果在产地附近可以较快的摆上货架。 水果从成熟后就启动了衰败的倒计时，所有水果都有最佳食用时间，过了这个时间就会影响水果的品相、口感、营养价值。 水果的区域性保证了水果可以在

写在前面： 本文作为人工智能系列的第一篇，先讲画图工具，人工智能的逻辑和画图有密切关系。 本文技术性较强，对Matplotlib数学库不了解的网友阅读可能吃力，可关注本人公众号，菜单栏获取一步步操作的教程。 另由于本文代码较多，也可后台查看代码版内容（本文代码是图片版）。 1. 概要本文简要介绍Matplotlib做图工具的系统架构，文章使用类图简要梳理Matplotlib的核心架构思路，立足于洞察工具的核心架构逻辑，支撑工具的日常使用。并对画布的四层级容器的作用和使用做演示说明。 概要架构图： 用计算机工具做图，是现实世界中画画，本质需要准备的东西是一致的，主要包括画图工具和画布两大模块。 2. 画图工具2.1. 画图工具说明画图工具就是各种笔，铅笔、水彩笔、刷子、颜料等，每种工具发挥的作用各有不同。 matplotlib采用面向对象设计架构，设计中肯定借鉴了该思路。区别是计算机程序不能完全对照现实的对象构建程序。 现实中，画家虽然需要准备各种画笔，但是最终有价值的是画家涂鸦的各种形状、色彩、布局等，画笔、颜料等只是实现涂鸦的手段。 计算机画图，本质是操作各种数字的变化涂鸦，所以画图工具，只需要构建各种可以用来组装的基本图形、颜色的积木和拼装平台即可。 下图中的rectangel、circle、line2d、axesimage等就是可供拼接的积木。window、figure、axes、axis就是积木拼接的平台。 2.2. 画图工具类图 按照面向对象的思想，大部分的架构都会划分为工具区和应用区。此处工具区的包括各种形状的定义、颜色、线条等。 3. 图像载体画布属于图像载体，图像载体还包括其他间接载体，硬盘也是图像载体。 3.1. 图像载体说明有了画图工具，接下来就需要画布。现实生活中可以在墙上、纸上、沙地上，各种载体都可以作为画布。显然，画在墙上，别人想参观，只能到现场，画到纸上，可以把纸带给别人，画在沙地上，风吹就会消失。 只有所承载的容器能被更大的容器容纳，能实现储存、运输、交换，这个载体才是好载体。 为了使图画能支撑更多的移动、组合，matplotlib使用了四层容器。 3.2. 图像载体类图 3.3. 载体承载关系图容器承载的逻辑生活中到处都是：饼干密封到包装袋、然后一起包装到盒子、箱子里，装到运载车辆里，车辆在地球上，地球在宇宙中... 使用容器承载，就