客户说“我们自己也能做”，先别急着反驳

设想部署的第一周。会上，客户的数据工程负责人打开笔记本，给大家看他周末写的一个演示：直接调用 LLM API，把支持工单总结得相当利落。然后他问：“这个我们团队自己就能做，为什么还要买？”

很多前线部署工程师（FDE）就在这里答错了。有人急着逐项为产品功能辩护，有人搬出数据，证明客户想得太简单。两种做法也许都能赢下争论，代价却是失去项目里最重要的那个人。

讽刺的是，正是 FDE 的工作方式招来了这个问题。PostHog 对 FDE 的描述是：坐进客户团队，快速搭原型，接受原型粗糙。

客户看到几天就跑起来的东西，自然会想“我们也做得到”。而向你提问的人，很可能正是你离开后负责运行这套系统的人。

为什么先说“是”？

“我们自己就能做”很少只是技术观点。里面有职业自尊，有对供应商锁定的担心，有时还有上级要求内部团队多承担的压力。直接反驳，只碰到了最外层。

所以最好的回答通常从真诚的认同开始：是的，这个版本你们团队完全做得出来。

Gong 的一篇文章引用了一组专家的观点：自建还是采购的决策，往往恰恰错在一处——人们以为快速搭出的原型就已经是完整的能力。

你认可的是原型，而不是“原型就是终点”这个想法。

下一步是换个问法。按 Gong 的说法，与其问“能不能做”，不如问真正的差异化在哪里。第二个问题是：等原型带来的兴奋劲过去，团队还想不想负责这一层？

MIT Sloan 的研究者给出了同样思路的原则：需要速度时，直接买现成的，或者买来再在上面构建；只有在能形成独特竞争优势的地方，才自己构建。

真正的成本在第二年才到来

周末写的演示还没有运行成本，因为根本没人在运行它。MIT Sloan 对“自建”的定义是：组织自己开发、运行并维护自己的模型。演示只完成了第一件事，功夫都在后两件上。

把这两件事落到工单摘要的场景里，变成具体问题。运行方面：工单里有客户的个人数据，谁来决定哪些数据可以发到外部？凌晨两点系统出故障，谁来值班？

维护方面：模型提供商换了版本、摘要质量下降时，谁会发现，谁来改提示词，谁来重跑评测集？

这些问题不需要你替客户回答。目的是让那位工程负责人自己看清演示背后排着的工作清单，再决定团队要接下哪些部分。Gong 的结论是：关键在于团队对“谁来负责”是否对自己诚实。

一份现在就能用的对话脚本

下面是一份示例脚本，可按自己的说话方式调整。

客户： 这个我们团队自己就能做，为什么还要买？

FDE： 您说得对，您的演示效果很好，团队也完全有能力做。我换个角度问：六个月后，您希望团队负责哪些部分？

客户： 什么意思？

FDE： 比如模型变了谁来重跑评测，哪些数据能发到外部由谁审批，出了故障谁来值班。贵公司独有的东西，应该由您的团队掌握；只是共享基础设施的部分，我们在平台上构建，团队就不必背着它。

客户： 我们独有的，是工单怎么分类、怎么分派给对的人。

FDE： 那就由您的团队来做这一部分，我和你们一起做。我们也现在就定下来：我离开项目后，你们这边由谁负责。

脚本分三步：认同，转到责任归属的问题，再把一块真正的工作交给客户。最后一句不是客套，而是从第一周就定下的交接计划。

梳理谁构建什么

谈完之后，把共识整理成双方都能看的表格，就像本文开头那张对比表。每个组件都写清楚：谁构建、交接后谁运维、出故障有什么风险。风险一栏最重要，它指出哪些部分必须有明确的负责人。

划分遵循 MIT Sloan 的原则。工单分类与分派是客户的差异化所在，由客户团队构建并保留。数据连接器、评测和访问控制属于共享基础设施，在平台上构建，以求速度。

内部周报这类低风险工作，是客户团队自己动手、边做边学的安全区。坏了也就晚几天，不会真正伤害到谁。

别指望每个客户的表格都一样。Rocketlane 指出，FDE 没有放之四海而皆准的模式，责任归属图也是如此。a16z 则提醒，客户不希望觉得自己被困在漫长的咨询项目里。一张已经写明运维人的表格，等于告诉他们你哪天抽身。

常见错误

最常见的错误是把数据当武器。据 Fortune 报道的一份 MIT 报告，企业中 95% 的生成式 AI 试点以失败告终。从专业供应商采购工具并建立合作，成功率约为 67%，而内部自建的成功率只有其三分之一。

Menlo Ventures 也发现，如今 76% 的 AI 用例是采购而非自建，因为现成方案更快进入生产环境，也更早体现价值。这些数据值得了解。

但拿它们去压一位刚展示完演示的工程师，只会让他更加防备。不如把它们留给自己，提醒自己为什么值得问出责任归属的问题。

相反的错误也很常见：为了让客户满意，FDE 承诺所有东西都定制开发。结果是一套没人能维护的系统和一个没有尽头的项目，正是 a16z 所说的客户不想要的局面。还有一种是达成了共识却没指定负责人，你一走，一切慢慢走样。

有个很少有人注意的错误：只把“我们自己来做”当成需要化解的异议。如果好几个客户都想自己构建同一层，这就是值得带回给产品团队的信号。

把这项技能变成求职优势

简历上别写“沟通能力强”。具体写你如何把一次“我们自己来做”的异议，变成一张双方共享的责任归属图：哪些部分由客户团队保留，哪些在平台上构建，交接后由谁运维。

面试时，按情境、行动、结果的结构准备这个故事。一个有具体负责人、分工清楚的故事，比你给自己贴的任何形容词都更有说服力。

下次再有人打开笔记本说“这个我们团队能做”，你不必赢下这场争论。你要争取到的是一个盟友：在你离开项目很久之后，仍在运行这套系统的那个人。