从云原生转型到AI转型，什么值得借鉴？什么需要摒弃？

1895 年，Panhard & Levassor 造出第一批量产汽车¹。不是在工厂从零设计的——他们把 Daimler 内燃机绑在传统马车的木头底盘下面。驭手座位还在，铁包木轮没换，只是马没了。同期 De Dion-Bouton 的"蒸汽马"也是一样的思路：发动机替代马，马车架原封不动。

那画面不是笑话——那辆车真的跑起来了，而且跑出了汽车工业的第一步。但它也跑不远：木头车架扛不住内燃机振动，铁包木轮在今天的柏油路上会打滑，转向系统是为马设计的没有所谓的方向盘。当时那辆车除了没马很多方面还不如马车（高昂的价格、难以驾驭、跑得慢），真正的汽车是后来才出现的——钢制底盘、橡胶轮胎、方向盘——从零为发动机设计的车。

转型的隐喻不在"往马车上装发动机"，而在那之后发生了什么。

旧马车是你现有的研发体系——流程、工具链、组织分工，全部为"人写代码"设计的。发动机是 AI 能力——大模型、Agent、自动化决策。往马车上装发动机能跑一阵子，Panhard & Levassor 的马车就跑了——但木头车架扛不住长期振动，转向系统是给马设计的。你的老流程也一样：硬塞 AI 进去，初期有点效果，但评审机制、测试体系、SLO 定义全是给"人写代码"设计的，撑不久。

我们得先造辆新车——建一个从零设计的 AI Native 试点，用新流程、新工具、新角色。跑通了，再把客人和货物一批批拉过去。同时修路——算力、电力、工具链。路不通，再好的车也跑不起来。

我搞云原生转型时，从荔枝微课（即十方融海）到腾讯音乐，推过云原生、Devops等，也推过服务网格乃至扩展，和这画面一模一样。现在推 AI 转型，还是这画面。

借鉴什么

最近看了锅总一篇讲 AI 组织转型的文章²，他把传统研发团队一步步改成 AI Native 团队，分了十一步。读到一半我就笑了——这剧本我见过。同一条曲线，只不过我当年的关键词是容器、K8s、服务网格，他的是 Agent、Prompt、模型适配。

第一条，搞定人。

锅总从灌 CEO 焦虑开始。我当年接手荔枝微课基础架构时，不需要这一步——老板已经被事故搞到头大了，我一说想法就是拍即合。但不管从哪起步，后面一样：技术选型可以慢慢调，人的阻力不解决，全是死路。

云原生时代开发者的阻力是"又要学 YAML？又要学容器？“AI 时代的阻力更深——“AI 写的代码我不敢用”、“我会不会被替代？“锅总踩过一个坑：有人提示词写得不好，产物质量差，于是更不信任 AI，更不愿意用——恶性循环。他只能一对一纠偏，坐过去教。这和我当年一模一样，有人被 YAML 缩进搞疯一次就再也不想碰 K8s，你也得一对一陪着改。

我还有个做法是往多里拉盟友。招进来的人要有相同的理念，从外部拉做推广的人做背书。管理层先上手体验，各种场合渲染"以前三天部署现在半小时”，但少提"转型"两个字——东西好用，大家自然就用了。

搞过转型的人懂这个节奏：什么时候推，什么时候等，什么时候让数据说话。焦虑是正常的，关键不是消除焦虑，而是给出一条能走的路。

第二条，工具减负是转型的生命线。

当年我在荔枝微课自己做过一个功能强大的平台，但很多人的反馈并不好，后来听取意见和团队推了一个 CLI，可以让开发一键创建、切换或协调占用集群里的分支测试环境。不解决"多人共用环境互相踩踏"的问题，开发永远不会觉得云原生帮到了他们。工具的意义不只是功能多强，更是让开发者少操一份心，我们说的减少心智负担。

AI 时代完全一样，而且工具链的缺口更大。我前段时间用 AI 对前公司的一个用于AI安全沙盒的开源项目 TenBox 贡献了几次提交，其中有一部分是windows端的，就发现 AI 对网页可以自动截图、操作元素，但对 Windows 窗口就不太行（当时不太行，后面马上就有 AI Agent 支持了）。理想状态是让 AI 通过 MCP 工具直接理解系统窗口、浏览器的渲染状态，不依赖截图——让 AI 掌控整个测试链路的感知和操作，人只做最终抽查验收。

同样的困境换个形式出现。测试用例过度冗余——一个表单 100 个字段，AI 硬是生成 400 条用例，逻辑没毛病但根本测不过来。UI 不一致也没解决——AI 看不到页面，生成的界面和预期差很远。我们搭 Harness 干什么？标准化流程，降低门槛，让团队能协作——和我当初把强大的基础架构功能简化成 CLI 入口的理由一模一样。

第三条，布道师和教练，同一个角色。

推云原生必须有 Cloud Native、DevOps 布道师——懂技术、懂业务、能讲课、能答疑。锅总自称"AI 教练”，试点阶段全程参与但不介入具体开发，试点完了建三套培训体系，持续做、一直做。同一个角色：“选试点、带人上手、沉淀最佳实践、解决’我知道概念但不知道怎么落地’"。我当年推云原生就是每月一次技术分享，每次找一个落地案例。

变的是技术栈，不变的是把一群人从"我不懂"带到"我试试"再带到"我用得很顺手”。

第四条，全链路思维可以平移。

云原生讲究全链路——监控、追踪、压测。服务网格，Sidecar 拦截流量、控制面下发策略，本质上都是在完整链路上做文章。现在我用 Harness 组织多 Agent 做全链路 RCA——把全链路的上下文塞给 AI，让它自己沿链路找根因。能做这件事不是因为我对 AI 有多熟，是云原生年代我就习惯这么想问题了。

其实当年就有 AIOps 的概念，理念完全正确，只是 AI 不够强。现在大模型能力够了，同一批人，同一个思路，换了更强的引擎。全链路不只是技术概念，也是组织概念——锅总的 5 人 FDE 小组端到端交付，和云原生的跨职能全栈小队如出一辙。

存量适配。 我在 腾讯音乐 做服务网格，不是从零搭建，是在已有发布系统、权限模型、网络策略上长出一层，还要适配内部专有协议。不能推倒重来，只能在老房子上加固，有时其实比从0开始更难。锅总的棕地项目试点就是 AI 转型版的存量适配——历史代码、历史数据、老文档对不上，你不是在白纸上画图。

第五条，持续演进，不是一次性项目。

我那篇《荔枝微课基础架构的演进与实践》³，标题里就有"演进"两个字。架构不是搞完一次就收工。锅总的 Harness 每天都在修——今天变更管理没覆盖到，明天测试用例太慢，后天换了模型 Prompt 不工作。不是 Harness 没搭好而是必须随场景演进。

云原生教会我的不是某个工具，而是"体系随场景演进"这个习惯。带着它进入 AI 时代，你不会被模型版本更新吓到，因为你早就习惯变化了。

摒弃什么：旧车架撑不住新引擎

借鉴的清单不短。但有些东西硬搬到 AI 时代，会变成坑。

云原生是确定性系统。K8s 声明 3 个副本就保证 3 个在跑——声明式配置、不可变基础设施、自动化回滚，全部基于"目标精确可知"这个前提。控制循环持续调和期望与实际，趋近的是可精确测量的目标。

AI 是概率性系统。同一套 skill 在不同模型上表现天差地别，Prompt 改几个字结果面目全非。你无法声明"这个 prompt 的幻觉率 ≤ 1%“并靠一个控制循环保证它。

但控制循环的思路可以平移。eval loop 就是 AI 版的控制循环：观察输出、对比期望、修正偏差。能借鉴的是这个循环模式。

不能硬套的是测量精度。K8s 调和的是副本数、CPU、延迟——可精确计数的量。AI 调和的是代码质量、幻觉率、功能遗漏——边界模糊、不可精确计数的量。如果你用 K8s 的精确 SLO 标准去管 AI 产出，你会疯的。并非思路错了，而是尺子不对。

具体几条，都是我以前推云原生时觉得天经地义、到了 AI 时代发现必须扔掉的：

不可变基础设施 → 持续迭代。 云原生讲究"一次构建，到处运行”。AI 系统里 Prompt 在持续优化，模型版本在切换，工具链每天都在修。锅总一开始"先写 PRD 再画原型”，实操发现根本行不通，只能反过来加需求澄清。我在我的多智能体项目里调 Agent 时完全一样：今天能跑的 Prompt 可能明天换了模型就不工作，你没法一次设计到位，只能在运行中持续改。这和存量适配是一个道理——不是放弃治理，而是把治理从"锁定"变成"持续调"。

可观测三支柱 → AI 原生评估。 Metrics、Logs、Traces 能告诉你延迟涨没涨、错误飙没飙，但不能告诉你 AI 生成代码质量有没有下降、幻觉率有没有上升。锅总的数据：bug 率提高了约 60%，但 bug 类型完全翻转——以前占大头的是逻辑错误和体验问题，现在占大头的是功能遗漏和 UI 不一致。传统监控根本看不到这些。

测试金字塔 → 要重画。 传统三层是为"人的 bug"设计的。锅总试了 TDD、Mock、集成、E2E、文档测试全上，质量还是不如预期。AI 的专属 bug——功能遗漏、细节对不上——在规格文档里明明写了，代码出来要么漏了要么跑偏。传统测试逮不住这种。

SLO 定义 → 要变。 云原生用延迟百分位、可用性几个九，精确。AI 质量边界是模糊的——“重要和核心的 bug 其实很少，一般性问题特别多”。你不能用"零 P0"这种目标管 AI 产出，得重新定义什么叫可接受的质量。

把这些列在一起看，本质是同一个转变：别试图把概率性系统塞进确定性框架里。 那不是提效，是给自己找罪受。

转向哪里：还没修完的路

还有些问题，锅总没解决，我也没解决，行业里没人有完整答案。Harness 搭好了流程，但在流程的每个节点——评估标准定在哪、SLO 怎么设、多人协作下变更怎么管——工程平台能执行，不能替你决策。方向可以说，也是我每天都在尝试的东西：

• 确定性编排 → 拥抱概率性。 用 eval loop 代替控制循环，接受"够好"而不是"精确"。换模型 Prompt 不工作就得重新调试，这不是 bug，而是新常态。
• 三支柱 → AI 原生评估。 建 eval dataset、做 prompt regression test、分层抽查。重点盯功能遗漏和 UI 不一致——这些 AI 专属 bug 传统测试逮不住。
• 不可变基础设施 → 持续迭代治理。 Prompt 版本管理，模型切换策略。专门设人做模型适配——这个角色云原生时代没有，AI 时代必须有。
• 传统 SLO → AI 质量 SLO。 定义幻觉率、功能遗漏率、UI 偏差度。有模糊指标比没有指标强一万倍。
• 开发自测 → AI 测 AI + 人工抽查。 代码生成太快，只靠人盯不过来。让 AI 掌控测试闭环，人只做最终质量判断。
• 代码 review → 规格 review。 AI 生成代码太快，代码层面查不过来。但文档层面严格把关：feature 规格、接口设计、DB schema。因为 AI 的 bug 主要是"漏了该做的"和"做了不该做的"，不是"写得不对"。

回过头看，我当年在荔枝微课造了一辆云原生牌的新车——K8s 是底盘，自研平台是驾驶舱，服务网格是悬挂。现在搞 AI Native，我在造另一辆：Agent 编排是底盘，大模型是引擎，MCP Tool 是手脚，质量评估是仪表盘加刹车。

两次造车，同一个人。工具变了，问的问题没变：这辆车能不能跑起来？路修到哪了？客人什么时候上车？

锅总的十一步，我基本都走过，只不过那年走的是云原生的版本。现在再走一遍 AI 的版本——这次不再是给马车装发动机，而是造一辆新车。

参考资料