为什么要领域建模80后程序员都知道，我们国家“系统分析师” 和“系统设计师” 是两种不同的职称考试，也就是分析系统和设计系统不是同一个人，这种割裂导致需求分析的结果无法直接进行设计编程，而能够进行编程运行的代码却扭曲需求，导致客户运行软件后才发现很多功能不是自己想要的，而且软件不能快速跟随需求变化。DDD则打破了这种隔阂，提出了领域模型概念，统一了分析和设计编程，使得软件能够更灵活快速跟随需求变化。后端技术演变服务器后端发展主要可以分成三个阶段： UI+DataBase的两层架构，这种面向数据库的架构没有灵活性。 UI+Service+DataBase的多层SOA架构，这种服务+表模型的架构易使服务变得囊肿，难于维护拓展，伸缩性能差，这也是Spring Web 应用的最大败笔. DDD+SOA的事件驱动的CQRS读写分离架构，应付复杂业务逻辑，以聚合模型替代数据表模型，以并发的事件驱动替代串联的消息驱动。真正实现以业务实体为核心的灵活拓展。 以DDD为代表的开发模式与传统CRUD或过程脚本或者面向数据表等在开发效率上比较如下： 对于事务脚本，一句话概括就是“上手容易，维护难”DDD革命DDD革命性在于，领域模型准确反映了业务语言，而传统J2EE或Spring+Hibernate等事务性编程模型只关心数据，这些数据对象除了简单setter/getter方法外，没有任何业务方法，被比喻成贫血模式。以银行账号Account为案例，Account有“存款”，“计算利息”和“取款”等业务行为，但是传统经典的方式是将“存款”，“计算利息”和“取款”行为放在账号的服务AccountService中，而不是放在Account对象本身之中。我们不能因为用了计算机，用了数据库，用了框架，业务模型反而被技术框架给绑架了，就像人虽然是由母亲生的，但是人的吃喝拉撒母亲不能替代，更不能以母爱名义剥夺人的正常职责行为，如果是这样，这个人就是被母爱绑架了。DDD不是银弹软件的世界里没有银弹，是用事务脚本还是领域模型没有对错之分，关键看是否合适。就像自营和平台哪个模式更好？答案是都很好，所以亚马逊可以有三方入住，阿里也可以有自建仓嘛。实际上，CQRS就是对事务脚本和领域模型两种模式的综合，因为对于Query和报表的场景，使用领域模型往往会把简单的事情弄复杂，此时完全可以用奥卡姆剃刀把领域层剃掉，直接访问Infrastructure。我个人也是坚决反对过度设计的，因此对于简单业务场景，我强力建议还是使用事务脚本，其优点是简单、直观、易上手。但对于复杂的业务场景，你再这么玩就不行了，因为一旦业务变得复杂，事务脚本就很难应对，容易造成代码的“一锅粥”，系统的腐化速度和复杂性呈指数级上升。目前比较有效的治理办法就是领域建模，因为领域模型是面向对象的，在封装业务逻辑的同时，提升了对象的内聚性和重用性，因为使用了通用语言（Ubiquitous Language），使得隐藏的业务逻辑得到显性化表达，使得复杂性治理成为可能。接下来，让我们看一个银行转账的实例，对比下事务脚本和领域模型两者编程模型的不同。DDD初体验银行转账事务脚本实现在事务脚本的实现中，关于在两个账号之间转账的领域业务逻辑都被写在了MoneyTransferService的实现里面了，而Account仅仅是getters和setters的数据结构，也就是我们说的贫血模型：public class MoneyTransferServiceTransactionScriptImpl implements MoneyTransferService { private AccountDao accountDao; private BankingTransactionRepository bankingTransactionRepository; . . . @Override public BankingTransaction transfer( String fromAccountId, String toAccountId, double amount) { Account fromAccount = accountDao.findById(fromAccountId); Account toAccount = accountDao.findById(toAccountId); . . . double newBalance = fromAccount.getBalance() - amount; switch (fromAccount.getOverdraftPolicy()) { case NEVER: if (newBalance < 0) { throw new DebitException("Insufficient funds"); } break; case ALLOWED: if (newBalance < -limit) { throw new DebitException( "Overdraft limit (of " + limit + ") exceeded: " + newBalance); } break; } fromAccount.setBalance(newBalance); toAccount.setBalance(toAccount.getBalance() + amount); BankingTransaction moneyTransferTransaction = new MoneyTranferTransaction(fromAccountId, toAccountId, amount); bankingTransactionRepository.addTransaction(moneyTransferTransaction); return moneyTransferTransaction; } }上面的代码大家看起来应该比较眼熟，因为目前大部分系统都是这么写的。需求评审完，工程师画几张UML图完成设计，就开始向上面这样怼业务代码了，这样写基本不用太费脑，完全是面向过程的代码风格。有些同学可能会说，我这样写也可以实现系统功能啊，还是那句话“just because you can, doesn’t mean you should”。说句不好听的，正是有这么多“没有追求”、“不求上进”的码农才造成了应用系统的混乱、败坏了应用开发的名声。这也是为什么很多应用开发工程师觉得工作没意思，技术含量低，觉得整天就是写if-else的业务逻辑代码，系统又烂，工作繁琐、无聊、没有成长、没有成就感，所以转向去做中间件啊，去写JDK啊，觉得那个NB。实际上，应用开发一点都不简单也不无聊，业务的变化比底层Infrastructure的变化要多得多，解决的难度也丝毫不比写底层代码容易，只是很多人选择了用无聊的方式去做。其实我们是有办法做的更优雅的，这种优雅的方式就是领域建模，唯有掌握了这种优雅你才能实现从工程师向应用架构的转型。同样的业务逻辑，接下来就让我们看一下用DDD是怎么做的。银行转账领域模型实现如果用DDD的方式实现，Account实体除了账号属性之外，还包含了行为和业务逻辑，比如debit( )和credit( )方法。// @Entity public class Account { // @Id private String id; private double balance; private OverdraftPolicy overdraftPolicy; . . . public double balance() { return balance; } public void debit(double amount) { this.overdraftPolicy.preDebit(this, amount); this.balance = this.balance - amount; this.overdraftPolicy.postDebit(this, amount); } public void credit(double amount) { this.balance = this.balance + amount; } }而且透支策略OverdraftPolicy也不仅仅是一个Enum了，而是被抽象成包含了业务规则并采用了策略模式的对象。public interface OverdraftPolicy { void preDebit(Account account, double amount); void postDebit(Account account, double amount); } public class NoOverdraftAllowed implements OverdraftPolicy { public void preDebit(Account account, double amount) { double newBalance = account.balance() - amount; if (newBalance < 0) { throw new DebitException("Insufficient funds"); } } public void postDebit(Account account, double amount) { } } public class LimitedOverdraft implements OverdraftPolicy { private double limit; . . . public void preDebit(Account account, double amount) { double newBalance = account.balance() - amount; if (newBalance < -limit) { throw new DebitException( "Overdraft limit (of " + limit + ") exceeded: " + newBalance); } } public void postDebit(Account account, double amount) { } }而Domain Service只需要调用Domain Entity对象完成业务逻辑即可。public class MoneyTransferServiceDomainModelImpl implements MoneyTransferService { private AccountRepository accountRepository; private BankingTransactionRepository bankingTransactionRepository; . . . @Override public BankingTransaction transfer( String fromAccountId, String toAccountId, double amount) { Account fromAccount = accountRepository.findById(fromAccountId); Account toAccount = accountRepository.findById(toAccountId); . . . fromAccount.debit(amount); toAccount.credit(amount); BankingTransaction moneyTransferTransaction = new MoneyTranferTransaction(fromAccountId, toAccountId, amount); bankingTransactionRepository.addTransaction(moneyTransferTransaction); return moneyTransferTransaction; } }通过上面的DDD重构后，原来在事务脚本中的逻辑，被分散到Domain Service，Domain Entity和OverdraftPolicy三个满足SOLID的对象中，在继续阅读之前，我建议可以自己先体会一下DDD的好处。领域建模的好处DDD最大的好处是：接触到需求第一步就是考虑领域模型，而不是将其切割成数据和行为，然后数据用数据库实现，行为使用服务实现，最后造成需求的首肢分离。DDD让你首先考虑的是业务语言，而不是数据。DDD强调业务抽象和面向对象编程，而不是过程式业务逻辑实现。重点不同导致编程世界观不同。面向对象封装：Account的相关操作都封装在Account Entity上，提高了内聚性和可重用性。多态：采用策略模式的OverdraftPolicy（多态的典型应用）提高了代码的可扩展性。业务语义显性化通用语言：“一个团队，一种语言”，将模型作为语言的支柱。确保团队在内部的所有交流中，代码中，画图，写东西，特别是讲话的时候都要使用这种语言。例如账号，转账，透支策略，这些都是非常重要的领域概念，如果这些命名都和我们日常讨论以及PRD中的描述保持一致，将会极大提升代码的可读性，减少认知成本。说到这，稍微吐槽一下我们有些工程师的英语水平，有些神翻译让一些核心领域概念变得面目全非。显性化：就是将隐式的业务逻辑从一推if-else里面抽取出来，用通用语言去命名、去写代码、去扩展，让其变成显示概念，比如“透支策略”这个重要的业务概念，按照事务脚本的写法，其含义完全淹没在代码逻辑中没有突显出来，看代码的人自然也是一脸懵逼，而领域模型里面将其用策略模式抽象出来，不仅提高了代码的可读性，可扩展性也好了很多。如何进行领域建模初步建模领域建模这个话题太大，关于此的长篇大论和书籍也很多，比如什么通过语法和句法深入分析法，在我看来这些方法论有些繁琐了。好的模型应该是建立在对业务深入理解的基础上，如果业务理解不到位，你再怎么分析句子也不可能产出好的模型。就我自己的经验而言，建模也是一个不断迭代的过程，所以一开始可以简单点来，就采用两步建模法抓住一些核心概念，然后假设一些业务场景走查一下，再写一些伪代码验证一下run一下，看看顺不顺，如果很顺滑，说明没毛病，否则就要看看是不是需要调整一下模型，随着项目的进行和对业务理解的不断深入，这种迭代将持续进行。那什么是两步建模法呢？也就是只需要两个步骤就能建模了，首先从User Story找名词和动词，然后用UML类图画出领域模型。是不是很简约？简约并不意味着简单，对于业务架构师和系统分析师来说，见功力的地方往往就在于此。举个栗子，比如让你设计一个中介系统，一个典型的User Story可能是“小明去找工作，中介说你留个电话，有工作机会我会通知你”，这里面的关键名词很可能就是我们需要的领域对象： 小明是求职者。 电话是求职者的属性。 中介包含了中介公司，中介员工两个关键对象。 工作机会肯定也是关键领域对象； 通知这个动词暗示我们这里用观察者模式会比较合适。然后再梳理一下领域对象之间的关系，一个求职者可以应聘多个工作机会，一个工作机会也可以被多个求职者应聘，M2M的关系，中介公司可以包含多个员工，O2M的关系。对于这样简单的场景，这个建模就差不多了。当然我们的业务场景往往比这个要复杂，而且不是所有的名词都是领域对象也可能是属性，也不是所有的动词都是方法也可能是领域对象，再者，看的见实体好找，看不见的、隐藏的，需要深入理解业务，需要“无中生有”才能得到的抽象就没那么容易发现了，所以要具体问题具体对待，这个进化的过程需要我们有很好的业务理解力，抽象能力以及建模的经验（知道为什么公司的job model里那么强调技术人员的业务理解力和抽象能力了吧）。比如通常情况下，价格和库存只是订单和商品的一个属性，但是在阿里系电商业务场景下，价格计算和库存扣减的复杂程度可以让你怀疑人生，因此作为电商中台，把价格和库存单独当成一个域（Domain）去对待是很必要的。另外，建模不是一个一次性的工作，往往随着业务的变化以及我们对业务的理解越来越深入才能看清系统的全貌，所以迭代重构是免不了的，也就是要Agile Modelling。模型重构模型统一建模的过程很像盲人摸象，不同背景人用不同的视角看同一个东西，其理解也是不一样的。比如两个盲人都摸到大象鼻子，一个人认为是像蛇（活的能动），而另一个人认为像消防水管（可以喷水），那么他们将很难集成。双方都无法接受对方的模型，因为那不符合自己的体验。事实上，他们需要一个新的抽象，这个抽象需要把蛇的“活着的特性”与消防水管的“喷水功能”合并到一起，而这个抽象还应该排除先前两个模型中一些不确切的含义和属性，比如毒牙，或者卷起来放到消防车上去的行为，这就是模型的统一。统一完的模型也许还不叫大象鼻子，但是已经很接近大象鼻子的属性和功能了，随着我们对模型对象、对业务理解的越来越深入、越来越透彻，我们会不断的调整演化我们的模型，所以建模不是一个one-time off的工作，而是一个持续不断演化重构的过程。模型演化世界上唯一不变的就是变化，模型和代码一样也需要不断的重构和精化，每一次的精化之后，开发人员应该对领域知识有了更加清晰的认识。这使得理解上的突破成为可能，之后，一系列快速的改变得到了更符合用户需要并更加切合实际的模型。其功能性及说明性急速增强，而复杂性却随之消失。这种突破需要我们对业务有更加深刻的领悟和思考，然后再加上重构的勇气和能力，勇气是项目工期很紧你敢不敢重构，能力是你有没有完备的CI保证你的重构不破坏现有的业务逻辑。实体在演变 以开篇的银行账号为例，假如一开始账号都有withdraw（取钱）的行为，此时只需要在Account上加上withdraw方法就好了。 - 演变一：随着业务的发展，我们需要支持ATM账号和Online账号，而Online账号是不能withdraw的，此时最差的做法是保持模型不变，而是在withdraw方法中判断如果是OnlineAccount则抛出异常。这种简单的代码堆砌可以满足业务功能，但是其业务语义完全被掩盖。更好的重构方法应该是将withdraw抽成一个接口IWithdrawable。 - 演变二：好的，没有什么可以阻挡业务对变化的向往。现在公司出于安全性的考虑，为新开通的ATMAccount设置了取款上线，超过则不能支取。简单做法是在IWithdrawable中再加入一个setLimit行为，可是我们并不想改动影响到老的账号业务，所以更好的重构应该是重新写一个ILimitedWithdrawable接口，让其继承老接口，这样老的代码就可以保持不变了。 通过上面的例子，我们可以看到领域模型和面向对象是一对孪生兄弟，我们会用到大量的OO原则，比如上面的重构就用到了SOLID的SRP（单一职责）和OCP（开闭原则）。在实际工作中，我的确也有这样的体会，自从践行DDD以后，我们采用OOA和OOD的时候比以前明显多了很多，OO的能力也在不断的提升。引入新抽象 还是以开篇的转账来举个例子，假如转账业务开始变的复杂，要支持现金，信用卡，支付宝，比特币等多种通道，且没种通道的约束不一样，还要支持一对多的转账。那么你还是用一个transfer(fromAccount, toAccount)就不合适了，可能需要抽象出一个专门的领域对象Transaction，这样才能更好的表达业务，其演化过程如下： 聚合根聚合根（Aggregate Root）是DDD中的一个概念，是一种更大范围的封装，把一组有相同生命周期、在业务上不可分隔的实体和值对象放在一起考虑，只有根实体可以对外暴露引用，也是一种内聚性的表现。确定聚合边界要满足固定规则（Invariant），是指在数据变化时必须保持的一致性规则，具体规则如下 ：根实体具有全局标识，最终负责检查规定规则 聚合内的实体具有本地标识，这些标识在Aggregate内部才是唯一的 外部对象不能引用除根Entity之外的任何内部对象 只有Aggregate的根Entity才能直接通过数据库查询获取，其他对象必须通过遍历关联来发现 Aggegate内部的对象可以保持对其他Aggregate根的引用 Aggregate边界内的任何对象修改时，整个Aggregate的所有固定规则都必须满足还是看银行的例子，Account（账号）是CustomerInfo（客户信息）Entity和Address（值对象）的聚合根，Tansaction（交易）是流水（Journal）的聚合根，因为流水是因为交易才产生的，具有相同的生命周期。 最后提醒一下，聚合根是一个逻辑概念，主观性很强，所以在建模过程中很容易产生分歧，因此在日常工作中千万不要教条，把握住一条主要原则，我们的最终目的是为了业务语义显现化，如果因为聚合根把模型弄的晦涩难懂那就得不偿失了使用领域服务什么是领域服务有些领域中的动作，它们是一些动词，看上去却不属于任何对象。它们代表了领域中的一个重要的行为，所以不能忽略它们或者简单地把它们合并到某个实体或者值对象中。当这样的行为从领域中被识别出来时，最佳实践是将它声明成一个服务。这样的对象不再拥有内置的状态。它的作用仅仅是为领域提供相应的功能。Service往往是以一个活动来命名，而不是Entity来命名。例如开篇转账的例子，转账（transfer）这个行为是一个非常重要的领域概念，但是它是发生在两个账号之间的，归属于账号Entity并不合适，因为一个账号Entity没有必要去关联他需要转账的账号Entity，这种情况下，使用MoneyTransferDomainService就比较合适了。 识别领域服务，主要看它是否满足以下三个特征： 服务执行的操作代表了一个领域概念，这个领域概念无法自然地隶属于一个实体或者值对象。 被执行的操作涉及到领域中的其他的对象。 操作是无状态的。领域服务陷阱在使用领域服务时要特别当心，一个比较常见的错误是没有努力为行为找到一个适当的对象，就直接抽象成领域服务，这会使我们的代码逐渐转化为过程式的编程，一个极端的例子是把所有的行为都放到领域服务中，而领域模型退化成只有属性的贫血DO，那DDD就没有任何意义了。所以一定要深入思考，既不能勉强将行为放到不符合对象定义的对象中，破坏对象的内聚性，使其语义变得模糊。也不能不加思考的都放到领域服务中，从而退化成面向过程的编程。应用服务和领域服务如何划分在领域建模中，我们一般将系统划分三个大的层次，即应用层（Application Layer），领域层（Domain Layer）和基础实施层（Infrastructure Layer），关于这三个层次的详细内容可以参考我的另一篇SOFA框架的分层设计。可以看到在App层和Domain层都有服务（Service），这两个Service如何划分呢，什么样的功能应该放在应用层，什么样的功能应该放在领域层呢？ 决定一个服务（Service）应该归属于哪一层是很困难的。如果所执行的操作概念上属于应用层，那么服务就应该放到这个层。如果操作是关于领域对象的，而且确实是与领域有关的、为领域的需要服务，那么它就应该属于领域层。总的来说，涉及到重要领域概念的行为应该放在Domain层，而其它非领域逻辑的技术代码放在App层，例如参数的解析，上下文的组装，调用领域服务，消息发送等。还是银行转账的case为例，下图给出了划分的建议： 边界上下文领域实体是有边界上下文的，比如Apple这个实体不同的上下文，表达的含义就完全不一样，在水果店它就是水果，在苹果专卖店它就是手机。所以边界上下文（Bounded Context）在DDD里面是一个非常重要的概念，Bounded Context明确地限定了模型的应用范围，在Context中，要保证模型在逻辑上统一，而不用考虑它是不是适用于边界之外的情况。在其他Context中，会使用其他模型，这些模型具有不同的术语、概念、规则和Ubiquitous Language的行话。那么不同Context下的业务要互相通信怎么办呢？这就涉及跨边界的集成了，集成不能是简单的HSF调用，而是需要一个专门的防腐层（Anti-Corruption）做转化，其意义主要有以下两点：和外部依赖解耦 避免外部领域概念污染Context内部实体语义 以我们真实的业务场景举个例子，比如会员这个概念在ICBU网站是指网站上的Buyer，但是在CRM领域是指Customer，虽然很多的属性都是一样的，但是二者在不同的Context下其语义和概念是有差别的，我们需要用AC做一下转换： 业务可视化和可配置化好的领域建模可以降低应用的复杂性，而可视化和可配置化主要是帮助大家（主要是非技术人员，比如产品，业务和客户）直观地了解系统和配置系统，提供了一种“code free”的解决方案，也是SaaS软件的主要卖点。要注意的是可视化和可配置化难免会给系统增加额外的复杂度，必须慎之又慎，最好是能使可视化和配置化的逻辑与业务逻辑尽量少的耦合，否则破坏了原有的架构，把事情搞的更复杂就得不偿失了。 在可扩展设计中，我已经介绍了我们SOFA架构是如何通过扩展点的设计来支撑不同业务差异化的需求的，那么可否更进一步，我们将领域的行为（也叫能力）和扩展点用可视化的方式呈现出来，并对于一些不需要编码实现的扩展点用配置的方式去完成呢。当然是可以的，比如还是开篇转账的例子，对于透支策略OverdraftPolicy这个业务扩展点，新来一个业务说透支额度不能超过1000，我们可以完全结合规则引擎进行配置化完成，而不需要编码。 所以我能想到的一种还比较优雅的方式，是通过Annotation注解的方式对领域能力和扩展点进行标注，然后在系统bootstrap阶段，通过代码扫描的方式，将这些能力点和扩展点收集起来上传到中心服务器，然后再通过GUI的方式呈现出来，从而做到业务的可视化和可配置化。大概的示意图如下： 有同学可能会问流程要不要可视化，这里要分清楚两个概念，业务逻辑流和工作流，很多同学混淆了这两个概念。业务逻辑流是响应一次用户请求的业务处理过程，其本身就是业务逻辑，对其编排和可视化的意义并不是很大，无外乎只是把代码逻辑可视化了，在我们的SOFA框架中，是通过扩展点和策略模式来处理业务的分支情况，而我看到我们阿里很多的内部系统将这种响应一次用户请求的业务逻辑用很重的工作流引擎来做，美其名曰流程可编排，实质上往往是把简单的事情复杂化了。而工作流是指完成一项任务所需要不同节点的连接，节点主要分为自动节点和人工节点，其中每个人工节点都需要用户的参与，也就是响应一次用户的请求，比如审批流程中的经理审批节点，CRM销售过程的业务员的处理节点等等。此时可以考虑使用工作流引擎，特别是当你的系统需要让用户自定义流程的时候，那就不得不使用可视化和可配置的工作流引擎了，除此之外，最好不要自找麻烦。我曾在银行工作过，亲眼看见过IBM是怎么忽悠银行使用它们的BPM系统，然后把系统弄的巨复杂无比，所以我对工作流引擎的印象并不好，当然也不排除有用的特别合适的案例，只是我还没看见，如果有看见的同学麻烦告诉我一声，学习一下。因为我们现在还没有让用户自定义流程的诉求，所以使用工作流引擎并不在我们现阶段的考虑范围之内。好文推荐栏网络基础SpringMVC工作原理Spring4+Spring MVC+MyBatis整合思路文件上传的三种方式

　　Rockstar 是一门图灵完备的动态编程语言。设计这门语言的目的是能够像写歌词一样开发计算机程序。它的歌词风格主要受 20 世纪 80 年代重摇滚和电力民谣的影响。　　为什么会有 Rockstar？　　如果我们让 Rockstar 成为一门真正的（虽然毫无意义）编程语言，招聘人员就不会在招聘时对“摇滚开发者”颇有微词。　　另外，它很有趣，一门基于歌词编译的编程语言很值得我们一试。　　我们还可以用它做贴纸，谁不想在自己的笔记本电脑上贴上“认证 Rockstar 开发者”这样的贴纸呢？　　Rockstar 语言规范　　注释　　我们不建议在 Rockstar 程序中使用注释。这可是 Rockstar，所以要让阅读代码的人自己从中寻找意义。但如果你坚持要使用注释，那么请把注释放在括号里。是的，这意味着你不能在算术表达式中使用括号，如果有复杂的表达式，要将它们分解为多个子句。　　Tommy was a lean mean wrecking machine. (initialises Tommy with the value 14487)　　变量　　在 Rockstar 中，有两种声明和使用变量的方式。　　公共变量由一个关键字（a、an、the、my 或 your）和关键字后面的变量名组成，变量名只能包含小写 ASCII 字母 a-z。　　特定变量由专有名词组成，专有名词是指任何不是保留关键字并以大写字母开头的单词。特定变量名称可以包含空格，只要每个空格后跟一个大写字母。可能有一些开发人员会创建类似 Customer ID、Tax Rate 或 Distance In KM 这样的变量名称，不过我们建议你使用惯用的变量名称，如 Tommy、Gina、Doctor Feelgood、Mister Crowley、Kayleigh、Tom Sawyer、Billie Jean 和 Janie。　　Eleanor Rigby、Peggy Sue、Black Betty、Layla 和 Johnny B Goode 在 Rockstar 中也都是有效的变量名，尽管严格来说它们算不上是惯用的。　　与 Ruby、Python 和 VBScript 一样，Rockstar 的变量是动态类型的，所以不需要在使用前进行声明。　　代词　　关键词 it、he、she、him、her、them、they 总是指向最近命名的变量。　　类型　　Rockstar 使用了与 ECMAScript 非常相似的类型系统，不过 undefined 听起来不是非常摇滚，所以我们使用 mysterious 替代它。　　Mysterious——任何未赋值的变量，使用关键字 mysterious 表示。　　——空值类型，在计算时等于 0 或 false。关键字 nothing、nowhere 和 nobody 是 的别名。　　Boolean——具有 true 和 false 值的逻辑实体。（关键字 maybe 和 definitely maybe 被保留下来，可能在未来会用到）。　　right、yes 和 ok 是 true 的有效别名。　　wrong、no 和 lies 是 false 的有效别名。　　Number——Rockstar 中的数字使用 DEC64 数字类型进行存储。　　String——Rockstar 中的字符串是 16 位无符号整数值的序列。　　Object——数据属性的集合，与 ECMAScript 一样。　　字面量和赋值　　Rockstar 中的字符串字面量使用双引号括起来。　　“Hello World”　　Rockstar 中的单引号被视为普通的字母。这似乎有点不寻常，直到你想起来 ain't talkin’ 'bout love 在摇滚中其实是一句完美有效的歌词。　　Rockstar 中的数字字面量是十进制数字。　　123　　3.141592654　　赋值使用 put/into 关键字组合：　　Put 123 into X 表示将 123 赋值给变量 X。　　Put “Hello World” into the message 表示将“Hello World”赋值给 the message 变量。　　递增和递减　　我们分别使用 Build {variable} up 和 Knock {variable} down 关键字进行递增和递减。　　Build my world up 将会让 my world 的值增加 1。　　Knock the walls down 将会让 the walls 的值减 1　　算术　　基本的算术运算使用 plus、minus、times、over 和 by 关键字。　　算术表达式：　　plus {b}——加法，别名为 with。　　minus {b}——减法，别名为 without。　　times {b}——乘法，别名为 of。　　over {b}——除法，别名为 by。　　例子：　　Put the whole of your heart into my hands——把 your heart 和 the whole 相乘，并把结果赋值给 my hands。　　My world is nothing without your love——将零减去 your love，并将结果赋值给 my world。　　If the tears of a child is nothing——检查 the tears 乘以 a child 是否等于零。　　My love by your eyes——返回 my love 除以 your eyes 的值。　　诗意字面量　　Rockstar 还支持一种独特的语言特性，称为诗意字面量（poetic literal）。受 here-document 语法的启发，诗意字面量允许程序员在初始化变量的同时表达他们内心深处的焦灼。　　诗意类型字面量　　在使用关键字 true、false、nothing、nobody 和 nothing 进行赋值时，使用单行代码，包括变量名、is 关键字和字面量。　　My heart is true——使用布尔值 true 来初始化 my heart。　　Tommy is nobody——使用 nobody 别名将 Tommy 的值初始化为 。　　诗意字符串字面量　　在进行诗意字符串字面量赋值时，以变量名作为开头，后面跟一个关键字（如 says），然后再跟上一个空格。剩余部分（直到碰到　　终止符）被视为不带引号的字符串字面量。　　Billy says hello world!　　表示使用字符串字面量 hello world! 来初始化 Billy。　　The world says hello back　　表示使用字符串字面量 hello back 来初始化 the world。　　诗意数字字面量　　在进行诗意数字字面量赋值时，以变量名作为开头，后面跟上关键字 is，或者别名 was 或 were。只要下一个符号不是保留关键字，这一行的其余部分将被视为一个十进制数，这个数由连续出现的字符串长度对应的数字组成。为了表示数字零，也为了弥补摇滚中缺少单字母单词和双字母单词，单词长度需要对 10 取模。句点（.）表示小数位。除第一个句点外，任何非字母字符都将被忽略。　　Tommy was a lovestruck ladykiller 表示使用 100 来初始化 Tommy。　　Sweet Lucy was a dancer 表示使用 16 初始化 Sweet Lucy。　　A killer is on the loose 表示使用 235 初始化 a killer。　　My dreams were ice. A life unfulfilled; wakin' everybody up, taking booze and pills 表示使用 3.1415926535 初始化 my dreams。　　请注意，诗意字面量可以包含保留论坛关键字，比如这个例子中的 taking。　　比较操作　　与 Visual Basic 和一些脚本语言中的单个等号运算符类似，Rockstar 中的 is 关键字出现在二手语句中还是出现在表达式中所表示的意思也不一样。　　Rockstar 中的比较操作只能在表达式中完成。　　Tommy is nobody 使用 nobody 来初始化 Tommy。　　If Tommy is nobody 表示在 Tommy 等于 nobody 时执行后面的代码块。　　修饰符 not 会反转比较操作的结果，类似于 SQL 中的 IS / IS NOT 。关键字 ain’t 是 is not 的别名。这种用法与惯用英语相反，其中“Tommy isn’t anybody”、“Tommy ain’t nobody”和“Tommy ain’t not nobody”表示相同的意思。　　Rockstar 还支持以下的比较语法：　　is　　higher/greater/bigger/stronger than 表示“大于”。　　is lower/less/smaller/weaker than 表示“小于”。　　is as high/great/big/strong as 表示“大于等于”。　　is as low/little/small/weak as 表示”小于等于“。　　输入输出　　在 Rockstar 中，我们使用 Listen 关键字从 STDIN 读取一行输入，并使用 Listen to 将输入赋值给变量。　　Listen to your heart——从 STDIN 读取一行，并将它赋值给 your heart。　　使用 Say 关键字将变量的值写到 SDTOUT。　　Say Tommy——将 Tommy 的值输出到 STDOUT。　　Rockstar 将 Shout、Whisper 和 Scream 作为 Say 的别名。　　流程控制和块语法　　条件语句　　条件表达式以 If 关键字作为开头，后面跟上表达式。如果表达式的计算结果为 true，则执行后续的代码块。在 If 代码块之后可以有可选的 Else 代码块。如果 If 表达式计算结果为 false，则执行 Else 关键字后面的代码块。　　循环　　与 If 语句类似，循环使用 While 或 Until 关键字表示，只要表达式得到满足，后面的代码块会被重复执行：　　Tommy was a dancer While Tommy ain't nothing, Knock Tommy down　　使用 16 初始化 Tommy，然后循环，每次将 Tommy 减 1，直到 Tommy 等于零。　　break 和 continue 语句的用法与其他大多数基于代码块的语言一样。Rockstar 将 Break it down 定义为 break 的别名，并将 Take it to the top 定义为 continue 的别名。　　代码块　　Rockstar 中的代码块以 If、Else、While 或 Until 作为开头，并以空行或 EOF 作为结尾。　　Tommy was a dancer While Tommy ain't nothing Shout it Knock it down　　函数　　函数使用变量名和后面的 take 关键字以及由 and 关键字分隔的参数列表进行声明。　　Multiply takes X and Y　　Search takes Needle and Haystack　　函数体是一个没有空行的语句列表。空行表示函数体的结束。Rockstar 中的函数总是有返回值，使用 Give back 关键字表示。　　使用 taking 关键字调用函数：　　Multiply taking 3, 5 相当于 returning (presumably) 15　　Search taking "hands", "lay your hands on me"　　示 例　　使用极简的 Rockstar 表达 FizzBuzz，为了清晰起见，使用了缩进：　　惯用的 Rockstar，使用诗意字面量，没有缩进：　　一些想法　　如果有可能，尝试改进这门语言。我并不热衷于连续块语法——对于初学者来说，还无法实现嵌套块。　　想办法实现图灵完备的摇滚民谣编译器。或许是基于 BF 的东西，我们使用单词长度或首字母或其他东西将歌词编译成 BF，或者其他一些极简但图灵完整的语言。　　制作”认证 Rockstar 开发者“贴纸，并将它们发给任何可以写 Rockstar 代码的人。　　使用 composer 为代码生成乐谱。

「中国首金！」「你永远可以相信中国短道速滑！」2 月 5 日晚上的首都体育馆，在短道速滑混合团体 2000 米接力决赛中，中国队击败对手，夺得中国首金。和万千观众共同见证这一重要时刻的，还有腾讯 3D 手语数智人主播「聆语」，并用手语传递了这份喜悦：「最后一个弯道！武大靖率先冲出弯道，通过终点！」在央视频多场赛事中，腾讯 3D 手语数智人「聆语」作为「AI 手语翻译官」，提供了手语解说服务，让处于无声世界中的特殊人群也能「听」到中国举办冰雪赛事的盛况，进一步提升了听障人士的观看体验。「聆语」解说短道速滑男子 1000 米决赛，任子威夺金。自由式滑雪女子大跳台决赛，中国选手谷爱凌夺得金牌。我们为什么需要 AI 手语数智人主播？在很多体育赛事中，敏锐、专业、生动、准确的赛事解说可以称得上是观赛过程的「灵魂」所在。但是对于听障人士来说，如果没有实时的手语解说服务，他们很难和其他观众一样充分感受到比赛现场的这份激情。在本次北京冬奥会的观众中，有一位来自武汉的听障人士。他表示，自己一直对冰雪赛事很关注，但在观看比赛时，最担心的地方就是「主持人语速较快，很容易错过一些内容」。「如果体育赛事能够借助 AI 手语翻译及时传递动态，我的观赛体验也会大大提升。」根据第二次全国残疾人抽样调查结果，中国有听障人士 2780 万人。手语是听障人士之间相互交流思想、获取外界信息的语言。目前许多新闻资讯、文娱节目中都缺少手语翻译，手语主持人「明显供不应求」，这为听障人士接收信息带来了不小的阻碍。目前，大众对冰雪赛事的关注热情创下新高，这对大型赛事电视观赛体验提出了更高的要求，其中也包括对手语解说服务需求的提升。AI 手语数智人主播迎来了更加广阔的应用场景。AI 手语数智人主播可以通过建立健听人语言体系、逼真的画面语言、连贯自然的动作和新词热词快速适配，提升 AI 手语表达的可懂度。2022 年 2 月，腾讯 3D 手语数智人「聆语」在央视频 APP 落地，「聆语」也迎来了自己的第一份工作：央视频 AI 手语翻译官。腾讯 3D 手语数智人「聆语」由腾讯云小微联合 PCG AI 等技术团队共同打造，整合多模态交互技术、3D 数字人建模、机器翻译、语音识别和自然语言理解等技术，让「聆语」的手语表达能力接近真人。腾讯自主研发了一套可视化动作编辑平台，为更专业的手语老师提供了友好的工具平台，可以让手语老师高效率的对全量手语动作进行精修。截至目前，腾讯 3D 手语数智人「聆语」词汇和语句覆盖量超过 160 万，并针对体育赛事做了大量定向优化，手语可懂度 90% 以上，技术水准行业领先。腾讯团队表示，他们希望为听障人士打造手语数智人，通过自身积累的 AI 技术，打造一款可懂度高的数智人，用技术为听障人士提供便利，这也是腾讯一直强调「科技向善」的理念。打造 3D 手语数智人「聆语」有何挑战？正如命名「聆语」所示，腾讯这款 3D 手语数智人是听障人士真正可懂的手语数字人。相比于其他的数智人，腾讯的手语数智人在技术上具备多项优势。对于观众来说，如果数字人在表达时出现神态和动作僵硬不自然的问题，那么观感就会大打折扣。在外观方面，「聆语」依托腾讯领先的 3D 重光照扫描还原、面部肌肉驱动、表情肢体手势捕捉等技术，生成了高度还原真人发肤、动作自然生动的数字人。笑意盈盈、一袭清爽蓝色套装的「聆语」最初亮相，就显著提升了手语播报的真实感与亲切感：更具挑战性的是，与一般的口头表达相比，手语是一套视觉语言，存在语序、表情和口型呈现等诸多问题，更不用说在表达过程中手势切换的流畅连贯性了。这些问题都要求 AI 手语主播需要具备较高的手语表达能力和精准连贯的手语呈现能力。如何让「聆语」像专业的手语主持人一样，实时、精准地传递解说内容，有效提高手语表达可懂度？在手语动作方面，为了让「聆语」实现流畅的交互，腾讯团队的程序员们啃起了《国家通用手语词典》，并让「聆语」在上岗之前也认真学习了《国家通用手语词典》的规范。经过漫长的手语调研、手语顾问团队建设，团队开发出了一套手语翻译系统。在手语解说时，「聆语」首先通过健听人语言与听障者手语的机器翻译能力，将健听人语言内容低延迟生成高准确率的手语语言表征。示例如下：输入：他是我的手语老师预处理：他 是 我 的 手语 老师翻译：他 我 手语 老师 是随后，「聆语」基于腾讯多模态端到端生成模型，进行联合建模及预测生成高准确率的动作、表情、唇动等序列，实现自然专业、易懂度高的手语效果。得益于腾讯云小微和PCG AI 在语音技术领域的长期积累，「聆语」的 AI 手语可懂度达到了90%以上。赛场手语翻译的难点，包括要通过 ASR 技术，将比赛解说的语音从赛场现场的复杂环境声音中分离出来进行精准的识别，然后再将识别出来的文本信息进行智能摘要，使手语翻译能够和主持人语速达到匹配。接下来，将手语翻译生成手语视频，保证每个动作准确的同时，也要实现动作与动作之间的精准衔接。在信息准确率方面，「聆语」还可以快速学习时下的新词热词，快速完成各种行业、业务场景和相关知识的学习，提升翻译准确性。比如 17 岁小将苏翊鸣被称为「小栓子」，再比如谷爱凌，需要「首字母 + 唇形」才能定义成特殊的词。借助腾讯的大数据技术能力，「聆语」能够做到快速及时地掌握热词，并进行手语词汇补充。此外，「聆语」更贴合业务，产品落地能力更强。腾讯团队综合运用 3D 数字人建模、机器翻译、多模态数字人生成、迁移学习、实时面部动作生成及驱动等多项 AI 技术，加深其感知理解，「聆语」支持业务场景更加丰富，业务数据积累量也更大。AI 手语合成主播未来可期随着 AI 交互智能的技术发展和应用落地，数智人已经成为很多行业的数字员工，辅助人类提供更加高效、精准的服务。在新闻传媒领域，在 2021 年 10 月，广电总局在《广播电视和网络视听「十四五」科技发展规划》中也首次明确指出，要推动虚拟主播、动画手语广泛应用于新闻播报、天气预报、综艺科教等节目生产，创新节目形态，提高制播效率和智能化水平。一直以来，腾讯云小微始终致力于推动 AI 交互智能领域的技术发展和产业应用落地。此前，腾讯云小微联合 PCG AI 及 AI Lab 等技术力量，打造了多个数智人方案，为大众提供客服、导览、讲解等多样化服务，涉及金融、传媒政务、家居、教育、展会、交通等众多领域。未来，来自腾讯技术团队的「聆语」还将在更多场景提供服务，帮助听障人士和正常人一样了解、交流新闻时事，助力实现更好的无障碍信息传播环境。

【重构前端知识体系之HTML】讲讲对HTML5的一大特性——语义化的理解引言在讲什么是语义化之前，先看看语义化的背景。在之前的文章中提到HTML最重要的特性，那就是标签。但是项目一大，标签多的看不懂，一堆叠着一堆。一些命名奇奇怪怪，想维护被劝退，团队协作导致团战开始！因此语义化迫在眉睫！什么是语义化在我们写HTML时其实无所谓，因为你里面长啥样，用户看不到，也不用看到。因为你有CSS的漂亮衣服，即使你的HTML一塌糊涂，CSS也可以让它光鲜亮丽。但是用户看不到，开发者看得到呀！因此，这个语义化的友好者是开发者本身。所谓语义化，就是凭着HTML本身，也能体验出人性化的结构！语义化的好处在没有CSS的情况下，页面也能呈现出很好地内容结构、代码结构。这样开发者一眼就明了你的意图，一秒破冰！对SEO友好。对开发者友好，那么对开发者的小虫子们也是当然！当标签应用得当，体现出上下文中你想要关键字的权重，那么搜索引擎爬虫就到了你的头上了。那么网站的访问量不就来了吗。可以支持一些特殊的设备（盲人阅读、移动设备），网页翻译等。最直观的一点，便是你的队友都希望和你合作！你的代码的语义化，队友都爱啊！语义化更具可读性，遵循W3C标准的团队都遵循这个标准，可以减少差异化。（跳槽快速融入？）工作中语义化的思考不要使用一些纯样式标签，这些CSS会帮我们做到。如：b、font、u等一些标签。需要强调的文本，可以包含在strong或者em标签中（，strong默认样式是加粗（不要用b），em是斜体（不用i）。使用 mark标签来表示标注的/突出显示的文本。 但是还是可以考虑使用CSS来完成。每个input标签对应的说明文本都需要使用label标签，并且通过为input设置id属性，在lable标签中设置for=someld来让说明文本和相对应的input关联起来。表单域要用fieldset标签包起来，并用legend标签说明表单的用途。应该使用<h1> - <h6>来表示标题。当用CSS写样式的时候命名也需要遵循HTML的结构，体现出语义化的本质。语义化的标签1、<header> 标签定义文档的页眉通常包含页面的正副标题。<header><h1>他真的是美男子吗?</h1><p>据现场勘查，他真的是美男子！</p></header>2、<footer>标签定义文档或节的页脚页脚通常包含文档的作者、版权信息、使用条款链接、联系信息等等。可以在一个文档中使用多<footer>元素。<footer>  <p>Posted by: 美男子</p></footer>3、<main>标签规定文档的主要内容。<main>元素中的内容对于文档来说应当是唯一的。它不应包含在文档中重复出现的内容，比如侧栏、导航栏、版权信息、站点标志或搜索表单。在一个文档中，不能出现多个 <main> 元素。<main>元素不能是以下元素的后代：<article>、<aside>、<footer>、<header>或 <nav>。<main>  <h1>我的介绍</h1>  <p>我是一个聪明的孩子</p></main> 4、<section> 标签定义文档中的片段。比如章节、页眉、页脚或文档中的其他部分。<section>  <h1>PRC</h1>  <p>The People's Republic of China was born in 1949...</p></section>5、<article> 标签规定独立的自包含内容比如文章下的评论之类的<article>   <h1>我为什么聪明呢</h1>   <p>我聪明的秘诀是我爱思考</p></article>6、<aside> 标签定义其所处内容之外的内容。用来装载非正文类的内容。例如广告，成组的链接，侧边栏等等。<p>聪明的研究</p><aside>  <h1>我为什么聪明呢</h1>  <p>我聪明的秘诀是我爱思考</p></aside>7、<nav> 元素代表页面的导航链接区域。用于定义页面的主要导航部分。<nav><ul><li><a href=”https://www.baidu.com”>百度</a></li><li><a href=”https://www.guizimo.com”>归子莫</a></li></ul></nav>一个语义化模板先来看一张图。看起来，一个标标致致的HTML结构就很清晰了。总结有的朋友肯定会问了，那平时都是用框架写的代码，基本不用用这些，又不是去写个人网站或者官网，都是写一些业务型的H5或者后台管理。其实对于个人网站或者官网来说，语义化是有实际价值的。而且，这个也是近些年来面试的常问的一题。最重要的是要去学习语义化的含义。做到代码语义化，包括函数的命名，组件的命名，组件业务功能的拆分。一直在路上！重构前端知识体系，你要一起吗？博客说明与致谢文章所涉及的部分资料来自互联网整理，其中包含自己个人的总结和看法，分享的目的在于共建社区和巩固自己。引用的资料如有侵权，请联系本人删除！感谢万能的网络，W3C，菜鸟教程等！感谢勤劳的自己，个人博客，GitHub学习，GitHub公众号【归子莫】，小程序【子莫说】如果你感觉对你有帮助的话，不妨给我点赞鼓励一下，好文记得收藏哟！关注我一起成长！所属专栏：重构前端知识体系（HTML）幸好我在，感谢你来！

目前有数百万人遭受语言障碍（speech impairments）的影响，根本原因主要是神经或遗传疾病导致的身体损伤、脑损伤或听力丧失。由此产生的症状也各有不同，包括口吃、构音障碍、失用症等，这些症状也会对自我表达、参与社会活动产生不利影响。 自动语音识别（ASR）技术能够通过语音助手帮助用户改善听写以及加强沟通，来帮助患有此类语音障碍的人训练。但ASR技术在显示应用中仍然有一个障碍，就是准确率仍然不够。 虽然深度学习系统计算能力相比和数据集的规模相比以往已经有很大提升，并且ASR系统的准确性也提高了很多，但对于许多患有言语障碍的人来说，性能仍然不够，在演讲的场景等都无法被语言障碍的人使用。2019 年时，谷歌推出了Project Euphonia，并讨论了如何使用个性化的、定制的无序语音ASR模型来实现更精确的性能，并且和通用ASR 模型的性能已经相差无几。 2021 年，Google 又在Interspeech 2021上发表了两项研究成果，这两项研究旨在将个性化ASR模型的可用性扩展到更多用户群体。 第一篇论文主要展示了一个数据集，包括了从Project Euphonia中大规模收集到的100多万次语音组成的无序语音数据。第二篇论文主要讨论了如何基于该语料库生成个性化的ASR模型。与通用语音模型开箱即用的能力相比，定制ASR模型可以产生更高精度的模型，并在选定的域中可以实现高达85%的字错误率改进。 自2019年以来，在各种情况下患有不同程度严重言语障碍的演讲者为Project Euphonia 提供了语音样本，这项工作已经将Euphonia的语料库增加到100多万个样本，包括1330名发言者的长达1400多个小时语音记录。为了简化数据收集过程，实验参与者在他们的个人笔记本电脑或电话（带耳机和不带耳机的情况都有）上使用了一个家庭录音系统，而非采用一个理想化的、基于实验室的环境来收集工作室级别超高质量的录音数据。 为了降低转录成本，同时保持高转录的一致性，在保存数据时优先考虑使用脚本的演讲。参与者阅读基于浏览器的录制工具上显示的提示，短语提示涵盖了家居自动化的指令，例如「打开电视」、和护理工作人员的对话，如「我饿了」，或者是和其他人的非正式对话，如「你好吗？今天过得愉快吗？」等内容。 大多数参与者收到了一个列表，包含超过1500个短语，其中有1100个短语只出现一次以及100个重复四次以上的短语。 语音专家在为每个说话人听语音的同时进行全面的听觉感知和语音评估，根据语音障碍类型（例如口吃、构音障碍、失用症）为每个说话人定级，总共包含24种异常语音特征的评级（例如，鼻音亢进、发音不精确、迷糊），以及技术上的问题（例如，信号丢失、分割问题）和声学问题（例如，环境噪声、次级扬声器串扰）相关记录质量评估。 有了数据才能训模型，这些新增的语音障碍的数据集也是开发新模型的基础：无序语音（disordered speech）的个性化的ASR模型。每个定制模型都使用标准的端到端RNN-T ASR模型，且仅使用目标说话者的数据进行微调。 RNN-T 的模型架构中，编码器网络由8层组成，预测网络由2层单向LSTM单元组成。 个性化ASR 模型重点调整编码网络，也就是模型中处理给定说话人声学数据的部分。研究人员发现，在固定住前三个编码层（同时固定他们的连接层和解码层）的同时，只更新底部五个编码层，可以获得最佳结果，并能够有效避免过度拟合。 为了使这些模型对背景噪声和其他声学效应更具鲁棒性，还用了一种专门针对无序语音的主要特征进行调整的SpecAugment配置。此外研究人员还发现，选择预训练的基础模型至关重要，最后他们选了一个在大型的通用语音语料库上训练的基础模型。 目前Google总共为大约430名演讲者训练了专属他们的个性化ASR模型，这些演讲者每人录了至少300条语音，把其中10%的话语作为一个测试集（训练和测试之间没有短语重叠），在这个测试集上计算个性化模型和通用语音模型的单词错误率（WER）作为评估标准。 实验结果表明，Google 提出的个性化方法在所有严重语言障碍条件下都有显著的改进。即使对于严重受损的言语，家居自动化领域短语的WER中位数也从89%左右下降到13%。在其他领域，如会话和护理人员交流下，准确性也有显著提高。在进行消融实验时，将实验分为几组：1、HighWER和LowWER：将说话人按照具有基于 WER 分布的第 1 和第 5 个五分位数的高和低划分个性化模型。2、SurpHighWER：具有特别高 WER 的说话人（在HighWER组具有典型的或轻度言语障碍的参与者）。 可以预见到，不同的病理和语言障碍表现会不均匀地影响 ASR。根据HighWER组中言语障碍类型的分布表明，由于脑瘫引起的构音障碍特别难以建模。该组的中位语言受损程度也更高。 为了确定影响 ASR 准确性的说话人特定和技术因素，研究人员检查了ASR 性能较差 ( HighWER ) 和优秀 ( LowWER )的参与者之间评级数据的差异。 和预期相同，LowWER组的总体言语受损程度显着低于HighWER组（p < 0.01）。清晰度是HighWER组中最突出的非典型语音特征，还包括异常的韵律、发音和发声。而这些语音特征在日常生活中也会降低整体语音清晰度。 SurpHighWER与比较组LowWER组（p <0.01）具有较少训练数据和更低的SNR ，除了速度外，其他所有的因素都对结果有较小的影响。相比之下，HighWER组在所有因素上表现出比较大的影响。最后研究人员将个性化 ASR 模型与人类听众进行了比较。三位演讲专家独立地为每位演讲者转录了 30 句话。可以发现，与人类听众的 WER 相比，个性化 ASR 模型的 WER 平均较低，并且随着语言受损严重程度的增加而增加。AI人工智能时代，残疾人士也能享受到科技带来的人文关怀，AI 技术的发展可以给残障人士加上耳朵、说话加上字幕、让盲人借助CV技术重新“看“到世界，愿科技真正向善。

「未来能否实现将芯片植入人脑就可以学到无穷无尽的知识？」一名青少年学生向科大讯飞高级副总裁杜兰博士提出了这样的问题。杜兰介绍了人工智能当前所属的阶段，以及讯飞在脑机接口方面的探索，指出目前认知智能还面临很多挑战，需要我们去持续探索。回归到青少年的学习，她强调人工智能可以将因材施教变成现实，能够结合每个孩子的特点进行个性化学习，从而让孩子更好的成长。少年强则国家强，少年智慧则民族智慧。到今年为止，科大讯飞联合未来论坛已经连续四年举办了「青少年对话未来科学大奖获奖人」的活动。图：青少年与2020未来科学大奖“数学与计算机科学奖”获奖者彭实戈院士对话12月30日，科大讯飞邀请了49名优秀青少年与 2020 年未来科学大奖获奖人进行了面对面对话。通过对话，讯飞旨在给优秀的青少年提供一个与科学家对话的机会。同时，讯飞也希望在青少年的心目中埋下「三颗种子」：第一颗是科技的种子，相信科技的力量；第二颗是奋斗的种子，相信知识可以改变命运；第三颗是快乐的种子，希望孩子们开心学习、快乐成长。这「三颗种子」希望激发更多的未来的科学家们健康茁壮地成长，在未来科学大奖的引领下，创造出越来越多的改变世界未来的科学成果，不仅造福人类，也使得中华民族在全球赢得更大的荣誉和尊重。就像杜兰在会上所说的那样，未来的人工智能时代，数据量会持续指数增长，会有更多的新的现象和知识出现，需要长期保持一个求知若渴的心态去拥抱这种变化。而人工智能可以让中国长久以来奉行的因材施教的理念真正得以实现，解放孩子的时间，让他们有更多时间与空间去探索这个世界。AI时代的因材施教，技术突破是新思路2020年，「内卷」、师生的课业负担重已经成为了全民热点话题。根据国家社会科学基金「中学专任教师工作量状况及标准研究」的数据，中小学教师工作量普遍超负荷，教师每周工作时间平均值为54.5小时，全年作业批改量达1.2万本，大多数教师为了完成批改作业等重复性工作，需要长时间加班；同时根据科大讯飞承担的国家发改委大数据专项「基础教育大数据研发与应用示范工程」，分析了35亿次答题记录后的数据结果显示，学生的日常作业中60%左右都是无效练习，学生负担重、错题解决率低。刷题，依旧是现在大部分学生提高成绩的唯一方法。时代在不断变化，技术也在不断变化，但是学习的方法却没有很大的变化。这不禁让我们思考，新时代的教育到底应该怎么做？科大讯飞董事长刘庆峰认为：人工智能时代的教育，本质是更加提高生命质量 。而因材施教的逻辑，就是通过人工智能对教学过程和学生的作业、测试的过程数据进行收集，而后进行精准的分析，从而给出每个孩子的知识掌握情况，同时帮助老师实现精准性备课、教学，减少作业批改等重复性工作，让师生解放成为可能。在目前的普惠教育下，人工智能更有希望真正实现对每个人的因材施教。凡是有规律可循的重复性活动，AI几乎都可以替代，甚至比人做得更好。那人工智能到底如何帮助教师因材施教，让学生更多的发挥自己的创意和想象力呢？首先，人工智能可以帮助师生「腾出时间」。例如，AI可以帮助老师做批改作业等重复性工作，并生成数据分析统计，让老师更好地关注孩子的优劣势；也可以帮助老师备课，留出时间关注孩子的身心成长。同时，人工智能也可以根据学生学情，结合知识图谱，推送个性化作业，为孩子的学习减负增效。据了解，应用人工智能因材施教，孩子的重复练习量下降50%，回家写作业时间降低32%，课外活动时间提升50%，同时还让焦虑情绪下降、学习兴趣持续提升。 其次，师生减负之后就会为「五育」（德育、智育、体育、美育、劳动教育）并举赢得更多时间，学生可以按照自己的兴趣进行更多有意义的学习，比如编程、实验、美术等等。除此之外，通过AI技术还可以促进城乡教育均衡，在一定程度上缓解教育不均的现状，提升农村地区的教学质量；推进群体均衡，让聋人孩子听不见声音，却“看得见”声音，用语音合成让盲人孩子看不见文字，却“听得见”文字。而这一切的背后，都与人工智能核心技术的突破密不可分。自1999年成立以来，科大讯飞一直坚持「顶天立地」的技术信仰，持续在研发上进行投入，最近3年就在国际人工智能领域的相关比赛上获得了30余项世界冠军。今年10月，科大讯飞与中科大联合团队，在NeurIPS教育挑战赛中凭借“预测学生对新试题的作答选项”、“评估试题质量”、“设计个性化试题推荐模型”三个任务脱颖而出，斩获一个赛道的公榜和私榜双项冠军及两个赛道的公榜第一。在中英文作文的自动批改方面，目前机器评阅也已经超过了人类专家水平。在教育部考试中心的支持下，科大讯飞的智能评价技术已经在今年九个省高考语文作文阅卷中应用，得到了教育部考试中心、国家语委的高度认可。在自然语言理解方面，技术的发展可以让机器实现对数理化的逻辑推理，让孩子们按图索骥知道他应该学什么，减少无效重复练习。2019年3月，哈工大讯飞联合实验室（HFL）与河北省讯飞人工智能研究院联合团队在斯坦福大学发起的国际权威机器阅读理解评测SQuAD 2.0挑战赛中登上榜单第一，在全部两项指标上均超过了人类平均水平，一举创下比赛纪录。从2020年初到现在，科大讯飞已经获得了10余项比赛冠军。正是基于这些技术的进步，人工智能在逐渐推动以学习者为中心的教育改革。现在还可以基于人工智能和大数据技术为每个孩子构建不同的知识图谱。这其中的知识图谱技术，科大讯飞从2013年开始投入研发，2016年在国际知识图谱构建大赛NIST TAC (KBP2016) 获得第一名，至今已经积累了7年。其中红色是不会的知识点，黄色是薄弱知识点，绿色是已学会的知识点。孩子们可以先学黄色、再学红色，循序渐进，不仅提高了学习效率，也可以真正做到因人而异、因材施教。知道了知识的习得顺序和逻辑，才是真正的长期的学习价值的体现。同时，由于今年的疫情影响，线上线下混合的学习模式成为热点。科大讯飞支持了21亿次的线上的教学和作业，发现学生们普遍存在「在线不在状态」的问题。通过人工智能技术，推出了在线教学七步法：进门测、新授课、互动测、出门测、A.I.作业、1对N答疑、可视化报告，让学生告别盲目学习，降低焦虑感。深耕教育十六年，讯飞将智慧教育带入更多课堂自2004年以来，讯飞在教育领域积累了深厚的技术、丰富的教育教研资源以及实践经验案例，真正地将技术进行落地应用。迄今为止，讯飞的智慧教育系列产品已经覆盖了全国31个省级行政区共38000余所学校，服务过亿师生。近期，科大讯飞还推出了新一代智慧课堂，这是由讯飞教育智慧窗、讯飞智能学生机两大硬件和班级超脑能力平台组成的产品。智慧课堂产品总监苗磊指出，新一代的智慧课堂“真正做到了更清晰、更护眼、更智能，专为课堂量身定制，全面支撑老师常态化教学工作。”通过班级超脑搭载的一系列人工智能领域的先进技术，实现了「2+1=N」的碰撞，将讯飞教育智慧窗与讯飞智能学生机紧密的联系在一起，通过一块大屏和一块小屏的对话，进一步为课堂教学服务。让技术在课堂教学的应用，不单再是简单的交互和互动，而是能够让课堂教学延伸的更具深度和广度，让孩子能够更方便的开展个性化的学习。例如智慧窗产品搭配86寸的超大屏幕，4K超高清画质，即便是教室最后一排的孩子也能看清屏幕内容。为了方便老师的移动教学，讯飞智慧窗还配置了一支A.I.智能教学笔，可用以开展远场教学。当老师走到学生身边互动时，可通过发出语音指令的方式，调动屏幕做出相应动作，如调取课本、翻页、打开文件等，更加符合教师教学习惯，便于和学生的互动、交流。与此同时，新一代智慧课堂解决方案中，班级超脑全新升级，不仅可以对学生课堂学情进行全过程数据动态反馈评价，还应用大数据技术，对学生学情进行分析，帮助教师实现精准教学。同时，班级超脑兼容海量教育资源，能够为师生匹配和推送精准教学和学习内容。换句话说，传统教学模式中由于技术手段的欠缺，老师没有办法对每一个学生的学习情况精准掌握，只能粗放地分出优、中、差等级，教学精度上比较粗糙。而班级超脑可以做到从课前、课中、课后的全场景数据闭环，同时除了支持场景数据采集，也支持多种题型采集，帮助老师更好地还原班级的学情，让老师对每一个学生的情况都有可视化呈现。由点及面，讯飞推出区域级因材施教解决方案如果说新一代智慧课堂是一个点，那么科大讯飞提出的区域级因材施教解决方案就将无数的点汇聚成了整体的一个面。所谓因材施教综合解决方案就是通过信息技术与教育教学的深度融合，实现资源生态化、教学互动化，突破时空限制，创新因材施教的教与学模式，为实施创新人才培养提供必要条件，为构建学习型社会奠定重要基础。「蚌埠市智慧学校项目」是科大讯飞进行的全国第一个真正的全市统筹、用人工智能来助推全市的教育均衡和因材施教的教育项目。2019年，蚌埠市引入科大讯飞因材施教综合解决方案，利用人工智能技术开发基于大数据的智能教学与管理平台，促进优质教育资源共享和师生减负增效。通过构建以学习者为核心的课程体系与评价体系，基于过程性数据生成专属教与学画像，帮助师生减负增效。蚌埠二中等学校通过智能化批改技术，减轻教师重复的工作量，创新讲题课教学模式，提升课堂效能；怀远一中、蚌埠实验中学等学校通过个性化学习资源的自动推送系统，改善题海战术等低效学习模式，提高了学习效率。今年11月，央视《新闻联播》中还提及了蚌埠第一实验学校的智慧教学情况，指出“这所学校的学生有了人工智能的‘新老师’，可以纠正他们的错误发音，还可以报听写，批改作业。”基于智慧课堂的应用，蚌埠第一实验学校积极探索人工智能与学科教学的深度融合范式，落实高质高效课堂，帮助学生全面且个性化成长。目前，我们已经可以看到一些具体的成效，如教师备课时间减少33%，学生无效练习降低49.6%等。这是在部分特定的场景下，未来还将往更多的场景去延伸。就在2019年，科大讯飞首次发布了一个企业宣传片 「A.I.向人类的表白」，其中有句话讲到，人工智能可以拥有全世界的知识，却不能替代老师；可以轻易诊断任何疾病，却不能替代医生；了解所有成长的秘密，却不能替代母亲。正如科大讯飞董事长刘庆峰所说：未来属于掌握人工智能的新人类 。因为，人类拥有人工智能所没有的东西：同理心，想象力，创造力，热爱……而这恰恰是要培养孩子跟未来机器最不同的地方。

在国外，微软、谷歌和 IBM，这些国外大厂也是用类似的方式将 AI 与公益相结合。 微软在 2016 年开发出 Seeing AI 辅助视觉方案，由一位盲人工程师开发，可以语音告知「一个穿红衣服的女孩正在踢球」等信息，帮助残疾人获取信息；2018 年 10 月，谷歌 AI 推出「社会公益 AI 倡议」项目，谷歌旗下慈善机构 Google.org 发起了 AI 影响挑战赛，奖金 2500 万美元。    科技和人文是不冲突的立场，让AI具有同理心，是未来发展的大方向。 而对于开发者来说，AI时代，能力越大，责任越大。 公益，也可以「开源」那么，公益只是大企业的舞台吗？ 公益，也可以有「开源」精神。 今年，百度启动了星辰计划公益项目，将依托人工智能技术，更全面地赋能社会公益事业； 海康威视启动「STAR公益伙伴计划」，将基于其AI开放平台，免费向各类公益组织提供算法训练等功能，助力公益组织快速提升能力。 IBM的「绿色地平线」计划也进入了第四个年头，利用IBM的数据同化和认知建模技术，北京市的PM2.5已经有了大幅下降。 如今已经八岁的腾讯优图实验室，更是在「践行科技向善」中，扮演了重要的角色。至今为止，优图聚焦计算机视觉，专注人脸识别、图像识别、OCR、机器学习、数据挖掘等领域，并陆续上线了算法类的一系列开源项目，如人脸检测算法 DSFD（Dual Shot Face Detector）、动作检测算法 DBG、通用目标检测算法 OSD（OneStageDet）、图像超分 SuperResolution-RealSR、人脸关键点算法 FHR(Fractional Heatmap Regression ) 、人脸属性算法 FAN 、神经网络推理框架 TNN等。             它们已经在公益寻人、信息无障碍方面发挥了重要作用。其中，为了实现更精准的跨年龄识别寻人，优图的算法模型进行了多轮大的迭代，先后尝试了上千次模型训练，专门针对寻人打造了优图祖母模型的版本。这些开源的技术，正是企业送给开发者实现「AI+公益」的有力工具。 因为每一个灵光一现的时刻，背后都可能是一个亟待解决的社会问题， 或许是看到一条条失踪儿童的信息；或许是偶然发现的父母头上的白发………你上一次冒出「想要做点儿什么」的念头又是什么时候？ 别让想法只是想法。 这一次，优图和开发者一起，让想法真正成为推动改变的力量！ 腾讯基金会、企鹅伴成长、腾讯优图实验室、腾讯云AI和腾讯云开发联合发起腾讯Light·公益创新挑战赛， 以「AI，让美好现在发生」为主题，「未成年人网络保护、适老化无障碍设计、野生动植物保护」三大赛题。      来看细节： 三大赛题，优图助力技术，让你的公益浮动起来！ 本次大赛选取了 3个应用场景：「未成年人网络保护、适老化无障碍设计、野生动植物保护」参与团队运用小程序云开发进行开发，使用最少一项基于腾讯优图和腾讯云提供的人工智能技术，打造小程序创新应用。             1）腾讯X联合国儿童基金会联合出品：未成年人网络保护 赛题以未成年人保护为方向，希望开发者聚焦未成年人互联网使用的重点场景和突出问题，如内容生态、网课学习、网络社交、网络沉迷等，设计和提供兼具实用性和前瞻性的技术解决方案，助力孩子在数字时代健康成长。 2）腾讯X深圳市信息无障碍研究会联合出品：「适老化」无障碍设计 本赛题希望开发者关注老龄化社会中的问题，将AI技术运用到「适老化」无障碍设计中，解决看不清、听不懂、说不准、做不到、记不住、互联网盲等问题，让他们不再被互联网的巨浪所淹没。 3）腾讯X桃花源生态保护基金会联合出品：野生动植物保护 本赛题呼吁开发者关注并合力推动野生动植物的保护，开发者可以基于物种面临的生存威胁，提升大众在野生动植物保护领域的参与度，为野生动植物保护和公众教育提供更多的可能。       作品示例：通过人像转换技术DittoGAN，上传图片，一键为你生成专属趣味野生动物保护漫画 在本次大赛中，你可以调用腾讯云上的AI能力，如助力跨年龄寻人的人脸识别算法，解决家长辅导作业痛点的「OCR 速算」等，开发者可以通过轻松便捷的接入方式就可以DIY各种智能产品，且运行在云开发小程序上。从12月30日至4月7日，参赛者通过http://light.mofyi.com/进行报名（左下角阅读全文），经过为期近4个月的报名、初赛、复赛、决赛四个阶段。在评审阶段，每组需提供图片、代码、文字说明进行作品展示。 评审团将对你的作品进行全方位的评估，详情如下：       获胜者将获得：        你可以是孤胆英雄，但也能组团上阵你可以以个人形式参赛，当然，组团比拼更能体现团队精神，但每个参赛队伍人数最多不超过4人，允许跨单位自由组队，但每人只能参加一支队伍。   公益为人人，人人为公益。       如果你是富有创造力的开发者/公益人，利用AI，打造一款足够创新，有用的小程序，把你的奇思妙想变成浮动的窗口，让你的项目赋予科技向善的力量吧！

「快看！一只大猫！」 今年十一期间，在青海省互助土族自治县北山林场，一对雪豹母子的活动影像，让护林员发现了这只罕见的野生动物。         听到雪豹这个名字，大家都会觉得它是一种通体雪白的豹子，跟白色的金钱豹没什么差别，但实际上，雪豹却是长下面这个样子的： 似乎，更像一只斑点老虎。 而且，雪豹和金钱豹有着不同的栖息地，一个是活动于雪线之上的「雪山之王」，另一个，则是森林生态系统的旗舰物种。 由于数量稀少，我们很难了解雪豹的信息，而随着人类旅游范围的拓宽，难免会打扰到这些珍稀物种的宁静生活。                但现在，借助一个小程序，我们能把这只大猫的信息一网打尽——「神秘雪豹在哪里」，它由腾讯联合WWF（世界自然基金会）、深圳市一个地球自然基金会打造，利用知识图谱，以灵活的点击方式、高清全面的视觉效果，将「雪地精灵」的知识全貌映入我们的眼帘，用科技力量助力雪豹保护行动。             俗话说，「知识改变命运」，通过了解这些生态知识，掌握在人类手中的大自然命运，也会悄然改变。 其实，AI可以做的，不仅如此。 回想过去的一年，你会发现在不知不觉中，AI正在悄无声息地改变着我们的生活。 无论是利用计算机视觉快速对比、锁定、匹配出可能的失踪人口，帮助找回多个被拐超过十年的孩子，               还是通过光学字符识别，让图像中的文字转换成文本格式，配合手机上的语音朗读功能，让视障者和老年人可以即时、便捷、顺畅地获取图片中的文字信息。                当AI与公益做乘法，科技公益就会变得人人可及。开发者的时代：能力越大，责任越大如果说谁缔造了这个AI时代？就是这群人，他们有共同的名字：开发者。代码，原本就是一串串冰冷的字符，开发者们赋予了它们自己的灵感与创意，出行时出租车会准时停在楼下；可口的食物会在你饥饿时敲开你的门；即使是疫情也不能阻隔人们的工作与交流；更有发现大脑与计算机惊人的相似性，探索人机共生的奥秘。 在电影《蜘蛛侠》中，当男主角有了超能力时，他为社会做出了更多贡献，所以就有了那句再经典不过的台词：能力越大，责任越大。将AI赋予到公益中，那就是开发者将能力赋予到责任中的一种体现。 寻亲、助残、教育等几个方面是广大开发者和科技企业不约而同选择的公益事业方向，这与目前 AI 发展大方向——「科技向善」无缝相连。 而头部AI企业可以利用自身在AI研发上的优势，实践「科技向善」。 在国内，百度在2019年发布了企业社会责任季度报告，其中包括以 AI 寻人，帮助盲人、听障儿童、翻译手语，帮助控烟等；腾讯优图实验室首创跨年龄人脸识别，帮助找回7名被拐超过10年的儿童；利用人脸核身技术，很多不方便出门的老年人，残障人士也借此完成了很多业务办理，提供了极大的便利。

还记得去年上海世界人工智能大会上的那场「双马」对话吗？ 马云和埃隆·马斯克激辩人工智能，一个更偏向相信人类，一个认为机器远比人类聪明。 孰对孰错、哪个站上风需要交给时间检验，但有趣的是：这场英文对话进行时，他们身后的大屏幕显示AI正在为他们进行实时语音识别与中英翻译。              哪怕成了被讨论的主角，AI依然有条不紊地运转着。 这项技术正是由科大讯飞全程参与提供。AI是否会取代人类仍是未知，但AI是否实现落地应用已经有了明确的答案。 12月27日下午，由国家工业信息安全发展研究中心主办的「2020中国语音创新发展高峰论坛暨中国语音产业联盟年会」在天津滨海召开，来自政、产、学、研、用等各方代表百余人齐聚一堂，围绕智能语音科技产业热点，共同谋划语音产业发展大计，助力人工智能与实体经济深度融合发展。        中国语音产业联盟旨在进一步整合产业资源，构建健康的产业生态体系，推进语音及语言产业的快速发展。在中美科技竞争背景下，中国智能语音企业坚持源头技术创新、技术自主可控，有效防止“卡脖子”风险。 会上，由国家工业信息安全发展研究中心发布的《中国智能语音产业发展白皮书》之十大观点摘要，为我们全面展示了语音行业的现状和未来。               《白皮书》十大观点重磅发布！科大讯飞市占率稳居国内第一 《白皮书》之十大观点摘要指出，全球智能语音及人工智能产业发展方兴未艾，进入规模化发展并保持快速发展态势。在深度学习、云计算、大数据和5G等四大基础技术的加持下，智能语音技术及应用不断向人工智能产业延伸。       图：2014-2019年全球智能语音产业规模和增长率 据预测，2020年全球智能语音及人工智能市场规模将超过200亿美元，谷歌、苹果、微软、科大讯飞等头部企业占有80%以上市场份额。全球智能语音头部企业优势明显，持续发力产业生态构建，市场发展潜力巨大。        图：2018-2019年全球智能语音市场份额 谷歌、微软和苹果的智能语音技术大多体现在其语音助手等C端消费产品上，而讯飞则是深入教育、医疗、家庭、办公等各大应用场景之中。          据IDC报告预计，在语音语义市场，科大讯飞市场占有率稳居国内第一，而后是百度、阿里云、思必驰等。    来源：IDC中国，2020 同时，据艾媒咨询《2020年上半年中国人工智能产业专题研究报告》显示，在智能语音赛道，科大讯飞的综合实力和成长能力远超同行业竞争者，独占第一梯队。    图：中国智能语音产业梯队，来源：艾媒咨询 可以看出，无论从市占率还是综合实力，科大讯飞都占据国内语音市场龙头地位，第二梯队的企业与之还有较大差距。 智能语音的「平台+赛道」两极放大效应凸显，围绕行业场景与个人场景加速落地。「涟漪效应」使得当前智能语音行业落地从刚需场景的典型案例走向规模应用，已在教育、医疗、政务、金融、运营商、司法等领域深度落地融合；个人场景重点围绕家庭、汽车、办公等场景展开，消费者智能语音产品不断涌现且频获市场认可。           同时，我国的智能语音应用催生了新消费、新应用、新市场。特别是新冠疫情爆发后，智医助理、电话随访、空中课堂、虚拟会议、虚拟主播等智能语音应用助力疫情防控，催生新的蓝海市场。              从近几年的发展来看，智能语音技术及产业化程度相对成熟，智能语音技术创新力度加大，语义理解技术取得较大突破。  今年NLP圈的一件大事就是GPT-3的发布，其1750亿的参数量引发了巨大轰动。要知道，人的大脑也才只有860亿个神经元，这一突破，使得很多人认为距离摘下NLP这颗人工智能的「掌上明珠」又近了一步。           白皮书也指出，人工智能下一步发展的关键创新点在小样本学习、动态自适应、迁移学习、离线计算与情感计算等，人机耦合将是技术长期发展趋势。          在新基建大战略下，智能语音交互将成为万物互联时代的人机交互入口和新型信息技术基础设施，对国家发展打造竞争新优势、注入增长新动能意义重大。在国内国际双循环相互促进的新发展格局下，智能语音技术及产品是解决人类交流的刚需。 要解决「卡脖子」难题，更要做「有温度」的黑科技 去年10月8日，据美国商务部官方网站公布的信息显示，科大讯飞等多家中国企业被列入美国实体清单。企业被列入实体清单后，美国政府即可根据《出口管理条例》限制对这些机构出口、进口或转口。 科大讯飞则是名单中首个没有因此而停牌的上市公司，当天股价下跌后第二天就涨了回来。 过硬的技术实力，是科大讯飞腰板挺直的真正原因。 在会上，中国语音产业联盟理事长、科大讯飞董事长刘庆峰还进一步强调了智能语音的战略地位： 「万物互联时代，语音是核心技术的必争之地，也是防止卡脖子的关键技术。」              同时，刘庆峰提出2020年语音行业发展呈现的三个变化： 1.应用场景从移动互联网进入万物互联的特征越来越明显，语音正日益成为万物互联的入口； 2.随着行业应用落地的深入，语音技术和认知智能的结合越来越紧密； 3.社会刚需引导下，多语言技术发展越来越快。 语音技术和产品的规模化落地绝非易事，大规模的生产和使用具有相当大的挑战性，但2020年的疫情给了科大讯飞一个检验自身实力的机会。       科大讯飞的「智医助理」已通过国家执业医师综合笔试，并超过了96.3%的考生，能够快速掌握新冠肺炎知识。疫情期间，在国家卫健委指导下，讯飞通过人工智能对200万名基层医生做了培训，节省医护人员大量宝贵时间。 在武汉封城期间，通过讯飞的语音技术，一个机器可以给成百上千个家庭打电话，6小时即可完成100万人的电话访问。电话访问结束之后还可以自动生成统计报表。在全国推广后，共完成了5900万次的访问和统计，极大地节省了随访时间。 如果说今年的疫情是全球共同面临的难题，那么即将到来的老龄化社会就是我国即将面临的考验。 近日，工信部印发了《互联网应用适老化和无障碍改造专项行动方案》，该方案提出，开展互联网主要行业网站及老年人、残疾人常用移动互联网应用(APP)的适老化及无障碍改造。 在天津，讯飞就在尝试打造一个「有温度」的城市。 利用语音技术，AI系统还可以调取水电煤气信息，若独居老人的用水用电信息有所异常，系统就会主动拨打电话进行问候；若无人接听，系统则会通知家属或社区，极大地提高了社会效率。 在今年的1024开发者节上，讯飞开放平台上有1000多个团队，专门为聋哑人和盲人开发应用，这些应用每天有5000万人在调用，其中有不少聋人和盲人还成了创业英雄。 这背后所有的一切，背后都依靠的是科大讯飞多年的技术沉淀。 此前，刘庆峰就曾表示：AI应用红利兑现的基础，就是突破AI核心技术鸿沟。拥有21年历史的科大讯飞在国际上不断取得技术突破： 在两年一次的国际多通道语音分离和识别大赛（CHiME）中，科大讯飞联合中科大语音及语言信息处理国家工程实验室（USTC-NELSLIP）在给定说话人边界的多通道语音识别两个参赛任务上夺冠。 自2016年以来，科大讯飞第三次参加这项国际竞赛并连续夺冠，语音识别错误率从CHiME-5的46.1%降至现在的30.5%。          在全球声纹识别（VoxSRC）大赛公开刷榜阶段，科大讯飞还刷新了世界纪录。DCASE比赛任务3也拿到了全球第一，对应的产品「工业听诊器」也已经上线，能为企业节省成本，助力工业智能化升级。 虽然通用人工智能才刚刚开始起步，机器的常识推理甚至还没有达到孩童的水平。但只要在专业领域有足够的数据，未来通过语音系统来大幅改善生活质量提升效率，是非常值得期待的事情。 语音的技术和应用事关产业未来，语音产业的发展也离不开生态建设。 刘庆峰强调说：「唯有开放才能生生不息，生态繁荣决定产业繁荣」。过去一年中，讯飞开放平台实现超50万增长，开发者总量达169万。其中天津「北方声谷」自2018年5月开园至今，开发者团队已达2.3万，增长约3.3倍。 正如刘庆峰所说： 「中文语音要由中国人做到世界最好，中文语音产业要掌握在中国人自己手上。」 相信一批批人工智能企业在协同联动和创新驱动中，将为全球化下的「中国策」贡献更多AI智慧，用智能语音向世界传递中国声音，用人工智能讲好中国故事。

 常见ASCII码的大小规则：0~9＜A~Z＜a~z  1）数字比字母要小。如 “7”＜“F”；  2）数字0比数字9要小，并按0到9顺序递增。如 “3”＜“8” ；  3）字母A比字母Z要小，并按A到Z顺序递增。如“A”＜“Z” ；  4）同个字母的大写字母比小写字母要小32。如“A”＜“a” 。  记住几个常见字母的ASCII码大小： “A”为65；“a”为97；“0”为 48。另外还有128-255的ASCII字符字符集简史  6000年前 象形文字  3000年前 字母表  1838年到1854年 Samuel F. B. Morse发明了电报,字母表中的每个字符对应于一系列短的和长的脉冲  1821年到1824年 Louis Braille发明盲文，6位代码，它把字符、常用字母组合、常用单字和标点进行编码。  一个特殊的escape代码表示后续的字符代码应解释为大写。一个特殊的shift代码允许后续代码被解释为数字。  1931年 CCITT标准化Telex代码，包括Baudot #2的代码，都是包括字符和数字的5位代码。  1890年 早期计算机的字符码是从Hollerith卡片,6位字符码系统BCDIC（Binary-Coded Decimal Interchange Code：二进制编码十进制交换编码）  60年代 扩展为8位EBCDIC,IBM大型主机的标准  1967年 美国信息交换标准码（ASCII：American Standard Code for Information Interchange）  在字符长度是6位、7位还是8位的问题上产生了很大的争议。从可靠性的观点来看不应使用替换字符，  因此ASCII不能是6位编码，但由于费用的原因也排除了8位版本的方案（当时每位的储存空间成本仍很昂贵）。  这样，最终的字符码就有26个小写字母、26个大写字母、10个数字、32个符号、33个句柄和一个空格，总共128个字符码。  ASCII现在记录在ANSI X3.4-1986字符集－用于信息交换的7位美国国家标准码（7-Bit ASCII：7-Bit American National  Standard Code for Information Interchange），由美国国家标准协会（American National Standards Institute）发布。  图2-1中所示的ASCII字符码与ANSI文件中的格式相似。ASCII国际问题  ASCII是美国标准，所以它不能良好满足其它讲英语国家的需要。例如英国的英镑符号（￡）在哪里？  拉丁语字母表重音符号  使用斯拉夫字母表的希腊语、希伯来语、阿拉伯语和俄语。  汉字系统的中国象形汉字，日本和朝鲜。  1967年，国际标准化组织（ISO：International Standards Organization）推荐一个ASCII的变种，  代码0x40、0x5B、0x5C、0x5D、0x7B、0x7C和0x7D“为国家使用保留”，而代码0x5E、0x60和0x7E标为  “当国内要求的特殊字符需要8、9或10个空间位置时，可用于其它图形符号”。这显然不是一个最佳的国际解决方案，  因为这并不能保证一致性。但这却显示了人们如何想尽办法为不同的语言来编码的。