北京
过去半年多，菜鸟内部 AI Coding 贡献率从约 10% 提升到 90% 以上。这里的口径是 AI 生成代码行数在提交代码中的占比。 但把有 AI 参与和没有 AI 参与的需求放在一起比较，需求变更周期只相差约 10%。编码环节的自动化速度，并没有按同样比例传递到整条需求交付链上。 这个反差来自菜鸟的复盘。它把问题说得很直接：模型能力的增长，尚未自动变成组织交付速度。 **瓶颈不在写代码，在交接处** 链路比写代码长得多。需求仍要经过澄清、方案设计、测试用例、编译、测试和部署。 即便某个阶段完成，往往还需要工程师确认结果、切换工具、再发起下一步。菜鸟把这种停顿归结为「人主导流程」的限制：人的注意力和时间，会在多个阶段之间成为端到端瓶颈。 换句话说，代码生成快了，但流程的节奏仍由人在节点之间推动。自动化只覆盖了链条中的一段。 **托管交付：让 Agent 从需求跑到预发** 菜鸟给出的方案是托管交付。任务从需求澄清一直运行到预发部署，由 Agent 主导，工程师只在必要节点确认。 运行环境选择云端沙箱。这一方面让任务可以持续运行，另一方面让流程和经验不只留在个人电脑上。 这也说明，端到端并不是让 Agent 自己连续聊天，而是给它一个可运行、可复用、可审查的企业环境。 方案被拆成四层： - 通用 Agent 提供 Harness，负责上下文管理、会话恢复或独立执行 - Plugin 承载 Skill、Subagent、Hooks、MCP 和 CLI 等可分发能力 - Playbook 用自然语言描述企业流程 - todo.json 记录每个任务的前置条件、状态与产物 四层分别处理执行、能力、流程和状态，而不是把所有细节塞进一个长 Prompt。 **结构化状态：不让不确定性藏进下一轮对话** 其中最值得借鉴的是结构化状态。菜鸟不使用容易被模型随意增删的 todo.md，而是限制 Agent 只处理序号最小的未完成任务，只修改状态与时间。 每次执行先检查前置产物，再进入进行中状态，调用对应能力，核查输出真实存在，最后更新状态。 当需求澄清和方案阶段需要人工确认时，流程会进入等待人工状态，而不是把不确定性藏进下一轮对话。 这套做法并非可以直接复制到任何组织的配方。它依赖已有的流程、云端沙箱和任务边界。上线后最近 30 天交付了一百多个需求，仍是有限范围的实践。 它的价值在于明确了先后顺序：先挑选验证成本低、边界清楚的任务，为每一步定义产物、状态和人工确认，再判断 Agent 是否真正缩短了交付，而不是只统计代码生成比例。 **同一批材料里的另外两个信号** Anthropic 尝试把前沿实验室内部的研发过程转化为可追踪指标。它把公司里的 AI 研发工作整理成任务树，再按六级自动化标准评分，从没有 AI 参与，到 AI 协作、AI 主导和完全自主。 内部快照显示，Claude 主导了 26% 的被测研发工作，达到 AI 协作及以上的工作超过 90%，但没有任何被测任务完全由 Claude 自主完成。 这套做法的关键不是给自动化一个好看的总分。固定任务树和权重后，同一组织才能比较不同月份的变化；公开分级方法后，外部才知道数字究竟描述了哪些工作。 大淘宝则把策略类 Agent 的评测拉回业务效果和上线治理。它提出「五层、四步、三阶段」的组织方式，五层评测对象覆盖输入约束、知识和上下文、执行过程、策略推理、业务效果与持续监控。 这样做是为了区分失败来源：提示词目标矛盾、知识供给错误、工具执行异常和策略方向偏差，不能被同一个通过率掩盖。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
