跟CTO聊AI，别像供应商推销

和CTO聊AI，技术深度是入场券，但决定你能不能留在牌桌上的，是商业语言。原文作者在多次高管简报中观察到同一个模式：输掉会议室的人从能力讲起，赢的人从一个问题讲起。

一个开场问题，打开所有真实对话

原文给出的开场问题很直接：「你们反复在做、但不产生任何竞争优势的最贵的事情是什么？」

这个问题之所以有效，是因为它不威胁任何人，也不预设你已经知道答案。它要求对方真正思考——而当高管开始和你一起想问题时，他们已经在心理上参与了这场对话。常见的回答包括：月末关账对账吃掉40个工时、供应商发票处理需要手动录入PDF、内部IT工单70%的问题只有五个答案。

每一个都是带真实成本的真实问题。真实成本意味着可以算ROI，而这正是你想要的对话。

原文还提供了一个完整的脚本，覆盖三种典型回应。当CTO直接说出痛点时，追问人数和每个周期的全负荷成本，把它变成你的ROI锚点。当对方说「现在什么都是优先级」时，不要退让，而是收窄：「如果两年内什么都没变，哪个流程还会和今天一样痛苦？」当对方进入怀疑模式、担心AI准确性和数据暴露时，不要为AI辩护，而是同意并转向：「你担心得对，大多数部署都跳过了护栏。我提议的是一个有明确回滚条件的自动化方案，AI只是实现细节，结果是更少的人工错误和更快的周期。」

技术流畅度是进入对话的门票，商业流畅度才是你被再次邀请的原因。

CTO真正在评估什么

一旦你命名了一个真实问题，CTO在你说话时其实只做三件事。

风险。 CTO的职业责任是保持系统运行、让公司不出现在新闻里。在关心它能做什么之前，他们需要知道出问题时谁负责。

成本。 你在和路线图上的所有其他项目竞争。一个具体数字——「每年消除Y的X小时，全负荷成本为Z」——比三页能力架构图更有价值。

竞争优势。 「你的竞争对手正在做这件事」把问题从「我们该不该投」变成「我们能不能不投」，这是两棵完全不同的决策树，而后者几乎总是指向同意。

原文给出了三个框架的先后顺序：业务结果第一，技术机制除非被问到否则不提；风险先于收益，先讲失败模式再讲上行空间；试点范围先于通用能力，不是「AI能做什么」，而是具体的事、具体的范围和如何判断是否成功。按这个顺序走，掉进注意力机制话题在结构上就不可能。

「丢掉会议室」长什么样

原文识别出两个信号。第一个：对方说「这很有意思」，然后开始谈AI战略。战略模式意味着你推销的是概念而不是方案，你会收到一个永远不会发生的后续会议邀请。第二个更糟：对方开始问其他供应商。这意味着你触发了采购反射而不是解决问题的反射，你已经进入了一场你并不想参与的竞标评估。

有意思的是，怀疑AI的CTO反而更好处理。怀疑者会问更难的问题，迫使你精确。面对怀疑者，不要为AI辩护——同意他们关于AI被过度炒作的判断，然后描述你想构建的具体自动化。「我们可以消除供应商发票处理中80%的手动匹配步骤」是一个关于自动化的主张，不是关于AI的主张。AI是实现细节。一旦跑通，这个怀疑者会成为你最强的内部盟友。

「采购反射」指的是企业采购流程被触发后形成的一套标准化反应：需求被转入招标、比价、供应商准入、合规审查等环节，决策权从业务负责人转移到采购部门，周期通常以月计。CTO一旦说出「你们和其他几家比一下」，对话性质就从解决问题变成了供应商遴选，技术优势会被压缩成报价单上的一行。与之相对的是「解决问题反射」：对方关注的是你的方案能否闭环他的痛点、风险如何兜底、多快能看到结果。触发采购反射的典型诱因包括：过早展示通用能力、给出模糊的范围、报价结构不清晰、或让对话停留在概念层面。避免它的方法不是回避采购，而是把讨论锚定在一个具体、可度量、预算低于单一审批阈值的用例上。

试点范围公式

当对话进展顺利、对方问「你会从什么开始」时，你需要这个公式：6周、一个用例、预定义成功指标、5万美元以内、回滚计划。

• 时长： 最长6周。短到不需要多季度承诺就能批准。
• 范围： 一个用例、一个团队。不是「财务AI」，而是「X地区AP团队的供应商发票匹配」。
• 成功指标： 试点开始前命名、可衡量、双方同意。「手动匹配错误减少80%」而不是「提升准确率」。
• 预算上限： 全部在内不超过5万美元。这是多数企业的单一审批人阈值，超过它采购部门就会介入，而采购意味着六个月的延迟。
• 回滚计划： 启动前写清楚。「如果第三周错误率超过X，我们回退到当前流程。」这在CTO开口之前就消除了他们最大的反对理由。
• 决策点： 第三周做继续或终止的决定，不是第六周。中点闸门表明你不是想用沉没成本把他们套住。

原文特别提到SAP场景的版本更有说服力，因为SAP环境有具体、昂贵、记录完善的问题。从PDF到SAP的供应商发票处理是企业软件中最好的AI试点候选之一：手动、导致付款延迟、三方匹配的错误率是已知成本中心。用AI文档抽取可以消除80%的匹配错误，把处理周期从几天降到几小时——这个数字具体、可审计、能关闭试点。第二个SAP切入点是基于SAP报表数据的自然语言查询，让高管不用等BI请求排队就能问「本季度各区域毛利率是多少」。SAP AI Core让这在技术上很直接，商业理由不言自明——多数SAP环境的约束是决策时间，不是技术复杂度。

「三方匹配」（three-way match）是应付账款流程中的核心控制环节：采购订单、收货单/服务确认单与供应商发票三份单据在数量、单价、金额上必须一致，发票才能被批准付款。任何一项不符都会形成例外，需要人工核查，这正是发票处理中成本最高、最容易出错的部分。常见例外包括数量差异、价格偏差、缺少收货记录、重复发票等。由于三方匹配规则明确、判定标准可量化，它天然适合作为AI文档抽取与自动核对的落地场景：模型从PDF发票中抽取字段，与SAP中的采购订单和收货记录自动比对，只把真正存疑的例外推给人处理。错误率和处理周期都是系统里已有的数据，因此收益可以被精确测量，这也是原文把它称为最佳试点候选之一的原因。

「SAP AI Core」是SAP BTP（业务技术平台）上的AI运行时与生命周期管理服务，用于部署、扩展和监控模型，并与SAP应用数据安全地连接。它的意义在于把AI能力放进企业既有的权限、审计和数据治理体系内，而不是另起一套外部管道。对CTO而言，这意味着数据不出边界、访问受角色控制、调用可追溯，直接回应了数据暴露的顾虑。在自然语言查询SAP报表的场景中，AI Core负责承载模型服务与编排，底层数据仍由SAP的语义层和授权机制约束，因此技术上可行、合规上可解释。理解这一点有助于在对话中把「AI」还原为一项受控的平台能力，而不是一个不可控的黑箱。

离开会议前的自查

原文在文末给出了三个自查项：你能否在描述任何技术之前，用一个数字说清具体的业务结果；你是否准备好了风险框架——什么会出错、谁负责、如何尽早发现；你是否加载了试点公式——用例、6周范围、预定义成功指标、回滚条件、预算。

还有一个「回请指标」：对话结束后问自己，我留给他们的是具体可思考的东西，还是模糊可考虑的东西？「我想给你看一个90秒的演示，用你的数据展示发票自动化长什么样，下周能给我20分钟吗」是具体的。「我们应该讨论AI如何有益于你的架构」是模糊的。一个是下一步，另一个是礼貌的送客。

原文强调演示的重要性：没有什么比看着自己的数据在一个上周还不存在的系统里得出正确答案，更能终结高管怀疑。在第二次会议之前就把演示做出来，而不是等立项批准之后。演示本身就是你获得批准的方式。