作者 | 温铭 (API7.ai 创始人兼 CEO,Apache APISIX PMC 主席)
我第一次真切感觉到变化, 是 2026 年春节。
那段时间, 我们在 Apache APISIX 上遇到一个非常棘手的 bug: 试了很多方法都没能复现, 读了几轮代码也没定位到。最后抱着最后一丝希望, 我们把这个 bug 的现象描述给了一个 AI Agent——它用了不到 10 分钟, 只靠静态代码分析加上我们描述的现象, 就准确地指出了问题在哪里。
那一刻, 真的把我惊艳到了。
后来我们又试了件更大胆的事: 既然这么强, 它能不能做一个像 Apache APISIX 这样的生产级项目? 要说半天就从架构、代码、测试到文档完整复刻, 它做不到 ; 但只要你把架构、技术栈, 以及你脑子里那些核心概念和它们之间的关系讲清楚, 单论"写代码",AI 半天就能完成我们当年三个月的代码量, 完全没问题。
所以对于写代码这件事, 我的判断很明确:AI 已经达到、甚至超过了一个资深工程师的编码能力, 这一点毋庸置疑。
这一两个月, 光我自己用 AI 写软件, 就烧掉了几百亿 token。但烧得越多, 我越确定一件事——瓶颈早就不在 AI 这一头了:AI 的能力已经溢出, 真正跟不上的, 是人。 下面这几条, 是我自己烧出来的经验, 没有大道理, 都是踩出来的。
AI 看得到 What、能完成 How,但 Why 还得人自己来
既然 AI 写代码这么强, 一个资深工程师现在真正值钱的是什么?
我觉得, 是他这些年自己踩过的坑、做过的技术权衡和判断, 以及从这些判断里熬出来的经验。这些东西, 从来没有被很好地写进任何公开的知识库。
你去看 Apache APISIX, 看到的是一个成品 ; 但它中间的思考过程、概念抽象、架构设计, 这些背后的 why,AI 是看不到的。它能看懂 What、也能完成 How, 但在对 Why 的理解、判断和抉择上, 和资深工程师比还是有不小的偏差。
说白了, 它接管的是打字, 没接管我脑子里的那张图。
我在公司"禁止手写代码"，反弹最大的是"领地意识"
我在公司做过一个挺有争议的决定: 尽量不手写代码, 把"打字"这件事交给 AI Agent。
反弹最厉害的, 是那些把自己定位得特别清晰的工程师——“我是前端”,“我是后端”。一旦你把自己框死,AI Agent 这种很容易帮你打破边界的工具, 反而会让你不适应。
举个我自己的例子。以前做一个前端页面, 你得对前端技术、审美、性能、SEO、各种框架都熟, 才算一个像样的前端工程师。但现在, 像我这种基本没写过前端的人, 也能做出一个还不错的 Dashboard——靠的不是手艺, 是你能不能说出前端的评判标准: 配色大概走什么色系、资源要走 CDN 加载、得考虑移动端适配。把这些说清楚, 你就能做出一个六七十分的页面。
这对产品的定义和迭代来说, 是个很不一样的视角。过去一个用户需求, 要产品经理、架构师、前端、后端几个角色配合才能交付 ; 现在很常见的场景是, 用户描述完需求, 做解决方案、甚至做销售的同事, 就能直接用 AI Agent 在产品里改一改、模拟出来, 拿给用户看"是不是你要的"。这个闭环, 从过去的几周缩短到了半小时以内。
所以, 会觉得这个决定"疯了"“不负责任"的人, 往往是把自己框得太死、或者还没真正深度用过 AI 的人。当你深度用过、而且没有太强的"领地意识”, 你会发现它是个特别好的工具。
当然, 公司里不是所有人都同意我。我给他们的建议是: 你可以不同意, 但请用最好的大模型, 放手让它去做——这样你才知道它的边界在哪。
而反弹最厉害的, 其实是最资深的那批工程师: 他们认定,vibe coding 做出来的只能是玩具。
是玩具还是生产级，这条线画在人身上, 不在代码上
那到底是玩具, 还是能上生产的东西?
经常有人问我: 哪些代码能交给 AI, 哪些不能? 我觉得这个问题本身就问偏了。比起区分代码类型, 有一个更核心的标准——指挥 AI 的这个人, 对架构、代码、测试有没有清晰的理解? 对把东西推上生产, 有没有一颗敬畏之心?
没有一个对技术、对代码有追求的人, 哪怕是 CRUD, 他也没法用 AI 写好。
为什么人必须待在里面? 因为哪怕 AI 的决策正确率有 85%、90%, 剩下那 10% 也足以让整个项目的质量大幅下降。它不可能每个决定都对, 但人一定要参与到决策里。我给自己定了一条原则:这个决定你要是看不懂, 那就一定别做。
举个我们自己的例子。我们最近写了一个新项目——一个 AI 网关, 叫 AISIX, 里面重度使用了 Claude Code 来编码 ; 但核心概念的设计、架构的选择、里程碑的推进、技术选型的权衡, 这些一概不交给 AI。在这个项目里,AI 是辅助。
怎么约束它? 你得让它做端到端测试, 做 Dashboard 核心路径的点击测试, 写完善的文档。AI 始终是工具, 在不同人手里, 会做出完全不同的东西。
AI 写的代码, 得再用一个 AI 去 review
这件事靠人是不行的。AI coding 一天能提几十个 PR、几千行代码, 人根本看不过来, 只能靠流程。
我们的做法是: 用 Claude Code 写, 写完之后, 让它冷启动一个全新的、独立的 AI Agent 去审计这个 PR——等于用 Claude Code 写、再用 Claude Code review; 同时再用 CodeRabbit 和 GitHub Copilot 做第二层。AI 写出来的代码, 至少要换一个不同的 AI 去 review。
但比"怎么审"更底层的是另一件事: 让一个项目稳定下来的, 从来不是代码写得多漂亮、架构做得多牛, 而是真有大量用户在生产环境里用它、暴露问题, 然后你不停迭代、不停改进。有人用, 它才会越来越好。AI 最革命性的地方, 就是把这个迭代速度拉到了极致——任何反馈、任何 bug, 我都能很快定位、很快修复。
举个具体场景。用户凌晨两点提了个 bug: 先由一个 AI 做初步分析, 判断问题在哪个产品, 再结合版本号、场景、错误日志做静态分析——超过一半的问题, 在这一步就能准确定位。如果定不下来, 它会自动拉起一个复现环境, 把对应版本的代码和插件跑一遍真实的端到端测试, 变着法子去复现。
定位到了也不算完——这时还要再起一个独立的 Agent、独立的环境, 拿着上一轮的分析结果重新复现一遍, 做一次 double check。
那人做什么? 人去不断优化这套自动化流程: 改提示词、换模型、打磨复现场景, 把自己的经验沉淀进去。最终的拍板, 还是人来做。毕竟凌晨两点你脑子未必清醒, 而 AI 已经把代码分析、环境搭建、问题的大致位置都摆在你面前——过去要半小时一小时的活, 它十分钟就备好了, 人只做最后那个判断。
所以, 一家公司是人多还是人少, 我觉得不重要。更重要的是: 它得先变厚, 再变大。
我现在每天要做四五十个决策
用 AI 写软件, 我大致经历了三个阶段。
第一阶段, 堆框架。 用各种 harness——比如 ECC、Oh My OpenCode 这类 skill 集合和提示词集合——去搭一个软件工程。你会发现它能帮你找到盲点, 一大堆 Agent 并行地推进任务, 那感觉像在指挥一个团队。
第二阶段, 把框架扔掉。 你开始不愿意再用这么重的框架, 更想把控制权抓回自己手里。原因很简单: 大模型已经足够聪明, 你只要告诉它"做一个端到端测试"“优化这个页面”, 它自己就能搜索、理解、做得很好, 根本不需要那么重的外部框架。这时你能给它的真正价值, 是把自己一二十年踩过的坑, 沉淀成一个一百行左右的 agents.md 或 CLAUDE.md——一个偏原则、偏经验的小文件, 让它每次干活都加载进去。换句话说, 你扔掉的是别人喂给你的经验, 留下的是你自己的。
第三阶段, 从"上瘾式编码"转向"高质量决策"。 因为到了第二阶段你会发现, 需要你做的决策实在太多了: 以前一天两三个技术决策, 加速键一按, 一天要做四五十个。人的精力, 根本扛不住。
先说说"上瘾"是什么样。那阵子, 我追求的是睡前给它一个大任务、让它整夜跑 ; 在公司不停地和 AI 迭代、决策 ; 回到家每隔一二十分钟还要决策一次 ; 睡前再盘一个大任务 ; 晚上睡不踏实, 一大早爬起来第一件事是看进度。看着很勤奋, 效果其实一路在掉。
所以我现在的节奏是: 并行五六个研发任务, 需要我判断时, 先把决策背后的逻辑搞清楚, 再和 AI 一起迭代。重要的决策、架构的选择都由人来做 ; 机器负责帮我调研、补背景、补盲区、扩视野, 最后所有判断由人拍板, 机器去执行和编码。
并行五六个任务, 一天差不多四五十个高质量决策。从早上七八点到下午三四点, 人的精力基本就耗尽了。所以我现在尽量把高质量决策都压在上午到下午三四点之间做完, 剩下的时间靠看书、运动把精力养回来 ; 晚上和周末, 尽量不碰 AI。否则你的决策质量撑不住, 只会陷进没完没了的迭代里——而那时候, 你对软件质量已经没有更多帮助了, 因为你已经做不出好决策了。
至于开头说的那几百亿 token——烧 1 亿还是 100 亿, 真不是关键。关键是两件事: 你的经验有没有沉淀进那个 md 文件, 你的高质量决策能不能高效地做出来。再说一遍:AI 的能力是溢出的, 跟不上的是人。
最后补一笔我很信的账: 同样的模型、同样的提示词, 不同的人来选, 结果天差地别。就像 1.1 的 100 次方是个很大的数, 而 1.01 的 100 次方和 1.1 的 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 网关有不少功能重叠, 但面向的人群、核心诉求和概念, 都不一样。
还有一个更底层的选择: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 的成本和安全, 变成挡在前面的那道墙。这才是最核心的。
油门得敢踩。剩下要解决的, 是怎么让人和组织跟得上。
今日好文推荐
AI 设计9个月就能媲美Blackwell？OpenAI “辣芯”绕开英伟达正面战场，但老黄的GPU大盘不稳了
