未来的工程师，必须重新靠近客户

传统软件公司习惯把客户和工程师隔开。客户告诉销售，销售告诉产品，产品写需求，工程师写代码，实施团队交付，客户成功负责后续使用。这个链条在标准软件时代可以运转，因为很多需求已经成熟，客户知道自己要什么，产品也知道该怎么抽象。

AI 项目不一样。

很多企业客户并不知道 AI 应该怎么进入自己的业务。他可能说想要一个 AI 助手，但这个表达太粗。真实问题可能是销售线索无人分级，合同审查耗时太久，客服知识库没人维护，内部数据口径混乱，生产排程依赖老员工经验。客户用一个“AI 助手”概括了焦虑，但真正的产品形态还没有出现。

需求经过层层转述后，很容易从业务痛点变成功能清单。业务说“我想更快拿到日报”，产品写成“自动生成日报功能”，工程师按需求做完，但上线后发现管理层不信任数据口径，一线也不愿意维护字段。功能没错，但问题没解。

未来的工程师必须重新靠近客户，不是因为工程师要替代产品经理，也不是因为所有工程师都要做销售，而是因为 AI 项目的关键判断越来越依赖真实上下文。数据质量怎么样，用户真正信任哪个系统，流程里的例外由谁处理，某个字段为什么总是空的，审批为什么明面走系统、实际先在群里沟通，这些问题很难通过需求文档传递。

靠近客户的工程师，能更快发现哪些问题值得做，哪些只是表层需求。他会知道某个接口不是技术问题，而是部门权限问题；某个模型效果不好，不是提示词问题，而是业务规则没有显性化；某个用户不用系统，不是培训不够，而是系统没有出现在他的工作路径上。

这会改变工程师的价值定义。过去好的工程师是把需求实现得稳定、优雅、可维护。未来好的工程师还要能参与问题定义、价值验证和产品回流。他要问的不只是“怎么做”，还包括“为什么做”“做到什么算成”“这个解法能不能复用”。

离客户越远，越容易写出正确但无用的代码。离现场越近，越有机会做出粗糙但真正有价值的系统。AI 时代的工程师不是要放弃工程专业性，而是要把专业性用在更靠近结果的地方。

这并不意味着工程师每天都要陪客户开会。更合理的方式，是在关键阶段让工程师靠近现场：需求定义阶段，工程师参与观察真实流程；最小可行部署阶段，工程师直接接触真实数据和用户反馈；复盘阶段，工程师和产品一起判断哪些现场解法值得产品化。

这样做还有一个好处：减少组织里的“翻译损耗”。很多项目失败不是没人努力，而是信息层层传递后失真。业务说痛点，产品翻译成功能，工程翻译成技术任务，交付再翻译成实施计划。每转一次，原始上下文就少一层。工程师适度靠近客户，可以让关键技术判断建立在一手信息上。

未来优秀工程团队可能会形成两种角色组合：一类人负责平台稳定、通用能力和长期架构；另一类人负责前线部署、客户问题和快速验证。前者让系统可持续，后者让产品不脱离现实。两者不是高低关系，而是同一套产品能力的两端。

这一篇可以写得更有冲突感：过去很多工程师觉得靠近客户是“脏活累活”，真正高级的是做底层架构、平台能力、技术突破。但 AI 应用的很多关键创新，恰恰来自客户现场。谁先看见真实流程，谁先理解真实约束，谁就更容易定义出有价值的产品。

当然，靠近客户不等于被客户牵着走。工程师不是去当接单员，而是去获得一手上下文。客户说要什么只是输入，工程师要结合系统能力、产品方向和复用价值做判断。该做的做，该劝退的劝退，该抽象的抽象。