开发实践

上周三下午,我同时开着四个东西:Cursor 里一个 agent 在改重构,终端里 Claude Code 在跑测试,GitHub 上一个 Copilot 后台 agent 在处理我早上随手丢过去的 issue,还有一个 Cursor 云端 automation 在等 CI 结果。我本人那段时间在干嘛?在看 Linear 上的工单,决定下一个派给谁。 我没写一行代码。但那个下午合并了五个 PR。 这不是什么"未来已来"的感慨。这是 2026 年 5 月一个普通工程师的普通下午。半年前——也就是 2025 年底——我的工作方式还不是这样。那时候 AI 编程工具的主流形态是"一个很聪明的补全",你在编辑器里写代码,它帮你接下一段。现在,补全这件事我几乎已经感觉不到它的存在了,因为我的注意力整个挪到了别处。 这半年到底发生了什么,值得拆开看看。 三级跳:补全 → 终端 agent → 后台 agent 如果要给 AI 编程工具这半年画一条线,它是这样三级跳的: flowchart LR A[代码补全2023-2024] --> B[IDE 内 agent2025] --> C[终端 agent2025 下半年] --> D[后台/云端 agent2026] style A fill:#e8e8e8,stroke:#999 style B fill:#fde7c2,stroke:#e8b23c style C fill:#fde7c2,stroke:#e8b23c style D fill:#c2e0fd,stroke:#3c8ce8 第一级是补全:Copilot 那套,光标后面灰字提示,你按 Tab 接受。这个形态决定了一件事——AI 是你的副驾驶,方向盘还在你手里,你得一直盯着路。 ...

一个用 AI 写代码的开发者,现在一天能开五六个 PR。 而审你 PR 的那个人,一天还是只能审五六个。 这两个数字凑在一起,就是 2026 年大多数工程团队真正的麻烦。Faros AI 的数据里,高 AI 使用率的团队完成的任务多了 21%、合并的 PR 多了将近一倍,但 PR 的 review 时长涨了 91%——而且那些 PR 还更大。Opsera 一份覆盖 25 万开发者的报告说得更直白:在没有治理的情况下,AI 生成的 PR 在 review 队列里等的时间是普通 PR 的 4.6 倍,哪怕从写完到提 PR 的时间砍掉了一半多。 写代码这件事,被 AI 解决了一大半。审代码这件事,一点没变。瓶颈就这么从「写」挪到了「审」,而且大多数团队还没意识到。 为什么 AI 写的代码,审起来反而更难 直觉上,AI 代码该更好审才对——它风格统一、不会忘加分号、命名规规矩矩。但真审过 AI 大批量产出的代码的人都知道,事情反过来了。AI 代码难审,难在三个地方。 第一,它看着太合理了。 人写错代码,常常会留下「破绽」——变量名词不达意、缩进乱、注释和代码对不上,这些视觉信号会让 reviewer 警觉。AI 不会。AI 写的错误代码,长得和正确代码一模一样:命名得体、结构清晰、注释贴心。CodeRabbit 的研究说 AI 写的代码暴露的问题比人写的多 1.7 倍,而这些问题里相当一部分是逻辑错误——业界一个被反复引用的说法是,AI 代码的纯逻辑错误率比人高约 75%。一个长得人模人样的函数,你的大脑会默认它没问题,于是真正的 bug 藏在「看着合理」的外壳里溜过去了。 第二,量。 一个 reviewer 以前一天面对的是三五个 PR、每个两三百行。现在是十几个 PR,而且单个更大。注意力是有总量的——审第一个 PR 时你逐行读,审到第八个时你已经在「扫」。Review 质量不是匀速下降的,是过了某个阈值之后断崖式塌掉的。量本身就是一种攻击。 ...

先说一个反常识的事:大多数团队的"第一个 LLM 网关"不是装出来的,是不知不觉写出来的。 最初你的代码里只有一句 openai.chat.completions.create()。后来 OpenAI 半夜抽风,你在外面包了个 try/except,失败就调 Anthropic。再后来财务问"这个月十几万的 token 花在哪了",你又加了一段记账逻辑。再后来某个客户的流量把你的限额打爆,你又写了个令牌桶。 这些 if/else 散在三个仓库、五个文件里,没人敢动。这就是网关——一个没有名字、没有人维护、谁碰谁倒霉的网关。 所以问题从来不是"要不要 LLM 网关",而是"这层东西,是攒成一坨烂代码,还是收拢成一个能被维护的组件"。这篇就讲清楚:它到底该管什么、自建还是用现成、路由策略怎么定,以及它本身会带来什么麻烦。 网关到底替你扛了什么 把它想成 LLM 调用的反向代理:你的应用只跟网关说话,网关再去跟一堆模型供应商打交道。它该扛七件事,但这七件事的优先级差得很远。 能力 解决什么 优先级 统一 API 一套 OpenAI 格式的接口调所有模型,换模型不改业务代码 必须 故障转移 某家供应商挂了 / 限流了,自动切到备用 必须 密钥管理 上游真 key 收在网关,业务侧只发"虚拟 key" 必须 限流配额 按 key、按团队、按租户限 QPS 和预算 高 成本核算 每次调用算钱,按业务线 / 用户出账单 高 可观测 全量请求日志、延迟分位、错误率、token 用量 高 缓存 命中过的请求直接返回,省钱省延迟 看场景 前三个是"接了第二个模型就立刻需要"的。中间三个是"上了生产、有了多个调用方"之后绕不开的。最后一个——缓存——别一上来就上,后面单独说。 统一 API 是地基。2026 年的事实标准是 OpenAI 的 /v1/chat/completions 格式:几乎所有网关都对外讲这套协议,对内再翻译成 Anthropic、Gemini、Bedrock、火山引擎、通义各自的方言。好处很直接——你的业务代码里不该出现任何一家供应商的 SDK,只有一个 base_url 指向网关。换模型这件事,从"改代码、过测试、发版"变成"网关上改一行配置"。 ...

先说一个数字:同样问"帮我查一下这个 bug",发给聊天机器人和发给 Agent,token 消耗能差 50 倍。 聊天机器人就一来一回:你发一段、它回一段,结束。Agent 不一样——它跑的是一个循环:看任务、调工具、读文件、改代码、再检查。循环里的每一步,都要把到目前为止积累的全部上下文,重新发给模型一次。 这就是 Agent 账单的根源。2026 年有人审计了 30 个在生产环境跑 Agent 的工程团队,一个 20 人的团队,单月 API 账单能冲到 11 万美元;用 Claude Code 或 Cursor 这类编码 Agent 的开发者,人均每月 400 到 1500 美元,失控的案例几天就烧掉 4000 美元以上。 更要命的是,这笔钱不是匀速烧的。Demo 跑得好好的,一上量就爆——大部分企业的 Agent 项目,在大规模铺开后的头 90 天里,实际花销会超出试点预算 4 到 11 倍。所以做 Agent,成本不是上线之后再优化的事,是设计时就得算进去的一笔账。 这篇把这笔账拆开:钱花在哪、怎么找到大头、有哪些真能省的手段、怎么设预算和熔断、怎么监控。 钱到底花在哪 先建立一个最反直觉的认知:Agent 跑一个任务的成本,主要不是输出,是输入。 模型 API 按 token 收费,输入和输出分开计价。聊天场景里,大家盯着输出看。但 Agent 不一样,它的成本大头在输入侧的重复计费。 为什么?因为对话历史会"滚雪球"。Agent 每调一次工具,就要把整段对话历史连同工具返回的结果,一起再发一次。一段已经积累到 10 万 token 的上下文,在后续每一次调用里,都按 10 万输入 token 收费——不是只收新增的那部分。一个跑到第 20 步的编码 Agent,光是文件读取塞进来的内容,单步输入就能超过 5 万 token,按 Sonnet 4.6 的价(每百万输入 token 3 美元)算,每一步 0.15 美元,二十步就是 3 美元,而这还只是一个任务。 ...

2025 年 7 月,METR 做了一个实验。16 个资深开源开发者,每人在自己熟得不能再熟的项目里干活,平均经验 5 年。246 个真实任务,随机分两组:一组允许用 AI(主要是 Cursor Pro 配 Claude 3.5/3.7),一组不许用。 实验前,这些人预测 AI 能让自己快 24%。干完之后,他们体感觉得 AI 让自己快了 20%。 实测结果:用 AI 的那组,慢了 19%。 这不是一个标题党段子。它是目前为止设计最干净的一个随机对照实验,而它的结论,跟你每天在朋友圈、在发布会、在融资 PPT 上看到的"10x 工程师"“生产力革命”,是相反的。 所以这篇文章想认真聊一件事:AI 编程到底是不是泡沫。我的答案会比较啰嗦——它在某些环节是真东西,在另一些环节是被吹大的气球,而把这两件事混在一起卖,才是真正的泡沫所在。 营销数字和实测数字,差在哪 先把两组数字摆出来。 营销侧的数字很漂亮:2026 年 84% 的开发者在用 AI 工具,AI 写了 41% 的新增商业代码,人均每周省下 3.6 小时。受控实验里,对那种"写一个函数"“生成一批单测"“铺一段样板代码"的细碎任务,提速 30%–55% 是常见的。 这些数字没造假。问题在于它们都是任务级的数字——把镜头怼到"写代码"这一个动作上,AI 确实快。 但你把镜头拉远到组织级,画面就变了。2025 年的 DORA 报告(Google 做的那份,样本是几千个真实团队)给出的结论很扎心:AI 让个人产出明显上涨——任务完成数 +21%,合并的 PR 数 +98%——但团队的交付速度,基本是平的。同一份报告里,AI 采用度和软件交付稳定性是负相关的。 更具体的两个数字:每个开发者引入的 bug 数,涨了 54%(过去的数据集里这个数字只涨 9%);每个 PR 引发生产事故的概率,涨了 242.7%——也就是说,每合一次代码,捅出线上事故的概率翻了三倍多。 看哪个层面 数字 谁在引用 任务级:写一个函数 提速 30%–55% 厂商、发布会 个人级:周产出 PR +98%,任务 +21% 厂商、个人体感 组织级:交付速度 基本持平 DORA 2025 组织级:稳定性 bug +54%,事故/PR +242% DORA 2025 资深 + 成熟项目 慢 19% METR RCT 同一件事,你站在不同的距离看,能得出完全相反的结论。营销永远站在最近的那个位置拍照。 ...

先说一个数字:Guardrails AI 在 2025 年初做过一次基准测试,结论里有句话很刺眼——单个护栏哪怕准确率有 90%,串五个,误杀率就到 40%。 这句话基本能概括做护栏的全部难处。你不是在"加保护",你是在一条已经够慢、够贵、够不确定的链路上,再叠一层会拖慢、会误判、还得自己维护的东西。问题不是"要不要护栏"——上线的 LLM 应用一定要有——问题是护栏管什么、做多厚、放哪一层。这三件事做错,护栏要么形同虚设,要么把好用户也一起赶跑了。 这篇不讲注入攻击的具体手法(那是另一篇的事),讲更宽的一件事:把用户的输入、模型的输出当成两道关口,这两道关口该怎么修。 护栏到底在拦什么 很多团队上来就装个 moderation API,以为护栏就是"过滤脏话"。不是。护栏分两侧,两侧拦的东西完全不一样。 输入侧,拦的是用户递进来的东西: 敏感信息。用户在对话里贴了身份证号、银行卡、内部工号、客户手机号。你不想把这些原样喂给第三方模型 API,更不想它们出现在日志里。 越界请求。一个做企业财报问答的 Bot,用户问"帮我写一首失恋的诗"。这不危险,但它不是这个产品该干的事——回答了,就是在替竞品做免费体验。 明显的恶意输入。攻击意图、自动化刷量、超长 prompt 灌爆上下文。 输出侧,拦的是模型吐出来的东西,这一侧更难,因为输出是模型生成的、不可预测的: 有害内容。暴力、仇恨、自残、违法信息。这是最经典的一类,也是 moderation API 唯一管得好的一类。 幻觉。模型一本正经地编了一个不存在的退款政策、一个错误的药品剂量。在 RAG 场景里,这意味着输出和检索到的资料对不上。 格式错误。你要的是一段能直接 JSON.parse 的结构化数据,模型给你前面加了句"好的,这是您要的结果:"。下游程序当场崩。 品牌口径。模型说了"我们的竞品确实更便宜",或者用了一个法务明令禁止的承诺词(“保证收益"“绝对安全”)。没毒,但能上财经新闻。 注意最后两类——格式和品牌口径——很多人根本不把它当护栏。但它们恰恰是上线后最高频出事的地方。有害内容一年可能出一次,格式错误一天能出一百次。 四种做法,从便宜到贵 护栏不是一种技术,是一个工具箱。按"成本/能力"从低到高,有四档。 第一档:规则与正则。 关键词黑名单、正则匹配身份证/手机号、长度限制、JSON schema 校验。便宜到几乎不要钱,延迟个位数毫秒,而且结果可解释——你能准确说出"它是因为命中了第几条规则被拦的”。缺点也明显:绕得过,且管不了语义。规则适合拦"形状固定"的东西:PII、超长输入、明确的禁用词。 第二档:专门的分类模型。 这是 2026 年的主力。Meta 的 Llama Guard 是一个专门微调出来的输入输出安全模型,自带六大类不安全分类,还能自定义类目;OpenAI 的 omni-moderation-latest 免费、能同时分类文本和图像。它们的关键优势是快——一个专用 guard 模型跑一次大约 29 毫秒,而拿一个大模型当审查员要 5 到 11 秒。但要清楚它们的边界:OpenAI moderation 只做内容分类,不查注入、不查幻觉、不做 PII 脱敏。它是基线,不是全部。 第三档:用 LLM 审查 LLM。 让另一个模型(或同一个模型换个 prompt)去判断"这条输出有没有问题"。最灵活,能处理"品牌口径"“答非所问"这种规则和分类器都搞不定的模糊判断。代价是它慢且贵——等于每个请求多一次完整的 LLM 调用,延迟翻倍,成本也翻倍。LLM 审查适合留给"少量、高风险、规则写不出来"的判断。 ...