API7.ai创始人温铭：烧了几百亿Token，我用AI重写了生产级网关，总结出6条经验

InfoQ 中文 2026-06-26T15:19:06.403096

API7.ai创始人温铭：烧了几百亿Token，我用AI重写了生产级网关，总结出6条经验

温铭（API7.ai创始人兼CEO，Apache APISIX PMC主席）在Apache APISIX项目上亲历了AI Agent十分钟定位棘手Bug的震撼，随后用AI重写了生产级网关，烧掉数百亿Token。他总结出6条核心经验：AI编码能力已超越资深工程师，但真正的瓶颈在人；人类必须主导Why，掌握决策节奏，同时重塑组织对AI的信任与协作方式。

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

2026年春节，我在Apache APISIX上遇到一个极其棘手的Bug：多次尝试复现无果，几轮代码评审也未能定位。最后，我将现象描述给一个AI Agent，它仅凭静态代码分析与现象描述，不到10分钟便精准指出了问题所在。那一刻，我真正感受到了质变。

随后，我尝试了一个更大胆的实验：用AI复刻类似Apache APISIX的生产级项目。结果发现，虽然AI无法在半天内完整复刻架构、代码、测试与文档，但只要你清晰阐述架构、技术栈以及核心概念之间的关系，仅“写代码”这一环节，AI半天就能完成我们当年三个月的代码量。

因此，我的判断很明确：AI已经达到甚至超过资深工程师的编码能力，这一点毋庸置疑。

但这并不意味着人可以放手。一个资深工程师的真正价值在于他踩过的坑、做过的技术权衡与判断——这些隐藏在成品背后的“Why”，从未被良好记录在公开知识库中。Apache APISIX是一个成品，但中间的思考过程、概念抽象与架构设计，AI无法看到。它能看懂What（是什么），能完成How（怎么做），但在Why（为什么）的判断与抉择上，与资深工程师仍存在明显偏差。AI接管的是打字，没有接管我脑子里的那张图。

我在公司“禁止手写代码”，最大阻力是“领地意识”

我做出了一个颇具争议的决定：尽量不手写代码，将“打字”交给AI Agent。反弹最强烈的，是那些将自己定位得特别清晰的工程师——“我是前端”“我是后端”。一旦把自己框死，AI Agent这种易于打破边界的工具反而令人不适。

以我自身为例：过去若要做前端页面，需精通前端技术、审美、性能、SEO及各种框架。如今，像我这样基本没写过前端的人，也能做出不错的Dashboard——靠的不是手艺，而是能否说清评判标准：配色色系、CDN加载、移动端适配。把这些讲清楚，就能得到六七十分的页面。

这对产品定义与迭代带来了全新视角。过去，一个用户需求需产品经理、架构师、前端、后端等多角色协作交付；现在，做解决方案甚至销售的同事，直接用AI Agent在产品中修改、模拟，半小时内即可给用户演示“是不是你要的”。闭环周期从几周缩短到半小时以内。

因此，觉得这个决定“疯了”“不负责任”的人，往往是自身领域意识过强，或从未真正深度使用AI的人。当你深度用过，且没有太强的“领地意识”，你会发现AI是极好的工具。当然，公司内部并非所有人都同意。我给的建议是：你可以不同意，但请用最好的大模型大胆尝试——这样你才会知道它的边界在哪里。

而反弹最厉害的反而是最资深的工程师：他们坚信vibe coding（凭感觉编码）做出来的只能是玩具。

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

“哪些代码能交给AI，哪些不能？”我认为这个问题本身就问偏了。核心标准不是区分代码类型，而是指挥AI的人对架构、代码、测试是否有清晰理解，对推送至生产是否有敬畏之心。没有一个对技术、对代码有追求的人，即使是CRUD（增删改查）也能用AI写好；反之，即便再基础的代码，缺乏判断力的人也无法靠AI做出高质量结果。

为什么人必须参与？因为即使AI决策正确率达85%甚至90%，剩下那10%的错误足以使项目质量大幅下降。人必须参与决策，我给自己定的原则是：这个决定如果你看不懂，就一定别做。

以我们新写的AI网关“AISIX”为例，该项目重度使用Claude Code进行编码，但核心概念设计、架构选择、里程碑推进、技术选型权衡等一概不交给AI。在这个项目中，AI是辅助。如何约束它？需要让它做端到端测试、Dashboard核心路径的点击测试，并撰写完善文档。AI始终是工具，在不同人手里产出截然不同的东西。

AI写的代码，必须用另一个AI审核

人工审查AI代码是不可行的。AI编码一天能提交几十个PR、数千行代码，人根本看不过来，只能依赖流程。我们的做法是：用Claude Code编写代码后，它冷启动一个完全独立的AI Agent来审计这个PR——相当于用Claude Code写、再用Claude Code review；同时叠加CodeRabbit和GitHub Copilot做第二层。AI写出的代码，至少要换一个不同的AI去review。

但比“如何审查”更底层的是另一个问题：让项目稳定下来的从来不是代码写得多漂亮、架构多牛，而是大量用户在生产环境中暴露问题，你不断迭代改进。有人用，项目才会变好。AI最革命性的地方，就是将迭代速度拉到了极致。一个具体场景：凌晨两点用户提交Bug，AI初步分析判断问题所属产品，结合版本号、场景与错误日志做静态分析——超过一半的问题这一步即可准确定位。若无法定位，自动拉起复现环境，运行真实端到端测试，变着方法复现。定位完成后，再启动独立Agent与独立环境，重新复现并做一次double check。

人做什么？不断优化这套自动化流程：改进提示词、更换模型、打磨复现场景，将自己经验沉淀进去。最终拍板仍是人来做。凌晨两点，AI已将代码分析、环境搭建、问题大致位置备好——过去半小时至一小时的活，它十分钟完成，人只需做最后判断。

因此，一家公司人多或人少并不重要，更重要的是：它得先变厚，再变大。

掌握节奏：从“上瘾式编码”转向“高质量决策”

用AI写软件，我大致经历了三个阶段。

第一阶段：堆框架。 使用各种harness（如ECC、Oh My OpenCode等技能与提示词集合）搭建软件工程。它能帮你找到盲点，并行推进任务，感觉像在指挥一个团队。

第二阶段：扔掉框架。 你开始不愿用这么重的框架，更想控制权抓回自己手里。原因很简单：大模型已足够聪明，你只需告诉它“做一个端到端测试”“优化这个页面”，它自己就能搜索、理解并很好完成，无需外部框架。此时你能给它的真正价值，是把一二十年踩坑经验沉淀成一个100行左右的agents.md或CLAUDE.md——一个偏原则、偏经验的小文件，每次干活加载进去。这意味着你扔掉别人喂给你的经验，留下的是你自己的。

第三阶段：从“上瘾式编码”转向“高质量决策”。 到达第二阶段后你会发现，需要你做的决策实在太多：以前一天两三个技术决策，如今一天要做四五十个。人的精力根本扛不住。“上瘾式编码”的表现：睡前给AI一个大任务让它通宵运行，在公司不停与AI迭代，回家每十几二十分钟还要决策一次，睡前再盘一个大任务，晚上睡不好，一大早爬起来看进度。看着勤奋，效果却一路下滑。

现在的节奏是：并行五六个研发任务，需要判断时先搞清楚决策背后的逻辑，再与AI一起迭代。重要决策、架构选择由人主导；机器负责调研、补背景、补盲区、扩视野，最终由人拍板后机器执行编码。并行五六个任务，一天约需四五十个高质量决策。从早上七八点到下午三四点，人精力基本耗尽。因此我尽量将高质量决策压在上午至下午三四点完成，剩余时间通过看书、运动恢复精力；晚上和周末尽量不碰AI，否则决策质量撑不住，只会陷入无休止的迭代，届时对软件质量已无帮助。

关键要点

摘要：几百亿Token的消耗并非关键，真正重要的是工程师的经验是否沉淀为可复用的决策知识，以及能否高效地做出高质量决策。面对AI大潮，企业不应吝啬Token的使用，而应警惕“省着用”的心态——只有勇敢踩下油门，才能推动组织跟上AI能力溢出的时代。

关于Token的真相：能力溢出，人才是短板

常说烧了几百亿Token，但烧1亿还是100亿并不是决定性因素。关键在于两件事：你的经验有没有沉淀进那份设计文档（.md文件），以及你的高质量决策能不能高效地做出来。再说一遍：AI的能力是溢出的，跟不上的是人。

一个值得深思的账目：同样模型、同样提示词，不同的人来选，结果天差地别。就像1.1的100次方远大于1.01的100次方，差距巨大。一位有经验的工程师，能把AI决策的正确率从80%抬到85%；没经验的可能一直停在80%。一天几十个决策这么复利下去，最终产出的软件质量判若云泥。

为什么我们又重写了一个网关

两年前，AI流量已经出现，只是量还不大。我们最初的想法是在Apache APISIX里用插件去代理这股新流量——毕竟看上去都一样：限流限速、负载均衡、fallback、健康检查、身份认证。AI流量和API流量本质上不是一回事吗？

做着做着就发现，它们表面相似，核心概念却截然不同。API网关的核心概念是路由、Service、Consumer、插件；而AI流量的核心概念是LLM Provider、虚拟API Key。当你要加上只有AI场景才有的能力——比如模型合议（让多个大模型各出一份结果，再汇总成一个判断）、语义路由——硬套进API网关就很别扭。不是不能做，是不自然。

于是我们干脆按AI网关原生的概念，从头做了一个新的开源的AI网关，叫AISIX。简单说，它把各家大模型统一在一个API后面，将Token计量、成本控制、多模型负载均衡和fallback、Prompt层面的安全、以及流量的可观测性，都纳入网关本身。到这时候你才会觉得，整个流量的处理是通畅的。它和API网关有不少功能重叠，但面向的人群、核心诉求和概念都不一样。

底层选择：为什么用Rust而非Lua

还有一个更底层的选择：AISIX我们是从零用Rust写的，没有沿用APISIX那套OpenResty/Lua。原因很实在——AI流量大量是长连接的流式输出，一个请求可能挂着很久，还特别吃并发。这种场景下，你需要一个没有GC停顿、单请求开销足够低、延迟可预测的运行时。Rust在这件事上，比我们过去那套更合适。

痛点来源：不是自己，而是客户的账单

这一点可能和直觉相反：这个痛点，最初并不来自我们自己。我买的是Claude Code的套餐（Max 20），Token大体够用；但和很多大公司的研发一聊发现，他们不是走套餐，而是接AWS Bedrock、Google Vertex的API按Token计费。同样的事，我一个月可能花200美金，他们一家公司可能要花2000美金甚至更多。钱花在了谁头上、安全怎么保证，是他们实打实的痛点。这跟当年做Apache APISIX一样：人在行业里，但产品要解决的痛点不只来自自己，而来自对一大批公司的观察和洞察。

最后

回到开头那个判断：AI的能力早就溢出了，跟不上的是人。

所以现阶段，一家公司最该警惕的，反而是“省着用Token”的心态——我认为这是早晚要出大事的。你要在公司里大力推行AI、改造组织、快速推进产品、让每个人都去体验AI的各种可能，就不能让AI的成本和安全，变成挡在前面的那道墙。这才是最核心的。

油门得敢踩。剩下的，是怎么让人和组织跟得上。

关键要点

查看原文