«

AI 架构师的开始

时间：2026-7-7     作者：TONG     分类： 无

以前我是做 Android 的。

这个背景对我影响挺大。因为写 App 的时候，我很早就知道一件事：一个页面能跑，和一个项目能长期维护，是两码事。

刚入行的时候，我也会被一些很漂亮的东西吸引。页面写出来了，接口通了，列表能刷新，缓存也有了。那时候会觉得，嗯，这个功能完成了。

后来项目一复杂，问题就都出来了。

状态放哪。
模块怎么拆。
异常怎么兜底。
新人进来怎么读。
产品改三次以后，原来的代码还撑不撑得住。

架构这个词，不是在功能跑起来那一刻出现的。
它往往是在系统开始变乱的时候，才真正有意义。

现在看 AI 项目，我经常有同样的感觉。

很多人说自己是 AI 架构师，实际做的是另一件事：搭智能体、写提示词、接 API、配一个工作流，然后录个演示视频。演示的时候确实挺顺，客户也容易被打动。

但演示不是上线。

上线以后才是麻烦的开始。

我现在对 AI 架构师的第一个判断

AI 架构师不是最会搭工具的人。

当然，工具要会。
不会工具也谈不上架构。

但只会工具，最多叫 AI 工具搭建师。

我现在更愿意把 AI 架构师理解成这样：

他要设计的是一家公司使用 AI 之后，工作怎么重新流动。

这里面有工具，也有人。
有流程，也有考核。
有知识库，也有责任边界。
有老板想看的收益，也有员工心里那点不舒服。

这句话不太像技术定义，但它更接近真实项目。

因为 AI 进企业以后，最先出问题的地方，经常不是模型。是人和流程。

员工觉得不好用。
中层不知道怎么验收。
老板只看省了几个人。
知识库三个月没人更新。
AI 生成的东西堆在后面没人改。
最后大家说，AI 没效果。

我以前也会顺着这个说法去想，工具是不是没做好。后来发现，不一定。

有些工具交付那天挺好。
只是企业没有给它一个能活下去的位置。

工具层只是第一层，不是全部

先把话说死一点。

工具层必须扎实。

一个客服 Agent，如果连产品价格都答错；一个内容助手，如果十篇稿子九篇都是模板味；一个销售助手，如果对客户阶段判断不准。那后面讲组织、讲流程、讲管理，都没有意义。

工具层至少要做好这些东西：

模块 我会重点看什么
模型选择 成本、速度、稳定性、中文表达、上下文长度
知识库 资料来源、更新频率、切分方式、召回准确率
权限 谁能看客户资料，谁能调用敏感数据
工作流 AI 插在哪个节点，前后由谁接手
日志 出错后能不能追到来源
反馈 员工发现错误后怎么回传
成本 哪个部门、哪个流程、哪个人花了多少调用费
兜底 模型失败、接口失败、知识缺失时怎么处理

这张表其实不复杂。

但很多项目连这张表都没有。

它们只是做了一个入口。输入一句话，输出一段结果。能跑，也能演示，但它不像企业系统，更像一个临时工具。

临时工具有临时工具的价值。
只是别急着叫架构。

我会先看业务里哪一段真的疼

AI 项目最怕一上来就说“全面 AI 化”。

这句话很大，听着很积极，落地的时候往往很散。

我现在更喜欢从一个很小的地方开始拆。比如内容团队、客服团队、销售团队、投放团队、培训团队。先别谈全公司，先看一个流程里最卡的那一段。

我会用一个很土的表。

判断项 适合先做 AI 的情况 暂时别急的情况
频率 每天重复发生 一个月发生两三次
标准 好坏能被判断 全靠老板审美
数据 有历史案例和资料 资料散在群聊和个人脑子里
风险 出错能人工修正 出错直接伤客户或伤钱
后续 AI 输出后有人接 生成完没人处理
收益 能算出时间、成本或转化变化 只是为了显得公司有 AI

这个表不高级。

但它能挡掉很多假需求。

有些需求不是不能做，是现在做了不值。
有些需求老板觉得很酷，但业务上不疼。
有些需求看起来简单，背后数据很乱，最后会变成无底洞。

架构师要敢说“不建议现在做”。

这句话比“能做”更难。

知识库不是把资料扔进去

我以前也犯过这个想法上的懒。

企业有文档，那就做知识库。
产品资料导进去，FAQ 导进去，销售话术导进去。
然后 AI 就应该懂公司了。

实际不是。

企业的知识大多不是一套东西，而是一堆版本。

销售有销售的说法。
客服有客服的说法。
老板有老板的说法。
产品文档写的是一个版本，客户实际问的是另一个版本。
老员工脑子里还有很多没有写下来的经验。

这些东西不整理，AI 只会把混乱说得更流畅。

这就很麻烦。

以前人说错话，可能还带点犹豫。
AI 说错话，语气通常很稳。

所以做企业 AI，知识库要先问四件事：

  1. 哪些资料是正式口径；
  2. 哪些资料已经过期；
  3. 哪些内容可以对客户说；
  4. 哪些内容只能给内部看。

再往下才是技术细节：怎么切分、怎么召回、怎么排序、怎么引用来源。

我现在越来越觉得，知识库的核心不是“库”，而是“知识负责人”。

没有负责人，知识库迟早变垃圾桶。

流程不重画，AI 的效率会被吃掉

拿内容团队举个例子。

原来的流程可能是这样：

选题 → 写脚本 → 改稿 → 客户确认 → 发布 → 复盘

现在 AI 把写脚本从两个小时压到二十分钟。

看起来提效很明显。

但如果改稿的人还是一个人，客户确认还是三天回一次，复盘还是没人看，那整个团队没有真的快起来。只是“写脚本”这个节点变快了。

瓶颈会转移。

这个东西在技术里很常见。
你把接口优化了，数据库慢了。
你把数据库优化了，前端渲染慢了。
你把一个点干快，系统不一定快。

企业流程也是一样。

AI 进来以后，流程图至少要重画一次。

不是为了好看，是为了看清楚这几个点：

这一步不做，AI 很容易变成“局部很先进，整体没变化”。

我对这种项目比较警惕。

因为它最容易在汇报里显得很好看，在业务里没什么感觉。

岗位不会简单消失，但责任一定会变

AI 进来以后，很多岗位的工作量会变化。

这个没必要回避。

内容岗以前主要写初稿，现在初稿被 AI 压缩了。
客服以前回答标准问题，现在标准问题被机器人接走了。
销售以前花很多时间写跟进话术，现在话术可以自动生成。
运营以前整理数据，现在数据整理也可以半自动。

表面看，是岗位被削弱了。

但我不太喜欢只这么看。

更准确一点，是岗位里的低价值部分被压缩，高价值部分被放大。

内容岗以后更像选题和风格判断。
客服更像复杂问题处理和知识库反哺。
销售更像客户意图判断和成交节奏设计。
运营更像数据解释和策略调整。

可以做一张岗位变化表。

原岗位 AI 压缩的部分 人要加强的部分
文案 初稿、标题备选、改写 选题、客户理解、表达判断
客服 标准问答、资料查询 情绪处理、投诉升级、案例沉淀
销售 跟进话术、客户摘要 成交判断、关系推进、关键异议
运营 数据整理、日报生成 指标解释、动作设计、复盘
管理者 手工统计、催进度 质量验收、流程调整、资源分配

这张表要跟团队讲清楚。

不讲清楚，员工只会看到一件事：AI 来了，我可能不安全。

人一旦这么想，就不会真正配合。

他会表面使用，实际绕开。
他会把 AI 当成老板监控自己的工具。
他会尽量不暴露自己真实效率。

这不是员工落后。
这是正常反应。

培训不能再讲“提示词万能公式”

很多企业做 AI 培训，形式很像。

先讲趋势。
再讲模型。
再讲几个提示词技巧。
最后让大家现场试一下。

当时热闹，第二周就凉。

不是大家不想学，是他们回到岗位以后，不知道怎么接到自己的工作里。

一线员工需要的是操作手册，不是趋势报告。

比如文案岗要知道：

客服岗要知道：

中层要学另一套东西。

中层不需要每天研究提示词，他要会验收。

他要知道一篇 AI 辅助文案到底好不好。
他要知道客服机器人答得准不准。
他要知道员工是真的提高了效率，还是只是把原来十分钟能做完的事，用 AI 包装成了半小时。

老板也有自己的课。

老板要看经营结果，不是看热闹。

调用量高不一定有效。
员工都注册了也不代表转型成功。
真正要看的是交付周期、返工率、客户满意度、新人上手时间、转化率、成本变化。

培训分层，AI 才能进岗位。

不分层，就会变成一次气氛很好的活动。

激励不改，员工不会真用

这个地方最难讲，也最应该讲。

一个员工原来一天写五篇稿子。
AI 进来以后，他一天能做十五篇。

如果工资不变，压力变大，他没有理由开心。
如果用得越好，越容易证明岗位可以减少，他更没有理由主动。
如果老板把省下来的钱全拿走，员工只会把 AI 当成威胁。

很多 AI 转型失败，表面是工具失败，底层是激励失败。

我觉得这里至少要改三件事。

1. 不要只按数量考核

AI 时代，数量太容易被刷出来。

更应该看质量、转化、客户反馈、返工率、复盘贡献。

2. 把 AI 使用质量放进绩效

不是看调用次数。

而是看员工有没有把 AI 变成更好的结果。比如沉淀了案例、优化了流程、减少了返工、提高了客户满意度。

3. 提效收益要让团队看见

不一定马上涨工资。

但至少要让团队知道，AI 带来的收益不会只变成更高的工作量。

可以是奖金，可以是分润，可以是晋升标准，也可以是把节省出来的时间转向更有价值的工作。

这件事不解决，前面做得再漂亮，最后也会卡住。

上线以后，还有一堆脏活

AI 项目最容易被忽略的是运营。

交付当天通常最热闹。
群里发通知，老板转发，大家试用，服务商讲解。
看起来很像一件事完成了。

其实刚开始。

上线后会发生很多小问题：

所以 AI 架构师必须给企业留一张运营表。

周期 要看什么 谁负责
每天 明显错误、高风险输出、接口异常 工具负责人
每周 使用率、失败案例、员工反馈 业务负责人
每月 成本、质量指标、流程瓶颈 管理层
每季度 岗位变化、绩效适配、场景扩展 老板和负责人

这个表不复杂。

但它决定系统三个月后还活不活。

AI 工具没有人养，会很快变旧。
业务在变，知识在变，客户问题在变，模型也在变。

上线不是终点。
上线只是开始欠维护债。

我现在看 AI 架构师，会看这些交付物

一个人说自己是 AI 架构师，我不会先看他会不会写很炫的提示词。

我会看他能不能交付这些东西。

AI 架构师交付清单

这里很多东西不酷。

甚至有点麻烦。

但企业 AI 落地，本来就不是只靠酷的东西。

真正能活下来的系统，往往是这些麻烦东西撑住的。

我给 AI 架构师下的标准

我现在会把 AI 架构师分成两种。

一种是工具型。

他能把智能体做出来，能把流程跑通，能让 demo 看起来不错。这个能力有价值，而且市场也需要。

另一种是系统型。

他会先判断场景值不值得做。
会整理企业知识。
会重画流程。
会拆岗位责任。
会设计培训。
会提醒老板改激励。
会给中层验收标准。
会给工具留运营机制。
会提前画风险边界。

这两种人都能做 AI 项目。

但只有第二种，我愿意叫 AI 架构师。

因为架构师这三个字，应该承担“系统长期运行”的责任。

只解决工具问题，交付那天就结束了。
解决系统问题，交付那天才刚开始。

写到最后

我从 Android 转到 AI 架构这个方向以后，越来越觉得两件事很像。

以前写代码，最怕的是只顾眼前功能，不管后面维护。
现在做 AI，最怕的是只顾眼前演示，不管企业怎么用。

功能跑起来不难。
系统跑下去才难。

AI 也是这样。

一个智能体能回答问题，不代表企业完成了 AI 化。
一个工作流能生成报告，不代表管理效率真的提升。
一个知识库能检索资料，不代表公司的知识真的被治理好了。

真正的 AI 架构师，要处理的是工具后面的东西。

人怎么用。
流程怎么变。
知识怎么更新。
责任怎么分。
收益怎么算。
风险怎么控。
三个月后谁继续维护。

这些东西不一定适合拿来做炫技视频。

但它们决定 AI 到底是一个新鲜玩具，还是一家公司新的生产力。

所以我现在不太愿意把“搭个智能体”叫架构了。

那只是开始。

AI 架构师真正要交付的，是一家公司用 AI 之后，能够跑起来、改得动、算得清、有人负责的一套工作系统。

Flag Counter