下面这篇文章是笔者整理分享的关于自身的产品和项目及面试经历，其中内容包含了爱企查/舆情/情报分析/风险预警等系统所解决的业务问题、各系统的共通之处及差异分析以及关于“架构”的一些思考的相关内容，对此感兴趣的同学接着往下看看了解更多叭！

个人从事2B/G产品工作3年半，期间个人直接或间接负责建设的系统包括：【智慧城管系统】、【政务热线分析系统】、【人体/车辆异常行为告警系统】、【舆情分析系统】、【开源情报分析及侦察系统】、【公共安全防控与预警系统】、【自训练平台】、【OA系统】等。

• 产品形态上，这里面以中屏居多，也有小屏和大屏；
• 产品服务模式上，有端到端的SaaS系统、客户端系统（需下载部署安装）、还有直接提供API服务的；
• 产品使用的AI技术上，有NLP的，有CV的，有ASR+NLP的，有知识图谱的，还有跨模态的；
• 产品使用的数据上，有仅开源的，有仅闭源的，也有开源+闭源相结合的。

今天就来聊一聊，这些系统以及诸如“爱企查”、“企查查”、“千里马招投标”，还有面向KOLMCN提供运营/营销服务工具的如“飞瓜数据”、“蝉妈妈”系统，有什么共通之处？又有什么差异？

一、爱企查/舆情/情报分析/风险预警等系统所解决的业务问题

二、上述各系统的共通之处及差异分析

1. 共通之处分析

做了这么多产品/系统，我发现，这些系统（城管系统、政务热线分析系统、公共安全防控与预警系统、舆情系统、情报分析系统…，包括爱企查、企查查、还有飞瓜数据、蝉妈妈、七麦数据等），它们本质上就是一类东西：【（大）数据处理与分析系统】。

即，都是对采集或获取到的各种数据（有仅开源的，有仅闭源的，有开源+闭环的），利用各类AI算法（有只用CV的，有只用NLP的，有多种技术结合的）进行治理和分析，最终给到业务侧去应用，而且业务应用功能多为：预警、分析。作为为业务发现风险的一个“上报源”。

——这是从数据流转层面来看的，上述各个系统的【共通之处】（即产品架构基本类似）。抽象来看，上述各个系统的业务流程都如下，且与OA系统的关系如下：

OA系统，可以负责上述【数据处理与分析系统】提供的风险数据的后续业务操作与处置，使得业务能够流转（如生成告警工单，案件处置表单等，进行多部门的协同）。

——从对外提供的产品服务模式来看，厂商一般也会优先提供基于互联网的PaaS服务或SaaS形式。

这是因为服务升级、运维均在厂商自己侧，维护和管理成本低。而私有化部署交付这种服务形式，对厂商侧的运维成本很高。

2. 差异点分析

（1）从产品面向的客户类型来看，这些系统（城管系统、政务热线分析系统、公共安全防控与预警系统、舆情系统、情报分析系统…，包括爱企查、企查查、还有飞瓜数据、蝉妈妈、七麦数据等），其是有差异的。

A. 客户类型不同，导致的交付模式差异

• 2G产品，客户一般都会要求私有化（不论是端到端的系统，还是AI能力）；
• 2B产品，如OA系统，在产品形态上，厂商会优先给客户推荐SaaS方式，但同时为兼顾一些大企业客户，也会支持私有化部署服务形式。
• 2C产品，如七麦数据、今日热榜等，一般会提供SaaS服务（H5），比较少有支持PC客户端或App客户端下载的。

B. 客户业务场景不同，导致的业务功能差异

由于这些系统（本文开头提到的系统）面向的行业、客户有所不同，这就导致具体的业务场景不同，业务场景不同，就会衍生出差异化的产品功能，也会根据业务需求，确定选择用哪些技术实现。

（2）若产品是专门提供数据服务的，从数据的开、闭源角度来看，这些系统（城管系统、政务热线分析系统、公共安全防控与预警系统、舆情系统、情报分析系统…，包括爱企查、企查查、还有飞瓜数据、蝉妈妈、七麦数据等）的对外服务模式也是有差异的。

• 若数据是开源的。厂商一般会选取SaaS形式交付（如舆情系统、为MCN/KOL提供营销工具箱的产品：蝉妈妈、爱企查等、为C端用户提供数据分析服务的产品：七麦数据等），数据治理分析的成果供客户/业务侧付费查询、使用。
• 若数据是客户提供的，即闭源的。客户一般需要私有化部署安装（Based LAW）。如本文中的【城管系统】、【安防监控分析系统】、大企业使用的【OA系统】等。
• 若数据既有开源，又有闭源的。那么产品服务模式，就会变成：半SaaS（PaaS）+半私有化。客户允许厂商数据进入客户内网，但客户绝对不会允许客户数据（关于人、车、公司强相关的业务数据，这些隐私、机密数据）出来到互联网环境。

三、关于“架构”的一些思考

为什么会写到这个内容，之前在面试过程中，几次被问到了产品架构相关的问题，遂有了下述思考，小伙伴们可有自己的见解哈~

1. 什么是架构？

我们经常会在什么短语中听到这个词？组织架构，对吧？每行每业都会有架构师。建筑行业的架构师：建筑设计师，再细分开来：有土木结构设计师、钢结构设计师、住宅建筑设计师、室内家装设计…

我们互联网这行，提到架构，经常会听到：解决方案架构、业务架构、技术架构、产品架构、功能架构、信息架构…对吧？

那到底什么是架构呢？先放几张图感受一下：

图来自网络（如有侵权，联系删除）

图来自于百度云官网-智能客服产品架构（仅作交流学习使用，如有侵权，联系删除）

图来自于网络-标签体系架构（仅作交流学习使用，如有侵权，联系删除）

图来某项目-个人设计的产品架构

图来自于阿里云官网-某数据需求场景解决方案架构图（仅作交流学习使用，如有侵权，联系删除）

我理解架构的本质，就是一个东西的内核，是其核心框架/骨架，并按一定的逻辑顺序，将支撑这个系统的核心骨架串起来，并给出各个模块间的交互关系，在每个骨架层同时加以“血肉”使其稍微“具象化”。至于最终的呈现形式可以是上面那些常见的规规整整的架构图，也可以是流程图，也可以是脑图、表格…等多种展现形式。

那业务架构、产品架构、技术架构、信息架构之间的关系是怎样的？

• 业务架构，一般来自于业务需求调研、业务流程梳理后，进行设计的，一般由企业的组织架构决定；
• 产品架构，一般来自于业务架构。
• 技术架构，来自于产品架构。
• 信息架构（在软件领域），来自于产品架构，等于最终呈现给用户的信息结构，如导航栏、菜单栏等。

2. 如何设计产品架构？

根据我相关产品/项目工作实践经验，我总结了几个有效的设计产品架构的方法：

（1）从数据流向来设计。即从数据怎么来的->怎么加工处理的->到怎么给到业务去应用的这样的顺序去设计。

（2）参照OSI框架来设计。

（3）按Iaas、PaaS、SaaS，从底到顶逐层来设计。

其实，上面这几种方法的本质是一样的，我认为都是根据数据流向来设计的。那什么是好的产品架构设计？

——类比于房子等建筑的架构，其好与坏，可以用一些实际应用情况来评估，比如抗风程度、抗地震程度…软件产品架构（软硬件结合产品的架构），一般要求：其稳定性、健壮性、鲁棒性均较强。

——但软件产品与房子建筑架构（结构）又不太相似的地方在于：软件产品一般更新迭代速度较快，而实体房子不会推倒重建（除非地震坍塌、建筑主体损坏，需要翻修等等），这就要求软件产品架构还需具备很重要的复用性和可扩展性。

3. 产品经理的架构能力要求

产品经理，一般从产品助理做起，从一开始接触简单的功能需求（如设计一个简单的功能模块：这里面可能会包含业务流程的调研/梳理/设计、功能输入输出的制定、原型界面设计等内容）、到负责一个产品核心模块的建设、到负责一整个产品线的建设，并为产品商业化负责。

在整个产品经理打怪升级过程中，不论是功能型的产品经理，还是策略型的产品经理，还是软硬（硬件产品经理）结合的产品经理，其架构能力要求，肯定是逐渐升高的。

• 工作1-3年的产品经理，其JD中，基本上不会有架构设计能力要求
• 工作3-5年的产品经理，其JD中，大部分开始要求具备产品规划、架构设计能力；
• 工作5-10年的产品经理（本质上，应该是高级产品经理或产品架构师了），其产品架构设计能力要求不言而喻，肯定是极高的。

图来自Boss直聘（如有侵权，联系删除~）

图来自我的某个offer

图来自Boss直聘（如有侵权，联系删除~）

所以，我们1-3年或3-5年的产品经理平时在进行产品工作时，要多去了解公司的组织结构以及业务情况，以及市场上的其它优秀产品，才能据此设计出适合于部门或团队的产品架构。架构能力的提升，我认为本质在于模块化、抽象化思维的不断锻炼。

四、全文总结

本文主要基于个人此前的产品和项目及面试经历，首先梳理了每个产品所解决的业务问题，然后介绍了这些产品在架构层面、在对外服务形态等层面的共通之处和差异点。最后介绍了关于“架构思考”的内容。文章中，如有不正确之处，欢迎小伙伴们指出，我们一同探讨，共同成长~