两周的审评周期，比许致远预想的要长。头几天他还能安心地做其他准备工作，到了第十天左右，他心里开始有些坐不住了，每天路过廊桥的时候都会下意识地往隔壁楼五楼的方向看一眼。但他没有催，也没有去问。李高工说了有意见会通知，那就等着就好。催来的反馈往往不如等来的全面。

第十五天下午，通知到了。李高工亲自给许致远打了个电话，语气平和，听不出喜怒：许总师，审评意见出来了。有几条需要修改，你过来一趟拿意见单，有些地方可能要当面沟通。

许致远挂了电话就过去了。李高工递给他一份三页纸的意见单，上面列了九条审评意见，其中六条是文字表述层面的修改建议，三条是技术层面的问题。技术问题里有一条让许致远格外留意，意见单上用加粗字体写着：应急程序章节未明确飞行末段若出现制导系统完全失效时，弹体安全处置的自动决策逻辑。建议补充完整流程或在后续专项评审中单独说明。

李高工坐在对面，等许致远看完，说：前面六条你们自己回去改就行，不需要再送审。第三条这条，审评组觉得你在大纲里写得不够清楚。不是说没有提，而是流程链条里缺了最后一环的决策依据。飞试毕竟是风险最高的阶段，末段出问题的话弹体可能在居民区附近落地，安全处置的逻辑必须闭环。

许致远点了点头。他确实在大纲里写了末段制导异常的应急程序，写了会启动弹上自毁系统，但他没有写自毁系统在什么条件下启动、由什么信号触发、决策时间窗口有多长。这些细节写在分系统层面的设计文件里，但审评组要求在顶层大纲中至少有一个明确的描述。

我理解。这条我来补，三天之内把补充说明发给你们。许致远说。

李高工说，然后许致远拿着意见单走出了办公室。

回去的路上，许致远在廊桥里站了一会儿，仔细把那条意见又读了一遍。它没有否定他的方案，只是要求他把最后一个环节写清楚。但许致远意识到，这个最后一环其实很重要——制导完全失效属于极端情况中的极端情况，概率极低，但一旦发生后果就严重。设计弹上自毁逻辑的时候需要平衡两个东西：触发太敏感，可能在误判的情况下把一枚本来还能挽救的弹打掉；触发太迟钝，则可能在真正需要处置的时候错过了最后的安全窗口。

许致远回到工位，把原大纲里应急程序那一章翻出来，又调出制导组之前提供的自毁系统详细设计文档。他花了一整个下午把两条信息链对接上——从飞控计算机检测到制导信号异常开始，到故障判定算法确认完全失效需要多长时间，再到自毁指令发出的时序窗口在弹道末段的哪个区间。他算了一组数字，写在草稿纸上，又自己反复验算了两遍，确认数字之间没有矛盾。

第二天他找到了周凯，两个人在会议室里把末段自毁决策的全流程从头到尾过了一遍。周凯负责制导系统，是最了解飞控软件的人。他把那个决策树的每个分支都摊开来给许致远看，讲清楚哪一级的判定由硬件看门狗来做，哪一级由软件逻辑来判断，哪一级需要地面遥测确认。许致远一边听一边记，把那些技术细节提炼成顶层大纲里需要的简练表达——不说硬件的型号和软件的算法，只说什么条件下、多长时间内、做什么动作。

还有一件事。周凯在讲完所有流程之后补充了一句，自毁系统的触发指令是双通道冗余的，两个独立的引爆电路分别走不同的电源和不同的信号路径。即使飞控计算机本身完全死机了，还有一个独立的时序模块可以在预定时间窗口内自动发出指令。这个是我之前没写在分系统报告里的，你最好也提一笔。

许致远在笔记本上加了一行字。好，这个加上之后链条就完整了。

他回到工位上重新修改大纲的应急程序章节。补写了整整两页新内容，把末段制导异常处置的全链条写清楚了——从异常检测到故障确认，再到自毁决策的触发条件和时序窗口，最后到执行机构的冗余配置。写完之后他又读了三遍，确认每一个时间节点都有数字支撑，每一个条件判定都有明确的边界。