客户问“为什么不用 Copilot”，别去比模型

设想第二次演示的场景。你的 Agent 刚刚顺利跑完，客户那边有人发问：公司已经给每位员工都买了 Copilot，这个有什么不同？

如果你争论哪个模型更聪明，几乎必输无疑。提问的人为一笔大额采购投过赞成票，没人愿意听到自己买错了东西。这个问题也并无敌意，它是预算负责人最该问的问题。

所以不要想着辩赢。你的任务是准确说明：现有工具已经能做哪些工作，还做不了哪些，你的方案放在哪里。

问题不在模型

据 Fortune 报道，MIT 的 GenAI Divide 研究认为，企业 AI 试点失败，主要原因是工具和组织两方面都存在“学习鸿沟”，而不是模型质量。通用工具之所以停滞不前，是因为它们不会从工作流中学习，也不会适应工作流。

这正是前线部署工程师（FDE）发挥作用的地方。根据 ZenML 对 Colin Jarvis 一次演讲的总结，OpenAI 把自家 FDE 描述为与客户坐在一起、构建和部署 AI 方案并持续迭代的人。你带来的不是更好的模型，而是对某个具体工作流的理解，并把它变成软件。

专做定制 AI 方案的公司 Tensoria 观察到，Copilot 非常擅长总结、起草和改写。它建议这样分工：Copilot 负责支持性工作，定制方案负责核心工作流。这是有商业利益一方的观点，但这种分工足够清晰，可以在客户现场当场检验。

开口之前先问三个问题

Microsoft 提供了一套可以直接借用的框架。它的 Copilot 插件开发生命周期，第一步就是明确要完成的工作、谁会使用插件、在哪里使用。客户问“为什么不用现有的工具”时，要问的也正是这三个问题。

问做什么工作，以区分通用写作任务和业务流程。问谁来做，以弄清真正的用户是普通办公人员，还是有自己工作流的业务团队。在哪里做，是最常被跳过的问题，而它恰恰决定了方案的形态。

接着核查数据。另一家有商业利益的公司 Credal 认为，Copilot 只能集成 Microsoft 365 边界内的数据。不要把这当作事实照搬，而要当作假设，在客户的租户上验证：工作流的数据是在 SharePoint、Outlook，还是完全在另一套系统里？

还有一项检验是数据主权。据 Tensoria 的说法，定制方案明显胜过 SaaS 工具的头一种情形，就是客户要求数据主权且毫不让步。如果客户要求数据绝不能离开某套基础设施，谈话的方向就完全变了。

一个完整的示例

设想一家保险公司，全公司都已用上 Copilot。你被请来帮助理赔团队：每一笔理赔在批准前，都要对照保单、现场照片和客户历史记录逐项核查。

套用三个问题。做什么：根据每种保单类型的具体条款，判断一笔理赔是批准、拒绝还是需要补充材料。谁来做：理赔员，而不是泛泛的办公人员。

在哪做：他们用 Teams 和 Outlook 沟通，但保单和理赔历史存放在公司自己的保单管理系统里。

答案随之浮现。起草邮件请客户补充材料，Copilot 做得很好，你应该坦率承认。用 Microsoft 365 之外的数据，对照保单条款核查理赔，才是需要你的部分。

接下来是最关键的一步：不要另做一个新应用，让理赔员再多开一个标签页。Microsoft 把 Copilot 插件定义为一个可安装的包，它把完成某项具体工作所需的能力打包在一起。这个包可以包含声明式 Agent、技能、连接器和 MCP 服务器的连接信息，而服务器本身单独运行在外部。

于是，你编写一个读取保单系统的 MCP 服务器，部署在客户允许的基础设施上，再把理赔 Agent 打包成插件。理赔员照常在 Copilot 里提问。Ramp 把这种做法描述为在客户已在使用的工具里服务客户，而不是逼他们接受一套全新的工作流。

演示时的对话可以这样展开：

客户：我们已经有 Copilot 了，这个有什么不同？

FDE：Copilot 仍然是团队工作的地方，它起草理赔邮件做得很好。它现在还做不到的，是对照你们保单系统里的条款核查理赔，因为这些数据不在 Microsoft 365 里。方案的这一部分会以插件形式在 Copilot 内部运行，理赔员不需要学新工具。

客户：为什么不让我们的 IT 团队来做？

FDE：可以，你们的 IT 团队会接手交付并继续推进。问题在于，头三个月里，谁能衡量这个 Agent 是否正确学会了理赔工作流。

最后这个回答值得留意。据 MIT 的研究，向专业供应商采购工具、建立合作关系，成功率约为 67%，远高于自建。但同一个数字也在提醒你：不要承诺一切从零开始做。

一张表看五个步骤

步骤	问题	需要的产出
明确工作	做什么、谁来做、在哪做？	一页纸的工作流描述，用用户自己的话写
梳理数据	数据在 Microsoft 365 之内还是之外？	数据源清单，标出外部数据源
核查约束	是否要求数据主权？	确定服务器部署在哪里
划分工作	通用写作还是核心工作流？	哪些交给 Copilot，哪些由定制方案负责
选择形态	用户已经在哪里工作？	Copilot 中的插件，或留在外部的明确理由

会让你丢掉客户的错误

最常见的错误是贬低 Copilot。你在技术上也许是对的，却会让签合同的人难堪，而他们会用放弃你的方式来捍卫自己的决定。

其次是搬出模型基准测试。如果真正的差距在于学会工作流，赢下基准测试回答不了客户的任何问题。

同样危险的是把供应商的说法当作事实引用。Credal 和 Tensoria 都在卖竞争方案，把它们的观点当作检查清单，再到客户的真实环境里核实。

最后是在用户已经整天泡在 Teams 和 Outlook 里的情况下，硬推一个新界面。更准确却没人打开的 Agent，仍然是一次失败的试点。

值得写进简历的技能

浏览 FDE 招聘启事时，留意 Microsoft 365 extensibility、MCP 或与客户现有系统集成这类说法。它们说明公司需要的是能把方案放进客户已采购生态里的人。

简历上不要只写“为客户构建 Agent”。要写你找出了现有工具做不了的工作，再把方案集成进同一个工具。这句话能让招聘经理看到，你既懂技术，也懂客户内部的人情世故。

本周练习：选一个你正在服务的客户的工作流，就“为什么不用现有的工具”写一段五句话的回答，读给扮演难缠 CIO 的同事听。只要有一句提到模型，就重写。