My Secret Rainbow

优惠券的设计指南

（一）：优惠券设计的整体框架

在上周的时候，我发布了一篇文章 《从红包看饿了么、美团外卖的烦恼》，没想到（自认为）引起比较大的动静，自己也很意外，只是很多人并不是在探讨“烦恼”，也确实不太好聊这个事，笔者本身也是猜测。更多的人来问我，关于优惠券的设计方案，甚至有朋友来找我要关于优惠券设计的资料。

其实文章发表的也蛮巧的，在文章发表后的当周，饿了么也将原本以异业合作为主的红包，变成了更有参与感和社交属性的类美团红包，也属于一个蛮巧合的事情。

其实在去年我的一篇文章《作为产品经理，我是如何理解产品的功能边界？》，为了引出我讲到的“边界”的概念，我借用了设计优惠券的时候的一个例子，在哪个时候，也曾经有朋友给我留言，询问我关于优惠券的设计。

说真的，当某一个朋友或读者，问我要相关优惠券或者其他的资料时，我其实蛮怕的，因为任何的产品设计的出发点，都是业务，虽然业务和业务之前有共同性，但脱离业务的设计是没有任何参考意义的，产品的设计，都是基于对业务的理解和目标的出发点而设计出来的。

为了让大家更容易理解和可参考，本文的优惠券设计指南，是基于饿了么的“下单后分享优惠券”这个业务模式而设计的。完全是我对这个业务的理解而出发，并不能代表饿了么或者美团就是这样设计的。设计仅供参考，希望大家从中学到的方法，如有雷同，纯属巧合。

本文会将红包、优惠券，统一成“优惠券”这个叫法。

 

一、业务介绍

要想设计好产品，首先要理解业务。

1. 业务介绍

饿了么优惠券的业务模式如下：

• （1）当用户在饿了么平台下单成功后，会提示可进行优惠券的分享；
• （2）用户将优惠券分享到社交平台；
• （3）自己或其他人可进行领取优惠券到账户；
• （4）在下单时，可使用优惠券，享受减免优惠；

关于分享中的设定第几个人是最大，还有发放异业合作的红包，由于是业务主线下的特点需求分支，因此不在主线范围内。

2. 数据指标

理解了业务之后，那还有一个需要了解，也就是目标，该如何监控我的效果好还是不好，是不是需要调整，那就涉及到几个目标。

• （1）分享率。也就是当用户下单后，有多少订单比率会产生分享。这是一个源头，所以需要监控好；
• （2）领取率。当我的优惠券分享出去后，假设可以供10个人领，那分享出去的有多少人领取，还有领满率多少，也就是我这优惠券发出去，有10个用户全部领取完了，这比率多少；
• （3）使用率。用户领取了优惠券后，有多少的使用率，直接决定了最终的效果，也就是转化率；
• （4）拉新数。这应该是个附带的，用户分享，势必会产生新用户的注册和下单，这个数据也可以看一下；

当然除了以上的，由于业务和公司的不同，还会有其他数据的监控，需具体情况具体分析。

 

二、框架设计

理解了业务模式，也明白了数据指标，假设需求就是实现如当前饿了么、美团外卖一样的优惠券获得。当然这里是为了简化才这样做的，各位需求方，千万不要如上面所说的：“和XXXXX一样就好了”这样的需求，任何一个产品经理都不想听到这样的话，这个在产品经理眼里，不对，不管在谁眼里，都等于没说。

本产品设计，会按照“产品的功能边界”的设计思路，进行对整个系统的设计，也就是通过构建不同的系统，进行对接式的方式，将不同的系统进行串联，最终形成完整的系统。

1. 优惠券系统

既然是一套发放优惠券的活动，那自然会有一个优惠券系统，可以对优惠券进行规则设定。

本质上，优惠券其实就是一套规则的集合体。规则一般包括：优惠金额、限制、有效期等。

（1）限制

限制里面一般基于业务不同进行不同的设定，以外卖为例，会有使用时间的限制，比如该优惠券是午餐的，那使用时间就是11点—2点；再比如会有品类的限制，比如该优惠券是下午茶的，那所选商家必须是下午茶品类的，比如奶茶店之类。

（2）优惠金额

对于优惠金额，一般是设置当前优惠券的金额，有的是固定金额，比如满减券、立减券；有些浮动金额，比如折扣券，随机券（当前饿了么、美团外卖就是随机券，领取时确定金额）。

（3）有效期

由于优惠券一般是基于活动进行发放，大多数是设定一个有效期限，比如3天、10天，起始日期已领取开始计算的模式。

对于异业合作的券，由于如果在领取时调取第三方领取接口，再进行发放，会存在比较大的风险，一般的处理时，是在优惠券系统创建一条异业合作的优惠券，然后通过导入对方券码的方式进行发放。

对于券码的导入、生成导出，如果业务需要，也会考虑进去。券码的导入时在进行发放异业合作优惠券时而设定，而生成导出，是在借助第三方发放优惠券，而增加的处理操作方式。

2. 活动系统

优惠券是规则的集合体，那活动就是将优惠券包装成一个活动，然后推给用户的实体。

一个活动一般包括优惠券、个性化、有效期三部分。

（1）优惠券

也就是该活动准备发放的优惠券，去进行对优惠券的关联。

这里对于随机券的处理上，一般会基于成本的考虑去设定总优惠金额，尽管每张券可能是随机金额，但一个活动的总的优惠金额其实已经限定了。

（2）个性化

为了吸引用户，尽管活动模板是固定的，但会提供比较大的个性化设定，可随着运营的调整进行不同内容的展示。

个性化一般包括分享个性化、内容个性化、规则个性化。

• ①分享个性化。当前主流的分享都变成了微信为主，微信也提供了可定制分享内容的方式，包括标题、描述、图片。
• ②内容个性化。便是基于活动模板进行的设定，比如头图、领取成功的弹层、按钮的跳转链接、活动说明等等，都是可以进行定制化设定的。

（3）有效期

这里的有效期一般是设定活动的有效期，去限定活动。

一般是设置一个日期区间。

 

3. 发放系统

有了优惠券，去限制使用和确定优惠规则。有了活动，作为优惠的发放实体，供用户参与。那接下来就是发放系统了，去设定活动的发放。

发放系统，是通过对不同节点的梳理，进行设置不同节点的发放活动，及对发放的限制。一般包括范围和个性化。

（1）范围

范围是指什么样的用户能够参与到活动的发放，对于像饿了么、美团外卖这样全国性的，势必会进行差异化的优惠，比如对于北山广，需求比较旺盛的， 参与度高的， 该设定什么样的运营策略，那运营策略的呈现就是活动。

范围一般会限定节点、地区、业务、用户。地区和业务相对来讲比较好了解，用户也是需要去筛选和过滤的， 比如对于会员性质的用户和非会员性质的用户，那下单后分享的活动是否进行区别对待之类的。对用户的过滤，是比较考验平台对用户的理解，和运营策略是否执行到位和准确的一个很重要的因素。

节点表示该活动是在什么样的状态下呈现，比如下单成功、注册成功等等，可以通过设定不同的节点，进行对用户推送不同活动，让用户进行参与。

（2）个性化

这里的个性化，包括两块，限制和展示。

限制，是指在当前范围下的诸如领取限制等。比如一个用户一天只能领取该范围下3个活动的优惠券。

展示，是指基于该范围，设定给用户端的展示内容，比如弹层文案、图片等。

这里要注意的是，发放系统发放的活动是基于活动系统生成之后，发放的子活动，也就是当节点发生时，产生的活动是一个子活动。

 

4. 数据系统

优惠券系统、活动系统、发放系统，是让这个业务能够跑起来，结合下单系统，可以形成一个很好的闭环。而数据系统，是完成第二部分的，也就是对目标和结果监控，获得数据的数据系统。

数据系统一般需要监控下单数、活动数、优惠券数。

• （1）下单数，是指当用户下单是符合活动发放时条件时，所产生的订单数；
• （2）活动数，是指当用户进行分享后，产生的活动数；
• （3）优惠券数，是指用户领取的用户数量，使用可以当做优惠券的一个状态进行标记；

拉新数量，可以通过在优惠券数的统计中，对手机号或者会员ID进行标记是否为新用户的方式产生；

那么在最开头提到的四个数据：分享率、领取率、使用率、拉新率，变可通过数据系统进行计算和展示。

分享率 = 活动数 / 下单数 * 100%；

领取率 = 优惠券数 / （活动数 * 每个活动参与数）* 100% 每个活动参与数即表示每个活动允许多少用户领取；

使用率 = 优惠券使用数 / （优惠券数 – 优惠券退券数） 如果优惠券可以退券，一般会把退券数刨除，也有是不刨除，主要看业务需求；

拉新数 = 领取过优惠券的用户中，标记为新用户的数量。

对于固定计算规则的数据，可以通过图表等更友好的方式进行展示，方便查看。

 

三、 总结

优惠券系统，确定优惠券的规则；活动系统，发放优惠券的实体；发放系统，设定活动的发放规则；数据系统，记录行为中产生的数据。四个系统相互配合，构成一套完整的优惠券活动发放系统。

当然，这里的“系统”不代表是个很庞大的内容，只是用“系统”这个词，来代替相关直接的区隔。

以上前期的思考和梳理的过程，后面的文章， 将深入到每个系统中去，去讲述该如何设计和思考，优惠券本身就是一个比较庞大，而且和业务有很强关联性的产品，借助一篇文章时很难讲完的。

最后，也特别说明一下，由于优惠券本身与业务的关联度非常强烈，业务的不同，会直接影响到整个系统的设计，特别是越细节的内容，越与业务紧密相连。该文章是以饿了么下单之后的分享红包这个业务出发，设计的优惠券整套系统，敬请知悉。

 

（二）：优惠券系统篇

优惠券系统，作为整套系统的基础和核心，将首先进行设计。当然了，考虑到业务的不同，我在这里做了一个过滤。一方面是优先将框架讲清楚；另一方面就是基于当前饿了么、美团外卖的下单之后分享的红包作为业务基础，去讲解我理解的设计。

在上一篇文章中，讲到的优惠券系统，包括三部分：优惠金额、限制、有效期。那接下来，将分别去讲述。

 

一、优惠金额

作为优惠券，作用自然是对金额进行优惠，那优惠的额度，自然是关注的焦点。从目前的情况来看，设置可归纳为两种，固定金额和浮动金额。

1、固定金额

固定金额言外之意就是这张优惠券的金额是固定的， 不会随着订单的金额进行变化，比如满减券、立减券，都可算作固定金额。

固定金额属于比较基础性的方式，也是目前比较通用的方式。
满减券意思是满足多少金额才享受减免，比如满30减5元；立减券则没有金额限制（订单金额必须高于减免金额。若订单金额小于减免金额，则使用后，金额为0），使用就会减免。

2、浮动金额

浮动金额，就是这张优惠券的金额是浮动的，在某一种情况下会产生不同的金额。引起优惠券价格的因素，一般分为订单和行为。

（1）订单

订单一般也是比较常见的一种，比如折扣券，就是基于订单进行确定的优惠金额。比如发放的8折券，就代表按订单金额的80%计算，那20%就是优惠金额，但具体的优惠金额会随着订单的价格不同而不同。
当然了，这里的订单价格，一般会分为两种，实际需支付金额和订单金额。由于在部分业务场景中，存在对部分产品或服务进行不计入优惠的范畴，所以会进行区分。

目前，折扣券也是属于比较流行的一种券优惠模式。

（2）行为

行为是指当用户进行了某种行为后，会基于行为进行判断优惠金额。饿了么、美团外卖的第X领取红包最大，就是这样的模式。

但“基于行为进行判断”这个逻辑一般会放到活动系统，而非在优惠券系统。

对于行为类的， 优惠券系统一般会设置优惠区间，设置两档的优惠区间，大的优惠区间和小的优惠区间。然后当有了行为后，基于逻辑后的结果，进行确定是取大的优惠区间，还是小的优惠区间。然后再确定优惠金额。

 

二、限制

这里的限制，是指非金额的限制，金额的限制，在“优惠金额”中已经设置。而这里的限制，是业务层面的限制。

这里拿饿了么、美团外卖的业务举例子。业务层面的限制包括：地区、使用时间、品类……
比如地区，会限制使用地区，发放上海地区的券， 无法在杭州的门店使用；比如使用时间，会限制券的使用时间，该券是下午茶券，从14:00-17:00 ，那在此时间段之外的无法使用；比如品类，会限制品类，比如该券是下午茶券，那只是是购买奶茶、甜点等品类时进行使用；

限制有很强的业务属性，完全体现了对业务的理解和深入程度，也从侧面能反映出运营的精细化程度。

 

三、有效期

关于有效期的设定，会有两种，一种是固定的有效期，设定一个是时间段；另一种是设定一个有效数，比如30天，一般是从领取之日起30天内有效。
饿了么、美团外卖一般是发放的第二种，从领取之日起多少天有效的方式，可以增加紧迫感，促进用户下单。

 

四、后台设计

上面的内容，只是基于优惠券系统的三部分进行讲述的，属于理论，如果你将按照这个进行设计后台，那将是完全错误的一件事情。

对思路的分析，是要从整体进行归纳和分析，而对于系统的设计，而是从一张优惠券的角度进行设计。 这是完全不同的两个角度。

那回归到一张优惠券，其实就是多个规则的组合，那就需要进行对规则进行梳理，然后集中到一个优惠券上。

后台的设计，会从饿了么的产品出发， 基于APP内看到的内容进行分析，而非官方设计，仅供参考。

1、规则

从上面讲述到的优惠金额、限制、有效期，其实都是规则的一部分。

从目前对业务的理解和优惠券的设计，大致上分了以下几大限制：金额规则、品类规则、品牌规则这三类。

（1）金额规则

金额规则，主要是确定优惠的模式，包括满减、立减、折扣三类。是固定金额，还是区间金额，会当做一个属性进行设定，基于设定，来确定折扣金额。区间金额不会出现在折扣类型上，只会出现在满减、立减上。

（2）品类规则

从饿了么APP来看，品类包括：果蔬生鲜、甜品饮品、美食、商超便利、早餐、夜宵、鲜花、医药、帮买帮送、准时达这几个品类。

由于品类作为公共内容，可不再维护范围内，品类规则，只是需要基于业务需要，对品类进行包装和再分组，形成符合的要去，比如鲜果超市红包，则品类会包含果蔬生鲜、商超便利两个品类。

（3）品牌规则

这个可以算作是品类的一个细分，当然也可以独立拿出来进行设定。

对于连锁类的比如麦当劳，一个品牌下面包含很多的门店，但无法通过品类限制，则可通过品牌进行规则设定。这里与品类规则是个互斥的，也就是设定了品牌，就无法设定品类，而且品牌是单选，不建议无法进行多个选择。

关于品牌规则， 可在设定一张优惠券时进行设定。可不进行规则设定。

2、优惠券

设定好了规则，就要开始设定优惠券了。此时的优惠券，完全是基于规则的整理和组合了。

3、之后

难道这样就结束了吗？显然并没有，这里只是将规则也好，优惠券也罢，只是将新建做了一个界面的设计，其他的还包括列表的展示、筛选条件的选择、编辑时的可编辑部分……都是需要后续基于业务进行逐渐丰富的。本文就不在赘述了。

 

五、异业合作

那对于异业合作的是怎么样的一个模式？

其实异业合作就是将合作方作为优惠券的发行方，进行对优惠券的发放，一般的步骤是：

那么对于优惠券需要做的就是：1、区分是自己券还是合作券；2、发谁的券；

那么单单从优惠券的角度，是加了一个模式，当模式为合作券时，需要同时增加合作方选择。

当然了，既然是合作方的券，那就需要在列表中增加一个导入功能，可支持导入合作方的券，同时可单独设置导入的规则，比如提醒、提醒警戒数等等。

素材下载地址： http://pan.baidu.com/s/1slodnVR 密码：h429

 

（三）：活动系统

一、 框架

在优惠券设计的整体框架中，已经进行了讲述，活动系统包括：优惠券、个性化、有效期三部分。

下面就分别对三个部分进行讲述。主要是优惠券、个性化，有效期会放到活动里进行讲述。

1.1 优惠券

既然是发放优惠券的互动，那自然核心的就是优惠券，在上一篇文章中，已经把优惠券的系统进行讲述完成，这里默认已经创建了符合的优惠券，那接下来的工作就是，将优惠券与活动进行关联，用来配置活动及该活动所发放的优惠券。

当然在创建活动时，是可以进行新增和添加的， 但在编辑时，则无法进行修改。

1.2 个性化

活动的个性化包括基础设置、分享设置、页面设置。

1.2.1 基础设置

基础设置包括活动名称、活动链接（考虑到与合作方的因素，对链接需要支持自定义）、有效期、活动状态。

但对于编辑时，则活动链接无法修改，活动名称、有效期、活动状态均可进行调整；

1.2.2 分享设置

分享设置，主要是对页面的TDK（页面标题、页面描述、关键词）的设置，或者如果需要支持微信分享，则包括分享标题（及页面标题）、分享图标、分享描述（页面描述）。

在编辑时，除了微信分享的支持选项无法修改，其他均可修改。

1.2.3 页面设计

这里主要是对活动的页面进行设置，主要是及基于选择的活动模板进行设置，目前有很多第三方的工具或者其他的，可以通过可视化的方式进行配置，这里只是做了一个包含，也就是一个活动页面包含的部分：活动Banner、领取弹层图片、活动图片（可配置参数，表示点击可弹出领取弹层）、成功页Banner、成功页按钮。

1.3 汇总

如果将优惠券、个性化的设置，放入到一个页面，就会组合成活动的设置页面。

活动页面，可进行新增、详情查看、编辑修改功能。

1.4 列表

在点击进入“活动设置”后，会展示当前已经新增的活动列表信息。

可通过活动名称、活动ID、活动状态进行查询。

也会展示包括活动ID、活动名称、优惠券名称、有效期、创建时间、状态的列表。

活动ID、活动名称是可进行点击的，活动ID可点击进入活动的详情查看。活动名称，则会新开的方式，进入活动链接，可预览活动。

 

二、领取发券逻辑

除了在活动系统中，进行配置活动页面及活动关联优惠券之外，活动系统还有个重要的逻辑，那就死领取发券逻辑。

领取发券逻辑，是基于优惠券的发券逻辑，一个活动中存在不同类型的优惠券（会尽量保证一致），因此是基于活动、优惠券进行的领取发券逻辑会分为三种：固定金额、浮动金额、浮动金额-某个最大（饿了么、美团外卖当前采用的模式）

2.1 固定金额

固定金额的发券模式相比来讲比较简单，属于基础的逻辑。

2.2 浮动金额

浮动金额相较于固定金额，在领取时，增加了一个获取优惠金额的流程。基于领取后剩余的优惠金额，在优惠券设置的最大值到最小值之前抽取整数进行作为优惠券的金额，这里类似于微信的红包。

2.3 浮动金额 – 某个最大

该发券逻辑，在活动生成之时，会随机确定某一个顺序领取的为金额最大。然后再领取时，会判断是否是最大顺序的领取，若是，则在优惠券设置中从中值到最大值的区间取值；若不是，则在优惠券设置中，按最小值到中值的区间取值。

 

三、 产品原型方案

在优惠券系统篇，只是简单的画了一下部分规则的新建的视图。

链接： http://hm2acs.axshare.com/#p=项目说明

密码：pmupday

点击可查看优惠券系统、活动系统的产品原型，后续的发放系统、数据系统，也会更新在里面，可收藏进行查看。当然，由于该方案只是出于产品原型方面，并没有与技术进行评审可行性及贴合业务的设计，同时这是个比较完整的项目，不太建议直接当产品原型，给到技术进行评估，据我的估计，整套完成的工作量还是比较大的。

 

（四）：发放系统篇

一、纠正

在体验饿了么、美团外卖的时候，会有如下的几种情况：

1. 饿了么的分享后的优惠券从原本的固定金额的券，变成了浮动金额的券。尽管文章中有过设计，但缺乏系统的考虑，并不完善；
2. 在领取时会有发现，大多数的活动是一个用户只能领取一次，而有些活动是一个活动可以多次发放；

因此为了解决上面的情况，对之前的《活动系统篇》做了调整。

增加用户标签

在对活动的设置中，会增加“用户标签”的选择，用户标签可根据不同的业务、公司对用户的标签进行设定。

当然，“用户标签”这次做了单独的处理，独立于四个系统之外，属于公共的部分，等下文会进行讲述。

发券的设置

发券的设置是指两部分，一个是固定、随机的发券模式的设置；另一个是每个人限制领取的次数限制。

发券设置分为固定券发放、随机券的发放。若是随机券的发放模式，会在发放是，随机确定哪一个顺位领取的是最大。

领取发券的逻辑

增加了用户标签、发券设置、每个人限制后，领取发券的逻辑自然需要调整。

在进入活动时，会增加用户标签的判断（范围是基于该活动所关联的发券逻辑进行限制的，下文会讲到），在领取时会增加领取次数的判断。

详情可查看原型方案，附带“—10.15修改”为本次的修改部分，可查看红框标记。

 

二、增加公共部分

在讲述《发券系统篇》之前，需要先讲两个公共的设置：用户标签、范围设置。

之所以现在讲，一个主要的原因是，《优惠券的设计指南》系列文章，是在我脑中有个整体的框架，然后边写边细化，同时会与读者交流，同时会更加深入的了解业务和整个优惠券，其实我对优惠券的认识，也在不断的深入中，深入后就会发现，有很多的遗漏，用户标签、范围设置，就是两个比较大的遗漏。包括上面提到的纠正的部分，也算是遗漏。

用户标签

这一块是我在细化发放系统时，考虑到的。在活动的最初策划阶段，会基于用户标签这个属性，对活动的性质进行确定， 比如新用户活动，那针对的用户标签就是新注册的用户。

由于用户标签是个很复杂的东西，这里只是基于优惠券这个，提到了几个点：会员、未下单时间、新用户。

会员只是这个活动是不是只针对会员的一次活动，通过在活动上进行区分，提高会员的价值，是一个很常见的运营会员的模式。

未下单时间只是已经多久未下单的用户，可通过这个进行唤起沉睡用户，策划激活沉睡用户活动的一个很关键的标签。

新用户，就是针对于新用户的，比较好理解一些。

范围设置

范围设置，是对地区的进行设置，通过人为的将区域进行划分，从而达到对某一地区或某一种地区的划分。

 

三、发放系统

在整体框架设计中，已经将做了说明，发放系统分为：范围、个性化。

范围就是公共的范围的设置，个性化更多的是对该发放规则下的活动的设置。

发放的设置包括：基础设置、活动设置、展示设置。

基础设置

基础设置包括发放名称、有效期、范围、状态。是基础性的设置。

范围的设置，就是范围设置的下拉筛选。

活动设置

这里是发放与活动的管理，一个发放只能管理一个活动。

除了活动，还包括节点、每个人限领次数。

节点是指在什么情况下进行发放或推送活动，一般由于每增加一个节点，就会涉及开发，这里只能只是筛选已增加的阶段。

每个人限领次数，是指每天该发放规则下一个用户的限领次数。

展示设置

展示设置只是在有活动推送的情况下， 比如提示分享时，展示的文案和标题，这里只是设置：标题、图片。可根据实际情况进行不同的规划。

四、原型查看

若要查看完整的《优惠券的设计指南》系列文章的产品原型，可访问：

链接： http://hm2acs.axshare.com/#p=项目说明
密码：pmupday

 

 

（五）：数据系统篇

一、数据

数据的作用本文就不再赘述了，讲一讲与优惠券相关的数据。

数据系统主要是对活动、优惠券的发放，进行统计，从而查看活动效果。

主要监控的数据为：下单数、(发起)活动数、优惠券数。

而分享率、领取率、使用率、拉新率，则可通过计算获得：

• 分享率 = 活动数 / 下单数 * 100%；
• 领取率 = 优惠券数 / （活动数 * 每个活动参与数）* 100% 每个活动参与数即表示每个活动允许多少用户领取；
• 使用率 = 优惠券使用数 / （优惠券数 – 优惠券退券数） 如果优惠券可以退券，一般会把退券数刨除，也有是不刨除，主要看业务需求；
• 拉新数 = 领取过优惠券的用户中，标记为新用户的数量

这里将数据系统分为了三部分：活动数据、优惠券发放、图形化。

活动数据

活动数据只是产生的活动的数据情况，通过查看，可看活动的分享情况、活动的领取情况，是活动维度的数据查看。

优惠券发放

优惠券发放是优惠券维度的数据查看，包括优惠券的领取情况、使用情况、使用记录等信息。

图形化

图形化是借助系统化的方式，通过图表的形式将数据进行展示，可方便快速的查看数据的走势情况。

二、总结

数据具有极强的业务关联性和运营需求，因此，只是该数据部分的产品方案，仅供参考，具体还是以最终业务的需要进行设计和展示。

三、原型查看

若要查看完整的《优惠券的设计指南》系列文章的产品原型，可访问：

链接： http://hm2acs.axshare.com/#p=项目说明
密码：pmupday

 

作者：蓝胖子