CIO原创丨AI 对技术的影响及对策

今天这篇，是"AI 原生重塑企业架构"系列的第 1 篇，主题是：AI 原生对技术的影响及对策。

这是一个根本性的转变。

AI 不是给现有技术加个插件，而是要重构整个技术逻辑。

从系统设计、开发模式到迭代逻辑，都在发生根本性变化。

───

一、AI 原生：不是"系统+AI"，而是"AI 原生系统"

现在很多企业的 AI 应用是什么样子？

• 在现有系统上挂一个聊天机器人
• 用户可以在对话框里问问题
• 系统给出回答

这不是 AI 原生，这是"系统+AI"。

真正的 AI 原生系统，是从第一天起就是为 AI 设计的。

传统系统的逻辑是： 功能模块化 → 用户操作 → 完成流程。用户知道要做什么，系统提供工具让用户完成。

AI 原生系统的逻辑是： 意图识别 → 智能体决策 → 动态编排功能。用户只需要表达意图，系统自己拆解任务并执行。

举个例子。

传统的 CRM 系统，用户要跟进一个潜在客户，需要：

• 点击"新建客户" → 填写表单 → 保存
• 找到跟进记录 → 点击"新建跟进" → 填写内容 → 保存

AI 原生的 CRM 系统，用户只需要说：

• "跟进这个潜在客户，约个时间聊聊产品。"
• AI 自动调取客户信息 → 分析客户背景 → 生成跟进方案 → 调用外呼系统 → 预约时间 → 记录结果。

能不能理解用户的模糊意图？能不能自主拆解任务并执行？能不能在过程中学习和优化？

做不到这三点，就不是 AI 原生。

很多企业做 AI 应用，是先把现有系统搬过来，再想办法加个 AI 入口。这是倒过来的。

应该先想清楚：AI 要完成什么目标？需要哪些能力？数据从哪里来？然后反向设计系统架构。

───

二、意图识别：AI 原生的关键中的关键

为什么？

因为意图识别是 AI 原生系统的"第一公里"。如果这一步错了，后面所有的决策、执行、优化，都会沿着错误的方向越走越远。

（一）、意图识别的三层挑战

第一层：理解"说什么"

• 用户说"我想看看上个月的报表"
• 系统需要识别：这是"查询"意图，时间范围是"上个月"，对象是"报表"

第二层：理解"想什么"

• 用户为什么想看报表？
• 是为了汇报？是为了分析？还是为了发现问题？
• 同样的"看报表"，背后意图可能完全不同

第三层：理解"要什么"

• 用户真正需要的是什么？
• 是原始数据？是分析结论？还是行动建议？
• 有时候用户说出来的，不是真正想要的

能不能回答这三个问题？

• 你的系统，能识别用户的显性意图吗？
• 你的系统，能推断用户的隐性意图吗？
• 你的系统，能在意图模糊时主动澄清吗？

做不到这三点，意图识别就是"伪智能"。

───

（二）、意图识别的技术栈

传统方式：关键词匹配 + 规则引擎

• 优点：简单、可控、可解释
• 缺点：覆盖有限、难以处理模糊表达、维护成本高

AI 方式：意图分类模型 + 上下文理解

• 优点：泛化能力强、能处理模糊表达、自适应进化
• 缺点：需要训练数据、可解释性弱、需要持续优化

我的建议：混合架构，分层处理

技术栈要求：

• 意图分类：BERT / RoBERTa / BGE（中文场景）
• 上下文理解：对话状态追踪 + 记忆机制
• 意图澄清：主动提问 + 多轮对话
• 持续优化：意图漂移检测 + 自动标注

───

（三）、意图识别的四个关键能力

1. 意图识别准确率

• 目标：>90%（高频意图），>80%（长尾意图）
• 方法：多模型投票 + 置信度阈值 + 人工兜底

2. 意图边界清晰度

• 目标：每个意图有明确的边界定义
• 方法：意图字典 + 边界案例库 + 负样本训练

3. 意图演化追踪

• 目标：能追踪意图随时间的变化
• 方法：意图版本管理 + 漂移检测 + 定期重训

4. 意图可解释性

• 目标：能解释为什么识别为某个意图
• 方法：注意力可视化 + 关键特征提取 + 人工审核日志

意图识别不是"一次性工作"，是"持续优化的过程"。

───

三、问题：AI 原生时代，5A 架构要怎么变？

过去 30 年，我们做企业架构，底层假设是什么？

5A 架构（业务架构、数据架构、应用架构、技术架构、基础设施架构），是给人用的系统设计的。

用户打开浏览器，点击按钮，填写表单，提交请求。系统返回结果，用户确认，流程继续。整个交互链路，围绕人的认知习惯设计：清晰的菜单、直观的按钮、友好的错误提示。

这套范式，用了几十年，很成熟。

但 AI 时代，这个假设不成立了。

现在的系统，不仅要给人用，还要给智能体用。智能体是什么？是能理解意图、调用工具、自主决策的"数字员工"。它不需要按钮，不需要表单，它需要的是：明确的能力接口、可组合的任务单元、可验证的返回结果。

问题出在哪？

• 业务架构
  ：流程是给"人"走的，不是给"智能体"走的
• 数据架构
  ：数据是"记录"，不是"燃料"
• 应用架构
  ：功能是"模块"，不是"能力单元"
• 技术架构
  ：接口是"给人调用的"，不是"给智能体编排的"
• 基础设施架构
  ：资源是"静态分配"，不是"弹性调度"

这不是技术升级，是设计范式的根本转变。

───

四、核心变化：六个维度的范式转移

第一个变化：交互对象从"人"到"智能体"

• 人需要友好界面，智能体需要明确接口。
• 人需要错误提示，智能体需要可执行的恢复建议。
• 人需要逐步引导，智能体需要一次性完成任务的能力。

第二个变化：上线不是终点，是起点

传统模式： 系统上线 = 项目结束，进入运维期。

• 目标是什么？系统稳定、Bug 少、性能好。
• 数据怎么对待？被动记录日志，很少主动采集。

AI 模式： 系统上线 = 学习开始，持续迭代。

• 目标是什么？模型效果提升、价值持续交付。
• 数据怎么对待？主动采集反馈，用于模型进化。

系统上线是迭代的开始，不是交付的结束。

第三个变化：AI 写代码的成本趋近于零

这是最颠覆的一点。

过去做系统设计，我们考虑什么？复用、抽象、DRY（Don't Repeat Yourself）。为什么？因为人力写代码成本高，能复用的尽量复用，能抽象的尽量抽象。

现在呢？AI 写代码的成本，趋近于零。

复用和抽象的价值，在贬值。

为什么？因为过度抽象，反而增加 AI 理解和调试的难度。AI 生成一段新代码，成本很低；但理解一段高度抽象的旧代码，成本很高。

这不是说复用和抽象不重要了，是优先级变了。

第四个变化：文档即代码——文档不是附属品，是核心资产

过去我们怎么对待文档？

• 项目后期补
• 能省则省
• 给"人"看的，不是给"系统"用的

AI 时代，文档的定义变了。

文档不是"给后人看的说明"，是"给 AI 的指令"。

• 需求文档
  ：不是"这个流程怎么走"，是"这个任务的目标是什么、边界在哪里、有哪些约束"
• 设计文档
  ：不是"这个模块怎么设计"，是"这个能力单元能做什么、不能做什么、怎么组合"
• 接口文档
  ：不是"这个接口有什么用"，是"调用这个接口要传什么、会返回什么、出错时怎么办"

文档即代码，意味着什么？

• 文档是"可执行的"：AI 能理解、能调用、能验证
• 文档是"可追踪的"：代码变了，文档自动更新
• 文档是"可测试的"：文档本身可以作为测试用例

建议：

• 文档不是负担，是"给 AI 的指令"
• 文档不是后期补，是设计时就考虑
• 文档不是"给人看的"，是"给系统用的"

───

五、落地对策：技术架构改造的 7 个优先级

怎么做到？我建议分 7 步走，按优先级排序：

P0（必须做）

意图识别框架

• 意图分类模型 + 上下文理解 + 澄清机制
• 要求：准确率 >85%，支持多轮澄清
• 产出：意图识别服务，支持意图字典管理

数据采集框架

• 埋点规范 + 反馈采集接口
• 要求：结构化、可追溯、可关联
• 产出：每个 AI 交互都有完整的上下文和结果记录

模型版本管理

• 模型仓库 + 版本回滚机制
• 要求：支持在线学习、A/B 测试、灰度发布
• 产出：模型版本可追踪，效果可对比

P1（优先做）

效果监控体系

• 效果指标 + 异常告警
• 要求：业务指标与技术指标联动
• 产出：实时效果看板，异常自动告警

A/B 测试平台

• 流量分配 + 效果对比
• 要求：支持多版本并行、自动流量分配
• 产出：效果对比报告，决策依据

文档即代码

• 意图说明 + 边界定义
• 要求：文档是"给 AI 的指令"，可执行、可追踪、可测试
• 产出：意图明确、边界清晰、示例完整

P2（逐步做）

自动化验证

• 测试生成 + 质量门禁
• 要求：代码生成后自动测试
• 产出：测试覆盖率报告，质量门禁

代码生成规范

• AI 友好型设计原则
• 要求：扁平化、直白化、可解释
• 产出：设计文档 + 代码规范

───

六、设计思想的"贬值"与"升值"

建议：

• 简单功能，直接让 AI 生成，不要过度追求复用
• 核心逻辑，谨慎复用，确保可验证、可解释
• 文档和注释，不是负担，是"给 AI 的指令"
• 测试，不是最后补，是设计时就考虑
• 意图识别，不是"锦上添花"，是"生死攸关"

能做什么，不能做什么？

• 能
  ：用 AI 快速生成代码、快速迭代、快速验证
• 不能
  ：用 AI 替代架构思考、替代业务理解、替代安全审查

───

七、行业观察

从多个企业的 AI 试点项目中，我观察到几个现象：

已经建立反馈闭环的项目：

• 智能客服：用户满意度反馈 → 模型微调 → 每周迭代
• 智能核保：核保结果反馈 → 规则优化 → 每月迭代

数据采集的痛点：

• 埋点不规范：不同项目埋点方式不一致，难以统一分析
• 反馈采集不完整：只有结果，没有上下文，难以用于模型优化

意图识别的实践：

• 有意图识别优化的项目：用户满意度提升 30%，人工干预减少 50%
• 无意图识别优化的项目：用户流失率高，AI 被弃用

文档即代码的实践：

• 有文档即代码的项目：模型迭代周期缩短 50%
• 无文档的项目：AI 生成代码的调试时间增加 3 倍

模型迭代周期：

• 最快：每周迭代（智能客服）
• 最慢：每季度迭代（复杂业务系统）

意图识别和数据采集闭环，是 AI 项目能否持续进化的关键。

───

八、核心观点总结

AI 原生时代技术架构的 6 个转变：

1. 从"给人用"到"给智能体用"
2. 从"交付功能"到"交付价值"
3. 从"上线结束"到"学习开始"
4. 从"复用优先"到"可验证优先"
5. 从"设计优雅"到"可解释、可调试"
6. 从"文档附属"到"文档即代码"

5 条核心建议：

1. 意图识别是关键中的关键
   ——投入足够的资源，建立持续优化机制
2. 不要追求技术上的完美，要追求价值上的可度量
3. 不要上线就万事大吉，要上线就开始收集数据
4. 不要过度抽象，要让 AI 能理解、能调试
5. 不要忽视文档，文档是"给 AI 的指令"

───

下一篇，我聊聊 AI 原生对数据的影响及对策。

欢迎大家交流你的观察和思考。