百度内部方案交付从 7 天缩至 2 天

一项需求从分析到形成可交付方案，过去需要 7 天，如今缩短到 2 天。这是百度搭子开发平台内部实践中的一项记录。它衡量的是需求经过多个环节后何时能够交出结果，比单独看写代码或制作文档的速度，更接近企业实际需要的交付能力。

爱范儿记录的这项变化，为理解“智能组织”提供了一个具体入口：企业引入 AI 后，值得观察的单位应当是一项完整任务。个人完成某个环节更快，和整项需求更早交付，是两个需要分别检验的结果。上述内部实践展示了流程缩短的可能，但不能据此推定所有企业、所有需求都能获得相同收益。

让任务成为协作的起点

在百度世界大会上，李彦宏提出了三项原则：打破岗位边界、沉淀隐性知识、设计流程闭环。沿着完整任务来看，这三项原则分别涉及谁来承担工作、经验如何复用，以及结果如何进入下一轮改进。

岗位边界的调整，已有具体实践。百度数字人创新业务部推动全员向 Builder 转型，让员工借助 AI 承担更加完整的工作流程，涉及产品、研发、设计、测试等原有岗位边界。原文还记录，一名校招新人借助 AI，用一天完成了一项过去需要五个角色、至少十天才能交付的需求。

这个案例的意义，在于员工能够承担的任务范围发生了变化。本文的理解是，围绕任务重组协作，需要把关注点从“这个岗位能多快完成自己的工作”，移向“谁能调动所需能力，把需求推进到可交付状态”。这并不等于每名员工都能独立完成所有工作，也不能从一个案例推出岗位可以普遍取消。

多智能体协作也应放在这个尺度下理解。原文提出的方向，是让人与多个智能体围绕任务协作。组织设计因此需要关注不同环节如何衔接、知识如何调用、最终结果如何检验。智能体数量增加，本身并不能说明这些问题已经解决。

把一次完成变成可重复交付

更完整的工作范围，还需要可复用的经验支撑。资深员工为什么放弃某个商机、工程师为什么优先排查某个故障点，这些判断如果始终留在个人经验里，换人接手时仍然可能需要重新摸索。李彦宏提出，通过 Skill、Workspace 等方式将隐性知识沉淀到公司平台，供员工和智能体调用。

爱范儿给出的内部实践数据，将知识积累与交付变化放在了一起：百度数字人创新业务部在第三季度完成 564 次产研迭代，沉淀 130 个 Skills 和 729 篇组织资产，产研人均吞吐提升 125.3%，交付周期缩短 28.8%。这些是原文所述团队的实践结果，不能拆解为某一项组织措施的独立效果，也不构成对其他企业的收益承诺。

知识沉淀之后，还要检验它是否有助于下一次任务。李彦宏用“可衡量 + Looping = 持续进化”概括这种机制：以明确的业务标准检验执行结果，再把经验、偏差和反馈带入下一轮工作。由此看，保存文档只是其中一步，能否根据交付结果调整方法，同样重要。

未来由人与 AI 围绕任务动态协作、形成大量工作循环的公司，仍是组织设想。已有内部案例能支持的判断更具体：企业可以尝试扩大员工借助 AI 承担的流程范围，并同时记录交付周期与知识积累。个人效率能否转化为组织能力，最终要回到完整任务上验证：是否交出了结果，以及下一次能否复用并改进这套做法。