/* MD / 富文本中的 .toc（含博客园搬家等嵌套结构）；.toc-box 在侧栏，不受影响 */
#content_views .toc,
/* 编辑器常在目录前后插入空 p（:empty 仍占 20px），一并去掉避免顶空隙 */
#content_views.markdown_views > p:empty:has(+ .toc),
#content_views.markdown_views > .toc + p:empty,
/* 富文本旧版目录标记 */
#content_views.htmledit_views #main-toc,
#content_views.htmledit_views #hr-toc,
#content_views.htmledit_views p[id*=\”-toc\”] {
display: none !important;
}
/* 目录去掉后，紧跟的首个标题不再多出一块上边距 */
#content_views.markdown_views > .toc + h1,
#content_views.markdown_views > .toc + h2,
#content_views.markdown_views > .toc + h3,
#content_views.markdown_views > .toc + h4,
#content_views.markdown_views > .toc + p:empty + h1,
#content_views.markdown_views > .toc + p:empty + h2,
#content_views.markdown_views > .toc + p:empty + h3,
#content_views.markdown_views > .toc + p:empty + h4 {
margin-top: 0 !important;
}
在 2026 年 AICon 全球人工智能开发与应用大会上海站上，菜鸟网络研发总监郭凤钊分享了一组"反常识"的数据：半年多时间里，菜鸟内部 AI Coding 贡献率从约 10% 拉升到 90% 以上，但需求变更周期只缩短了约 10%。
这篇分享最有价值的地方，不是告诉我们"AI 提效了"，而是坦率地暴露了一个落差——编码自动化，并不等于研发效能跃升。本文基于该分享，梳理其背景、亮点、创新点，以及那些"说了半句"却没讲透的问题。
一、故事的开端：当"AI 写代码"撞上"交付没变快"
1.1 一组刺眼的对比数据
菜鸟这次分享的起点非常坦诚：
- AI Coding 贡献率：从约 10% 提升至 90% 以上，部分团队接近 100%。这里贡献率的定义是"提交到代码仓库中 AI 生成代码行数占整体提交行数的比例"。
- 需求变更周期：对比有 AI 参与和没有 AI 参与的需求，二者只相差 约 10%。
90% 的贡献率，10% 的提速。这个巨大的剪刀差，是整场分享最尖锐的问题——AI 让写代码变快了，但交付并没有等比例变快。
1.2 为什么会这样？三个原因
菜鸟给出的诊断是：
一句话总结菜鸟的判断：只要流程仍由人主导，人的注意力和时间就是端到端交付的瓶颈。
二、值得记笔记的亮点：菜鸟到底做了什么
2.1 增速的三大推手
从 10% 到 90% 只用了半年多，菜鸟认为背后有三股力量：
- SOTA 模型持续进化：从 Opus 4.5、Sonnet 4.5 起，基础能力的提升直接抬高了 AI Coding 的天花板。
- Coding Agent 快速成熟：Cursor、Claude Code、Codex 等产品进入激烈竞争，开发者可以交出"真实任务"而非"代码片段"。
- 内部推广策略：包括选拔 AI 布道师、引入成熟市场化工具（菜鸟曾自研约 10 人团队的 Copilot，后来选择引入市场产品）、团队与个人维度贡献率公开度量、与安全团队联合防控风险。
2.2 整体技术方案：一句话概括
通用 Agent 提供 Harness，Plugin 承载能力，Playbook 描述流程，todo.json 保证长程任务的确定性执行。
拆开看：
- 云端沙箱：整个流程运行在云端，底层由 Claude Code 等通用 Agent 提供 Harness。相比本地运行，云端能提供 7×24 小时稳定运行环境，也便于企业内部最佳实践的共享复用。
- Plugin 承载能力：Plugin 可以包含 Skill、Subagent、Hooks、MCP、CLI 等。不同业务团队维护自己的 Skill 和 Playbook 并打包进 Plugin，平台层无需硬编码所有差异。
- Playbook 描述流程：用自然语言描述企业内部交付流程，例如 Task 1 需求澄清 → Task 2 技术方案生成 → Task 3 测试用例生成 → Task 4 代码实现及后续流程。
- todo.json 兜底：Playbook 通过 Skill 转成 todo.json，再由 Executor 循环执行。
2.3 一个容易被忽略的工程细节：为什么是 todo.json 而不是 todo.md
这是全文少有的"可复用设计决策"，值得单独拎出来：
- JSON 提供更强的结构化约束。规则规定：Agent 每次只能选择序号最小的未完成任务，只能修改任务状态、开始时间和结束时间，不能改其他字段，更不能增删任务。
- 执行循环大致是：定位最小未完成任务 → 检查前置产物 → 标记 In Progress → 调用 Skill / Subagent → 校验输出真实存在 → 更新状态 → 继续。
- 编译和部署适合放进 Subagent，因为主 Agent 不关心中间输出，只需知道成功与否和失败原因。
- 需求澄清、方案生成阶段会进入 Waiting for Human 状态，通过 AskUserQuestion 请求确认，形成持续运行的 Agent Loop。
菜鸟也坦言：随着模型能力提升，这层 Harness 未来可能简化，也许只用 Markdown 描述流程就够了——但在当前阶段，结构化状态和确定性约束仍不可或缺。
2.4 产品形态与场景选择
- “用户在哪里，托管交付 Agent 就应该在哪里”：把能力嵌入现有需求管理系统，而不是再造一个工具。
- 黄金场景：不是所有需求，而是 “开发者不愿意做、却又不得不做的小需求”——工单类（MySQL 修改、安全工单、漏洞升级、线上 NPE 修复）、体验优化类（加按钮、调表格）、重复性需求（简单 CRUD、协议转换）。这类任务边界明确，往往能直接定位到应用和代码仓库，类似 GitHub Issue 天然属于某个仓库的 A-to-A 协作。
三、这篇文章真正的创新点在哪
抛开"某某公司又提效了"的常规叙事，这篇分享有几个判断和设计确实有增量价值：
3.1 用"贡献率 vs 交付速度"的剪刀差提出真问题
多数效能分享停留在"我们提效了多少"，而这里主动暴露"提效很小"的落差，并把原因定位到"编码只占约 30% 时间 + 阶段间仍需人工确认"。承认问题的勇气本身，比报喜数字更有信息量。
3.2 把问题重新定义为"长程任务可靠性"
菜鸟没有停留在"再接几个工具"，而是识别出三类失败模式：上下文腐烂、上下文耗尽、上下文焦虑。这实际上把问题从"工具集成"抽象成了"长程 Agent 稳定性"，层次更高。
3.3 todo.json 的确定性约束设计
在"用自然语言描述一切"的主流叙事里，文章给出了一个反例：为了可靠执行，结构化状态与确定性约束不可删除。这是一个具体、可复用的工程答案，而非泛泛而谈。
3.4 Harness / Plugin / Playbook 的分层抽象
这套分层回答了"企业流程知识如何沉淀进 Agent"这个常被忽略的问题，且通过 Plugin 机制支持业务团队自治，避免了平台层硬编码。
3.5 度量观上的克制
明确提出"体验改善 ≠ 效能提升"，主张指标应用于观察趋势和发现摩擦点，而非当作绝对答案；用北极星指标定方向，用多维检查指标相互制衡。在普遍用单一指标邀功的语境下，这种自我约束难得。
四、没讲透的部分：那些被"半句话"带过的问题
这部分可能是全文最有讨论价值的——分享给了方向，但关键账没算清。
4.1 "90% 贡献率 + 10% 提速"的因果链并未验证
把提速有限归因于"编码只占 30% + 人工介入"，这只是相关性推测。真正需要排除的还有：需求本身变大变复杂、测试环境排队、发布窗口限制、评审流程冗长、跨团队依赖等待。如果这些才是主因，那么投入端到端 Agent 的收益天花板就完全不同。 文章没给出时间花在哪里的具体分解数据。
4.2 度量口径模糊
- "AI Coding 贡献率"是按代码行数、需求数还是 PR 数？文中定义是代码行数——而按行数口径，极易被"生成大量低价值代码"人为拉高，恰恰削弱指标可信度。
- "需求变更周期"从哪个环节算到哪个环节，也没交代。
- 口径不清，指标之间就难以真正相互制衡。
4.3 成本账与人账缺失
把 Agent 搬到云端沙箱、7×24 运行、持续维护 Plugin 与 Playbook，都是持续投入。文章没有回答：节省的工程师时间是否覆盖了基础设施与维护成本？谁来维护 Playbook 随流程变化而更新？没有成本侧数据，"效能提升"只是单侧账。
4.4 质量、返工与技术债被淡化
全文几乎只谈速度和贡献率，未涉及 AI 生成代码的线上故障率、返工率、可维护性，以及人类 review 机器代码的认知负担。如果交付加快伴随缺陷上升，实际端到端周期会被返工吞噬——这是明显的盲区。
4.5 黄金场景的可迁移性存疑
推荐的黄金场景恰恰是最容易被自动化、价值也最低的尾部需求。它回避了核心问题：AI 在高复杂度、跨系统、需要设计判断的需求上到底能做到什么程度？如果 Agent 只能吃低价值长尾，那对整体交付效率的拉动必然有限——这与开篇观察到的 10% 恰好自洽。
4.6 组织与人的阻力被轻描淡写
文章提到"找 AI 推广先锋"“与安全团队合作”，但真实的摩擦在于：工程师是否愿意让出决策权？评审者是否信任无人干预的产出？责任归属如何界定？绩效体系如何重估？这些组织政治与激励机制问题，往往比技术架构更决定成败。
4.7 生态依赖与锁定风险
文中提到"引入成熟的 Coding Agent"，但未讨论能力绑定带来的锁定风险、数据合规边界，以及底层模型能力或定价变化时的应对策略。
五、总结：把问题讲清楚了，但没证明"答案就是它"
这篇文章的贡献在于：
但它没有回答的是：
- 那 10% 的提速瓶颈究竟在哪（缺数据分解）；
- 指标口径是否可靠；
- 成本与质量账是否算得平；
- 这套方案是否只适用于低价值尾部需求。
换言之，它把"编码不是全部"讲清楚了，却没有证明"端到端 Agent 就是那缺失的部分"。
对正在做企业级 Agent 落地的团队来说，菜鸟的实践是一份真实、有价值的工程切片——但用它做决策前，建议先补上自己场景下的三张表：时间分解表、成本收益表、质量返工表。
本文基于菜鸟网络研发总监郭凤钊在 2026 AICon 上海站的分享整理与延伸评论。
关键词：AI Coding、研发效能、Agent 托管交付、Claude Code、Playbook、todo.json、DORA、DevEx
