把三年压成六个月：Trinity Industries 用 AI FDE 重造铁路维修账单核对

摘要

Trinity Industries 是北美最大的租赁车队所有者之一，拥有 12 万节铁路货车的车队、制造与维修业务。CEO Gene Savage 与 Palantir 软件工程师 Ankit 演示了新产品 AI FDE（AIFD）如何重构最头疼的流程：每月数千条来自全北美各处的货车维修记录，都要逐条核对工时、成本、重复计费与正确性——按美国铁路协会（AAR）规则，发现错误后只有六个月窗口去纠正。

AIFD 的理念是「AI 替你点鼠标」：把源数据与领域专家文档交给它，它自行理解数据、推断关系、提出本体提案，在 Foundry 分支（沙盒）上完成转换与本体构建，用闭环查询自我验证，并以永久血缘（lineage）支撑 SOX 审计。随后它还能基于同一套积木生成生产就绪的应用——审计团队获得按金额排序的机会列表、一键发起调查、自动起草索赔。

Savage 的旧管理系统已 25 岁，外部报价五年半、砍到三年；如今他说「有 AIFD，我们大概六个月就能做完」。从维修账单核对到资产管理系统（AMS）与销售数据打通，这家公司看到了整整一类新可能。

正文

一、每月数千条维修记录的核对难题

Trinity Industries 是北美最大的租赁车队所有者之一：既造新车，也维护车辆，还向客户提供数字服务。其货车按美国铁路协会（AAR）的交换规则运营——车可能在北美的任何地方，一旦需要维修，就要遵循不同的程序、流程、成本与标准工时。

Gene Savage 抛出的问题很具体：每个月公司都会收到数千条货车维修记录。记录进来后，必须判断：价格对吗？工时对吗？有没有重复计费？计费是否正确？这是一个庞大的流程。如果某个趋势出了问题，公司无法快速察觉——而在 AAR 规则下，你只有六个月时间发现问题并纠正。若要把这套流程收归自建，需要把六个不同的小组拉到一起，花一年时间做这个项目——以公司现有资源，根本做不到。

更大的背景是：公司一年前启动了一个新管理系统项目，旧系统已经 25 岁。第一次报价是五年半（成本他都不愿提），第二次说三年能做完。项目已进行一年，「以我目前所见，我真希望当时就有这个工具——不是三年，我们大概六个月就能做完」。

二、「AI 替你点鼠标」：从数据探索到本体提案

这类系统与工作流建设的第一步，往往是搞清楚：哪些现有系统在做这件事？Trinity 用的是 Rail Link 加一些既有基础设施，还要与现有供应商协作——而光是弄清那些系统里有什么，就常常要拉来一群人、做大量人工探索。演示中，他们带入了与领域专家讨论过的文档：计费流程的通用参考、价格主数据（price master）在哪里、拆分人工与材料等不同部分的一般规则、反向计费（counter-billing）的快速参考，以及内部流程信息——今天你们怎么汇总数据？一张发票的处理要经过哪些环节？

把这些数据集带进 AIFD 界面，什么都不用解释，只问一句：「这些数据集是什么？我如何把它们用于计费工作流？」AIFD 就会去查看数据集、拆解源系统里实际有什么、画出数据集之间的关系图、推断可能的用法，然后提出提案：车与各种资产、材料、定价、所有者是谁，以及如何把原始信息组合起来——哪些部分对决策真正相关。它直接为你提出了本体。「只有一个问题、没有任何其他输入，就能这么快做到。」

下一步是实施——Ankit 称之为「AI 替你点鼠标」。人工流程是这样的：收到发票，每张发票有多个行项目，每个行项目包含所做工作的类型、所用材料、维修数量与对应人工——每个行项目、每一部分都要检查，错误与可审计性都藏在这里；还要核对车号不会对同一次维修重复出现。把这些流程大纲交给 AIFD，把领域专家如何看待维修、如何拆解行项目问题的上下文编码进本体与系统。关键在于：它先在 Foundry 分支（branch）上工作——在沙盒里改动，不影响真实生产工作流。整个平台围绕「支持真正的运营工作流」构建：必须可靠、不能引入错误。基于现有本体起步、在分支上改，经审查、用真实数据验证符合预期后，再合并回主生产线。这个沙盒机制正是加速的关键——传统项目里，变更管理、对「做的是对的事」的信心，恰恰是拖慢进度的最大阻力；Savage 深有体会：以前要么靠并排跑两套系统观察六个月甚至一个季度，才敢上线。

三、闭环验证、血缘与审计：模型自己检查自己

验证怎么做？AIFD 是一个闭环系统：每做一处改动，它就实际执行查询、验证改动是否符合预期。可以给它判据——比如「应该匹配我们之前做过的一些分析」或「这几个数字应该等于我们预期的值」——然后在循环里迭代。你会看到它生成代码（代码明确标注「由 AI 生成」、注释详尽），然后让它验证——它真的会撞上错误：改动失败、没做对。「模型和人一样有误差率，AIFD 提供了轨道把误差打回去，让模型本质上能检查自己的工作。」

面对 SOX 审计怎么办？这是客户问得最多的问题之一：你要能随时间看到这些改动——谁做的？改动长什么样？什么时候做的？不仅能查最终结果，还能查沿途的每个中间步骤，尤其当它进入越来越多的工作流时，你要能信任它是如何拼起来的。平台内置的原语——血缘与追踪视图（lineage and tracing view）——让这一切可验证，而且血缘永久保留：你能看到数据最初何时引入、如何随时间演化；如果哪里看起来不对，AIFD 还能替你去调查那些改动。迭代的最终产物，是一组准备好集成进本体的对象与动作：转换逻辑背后的改动、查询校验，以及一份实现摘要——把领域专家给的公式与原始源系统组合成计费工作流真正关心的形状。

接下来创建本体：维修发票、行项目、货车更新、价格主数据信息这些对象，它们之间的关系，以及写回系统的动作——在 Palantir 平台内做的改动要反映到真实系统里，这才是真正运营化。血缘视图完整呈现从源系统、原始数据集、数据转换、本体对象直到动作（发起索赔、修改机会）的全链路。而且系统会随你演化：每季度信息都会变，你可以随时更新任何步骤，并保留逻辑与数据本身的变化历史——「我是怎么得出这个结论的？输入的源材料是什么？」审计人员最爱这个。还能追踪谁改了逻辑、来自自动化上游还是真实用户，以及平台内每个人的动作：这个机会谁审的？谁批准了改动？索赔是谁提的？

四、从本体到应用：让审计团队拥有专属工作台

Savage 追问了一个加购场景：公司还有「维护曲线」——提示某类维修应该何时发生；如果提前发生了，就要质疑——而这些不会出现在源数据里。按不同车类型对照维护曲线检查，改起来有多难？Ankit 的回答是团队反复验证过的经验：「第一版永远是错的版本，所以要尽快做出第一版」——过去要一天，现在几分钟就能出初稿；之后可以让 AIFD 改，也可以把它烘焙进应用。

因为一次性的仪表盘捕捉不到你谈的那种细微差别——「我怎么围绕它做工作」——下一步是构建应用。有了本体，AIFD 就能用同一套积木——发票、行项目、货车、资产——来构建应用，而不是拼接任意代码。它还能编码动作：创建、删除、修改这些机会；用户可以说「这里不太对，补充一些上下文」。从空白自定义应用开始（通常这是大工程，但灵活性极高），让 AIFD 构建第一版：它自带平台同等的安全与权限控制、生产就绪，还会请求数据访问权限。出来的第一版有点粗糙，但已有顶层指标，可以开始调查最大的机会，也能看到具体行项目。

关键是区分「构建者视图」与「日活用户视图」：审计团队的人不想思考工作流怎么搭，他们想要的是——哪些发票需要我看？价值最高的是哪些？预期机会价值是多少？我能采取什么动作——能不能在这里发起调查？能不能直接说「发起索赔」，让它起草并发出去？把所有手工工作拿走，把优先级给他们。列表默认按金额排序，也可以按任何标准（新品、定价、工种代码）排序，还能提出后续要求——「我们想按状态看，拆成看板视图」——当场改。Savage 特别提到工种代码的价值：换轮对是他最关心的——「一套轮对换下来超过 2,000 美元，是我们从 AAR 收到的最大维修项」。如今，过去不会成为平台构建者的人也能进来说「我想这么看」或「把我桌面 Excel 里的新信息带进来」——以前要花太多时间集成的信息，现在几分钟内就能让 AIFD 拉进来。

五、从 25 年旧系统到全新运营模式

Savage 眼中还有一整批待办：AMS（资产管理系统）整体切换——「按这个速度，大概三到六个月就能改完」，而它管理着 80 亿美元的租赁车队；对车的位置、状态、租赁到期续约的控制，目前拿到信息并采取行动都太慢；维修类型的异常——某个地点突然修了大量车，可能意味着几百万美元，越早发现越好；销售团队的信息进出也一直很难，能快速写程序拉取决策所需信息将是关键。

传统做法是：先做三到六个月的 scope 范围定义，再开始建，建完你想改点东西？推倒重来。「能这么快做这件事，改变了我们能做的工作量、能部署的东西——它为我们打开了很多扇门，让我们能完成想完成的事、做出决策、经营好生意。」Ankit 最后展望：「谁算构建者」的边界会扩大——大量日复一日使用这些工具的人，现在有机会去改动这些工具，让它们更贴合自己的工作流。第一版已经成型，他们正与 Trinity 团队里的 Steven 讨论，准备把提案交到真实用户手里收集反馈——下一步，就是让它真正运转起来。