# 从云原生转型到AI转型，什么值得借鉴？什么需要摒弃？ 1895 年，Panhard & Levassor 造出第一批量产汽车[^1]。不是在工厂从零设计的——他们把 Daimler 内燃机绑在传统马车的木头底盘下面。驭手座位还在，铁包木轮没换，只是马没了。同期 De Dion-Bouton 的"蒸汽马"也是一样的思路：发动机替代马，马车架原封不动。 {{< image src="car1.jpg" alt="1895年 Tunbridge Wells 无马马车展，Daimler 发动机装在马车上" caption="1895 年 Tunbridge Wells 无马马车展。Daimler 内燃机绑在木头马车架下面——最早的汽车不是新车，是旧车换了个新引擎。" width="700px" linked=false >}} 那画面不是笑话——那辆车真的跑起来了，而且跑出了汽车工业的第一步。但它也跑不远：木头车架扛不住内燃机振动，铁包木轮在今天的柏油路上会打滑，转向系统是为马设计的没有所谓的方向盘。当时那辆车除了没马很多方面还不如马车（高昂的价格、难以驾驭、跑得慢），真正的汽车是后来才出现的——钢制底盘、橡胶轮胎、方向盘——从零为发动机设计的车。 转型的隐喻不在"往马车上装发动机"，而在那之后发生了什么。 **旧马车**是你现有的研发体系——流程、工具链、组织分工，全部为"人写代码"设计的。**发动机**是 AI 能力——大模型、Agent、自动化决策。往马车上装发动机能跑一阵子，Panhard & Levassor 的马车就跑了——但木头车架扛不住长期振动，转向系统是给马设计的。你的老流程也一样：硬塞 AI 进去，初期有点效果，但评审机制、测试体系、SLO 定义全是给"人写代码"设计的，撑不久。 我们得先**造辆新车**——建一个从零设计的 AI Native 试点，用新流程、新工具、新角色。跑通了，再把客人和货物一批批拉过去。同时**修路**——算力、电力、工具链。路不通，再好的车也跑不起来。 我搞云原生转型时，从荔枝微课（即十方融海）到腾讯音乐，推过云原生、Devops等，也推过服务网格乃至扩展，和这画面一模一样。现在推 AI 转型，还是这画面。 --- ## 借鉴什么 最近看了锅总一篇讲 AI 组织转型的文章[^2]，他把传统研发团队一步步改成 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 转型版的存量适配——历史代码、历史数据、老文档对不上，你不是在白纸上画图。 **第五条，持续演进，不是一次性项目。** 我那篇《荔枝微课基础架构的演进与实践》[^3]，标题里就有"演进"两个字。架构不是搞完一次就收工。锅总的 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 的版本——这次不再是给马车装发动机，而是造一辆新车。 --- **参考资料** [^1]: 1895 年 Tunbridge Wells 无马马车展——[Grace's Guide](https://www.gracesguide.co.uk/1895_Horseless_Carriage_Exhibition)；Panhard & Levassor 历史——[Wikipedia](https://en.wikipedia.org/wiki/Panhard) [^2]: 硅基锅总[《组织转型实录——我把传统研发团队改成AI驱动，踩了无数坑》](https://mp.weixin.qq.com/s/xeC7hnkbdvC0uNOK2SutfA) [^3]: whitefirer [《荔枝微课基础架构的演进与实践》](https://whitefirer.org/posts/2020/09/11/the-evolution-and-practice-of-tenclass-infrastructure/)