1. 300小时 VS 8000小时
我很小的时候就听说过尤里·加加林的名字，知道他是人类历史上第一个进入太空的。后来读一些科普书，又知道他是非常优秀的歼击机飞行员，也为他最后死于飞行事故而惋惜不已。
直到最近，我才知道他在进入太空之前，总共也“只有”不到300小时的飞行经验。我很小就知道，朝鲜战争期间，美国不少“王牌”飞行员都已经有几千小时的飞行经验了。后来美国从试飞员中选拔宇航员，“起步门槛”就是至少拥有1500小时的飞行经验，实际上很多人都飞行超过2000甚至3000小时。
举例来说，美国第一个进入太空的宇航员Alan Shepard，已经拥有超过8000小时的飞行经验，其中喷气机的飞行经验超过3700小时。而第一个登上月球的宇航员Neil Amstrong，在入选NASA之前也有超过2400小时的飞行经验。
苏联送上天的第一名宇航员，其飞行小时数只有美国同行的几分之一甚至几十分之一，这种对比实在是很惊人。
是因为苏联没有那么多优秀的飞行员吗？
不是，是因为苏联和美国在太空竞赛时有不同的工程指导思想。
2. 同样的问题，不同的解法
今天我们看飞行器上天，宇航员漫步，总觉得稀松平常——“无非就是失重环境嘛，你看现在零重力座椅都快成汽车的标配了”。话是这么说没错，但我们之所以觉得稀松平常，是因为我们已经看多了航天的画面。回到20世纪50年代，探索太空对全人类来说都是全新的话题，充满了未知数。
一个显著的问题是：人在失重环境下到底会怎么样？会不会神智错乱？会不会反应迟缓甚至失去知觉？
在当时，谁都没有这样的经验，谁也无法回答这样的问题。
考虑到当时的航天器只能装载一个人，没有多人“互相观察、互相协助”的可能，那么，怎样选择这个人，就非常重要。
为了保证现实的可行性，苏联人的航天计划里，人的角色主要是“乘客”，所有的一切，能够依靠科技的尽量依靠科技，尽量减少“人”的不确定性。一个突出的例子是，为了防止错误操作，紧急逃生计划是不会提前告知宇航员的。逃生计划的操作步骤被列在纸上，封进信封，贴在飞船里。如此，确保只有在真正紧急的情况下，宇航员才可以执行它。
这样，就可以理解为什么加加林只有不到300小时的飞行经验了，因为“乘客”并不需要太多的飞行经验，而在其它方面，加加林几乎完美契合了各种要求，比如身材不能太高大，以及政治上必须绝对可靠，出身于贫苦家庭……
加加林成了人类历史上第一个进太空的人，这就说明苏联当局航天计划的可行性。那么，同样在积极筹备太空竞赛的美国人，是不是也应该效仿呢？
在科技史上，“殊途同归”的故事并不罕见。同样的问题，往往有迥然不同的解决方案，而且同样有效。
我以前提过太空竞赛早期，美国和苏联的飞船形状。因为不知道飞船再入大气层时会如何翻滚，苏联把飞船设计成了球形，这样就能始终保持稳定。而美国因为有条件进行多次试验，确定了钝头圆锥形的飞船形状。结果，无论是球形还是扁锤形，都确实能顺利完成再入。
3. 平行轨道的交会
回到加加林的问题，美国一开始也是采取了与苏联相同的思路。大家都知道，二战后期美国俘获了纳粹德国火箭专家冯·布劳恩（Von Braun），他后来在美国主持设计了多型火箭和导弹，也培养了最早的一批航天科技人员。
对冯·布劳恩的团队来说，“进入太空”和“载人”基本没什么关系，他们关心的重点是“火箭怎么飞上去”，甚至“载人”根本就是负担——如果不载人，根本不需要费神去解决“怎么回来”。
不过，美国的航天计划需要综合陆军和空军的力量。冯·布劳恩之前的工作都属于陆军，一旦空军的人进来，他们就带来了全新的诉求：宇航员必须有足够的操控权。空军的人非常排斥把飞船叫成“太空舱（Capsule）”，因为那会让公众觉得宇航员只是“乘客（Passenger）”，他们更偏爱的术语是“飞船（Vehicle）”和“宇航员（Astronaut）”。
来自空军的这种诉求给冯·布劳恩的团队造成了不小的困扰。用其中一人的话说，“火箭和载人航天，原本像两条平行轨道，本来相安无事，现在难道要让我们跳车？”。
确实，如果工作文化是“自上而下”的，那么空军的这种诉求多半会被视为无理取闹，如果不是，那么最终结果就取决于多种因素的综合博弈。
更何况，空军的诉求既有本位主义的考量，也有现实的因素。
实际上，“给予宇航员更多操控权”的试验并不成功。冯·布劳恩团队设计的火箭和导弹已经有相当的成功率，让宇航员操控火箭飞上天空却被证明是死路一条：火箭在上升阶段加速度巨大，宇航员几乎处于生理耐受极限。更何况，在各级火箭分离的阶段还有巨大的震动，此时几乎不可能精确操纵。所以，让火箭“自动”飞向太空，是现实的选择。
但是美国宇航局（NASA）也发现，自动化并不是唯一的解决方案。为了保证“阿波罗”项目的成功，需要先在“双子星”飞船上演练飞船的对接和分离。在“双子星”飞船演练中发现，太空对接和分离涉及的因素太多，完全无法在地面模拟，此时完全依靠计算机是不行的，必须有宇航员的密切观察、实时修正——这个给了宇航员很多的信心，“你看，人终究不会被计算机取代”。
此外，在飞船返回时，必须先在太空精确对准再入大气层的位置，这样才能保证飞船可以降落在预定的位置。在极快的速度下，在遥远的距离上做精确的指向，这种的要求超过了人类感知的极限，又只能依靠计算机来完成。
在载人航天的目标下，一方面是各方势力互不相让，一方面是技术能力和生理能力各有长短。最终结果就是，“来自五湖四海的力量，为了一个共同的目标，走到一起来了”，这就是NASA总结的man in the loop的思想。
4. Man in the loop
Man in the loop，翻译成中文就是“人在回路中”。“回路”很好理解，大致等于前些年流行的黑话“闭环”。关键在于man in the loop，人是“镶嵌”在回路中的，他与计算机并不是简单“谁说了算”或者“谁听谁的”的关系。人既要约束回路中的其它环节，也要被回路中的其它环节所约束。
在飞船发射时，人基本是被动的，火箭按照预定程序发射升空；在太空执行对接和分离时，离不开宇航员的观察、修正、调整；在返回时，又是计算机主导。
Man in the loop，人只是系统的一个环节，控制权在各环节之间不断转移，为的是完成共同的目标。
“阿波罗”飞船的导航计算机AGC（Apollo Guidance Computer）的设计，同样是这种思想的体现。
最早设计时，对AGC的要求是“全程自主，且高度可靠”。“全程自主”意味着飞船搭载的导航计算机可以在不需要外界帮助的情况下，独立完成飞船的定位和航向设定。“高度可靠”意味着导航计算机必须有足够的可靠性和冗余设计。
当时正是集成电路刚刚兴起的年代，集成电路在重量、能耗、处理速度上都显著优于传统的电子管设备，但可靠性上则还没有足够的把握。为了提供冗余保障，AGC被设计为29个独立模块，对每一个模块，“阿波罗”飞船都携带了一个备件，以便随时更换。这仍然是man in the loop的思想，只不过，回路中的人承担的是“计算机维修工”的职能。
不过，这种决策这引起了宇航员的极大抱怨，他们认为自己应当专注于飞行，而不是“学习修计算机”。美国的“太空第一人”Alan Shepard曾讽刺说：“学吧，学吧，干脆让我们也学点外科知识，这样万一在太空出事，飞船里还可以动手术救命”。
在1963年5月“双子星”飞船的最后一次飞行中，尿液收集器出现了问题。返回地面之后发现，渗出的尿液带来了水分腐蚀了电路板。技术人员这才想到计算机必须密封，防止水分的侵蚀，之前“独立模块组合”的设计就不具备实用性，计算机必须是整体密封的。既然整体密封，“更换模块”就没有可能，“现场维修”更是无从说起。
于是NASA去掉了宇航员的“计算机维修工”的职能，但没有改变man in the loop的模式。NASA 最终形成的方案，不再追求飞船完全自主，而是把控制权分散到了飞船、地面与宇航员之间：飞船的定位由遍布全球的监测站完成，导航轨迹的监控、设定，以及飞行的决策，主要由位于休斯顿的飞控中心（Flight Control）完成，飞船上宇航员的主要职责是监控导航计算机的运行状态，执行地面的指令。
这里有个小插曲，这种控制方式要求非常可靠的协作和通讯。按照原始设计，飞船应当搭载电传打字机，这样可以短时间内把一系列指令打出来交给宇航员，之后慢慢操作。但是在综合考虑了重量、性能、可靠性之后，这个方案被直接通话所取代了，密集的通话也给后人回顾“阿波罗”留下了丰富的素材。
Man in the loop不只是静态的职责分配，而能够适应动态演化。因为系统需要综合各方的优劣，针对不同情境、不同约束，调整任务的组成和职责的分配。在这个过程中，人的角色也在被不断重新定义。
在后来的登月任务中，它也确实发挥了重要作用。
5. 成功案例：阿波罗11
在“阿波罗11”飞临月球时，飞船的计算机忽然出现报警信息，代码先是1202，之后是1201，并且反复出现。这让所有人都非常紧张，如果计算机出现故障，很可能必须立刻中止登月程序，以保障安全。
好在执行登月任务的是Neil Armstrong，他在训练阶段就表现出出奇的冷静，总是能比其他人更沉着地应对各种问题。于是，Armstrong只是向地面飞控中心报告了问题，并耐心等待答复。
飞控中心的导航指挥官(GUIDO, Guidance Officer) Steve Bales只用了几十秒就做出了建议：“不要紧，按原定方案执行”。因为Bales判断出，计算机并没有出问题，报错的原因是飞临月面时，交会雷达向计算机发出了大量数据，超出了预期——当时的计算机运行频率只有约1 MHz，内存只有几KB，短期内无法处理这么多的数据。
飞控中心的总指挥Gene Kranz迅速确认了Bales的意见，发出了“Go”的指令。于是登月继续进行，计算机自动寻找预定着陆点，自动计算下降轨道，一切都按计划进行。
但很快，Neil Armstrong透过舷窗发现，预订的自动着落点遍布石头，地形崎岖，并不适合飞船降落。于是，他开始手动控制，自行寻找着陆点。
这里说的”手动控制“，并不是像飞行员开飞机一样，赋予宇航员彻底的飞行控制权，不能“想怎么飞就怎么飞，想飞去哪里就飞去哪里”。
在”阿波罗11“飞船上，Armstrong启动的是P66着陆程序。这同样是一条预设的程序，容许宇航员手动控制水平移动，调整下降点，同时计算机仍然负责姿态稳定和基础导航。这也是飞船控制系统设计之初就定下的一条原则：如果开启宇航员手动控制模式，计算机仍然必须保证飞船在“受控”状态下。现在的情况是，Armstrong通过肉眼观察，决定“飞去哪里”，再由计算机执行“怎么飞去那里”。
在发动机燃料接近耗尽时，Armstrong发现了一块相对平坦的陆地，准备进入最后的着陆。此时发动机吹起了大量的月壤，模糊了视线。他回忆说，“很像在雾中着陆”。但是，计算机仍然准确知道此时登月舱的状态和高度，所以能保持登月舱平稳下降。最后，探针接触到地面，发动机自动关机，登月顺利完成。
Man in the loop，其实是man must be always in the loop。因为loop的目标是保证“登月成功”，无论是飞船搭载的计算机，还是登月舱的宇航员，或者是地面上的飞控中心，都是loop中的一员，都应当忠实承担自己的责任，同时受到其它环节的约束，与其它环节配合。
6. 前事不忘，后事之师
长期以来很多人都强调“闭环”，强调“系统思维”，但仍然对man in the loop的说法感到新奇，因为它特别强调了man。之所以会这样，在我看来，恰恰是因为长期以来大家习惯了“两分法”，把人和计算机，人和“系统”隔离开来——当我们说“配合”的时候，往往想到的是“人与人的配合”，“系统与系统的配合”，很少想到“人和计算机的配合”。
很多人（当然也包括我在内）一直忽略的是，在系统中引入“人”这个角色，既带来了便利，也带来了变数。Man in the loop，就是在系统设计时，充分考虑“人”的角色和复杂性，同时也要让“人”学会理解自己在系统中的角色。
从这种视角出发就可以看到，今天人类面临的许多技术问题，仍然与man in the loop的思想有关。
我最先联想到的例子就是自动驾驶。许多人都同意，“自动驾驶”是充满前景的未来，但同时，“自动驾驶”仍然存在很多问题。
驾驶的终极目的是什么？我想一定不是“让计算机开车”，而是“安全的驾驶”。既然大家都承认，目前计算机还不能做到彻底安全的自动驾驶，那么人（司机）的角色就仍然不可或缺。换句话说，我们仍然没有脱离man in the loop的情境。
回看成功的man in the loop的案例，比如“阿波罗”登月计划，人在其中扮演什么角色？虽然人的职能在不同场景下不断重新定义，但是人始终需要承担自己的职能，始终需要需要不断观察、保持判断能力。这样，在人需要介入的时候，才能够顺利、称职地接手。
可惜，今天的“自动驾驶”的许多宣传，让很多人产生了“设定目的地之后就可以放心睡大觉”的幻想。现实是“人仍然在回路中”，但错觉是“人不必在回路中”。
既然“人不必在回路中”，人就不必保持清醒和关注，可以放心对待自己的分心、倦怠。在现代航空里，这种情境已经有不少对应的概念，即mode confusion或者out-of-the-loop performance problem。
更关键的是，在man in the loop中，控制权在转移时并不是“硬切换”，而是有“双向确认”的过程，确保整个过程的平滑。飞行训练里，这种场景很常见，当控制权从A转交到B时，需要三次对话：
A: You have control（我准备让你接管）
B: I have control （我已经接管）
A: You have control（我确认你已经接管）
实际上，在“自动驾驶”中也有这样的流程。
我们都知道，“自动驾驶”的启动是有条件的。只有当车载计算机准备完毕，提示可以接管汽车控制权时，司机才可以启动“自动驾驶”——这恰恰是一个双向确认的过程。如果车载计算机没有准备好接管，如果司机没有主动授权，汽车都无法进入“自动驾驶”模式。
可惜，这样的流程只覆盖了一部分场景，在另一部分场景中，事情并不是这样。
最常见的例子就是许多事故发生后，汽车厂商声明“在事故发生前xx秒，已经退出了自动驾驶模式”，言下之意就是“系统免责”。但是仔细思考就会发现，这种时候的“交接”，完全看不到“双向确认”的影子，而只有“单方面退出”。因为车载计算机根本不管司机是什么状态，有没有准备好接管，也不需要与司机确认是否要接管，甚至都不必关心司机有没有足够的时间来接手，只要自行宣布“退出自动驾驶模式”，转瞬之间，控制权和责任就转交给了司机。
也许“赠送”或者“投掷”，比“转交”更适合描述这个过程。
而这种“协作方式”（如果能叫“协作”的话），其实对“人”提出了比计算机更高的要求，因为它假设人必须时刻保持警觉，随时准备接手。而我们都知道，人类大脑是有生理极限的，它无法长期维持监督状态，也需要时间来切换工作模式。在航空史上的多次事故，都已经证明了这一点。
具体到“自动驾驶”，这种问题要如何解决？我没有答案。也许，只有我们要等到计算机足够强大，能够彻底摆脱man in the loop模型的那一天，才能放心。
但是在那一天到来之前，保持小心谨慎，不忘自己是loop中的man，总没有错。
注：本文是Digital Apollo读书笔记的第二篇。如果你看完本文有兴趣，或许可以再翻看第一篇 读书笔记：历史的问题，从来不只属于历史。