最近翻了下 AICon 上海站菜鸟郭凤钊的分享里面有个数据特别扎心菜鸟内部的 AI Coding 贡献率半年多从 10% 干到了 90% 以上可需求的交付周期几乎没怎么变快。这事儿挺反直觉的。很多团队包括我们都在冲AI 写了百分之多少代码这个指标但菜鸟用真金白银的投入告诉我们编码自动化跟需求交付提速根本不是一回事。这篇文章我把分享里最值得普通开发者/技术负责人借鉴的部分拆出来讲尽量说人话。一、先把背景说清楚90% 是怎么来的菜鸟从 2025 年 10 月左右开始大规模推 AI Coding。一开始大家都不信——“AI 写写新项目还行咱这些祖传代码、历史包袱它搞得定”当时菜鸟的 AI Coding 贡献率大概只有10%。他们定了个目标半年后到 20%挑战 50%。AI Coding 贡献率是什么你们团队提交到代码仓库里的代码有多少行是 AI 帮忙写的占全部提交代码行的比例。比如你今天提了 100 行其中 80 行是 AI 生成的贡献率就是 80%。结果半年多后这个数字直接干到了90% 以上部分团队接近 100%。郭凤钊总结提速主要来自三股力量模型越来越强。从 Opus 4.5、Sonnet 4.5 一路迭代底座能力直接抬高了天花板。Coding Agent 打起来了。Cursor、Claude Code、Codex 这些产品把生成代码片段升级成了把真实任务交给 AI。内部推广策略做对了。菜鸟主要干了四件事找一批真信 AI 的开发者当布道师研究并推广最佳实践不再自研 Copilot10 人小团队拼不过专业产品公司直接引入成熟工具把团队和个人的贡献率度量出来、公开晒联合安全团队防住 AI 带来的代码/数据安全风险。到 2026 年二三月平均贡献率过 50%之后一路上 90%。然后问题来了贡献率上去了交付周期却没等比例缩短。二、最扎心的对比有 AI 和没 AI交付周期只差 10%菜鸟对比了有 AI 参与和没 AI 参与的需求发现两者的需求变更周期只差了大约 10%。打个比方你雇了个打字飞快的助理他写代码的速度是你的 5 倍。但你交活儿的总时间只少了 10%。为什么因为写代码只是整个流程里的一小段。三个原因很实在编码只是交付链路的一环。一个需求从澄清、技术方案、用例生成、编码、编译、测试到部署编码就算 100% 自动化在整条链路里可能也就占 30% 的时间。编码之外的步骤还没被 AI 托管老研发系统对 Agent 也不友好没法像 Vibe Coding 那样顺滑自动化。阶段之间还得靠人推。一段干完了得工程师确认、切工具、再发起下一步。工程师要是正忙别的整条流就停了。结论一句话只要流程还是人主导人的注意力和时间就是端到端交付的瓶颈。所以菜鸟下一步不是继续优化写代码而是探索需求的端到端托管交付从需求澄清一路干到部署到预发环境由 Agent 主导人只在必要节点确认。三、先解决跑在哪为什么是云端沙箱托管交付 Agent 得有个运行环境选项有三个本地、普通云端、云端沙箱。菜鸟选了云端沙箱理由很务实7×24 小时在线。本地环境你一关电脑任务就断了云上不会。利于经验共享。如果最佳实践只存在某个人脑子和小本本里别的团队根本复用到。云端沙箱是什么简单理解就是云上的一台开发机随开随用、跟你本地电脑解耦关了电脑它还在跑。四、长程任务的坑光把 Skill 串起来没用企业内部常见四类方案菜鸟都见过方案做法问题Workflow 编排把澄清/方案/用例/代码节点串起来链路太长很快难维护、不灵活自研专用 Agent用 Spring AI 自己写一套成本高难兼容各团队差异迭代追不上各步骤做 Skill 人工调用写完单测再手动触发下一个单步快了人还是瓶颈一个 Prompt 编排所有 Skill用大 Prompt 调度复杂长任务直接撞上下文上限三个绕不开的上下文坑长任务跑着跑着容易撞上这三件事上下文腐烂Context Rot上下文里混进太多无关信息模型对关键内容的注意力明显下降。上下文耗尽Anthropic 举过例子直接让 Agent 基于 Claude Code SDK 做一个完整官网可能干到一半上下文就满了压缩后剩下的现场也未必够下一个 Agent 接手。上下文焦虑模型快到上限时可能提前宣布我做完了你一查代码核心功能根本没写。上下文Context是什么模型一次能看见的全部信息窗口。System Prompt、历史对话、工具定义、读进来的文件……全都占这个窗口。哪怕号称百万 Token真正能留给任务的空间也没那么宽裕。解法郭凤钊说得很直白先拆功能清单再增量推进每步只做一件事做完检查真实产物别光信模型的我好了。通用 Agent 一般用新开会话、压缩上下文、Subagent 隔离、回退/继续来管理上下文。光靠 Skill 不行——Skill 自己就活在上下文里没法从外部管自己。五、菜鸟的招Plugin 管上下文Playbook 写流程菜鸟的解法是Plugin。几个名词快速过一遍Plugin插件把各种能力打包、带版本管理和分发机制的容器。Subagent子代理开一个独立上下文在内部把任务闭环跑完只把结果回给主 Agent。Hooks钩子在特定事件前后确定性地执行脚本避免模型因上下文太长忘了必须做的事。MCP / CLIMCP 是模型连外部工具的协议CLI 是命令行工具可以--help一步步发现命令不用一开始就把所有命令定义塞进上下文。分享里还提到CLI 正在替代一部分 MCP 场景原因就是更省上下文。从上下文管理的角度看这些组件各有分工组件在上下文管理里的角色Skill渐进式加载知识和操作手法Subagent开独立上下文内部闭环只回结果Hooks事件前后确定性执行防遗忘CLI按需发现命令不预载全部定义但通用 Agent比如 Claude Code并不知道菜鸟内部一个需求该怎么交付、步骤间什么关系。所以菜鸟又引入了Playbook用自然语言把企业内部的交付流程写清楚例如Task 1需求澄清Task 2技术方案生成Task 3测试用例生成Task 4代码实现及后续流程Playbook 会被转成一个todo.json再由 Executor 循环执行。整套跑在云端沙箱里底层是通用 Agent 提供的 Harness运行底座。一句话概括菜鸟的方案通用 Agent 提供 HarnessPlugin 承载能力Playbook 描述流程todo.json保证长程任务的确定性执行。不同业务团队维护自己的 Skill 和 Playbook打包进 Plugin。平台就能按各团队定义的流程跑任务不用在平台层写死所有差异。六、为什么是 todo.json而不是 todo.mdManus 这类 Agent 早期爱用todo.md先列清单完成一项划一项。但企业交付的状态比划掉复杂得多。选用todo.json的两个硬理由Markdown 容易被模型乱改。Agent 可能凭空加任务也可能把原有任务删了。Markdown 待办只有完成/未完成。表达不了 Pending、In Progress、Skipped、Failed 这些状态。比如生成技术方案前必须先确认需求澄清文档已存在否则就该退回澄清阶段而不是硬往下走。就像你给装修队一张清单不能只标做了/没做还得标等业主确认中“这步卡住了”“这步跳过了”。JSON 正好能把这些状态钉死。JSON 给的约束很死Agent 每次只能挑序号最小的未完成项只能改状态、开始/结束时间不能改别的字段更不准增删任务。执行流程大致是这样json示例 伪流程{tasks:[{id:1,name:需求澄清,status:Done,start:2026-05-12T09:00,end:2026-05-12T09:40},{id:2,name:技术方案生成,status:In Progress,start:2026-05-12T09:41,end:null},{id:3,name:测试用例生成,status:Pending,start:null,end:null},{id:4,name:代码实现及后续,status:Pending,start:null,end:null}]}// 每轮循环的执行逻辑伪代码 1. 在 todo.json 里找序号最小的未完成任务 2. 检查它的前置任务和必要产物是否已完成 3. 把当前任务标记为 In Progress 4. 调用对应的 Skill / Subagent 5. 检查输出是否真实存在且满足条件不光看模型说好了 6. 更新状态继续下一项编译、部署适合丢进 Subagent主 Agent 不关心中间过程只要成没成、为啥失败。需要主流程持续用上下文的任务比如澄清、方案用 Skill 跑。在澄清/方案阶段流程会进入Waiting for Human状态通过AskUserQuestion请工程师确认确认后继续——这就是一个持续运转的Agent Loop直到最后一项结束。郭凤钊判断等模型再强点这层 Harness 可能会简化未来也许光用 Markdown 描述流程就能可靠执行。但在当下结构化状态 确定性约束还是省不掉。七、产品在哪Agent 就该在哪产品形态上菜鸟坚持一个原则用户在哪托管交付 Agent 就该在哪。他们没有让用户去一个独立的 Agent 平台而是把能力直接嵌进现有的需求管理系统。界面三块左边 Agent 控制/对话区中间人工 Review 区右边执行进展。几个细节很接地气过去由人写的 PRD现在由 Agent 生成人在中间区 Review交互上尽量不让用户写复杂 Prompt而是用 A/B/C 选择题引导补充信息类似 Superpowers 的 Brainstorming 思路需求交付不是直线的。有时都部署到预发了才发现漏了功能或实现不对得退回澄清或方案阶段。所以引入了Round轮次概念允许一次需求经历多轮澄清和执行、在各阶段间回退所有中间产物都持久化Hooks 监听todo.json变化一旦有新产物就写进数据库。用户不用登沙箱就能在需求管理界面看进展沙箱还顺手降低了使用门槛任务启动就初始化沙箱、克隆你选的仓库。你不用在本地装 JDK、Maven 或 Claude Code。这套能力 2026 年 5 月上线最近 30 天交付了100 多个需求。量还不大但路走通了。有意思的是PMO、产品经理、技术运营这些非技术岗也开始用这平台交付生产代码主要面向内部提效工具。过去得等研发排期现在一些影响范围小、失败成本可控的内部需求他们自己就能交。八、怎么推广别从我还能加什么出发Demo 做出来后新问题是怎么让人真用起来。平台团队容易从还能加什么能力想产品但平台有这能力不等于用户需要它。分享里借了《与运气竞争》的Jobs to Be Done理论用户雇佣一个产品是为了完成某项任务。雇佣是有成本的——哪怕公司内部工具免费用户也要搭学习和操作精力万一干不成还得切回老办法。顺着这个思路菜鸟认为托管交付的黄金场景不是所有需求而是开发者不愿做、却又不得不做的小需求。类别例子为什么适合工单类MySQL 改动、安全工单、FastJSON 漏洞升级、线上 NPE 修复事小但专门开个迭代又不值当体验优化加个按钮、调表格尺寸、改交互细节必须做但工程师提不起劲重复性简单 CRUD、协议转换第三方能力转内部网关协议重复度高没人想反复手搓打个比方就像家里那个滴水的水龙头你知道该修、但又懒得动手。Agent 帮你修好你只要确认行不行、合不合用就行。阻力自然小。这类场景还有个天然好处往往能直接确定要改哪个应用、哪个仓库。GitHub 之所以能做成 A-to-AAgent 提 Issue、另一个 Agent 修并开 MR协作就是因为 Issue 天生属于某个仓库。工单、安全问题、异常日志通常都带着应用信息丢给 Agent 最顺。理想状态是Agent 每天主动发现并干完一批这种活再通知工程师——“这问题修好了你确认下要不要合并发布”。到那时候托管交付就不再是又一个开发工具而是一个直接帮你干完待办活的 Agent。分享里也提到《跨越鸿沟》新技术从早期市场走向主流得先在一个细分领域打透。对这些不愿做又不得不做的小需求下功夫就是菜鸟选的突破口。九、效能度量别只看代码贡献率贡献率冲到 80%、90% 之后老板和 CEO 还是会问一句So what菜鸟梳理了研发效能度量框架的演进DORA较早看部署频率、变更前置时间、变更失败率、服务恢复时间。关注交付快不快、稳不稳但不回答团队做的是不是正确的事。SPACE2021扩展出满意度、质量与效率、工作活动分布、协同效能、效率与心流等维度。全面但维度太多团队反而不知道先优化啥。DevEx2023 起聚焦开发者体验尤其是反馈闭环、心流、认知负荷。为什么前端工程师更早被大模型冲击一个原因就是前端反馈闭环短改个按钮立马能看到验证成本低后端改动可能引入性能问题或暗坑光看代码表面发现不了。闭环越短、认知负荷越低越容易进入心流。但 DevEx 也有局限体验好 ≠ 效能高。AI 时代团队可能为了刷高贡献率跟 AI 聊了大量没实际价值的对话——指标涨了业务产出没涨。所以菜鸟的结论是还得有一个北极星指标从多、快、好、省回答 AI 到底带来了啥单位周期里人均交付需求数有没有增加需求整体交付周期有没有明显缩短工单数、故障数有没有下降代码质量有没有提升。对非技术岗尤其要跟管理层解释 AI 价值时北极星指标能提供清晰牵引。但只有一个北极星也不行——当一个指标变成唯一目标它往往就不再是好指标。所以需要检查指标来制衡人均交付需求数涨了要查是不是把大需求拆小了凑数评估交付周期要排除需求规模变化的影响。最后提醒一句研发效能度量像座冰山。水面之上是能统计的指标水面之下是组织架构、技术架构、业务阶段和组织文化。按康威定律系统架构和组织架构强相关企业所处业务阶段不同合适的指标也不同。很多影响效率的因素没法量化所以指标不是标准答案而是用来看趋势、找摩擦点、推优化的。十、四个判断值得抄作业的结论把整场分享收个尾郭凤钊给了四个判断我觉得对普通团队也管用推 AI Coding 落地先抓三板斧用先进模型、选好用的 Coding Agent、对关键指标度量并公开。做长程任务比如需求交付可以用通用 Agent 当 Harness Plugin 承载能力 Playbook 描述流程的组合再用结构化任务状态保证执行的确定性。做完产品要回到用户视角想清楚用户愿意雇佣它完成什么任务。把具体场景做透产品才有机会跨过早期尝鲜 → 规模化的鸿沟。效能度量不是为好看的数字而是发现交付里的摩擦点。用北极星指方向用多维检查指标相互制衡再结合组织和业务背景看趋势才接近 AI 创造的真实价值。参考资料与配图来源郭凤钊《菜鸟 AI 研发效能实践》2026 AICon 全球人工智能开发与应用大会上海站分享。文中架构图、界面图、场景图均来自 InfoQ / 极客时间现场截图原分享配图封面图与云端沙箱概念图为本文原创生成图。相关概念延伸阅读《与运气竞争》Jobs to Be Done、《跨越鸿沟》、DORA / SPACE / DevEx 研发效能框架。