烧了几百亿 Token 用 AI 重写生产级网关：温铭的 6 条经验

文章正文

背景:为什么用 AI 重写生产级网关

温铭(API7.ai 创始人兼 CEO,Apache APISIX PMC 主席)用 AI 写软件这件事,真正的转折点是 2026 年春节——团队在 Apache APISIX 上遇到一个复现不出来的棘手 bug,抱着试一试的心态把现象描述丢给 AI Agent,它在 10 分钟内只靠静态代码分析就精确定位了问题。"那一刻,真的把我惊艳到了。"

之后他做了一个更大胆的尝试:让 AI 复刻 Apache APISIX 这样的生产级项目。结论是——如果只让 AI 照着成品抄,它做不到;但只要你把架构、技术栈、核心概念和它们之间的关系讲清楚,AI 半天写出的代码量等于人类三个月。两个月里他自己就烧了几百亿 Token,得到的判断是:瓶颈早就不在 AI 这一头,真正跟不上的是人。

这个背景是理解后面 6 条经验的前提——这不是一篇"AI 能写代码"的赞叹文,而是一篇"组织和人怎么配得上 AI"的反思文。

几百亿 Token 烧出了什么

烧 token 的具体规模不重要(1 亿还是 100 亿不是关键),重要的是烧出来的东西:

• 新项目 AISIX:完全用 Rust 从零写的 AI 网关,而不是在 APISIX 上加插件(后面单独讲为什么)
• 重写规模:Claude Code 重度参与的完整生产级网关代码,包括架构、代码、测试、文档
• 组织改造:公司内部"尽量不手写代码"成为默认工作方式
• 经验沉淀:踩坑经验被压缩成 100 行左右的 agents.md / CLAUDE.md,让 AI 每次开工都加载
• 流程模板:AI 写 + 独立 AI 冷启动 review + CodeRabbit / GitHub Copilot 第二层,变成默认 PR 流程

6 条经验逐条拆解

1. AI 看得到 What、能完成 How,但 Why 还得人自己来

• 真实含义:AI 能看懂"是什么"(What)、能照着做"怎么做"(How),但为什么这样设计(Why)——概念抽象、架构权衡、踩坑经验——AI 看不到,因为这些东西从来没被写进任何公开知识库。温铭的原话是:"它接管的是打字,没接管我脑子里的那张图。"
• 踩过的坑:让 AI 复刻 APISIX 时,如果只给成品,AI 做不出来;但只要把概念之间的关系讲清楚,AI 半天能写人类三个月的代码量。这说明 AI 的瓶颈不在执行,在"人能不能把判断说清楚"。
• 前端工程类比:完全适用,而且可能更痛。前端工程的"为什么"特别多——为什么用 RSC 而不是 SPA、为什么用 Vite 而不是 Webpack、为什么状态放 URL 而不是 Redux、为什么这个组件要 memo 那个不要。这些判断散落在 issue、Slack 回顾、PR 评论里,从来没沉淀成结构化知识。如果让 LLM 改写 React 组件,你怎么向它讲清楚"这个 prop 不该内联,因为它在 render 里创建新引用"——这就是 Why。

2. 我在公司"禁止手写代码",反弹最大的是"领地意识"

• 真实含义:温铭在公司推动"尽量不手写代码,把打字交给 AI Agent"。反弹最厉害的不是新人,而是把自己定位得很死的资深工程师("我是前端"、"我是后端")——领地意识越强,越抗拒 AI 跨界。
• 踩过的坑:他举了自己的例子——以前做 Dashboard 要懂前端技术、审美、性能、SEO、各种框架,现在他这种"基本没写过前端的人"也能做出 70 分的页面,关键是能不能说出"评判标准":配色走什么色系、资源走 CDN、考虑移动端适配。
• 前端工程类比:高度适用,而且反向适用。前端本来就是最容易被 AI 跨界的工种——产品经理、销售、设计师都能用 AI 写一个 mock 页面。Rainsho 视角下,这意味着前端工程师的价值要主动从"我写得出来"转向"我判断得了写得好不好"——配色、可访问性、性能预算、状态正确性,这些判据才是护城河。

3. 是玩具还是生产级,这条线画在人身上,不在代码上

• 真实含义:经常有人问"哪些代码能交给 AI、哪些不能",温铭认为问题本身就问偏了。真正的标准是指挥 AI 的人——他对架构、代码、测试有没有清晰理解?对把东西推上生产有没有敬畏之心?没有追求的人,哪怕写 CRUD 也用不好 AI。
• 踩过的坑:他给 AI 设了一条铁律——"这个决定你要是看不懂,那就一定别做"。哪怕 AI 决策正确率有 85%–90%,剩下那 10% 也足以让整个项目质量大幅下降。AISIX 项目里,核心概念设计、架构选择、里程碑推进、技术选型权衡"一概不交给 AI",AI 只做辅助。
• 前端工程类比:非常适用,且需要警惕。前端工程里"看上去能跑"的代码最多——UI 长得对、交互能点、构建过了、Lighthouse 80 分。但生产级的判据远不止这些:SSR hydration 一致性、错误边界、可观测性、A/B 灰度、回滚能力。"看不懂就别上"这条铁律,在前端要变成"在慢网、3G 设备、视障用户、有干扰的 JS 环境下,行为是否可预测"。

4. AI 写的代码,得再用一个 AI 去 review

• 真实含义:靠人 review 是不行的——AI coding 一天能提几十个 PR、几千行代码,人根本看不过来。温铭的做法是三层审计:用 Claude Code 写 → 冷启动一个全新独立的 AI Agent review(防止同一个 AI 自我背书)→ CodeRabbit + GitHub Copilot 做第二层。
• 踩过的坑:比"怎么审"更底层的是另一件事——让项目稳定下来的不是代码漂亮、架构牛,而是真有大量用户在生产环境用,暴露问题,你不停迭代。AI 最革命性的地方是把迭代速度拉到极致:任何反馈、任何 bug 都能快速定位、快速修复。具体场景:用户凌晨两点提 bug,AI 先做静态分析(>50% 的问题在这一步定位),定不下来就拉复现环境跑端到端测试,定位到后再起一个独立 Agent + 独立环境做 double check。
• 前端工程类比:完全适用,且已有成熟模式可抄。前端天然适合这套——Storybook 跑视觉回归、Playwright 跑 E2E、Chromatic 做 UI 截图 diff。Rainsho 视角下,这套机制可以无缝平移:Claude Code 写组件 → 独立 Agent review(查 a11y、查 props 接口、查 memo 是否合理)→ E2E + 视觉回归作为"第二层"。

5. 我现在每天要做四五十个决策

• 真实含义:用 AI 写软件,温铭经历了三个阶段:
  • 第一阶段:堆框架——用 ECC、Oh My OpenCode 这类 harness 和提示词集合搭软件工程,感觉像在指挥一个团队。
  • 第二阶段:把框架扔掉——大模型已经足够聪明,只要告诉它"做一个端到端测试",它自己能搜索、理解、做得很好。真正的价值是把一二十年踩过的坑沉淀成 100 行左右的 agents.md / CLAUDE.md——你扔掉的是别人喂给你的经验,留下的是你自己的。
  • 第三阶段:从"上瘾式编码"转向"高质量决策"——以前一天两三个技术决策,加速键一按变成四五十个,人根本扛不住。
• 踩过的坑:他讲了一段"上瘾期"的真实状态——睡前给 AI 派大任务让它整夜跑,在公司不停迭代,回家每隔一二十分钟还要决策一次,睡前再盘任务,晚上睡不踏实,一大早爬起来看进度。看着很勤奋,效果其实一路在掉。现在的节奏是:并行五六个研发任务,需要判断时先把决策背后的逻辑搞清楚,再和 AI 一起迭代;重要的决策、架构的选择都由人来做,机器负责调研、补背景、补盲区、扩视野,最后所有判断由人拍板,机器去执行和编码。
• 关键数据:从早上七八点到下午三四点,人的精力基本就耗尽。高质量决策要压在这个窗口里做完,晚上和周末尽量不碰 AI,否则会陷进没完没了的迭代里,反过来拖垮决策质量。
• 前端工程类比:高度适用,且 Rainsho 可能正在经历"上瘾期"。前端工程里 AI 加速尤其明显(组件生成、样式调整、测试用例),但决策密度会爆炸——一个 PR 里要不要加 error boundary、用不用 memo、a11y 要不要做到 AA、要不要支持 SSR——每一项都是判断,以前靠"不写就不决策"回避,现在 AI 提了方案逼你表态。

6. 为什么我们又重写了一个网关(AISIX,以及"省着用 token"的心态)

• 真实含义(藏在最后,不是单独的"经验",但是文章的收束):两家公司的核心判断从来不是"AI 多强",而是"什么样的产品形态才配得上 AI 时代的流量"。两年前 AI 流量出现,温铭团队最初想在 APISIX 里加插件代理(限流、负载均衡、fallback、健康检查、认证),但做着做着发现:API 网关的核心概念是路由、Service、Consumer、插件;AI 流量的核心概念是 LLM Provider、虚拟 API Key——强行套进 API 网关"不是不能做,是不自然"。于是从头用 Rust 做了 AISIX,把 token 计量、成本控制、多模型负载均衡、prompt 安全、可观测都放进网关本身。
• 选 Rust 的真正原因:AI 流量大量是长连接流式输出,一个请求可能挂很久,还特别吃并发——需要没有 GC 停顿、单请求开销足够低、延迟可预测的运行时。Rust 比 OpenResty/Lua 更合适。
• 痛点的来源:这个痛点最初不来自 API7 内部,来自对一批大公司的观察——他们接的是 AWS Bedrock / Google Vertex 按 token 计费,一家公司一个月可能花 2000+ 美金,钱花在了谁头上、安全怎么保证才是他们的真痛点。
• 最后的警告:AI 的能力早就溢出了,跟不上的是人。现在最该警惕的是"省着用 token"的心态——这早晚要出大事。你不能让 AI 的成本和安全变成挡在前面的那道墙。油门得敢踩,剩下要解决的是怎么让人和组织跟得上。
• 前端工程类比:这是整篇文章最值得 Rainsho 咀嚼的部分。"别在旧架构上打补丁,该重写就重写"——前端工程里,当一个新的运行时(Edge)、新的渲染范式(RSC)、新的构建范式(Vite/Rspack)出现时,老项目应该加插件,还是新写一个项目?温铭的判据是:核心概念变了,就不该打补丁——这同样适用于前端判断。

AI 写网关代码 vs 人类写网关代码

温铭没提但值得思考的潜在风险

1. 幻觉代码的传染性:AI 生成的代码会"看起来对"——变量名规范、风格统一、跑通测试。但若 AI 引入了一个假想的标准库函数、一个不存在的 API,人是很难一眼识别的。网关代码尤其危险——一次错误的路由匹配、一次 off-by-one 的限流计算,会在生产环境放大成大事故。
2. 回归测试覆盖率的"假阳性繁荣":AI 可以一天生成几千行测试,但测试覆盖了不等于测试正确。如果测试本身就是 AI 写的,等于"AI 用自己的理解去验证自己的实现"——验证了 What,完全没验证 Why。温铭的"独立 Agent + 独立环境 double check"是补救,但人类需要守住一份"关键路径测试清单"。
3. 回滚成本被低估:AI coding 一天提几十个 PR,意味着 git log 里 70% 是 AI 写的。事故发生时,回滚到哪个版本?Rainsho 视角下,前端工程里这种问题已经被体验过——一个 PR 看似只改了一个 prop,实际触发了 React 19 的某个 hydration bug,但 git log 里这种 PR 太多,定位极慢。建议给 AI 写的 commit 强制加前缀(如 ai:),便于事后追溯。
4. agents.md / CLAUDE.md 本身会成为新的"祖传代码":温铭说经验沉淀到 100 行的小文件里,但 100 行不是天花板——一年后这个文件可能变成 800 行,谁也不敢删,谁也不敢改,变成"组织里最神圣也最不可读的文档"。需要给这个文件也配一个 review 流程,且每条经验必须配"曾经踩过的具体事故"做引用,否则会变成口号。
5. "组织先变厚再变大"会被误读为"先加人再加人":温铭说"一家公司人多还是人少不重要,重要的是先变厚再变大"——这话很容易被简化成"先招一波人再扩张"。其实他指的是能力的厚度(判断密度、经验沉淀),不是人头。但招聘市场会怎么解读,完全不可控。
6. 个人精力的"下午三点天花板"是组织性风险:温铭承认自己一天只能做四五十个决策、下午三点后就废了——这意味着整个公司的关键决策被串行化到一个高管的个人精力上。如果温铭不在,谁来拍板?组织有没有"第二个能拍板的人"?

Rainsho 视角

这 6 条经验里,最普适的是第 1、3、4、5 条(Why 在人、AI 写必须用 AI review、决策密度爆炸),可以原封不动平移到前端 LLM 改写组件、构建工具生成的场景;最值得警惕的是第 2 条(领地意识反弹)——前端工程师是第一批被"AI 跨界"冲击的群体,反作用力会比后端更早、更猛;最容易被忽略的是第 6 条背后的"别在旧架构上打补丁"——前端工程的 RSC、Edge Runtime、Server Components 出现时,多少团队还在用"加一个 webpack plugin 解决"的心态在硬撑?温铭没说出口但隐含的判断是:核心概念变了,就该重写,不该打补丁。最后,他的"省着用 token"警告在企业内部会被严重误读——它不是成本建议,是组织变革的号角:不敢放开用 AI 的团队,会输给敢放开用的团队,但敢放开用而人跟不上的团队,会输得更惨。这道题没有银弹,只有节奏。