在我之前的文章中，我探讨了 AI 需求定义的现状——流程正从"整理"转向"决策"，以及我所担忧的：许多工作场所盲目地将思考外包，却未意识到这一转变。
这次，我想就一个相关问题再次敲响警钟。
问题在于，CTO 和内部 SE 因为能借助 AI 驱动开发快速编写代码，正在沦为业务部门的单纯订单执行者——本质上变成了'内部 SIer'。
AI 驱动开发带来的新格局
AI 驱动开发的普及无可否认地大幅降低了编码门槛。
结果，业务部门诸如"我想要这个"或"我想把这个系统化"的请求以前所未有的速度涌入。业务人员自己用 AI 列出需求，甚至制作原型，这已屡见不鲜。
乍看之下，这是好事。看起来像是一个理想场景：业务部门主导 DX，与 IT 协作快速上线系统。
然而，这里有一个陷阱。
我感觉到越来越多 CTO 和内部 SE 正变成'仅仅把业务部门的请求具象化的人'。 他们接收请求，用技术实现，然后交付。这恰恰就是 内部 SIer 的角色。
订单执行模式的终点
响应业务请求本身并没有错。问题在于 当你持续按原样满足每个部门的请求时会发生什么。
我称之为 '游离系统'和'游离数据库'的泛滥。
销售部门建立自己的 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 Satya Nadella 在 2024 年底说出这句话以来，许多人预测了 SaaS 的终结。确实，SaaS 的估值正在被压缩，投资者兴趣正迅速转向 AI 原生平台。
但 SaaS 真的在消亡吗？
我不认为事情这么简单。SaaS 公司正在大力投资研发，寻找 AI 时代软件的最佳形态。 Agentic AI 集成、基于结果的定价、行业专用 AI 平台……产品很有可能会以我们现在无法想象的形式出现。
换句话说，既不能武断地认为'SaaS 已死'而仓促投入内部开发，也不能停止思考，认为'SaaS 就够了'，两者都有风险。
CTO/内部 SE 应采取的姿态不是押注其中一方。而是 设计一个无论事态如何发展都能响应的架构。
具体来说，标准化数据存储方式，创建不锁定于特定 SaaS 或工具的结构。通过 API 保持系统间的松耦合连接。不要让游离系统泛滥，统一公司的数据基础。
有了这种设计理念，如果 SaaS 进化并出现更好的产品，你可以切换。反之，如果某个领域内部开发更合适，也可以迁移过去。
你无法预测未来。但你可以创建能够应对未来的结构。这就是 AI 时代对 CTO 和内部 SE 架构设计的本质要求。 反过来，也只有技术专家才能做到这一点。我不希望你把这些宝贵的资源浪费在内部 SIer 的角色上。
用 AI 加速上游流程
为了支持上游流程的转型，我们以开源软件（OSS）形式发布了 'GEAR-UI'——一个屏幕定义和原型生成 AI 工具。
通过开源，我们希望帮助用户摆脱实施障碍，直面本质问题。请特别将其用于我讨论的"构建前判断"。
定制完全自由。请善加利用。
