Tech
目录
“学而不思则罔,思而不学则殆”，本文记录了作者在锦礼侧工作1年间遇到的思考与成长、挑战与困难，也是对过去工作的总结与反思，分享出来，希望对大家有所帮助。
京东锦礼相关
京东锦礼平台链接：https://jdjl.jd.com/#/
目前申请开通方式是在线提交申请，京东客服将尽快与您联系~
产品服务包含以下六个方面
01 引言
在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！光阴似箭，来到锦礼产品线已满一年了，这期间深刻的了解到B端不同解决方案之间的巨大差别，当然也遇到过很多挑战与困难，有业务团队认可的成就感，有眼高手低造成系统BUG的挫败感，有担任救火队长处理线上问题的紧迫感... 回顾这一年，感慨很多。本篇文章没有高屋建瓴地对整个锦礼商城的交易体系进行分析，只从一位一线开发的角度，写了写自己在这一年的工作开发中的思考和感受，以及技术上的总结反思。
我将其分为三大部分，一、关于成长 二、关于技术 三、关于沟通，欢迎指教讨论。【京东锦礼】以京东供应链为基础整合京东集团优质服务资源，面向企业客户提供的员工福利模式的服务及采购平台，主要以服务企业员工福利场景（企业客户向其员工发放福利额度，员工自主兑换采购）、市场营销场景（品牌客户向其会员营销激励，会员积分兑换采购）等多元化业务场景。欢迎集团各业务线伙伴前来合作。同时京东集团员工使用的福粒也是出自锦礼。
02 关于成长
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。说到成长，我们每个人都在不断变化，而成长就是其变化的积极面，它不单单是技能、知识等方面的提升，更多的是价值观、人生观的一些演变。这些改变会“润物细无声”般的影响我们的行为和决策，从而改变我们的生活和工作，以下我将以四个标题总结我对去年成长的一些思考总结，供大家参考。
我相信和很多同学有这一样的困惑，在同一条产品线较长时间后的得心应手，但又觉得内心空空。毕竟在我个人看来，技术的提升，一定程度上源于其场景（不同的产品，不同的系统）的限制，如果没有场景上的改变和突破，会进入逆水行舟的状态。就像罗翔老师说的：其实无论多么高大上的工作，时间一长，都会滋生无聊的感觉，都会觉得工作不过是一种重复的机械劳动。因此在23年初，我主动向我的直属leader沟通是否可以进行工作职责的一些调整。十分庆幸和感谢，我的直属 leader不仅仅与我谈心这个想法，更是站在他的经验之上，给我提供了行之有效的职业规划建议。最后在去年3月底确认从VOP产品线调整到目前的锦礼产品线，当时我的核心考虑是希望自身能从深度到广度的了解我们为企业客户提供的其他系列综合解决方案，了解更多的系统，进一步完身自己的技术体系，跳出舒适圈给自己一些新的挑战。在GPT3.5和4.0发布期间，我和其他业界的同学在一个技术群中沟通，其中有一个同学的回复让我印象深刻。“获取知识的成本越来越低，也就体现出思考的重要性越来越高”。在我看来，还要加上一句，行动的重要性更高。因为我相信大家或多或少都思考过很多东西，特别在技术领域，我们能接触到更多的先进的观点和技术，但是是否可以付诸行动，赋能业务？是否可以将思考转化为行动，这就需要我们有强大的自控力，能够坚持不懈。同时我们也需要有效管理我们的时间和精力，避免在无关紧要的事情上浪费时间。或许有同学会挑战，那意思就是我们不要思考了？如果方向错了，也不撞南墙不回头吗？当然不是，避免“我思故我在”，这里的思更多指的是分散精力&质量低下的思考。我们需要的是时刻保持清醒的头脑，专注于重要的、有价值的事务，而非大量的次要或者无关紧要的事务，同时对我们的行动也要进行批判性的思考，以确保我们的行动是有目的、有计划的，而不是盲目的。之前我阅读过这样一段话，对于技术同学来说，要时刻思考：抽离掉技术底座和业务后，你的价值是否归零。细细品尝，何尝不是，我们搭建的服务都是依托当前已经成型的平台进行的，逃脱了平台加成，剩下的才是我们自己，所以不要生出膨胀的心理。毕竟每个人的知识和经验都是有限的，我们都会有自己不擅长或者不了解的领域，不固步自封，敢于正视自己的局限性，承认自己不可能知道所有事情，这也是成长需要具备的心态之一。这里也引用一下苏格拉里的一句话，承认自己的无知，乃是开启智慧的大门。真正的大师永远怀着一颗学徒的心，这句话在我看来，不单单是谦虚，更多的还有要求我们保持开放、持续学习并接受新的观点和知识。这里的学习，不单单是关注技术本身的进步，更多的是要密切关注客户的需求和市场的变化，因为淘汰技术的永远不是技术本身，而是市场是否还需要这份技术。我们从去年Q4到现在一直面临着老平台迁移新平台的过程，众所周知，大家对于新事物的接触肯定是抵触的，毕竟需要付出额外的学习和熟悉的成本，在切换周期中的阵痛感，是难以避免的。我之前和一个区域的业务同学进行沟通，了解我们新产品使用的体验和一些痛点问题，说实话，他滔滔不绝，当然不少问题源于我刚才提到的迁移阵痛。但是同时我又问了他一个问题，“为什么不把这些你觉得痛点的问题提到产品侧转化为优化需求呢？我们每个版本迭代也在针对用户体验的专项进行优化的“。他回答到：“太麻烦了，还要写BRD，还有成本等等”。我不予置评。当然我个人也是有同类的问题，比如技术评审阶段，大多时候太专注个人，虽然不至于“各扫门前雪”的状态，但是我针对团队其他人的技术设计确实没有做到百分百的关注。以至于上线后，某位同事的方案出了问题，紧急进行救火处理。“救火英雄”固然很牛，但是带来的都是严重的教训，针对系统建设，我个人认为，如何从“救火英雄”到“防火卫士”也是需要我们为之努力的。以及各种各样我们每天遇到的不同问题，仿佛世界上永远有不完美的事情，永远有麻烦，但是唯一解决之道就是面对它，解决它。做实实在在的事情，改变我们不满的现状。当然问题可以是解决 80%，也可以是 100% 解决，这就取决于个人工匠精神和极致的追求。
03 关于技术
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。上面总结了一些自己的成长，那么聊聊关于技术，这一年里，通过不断深入了解锦礼平台，根据和VOP系统的共性及差异点，不仅将在VOP系统中优秀的经验和案例进行引入，另外也在符合锦礼业务场景下做了一些技术创新和业务赋能。在详细介绍之前，这里分享一个对于技术规划本质的一个说法，其实无论团队还是个人，我们在设定技术目标与规划技术体系时，大多都会按照体验、稳定性、效率（降本增效）等等维度去拆分，但是每个人或者说每个团队的精力和资源又都是有限的，所以如何选择，如何判断事情的轻重缓急，要回归到产品和商业本身，毕竟技术存在的价值是以实现业务价值为前提的。
针对关于技术，我大致总结了三个方面，分别为积分资产防护、技术风险规避、客户体验升级，欢迎各位技术大佬留言交流。
积分资产防护
锦礼商城作为企业业务唯一的BBC商城，也是唯一以个人消费积分（自身积分台账），企业付款进行结算的平台，积分台账中的个人账和企业账数据的一致性&准确性，以及多场景活动（主商城模式、套餐模式、单次模式、不同定价规则等）下，多样的积分结算方式，大幅的增加了资金损失的风险等级。积分的背后本身就是资金，所以无论多付少付，还是多退少退，都是涉及企业客户对于我们京东的信任问题。因此秉着做当时环境最需要的事情，我针对性的提出积分资产防护的专题。
其中主要包括：
基于此，我以提单支付流程为起点，积分台账数据为依据，全面梳理积分资产生命周期中各个环节的异常情况（发放错误、消费错误、返还错误等），增加更为严格的事前规则校验、积分平衡核对。
如：增加多层级的商品数据校验，价格变动拦截，异常积分限制，平账任务并发控制，个人支付等。
另外调研中台能力（RC规则中心，大数据平台），结合业务场景，快速落地不同层次不同维度不同时间延迟的积分对账，以此通过（京ME、邮箱、鲸盘文件等方式）及时感知资损问题的产生。实现逻辑：
消费环节以JMQ为触发媒介，规则中心为驱动，匹配不同的校验规则，触发旁支校验来核对线上逻辑。主要采用基线核对、两两核对、离线核对（T+1）快速发现异常，定位问题，同时全链路的过程数据通过VOP日志组件进行持久化和冗余备份，方便不同场景下的核对以及基于过程数据进行数据修复等，同时对于高资损风险项预置必要的应急预案，在紧急情况发生时可以及时熔断止血以保障积分资产安全。（如交易消息可选择性回放和基于幂等原则的重新消费）。
基线核对：将本地数据（本地订单快照、订单商品快照）作为预期，进行对比，可快速发现重大的资金问题。
两两核对：将上游数据（B中台数据）作为预期，进行对比，双重保险，准确度高。
离线核对：采用大数据平台任务驱动的方式通过基线以及两两核对的方式兜底来保障资金安全。
当前整个专题已经完全落地，事前规则校验天维度拦截140+次，旁支校验有效拦截和预警了70+次积分少付&多退的风险，其中还包括，春节期间检测客户账号转售的风控问题。后续积分资产防护会随着每次业务功能开发进行增量式规则配置即可，比如近期我们计划的限购规则的防护&兑换码超期的防护，防止客户提单突破限购规则或者超期的限制，我侧无及时感知的情况。
技术风险规避
在保险行业有一个著名的法则，叫做“海因里希法则”，是美国著名安全工程师海因里希提出的300∶29∶1法则。通过分析工伤事故的发生概率，为保险公司的经营提出的法则。这个法则意思是说，当一个企业有300个隐患或违章，必然要发生29起轻伤或故障，在这29起轻伤事故或故障当中，必然包含有一起重伤、死亡或重大事故。
放到我们系统中，同样适用。系统日常过程中的报警，我们需要排除无效报警的噪音干扰，针对隐患问题究其根因，按照优先级进行优化处理。当一件重大线上问题发生后，大概率往往是我们当初已经定位过或者计划处理的问题。事实证明我们一定要敬畏墨菲定律，特别在锦礼这种节日类特点的复杂场景下，已经有太多的案例来证明，如果觉得一个点隐约存在问题，那么它早晚一定会变成问题。
锦礼商城其节日类特点的场景，也造成在比如端午、中秋、春节等传统节日中，流量激增的情况，企业客户正常开放活动无问题，但是节日类期间，部分企业为提升员工幸福感，会进行一些类秒杀的活动开放，类似场景（上万人活动秒杀）的流量高峰对我们系统的稳定性就有了更高的考验。
在充分了解我们现有架构及问题后，我在技术风险规避方面，做了三个方向上的设计和实践。
限流能力建设
通过调研实践，在过去一年我们所有对外系统全面接入轻量级、标准化的限流熔断平台—泰山小盾龙，并进行活动维度限流，以此隔离每个活动之间不会互相影响，并增加ip维度限流，避免异常流量的攻击。另外通过小盾龙实时的观测告警手段和灵活的配置策略，可快速发现异常流量的活动，并根据系统现状进行快速调整。
另外毕竟涉及企业下大量C端客户的使用情况，所以我们也协同前端同学通过有效的交互设计，降低由于系统限制造成的客诉问题。至今已支持企业客户类秒杀活动80+次，无客诉产生，其中多次万人活动。“熵增定律”大家肯定都清楚， 在一个孤立的系统里，如果没有外力做功，其总混乱度会不断地增大，最后达到一个无序的状态。对于软件系统来说，“熵增”是无处不在的。比如：团队在为快速实现各种新项目，新需求，烟囱式架构，整个链路存在大量重复调用，无效调用等等，既浪费系统资源，又会在流量高峰期导致系统及底层存储稳定性问题。或许我们很多情况，首想首选的都是扩容处理，既快捷，又有效。但是我们很多时候更应该认真思考的是，如何在资源的有限性中，来解决系统的稳定性问题。因此在这一年里，我们协同团队所有同学，在需求迭代的同时，根据现有需求，梳理链路，采用提出无效调用，重复调用合并、缓存化、单条转批量等等举措进行优化，在过去一年里，我们优化涉及20+核心接口，以活动查询为例通过技术手段消除重复调用、消除不合理调用，提高流量的有效率，接口调用量降低80%。间接提升系统稳定性，规避技术风险。这个专题方向的来源背景是，我们的上游某接口出现问题返回对应异常，但是该异常本身属于业务异常，日常也会有偶发的情况，源于客户本身的属性。但是由于上游系统上线故障问题，把不该命中的客户也命中了，系统又由于其属于业务异常导致未检测到，直到客户产生客诉，我们才得知。看过我之前文章的同学，在TOB领域，本身就存在大客户的口碑效应，如果恰好头部客户碰到该问题，那么极易被放大和激化。不过所幸当时不是一个某大客户的投诉，不过也让我们开始反思类似问题如何及时发现，优先于客诉前处理。就于此，我们优先以提单为标杆，设计了业务异常水位值报警，通过DUCC配置中心、ConcurrentHashMap和Scheduled 设计了一个业务异常水位报警的配置化实现。截止目前有效监控10+起相关技术风险问题（活动配置异常、上游接口异常等），通过专人跟进报警，在未产生客诉前解决问题。另外值得一提的是，过程中，为进行不同业务异常的水位值设置，我梳理提单异常数据进行分析，发现提单收货地址有误异常天维度占比较高，并通过专项优化（智能解析地址&异步调整和删除不合规地址），提单收货地址有误异常下降95%，有效提升了客户体验。过去一年，针对在客户体验上，整个团队也做了大量的努力，比如上面刚提到的提单地址问题等等。客户体验升级，在我看来是一个持久性的话题，需要团队更多的建设者一起添砖加瓦。这里只列举一个例子，针对商城可见不可售情况的优化方案——重定位技术的二次过滤组件。一句话描述一下背景，由于我们系统涉及B 端控制台和商城，企业采购员客户在我们控制台进行商品的增删操作，其企业下的 C 端使用者在商城端进行积分消费和商品购买，但是往往由于多个系统间的异步同步问题，导致商城端页面偶发出现可见不可售情况，产生客诉。该重定向技术的二次过滤组件是为了在商城端的“最后一公里“（异步同步的时延问题各团队也在升级，提升吞吐量，保障尽可能的实时性，最后一公里指客户真实看到的页面）解决可见不可售情况，以此给予客户可见即可售的优质体验。其背后的原理是非常简单，在搜索推荐的底层嵌入二次过滤工具，该工具适用于瀑布流式的列表请求过滤。主要原理是提前拉取后续数据进行过滤和寄存，并自动补齐缺失数据，下次请求直接从寄存器中获取。通过自定义调整请求深度和步长倍数，保证接口查询的性能，减少不必要的请求次数，提高系统的响应速度和稳定性。通过过滤组件我们合并了 5处的过滤逻辑，其中主要流量入口屏蔽可见不可售商品，平均每天过滤585w次以上，根本上规避了可见不可售问题。效果图如下：一写到技术相关，不好刹车了，综上，就此停一下，其他的案例和故事，我后面再分享大家，比如我们是如何使用设计模式重构我们的价格服务，从而实现了一套可扩展性的架构，应对灵活多变的积分价格需求；如何梳理我们的任务平台架构并优化，实现降低核心库cpu30%+ -> 10%+；如何重构积分账单相关代码，来将积分逆向模块解耦，在后续项目中实现0成本开发的；如何计划引入 AIGC 能力赋能业务 等等。如大家所见，一个技术的价值，不在于你的方案多先进，框架多厉害，而是是否可以更好的满足业务需求，创造出新的东西。
04 关于沟通
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。我本身是比较纠结这个话题总结的，因为有时候我的沟通也是一地稀碎。我也有看到工作工程中，不少由于无效的沟通或者无谓的冲突导致事情没有完美做好的。因此纠结再三，我还是写下了，希望也是自己为之努力的目标，可以以这些准则来进行律己，与各位共勉。我们在各种评审会或者日常沟通中上，比如PRD评审、技术评审、测试用例评审等，每每遇到一些不客气的言论，就很容易上头，认为对方是在故意抬杠、针对自己，从而很容易情绪失控。要么，演变成双方的争吵；要么，自己在心里生闷气。这时，一个更好的思考方式可能是：与其默认对方带着恶意，不如默认对方只是单纯的沟通不畅。也就是说：不如试着告诉自己：对方也许并没有恶意，这就是他一向的说法习惯，或许只是他的无心之语，不要太在意，尽量冷静、平和的方式跟他沟通，把事情讲清楚。谨防言者无心听者有意，一来二往，导致原本正常的交流开始带着火药味，变成唇舌之争，这完全没必要。当然这并不代表很多情况下我们要妥协，因为并不排除对方确实就是故意找碴。如果你反复表达善意，换来的还是恶语相向，那么就可以考虑果断停止沟通了，做会议过程中的“终结者”。无论是和同事，还是领导，讨论问题的时候，尽量使用客观的、严谨的数据和事实，少用模糊不清的我记得、我觉得、大概是，等等。事实证明大多情况下我们也确实是栽在了这模糊的的印象和臆测中。这包括哪些呢？比如某个技术方案的设计、统计数据、ROI设定、结果验证，等等。尽量做到每个断言都有出处，都可以溯源。如果忘了具体数据怎么办？那就先查证，再发言，绝不妄加揣测。可能很多时候我们会觉得这很困难。实际上，这与其说是一种沟通方式，不如说是一种思维方式：当你要求自己在沟通中多使用数据和事实时，它就会倒逼你在生活中，有意识地多去积累数据和事实。换句话说：这是一种系统性的改变。你对自己输出的要求越宽松，那么你摄入和处理信息就会越随便；你对自己输出的要求越严格，那么你摄入和处理信息，就会更加严谨。阐述观点时讲清自己的理由和证据，谨慎对待没有理由的观点当表达一个观点的时候，尽可能的加上一句：因为...，来阐明得出这个观点的理由和证据。它们可能不是那么严谨，可能不够全面，但必须要有。如果没有，是否大家可以认为，这个观点是一厢情愿，或者在转述别人的看法？如果我们自己都没有办法为自己的观点进行辩护，又如何让别人信服它呢？比如我们在技术改造和业务需求之间的需求排期矛盾中，如果一个版本我将较多的精力放在了技术改造上，我就需要讲清这一块计划改造的理由和并在改造中做好数据上的埋点记录，不单单为了分析功能的效果，更多的是有一个充分的支点支撑你技术改造的价值。总之，要对自己的发言负责，让自己讲出去的话，都有理有据。这样，你的话才会有分量。这也是对于个人品牌的一个积累，毕竟靠谱的同学无论做什么业务会抢手受欢迎。很多情况，特别在跨团队跨部门的会议中，以及特别在面临不同工种的时候，隔行如隔山，再加上技术人员的一点点的小清高以及表达容易进入晦涩的领域。往往交流时容易陷入一个误区，那就是各说各话：你在重复你的观点，我在重复我的观点。看起来讨论得很热烈，但其实一直对不到同一个点上。为什么会出现这个问题呢？因为人都有旺盛的表达欲。相比起聆听，我们往往更喜欢表达。因此，经常是你的话还没说完，对方就以为自己已经听明白了，开始迫不及待地输出他的观点。解决这个问题的一个方法就是：在表达你的观点之前，先简要概括对方的观点，向对方确认：你想表达的是……吗？我的理解有没有问题？以此达到对齐和校准的作用，让对话双方能够基于同一个共识和目的进行交流，而不是把时间空耗在自说自话上。这是一个非常有效地把话题引导向正规，避免它转向细枝末节或钻牛角尖的方法。许多人容易犯一个错误：总是喜欢把讨论变成争论。在我这个领域，我觉得特别是在方案的讨论上，有跨部门中因为方案中某个模块因为界限模糊，或者其他原因导致无法确定由那个团队进行落地的争论，有本部门中技术方案想法不一致的争论，有是否应该遵循一些规范的争论等等。每个人都有自己的立场和看法，人与人之间看法不同，实在是再正常不过的事情了。但当许多人发现对方跟自己看法不同时，他们往往就会变得十分激动，非要争一个输赢。仿佛只要说得对方哑口无言，自己就赢了，就成功捍卫了自己的立场。但这是没有意义的。有效的讨论是什么？是为了达成共识，找到一个双方都认可的结论，而不是争一个输赢 —— 它除了给你一个虚幻的满足感之外，毫无价值。讨论的本质，是信息的交换，是让你知道除了我的看法之外，原来还可以有别的看法，它是一种对你的视角和认知的补全。不要以自己为中心去思考问题，要考虑“共赢”、“利他”，以团队和合作视角全方面立体地思考问题。我们更多的目的都应该是如何帮着一起把产品做好，要多给建议，而不是处处挑战。求同存异，想必不用我多说了吧。当然，如果当你和同事进行方案沟通中，你也拿出了上面说的的数据/理由/态度尽最大的努力去说服他，但是充分沟通还形不成共识，那么可以进行升级沟通，让领导参与最后的拍板。但是如果你和领导也发生了分歧，并且充分沟通还形不成共识时，那就先听他的。一定程度上，这不是一种媚上，而是“在必须达成一致的前提下，相信更有概率做出正确决定的那个人”。特别在于产品设计以及用户体验上，我们总是觉得自己可以站在客户和业务的角度进行换位思考，以前我也是很倾向“换位思考”这个概念，总觉得我都站在你的角度帮你想这个事情了，还要我怎样？后来我就完全否定了，原因很简单：我们永远无法想象自己不知道的事物。因此，所谓的“换位思考”，本质上，还是在用我们过往的经验和框架去思考，并没有能够真正地代入别人的角色，体会别人的感受、想法和逻辑。这种做法是没有用的。它其实是一种傲慢，是一种认为我能替代你去思考，替代你去感受的自以为是。更好的做法是：坦诚相对，直接询问对方的想法、感受和意见。做一个学徒，放低自己的姿态，去跟别人沟通，去接受别人的表达和倾诉。不要自以为是，不要越俎代庖，不要自作主张，而是聆听，接受，包容，在根据对方的想法、感受和意见进行有效的设计和开发。
05 结语
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。以上，无论成长、技术、沟通，大多都携带我个人的一些想法，文笔有限，无法完全描述，如有问题，欢迎交流斧正。谈不上洋洋洒洒，在编写这篇文章的同时，我也在不断的反思和展望，反思过去一年的自己，展望即将迈入锦礼的第二年，需要如何提升自己，如何提升系统的稳定性，如何提升产品的使用体验？你看又要面临迷茫了，不过谁的“青春”又不迷茫呢？ 欢迎志同道合的朋友交流讨论，一起打破迷茫，一同在这个充满挑战的新征程里，勇往直前。打个广告：我们是企业业务研发部的团队，我们团队通过专注于探索、研发、打造采购解决方案，将前沿技术与多年经验深度融合，致力满足企业的多种需求。同时，整合顶尖专家资源，利用前沿科技探索采购领域新知识，产出领先的行业洞见，不断推动中国企业采购行业向前发展。欢迎大家一起交流。团队急需校招人才加入，如果你熟悉JAVA技术栈，Android技术栈，或者有推荐的人才，欢迎加入我们，base 北京，邮箱：limengdong@jd.com。
打造SAAS化服务的会员徽章体系，可以作为标准的产品化方案统一对外输出。结合现有平台的通用能力，实现会员行为全路径覆盖，并能结合企业自身业务特点，规划相应的会员精准营销活动，提升会员忠诚度和业务的持续增长。▪底层能力：维护用户基础数据、行为数据建模、用户画像分析、精准营销策略的制定▪功能支撑：会员成长体系、等级计算策略、权益体系、营销底层能力支持
▪用户活跃：会员关怀、用户触达、活跃活动、业务线交叉获客、拉新促活