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

试过技能、智能体、MCP 工具和基于 SDK 的工作流之后,我对企业 AI 采用的看法变了。
当一家公司说“我们不需要 AI”时,我通常听到的潜台词是:我们还不知道 AI 应该放在哪里。
重要问题不是 AI 能不能帮公司。它能。真正的问题是 AI 应该放在业务的什么位置,它应该拥有多少权限,以及当它开始接触真实数据、真实流程和真实客户时,谁来负责架构。
大多数公司还在消化这个变化。有些团队在试聊天界面,有些在做内部工具,有些在购买专门 AI 产品,还有一些在等待,因为不知道怎样安全采用 AI。
我不认为只有一条正确路线。合适路径取决于公司的技术能力、数据复杂度、风险承受能力和对定制化的需求。
但我确实认为,每家公司都需要有人负责 AI 架构。
AI 采用有几条路

采用路径很大程度上取决于你是哪类组织。
| 公司情况 | 实际路径 | 强项 | 弱点 |
|---|---|---|---|
| 技术团队强 | 用 SDK 构建定制 AI 方案 | 控制力和定制化最高 | 需要工程所有权 |
| 业务团队为主 | 使用技能、聊天智能体,或 M365 Copilot 之类工具 | 采用快、门槛低 | 流程保证有限 |
| 技术资源有限 | 购买或外包专门 AI 服务 | 最快拿到封装好的专业能力 | 可能不贴合业务,也容易被供应商锁定 |
如果公司有强工程团队,我会直接从基于 SDK 的方案开始。不是因为 SDK 新潮,而是因为代码给你控制权。你可以决定哪些数据进入模型,模型能调用什么工具,输出如何验证,日志放在哪里,以及什么时候必须由人批准下一步。
对更偏业务的组织,技能和基于聊天的智能体可能是更好的起点。团队可以编码重复工作流、沉淀实践、自动化常见任务,而不必一开始就做完整自定义平台。写作、评审、总结、内部知识访问和办公工作流都适合从这里起步。
对技术资源非常有限的公司,外包也有意义。专门服务商可能已经理解这个领域,比从零招聘团队更快产生价值。
这些路径没有哪条天然错误。问题是:你不能在不理解取舍的情况下选择其中一条。
定制化问题

我对封装式 AI 服务最大的担心是定制化。
每家公司都有自己的数据形状、权限模型、工作流、遗留系统、报告习惯、合规规则和内部语言。两家公司都说需要“AI 客户支持”,但实际需要的系统可能完全不同。
一家需要深度 CRM 集成,另一家需要多语言升级流程,第三家需要所有对外回复先经过法律评审,第四家只想让 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.
相关文章

我可能看错了 Agentool
一篇个人自动化复盘:我曾经构建 agentool,希望让 AI CI 工作流更轻;后来意识到真正的成本可能是功能维护、编排复杂度,以及追逐 Claude Agent SDK 和 Codex SDK 已经承担的 SDK 行为。
阅读文章
别再从零开始教每一个 AI
一篇关于 Dense-Mem 的个人反思:哪些问题把我从静态 skills 和过期文件推向动态共享记忆、只读自动化上下文、导入导出,以及受治理的知识图谱。
阅读文章
我有点替 AI 委屈
为什么 AI 狂热和反 AI 敌意都错过了同一个重点:LLM 更像成绩很好的应届新人,而不是资深专家。有用的智能体需要入职培训、技能和维护过的记忆,而不是第一次尝试就完美的期待。
阅读文章订阅更新
Go、AI/LLM 和分布式系统的技术文章,绝不滥发。
评论
正在加载评论...