快手风控团队把需求流转节点从 12 个减到 6 个

快手一支风控团队的负责人在 10 月 31 日给出了一组少见的数字：工程师用 AI 写码已经快了很多，交付却没有同步变快，直到团队把需求在岗位之间流转的节点从 12 个减到 6 个。29 人的局部试点里，需求吞吐率从 36% 升到 84%。

这组数字回答了很多公司正在问的问题：AI 让每个人更快，为什么整个团队没有更快？快手给的答案是，慢在交接，不在写码。数字来自团队负责人在自家技术沙龙上的分享，质量与人手代价没有公开。

编码只占交付时间的 20%

据财经网的报道，快手磁力引擎风控技术负责人王东旭在第六期快手技术沙龙上用阿姆达尔定律算了一笔账：编码只占端到端耗时的 20%，就算压到接近零，整体交付也只快约 25%。

智东西的报道记下的是另一种算法：开发提速 10 倍，整体约快 22%。编辑按 20% 的占比复算，两种说法都成立。

这不是一个团队的孤例。快手在 InfoQ AICon 上海的议题页里写道，2024 年公司 AI 代码生成率已过 30%，83% 的研发人员在用 AI 工具，个人体感提效 20% 到 40%，需求交付效率却没有相应提升。

先让一个人跨岗，再减掉一半节点

王东旭的团队超过百人，覆盖产品、运营、研发、算法和测试。他们先在真实业务里试「一个人能做多少」：据财经网，一名成员 25 天内全栈交付了一个反作弊洞察平台。

但一个人变快，排期等待照旧。团队随后做了三件事，按财经网的描述是「绑目标、缩节点、搬工位」：

• 算法和工程的边界合并，前后端转全栈；
• 部分 Prompt 配置和运营交互能力交给更接近业务的运营人员；
• 产品、运营、研发、算法、测试围绕同一目标集中办公。

下表是 29 人局部试点的结果，两家媒体的写法不同，换算后一致。

指标	财经网写法	智东西写法
需求吞吐率	36% 升到 84%	提高 133%
交付周期	压到原来的五分之一	缩短 79%
全栈交付需求数	增至此前 9 倍	提高 800%

读这张表要记住，三项都是团队负责人在公司活动上的自报，分母是这 29 人覆盖的 3 个业务方向。

新增的活落到了运营和全栈工程师身上

这套安排改变的是谁做什么。运营人员接过了一部分原本归工程师的配置工作，算法和工程人员转去做更复杂的系统；会写前端又会写后端的人，成了减掉节点的前提。王东旭的原话是「全栈不是多做一份工，而是少等一个人」。

公司层面也在把单位往上挪。据证券日报的报道，快手企业智能体建设负责人沈浪说，公司目标是到 2026 年底让 80% 的线上交付需求达到人机协同的 L2 水平，目前已超过 70%，并用「词元积分制」控制预算。

财经网报道，内部已有 500 多个团队智能体、1000 多个数字员工在运行。

我们的判断是，AI 写码提速变成交付提速，靠的是减少岗位之间的交接。这是分析推断，依据是快手给出的 20% 占比和试点前后的节点数，它只在这 29 人身上被宣称过。

王东旭自己列了三类不适用的场景

有人会说，29 人试点挑的是最合适的业务和最强的人，吞吐率翻倍可能来自集中投入，而不是 AI 或节点减少本身。这个质疑我们接受一半：没有对照组，确实分不开。

王东旭本人也划了边界。据财经网，复杂的存量核心系统、强跨团队依赖、无法保证人员集中投入或缺少合适负责人的场景，现阶段都不适合这种做法。智东西还记下他的另一句判断：小团队要和大组织协作时，外部流程仍会卡住。

三件事快手没有公开：试点前后的缺陷率和线上事故数，29 人的加班时长与人员进出，接手 Prompt 配置的运营人员工作量怎么变。如果后续披露的缺陷率明显上升，或者这套做法扩到更多团队后吞吐率回落，上面的判断就要改。