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

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

- Canonical: https://markhuang.ai/zh/blog/my-company-doesnt-need-ai-think-again
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-05-17
- Section: AI 与 LLM
- Tags: AI 策略, AI 采用, AI 架构, AI 开发者, 企业 AI
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![一个内部 AI 架构团队正在为组织设计安全、可定制的 AI 工作流](https://cdn.markhuang.ai/blog/my-company-doesnt-need-ai-think-again/hero.webp)

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

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

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

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

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

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

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

## 落地路径有好几条

![三条 AI 采用路径汇聚到业务价值](https://cdn.markhuang.ai/blog/my-company-doesnt-need-ai-think-again/adoption-paths.webp)

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

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

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

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

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

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

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

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

## 定制化的坑

![公司特有的数据和工作流试图塞进刚性的外部 AI 服务盒子](https://cdn.markhuang.ai/blog/my-company-doesnt-need-ai-think-again/customization-trap.webp)

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

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

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

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

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

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

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

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

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

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

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

![中央 AI 架构工作室连接到各产品团队内嵌的 AI 开发者](https://cdn.markhuang.ai/blog/my-company-doesnt-need-ai-think-again/team-model.webp)

*中央 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 工具"。

我会先画一张图：

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

这张图会告诉你：你需要的是供应商工具、skill-based 工作流、chat agent、基于 SDK 的自定义应用，还是压根就不该用 AI。

AI 落地不是装个软件，而是融入业务。

想明白这一点的公司，能建立起长期的竞争壁垒。把 AI 当插件用的公司，短期可能尝到效率提升的甜头，但第一版产品跟真实工作流对不上的时候，就会很难受。

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

所以每家公司都需要 AI 架构——道理就这么简单。