# 客户 CTO 否决你的 AI 设计时，别急着再解释一遍

> 反对意见背后往往藏着你还没听到的约束，问对问题比再解释一轮更快化解分歧。

原文: https://fdetimes.net/zh/guides/handling-cto-pushback-on-ai-architecture/

设想这样一个场景：你讲到第四页幻灯片，AI 助手的架构图刚刚出现，客户的 CTO 打断你：“为什么还要再加一个向量数据库？我的团队没人运维过这东西。”多数工程师的本能反应是再解释一遍，讲得更细，摆出更多数字。

咨询会往往就是从这一刻开始走偏的。对面的人并不需要你更有说服力。他们是在告诉你一个架构图没有考虑到的约束。

对前线部署工程师（FDE）来说，这种会议比表面上更重要。First Round Review 在一篇讲招聘 FDE 的文章里，把驻场、与客户共处视为这一岗位的核心。你在现场，恰恰是为了听到这类约束，而不是为自己的幻灯片辩护。

## 把反对意见当作信息，而不是攻击

Google 关于代码评审中如何应对反对意见的工程指南里，有一条建议值得贴在显示器上：如果对方说得对，就告诉他们，然后放下这一点。听起来简单，但它要求你在反驳之前先停下来，问问自己。

把“代码”换成“客户的系统”，这条建议对 CTO 更加适用。他们知道夜里哪个团队值班，哪个系统出过故障，哪条法规要求数据留在自己的基础设施里。而你才来了几周。

同一份指南还提醒，允许别人“以后再清理”，是代码库逐渐变差的常见路径。在客户那里也一样：一旦承认某一点是对的，就立刻在设计中修改，而不是把它推到一张没人再打开的“以后”清单上。

## 别让 CTO 成为第一个读设计的人

走进会议室之前，应该先让别人读一遍设计。Refactoring English 上一篇讲如何获取设计文档反馈的指南认为，与一位评审者一起改掉错误，好过让十个人都被它绊一跤。

在客户那里，理想的第一位读者是对方的一名工程师，最好是和你共事了几周的人。他们能指出你自己不可能知道的事，比如平台团队刚刚否决过一个新服务。他们每发现一个错误，CTO 就少问一个问题。

## 一场咨询会，逐条处理反对意见

假设你在为一家保险公司提议一个助手，帮助理赔人员查阅案卷。架构包括文档存储、embedding 步骤、向量数据库、通过外部 API 调用的 LLM，以及给回答打分的评测套件。下面三条反对意见相当典型。

**反对意见一：**“理赔文件里有个人数据，不能发送到外部 API。”这一点没什么可争的。正确的回答是：“您说得对，我没有考虑到这个约束。我会修改架构图，让模型在你们的基础设施内运行，周五前把新版本发给您。”

**反对意见二：**“加一个向量数据库，就意味着又多一个系统要值班。”别急着辩护，也别急着放弃。Product Talk 在一篇讲如何与不喜欢某个功能的工程师找到共识的文章中描述过这样的情况：工程师卡在一个实现问题上，表达出来却像是反对这个功能本身。

所以，问一个有针对性的问题：“你们团队现在运维哪些数据存储？如果复用其中一个，我们会失去什么？”据 Product Talk 介绍，单是提问，往往就能让提出反对的人自己看清真正的顾虑是什么。

在这个例子里，反对意见变成了一条设计标准：对方团队的运维成本。

**反对意见三：**“为什么不直接用我们的数据微调一个模型，一劳永逸？”这一点确实存在争议。Product Talk 建议，当双方在方向上有分歧时，不要围绕方向本身争到彼此都很沮丧，而要转向背后的理由。

可以这样说：“这是个大决定。我把它记为一个待决问题，写清两种方案各自的理由，等你们团队一起评审时再定。”检验一个待决问题写得好不好，标准很简单：主张微调的人读了你对他观点的描述，仍然会点头认可。

## 每条反对意见背后，顾虑各不相同

| 你听到的 | 背后通常是什么 | 如何回应 |
|---|---|---|
| “数据不能离开我们的系统” | 你不知道的法律或安全约束 | 立即接受，修改设计，定好新版本的日期 |
| “我的团队运维不了这个” | 运维成本，夜里谁值班 | 询问现有基础设施，把运维列为标准 |
| “为什么不用 X 来做？” | 他们权衡过或坚信的某种方案 | 记为待决问题，公正呈现两种方案 |
| “很好，那就做吧” | 热情，但不一定准备好了 | 承诺之前，先核实数据、人员和流程 |

最后一行最容易被忽略，因为它看起来不像反对意见。但一位热情点头的 CTO，未必有干净的数据，也未必有团队来运维你刚画出来的东西。

## 解释到第三遍仍然无效时

最能说明论证局限的例子，并不来自 CTO。Vinoo Ganesh 讲过，在 Kepler，提出反对的是一名数据质量工程师：她把数据从 CSV 迁移到 Parquet 的工作挡了大约一年。一遍又一遍地解释技术好处，丝毫没能化解她的反对。

真正的约束在于她的工作方式。她靠直接打开 CSV 文件来检查数据，而 Parquet 没有能让她这样做的阅读工具。打破僵局的是一个查看器，它保留了她查看数据的能力，几天之内迁移就跑起来了。

一年的争论，不如花几天修好真正该修的东西。职位虽然不同，但这个机制值得带进与 CTO 的会议：反复出现的反对意见，通常是在保护某种习惯或风险，而你的幻灯片从未触及它。

LeadDev 一篇讲如何与反对者建立共识的文章建议，找到更深层的顾虑，并在那个层面上解决，而不是陷入无休止的争论。值得问的问题是“怎样您才会放心？”，而不是怎样把自己的论点说得更漂亮。

**要点:** 反复讲技术论据很少能化解反对意见；理解对方在保护什么，才可以。

## 毁掉咨询会的几种错误

最常见的错误是把讲解当成推销，在 CTO 提出一个足以推翻半个架构的约束之后，仍然继续往下翻幻灯片。

第二种是在会上把每个争议都定下来，让缺席的人觉得被边缘化，事后再提出反对。第三种是承诺修改，却不给新版本定日期，于是“您说得对”听起来只是客套。

就职业发展而言，这项能力比想象中更容易展示。如果一则 FDE 招聘启事提到要担任客户管理层的技术顾问，就说明你该准备好一个故事：讲讲客户曾经如何反对你的设计。

这个故事应包含三部分：你提出了什么方案，对方指出了哪些你遗漏的问题，最终设计又因此好在哪里。

## 为下一次 CTO 会议准备的练习

会前，把上面那张四行的表格抄到一张纸上。针对每一行，写下你预计 CTO 会对你自己的架构提出什么反对意见，以及你打算如何回应：接受并定日期、追问，还是记为待决问题。

会后，标出哪些预测对了，哪些让你意外。下一次，把这些意外带给你的第一位读者。

CTO 愿意再次邀请的，不是每场争论都赢的人，而是因为认真倾听、带着一份不同的设计离开会议室的人。

**本周动手试试:**

- 拿出你最近写的一份设计，只发给一位同事先读，请对方扮演最难对付的 CTO。
- 挑一个在文档评论里停滞不前的争论，把它单独拎出来作为一个待决问题，把每种观点写成一段持有者本人也认为公正的文字。
- 改写简历中的一行，写一次你在客户反对后修改设计的经历：你提出了什么、对方反对什么、结果如何。

## 信源

- [How Forward Deployed Engineering is done at Kepler (Vinoo Ganesh, AI Engineer World's Fair 2026)](https://ai.engineer/talks/1OMHGsUZiqA-forward-deployed-engineering-is-done-kepler)

- [How to build consensus when dealing with detractors](https://leaddev.com/communication/how-to-build-consensus-when-dealing-with-detractors)

- [How To Find Common Ground When Engineers Don't Like Features](https://www.producttalk.org/how-to-find-common-ground-when-engineers-dont-like-features/)

- [Handling pushback in code reviews](https://google.github.io/eng-practices/review/reviewer/pushback.html)

- [How to Get Meaningful Feedback on Your Design Document](https://refactoringenglish.com/blog/useful-feedback-on-design-docs/)

- [So You Want to Hire a Forward Deployed Engineer](https://review.firstround.com/so-you-want-to-hire-a-forward-deployed-engineer/)