制造与航空：工程师必须理解生产

纳比尔·库雷希（Nabeel S. Qureshi）在 2015 年夏天加入 Palantir，职位是前线部署工程师。他后来回忆，自己在图卢兹住了一年，每周四天进入空客工厂。客户要解决的是 A350 扩产：他们把工单、缺件和不合格项连成界面，让使用者查看别的团队进展、部件与计划，并检索过去怎样处理质量问题。¹

这些词不像人工智能宣传中的主角，却决定了一件更直接的事：下一道工序能不能开始。

这段当事人回忆留下了两项真实设计选择：把当前的跨团队依赖放到一起，把历史质量处理变成可检索的依据。前一项帮助定位谁还在等谁，后一项帮助使用者寻找已有处理经验。回忆没有披露每项功能的个人决策分工或逐次验收，却呈现了一种具体的扩产路径：先帮助现场识别和处理生产中的阻碍。

这也是制造业给 FDE 的第一道考题。会写程序，只能保证系统按照某种定义运行；理解生产，才能发现定义本身是否遗漏了关键条件。本章沿着空客的制造合作向外看，走到供应商、航空公司和维修管理，再用中国化工装置的连续运行作对照。它们属于不同环节，也不是同一支 FDE 团队完成的同一个项目。贯穿其中的问题是：数据怎样获得足够明确的含义，让有责任的人采取行动？

把“可以开工”问清楚

2018 年 7 月，空客介绍了面向供应商的 Skywise 应用。其中，Dispatch 是帮助供应链计划对齐的应用，用于连接供应商生产计划与空客需求，关注缺件、交付和装配安排；Premium Aerotec 是这一应用的试点伙伴。公告还说明，早期参与者经过选择，参与意愿和数字准备程度都是条件。²

这提供了一个理解制造软件的切口。客户的需求表和供应商的生产表，即使都准确，也未必回答同一个问题。前者希望知道某个日期能不能用到部件，后者可能只记录某个日期能不能完成制造。两者之间还有运输、检验、配置匹配，以及发生异常之后由谁处理。直接把两个日期排在一起，可能得到整齐的图表，却没有消除真正的分歧。

下面构造一个贯穿本章的工厂教学情境，并非空客内部记录：一家工厂准备安装一套组件，仓库显示已经到货，班组却说不能开工，因为检验尚未完成。如果工程师把“库存数量大于零”写成开工条件，系统就会催促班组做一件目前不能做的事。班组若不断解释、不断忽略提醒，再先进的界面也会变成额外负担。

解决办法不是给“已到货”换一个颜色。工程师需要和仓库、检验、计划及现场负责人一起，把一项笼统的承诺拆开：部件是否实际到达？身份是否正确？检验是否完成？是否分配给这项工作？前一道工序是否已经交接？每个答案还要附上确认者和确认时间。这样，计划人员才能知道应该追运输、追检验，还是调整任务顺序。

继续这个例子，假如检验已经完成，但数据尚未回传，软件也不能直接把它判为实物不合格。这是两种不同的问题：一种需要处理部件，另一种需要核实记录。若系统把它们合成同一种红灯，现场就必须重新调查每条警报。所谓数据整合，只是把调查工作从找表格，搬到了解释红灯上。

因此，一个可以讨论和验收的工程流程，应当从具体异常开始：系统发现条件缺失，说明缺的是哪个条件，把它交给能够核实的人；核实之后，保留“记录过期”“检验未完成”或“部件确有问题”等不同结论，再由有权安排生产的人决定下一步。采取行动后，结果应回到系统，让下一班人员看见问题为何关闭。

这个模型把软件与责任连接起来。程序负责找出需要处理的差异，专业人员负责判断差异的含义，生产负责人负责在允许的条件下重新安排工作。三者可以合作，却不能用一个“智能推荐”按钮把责任混在一起。工程师驻场的意义，也由此变得具体：他需要看见一个字段如何改变别人的工作，而不仅是听清客户希望增加哪个字段。

提醒本身也有代价。在这个教学例子里，如果每个等待检验的任务都自动要求立即处理，系统只是把计划压力转移给了检验人员。为了响应更多提醒，他们可能不断切换工作，而真正紧迫的任务仍在队列里。设计者因此需要与生产负责人确认优先顺序，并允许接收者说明为何暂不处理。衡量效果时，要看整项工作的等待是否缩短，而不能只看发出提醒的部门是否更快清空了自己的待办。局部报表改善，有可能只是把等待换了一个承担者。

同一架飞机，为什么会有几种状态

飞机离开工厂后，数据与实物之间的关系并不会自动稳定下来。一次部件更换、一次软件更新，都可能改变“这架飞机现在是什么样”。制造环节关注装配能否继续；维修环节还需要持续确认设备的实际配置。这是另一个业务问题，但它让“理解现场”有了更精确的技术含义。

空客的配置核对工具 Configuration Cockpit 提供了一个公开可查的流程。工具自 2024 年 5 月向 Skywise 客户提供，2025 年 6 月扩展到非 Skywise 客户。输入可以来自维修记录，也可以来自机载配置报告，随后与空客掌握的已报告配置及允许部件清单进行核对。结果除了匹配和错误，还保留“需要人工分析”的状态。³

这里至少存在三种不同的信息来源：运营者的维修记录、飞机生成的配置报告，以及制造商掌握的配置依据。它们分别来自不同活动，不能因为都描述同一架飞机，就假定永远同步。系统的工作正是让这些差异显现，而不是在导入数据时悄悄选一份作为唯一答案。

对非技术读者来说，可以把它理解为核对一件复杂设备的三份档案：账上记了什么、设备报告了什么、规则允许什么。第一份可能需要更新，第二份需要正确解读，第三份决定前两份即使一致，是否仍存在问题。数据一致与状态正确，是两个不同层次的判断。

“需要人工分析”尤其值得注意。如果工程师只追求自动判断比例，就可能把不能自动确定的情形强行归入通过或失败。前者会掩盖尚未解决的问题，后者会制造没有必要的警报。保留第三种状态，相当于承认系统的能力边界，并把这条边界变成可执行的工作分配。

不过，一个状态本身还不等于流程已经完成。站在交付者的角度，还应继续追问：它进入谁的工作队列？处理者能看见哪些原始依据？是否知道判断适用哪一架飞机、哪一个部件？如果暂时无法判断，下一步需要补什么证据？这些实施问题，需要在各航空公司的实际安排中继续确认。

同样重要的是，不要让“已匹配”承诺它并未检查的事情。配置核对通过，只能回答这次核对所覆盖的问题，不能替代所有维修判断。空客的技术文章明确强调软件部件号的检查，并把该工具定位为额外的安全检查；操作人员应完成的检查并未因此消失。³

这对工业 FDE 提出了一项容易被低估的要求：他不必代替每一位领域专家，却必须知道系统在哪些地方必须停下来等待专家。一个可靠的应用，应当让使用者知道它为什么给出结论、还有什么没有判断。否则，现场人员要么过度信任结果，要么必须从头复查，软件在两种情况下都没有真正承担好辅助工作。

责任也不能只在上线时分配一次。规则变化之后，旧结论可能不再适用；数据重新同步之后，原有差异可能消失。维护系统的人需要知道何时重新检查，业务负责人需要知道何时重新确认。这里的维护，既包括程序继续运行，也包括程序使用的定义仍然有效。生产环境中的“坏了”，有时表现为程序顺利执行了一条已经过时的规则。

预测之后，工作才刚刚开始

如果说配置核对解决的是“现在是否一致”，预测性维修试图回答的则是“未来可能发生什么”。2018 年 3 月 27 日，easyJet 宣布与空客开展五年预测性维修合作，并披露此前试点聚焦 85 架飞机的三类技术问题。按航空公司的说法，系统预测了 31 次技术故障，工程人员得以提前移除部件，至少 31 个原本可能受影响的航班因此按计划运行。⁴

这个故事里，真正把分析变成运营结果的动作，是工程人员在故障发生前处理部件。预测提供了机会，行动才利用了机会。

不妨把这段过程再向前推演一步。假设某个部件的异常迹象被提前发现，航空公司还需要判断：警报是否值得行动？飞机何时有合适的维修窗口？相应的备件和人员是否可用？处理完以后，发现的实际情况是否支持最初判断？这些问题没有同时得到解决，预测就可能停留在屏幕上。这里是对实施条件的分析，不是补写 easyJet 未披露的工作记录。

由此也能看出，为什么“提前多久”不是越长越好这样简单。提前量太短，组织来不及安排；提前量很长但不确定性很高，又可能引发不必要的检查和更换。合理选择取决于可采取的行动，以及错误行动和不行动分别会带来什么代价。FDE 若只听数据团队解释模型准确率，就还没有理解交付目标；他需要知道维护团队能怎样使用这个预测。

专业知识也不会因为数据汇集起来而自然出现。2018 年 7 月，部件供应商利勃海尔在合作公告中，把自己的部件知识与 Skywise 数据分析并列，说明试点用于研究机载系统的在役表现，并探索改进运行建议。⁵ 这段材料的价值，在于让供应商专家重新进入故事：谁设计、制造和服务这些部件，谁就可能掌握解释异常所必需的知识。

跨公司协作因此不是简单地扩大数据池。若某种信号出现了变化，算法可以帮助定位，供应商专家可以解释部件机制，航空公司的维修人员则知道什么安排可执行。要把三者连起来，交付团队必须让问题携带足够的上下文流动：是哪一类设备、怎样的使用条件、此前进行过什么处理。上下文缺失时，更多数据有时只会产生更多需要补问的问题。

easyJet 的“31 次”也应当在这个层次上阅读。它是客户披露的试点结果，不是公开的独立对照实验。公告没有提供全部误报、漏报及对照设计，因而不能据此算出整个机队的净收益，更不能推定所有技术延误都可以消除。承认这一点，不会抹去试点价值；它只是把“已经看到可用的机会”与“已经证明全面经营回报”分开。

可以用一张教学表把缺失的分母补出来。假设某设备团队在同一个四周观察窗口内发出二十条警报，已逐条去重；以下数字完全虚构，与 easyJet 无关。

若只报“六次发现”，读者看不到从二十条提醒到九次检查的损耗。教学记录另列调查总计八小时、为检查预留但未使用的两件备件各占用七天；这些代价也要计入，不能只看发现了六个需处置问题；是否完成处置、产生什么结果，还需另记。对未发警报却后来出故障的设备，还需要另建记录，才能讨论漏报。已填采用记录与空表保留了每一步的分母及未完成原因，帮助团队判断下一步应改模型、通知、资源安排，还是停止扩大范围。

连续运行的装置，不能只照搬工单经验

飞机装配和部件维修，通常可以围绕一项工单追踪条件。连续运行的化工装置提出了另一种要求：上游参数变化时，下游仍在生产，判断和动作发生在不断变化的过程中。

中控技术公开的广西华谊能化案例提供了这种对照。公司描述，项目连接了九个核心业务系统、近二百个接口；其TPT时间序列大模型用于硫回收等装置的趋势预测，并与计划调度系统协同。案例还区分了工艺参数的预测、控制参数优化，以及成本效益测算。⁶ 这些是供应商对工程范围的陈述，尚不足以独立证明经济收益；公开材料也没有确认交付团队使用FDE职称。

所谓时间序列，可以先理解为按时间排列的温度、压力等测量记录。预测这些数值怎样变化，与用语言解释一份操作手册，面对的输入和失败方式不同。这里不能把所有模型都当作聊天模型，也不能因为几个应用都叫Agent，就推断它们有相同的动作权限。

从实施角度推演，团队至少要分清三件事：预测提醒操作员注意什么，优化程序建议改变什么，以及控制系统实际上允许改变什么。预测准确，未必来得及行动；建议改善某个局部指标，也可能影响另一道工序。具体限值、联锁与操作规程应由具备资格的生产和安全团队确定，本书不替真实装置给出控制参数。

这也使验收问题发生变化。航空维修教学表问警报有没有走到可执行的检查；连续装置还要问，同一负荷与原料条件下是否稳定、异常时如何接管，以及局部优化有没有把代价推到其他环节。若生产条件或价格同期改变，财务结果便不能只归因于模型。现场知识的价值，正在于知道哪些条件必须一起比较，而不是收集到更多测点就宣布已经理解生产。

离开现场之后，什么可以留下

空客在 2017 年 6 月发布 Skywise 时，已经把内部制造、工程与服务的合作经验，引向航空公司和供应商。⁷ 从一家企业的问题，走向多方使用的平台，这是工业 FDE 模式中很有吸引力的一步：一次现场工作，能否留下不止一次使用的能力？

工业软件能否换一个现场继续使用，关键在于规则是否仍适用。某个部件能否替换另一个，某道工序完成后谁可以签认，需要与具体设备和生产安排一同确认。可配置的规则还应有负责人解释其用途，不能只藏在现场工程师的一段条件判断里。通用方法参见 第19章 产品复用和 第21章 客户接手；这里先看工业记录中特别重要的时间问题。

回到组件安装的情境。如果检验要求改变，今天“可以开工”的条件与上个月不同，复盘旧任务时就不能直接套用今天的规则。需要找回当时部件的状态、当时适用的条件、作出判断的人，以及后来发生了什么变更。否则，原本合规的决定可能被新规则重新标为异常，过去的失误也可能被新规则掩盖。保存这一对应关系，会增加建设工作，却能让质量与生产人员围绕同一次任务核对依据，而不是各自拿着不同日期的截图争论。

跨企业复用还有商业条件。Palantir 在截至 2024 年 9 月的季度报告中说明，2016 年开始的空客合作逐步发展为 Skywise 平台合作，同时限制了它独立向某些航空公司及空客竞争者提供平台的能力。⁸ 因此，平台越成熟、客户覆盖越广，并不必然意味着供应商可以不受限制地进入每一个市场。行业伙伴带来接近客户的机会，也可能界定可进入的范围。

本章所读材料没有公开合作的完整成本与收益分配。企业负责人仍可以追问具体责任：规则变更由谁确认，记录由谁维护，跨企业使用是否受合同限制。这些工业条件会影响合作能持续到哪里，不能仅凭同一个平台已被另一家公司采用就默认相同安排。

软件能消除哪一种等待

这些要求，是不是一个合格的内部工程团队、制造执行系统团队或系统集成商也应该做到？为什么需要把它们归入 FDE？

答案应当诚实：这些能力并不由 FDE 独占。空客早期制造合作有当事人明确的 FDE 身份记录；本章讨论的供应链、维修和运营材料，却不足以证明每一个应用都由这个岗位交付。它们帮助我们检验的是一种工作方式，而不是为同一个职位名称收集越来越长的功劳清单。

这套方式的适用条件，是问题跨越多个系统和角色，现有责任划分又不足以把软件持续改到可用。此时，让能写代码的人接近真实使用者，可能缩短发现误解和修正程序之间的距离。但如果标准系统已经满足需要，组织也有稳定的维护能力，再增加一支长期驻场团队未必划算。判断依据应是尚未解决的协作困难，而不是岗位名称是否流行。

即使协作问题解决了，物理约束仍然存在。2026 年 2 月 19 日，空客发布全年业绩时，仍明确指出普惠发动机短缺影响生产爬坡，并说明相关供应承诺问题影响 A320 系列的计划。⁹ 这不是对 Skywise 成败的评判，却足以提醒读者：航空制造中的等待，并非都来自信息看不见。

至少应分清三种等待。第一种是事情已经发生，相关人员却还不知道；第二种是大家知道问题，却没有合适的决定和协调；第三种是决定已经做出，但设备、部件、产能或运输时间仍构成限制。前两种可能受益于更好的软件和协作流程，第三种需要真实资源或物理过程的改变。软件可以帮助提前发现第三种等待、调整影响，却不能仅靠更新一张表让发动机按时出现。

回到同一项组件安装任务，可以把三种等待写进一条时间记录。下表的两列均为构造值，只为说明比较方法，不是空客或任何工厂的实测改善。假设任务的部件、检验要求、人员能力和可用工位相同，“改后流程”一列只表示一种希望检验的变化。

原流程从 08:40 到 09:10 的三十分钟属于信息等待；接下来的十五分钟属于决定等待；09:25 之后的三十五分钟则在等工位和人员。构造的改后流程里，前两段都缩成五分钟，实际开工却仍是十点。资源等待因此变长，总开工时间没有改善。这个结果不矛盾：更早知道、也更早安排，可以减少查询与临时协调，但不会自动产生一个提前空出的工位。

实际验收时，时间不能全部来自应用的刷新日志。检验人员的签认、负责人取得足够依据的时点、决定记录以及班组开工回执，分别回答不同问题。若只记录数据何时到服务器，就无法知道信息何时足以支持安排；若只记录任务何时关闭，又无法判断中途到底等什么。等待原因也应允许责任人核实，避免把未记录的阶段一律算作软件耗时。

比较真实的前后任务，还需控制任务类型、检验难度、班次和资源负荷，记录同期是否增员、扩充工位或改变供应计划。若项目只改了信息交接，就先检查相应时间是否缩短；决定变快若来自授权调整，应归入共同的流程改进。资源供应发生变化，则另列原因。这样才能看见项目改善了什么，也能看见下一项投入应该去哪里。

这个区分会改变项目目标。如果团队主要减少了查找、核对和交接时间，就应首先证明这些环节的变化，再研究它们是否传导到产出。不能因为飞机产量同时增长，就把整段增长记到软件名下。资本投入、人员、供应商和工艺变化都可能参与其中；没有对应证据，FDE 的贡献只能限定在能够解释和核查的范围内。

它也会改变工程师在现场的注意力。面对“我们需要一张更实时的看板”，值得继续调查的是：看板更新以后，谁将做出哪个不同的决定？如果没人能行动，问题可能在授权或资源；如果可以行动但依据不足，问题可能在数据定义；如果已经行动却没有留下结果，下一轮预测和安排又会建立在不完整的记录上。找到真正断开的那一步，比把所有数据刷新得更快更有价值。

从图卢兹工厂的工单，到飞机在役之后的配置核对，贯穿其中的工作，是让软件中的状态经得起下一步行动。理解生产，不要求一个工程师掌握所有人的专业；它要求他尊重那些专业如何共同约束一项决定。现场留下的最佳成果，是后来的人仍然能够依靠系统，把该做的工作做对，并知道什么时候必须停下来查清楚。