1. 从接到需求到项目落地DeskcommCRM 到底解决什么问题先说个我在一线摸爬滚打常遇到的场景团队规模三五十人、销售加客服加运营混杂在一起每天大量客户信息散落在微信聊天、Excel 表格、纸质便签和各个同事的脑子里。客户跟进了三次换一个人对接前因后果全部断档销售下午要跟进一批潜客却连今天该打哪几个电话都理不清楚老板想看看这个月线索转化率财务给你一张从 ERP 导出的账单运营给你一份从企微扒下来的聊天记录两边对不上数。这种状态下不是员工不努力而是缺少一套能把客户信息、跟进过程、协作分工、统计分析放在同一个地方的业务系统。DeskcommCRM 这个概念本质上就是针对上述问题的整体解决方案。它不是某个特定软件的名字而是一类以“桌面办公 沟通协作 客户关系管理”为核心的工具型系统的代称。我在实际项目里遇到过的 DeskcommCRM 实现方案既可以是基于开源套件二次开发出来的内部系统也可以是采购成熟 SaaS 以后做了大量自定义配置的业务中台。无论技术路线怎么选它要解决的都是同一件事把客户数据、销售流程、团队协作和沟通记录统一收口让每个人都清楚“现在该干什么、之前发生了什么、接下来怎么推进”。这类系统适合谁去看、去参考第一类是业务负责人天天被线索流失和撞单问题困扰想搞明白 CRM 到底能帮团队做什么第二类是产品经理或项目经理需要设计 CRM 的落地形态正在纠结数据模型怎么建、权限怎么分第三类是开发同学需要从零搭建一套可用的内部系统想看看一个合规、完整、能跑起来的 CRM 该拆成哪些模块以及每个模块里面有哪些容易踩的坑。这篇文章我会从产品设计、技术实现、实操落地三个层面把 DeskcommCRM 从头到尾拆开讲清楚。2. 设计思路不要把 CRM 做成“填表工具”2.1 一次失败的选型给我的教训之前有个朋友的公司选型 CRM领导拍板买了某知名 SaaS结果用了半年业务人员怨声载道每天被迫录入大量字段跟进记录没人写报表数据全是垃圾。问题出在哪他们对 CRM 的定义就是“一个记录客户信息的数据库”把管理的重心放在了“填得多不多、填得全不全”上而不是“帮业务人员提高效率、帮管理者看清现状”。真正好用的 DeskcommCRM 系统设计逻辑应该是倒过来的先理清业务角色每天的工作流再看看系统能在哪些环节帮他们省事最后才决定需要哪些字段和页面。销售打开系统的第一眼应该是“我今天要跟进的客户列表”而不是一张空白的录入表单客服接到客户来电系统应该自动弹出这个客户的完整历史记录而不是让客服先去搜索客户姓名。把“查询和记录”变成“系统主动推送和自动填充”这是 CRM 能不能被团队真正用起来的生死线。2.2 核心角色与场景拆解我在规划 DeskcommCRM 的功能模块时习惯先用一张“角色-场景-痛点-方案”的表格把需求收敛清楚。下面这个表格是我在多个项目里反复打磨出来的模板你也可以照着它先给自家业务做一轮梳理角色核心场景核心痛点系统方案销售人员每日跟进、记录沟通、推进商机不知道先联系谁、忘记上次聊了什么工作台按优先级展示今日待办跟进记录时间线自动归档销售主管查看团队进展、预测业绩、协调资源靠开会和问询获取信息信息滞后失真实时看板展示商机阶段分布、转化率、预计回款客服人员快速响应咨询、处理售后问题客户信息分散重复询问让人反感来电/来访自动弹窗展示历史订单与历史工单运营人员活动线索导入、分层运营、效果分析线索质量参差活动 ROI 算不清楚线索来源跟踪、批量导入与自动打分机制管理层查看整体经营、复盘销售策略数据口径不统一、跨部门数据难打通统一的客户数据中心与可配置的多维报表有一点必须承认不管系统设计得多好如果业务人员觉得“用系统比不用系统更费事”那这套系统大概率会被弃用。所以我在做功能设计时优先级排序一定是减少重复劳动 提升信息查找效率 帮助决策分析 满足数据管控要求。一线用户感受到的永远是“系统帮了我”而不是“公司又给我增加了一个任务”。2.3 为什么选型要优先考虑可配置的元数据驱动架构市面上很多 CRM 产品最大的问题是“灵活性不够”字段是固定的流程是写死的客户类型一多、业务模式一变系统就变成了鸡肋。我个人的经验是无论是自研还是基于开源产品改造一定要优先选择“元数据驱动”的架构方案。所谓元数据驱动简单说就是把“字段怎么定义、页面怎么展示、流程怎么流转”这些规则从代码中抽离出来存放到配置表里。当业务需要增加一个新的客户类型时管理员在后台配置一下即可而不是让开发改代码再发版。一个形象的类比是传统开发方式相当于在墙上打了很多固定的挂钩每来一件新衣服你都要重新凿墙打孔而元数据驱动的系统相当于给你一面洞洞板换挂钩的位置和数量只是几秒钟的事情。DeskcommCRM 如果要做成通用产品元数据驱动架构几乎是必选项因为没有哪两家企业的销售流程是完全一致的。3. 功能模块拆解一张图看懂 DeskcommCRM 的整体框架严格来说一个完整的 DeskcommCRM 系统应当包含客户数据管理、线索与商机管理、跟进协作、工单售后、数据分析与系统管理六大核心模块。下面我逐个拆解每个模块的设计要点和关键技术决策。3.1 客户数据管理唯一的客户 ID 是数据流转的基础所有业务系统最终都要落到数据上而客户数据管理的核心任务就是把分散在不同入口的客户信息统一起来。在实际建设时我建议优先解决三个问题第一唯一客户 ID 的生成规则。客户可能来自手机号、微信号、企业统一社会信用代码等不同标识系统需要定义哪一个是主键。实践中我常用“手机号为主键其他标识作为辅助”的策略因为中国市场环境下手机号覆盖率最高。但需要特别注意的是一个手机号可能对应多个联系人一个企业客户也可能有多个联系人和多个下单账号所以客户表与联系人表必须分开设计不能塞进一张宽表里。第二数据合并与去重策略。销售在录入客户时大概率会录重复。系统在新增客户时要自动做相似度匹配姓名手机号完全一致直接合并企业名称经过标准化处理后一致也合并邮箱、地址等字段则作为辅助置信项。合并的时候还要小心不能简单删除要保留历史审计日志否则客户数据被误合并后极难恢复。第三360 度客户视图。这是 CRM 系统里最能提升体验的设计在客户详情页把基础信息、跟进记录、订单情况、工单记录、沟通记录、待办任务全部集中在一个时间线上展示。这样任何一个接手同事打开客户页面都能完整了解前因后果减少重复沟通。3.2 线索与商机管理销售流程的数字主干线索Lead与商机Opportunity的区别很多做 CRM 系统设计的人自己都说不清楚。我一般这样向业务人员解释线索是一个“潜在的可能成交的未知对象”商机是销售团队已经明确认可的、有具体金额预期和成交时间预期的销售机会。线索是业务漏斗的入口商机是漏斗的中段而最终成交形成的订单则是漏斗出口。在设计上线索阶段要包含“来源渠道”“意向等级”“下次跟进时间”“负责人”并且要支持批量导入运营经常从活动报名表整理成 Excel 批量导入。当销售把线索转化为商机时系统应该自动带入线索全部信息并把线索状态调整为“已转化”禁止重复转化。商机阶段则是销售预测的核心我通常建议采用“阶段 概率”的模型。例如初步沟通10%、需求确认30%、方案报价50%、商务谈判70%、赢单100%。当商机推进到一定阶段时系统自动提醒销售补充必要信息比如报价单是否上传、谈判纪要是否填写这比人工去查记录要可靠得多。还有一个经常被忽视的模块是“商机评审”。很多面向 B 端的销售场景丢单不是因为销售不努力而是折扣太低、回款条件太差。系统里应该内置一个审批流当商机金额超过一定阈值或折扣低于标准值时自动触发审批流程。换句话说CRM 不只是记录工具还要能承载业务规则。3.3 跟进协作与沟通记录让信息流转不依赖人的记忆团队协作模块的核心是“跟进记录”和“工单系统”。跟进记录在业界最佳实践里被称作“Feed”或者“Timeline”它不是一个简单的文本字段而是一串带时间戳、带类型、带参与人的事件流。比如 2025 年 5 月 10 日上午十点销售 A 给客户 B 打了电话沟通过程记录为“对方对价格仍有疑虑已重新发送报价单”系统自动把这条记录挂到客户 B 的页面上同时生成一条提醒注明下次跟进时间是两天之后。工单系统的设计相对独立因为售后场景与销售场景的时效要求完全不同。销售注重线索阶段的转化效率工单注重 SLA 响应时效。我建议工单模块至少要支持“待处理、处理中、待客户确认、已解决、已关闭”五种状态并且在状态变化时自动通知客户或内部负责人。如果一个工单超过 24 小时未处理系统自动向上级升级避免客服遗漏造成客诉。沟通记录的集成也值得多说一句。主流方案是企业微信或钉钉的会话存档接入常见做法是把客户群、单聊记录、电话录音转写的文本全部自动归档到客户时间线。这块在实施时的技术复杂度主要在数据同步和隐私边界两个点后面我会在实操章节再把接口对接的关键步骤讲清楚。3.4 数据分析与报表指标口径一致比图表漂亮更重要最容易被低估的模块是数据分析。很多团队上 CRM 时对报表的期待就是“有几个漂亮的图表”但实际运行一段时间后就会发现图表漂不漂亮是次要的指标口径一不一致才是生死攸关的问题。销售说这个月新增线索 50 条运营说活动带来 80 条老板问到底哪个数是对的系统内部如果连“线索”的定义都不统一那所有分析都是扯皮。我建议在项目初期就成立一个指标字典把 CRM 涉及的每一个关键指标定义清楚。下面我列一个我自己项目中常用到的指标定义表供大家参考指标名称业务定义计算口径新增线索数本周期内首次进入系统且未被删除的线索总量按线索创建时间统计排除系统自动生成或测试数据线索转化率线索转化为商机的比例已转化商机的线索数 ÷ 有效线索总数 × 100%商机赢单率赢单商机占全部关闭商机的比例赢单商机数 ÷赢单商机数 输单商机数× 100%平均成交周期从线索创建到赢单的平均天数SUM(赢单日期 - 线索创建日期) ÷ 赢单数回款率已回款金额占合同金额的比例已回款总额 ÷ 合同总额 × 100%报表设计的前端展示是最后一步反而是数据仓库层的模型设计最花时间。如果你使用一套独立的数据分析库比如将 CRM 数据通过定时任务同步到 ClickHouse 或 MySQL 分析实例建议在源头就把客户、线索、商机、订单、工单这些核心表的字段规范好尽量做到一数一源避免报表层到处查数据、到处拼表。3.5 系统管理与权限模型三层的权限设计最稳妥权限设计不到位CRM 上线第一天就会出乱子。销售总监能看到所有客户和商机那是应该的但普通销售如果能看到全公司所有客户的手机号和成交价格轻则团队内互相“撬单”重则数据被批量导出泄露这是合规层面的大问题。我在项目中标准做法是采用“功能权限 数据权限 字段级权限”三层模型。功能权限决定用户能使用哪些菜单和按钮例如“导出客户数据”这个功能只对特定角色开放数据权限决定用户能看到哪些数据行常见规则有“本人数据、本部门数据、全部数据、自定义范围”字段权限决定用户能看到哪些列例如普通销售能看到客户的采购意向但看不到成本价和折扣底价。实际配置时还有一个细节很容易被忽略离职员工的客户资源自动转移。销售岗位流动性高如果员工离职时系统没有自动做客户负责人变更客户资产的流失率会非常惊人。我建议在系统的员工管理模块中将离职操作与客户转移绑定离职提交时强制选择一个接管人系统自动完成数据交接。4. 从零搭建 DeskcommCRM技术选型与关键实现前面讲了产品设计层面这一章我会把自研或者二次搭建 DeskcommCRM 的技术路线、技术栈组合和核心实现细节讲透。对于预算充足的团队可以直接购买成熟产品但对于预算有限、或者业务模式特殊到市面上产品覆盖不了的团队自研仍然是值得认真对待的选项。4.1 技术栈选型不妨从最“无聊”的稳定组合开始在技术选型这件事上我吃过不少亏。早些年我热衷于追逐新框架Redis 换成了某种更新的内存库数据库从 MySQL 换成 PostgreSQL结果项目交付时遇到一堆兼容问题。后来我自己总结了一个原则核心业务系统尽量选择工程师熟练掌握、生态成熟、社区文档丰富的主流技术栈不要为了炫技引入太新颖的组件。在 DeskcommCRM 的项目里我建议采用如下组合层次技术选型核心原因前端Vue 3 / React 18 Element Plus / Ant Design组件丰富适合快速搭建后台管理界面后端Java Spring Boot 或 Go Gin生态成熟事务处理与权限控制能力稳定数据库MySQL 8.x业务库 Redis缓存与会话关系型数据存储适合 CRM 的强事务需求文件存储阿里云 OSS / MinIO私有化部署存储合同附件、客户证件、导入模板等文件定时任务XXL-Job 或 Spring Scheduler处理邮件提醒、次日跟进提醒、数据同步任务消息通知企业微信/钉钉 Webhook 内部站内信让用户及时收到工单、审批、待办通知前端界面我推荐使用 Ant Design Pro 这类后台管理模板作为起点它可以帮你解决头部导航、侧边菜单、权限路由、用户管理这些通用能力节省大量基础工作。后端在权限控制方面建议使用 Spring Security 或 Casbin 这类成熟权限框架而不是自己手写拦截器权限模型一旦复杂起来手写方案会非常痛苦。4.2 数据库表设计客户、联系人、商机、跟进记录的建表思路这部分是整个系统开发中最核心、也最需要提前规划的环节。我常在项目里讲CRM 的数据模型设计很大程度上决定系统未来能走多远因为后面所有报表、所有高级功能都要从底层的表结构生长出来。客户主表我一般命名为customer核心字段包括customer_id主键、customer_name客户名称、customer_type个人/企业、phone手机号、email邮箱、province/city地域、industry行业、source_channel来源渠道、owner_user_id负责人、status有效/无效、created_at创建时间、updated_at更新时间。注意客户主表尽量别放过于个性化的字段个性化字段应放在“扩展属性表”中通过customer_id attr_key attr_value的结构来存储。这样当业务属性变化时不需要频繁修改表结构。联系人表customer_contact与客户主表是多对一关系一个企业客户可以对应多个联系人。联系人字段包括contact_id、customer_id、contact_name、position职位、phone、wechat、is_primary是否为第一联系人。新人最容易犯的错误是把联系人和客户合并成一张表结果一个客户有多个采购对接人时数据根本存不进去。商机表opportunity则包含opportunity_id、customer_id、opportunity_name、amount预期金额、deal_probability赢单概率、sales_stage销售阶段、expected_close_date预计成交日期、owner_user_id、created_at、updated_at。商机金额字段建议用decimal(12,2)类型不要用float或double后者在累计求和时容易产生精度误差这是财务数据的大忌。跟进记录表follow_up_record采用事件流的模式设计record_id、biz_type跟进/电话/邮件/会议、biz_id关联客户 ID 或商机 ID、content跟进内容、next_follow_time下次跟进时间、create_by、create_at。这张表会快速增长半年可能就上百万行所以务必提前规划索引策略。我的习惯是给(biz_type, biz_id, create_at)建联合索引同时定期把超过一年的历史归档到冷数据表。4.3 权限模型落地从数据范围到字段掩码技术上的权限控制说白了要在两个层面实现后端接口层面确保用户请求只能拿到授权范围内的数据前端页面层面把无权访问的按钮和字段隐藏掉。切不要以为前端隐藏了按钮后端就可以不校验安全永远以后端为准。数据权限我用“数据范围编码”来实现。用户表里配置dataScope字段取值为ALL全部、DEPT本部门、SELF本人。在后端查询客户列表时通过 MyBatis 拦截器自动拼接 SQL 条件-- 如果用户 dataScope SELF SELECT * FROM customer WHERE owner_user_id #{currentUserId} -- 如果用户 dataScope DEPT SELECT * FROM customer WHERE owner_user_id IN ( SELECT user_id FROM sys_user WHERE dept_id #{currentUserDeptId} ) -- 如果用户 dataScope ALL则不加过滤条件字段级权限则更细一些需要在配置中心维护一张“字段可见性配置表”某个角色对某个字段定义是否可见、是否可编辑。后端在返回数据时根据当前角色的配置动态剔除敏感字段。例如销售主管角色可以看到商机的成本价普通销售角色看到成本价字段时后端直接返回null或掩码星号。实现这个功能并不复杂但需要前端配合在表格渲染时根据字段权限配置动态渲染列。4.4 沟通记录与企业微信集成打通 IM 与 CRM 的最后一公里现在的业务沟通基本都在企业微信或者钉钉上如果系统里面保存的客户沟通记录还需要人工录入那这套系统用起来会非常累。我在项目里做过一次企业微信会话存档的接入核心流程是这样的企业微信管理后台开启“会话内容存档”功能配置回调 URL企业微信服务器将客户群聊和单聊的文本消息推送到回调服务回调服务对消息体进行解密和解析根据客户手机号或外部联系人 ID 关联到 CRM 客户最后把消息文本与附件归档到客户时间线同步触发关键词提醒或情绪分析可选。需要特别注意的是数据安全合规。会话存档数据包含客户个人信息企业必须告知客户并取得授权存储和访问都要有权限控制。这块不建议做成全量开放查询而应限制为“客户负责人本人查看自己客户的沟通记录主管可查看本部门管理员可查看全部”。我做上线培训时还会明确提醒销售系统不是用来监视大家而是用来保护大家——员工离职时交接的客户资产和历史沟通记录都在客户的连续性不会断。5. 实操过程中的经典问题与排查实录系统建设到了上线运维阶段真正考验技术的时刻就来了。下面我把我实操过程中踩过大坑、排过的雷以“问题现象—排查思路—解决方案”的形式整理出来这些几乎每个 CRM 项目都会遇到。5.1 数据重复与权限“串号”最先失控的大坑系统上线大概两周后我们收到了第一个严重的反馈销售 A 能通过搜索手机号看到客户 B 的信息但这个客户并不属于 A 负责。排查下来发现原因是客户数据是从三个渠道导入的分别是销售手动录入、运营 Excel 批量导入、客服工单自动建档三个渠道没有统一调用同一个“创建客户”的后端接口有的通过导入工具直接写库导致归属校验逻辑被绕过。解决方案分三步走第一步把所有客户创建入口收敛到同一个 Service 方法方法内部强制校验当前用户是否有创建客户的权限第二步做全库数据扫描找出所有owner_user_id为空或与创建人不一致的异常数据通过管理员后台批量修正第三步在数据库层面给(phone, customer_type)加唯一索引从源头避免重复数据。经过这三步客户重复率从 8% 降到了 0.5% 以下。5.2 商机金额汇总对不上都是浮点数惹的祸财务部门每个月月底都要做业绩预测但没多久就发现系统中所有商机金额汇总的总数和财务从订单系统导出的数字总有几分钱到几块钱的差异。一开始大家怀疑是统计口径不同后来才发现是表设计时金额字段用了float类型。float在计算机中以二进制表示很多十进制小数无法精确存储累计求和时误差不断累积最终导致报表数字对不上。修复方案不复杂把所有涉及金额的字段统一改为decimal(12,2)同时在应用层计算汇总时使用BigDecimal而不是double。如果你用的是 MySQL查询时顺手加上CAST(SUM(amount) AS DECIMAL(12,2))来避免隐性转换。这个小问题看似不起眼但一旦被财务部门发现信任度会大打折扣。5.3 跟进记录没人写数据变成“死库”上线三个月后我有一次空闲时打开系统翻看数据吓了一跳超过一半的客户没有一条跟进记录所谓 CRM 完全成了一个沉睡的客户名册这种数据对销售管理毫无价值。原因并不复杂业务人员觉得写跟进是一个“低价值的额外负担”。于是我做了一个关键调整把“跟进记录”变成了“销售工作流”里的一环销售完成外呼后如果客户状态标注为“有意向”系统自动弹窗提醒录入跟进内容并提供“快捷备注”模板销售未按时填写跟进的客户次日自动出现在“待跟进”列表首位系统增加跟进频率统计报表主管每周可以直观看到哪些客户长期无跟进把“跟进记录”纳入绩效考核不强制要求字数但要求必须有。调整后执行一个月跟进记录填写率从不到 30% 提升到了 75%销售自己也开始觉得系统里客户情况清清楚楚打电话之前不用再去翻聊天记录了。这个改进让我更加坚定CRM 系统只有绑定了具体的业务流程才能让团队真正用起来。5.4 报表打开慢索引缺失和 SQL 写法问题上线一段时间后业务量上来了不少用户开始反馈“客户列表页打开要等好几秒”“部门报表跑不动”。我排查后发现主要有两个原因一是follow_up_record表数据量已经超过 50 万行但很多查询条件字段上没有索引二是部分报表 SQL 在 JOIN 时写法很随意没有走主键索引全表扫描拖垮了数据库。我做的优化动作如下一是根据高频查询条件给customer表增加(owner_user_id, created_at)联合索引给follow_up_record表增加(customer_id, create_at)联合索引二是把报表查询中的COUNT(*)和SUM改成定时预聚合每 5 分钟把结果写入一张汇总表报表页直接查询汇总表三是给超过半年的历史数据建立归档表主表只保留六个月内热点数据。经此优化之前需要 5 秒的页面响应时间降到了 500 毫秒以内数据库负载也显著下降。5.5 一个隐藏很深的“定时任务重复执行”问题定时任务模块负责每天早上九点给销售推送今日待跟进客户列表某段时间销售陆续收到过重复的消息。排查后发现XXL-Job 的调度配置在一台节点下线后自动 failover 策略把同一个任务在其他节点上重新触发了一次而任务本身没有做“幂等”处理导致同一批数据被推送了两次。解决这类问题的标准做法是引入幂等标识。任务执行前先往task_execution_record表插入一条task_id business_date的唯一记录如果插入成功再执行推送业务否则说明该任务当天已执行过直接跳过。这一招在几乎所有定时任务场景里都是有效的不只是推送消息邮件通知、数据同步也适用。6. 上线后的运维与持续迭代系统稳定运行不等于项目结束真正的考验在上线后的持续运营阶段。我总结几个值得长期投入的方向。6.1 一次 “不做大需求” 的成功改造从录入系统到销售助手DeskcommCRM 上线初期团队使用率下降是常态。后来我们做的最成功的一个小改造是给销售工作台加了一个“今日优先跟进的 5 个客户”模块由系统根据客户意向等级、上次跟进时间、当前商机阶段三个维度综合计算得出。这个能力看似很简单但实际上彻底改变了销售打开系统的第一感受不再是一张冷冰冰的客户列表而是一个有判断、有优先级的“工作助手”。上线后第二周销售人均每日活跃时长翻了一倍。6.2 数据质量运营好的 CRM 是“用”出来的还要持续投入的是数据质量治理。我见过太多系统上线时数据整整齐齐三个月后就到处是空字段、脏数据。我建议建立一个月度数据质量评分机制按“字段完整度、唯一性、时效性”给各团队打分并在月度经营会上通报。这个机制不是为了罚人而是让大家意识到系统里面每一份数据都是团队资产数据质量差最后吃亏的还是自己。另外数据安全与备份意识要时刻在线。数据库要设置自动备份并定期做恢复演练重要操作删除客户、修改商机金额、批量导入必须留存审计日志后台导出功能要加水印防止敏感数据外泄。这些听起来都是小事但一旦出事就是大事。7. 写在最后的几点真实体会按照惯例最后不做什么宏观总结了就讲几点我个人在这类项目里摸爬滚打攒下来的实在感受。第一上线 CRM 最大的阻力永远不是技术而是“人心”。一线销售天然会担心系统是来监控自己的是来抢客户资源的。所以方案在启动阶段就必须让业务骨干参与共创让大家感受到“系统是帮我减少重复劳动、帮我提高成交率”而不是“公司又多了一个管理工具”。第二功能永远不要一次求全。我见过最失败的项目是老板要求第一个版本就要包含销售、客服、进销存、财务、BI 大屏全部功能结果干了八个月还没有上线。一个 CRM 系统第一版只需做“客户 跟进 商机 简单报表”就跑通一个最小闭环让业务真正用起来后面再逐步增加模块这比一上来搞一个大而全的完美系统要靠谱得多。第三数据资产这件事再怎么强调都不过分。客户数据是公司最值钱的资产之一不要在数据建模和权限设计上偷懒。系统可以慢慢迭代但数据模型一旦建错越到后期就越难改。如果你也在准备搭建或选型一套类似 DeskcommCRM 的系统建议先花一两个星期把业务角色和行为流程彻底摸一遍再来谈技术和方案。基础打牢了后面就是水到渠成的事。