正在加载，请稍候
菜鸟把 AI 生成代码占比从约 10% 推到 90% 以上，需求变更周期却只缩短约 10%。原因不在模型，而在编码之外那七成交付链路。
菜鸟用半年多把提交代码里的 AI 生成比例从约 10% 推到 90% 以上，可需求变更周期只缩短了约 10%。这组数字指向一个不太受欢迎的结论：把研发效能押在"写代码"这一段，边际收益已经很低。
先对齐口径。菜鸟统计的贡献率，指提交进代码仓库的 AI 生成代码行数占整体提交行数的比例。这个数在 2026 年二三月先摸到 50%，随后平均值越过 90%，部分团队接近 100%——而团队半年前设定的目标只是"达到 20%，挑战 50%"。
推动它上行的不是单一变量。菜鸟研发总监郭凤钊在 AICon 上海站的分享里给了三层原因：底座模型持续换代（自 Opus 4.5、Sonnet 4.5 那一代起上限被明显抬高）、编码智能体从代码补全工具进化成能接管真实任务的产品、以及内部的推广动作。推广里最具体的是四件事：挑出真正愿意研究提示词与 Coding Rules 的开发者做布道师；引入市场上成熟的编码产品；对团队和个人两个维度度量并公开展示贡献率；与安全团队联合识别代码与数据风险。
最值得抄的是一条反面经验。菜鸟曾组建约 10 人的团队自研类 Copilot 工具，后来主动放弃，改用市场产品，理由是市场迭代速度超出小团队的追赶能力。这个判断对所有准备自研编码平台的企业都成立：先估自研团队与产品公司之间的迭代速度差，再决定要不要自己造。
第二个数字更值得决策者停下来看。对比有 AI 参与与无 AI 参与的需求，变更周期仅相差约 10%。三个原因叠加造成了这个差额。
所以瓶颈不落在模型能力上，而落在"确定性"上：模型能写代码，但流程的推进权还在人手里。菜鸟的解法是把探索范围从 Vibe Coding 扩到需求的端到端托管，让流程由智能体主导，工程师只在必要节点确认。
运行环境的选择也有取舍。本地跑符合开发者习惯，但云端沙箱有两个不易替代的好处：任务不会因为开发者合上笔记本而中断；最佳实践沉淀在共享环境里，而不是散在某个人的电脑和脑子里。菜鸟选了后者。存量系统这一关的细节，站内另一篇迁移 4 万行遗留代码的复盘记录得更细。
托管交付面对的是跨度极长的任务。菜鸟在内部见过四类做法，每一类都有自己的代价：
| 做法 | 看起来拿到什么 | 真实代价 |
|---|---|---|
| Workflow 编排固定节点 | 节点可控、便于审计 | 链路一长流程就难维护，灵活性差 |
| 自研专用托管系统 | 贴合内部流程（2025 年 4 月曾用 Spring AI 做过） | 投入高；各团队流程差异要逐个兼容；跟不上最佳实践迭代 |
| 每个步骤封装成 Skill、人工逐个触发 | 单步效率明显提升 | 人依然是流程瓶颈，串联仍靠手动 |
| 用一个提示词编排其余全部 Skill | 上手最快 | 长程任务下直接顶到窗口边界 |
最后一条最容易踩坑。即便模型给出接近百万级的窗口，真正能留给任务的空间也没有看上去那么充裕——系统提示、历史会话、工具定义、工具调用结果、读入的文件内容都在分食这块预算。
随着执行轮次增加，菜鸟把观察到的失效归纳成三类：
通用应对手段是新建会话、上下文压缩、用子智能体隔离、失败回退或续跑。仅靠 Skill 本身解决不了，因为它自己就跑在上下文里，没法从外部管理它。落到操作上只有一条纪律：先把功能清单拆出来，再增量推进，每次只做一步，做完检查真实产物——不要只信模型的自我反馈。同一类失效在记忆层还有另一种表现，工具调用到第 50 次之后目标开始丢失那篇给出了分层改造的做法。
编码之外的环节要被托管，前提是每一步都有能自动判定的门。行业在这个方向上交过学费：Hoodline 在 9 月 18 日报道，美联航的客服机器人告诉客户一笔 200 美元的旅行积分自存入起五年有效，而这笔积分实际在 2026 年 9 月 27 日到期，最后只能人工补发替代凭证。Gartner 的预测更冷：超过 40% 的 Agentic AI 项目会在 2027 年底前被取消，风险控制不足是原因之一。Scale AI 在论文《READY》里的表述最直白——一个智能体可以在基准测试上表现很好，仍然不适合部署。
对应的解法是把"凭什么上线"变成可测量的流程。亚马逊云科技 2026 年 6 月发布的白皮书提出 Agent DLC，把生命周期拆成定义、构建、评估、发布、观测、回流六个环节，放行由评估结果决定：达标就走，不达标返工，不在会上拍板。沉淀下来的资产分两部分——定义"什么算对"的评估规范，以及可复现、带基线准确率的黄金轨迹集。这套东西没法直接搬，但思路可以借：把团队对智能体的每一条要求，从意图识别到"不得编造"到单次调用成本上限，都变成能自动测的判据。
要先把这条线补上，可以先看两篇旧文：一篇讲大多数试点其实死在验收环节而不是模型，另一篇讲日志攒了一堆却判断不出对错，缺的是评估链路。
2026 年 9 月这套账又变了一次。编码侧，Claude Code v2.1.280 把 Opus 5.5 设为默认档位，支持 1M 上下文，定价每百万 token 输入 4 美元、输出 20 美元，缓存读取每百万 token 0.20 美元；同时把 Pro 与 Team Standard 计划的默认模型从 Sonnet 换成了它。官方对新一代的说明是：典型负载成本比上一代低 40%，输出速度提升超过 30%。
默认档位上移，既不代表账单必然变贵，也不代表必然变便宜，它把两个变量推到了台前：重试次数与缓存命中率。长程任务里一次失败重跑的成本，可能高于降价省下来的部分；而缓存读取的单价只有输入价的二十分之一，上下文复用做得好的团队吃到最多红利。Uber 那边接管了七成代码 PR 而账单没有膨胀，靠的正是这套复用与限额的组合。
另一条省钱路径是按边界清晰度分层。有个平台推出的批量接口在 24 小时窗口内异步完成请求，通常按正常单价的 50% 或更低计价，已支持 70 多个模型，适合回归测试、批量重构这类不着急的活。更极端的例子来自同平台实测：在 3080 条客服语料的意图分类任务上，小模型准确率 81.0%，比大模型低 3.3 个百分点，但中位延迟 175 毫秒对 2266 毫秒，每千次请求成本 0.11 美元对 2.42 美元。分工因此清晰：边界清晰的高频步骤交给小模型，模糊的长程任务留给大模型。
说明代码来源结构变了，不说明交付变快了。这个指标的分母是提交行数，而编码只占交付链路约三成时间。要判断效能，得同时看变更周期、返工率与部署频率。
先估迭代速度，而不是先估功能清单。菜鸟的经验是约 10 人自研团队追不上市场产品；另一条自研路线的代价是要兼容各团队流程差异，且很难长期保持先进性。除非你的研发流程本身就是核心竞争力，否则采购加定制通常更划算。
有，但都在框架层面而不在提示词层面：新会话、压缩、子智能体隔离、失败回退。判断标准只有一个——完成一步就去检查真实产物，而不是接受模型的自我报告。
可以先不做全链路。把交付过程按阶段列出来，标出每段的等待时间，先托管等待最长、判断标准最清晰的那一段。评估门比沙箱更优先——没有判据，托管只会把错误自动化。
落地顺序建议是：先测各阶段耗时，再定评估判据，最后才决定托管哪一段。蓝曜炬辉（www.lanyaoai.com）给企业做研发效能改造时，第一步也是这张表，而不是先选模型。想看同类项目怎么拆链路，可以翻我们的项目案例库；想把你们的阶段耗时表拿来对照判据，直接联系我们即可。