http://73520.com

「APP刷评论」app实名绑卡平台告诉你如何写好移动端产品文案

提及「设计类型」,app实名绑卡平台以为我们凡是会想到的是UI类型、交互类型。而文案呢?在我们凡是的认知里,应该是运营而不是设计师最终认真的领域,更没有出类型的须要性。但我小我私家的习惯是,既然呈此刻我的设计稿上、由我提出的文案方案,就起码要先过本身这关,无论最终在职责上归谁认真敲定,那是另一码事。文案毫不是在交互文档上随便示意一下,然后写一句「最终文案由运营确定」就甩锅给运营完事了,况且许多时候运营更擅长对业务指标把关,并不垂青(可能说不如产物、交互设计师擅长)从用户体验的维度去把关。所以,呈此刻本身设计稿上的文案,主动官僚把握在本身手里才踏实。

同时,在我看来文案设计类型的须要性一直被忽视了。一个产物的设计稿大概从初稿到定稿之间的修改周期很是长,依据评审结论也有许多变数,设计师本日出几个页面、来日诰日改几个页面,由于小我私家语言习惯,以及出稿子时思路和脸色差异,文案很难从始至终保持一致、不出过错。

所以在定稿交付开拓前,按照统一的文案设计类型,从头对文案彻底Review一遍是很有须要的。就像这次用作案例的观念方案「一站」,在按照类型举办一次细致的走查后,对比一个月前分享出来的版本也完善了许多文案上的细节。

在我的相识范畴内,今朝很少看到有对文案类型的总结与分享。只有Ant Design在其组件文档中对文案留意事项有一个相对系统的总结,在思考的系统性上较量有进修代价,在此前用于事情上的文案自查中给了我很大的辅佐。但个中许多结论是基于一款金融处事行业的Web端中靠山产物拟定的,小我私家以为有许多不必然合用于这个范畴之外的产物。

因此,一直但愿通过一篇文章,对移动端产物的文案设计类型举办一次合用面更广的梳理和总结——一份文案设计类型需要包罗哪些条理的内容?有哪些原则需要在类型中写明?

本文将以一个基于地铁查询东西的脸色分享平台「一站」为例,其间也会穿插一些其他APP中的例子,尽大概具体先容文案设计中大概呈现的常见问题范例,以及一份较量完善的文案设计类型由哪些内容组成。

app实名绑卡平台汇报你如何写好移动端产物文案

文章内容:文案设计类型的三个条理

1. 一致性类型:词汇一致、句式一致、动作点与目标页面标题一致、时间表达类型、数字一致性类型、标点一致性类型。

2. 精确性类型:用词精确、不累赘、不缺失、不恍惚。

3. 更高的要求——懂用户:从用户视角描写代价、正确利用人称代词、让用户听得懂、汇报用户Why not。

一. 一致性类型

1. 词汇一致

词汇的一致是文案一致性的基础,但汉语的博大博识,造成在同一个表达中大概换许多词都是说得通的。因此,词汇是在设计进程中最容易呈现前后纷歧致的处所,也是交付前Review的重点。

一些用词、句式的选取上,大概未必我选择的就是最好的,但照旧那句话,统一了就比不统一要好一百倍。这篇文章也不是为了细究A和B哪个表达更好,只是探讨统一类型的须要性和组成内容。

量词

故事的量词,统一用「篇」,而不是「段」、「条」。

△ 一站 · 故事的量词统一用「篇」

✔️ 「22 篇故事」

❌ 「22 段故事」,「22 条故事」

搜索功效的量词,统一用「条」,而不是「个」。

量词的例子尚有许多,在此不做过多罗列。个中,有些量词的一致化需要思量切合产物场景和糊口习惯,与语文角度大概会有所差别。app运营平台

好比,车站的量词统一选用「个」,而不是「座」,因为糊口中口语中实际上很罕用「座」来形容地铁站,且在本产物的情况中并不需要强调其具象修建层面上的寄义。

名词

名词的一致化对产物统一心智的形成很是重要,尤其是一个产物中最焦点的观念界说。

譬喻,「一站」中最焦点的内容元素就是用户宣布的地铁「故事」,这是必然要统一的词汇,不能混用「文章」、「评论」等等词。

动词

动词的一致化不必然要用一个词去涵盖全部,因为凡是都要同时应对两种语境(可能说时态)。

以内容宣布为例,是表达「正在发出」的行为,照旧对「已经宣布了的内容」的告诉?

对「正在发出」的行为,凡是呈此刻宣布表单、宣布后的Toast提示中。有关表单宣布的词汇,在「宣布」之外的近义词许多,如「确认」、「确定」、「提交」、「生存」、「完成」、「颁发」。在本产物的语境中,最公道的应该选用「宣布」。

△ 一站 · 暗示正在发出的行动统一用「宣布」

✔️ 「宣布」,「宣布中…」,「故事宣布乐成」,「评论宣布乐成」

❌ 「完成」,「提交中…」,「故事颁发乐成」,「评论提交乐成」

对「已经宣布了的内容」的告诉,用「宣布了」自然不算错。但按照平台调性的差异,可以有许多比冷冰冰的「宣布了」更有温度感的选择,譬喻我在类型中选择的「写下了」,一方面与「故事」更搭调,一方面也能同时合用于Timeline和用户数据展示等多个场景。

△ 一站 · 暗示已宣布的内容统一用「写下了」

✔️ 「写下了故事」,「写下了 2 篇故事」

❌ 「宣布了故事」,「颁发了 2 篇故事」

其他词汇一致性类型示例

「评论了 Qinsman 的故事」,而不是「回覆了 Qinsman 的故事」、「评价了 Qinsman 的故事」

「开往长湴」,而不是「去往长湴」、「开向长湴」

「点赞」,而不是「喜欢」

「TA」,而不是「他」或「她」(这是思量到产物的场景并没有强化用户性别认知的需求,且需要思量到用户配置性别保密的环境。相反,假如是一款主打异性生疏人社交的产物,那么显示的奉告用户性此外意义就大了许多)

「车站」,而不是「地铁站」、「站点」(有个破例是「站点列表」页,因为需要强调List中的每个站在「车站」这一统称下的个别性,因此仅在此页面利用「站点」)

「专题」,而不是「话题」、「主题」

「故事宣布乐成」,而不是「故事宣布完成」

「相互存眷」,而不是「彼此存眷」

这里看一些其他APP中的例子。app运营数据报表

△ 左:抖音 右:网易云音乐

抖音中呈现了「赞」和「喜欢」两个近似观念的混用,给别人点「♥️」,在本身的主页显示的是「喜欢」,而被别人点「♥️」,显示的则是「获赞」。网易云音乐中,两个并列的Tab「动员态」和「宣布视频」,一个动词是「发」一个是「宣布」。

app实名绑卡平台汇报你如何写好移动端产物文案

我不太清楚这两组词汇混用的背后是否确实有本质的区别,亦或仅仅是文案上的不同。

但作为用户角度,这样的纷歧致让我的领略本钱增加了。2个词汇对用户而言是2个差异的观念,尤其是许多APP中「赞」和「喜欢」就是两个完全差异性质的成果,因此我在第一次利用时会试图揣摩这两者之间的区别在哪。刷talking data

下面这个例子更浮夸一点。电信营业厅APP里,在4个一级Tab中都要求用户登录,但4个Tab别离用了4种差异的提示文案「请登录~」、「当即登录」、「登录」、「顿时登录」。

△ 电信营业厅:八门五花的登录提示语

2. 句式一致

一站的正常流界面中涉及句法的类型问题较少,主要呈此刻种种中间态和异常流的提示语中。

同类提示语保持一致,制止每个处所写的句子都完全纷歧样,最终导致表达同样寄义的提示语在整个产物中变得八门五花。

✔️ 「你已经输入了故事内容,确定放弃并返回吗?」与「你已经输入了评论内容,确定放弃并返回吗?」句式一致

❌ 「你已经输入了故事内容,确定放弃并返回吗?」混用「确定放弃已输入的评论并返回吗?」

语序一致:「图片上传失败」、「故事宣布失败」保持一致的「名+动+状」布局,制止混用「动+名+状」之类的其他语序,如「上传图片失败」、「宣布故事失败」。

✔️ 「图片上传失败」与「故事宣布失败」句式一致

❌ 「图片上传失败」混用「宣布故事失败」

其他产物中,在正常流界面中也需要留意语序一致。好比不要一会写「流量充值」一会写「充值流量」。应用宝下载安装

建行APP的「全部投资理工业品」页,对所有同时涉及动词和名词的进口文案而言,险些都回收的是「名+动」,如「资金投资」、「债券投资」、「黄金积贮」、「外汇交易」,唯有「署理贵金属」是「动+名」,雷同的词组最好照旧做好句式一致。

△ 建行「全部投资理工业品」页的进口文案

3. 动作点与目标页面标题一致

这一点较量容易领略,但在页面设计中,改来改去很容易进口和跳转页面的文案就对不上号了。个中最常见的一种环境是漏掉前缀可能写了多余的前缀:

「编辑精选」跳转到了「精选」

「我的动态」跳转到了「动态」

「关于一站」跳转到了「关于我们」

「配置」跳转到了「系统配置」

豆瓣首页的「豆瓣日历」点击后跳转到的页面标题却是「豆瓣市集」,直到看到下面的新品首发才气大白「豆瓣日历」是正在出售的新品中的一种,然而豆瓣市集里显着还同时出售其他许多商品,这个进口名称的配置很容易让用户一头雾水。

△ 豆瓣首页「豆瓣日历」的跳转去向是「豆瓣市集」

虽然,由于进口字数受限,因而不得不缩减字数表达的环境是个破例,在没有其他更好步伐的环境下也只能接管。

4. 时间表达类型

内容宣布时间的表达上,凭据所处场景自己是否有时间属性,需要分成两个大的范例举办思量。

方案A. 全部回收绝对时间

合用景象:普通内容List、内容结尾节点。

在普通内容List中,内容以热度、运营计策或其他逻辑抉择排序,自己没有时间相关的属性,此时宣布时间没有须要也不符适用「X小时前」这样的相对时间举办表达。譬喻首页本周热门、编辑精选、车站详情页的故事List、热门评价区等。

同时,在内容欣赏链路的结尾节点(如内容详情页和对话气泡列表),需要担保所有关于内容的信息不能呈现缺失,因此在这里需要详细的汇报用户这篇内容宣布的绝对时间。

△ 一站 · 左:普通内容List 右:内容详情页

在这两种环境下,用绝对时间表达越发符合:

方案B. 相对时间+绝对时间

合用景象:Timeline、动静列表等。

在Timeline、动静列表等自己包括了时间逻辑(凡是是默认倒序)的列表中,可以在近期内按相对时间表达,向用户转达更直观的时间观念,减轻用户对时间的思考负荷。一站中典范的例子,如我的保藏、我的存眷Feeds、我的动态、最新评价区等。百度手机app推广

至于「近期」到底以什么界限分别,没有绝对的对与错,按产物实际需要拟定类型就可以。常见的分别界限是昨天、前天和一礼拜前。

△ 一站 · 左:我的动态 右:动静

对上述范例的时间信息,近期内回收相对时间表达,更早的则依旧回收绝对时间表达:

留意:月、日为1位数字时,前方不补0;小时、分钟为1位数字时,前方补0凑齐2位。

另外有一个非凡环境,以车站故事的「最热/最新」两个Tab为例,那么固然「最新」理论上切合基于车站维度聚合、定时间倒序的内容流,应该回收方案B。但为了担保同一信息布局下的两个Tab中时间泛起名目一致,名目上仍与「最热」一同回收方案A。

△ 一站 · 车站故事的两个Tab

5. 数字一致性类型

涉及数字的表达统一利用阿拉伯数字,这点在设计进程中一般不会堕落,但数字是1的时候偶然大概会习惯性地写成「一」,如地铁线路表达为「1号线」而不是「一号线」;新评论提醒的Push文案是「您的故事收到了1条新的评论」,而不是「您的故事收到了一条新的评论」。

△ 一站 · 统一用阿拉伯数字表达

✔️ 「1号线」,「您的故事收到了1条新的评论」

❌ 「一号线」,「您的故事收到了一条新的评论」

但一站中存在一些破例环境,如我的故事中的时间戳、专题卷数等需要突出时间陈迹、汗青感的场景下,仍用汉字数字表达。因此,数字名目标类型要按照产物实际需要,明晰非凡用例。

△ 一站 · 非凡环境确有需要时,仍用汉字表达

另外,数量信息前后有汉字时需要加空格,让写死的文本字段和变量字段的区隔更清晰。留意像「7号线」等不表达数量信息的阿拉伯数字无需补加空格。另外,系统Push中的数量(如「你的故事收到了3条新的评论」)也不需要补加空格,因为Push只是一串文本,不需要思量作为界面元素泛起时的清晰性。

△ 一站 · 数量前后有汉字时增加空格

✔️ 「写下了 4 篇故事」

❌ 「写下了4篇故事」

6. 标点一致性类型

地铁线路或地铁站前方需要注明都市时:由居中点号「 · 」区隔,留意不是小数点,前后各有1个空格。例:「广州 · 4号线」,「重庆 · 杨家坪」。

换乘站的所属线路表达:由「/」区隔,前后无空格。例:「4号线/7号线」。

括号类型:统一利用英文半角括号,前方或后方有汉字时,增补1个空格隔断。例:「故事 (1292篇)」。

超长截断:回收半个省略号「…」(1个全角字符),而不是整个省略号「……」(2个全角字符)或「…」(3个半角英文小数点)。

不利用句号等标点的环境:页面主标题与副标题、输入提示符、输入框下方或输入框中的提示文字、Toast中、弹窗或Actionsheet的选项、按钮中。确有须要需要利用逗号和问号时除外。

这里看两个我们常用APP里的例子。友盟刷量留存

△ 左:豆瓣小我私家配置页 右:百度舆图的评分弹窗

豆瓣在编辑小我私家主页的生日配置中,贴心地汇报用户生日配置并不会被用于本性化推荐,但这类说明文案是没有须要加句号的。

再看看百度舆图的评分弹窗,这里且岂论没用屡次就弹出来要求用户评分的弹窗是否公道,就那3个硕大的叹息号已经足够让许多用户心惊肉跳一下了。

二. 精确性类型

1. 用词精确

这一点应该是文案的根基要求,用词呈现禁绝确、不切适用户习惯的现象,容易增加用户的领略本钱,给用户留下不专业的印象。

举个简朴的例子,短信验证登录是此刻移动端登录的标配途径,用户对「验证码」的观念已经成立了相当安稳的心智,99%的产物中也都遵循了这一老例叫法,而偏偏有一些APP里会沿用本身奇特的术语,好比电信营业厅的登录页中就叫「随机码」(这里就不说「获取随机码」和「请输入随机要码」纷歧致的问题了)。

△ 电信营业厅APP

这个叫法能不能说得通?虽然能,验证码虽然是随机的数字组合。但能说得通并不代表用词精确,精确与否是由海内用户的惯有认知抉择的。

再好比,喜马拉雅APP在编辑资料时,「简介」是一个输入项,提示「未填写」是正确的,而「生日」和「地域」都是选择器,不该该提示「未填写」而应该是「未选择」。

△ 喜马拉雅 · 编辑资料页

另外,在toB的企业打点应用、金融付出相关、行业配景专业性较强的应用中,更需要留意一些行业术语的利用精确。这点在之前做过的B端企业应用、项目打点平台里感伤颇多,不外因为行业配景离日常糊口较量远,这里就不外多举例了。

2. 不累赘

在文案复查中寄望是否存在冗余的文字,团结页面场景和上下文已经完全能领略的信息无需反复表达,只会徒增用户的信息认知承担和领略本钱。

譬喻在「一站」的故事宣布页面中,车站和所属专题的选择提示文案,就不消再强调其与故事之间逻辑从属干系。右上角的「宣布」按钮,也不消强调是「宣布故事」。

△ 一站 · 故事宣布

✔️ 「请选择」

❌ 「请选择故事对应的车站」,「请选择故事所属的专题」

在专题首页中,在List内容显然全都是「故事」的前提下,3个Tab也无需再次强调「故事」的字眼。

△ 一站 · 专题首页

✔️ 「最新」/「最热」/「精选」

❌ 「最热故事」/「最新故事」/「精选故事」

下面看看这两个阅读压力很是大的页面。

△ 左:懂球帝 右:同花顺

懂球帝的扫一扫界面中,在扫码框上方写了两行文案「打开网页版懂球帝登录页面,扫描二维码登录」和「扫描懂球号二维码,存眷懂球号」,先容了懂球帝里扫码的2个场景。

而实际上用户之所以在懂球帝打开了扫一扫,绝大大都环境下都是已经处于这2种场景中的个中一种。绝大大都用户进入扫一扫,并不是闲的没事,app下载量,进来后看到“哦,本来这两个处所可以用到”,然后去找码扫。而是先有扫码场景,才会进入扫码成果。

那么在扫一扫界面,又有什么须要再汇报用户「你必然是从这两个处所来的」呢?只能徒增用户的阅读负荷。有乐趣的伴侣可以去看一下其他APP的扫码页面,提示文案一般只有下方那句「将二维码放入框内即可自动扫描」,这才是不熟悉操纵的用户在这个界面大概需要看到的文案。

同花顺的模仿炒股大赛报名页更浮夸一点,在每个输入框的占位提示符中反复了「请输入您的」这5个字,一下子让整个页面布满压迫感。同时,主动作按钮文案也略显冗余,「报名」两个字足够说清的工作,却用了「提交资料 报名参赛」8个大字。

3. 不缺失

对动作点文案而言,要做到将动作点背后的要害信息精确、直接的让用户知晓。

譬喻,在搜索栏的提示占位符中清晰的奉告用户可以搜索的数据范例。

△ 一站 · 搜索提示文案

✔️ 「搜索车站 故事 用户等」

❌ 「搜一搜」、「点击举办搜索」、「点击开始搜索」

异常流报错时,该当汇报用户可行的办理方案,或产物为用户做了哪些挽救法子。

譬喻,A用户宣布了一条故事,app下载量,他的挚友B用户看到后,用几分钟写了评论,但点击宣布之前A用户已经删了这条故事。那么此时应该在Toast中汇报B用户评论宣布失败的详细原因。

Toast:

✔️ 「评论宣布失败,该故事已被宣布者删除,内容已生存至系统剪贴板」

❌ 「评论宣布失败」

空态中,也需要汇报用户下一步可以采纳的动作,而不是纯真的汇报用户这里为空。这实际上不是一个文案问题,而是一个产物和交互的问题。

空态的处理惩罚做得好的产物,很容易让用户对平台的「关心」发生好感度,同时遵循文案的引导,去执行对产物有利的操纵,告竣业务方针与体验的双赢。譬喻存眷列表的空态就很是适合引导拉新。

△ 一站 · 存眷的人(空态)

✔️ 「存眷大概感乐趣的人」+「可能 我要邀请我的挚友」

❌ 「还什么都没有哦」、「这里空空如也」、「还没有存眷任何用户」

4. 不恍惚

制止「大概」、「或许」、「也许」,会为用户凭添一层「到底是不是」的判定,除非在一些异常流中技能上确实无法判定问题地址。

三. 更高的要求——懂用户

1. 从用户视角描写代价

在动作点相关的文案中,以用户的视角描写「你」能通过此操纵到达的目标,为用户缔造符合的念头,帮其解除担心息争决障碍,都能更好的撬动用户去执行,而不是从「我们」(产物团队)的角度强迫用户接管某一设定。

以一站在「配置」中的绑定邮箱和动静推送开关的说明文案为例:

缔造念头、解除担心:「绑定邮箱可以让你快速找回可能重置暗码,一站不会向你发送任何告白或营销邮件」

办理障碍:「动静推送的开启和封锁,需要前往iPhone系统配置的“通知”中举办配置」

在这方面做得很是棒的一个APP就是Keep,其体验路径的各个环节都能感觉到产物在文案上的用心水平。这里只举一个注册流程的例子。在注册完成后,Keep会但愿用户完善一些根基资料,对产物来说有利于制订本性化的用户分层计策,也是很有代价的数据沉淀。在这个流程中,Keep充实通过文案向用户转达了完善资料对他的代价(找到符合的练习、实现健身方针、依据身高设计练习内容等),并解除了用户对隐私数据的担心(安心,Keep不会泄露你的资料)。

△ Keep

反例是Airbnb,同样是但愿用户完善资料,「我的」页的资料完善进度条下方的文案是这么写的:「我们要求每一位爱彼迎用户在观光或出租之前提供一些详细信息,此刻就来完善这一步吧」。

△ Airbnb · 「我的」

我不清楚一个以体验优秀著称的产物里怎么会呈现这样一句文案,也许是直译导致的问题。

改成「在观光或出租之前提供一些详细信息,可以在爱彼迎得到更好的处事与体验」,是不是同样的意思,听起来舒服多了?

2. 正确利用人称代词

一站的人称代词类型:默认利用「你」,同时,在语境公道、语法通顺的环境下尽大概利用「我」取代「你」。

文案中常用的人称代词是第一人称「我」和第二人称「你」、「您」。第二人称的泛用性较量好,可以适合绝大大都的语境和句式。但在公道的环境下,可以尽大概多的实验以第一人称「我」为主体举办描写,对比第二人称,更能让用户感觉到本身在产物体验进程中的主导职位。

至于第二人称顶用「你」照旧「您」,并没有绝对的对与错。对年青群体为主的社交、电商、娱乐型的APP,用「你」更符合、对用户更具亲和力和自由平等的感受,「您」反而让用户感想与产物之间有一种莫名的间隔感。反过来,银行、金融处事产物中,其线下场景「宾至如归」的立场在线上也需要浮现,此时用「您」越发符合,面向企业用户的B端产物也同理。

第一与第二人称没有绝对的黑白之分,「你」和「您」也没有绝对的对与错,但至少需要在APP级举办统一,并不料味着可以随意混用。我们看看移动营业厅APP中的两个例子:

△ 移动营业厅

左图是处事页,在处事项的副标题中,同屏呈现了「修改您的宽带暗码」和「打点我的发票昂首」,假如说两个混用的还算常见,再看看三个一起混用的局势有多杂乱——右图的移动体检页面,共呈现了3个涉及人称代词的文案:「存眷您每一分权益」、「套餐合不符合,我来汇报你」、「本日,我4G了吗?」。

我到底是「我」照旧「你」照旧「您」?一会「你」一会「您」,你到底是尊重我照旧不尊重我?

3. 让用户听得懂

按照用户群体的差异,在文案中只管利用他们能听得懂的词汇。譬喻,在社交、娱乐、电商、出行等用户群体较广的应用中,用语该当尽大概简朴、直白。制止利用一些设计师可能产物团队内部本身大白,而用户听起来一头雾水的词语。

就举一个最简朴的例子,12306买票时,这个「受让人」和下面那句温馨的绕口令,请问有谁能在事先不相识「受让人」是什么意思的环境下看懂?

△ 百姓级APP——12306

另外,假如用户的行业属性很强,就要吃透他们的语言习惯。

譬喻,在一个工程项目打点应用中,「专业认真人」是工程业内用户很是熟悉的一个专有名词,代表暖通、电气、给排水等各个专业的牵头人,这时用互联网行业的「主管」之类的词语就贻笑大方了。

同样,在一个专业理工业品里,一些金融术语该直接利用时就直接利用,写得太白话反而影响专业性。

4. 汇报用户Why not

让用户始终有选择的权利,让他在体验中感受到可控性长短常重要的。以系统配置为例,只管担保呈此刻配置中的选项都是答允用户选择的。而如确有须要不答允用户选择时,应该汇报用户其背后的原因。

譬喻,知乎不答允用户封锁已存眷话题的推送,Airbnb不答允用户封锁邮箱推送。而对比之下,Airbnb就比知乎表明得清楚许多。

△ 无法选择时汇报用户Why not 左:Airbnb 右:知乎

结语

文案设计类型的三个条理中,一致性是文案质量的基石,精确性是晋升质量的要害,懂用户则是更高的要求。

这里举的一些反例大概整体看来都长短常优秀的产物,好比Airbnb和网易云音乐,大概有伴侣会以为是不是太吹毛求疵了?仿佛例子中的这些问题对体验也无感冒雅,也不影响产物全局的评价和口碑。

说实话,假如作为一般用户,大概确实不需要寄望到这些细节,或许率对焦点体验也没有出格大的影响。

但作为一个具有职业敏感性的产物设计师来说,我以为对细节的追求照旧要有的。换位思考一下,在本身的产物中,能通过类型和走查制止的问题,为什么必然要用「无感冒雅」去开脱呢?

从项目标责任心上说,文案设计是设计师和运营要各自从用户体验和业务指标上配合把关的。而从设计师小我私家的生长来讲,每多把稳一次文案细节,将来出雷同方案时就可以信手拈来地给出高质量的文案,对本身在项目中造就更类型、更严谨的设计习惯也大有裨益。

app实名绑卡平台汇报你如何写好移动端产物文案

郑重声明:本文版权归原作者所有,转载文章仅为传播更多信息之目的,如作者信息标记有误,请第一时间联系我们修改或删除,多谢。