跳转到主要内容

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

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

5 分钟阅读
分享:
AI 驱动

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

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

从 Skills 到 Agents,从 MCP tools 到 SDK 工作流,我都折腾了一遍之后,对企业怎么落地 AI 这件事,看法确实变了不少。

经常有公司说"我们不需要 AI"。但这句话背后真正想说的是:我们还不知道 AI 该往哪儿放。

关键问题从来不是 AI 能不能帮到公司——当然能。真正的问题是:AI 在业务里应该放在什么位置?给它多大的权限?当它开始碰到真实数据、真实流程、真实客户的时候,谁来管这个架构?

大部分公司其实还在摸索。有的团队在试 chat 界面,有的在搞内部工具,有的直接买现成的 AI 产品,还有的干脆不动——因为不知道怎么安全地用起来。

我觉得没有标准答案。走哪条路,取决于公司的技术底子、数据复杂度、风险容忍度,以及对定制化的需求有多强。

但有一点我很确定:每家公司都需要有人来管 AI 架构这件事。

落地路径有好几条

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

选哪条路,很大程度上取决于你是什么类型的公司。

公司情况实际路径优势短板
技术团队强用 SDK 自建 AI 方案控制力和定制空间最大需要工程团队持续投入
业务团队为主用 Skills、chat agents,或者 M365 Copilot 这类工具上手快、门槛低流程控制力有限
技术资源有限买或外包专业 AI 服务最快拿到现成的专业能力容易水土不服,也容易被供应商绑定

如果公司工程团队够强,我会建议直接走 SDK 路线。不是因为 SDK 时髦,而是因为代码意味着掌控力。哪些数据可以喂给模型、模型能调什么工具、输出怎么校验、日志存到哪里、什么环节必须人工审批——这些全由你说了算。

如果公司更偏业务侧,Skills 和 chat-based agents 可能是更好的切入点。团队可以把重复性的工作流固化下来,把最佳实践沉淀成文档,把日常任务自动化——不需要一上来就搭一整套自定义平台。写草稿、做 review、生成摘要、查内部知识库、处理日常办公流程,这些场景都很适合。

技术资源确实有限的公司,外包也说得通。专业的服务商可能已经很懂你的行业,比从零招人组建团队要快得多。

这几条路没有哪条是天然错误的。

问题在于:你选的时候,有没有想清楚背后的取舍。

定制化的坑

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

我对 packaged AI service 最大的顾虑,就是定制化。

每家公司的数据结构、权限模型、工作流、老系统、报表习惯、合规要求、内部术语都不一样。两家公司都说需要"AI 客服",但实际需要的系统可能完全不同。

一家要深度对接 CRM,另一家要支持多语言升级流转,第三家要求所有对客回复必须先过法务,第四家只需要 AI 帮忙总结工单但绝对不能自动回复客户,还有一家的历史数据一团糟,不清理干净根本没法用。

通用型的服务当然能帮上忙,但它往往是要你去适配它的模型。结果就是:配置复杂、connector 脆弱、流程改动空间有限,甚至将来想迁移的时候发现太痛苦——因为太多业务流程已经围绕着别人的产品长出来了。

这就是为什么 AI 落地不只是选个工具那么简单。

它本质上是一个架构问题。

总得有人来回答这些问题:

  • 哪些场景适合让 AI 自动处理?
  • 模型能看到哪些数据?
  • 哪些操作必须经过人工审批?
  • 哪些流程必须用确定性代码,不能让 agent 自己推理?
  • 怎么衡量这套系统到底有没有用?
  • 业务变了,系统怎么跟着变?

如果这些问题没人管,AI 落地就会变成一盘散沙式的实验。有些能派上用场,有些会埋下风险,大多数会变得越来越难维护。

我觉得公司需要什么样的团队

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

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

事情没那么复杂:每个组织都应该有 AI 架构这个职能。

小公司的话,一个 AI 架构师加一两个 AI 开发者就够了。大公司、工程体系比较成熟的,我觉得未来每个业务团队嵌入一个 AI 开发者、再有一个中央 AI 架构团队做支撑,会变成常态。

AI 架构师管的是全局:

  • 哪些地方允许 AI 做决策
  • 哪些地方必须用确定性系统把控制权握在手里
  • 数据访问的边界怎么划
  • 团队应该复用哪些模式
  • 评估和审计的标准是什么
  • 供应商的工具怎么融入长期架构

AI 开发者负责把东西做出来:

  • 基于 SDK 的工作流
  • 内部 copilot
  • MCP tools 和 connector
  • 数据检索 pipeline
  • 评估框架
  • 人工审批流程
  • 各团队专属的自动化

这可不是写写 prompt 就行的。Prompt engineering 是其中一环,但真正值钱的能力是:把一团乱麻的业务需求,变成好用、安全、可维护、能演进的系统。

这个角色未来更像解决方案架构师

我很看好能在这个交叉地带干活的开发者。

公司需要的不是会调 LLM API 的人——这件事越来越简单了。公司需要的是能看懂一个业务流程,然后判断:哪些环节该自动化、哪些该留给人、哪些必须确定性执行、哪些可以概率化处理、各个部分怎么串起来。

这也是为什么我觉得 AI solution architect 这个角色会越来越重要。

这份工作的核心不是把所有工作流都换成 agent,而是设计 AI 和业务之间的那条边界线。有时候答案是 SDK,有时候是 chat 界面,有时候是买供应商的产品,有时候是告诉公司:这个决策先别自动化,数据还没准备好,或者风险太高。

AI 落地做得最好的,不会是 AI 用得最多的公司,而是最清楚 AI 该放在哪里的公司。

我现在的看法

如果今天有公司来问我建议,我不会上来就聊"该买哪个 AI 工具"。

我会先画一张图:

业务工作流
  -> 涉及哪些数据
  -> 在做什么决策
  -> 输出出错的风险有多大
  -> 需要多深的定制
  -> 目前的技术能力
  -> 最适合的 AI 落地路径

这张图会告诉你:你需要的是供应商工具、skill-based 工作流、chat agent、基于 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.