“我的公司不需要 AI。”再想想。
AI 采用不只是选择工具。即使自认为不需要 AI 的公司,也需要理解 AI 应该放在哪里、哪些东西必须保持确定性,以及谁来负责定制、安全和长期控制。
AI 驱动 · 每小时限 20 次请求

从 Skills 到 Agents,从 MCP tools 到 SDK 工作流,我都折腾了一遍之后,对企业怎么落地 AI 这件事,看法确实变了不少。
经常有公司说"我们不需要 AI"。但这句话背后真正想说的是:我们还不知道 AI 该往哪儿放。
关键问题从来不是 AI 能不能帮到公司——当然能。真正的问题是:AI 在业务里应该放在什么位置?给它多大的权限?当它开始碰到真实数据、真实流程、真实客户的时候,谁来管这个架构?
大部分公司其实还在摸索。有的团队在试 chat 界面,有的在搞内部工具,有的直接买现成的 AI 产品,还有的干脆不动——因为不知道怎么安全地用起来。
我觉得没有标准答案。走哪条路,取决于公司的技术底子、数据复杂度、风险容忍度,以及对定制化的需求有多强。
但有一点我很确定:每家公司都需要有人来管 AI 架构这件事。
落地路径有好几条

选哪条路,很大程度上取决于你是什么类型的公司。
| 公司情况 | 实际路径 | 优势 | 短板 |
|---|---|---|---|
| 技术团队强 | 用 SDK 自建 AI 方案 | 控制力和定制空间最大 | 需要工程团队持续投入 |
| 业务团队为主 | 用 Skills、chat agents,或者 M365 Copilot 这类工具 | 上手快、门槛低 | 流程控制力有限 |
| 技术资源有限 | 买或外包专业 AI 服务 | 最快拿到现成的专业能力 | 容易水土不服,也容易被供应商绑定 |
如果公司工程团队够强,我会建议直接走 SDK 路线。不是因为 SDK 时髦,而是因为代码意味着掌控力。哪些数据可以喂给模型、模型能调什么工具、输出怎么校验、日志存到哪里、什么环节必须人工审批——这些全由你说了算。
如果公司更偏业务侧,Skills 和 chat-based agents 可能是更好的切入点。团队可以把重复性的工作流固化下来,把最佳实践沉淀成文档,把日常任务自动化——不需要一上来就搭一整套自定义平台。写草稿、做 review、生成摘要、查内部知识库、处理日常办公流程,这些场景都很适合。
技术资源确实有限的公司,外包也说得通。专业的服务商可能已经很懂你的行业,比从零招人组建团队要快得多。
这几条路没有哪条是天然错误的。
问题在于:你选的时候,有没有想清楚背后的取舍。
定制化的坑

我对 packaged AI service 最大的顾虑,就是定制化。
每家公司的数据结构、权限模型、工作流、老系统、报表习惯、合规要求、内部术语都不一样。两家公司都说需要"AI 客服",但实际需要的系统可能完全不同。
一家要深度对接 CRM,另一家要支持多语言升级流转,第三家要求所有对客回复必须先过法务,第四家只需要 AI 帮忙总结工单但绝对不能自动回复客户,还有一家的历史数据一团糟,不清理干净根本没法用。
通用型的服务当然能帮上忙,但它往往是要你去适配它的模型。结果就是:配置复杂、connector 脆弱、流程改动空间有限,甚至将来想迁移的时候发现太痛苦——因为太多业务流程已经围绕着别人的产品长出来了。
这就是为什么 AI 落地不只是选个工具那么简单。
它本质上是一个架构问题。
总得有人来回答这些问题:
- 哪些场景适合让 AI 自动处理?
- 模型能看到哪些数据?
- 哪些操作必须经过人工审批?
- 哪些流程必须用确定性代码,不能让 agent 自己推理?
- 怎么衡量这套系统到底有没有用?
- 业务变了,系统怎么跟着变?
如果这些问题没人管,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.
相关文章

下一段路:建立跨模型家族的 AI 实践
从单一模型到自优化的五级成熟度模型,面向个人、团队和企业的可执行下一步,以及对仍需补齐的证据缺口的坦诚整理。跨模型家族多 AI 系列第六章。
阅读文章
System Prompt 与 User Prompt:GenAI 功能下面的那一层
一篇面向初学者的 system_prompt 与 user_prompt 解释,用 ChatGPT、Claude Projects、Claude Cowork 和 Claude Code 作为例子。
阅读文章
AI 是坏的吗?
AI 可以让你更快、更懒、更有能力,也更依赖外部系统。真正的问题不是 AI 好不好,而是你选择外包哪部分知识,以及这笔交换是否值得。
阅读文章