这种一般都是 Request 的 Head 里跟踪了 Referer，如果是非指定 Referer 就无权限访问。

全国电影票务是集中在几家票务公司的，猫眼淘票票这种分销渠道基本上都是买票务公司接口。

多语言混合语音识别国内没一家能到流畅使用水平的，虽然这种控制类还好点……

@cheart 可以

Sketch 做这个很方便

加密的目的就是要增加信息的不确定度，包括上面有人提到的行业黑话也是这样。

不在行内其实就等同于拿不到密钥，所以对无密钥的你来说黑话的不确定度要高于白话。

@renxiangbin 前辈不敢当，就是多趟了几年雷 233

@renxiangbin 唉……

其实写文档只是产品经理的一部分工作，想提高效率就多积累，写熟悉了就好了。我工作九年多，最长的产品文档写过 70 多页。光登录注册改版就做过三家的，每家的坑都不一样。最坑那家在老版设计里把注册邮箱当用户名写死了，导致老用户没法完全解绑邮箱，这都是坑……

@renxiangbin
呐，像你说到的，密码一个 TextField 涉及到的约束条件就包括长度范围（最小、最大）、字符类型（数字？英文大小写？混合？是否可以有特殊字符，如果有可使用的特殊字符有哪些？）、可见性、密码强度检查（包括长度、必须的字符混合类型和比例、是否允许与设定的用户名、填写的邮箱等其他资料有重复字符），你这有些业务根本不涉及这么复杂，有些业务就确实需要这么复杂。你怎么统一？

编程时候一般是用一个基类，然后在子类定义时候去扩充属性，你这如果也这样处理不得麻烦死……
这还只是一个密码输入框。

从根本上说，规则容易漏，最大的问题是开始需求理解以及逻辑流程分支闭环没想清楚，建议用脑图或者流程图去理顺。
流程图和脑图框架出来后跟开发去碰逻辑，按照业务现状和需要进行修补，等多方确认基本无误后再去写文档，至少能保证大方向上没问题，至于开发过程中遇到的小问题，勤和 RD 沟通，随时进行文档调整就行了。

再说回你的构想，如果业务固定，你做这套自用没问题，但广泛实用性并没有想象的那么高，理由就是我上面提到的，业务决定需求，你没法确定各家业务的情况，就不会存在银弹去解决产品需求问题。
而如果你把设想的这种东西做的过于灵活，需要在初期去设定很多规则值方便日后用，那也失去了你最初构想的意义，和每个人自己维护一套适合自己业务需要的 Axure 模板没啥差。

@renxiangbin
其实吐槽的点是，产品设计和需求文档没有银弹，包括登录密码交互提示，各类产品要求以及各家产品的现状都不一样。简单说就是业务决定需求，你直接生成的灵活性不能保证，还得手工改，到底能省多少人工我很怀疑。

而如果是普通布局和简单交互，Axure 的模板基本够用。

Axure 模板了解一下

@FFLY 网易邮箱……说多了都是泪

@alex321 所以说啊，我的意思是要分开看啊，你如果工单描述说「我用网易企业邮箱注册个推账号，无法收到个推的验证邮件」完全没问题，但如果直接说个推不发邮件，这很有可能不是事实啊

好吧，我就是轴了点 orz

http://wx2.sinaimg.cn/large/4960720fly1fo10xb14z1j21kw0c8q7d.jpg

以上的截图是我从我自己 QQ 邮箱自助查询记录里看到的
红框里的 [被拦截 (系统拦截)] 就是被邮箱服务商判断为明显垃圾邮件的记录，是直接服务商拒收的，我自己在邮箱里是看不到的。
如果是意思垃圾邮件的，邮箱服务商会标记类似红框里另一种 [垃圾箱 (系统判断)] ，这种是服务商已收取邮件到服务器，但被归类到你的垃圾邮件夹了。

这二者是有明显区别的

@alex321 收其他没问题，也不能说明个推没有发邮件。
邮件发送后邮箱服务商会先做过滤，对明显疑似垃圾邮件的发送行为会直接过滤，这甚至都没到你邮箱的垃圾箱那一步。这时候你邮箱里看不到这邮件的，但实际上人个推是发送了的。

所以说，发没发和发了收不到是两件事。前者属于个推的服务 bug，后者是个推发送服务的邮箱域名等被邮箱服务商反垃圾误伤了。

是人发了你没收到还是人没发？这是两件事

93pg2z

g5e5s4

z35a6r

i9e8m9

e2p4p2

接力