AI Coding 时代，核心业务系统选型：该追求技术先进，还是优先工程成熟？

昨天发了一个帖子（帖子地址： https://v2ex.com/t/1227508#reply72 ），原本想讨论的是 Java 和 Go 各自的生态，对公司核心业务系统技术选型的影响。但因为我的表述不够准确，最后讨论更多集中在语言本身。

上一个帖子里的每条回复我都认真看了，非常感谢大家提出的各种观点。这里想进一步补充说明一下我的原意。

我并不是认为 Go 、Java 或其他语言谁好谁坏，也不是想发起一场语言之争。

我真正想讨论的是：在 AI 编程能力越来越强、各种语言和技术栈百花齐放的今天，企业应该如何评估一个核心业务系统的工程化能力，并据此完成长期技术选型。

我们目前从事的是与金融相关的业务。公司下面各个事业部需要相对独立地展业，同时每个事业部又有自己的业务系统，并需要与总部的核心业务系统对接。

因此，总部的核心业务系统并不是一个普通的管理后台，而是承担了客户、销售、组织、权限、业务协同、数据汇总和系统集成等职责。

由于业务涉及金融产品，系统每年还需要接受审计。这意味着系统不仅要能够正常运行，还要长期保证权限边界清晰、操作过程可追溯、数据变更可审计、系统行为可解释。

对于这样的企业核心系统，我更看重的不是短期开发速度、语言热度或者单纯的运行性能，而是未来五年甚至更长时间内的可维护性、稳定性和可靠性。

核心系统一旦正式投入使用，就会不断接入新的业务、数据和上下游系统。后续可以持续迭代、修复问题和增加功能，但通常很难推倒重来，也很难更换技术栈重新建设。

因此，技术选型的成本不能只看开发和上线阶段，还要考虑未来多年的维护、升级、审计、人员交接和故障处理成本。

Go 的优势很明确，例如部署简单、资源占用较低、并发能力强、语法相对简洁。但语法简单并不意味着大型业务系统的工程复杂度会消失。

多租户、跨事业部数据隔离、总部数据权限、事务一致性、审计日志、链路追踪、幂等、错误治理、报表以及第三方系统集成等问题，无论使用什么语言都必须解决。

区别在于：语言生态、框架能力和团队经验，能够帮助我们承担多少复杂度。

Java 虽然已经非常普及，也经常因为历史包袱、框架复杂度和资源占用受到批评，但它的普及本身也带来了一个现实优势：成熟的生态、大量开源组件、丰富的行业实践、充足的人才储备，以及大量经过生产验证的问题解决方案。

并不是每家公司都有能力开发通用框架、中间件、底层组件和基础设施平台，也不是每个技术团队都适合长期维护这些内容。

对于资源和工程能力有限的公司来说，成熟生态中已经被验证过的“轮子”，并不一定是负担，反而可能是对团队能力的重要补充，可以降低试错成本和长期维护风险。

当然，开源组件多并不意味着可以无脑引入，也不代表 Java 一定优于 Go 。任何组件都需要评估维护状态、社区活跃度、安全性、兼容性和升级成本。

Go 同样可以完成复杂企业系统的开发，但相对而言，往往更加依赖团队自身的工程能力、基础组件、脚手架和规范建设。

我真正担心的是：如果团队缺少成熟的 Go 技术积累，技术负责人也没有大型 Go 企业系统的实践经验，那么最终是否会重新实现一套成熟生态已经解决过的能力，并承担这些内部组件未来多年的维护、升级、审计和人员交接成本。

所以，我想讨论的核心并不是“Go 能不能做核心业务系统”，而是：

在当前业务约束下，公司是否具备成熟的 Go 工程体系；自研基础组件是否值得长期维护；缺少的 SDK 和生态能力是否会持续增加成本；使用 Go 后的稳定性、可靠性、开发效率和长期维护成本，是否真的优于其他方案。

如果业务以网关、长连接、推送、高并发接口和基础设施为主，我认可 Go 很合适。

但如果系统的核心是复杂权限、多租户、跨事业部协作、事务、审计、报表和大量第三方系统集成，那么至少应该认真评估成熟企业级生态在长期维护上的综合价值。

大厂使用 Go ，也不能直接证明普通公司同样适合。大厂通常拥有完整的平台工程、中间件、基础设施和专业团队，而普通公司的团队规模、人才结构和资源投入往往并不相同。

AI 确实降低了学习新语言和编写代码的门槛，但 AI 更擅长解决“如何更快地写出代码”，并不能替代系统架构、数据一致性、权限模型、工程规范、故障治理和长期维护责任。

因此，我真正想讨论的是：

在不同语言都可以完成业务开发的情况下，企业应该如何结合团队技术实力、人才结构、语言特性、生态成熟度、业务适配度和系统生命周期，选择综合风险更低，并且团队能够稳定维护多年的技术方案。

我承认原帖举例不够具体。我的重点不是否定 Go ，而是想讨论：对于一个承担金融业务、总部协同和审计责任的核心业务系统，技术选型究竟应该优先考虑语言本身，还是团队能力、工程生态和未来十年的维护成本？