学会用客户的语言——收入、成本、时间、采用率、合规风险和运营风险——来解释工程决策。
由 The Forward Deployed 编辑团队撰写并审校
示例性质。 本课延续 Discovery 和 Scoping 中的综合案例：那家物流公司、那些合规扣留。对话为教学目的虚构，不含任何虚构的统计数据。凡是会出现数字的地方，本课都展示如何从客户那里获取，而不是凭空编造。
你已经完成了一个标记高风险路由决策的系统的范围界定。现在副总裁必须走进预算会议，为这项支出辩护，而与会者永远不会看到代码。你的工作是把论据用他们的单位交到他们手上。这是一位 AI 工程师从不做的翻译，也是这个职位存在的重要原因之一。
这里有一个大多数文章都会掉进去的诚实陷阱：它们教你去断言回报（“这每年为您节省数百万！”）。不要这样做。你不知道那个数字，而编造的数字是失去精明买家最快的方式。可信的做法是用客户自己的数字构建 ROI 案例，并且像陈述收益一样清晰地陈述风险。
阅读之前
副总裁问：“我需要向财务部门证明这项投资的合理性。ROI 是多少？”
你不知道一次合规扣留对这家公司的成本是多少。你会说什么——又拒绝说什么？
你拒绝编造一个金额。你要做的是给出计算的框架，并请对方提供填补框架的那个数字。看好了。
步骤 1 —— 搭建框架，请他们提供数字
不要回答“ROI 是 X”。给出回报的结构，让他们提供数值：
你：“我不会递给您一个我编出来的数字。财务部门会看穿它，您也会。我给您的是这个框架：系统的价值 = 避免的扣留次数 × 每次扣留的成本。第二个数字我不知道；您知道，或者您能查到。一次合规扣留实际让您付出多少代价？罚款、延误、员工追查它所花的时间。”
副总裁：“我们从没算过一个确切的数字，但一次严重的扣留会让一批货滞留好几天，还得有人花一周时间处理文书。”
你：“那这就是您的 ROI 输入。如果我们能从日志中证明，每个季度哪怕只避免了少数几次这样的扣留，您把它乘以每次扣留的成本，就得到一个站得住脚的数字，而且建立在您自己的数据之上。而且我们会有标记日志来证明这个次数。”
你刚刚给了副总裁一个远比虚构的预测更有力的东西：一个他们自己拥有的公式，以及一个用系统本身的真实数据填补唯一变量的计划。
步骤 2 —— 像陈述收益一样清晰地陈述风险
一个全是好处的推销听起来就像销售话术，精明的买家会打折扣。点明风险反而能建立可信度：
你：“诚实的风险是误报。如果系统在本来没问题的路线上频繁‘狼来了’，老手们一周内就不会再信任它，那我们就完了。这才是会让整个项目失败的问题，所以我想现在就把它说出来。因此我们采取保守起步：只标记高置信度的风险案例，衡量我们的准确率，在扩大范围之前先调优。漏掉一次扣货的代价很高；惹恼你最好的调度员的代价同样很高，我的设计要同时兼顾这两点。”
主动说出失败模式，并展示你已经围绕它做了设计，会让副总裁知道你以前做过这类事。这也能为你“打疫苗”：当误报发生时（一定会发生），你早已预言过它，所以它看起来只是你计划中的调优步骤，副总裁的信心就能保住。
差 / 好 / 卓越——“投资回报率是多少？”
差——“它能帮你省下数百万。” 这个数字是你编的。最好的情况是财务部门无视它；最糟的情况是他们以此为锚点，而你就承诺了一个自己无法控制的回报。无论哪种情况，你都花掉了本需要的可信度。
好——“它能减少合规扣货，而扣货成本很高。” 这是事实，方向也对，但这不是一个副总裁能拿去说服财务部门的论据。没有结构，也没有他们能为之辩护的数字。
卓越——“回报等于避免的扣货次数乘以你们每次扣货的成本；我会从日志中展示避免的次数，你提供成本数据，这样我们就得到一个建立在你们数据之上的数字。主要风险是误报会侵蚀信任，所以我们从窄范围起步，并基于实测的精确率进行调优。” 你给出了一个基于他们数据、经得起推敲的公式，并在他们开口之前主动指出了风险。你以一个与他们共同构建商业论证的合作伙伴形象出现。
需要预料的追问
副总裁：“财务部门现在就要数字，在我们还没收集任何日志之前。”
你：“那我们就给他们一个保守的区间，把计算过程展示出来并标注为估算值，使用你们的单次扣货成本和一个刻意压低的避免次数，并承诺在第一个季度内用实测数据替换这个估算。一个展示出来、可供他们压力测试的保守估算，胜过一个他们无法验证的自信数字。而且等我们拿到真实日志的那天，这页幻灯片只会更有说服力。”
为什么这是资深水平的信号
注意这个转译真正在做的事情：它把一个工程产物（一个标记模型）转换成一个商业对象（一个指明了风险、经得起推敲的投资回报率论证），使其能在满屋子的非工程师面前站得住脚。这种转换正是 FDE 的杠杆所在。面试官会直接探查这一点：“你会如何向客户的领导层证明这件事？”做过这件事的人的标志是，他们会去拿客户的数据并主动说出不利之处，而不是背诵一堆好处。
可迁移的模式
给客户展示回报的结构，填入他们的数字，并像强调收益一样大声指出风险。 绝不要凭空编造数字。要从他们的数据和你的系统自身日志中推导出来，并在他们发现之前主动指出失效模式。这样他们才能在没有你在场的情况下为这个论点辩护——而这正是你被聘用后要留下的东西。
下一步： 推动采用。商业案例只有在人们真正使用产品时才算成立，而最难搞的用户就是那个确信自己不需要它的人。