@WardenRU 记得是同时用几家，哪家返回快用哪家。自研这块好像也在做，进展缓慢。小米大脑和 IOT 是俩部门，略尴尬

二线互联网公司的话，搜狗？

小米语音识别用的其他家的吧

@FanError 你这说的跟 QQ 重连那个完全没关系

你只是不想硬编码条件来约束抢单量。

最简单的，累计数据，做一个数据拟合去建立模型，利用模型去确定总量和理想最大抢单量关系。

我之前 Echo 绑的 Spotify 就试过，直接说马友友 周杰伦 根本没法识别，说 YOYO-Ma Jay-Chou 能识别。

记得 Alexa 不支持中文啊，播放控制类的 skill 都是通过 NLP 对语音转文本进行抽槽位处理，Alexa 本身不支持中文的 NLP，抽槽位都困难，更没法播了。
如果单纯播英文歌，还不如改 Spotify

完全看不懂你说啥意思。

QQ 重连那个用一个带状态判断的 loop 就能搞定

只要给个初始化 gap_time = 5 秒 如果连接失败
间隔时间 = 间隔时间 * 系数 k 继续进入下一个 loop 就完了。
一旦链接成功 reset 间隔时间到 5s 不就好了

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

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

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

@cheart 可以

Sketch 做这个很方便

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

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

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

@renxiangbin 唉……

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

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

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

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

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

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

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