夜雨聆风这是飞龙AI知行录的第 8/113 篇。法篇开篇，从五层架构看AI转型的全局。
朴散为器，圣人用之则为官长，故大制不割。——《道德经》第二十八章
不谋全局者，不足谋一域——AI转型的五层架构法。
法篇·大制不割·第八期（总第8期）
一、一把手术刀，还是一个人体解剖图？
2025年初，我第一次走进某车企的IT会议室。墙上挂着三块大屏，每一块都在实时刷新数据：新车销量、售后进场台次、客户满意度评分。会议室里坐了三拨人：IT部门的架构师、业务部门的总监、还有我——一个被请来做AI转型咨询的外部顾问。
"飞龙老师，"IT负责人开门见山，"我们想做一个智能客服，用AI替代目前的人工热线。你能帮我们评估一下可行性吗？"
我没有直接回答。我在白板上画了一个五层的矩形。
"我们先不谈智能客服，"我说，"我们先回答一个问题：你们现在的客户数据，服务顾问能在几秒内调出来？"
沉默。一位售后总监开口了："大概……三分钟？要先打开DMS系统，输入车牌号，等待查询结果，然后再打开另一个系统查投诉记录，再打开第三个系统查保险到期日……"
"这就是问题所在。"我指着白板上最底层的那个矩形，"如果你的数据层是散装的，你在应用层加再多AI，也只是在流沙上盖房子。"
这就是五层架构法的诞生背景。它不是我在书斋里想出来的理论框架，而是我在十几个AI咨询项目中反复撞墙之后，痛定思痛总结出来的诊断工具。
图1｜五层架构法总览——上层建筑的高度，取决于地基的深度
1.1 五层架构法的思想源头
五层架构法本质上是两种传统方法论的融合：
一是IBM于上世纪80年代提出的Zachman企业架构框架（Zachman, 1987, "A Framework for Information Systems Architecture", IBM Systems Journal）。Zachman框架的核心思想是：系统的复杂度来自于多视角——不同角色看同一个系统，看到的是完全不同的东西。企业的CEO、CIO、开发工程师、最终用户，他们各自关心的问题域是正交的。
二是华为在2010年代引入的TOGAF（The Open Group Architecture Framework）实践中的分层治理理念。TOGAF的核心方法论ADM（Architecture Development Method）将企业架构分为四个层次：业务架构、数据架构、应用架构、技术架构。2016年，华为在引入TOGAF的过程中，结合自身实践形成了五层架构的雏形——在标准四层之上单独拆出了"平台层"，以应对大规模分布式系统的治理需求。
我的贡献是在这两个源流的基础上，针对AI时代的特殊挑战做了两项关键创新：
第一，我将"交互层"独立出来，作为第五层。原因很简单：AI时代的交互范式发生了根本性变化——从图形界面（GUI）到对话界面（CUI），从"用户操作机器"到"用户与Agent协作"。这个变化之大，类似于从命令行到Windows的跃迁。正如计算机交互先驱Alan Kay所说："真正认真对待软件的人，应该自己做硬件。"（Kay, 1982, "The Computer Revolution Hasn't Happened Yet", ACM Turing Award Lecture）。在AI时代，我的翻译是：真正认真对待AI应用的人，应该重新设计交互范式。
第二，我明确了五层之间的因果依赖关系——不是平行的五条线，而是一条从底层到顶层的因果链。正如质量管理大师戴明（W. Edwards Deming）在他的系统优化理论中所言："一个系统的94%的问题来自于系统本身，只有6%来自于人。"（Deming, 1993, "The New Economics"）。AI项目的失败，94%不在AI模型本身，而在于你底层的系统基础。
图2｜五层架构法的思想源流：Zachman → TOGAF → 华为实践 → 两项关键创新
二、五层架构的逐层拆解
2.1 数据层：地基，不是金矿
数据层是五层架构的最底层，也是最容易出问题的一层。它包括三个核心维度：
数据完整性：你的数据是否覆盖了业务流程的每一个关键节点？缺失的部分在哪里？
数据一致性：同一个业务实体（比如"客户"）在不同系统中是否统一标识？
数据时效性：数据更新的频率是否匹配业务决策的节奏？
方法论溯源：数据治理的理论基础可以追溯到MIT Sloan管理学院的Richard Wang教授和Diane Strong教授在1996年发表的经典论文《Beyond Accuracy: What Data Quality Means to Data Consumers》（Journal of Management Information Systems）。他们提出了数据质量的四维度模型：内在质量、上下文质量、表达质量和可访问性质量。
在某头部车企的项目中，数据层的诊断结果触目惊心：
DMS（经销商管理系统）和CRM（客户关系管理系统）中的"客户ID"使用的是不同编码体系，同一个客户在两个系统中是两个人；
车辆故障码的记录格式在2019年做了一次系统切换后发生了变化，2019年之前的数据与之后的数据无法衔接；
保养记录的完整率在县级4S店只有43%——大量服务记录根本没有数字化。
数据层诊断自检清单：
核心业务实体是否在"单一真实数据源"（SSOT）中统一定义？ 数据更新延迟是多少？是否在业务容忍范围内？ 数据质量问题的根因是技术问题还是流程问题？
2.2 模型层：引擎，不是魔法
模型层是AI价值创造的核心。它包括三个子维度：
模型选择：通用大模型（基础能力）vs 垂直模型（领域精确度）vs 小模型（成本效率）
模型治理：版本管理、性能监控、A/B测试机制
模型安全：输出内容的合规审查、偏见检测、幻觉率监控
方法论溯源：模型治理的概念源自Google在2015年发表的论文《Hidden Technical Debt in Machine Learning Systems》（Sculley et al., NeurIPS 2015）。这篇论文指出：在一个真实的机器学习系统中，ML代码本身只占整个系统代码的很小一部分（约5%），其余95%是数据管道、配置管理、服务基础设施等"胶水代码"。
我在项目评估中经常做一个简单的测试：问客户的AI团队，"你们上一个模型的版本号是多少？它在生产环境中跑了多久？如果它明天突然出了问题，你们需要多长时间定位到问题？"
三个问题，90%的团队连一个都答不好。
模型层诊断自检清单：
你的模型是否有版本管理系统？ 你的模型在生产环境中的表现是否有实时监控？ 你的模型输出是否有人工审核的熔断机制？
2.3 平台层：底座，不是通道
平台层是连接模型与应用的关键枢纽。它承担三个核心功能：
API网关与流量管理：确保AI服务可以弹性扩展、安全可控地被各业务系统调用 MCP协议与知识库管理：管理模型与外部工具、知识库的连接 技能（Skills）与插件生态：管理Agent的可调用能力
方法论溯源：平台工程（Platform Engineering）的概念最早由ThoughtWorks的技术雷达在2017年引入，随后被Gartner在2022年列为十大战略技术趋势之一。
我的扩展是：AI时代的平台层不仅要服务人类开发者，还要服务AI Agent。你得设计两个"租户"——人类开发者和Agent——它们共享同一个平台基础设施，但调用模式和权限边界完全不同。
平台层诊断自检清单：
你的AI能力是否以API形式标准化暴露？ 你的Prompt模板和知识库是否有统一的版本管理？ 你的平台是否支持Agent和人类在同一权限体系下协作？
2.4 应用层：界面，不是外挂
应用层是AI能力面向业务场景的具象化。它的核心挑战是"嵌入"而非"外挂"——AI不能是业务流程中的一个独立步骤，而应该是每个流程节点的自然组成部分。
方法论溯源：应用层的设计原则可以追溯到哈佛商学院教授克莱顿·克里斯坦森（Clayton Christensen）在1997年提出的"颠覆性创新"理论。
举个例子：传统客服流程是——用户打电话→IVR语音导航→人工坐席接听→查找知识库→回答问题。AI-enabled的做法是：在现有流程中加一个环节——人工坐席接听的时候，旁边弹出一个AI建议窗口。AI-native的做法是：重新定义流程——用户用自然语言描述问题→Agent理解意图→自动查询知识库→如果答案确定性超过阈值则直接回复，否则转人工。
图3｜外挂式 vs 嵌入式——「人先做，AI帮一点」与「AI先做，人审一下」的分野
应用层诊断自检清单：
你的AI应用是"嵌入"在现有流程中，还是"外挂"在旁边？ 用户使用你的AI功能需要额外学习吗？ 你的AI应用有明确的"人类接管"机制吗？
2.5 交互层：入口，不是屏幕
交互层是用户感知AI的"第一界面"。在AI原生架构中，交互层不再是传统的图形界面，而是以对话、语音、多模态为主的新型交互范式。
方法论溯源：交互层的重要性在唐·诺曼（Don Norman）的经典著作《设计心理学》（The Design of Everyday Things, 1988/2013）中早有论述："好的设计是让你感觉不到设计的存在。"
斯坦福大学人机交互实验室的Terry Winograd教授（Google创始人Larry Page和Sergey Brin的导师）在2006年的论文中提出过一个前瞻性观点：交互设计的对象正在从"计算机"变为"信息"。AI加速了这一转变——用户不再关心他们在用什么软件，他们只关心自己的需求是否被理解。
交互层诊断自检清单：
用户是在"学习使用你的AI"还是在"让AI帮他做事"？ 你的AI交互是否支持多轮对话而非单次问答？ 你的交互界面是否在不同设备上保持一致的体验？
三、五层之间的因果链：一个真实案例
回到某头部车企的案例。我带着IT和业务团队，按照五层架构法从底层开始逐层诊断。
数据层问题：客户ID在两个系统中不统一，导致任何一个"精准营销"的AI模型都是在混乱的客户画像上建立起来的。修复策略：启动客户数据平台（CDP，Customer Data Platform）建设，将DMS、CRM、SCRM三个系统中的客户数据打通，实现One ID。
注：CDP的概念最早由David Raab在2013年提出，Gartner在2018年将其纳入技术成熟度曲线。
模型层问题：在数据没有打通的条件下，任何AI模型的训练都是"垃圾进，垃圾出"（Garbage In, Garbage Out，简称GIGO原则，这一原则可追溯到1957年美国军方计算机先驱William Mellin的原始表述）。但修复策略不是等数据完美了再开始——那是永远等不到的。而是采用"垂直场景优先"策略：先选择数据质量相对最好的场景（比如保养到期提醒），训练一个专用模型，跑通后再扩展到其他场景。
平台层问题：某头部车企没有一个统一的AI服务平台，各业务部门各自为战。企微SCRM用一套NLP引擎，电话客服用另一套，小程序上的智能助手用第三套。三套引擎之间没有知识共享。修复策略：启动AI中台建设，将模型服务、Prompt管理、知识库统一纳管。
应用层问题：现有的AI应用都是在现有系统上"外挂"的。比如服务顾问在DMS里填写工单的时候，旁边弹出一个AI故障诊断建议窗口——但这个窗口和DMS是完全独立的两个系统，数据不互通。修复策略：用"嵌入式AI"替代"弹窗式AI"，让AI建议自然出现在业务流程的每个关键决策点上。
交互层问题：用户在微信端、App端、车载端感受到的AI形象和对话能力完全不统一。修复策略：建立统一的"品牌数字人物"体系，确保跨渠道的一致体验。
图4｜某头部车企售后五层诊断实录：每一层的问题与修复策略
四、五层架构法的使用心法
经过几十个项目的验证，我总结了使用五层架构法的三条黄金法则：
法则一：永远从下往上诊断，从上往下修复
诊断从数据层开始往上看——90%的问题出在底层。但修复反过来——从交互层开始往下做，因为交互层的改进"见效最快"，能快速证明价值。这个原则的智慧源自丰田生产系统的"现地现物"理念——大野耐一说："数据当然重要，但我最重视的是事实。"
图5｜诊断与修复的双向路径——90%的问题出在底层，但修复从交互层开始
法则二：每一层都有一个"不能妥协的最小标准"
数据层：核心业务实体必须有唯一的、统一的标识（One ID） 模型层：必须有版本管理和回滚机制 平台层：所有AI调用必须经过统一的API网关 应用层：必须有"人类接管"的熔断机制 交互层：必须支持多轮对话的上下文管理
法则三：架构是活的，不是画完就挂墙上的
五层架构法不是静态的"架构图"，而是动态的"诊断框架"。你应该在每个AI项目的每个关键里程碑都用它做一次全栈检查。就像丰田的"A3报告"——不是写完了就完事了，而是一个持续更新的问题解决记录。
五、结语
回到开头那个故事。那位IT负责人问我能不能做一个智能客服。
我用五层架构法做了诊断之后，给他的答案是："能，但不是现在。"
"你需要三个月启动智能客服的MVP——不是因为先把数据和平台全部搞定了，而是因为数据和平台的搭建与智能客服的第一个原型在并行推进中互相校准。到第十一周，你拿出来的不是一个孤立的客服系统，而是一个嵌入在服务顾问工作流程中的AI助手——它的底层，已经被真实的客服需求牵引着打好了地基。"
他沉默了几秒，然后笑了："所以你说的不是智能客服。"
"不是。我说的是智能化的售后服务系统。客服只是用户接触到的那个'顶'。"
《孙子兵法·谋攻篇》说："不谋全局者，不足谋一域。"清代学者陈澹然在《寤言·二迁都建藩议》中将其概括为更精炼的版本："不谋万世者，不足谋一时；不谋全局者，不足谋一域。"
AI转型最怕的不是没技术，而是在没有看见全局的时候就一头栽进了某一个细节。五层架构法不是别的——它就是那双让你看见全局的眼睛。
如果这篇文章让你想起了某个还在流沙上盖AI的老板/同事，转发给他。有些话你说不出口，我帮你说。
下期预告
第九期·上德不德，是以有德——AI评估指标体系的三级分解怎么判断一个AI项目到底有没有价值？
长按识别二维码，关注「飞龙AI知行录」，别错过后面的105篇。
