银行AI改造：为什么技术团队要先见客户再写代码

Capital One的技术负责人Ashish Agrawal最近提到一个反直觉的现象：让工程师直接面对客户，反而能催生出更多"横向创新"。这不是什么管理鸡汤，而是这家银行在AI转型中摸索出的硬经验。

麦肯锡的研究提供了一个刺眼的背景数据：尽管多年数字化投入，大型企业仅从数字投资中捕获了不到三分之一的价值。问题出在哪？大多数公司从现有技术能力出发，把应用往上堆叠，而不是从客户需求倒推技术方案。结果是碎片化的解决方案、割裂的客户体验，以及最终失败的转型。

Capital One选择反过来做——他们称之为"客户反向工程"（customer-back engineering）。

什么是"客户反向工程"

简单说，就是产品开发时先把客户体验放在核心位置，包括客户的挑战、需求和期望。然后团队以敏捷方式倒推，找出设计和构建解决方案的必要步骤，最终实现预期的体验。

Agrawal负责Capital One的商务卡和支付技术。他观察到，当工程师离客户更近时，"会产生乘数效应"——工程师能从与销售或产品视角不同的维度来解决问题。

这背后有个基础判断：工程师天生是问题解决者。当他们直接听到客户遇到的挑战，或了解产品在真实场景中的使用方式时，由于比公司其他团队更贴近系统和数据，他们能更高效地设计出满足客户需求的方案。

具体怎么操作

Agrawal的团队设定了硬性目标：每位工程师每年要通过多种形式与客户建立若干接触点。这些形式包括：

数字共情会议——观察用户旅程，识别摩擦点；

嵌入式客户支持——阶段性深入一线，理解服务需求；

工程随行——工程师跟随客户成功、销售和支持团队参加电话会议或实地拜访；

黑客马拉松——围绕真实客户问题构建解决方案。

Agrawal强调这需要"纪律性"。不是偶尔组织一次活动，而是系统性地把客户接触纳入工程师的工作节奏。

动机层面的变化

这种接触还有个隐性收益：工程师能看到自己写的代码如何直接影响客户生活。

"当工程师真正开始看到，他们所做的核心改动或新增的功能，正在对客户生活产生直接影响时，培养以客户为中心的文化会产生激励效应。"Agrawal说。

这解决了大型技术团队常见的疏离感——代码提交后流向黑箱，工程师不知道最终谁在用、用得怎样。

AI时代的特殊意义

文章提到，代理型AI（Agentic AI）正在帮助机构从客户视角彻底重新构想核心银行流程和运营，而非仅仅做渐进式改进。

但这里有个关键张力：大型公司的工程师往往缺乏直接接触客户的渠道。层级、部门墙、流程设计把技术团队和客户隔离开来。而AI恰恰需要更精准地理解真实场景中的需求——不是产品经理转述的需求，而是工程师亲眼所见的细节。

Capital One的实践暗示了一种可能性：在AI改造传统行业的浪潮中，组织设计的调整可能比算法本身更关键。让谁接触客户、以什么频率、通过什么形式，这些决策可能比选择哪种模型架构更能决定转型成败。

未完成的讨论

原文在此处中断，但留下了可延伸的思考空间。

一个明显的问题是：这种模式的成本。工程师时间昂贵，客户接触需要时间投入，如何平衡短期交付压力与长期能力建设？Capital One提到"纪律性"，但未展开说明如何量化这种投入的回报。

另一个问题是规模边界。Capital One作为单一机构可以推行这种文化，但在更大型的金融集团或跨行业场景中，客户接触的复杂度呈指数级上升。工程师该接触哪类客户、多频繁、在什么决策阶段介入，都需要更精细的设计。

还有技术伦理的维度。当工程师直接面对客户，他们同时掌握了系统能力和用户痛点，这种信息集中度带来了便利，也可能带来风险——如何确保客户数据在"共情"过程中不被滥用，原文未涉及，但这是实际运营中无法回避的议题。

最后，"客户反向工程"与"技术驱动创新"并非简单的对立关系。Capital One的案例有其行业特殊性：银行业务高度标准化，客户需求相对可预测，技术债务积累深厚。在需求更动态、技术迭代更快的领域，完全倒推可能错失突破性机会。两种模式的配比，或许才是更值得探讨的命题。