AI时代，面对客户只能说 YES 的时候，已经很难赢得尊重

项目需求会上，有一种气氛很容易让人误以为事情进展得不错。

客户提一个想法，供应商说可以。客户顺着又补了几个要求，供应商继续点头。一个小时聊下来，大家没有争议，待办事项记了不少，会议在一团和气里结束。

回到公司，产品开始补方案，技术开始估工作量，项目经理这时才发现，有些要求数据根本支撑不了，有些功能即使做出来也不解决问题，还有一些承诺，连验收标准都说不清。

会上的 YES 很轻，真正交付时却很重。

企业当然可以自己招人做 AI，但一支队伍要同时具备产品、算法、工程和业务经验，成本很高，培养周期也很长。很多企业选择外部团队，就是想借用供应商已经积累的经验。

客户熟悉自己的业务。他知道哪个环节麻烦，哪些人每天在抱怨，哪些事情拖了很久。可他未必知道模型能做到什么，也不一定能判断应该用知识库、智能体，还是重新改一段业务流程。

这正是专业公司该补上的部分。你需要继续追问，把需求背后的问题找出来，再告诉客户现阶段能做到哪里，代价有多大，哪条路更合适。

如果客户说什么，供应商就原样做什么，技术判断其实仍然留给了客户。花钱请来的专业团队，最后成了一支高级外包队。

供应商不愿意提出不同意见，原因并不复杂。销售怕影响签单，项目经理怕破坏关系，技术人员即使觉得有问题，也可能认为需求已经定了，自己照着做就行。

于是大家常说：“先答应下来，后面再想办法。”

这句话往往就是项目开始失控的地方。前期为了让客户满意，把边界说得很宽；中期发现做不到，再解释技术限制；后期为了验收，不断追加人力，把原本应该提前讨论的问题拖到最后处理。

客户也会慢慢改变对你的看法。他发现这支队伍很配合，却给不了可靠意见。以后遇到重要问题，他仍然要自己做判断，只把已经决定好的任务交给你执行。

一旦走到这一步，供应商就很难再进入客户的核心讨论。没有人会把重要决策交给一个只会点头的人。

客户说出来的通常是一个想法，有时已经带着具体方案。供应商要做的第一件事，不是评价这个方案能不能做，而是弄明白他为什么会想到这里。

比如客户说：“我们希望这个模型以后能够自学习。”

直接回答“可以”，几乎等于给自己挖坑。所谓自学习，可能只是希望新制度发布后系统能及时更新，也可能是员工纠正一次错误后，下一次不要再答错。还有一种情况，是客户不想每次调整业务都重新找供应商开发。

这些诉求听起来很像，实现方式却完全不同。知识更新、反馈记录、效果评测、人工审核，往往比直接训练模型更现实，也更容易维护。

专业的回答可以是：“这个方向能理解，但我们先把您说的自学习拆开。您最希望系统在哪类错误上变好？如果先解决知识更新，现有方案就能完成；如果要让模型持续训练，还需要补充数据和评测机制。”

有些团队从一个极端走向另一个极端。以前什么都答应，后来为了显示专业，动不动就说客户不懂技术、需求不合理。这同样很难赢得尊重。

客户比供应商更了解业务现场。很多听起来不合理的要求，背后可能是已有流程逼出来的。供应商没有弄清楚原因就直接否定，和没听懂就答应一样草率。

真正有用的意见，要把依据说出来。原方案的风险在哪里，需要什么数据，投入大概是多少，最后又该怎样验收。只要能给出一个更可行的替代办法，客户通常愿意继续讨论。

这样的沟通没有一句 YES 来得痛快，却把双方以后可能遇到的问题提前摆到了桌面上。

ToB 项目很少靠一场会议决定成败。客户会在后面的合作里慢慢判断：这家公司说过的话能不能落地，遇到问题会不会躲，提出的建议有没有帮自己少走弯路。

所以专业也不能停在表达上。提出不同意见以后，供应商要愿意拿出方案、做验证，并为自己承诺的部分负责。只会反驳，最后又做不出结果，客户同样不会买账。

服务意识当然重要。需求要及时响应，交付中的困难也不能推回给客户。但服务客户和顺从客户是两回事。前者关心项目最后能不能做好，后者只关心眼前这次沟通能不能顺利结束。

客户不会因为你答应得多，就认定你更专业。他真正记得的，往往是某个关键时刻，你提醒他别急着往前走，并给出了一条更靠谱的路。

说完以后，拿出依据，给出替代办法，再把自己承诺的结果交出来。

客户对专业团队的尊重，大多就是这样一点点建立起来的。