EBT训练正在变得时髦，有些人开始宣称自己是EBT教员了，伴随着目光的离散。可是EBT到底是什么呢？和以前的训练到底有什么区别？离散的目光意味着什么？为什么提及哈希和JSON？让我们在这里仔细挖一挖。
EBT，即循证训练，医疗系统早就有循证医学，并不是什么新事物。可是循证训练到底是什么呢？如果精准翻译的话，Evidence-based Training应该是“实事求是的训练”，意思是不要搞那些想象中的、现实世界不存在或这辈子很难出现的科目来难为人，转而针对实际中存在的问题、带有普遍性的问题进行训练，从而回归训练的本意，提升飞行质量。
简单讲，就是EBT以后，你不会再碰到诸如单发叠加大侧风，还碰巧旅客心梗这类科目，而是感受到更加贴近现实的培训。
既然这么简单，为什么EBT看上去这么高大上而又神秘莫测？
首先是人的问题
人的问题解决了，EBT也就建立了。
专家问题：每当看上去很新的概念出来后，就会涌现一批专家，用一堆新词、缩写词来一顿狂轰滥炸，把大伙儿搞晕，乱而后治，这是专家们的责任和义务。
解决办法：勒令专家说人话，严禁反复口吐生僻的缩写词。
缩写
实际含义
CD-Course Developer
课程开发人员
TI-Theory Instructor
理论教员
SC-Simulator Coach
模拟机教员
LSC-Leading Simulator Coach
资深模拟机教员
II-Implement Instructor
飞行教员
IE-Implement Examiner
检查员
ADDIE-Analyze-Design-Develop-Implement-Evaluate
演进过程-分析、设计、开发、执行、评估
KSA-Knowledge，Skills and Attitudes
知识，技能和态度
CRM-Crew Resource Management
机组资源管理
TEM-Threat and Error Management
威胁和差错管理
SBT-Scenario-based training
基于场景的训练
课程开发人员问题：传统上造成训练科目生搬硬套、拉郎乱配的情况，一种可能是课程设计部门人手不足，把开发工作交给了精通word、excel的工作人员，他们并不具备飞行经验；或者是层层转包，最后干活儿的是个临时来帮忙的刚毕业副驾驶。他们只会搬手册，不会搬实际运行情况。
解决办法：EBT课程开发组需要飞行教员、IT工程师、其他技术人员组成，但要以实际参加飞行的教员为主，建立课程开发团队并保证深度参与。同时，重视负责案例收集的小组（也称为数据收集），这个小组需要飞行教员深度参与，而不是IT工程师（一说到数据，就以为是QAR，就以为是IT的事儿）。
教员问题：教员传统上都按科目教学，教会一课是一课，喜欢打听考试科目，随即陷入应试教育的泥潭。很多教员只会简单打分，还不知道或尚不理解胜任力评估方法。
解决办法：EBT则要让教员摒弃应试教育，回归快乐教育，增强互动性；开展胜任力评估培训，让教员理解新的评估体系的好处。
看到这里，很多人会有疑问，胜任力评估又是什么鬼？下面我们说第二个问题。
CBTA是什么？
EBT不复杂，但是它是基于CBTA（基于胜任力的培训和评估）的，我们之前并没有普及CBTA，所以这是两步并作一步走，稍微有点吃力。
CBTA最开始称为CBT（Competency-Based Training），基于能力的培训的缩写，由于和之前的基于计算机的培训缩写重样，所以改成了CBTA（Competency-Based Training and Assessment），中文也改成了基于胜任力的培训和评估。
基于胜任力是什么意思？
还记得实践考试工作单、熟练检查工作单吧？前面两页是科目，最后有一个综合评估页面，检查员要对整场训练做出总结后填写这部分内容，然后才能签字做结论。
这部分现在不叫“综合评估”了，改称“胜任力评估”，内容还是那些内容，只是被整合成九条，并设定了新的、更实用的打分规则。这是CBTA的基本盘。
这里打个比方，如果液压故障没飞好，可能是人工飞行能力欠佳，也可能是知识基础薄弱；如果单发后关错发动机，可能是程序执行出了问题，也可能是工作量管理混乱。总之，每一个不达标的科目，都涉及到一个或多个胜任力的问题，从胜任力角度去训练，比反复训练单一科目，更符合安全运行的需要。
九项胜任力中，知识基础就是K-Knowledge，人工飞行 自动飞行 程序执行对应S-Skills，其余五项对应A-Attitudes，合起来就是KSA。其中A的训练就是之前的CRM训练。九项胜任力合到一起，干的就是TEM。所以，CBTA实际上让KSA、TEM、CRM走进了历史。
每项胜任力处于什么状态，可以基于新的打分规则来判断，就像战士打靶：
完美战士，值得赞扬、鼓励（少数）
这个战士够标准，没毛病（大多数）
可以参战，还有提升空间（较少数）
还不能上战场，但还有希望（很少）
纯属浪费子弹，考虑安排到炊事班（罕见）
基于对各训练科目的九项胜任力打分，确实有利于对飞行员训练水平的追踪，可以较为清晰的判断一个飞行员当前的水平，以便提供更有针对性的教学。
理想很丰满，现实很骨感......，改革带来了令人头疼的新问题：CBTA的评分方式令教员和检查员的评分表格填写量巨大，如下图，每个科目都需要按九项能力逐一评分，虽然个别能力可以忽略，但总量依然庞大。
基于纸张的胜任力评估，导致教员、检查员们深陷胜任力矩阵的汪洋大海，目光离散、手疲劳、指纹磨损，几番操作后还能否认真教学令人怀疑。
于是有人提出，能否和以前一样，把最后的表格稍微改一下，九项能力各打个总分就行？这样的缺点是，缺陷对应的具体科目不清楚，时间长了这个数据失去价值。
如果按阶段呢？起飞阶段打一遍，巡航阶段打一遍？这样的话，上面两种方式的缺陷兼备，得不偿失。
上面的方案都是基于蔡伦以降根深蒂固的纸张思维，电子时代应该采用电子思维，一如乔布斯所为。
这也是为什么PLM路线图第一阶段要实现电子化。电子化绝不是在PAD上干纸张的活儿。
哈希来了
电子化很适合规模化管理、异地管理，但也有其固有缺陷。如果是纸张记录，一旦放入保险柜存放，篡改的可能性就很低；电子记录容易访问、方便分发，也就容易被攻击篡改，无论是分发副本、数据库还是后台log。
解决办法是电子签名或者区块链技术，其原理是将数字档案压缩加密为一个字串，称为哈希（hash），然后将哈希交给第三方存证，这叫电子签名；交给多方存证，这叫区块链；古人称一言九鼎。具体可看：
名词乱炖之区块链哈希是基础，解决了电子系统的可靠性，接下来，解决矩阵的汪洋大海，需要另一个大神来加持：JSON。
JSON
JSON: 全称JavaScript Object Notation，即JS对象简谱 , 是一种轻量级的数据交换格式。
它不需要绘制大量表格，不需要填写大量重复而不重要的内容，它可以针对任何层级，既可以针对科目，也可以针对阶段，还可以针对整场训练。
{
'日期':'2023-6-9',
'机型':'A-320',
'胜任力':['知识','人工','自动','程序',{
'阶段': '巡航',
'科目': '单发',
'问题': '关错发动机',
'得分': '2'
}
'工作量'，'情景意识','决策',
'领导力'，'沟通'],
'加课':{
'场次':'2场',
'教员':'李四'
}
}
上面是一个完整的JSON实例。不过这是给IT工程师看的，飞行员看到的应该是一个漂亮的标签。
例如，某一场训练全是蹲起落，就可以针对整场训练填写主要问题；
某一场训练中，紧急下降科目中某些问题比较突出，可以针对这个科目填写主要问题；
如果是一场训练中，多个进场组织都很忙乱，也可以针对阶段填写工作量管理的问题。
这样一来，教员可以有针对性的填写任意科目、阶段或整场发现的问题，并做出几项能力方面的评估，节约大量时间，把主要精力回归到教学中。
简单来讲，使用JSON就像使用一个标签，一旦发现有5分、3分、2分、1分的情况，便将这个分数和说明、处置情况写入标签，插入相应科目、阶段或者整场训练，所有的4分都不用理会。
如果习惯看矩阵，IT工程师可以轻松将JSON还原为矩阵；
如果需要分析，也可以把历史JSON整合，实现表格化或可视化都很方便。
JSON还具备便于存储，易于跨平台、跨系统，传送方便等优势。
试想一下，当一个人放机长时，考官面对他历史上100场训练，每场200个数据组成的矩阵，或者基于327个JSON的可视化图形，会选择哪一个？
EBT并不复杂，CBTA也很好理解，哈希和JSON只是手段，用于扫除新道路上的障碍，祝愿大家的训练越来越实事求是。
Keep it Simple,Stupid
