真实航路：迭代篇
六月底，我把 BravoFinder v3 的第一个完整版本写完时，它已经能做一件前两版从未真正做到的事：从机场的真实离场程序上路，沿有方向、有高度限制的航路飞行，再从真实进场程序下路；搜索给出的不是地图上最短的一条折线，而是一组至少在数据与模型意义上可提交、可解释的候选航路。
那时我以为，最难的部分已经过去了。
一个半月以后再回头看，初版更像是搭起了一副正确的骨架。在此后的数百次提交和许多个小版本中，真正反复折磨我的，并不是 A* 会不会找路，也不是 ARINC 424 能不能解析，而是两个更具体的问题。
第一个问题是：程序和航路网到底在哪里握手？ 一条 SID 或 STAR 会经过许多定位点（fix），其中哪些才是程序正式指定的交接点，哪些只是程序内部路过的点？发布入口本身不在航路网上怎么办？机场没有 STAR 又怎么办？如果搜索器为了省几十海里，把飞机一路沿航路送到跑道门口，再挂上一截几乎为零的 STAR，数学上更短，航空意义上却明显不对，我们该怪谁？
第二个问题是：当程序已经算对了，凭什么相信自己把它加速对了？ 性能分析工具显示的 1% 真的是 1% 吗？高速缓存未命中率下降是不是就意味着更快？一种理论上能减少八成节点扩展的方案，做成可部署版本以后为什么反而更慢？一项省下几兆内存的改动，如果会让等价候选的顺序跨版本漂移，它还算优化吗？
这一个半月里，迭代压力也不再只来自我自己对着导航数据找茬。引擎开始被嵌进别人的产品：有人直接链接它的静态库，有人提出上层运控真正需要的过滤规则，也有人送来第四个数据加载器。一个原本由作者、数据和算法组成的闭环被打开了。外部使用不会替我做设计，但它会很诚实地告诉我，哪些问题在真实产品里最先疼。
这篇文章不要求读者看过上一篇。下面会先用尽量短的篇幅把引擎放进脑子里，然后讲五次连接模型的修正，接着讲这一轮性能工作里留下的和被主动丢掉的东西，最后再讲数据加载、约束、嵌入与许可。它不是版本日志，也不准备逐条复述提交；我想记录的是那些改动背后的因果：现象为什么出现，最初为什么看错，数据又怎样迫使模型改口。
