跳转到主要内容

“我的公司不需要 AI。”再想想。

AI 采用不只是选择工具。即使自认为不需要 AI 的公司,也需要理解 AI 应该放在哪里、哪些东西必须保持确定性,以及谁来负责定制、安全和长期控制。

5 分钟阅读
分享:
AI 驱动

AI 驱动 · 每小时限 20 次请求

一个内部 AI 架构团队正在为组织设计安全、可定制的 AI 工作流
一个内部 AI 架构团队正在为组织设计安全、可定制的 AI 工作流

试过技能、智能体、MCP 工具和基于 SDK 的工作流之后,我对企业 AI 采用的看法变了。

当一家公司说“我们不需要 AI”时,我通常听到的潜台词是:我们还不知道 AI 应该放在哪里。

重要问题不是 AI 能不能帮公司。它能。真正的问题是 AI 应该放在业务的什么位置,它应该拥有多少权限,以及当它开始接触真实数据、真实流程和真实客户时,谁来负责架构。

大多数公司还在消化这个变化。有些团队在试聊天界面,有些在做内部工具,有些在购买专门 AI 产品,还有一些在等待,因为不知道怎样安全采用 AI。

我不认为只有一条正确路线。合适路径取决于公司的技术能力、数据复杂度、风险承受能力和对定制化的需求。

但我确实认为,每家公司都需要有人负责 AI 架构。

AI 采用有几条路

三条 AI 采用路径汇聚到业务价值
三条 AI 采用路径汇聚到业务价值

采用路径很大程度上取决于你是哪类组织。

公司情况实际路径强项弱点
技术团队强用 SDK 构建定制 AI 方案控制力和定制化最高需要工程所有权
业务团队为主使用技能、聊天智能体,或 M365 Copilot 之类工具采用快、门槛低流程保证有限
技术资源有限购买或外包专门 AI 服务最快拿到封装好的专业能力可能不贴合业务,也容易被供应商锁定

如果公司有强工程团队,我会直接从基于 SDK 的方案开始。不是因为 SDK 新潮,而是因为代码给你控制权。你可以决定哪些数据进入模型,模型能调用什么工具,输出如何验证,日志放在哪里,以及什么时候必须由人批准下一步。

对更偏业务的组织,技能和基于聊天的智能体可能是更好的起点。团队可以编码重复工作流、沉淀实践、自动化常见任务,而不必一开始就做完整自定义平台。写作、评审、总结、内部知识访问和办公工作流都适合从这里起步。

对技术资源非常有限的公司,外包也有意义。专门服务商可能已经理解这个领域,比从零招聘团队更快产生价值。

这些路径没有哪条天然错误。问题是:你不能在不理解取舍的情况下选择其中一条。

定制化问题

公司特有的数据和工作流试图塞进刚性的外部 AI 服务盒子
公司特有的数据和工作流试图塞进刚性的外部 AI 服务盒子

我对封装式 AI 服务最大的担心是定制化。

每家公司都有自己的数据形状、权限模型、工作流、遗留系统、报告习惯、合规规则和内部语言。两家公司都说需要“AI 客户支持”,但实际需要的系统可能完全不同。

一家需要深度 CRM 集成,另一家需要多语言升级流程,第三家需要所有对外回复先经过法律评审,第四家只想让 AI 总结支持工单但绝不能自动回复客户,还有一家的历史数据很乱,不清洗就不能信。

通用服务可以帮忙,但它通常要求公司适配服务本身的模型。这可能意味着复杂配置、脆弱连接器、有限的流程变化,或者未来迁移时很痛苦,因为太多业务流程已经围绕别人的产品塑形。

这就是 AI 采用超出工具选择的地方。

它变成了架构。

有人必须回答这些问题:

  • 哪些用例适合 AI 自动化?
  • 模型可以看到哪些数据?
  • 哪些动作需要人类批准?
  • 哪些工作流应该用确定性代码,而不是智能体推理?
  • 如何衡量系统真的有帮助?
  • 业务变化时,系统如何跟着变化?

如果没人负责这些问题,AI 采用就会变成分散实验。有些会有帮助,有些会制造风险,大多数都会很难维护。

我认为公司需要的团队

中央 AI 架构工作室连接到各产品团队内嵌的 AI 开发者
中央 AI 架构工作室连接到各产品团队内嵌的 AI 开发者

我脑中的理想状态,不是每家公司都建一个巨大的 AI 实验室。

它更简单:每个组织都应该有 AI 架构职能。

对小公司来说,这可能是一位 AI 架构师加一两位 AI 开发者。对工程能力强的大公司,我认为每个团队嵌入一位 AI 开发者,并由中央 AI 架构团队支持,会变得很正常。

AI 架构师负责确定采用方式的形态:

  • 哪里允许 AI 做决定
  • 哪里必须由确定性系统保持控制
  • 数据访问如何限定范围
  • 团队应该复用哪些模式
  • 需要什么评估和审计标准
  • 供应商工具如何放进长期架构

AI 开发者负责构建实际系统:

  • 基于 SDK 的工作流
  • 内部副驾
  • MCP 工具和连接器
  • 数据检索流水线
  • 评估框架
  • 人类审批流程
  • 团队专属自动化

这不只是提示词工程。提示词设计是其中一部分,但真正有价值的能力,是把混乱的业务需求转化为有用、安全、可维护、可演进的系统。

未来角色更接近解决方案架构

我很看好能在这个交叉领域工作的软件开发者。

公司不只是需要会调用 LLM API 的人。那件事会越来越简单。公司需要能看懂一个业务流程,并决定哪些部分应该自动化、哪些应该保留给人、哪些应该确定性运行、哪些可以概率化处理、以及所有部件如何连接的人。

这就是我认为 AI 解决方案架构师会重要的原因。

这份工作不是把每个工作流都换成智能体,而是设计 AI 和业务之间的边界。有时答案是 SDK,有时是聊天界面,有时是买供应商产品,有时是告诉公司暂时不要自动化某个决策,因为数据还没准备好,或者风险太高。

最好的 AI 采用,不会来自“使用最多 AI”的公司,而会来自知道 AI 应该放在哪里的公司。

我现在的看法

如果今天让我给一家公司建议,我不会从“我们应该买哪个 AI 工具?”开始。

我会先画一张地图:

业务工作流
  -> 涉及的数据
  -> 正在做出的决策
  -> 错误输出的风险
  -> 所需定制化
  -> 当前技术容量
  -> 最佳 AI 采用路径

这张地图会告诉你,你需要供应商工具、基于技能的工作流、聊天智能体、自定义 SDK 应用,还是根本不该用 AI。

AI 采用不是安装,而是集成。

理解这一点的公司会建立持久优势。把 AI 当插件的公司,可能得到短期生产力收益,但当第一版不适配真实工作流时,会很痛苦。

每家公司都会需要 AI 能力。但不是每家公司都需要同一套 AI 技术栈。

这正是为什么每家公司都需要 AI 架构。

许可

Article text © 2026 Mark Huang. Licensed under Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0) unless otherwise noted. 文章文本可在非商业场景下分享或翻译,但需标注原文 URL。商业使用需事先取得书面许可,并清楚引用原始来源。

代码片段、截图、第三方素材和网站源码可能适用单独条款。

建议署名: Based on "“我的公司不需要 AI。”再想想。" by Mark Huang, originally published at https://markhuang.ai/zh/blog/my-company-doesnt-need-ai-think-again.

订阅更新

Go、AI/LLM 和分布式系统的技术文章,绝不滥发。

评论

正在加载评论...