CTO 和内部 SE 是否正因 AI 驱动开发而沦为“内部 SI”?

@qumaiu
JAPANESE2 months ago · Jun 08, 2026
562K
587
69
4
845

TL;DR

AI 虽然提升了编码速度,却也可能导致碎片化的“流浪系统”产生。CTO 和内部 SE 必须从单纯的构建者转型为架构师,优先考虑全公司范围的数据集成,并做出关于“不构建什么”的战略决策。

在我的上一篇文章中,我探讨了 AI 需求定义的现状——流程如何从“整理”转向“决策”,以及我对许多职场在未意识到这一变化的情况下盲目外包思考的担忧。

这次,我想就一个相关问题再次发出警示。

问题在于,CTO 和内部 SE 因为能够借助 AI 驱动开发快速编写代码,正在沦为业务部门的单纯执行者——本质上变成了“内部系统集成商”。

AI 驱动开发带来的新动态

无可否认,AI 驱动开发的普及极大地降低了编码的门槛。

结果,业务部门提出的“我想要这个”或“我想把这个系统化”之类的请求以前所未有的速度涌入。业务人员自己用 AI 列出需求,甚至制作原型的情况已不罕见。

乍一看,这似乎是好事。这看起来像是一个理想场景:业务部门主导数字化转型,与 IT 协作快速上线系统。

然而,这里面有陷阱。

我感觉到,越来越多的 CTO 和内部 SE 正在变成“单纯将业务部门需求具象化的人” 。他们接到请求,用技术实现,然后交付。这正是 内部 SI 所做的。

被动执行终将走向何方

响应业务需求本身并没有错。问题在于 当你继续原样满足每个部门的个体需求时会发生什么。

我称之为 “零散系统”和“零散数据库”的蔓延。

销售部建立自己的 CRM,市场部搭建独立的数据分析平台,客服部构建自己的工单管理系统。每个部门都很满意,因为他们以极快速度获得了针对自身工作优化的系统。

但公司整体呢?

数据分散在不同地方,格式不统一。同一客户信息以不同形式存在于多个数据库中。每当尝试跨部门关联数据时,都需要人工处理或定制开发。

这就是 技术孤岛。

由于 AI 驱动开发让系统构建变得异常容易,这种孤岛化以前所未有的速度推进。过去,高昂的开发成本充当了天然刹车。存在一种“建起来难,所以只严格选择真正必要的东西”的动态。

现在,这个刹车消失了。因为能建,所以建了。结果,零散系统和数据库不断增多,需要管理的应用和基础设施数量持续增加。

为什么在 AI 时代这是致命的

你可能想,“系统稍微分散一点也没关系,能用就行。”但在 AI 时代,这种孤岛化会引发比以往更致命的问题。

原因很简单:AI 的价值与数据集成程度成正比。

只有当数据在整个公司范围内整合,才能实现跨部门的洞察,AI 才能真正发挥力量。只有当销售数据、客户历史、营销效果和财务数据集成在一起时,AI 才能提供有助于管理决策的洞察。

在遍布零散系统的环境中,数据根本就没连通。你或许能在部门内部实现小规模 AI 优化,但永远无法达到真正有业务影响的公司级 AI 应用。

通过积累部门级优化,你永久地失去了整体优化。这就是被动执行的 CTO 和内部 SE 在无意识中制造的风险。

CTO 和内部 SE 应扮演的真正角色

那么,CTO 和内部 SE 应该怎么做?

答案很明确:成为“设计者和决策者”,而不仅仅是“构建者”。

这里的“设计”不是指设计单个系统,而是指 设计整个公司的数据和系统架构。

当业务部门提出需求时,不是直接构建,而是判断“这个需求在公司级架构中应该如何定位”。有时你必须说,“这个不应该单独建”。如果可以通过扩展现有平台来处理,就引导他们去那里。

这可能会让业务部门感到不便。他们可能会问:“我只是想现在把这个建起来,你为什么要谈整个公司?”

但只有 CTO 和内部 SE 才能做出这种判断。业务部门有优化自身领域的动力,但没有保护公司级架构的动力。因此,技术专家必须扮演 整体优化守护者 的角色。

“不构建的决策”是最高技术能力

讽刺的是,在 AI 时代,CTO 和内部 SE 最重要的能力可能正是“不构建的决策”。这就是我称他们为“决策者”的原因。

业务部门提出一个请求。技术上可行。借助 AI 几天就能成型。但你必须有能力质疑:构建这个对公司整体来说真的是正确的吗?

这个请求能否由现有平台处理?数据结构是否符合公司规范?其他部门是否已经在运行类似的系统?添加一个个体优化的系统是否会让未来的数据集成变得困难?

能够提出这些问题,才是 AI 时代的真正技术实力。

编码将由 AI 完成。然而,判断构建什么、不构建什么 是 AI 做不到的。正如我在上一篇文章中提到的“需求定义将变成决策过程”,CTO 和内部 SE 的角色正是遵循完全相同的结构。

与其做被动执行者,你在公司架构设计中的角色因为 AI 时代而变得更加重要。

打造“随时准备好的状态”,因为未来不可预测

虽然我强调了“不构建的决策”的重要性,但 CTO 和内部 SE 还应该具备另一个视角。

因为在 AI 时代未来不可预测,你必须让公司保持随时可以行动的状态。

目前,“SaaS 已死”的论调正在传播。自从微软 CEO 萨提亚·纳德拉在 2024 年底说出这句话后,许多人预测了 SaaS 的终结。确实,SaaS 估值正在被压缩,投资者兴趣迅速转向 AI 原生平台。

但 SaaS 真的会消亡吗?

我认为没那么简单。SaaS 公司正在大力投资研发,寻找 AI 时代软件的最佳形态。 智能体 AI 集成、基于结果的计费、行业特定 AI 平台……产品很可能以我们目前无法想象的形式出现。

换句话说,无论是断定“SaaS 已死”而匆忙转向自研,还是认为“SaaS 就够了”而停止思考,都存在风险。

CTO/内部 SE 应该采取的立场不是押注其中某一方,而是 设计一种无论事态如何发展都能响应的架构。

具体来说,就是标准化数据存储方式,创建不被特定 SaaS 或工具锁定的结构。通过 API 保持系统连接松散耦合。不让零散系统蔓延,统一公司的数据基础。

有了这种设计理念,如果 SaaS 进化出更好的产品,你可以切换。反之,如果某个领域自研更优,你也可以迁移过去。

你无法预测未来。但你可以创建能够响应的结构。这就是 AI 时代对 CTO 和内部 SE 的架构设计本质要求。 反过来,只有技术专家才能做到这一点。我不希望你把这些宝贵资源浪费在内部 SI 上。

用 AI 加速上游流程

为了支持上游流程的转型,我们发布了 “GEAR-UI”,一个屏幕定义和模型生成的 AI 工具,作为 OSS(开源软件)。

通过将其开源,我们希望帮助用户摆脱实施障碍,直面本质。请特别在我讨论的“构建前判断”中使用它。

自定义完全自由。欢迎使用。

One-click save

Use YouMind for AI deep reading of viral articles

Save the source, ask focused questions, summarize the argument, and turn a viral article into reusable notes in one AI workspace.

Explore YouMind
For creators

Turn your Markdown into a clean 𝕏 article

When you publish your own long-form writing, images, tables, and code blocks make 𝕏 formatting painful. YouMind turns a full Markdown draft into a clean, ready-to-post 𝕏 article.

Try Markdown to 𝕏

More patterns to decode

Recent viral articles

Explore more viral articles