从个人提效到组织变革，快手重构企业AI生产力
来源：界面新闻
沈浪没想到，他和团队推动为工程师打造的AI编程工具，却吸引了越来越多不写代码的同事使用。
作为快手企业智能体建设负责人、企业AI生产力专家，沈浪团队推动这套工具建设的出发点，是希望借助AI重构软件研发流程。2025年，快手围绕本地AI Coding工具CodeFlicker和云端研发平台KATE，将需求分析、CI/CD、Code Review、测试用例编写、线上监控等环节逐步Agent化，试图让AI从辅助编程走向独立承担部分研发任务。
但在工具逐步成熟的过程中，越来越多非技术员工也开始使用CodeFlicker来制作演示文稿、开展调研、分析数据，甚至完成一些与编程毫无关系的工作。
在他看来，这是员工用脚投票：相比传统工具，能够理解需求、调用能力并完成任务的交互方式，更符合同事们对AI的期待。
2026年3月，快手开始将编程助手与Work形态的产品整合，打造面向全员的通用Agent MyFlicker，并于5月正式发布。AI的应用边界由研发部门扩展至整个组织。
然而，让所有人都能用上AI，只是第一步。当使用规模迅速扩大，Token成本、员工使用习惯、岗位分工和组织协作方式等问题接踵而至。
10月31日，在快手技术沙龙第六期上，沈浪分享了快手通过建设AI生产力工具的全过程。从一个编程助手意外破圈，到一套企业级AI生产力体系逐渐成形，快手试图探索的，已经不只是如何让员工借助AI提升个人效率，而是如何让AI真正成为组织生产力的一部分。
快手开始意识到，企业AI生产力建设不能停留在工具层面，还需要一套与之匹配的成本机制、人才培养体系和组织架构。今年2月，快手将研发效能中心升级为AI生产力中心，将原本用于研发工具建设的资源大幅转向公共AI基础设施。
这背后，是企业AI应用正在经历的一次转变：当AI从少数人的效率工具变成全员都能调用的生产力，真正的考验就不再是工具本身有多强，而是企业能否建立一套新的运行机制，让分散在员工手中的AI能力转化为整个组织的效率。
快手的探索，也正是从这里开始深入。
从个体到团队：先蒸馏，再折叠
当产品服务的用户越来越多之后，成本问题立刻浮现。
沈浪并没有因为 CodeFlicker 的用户量大涨而感到高兴。按照传统的成本分摊机制， AI 工具产生的 Token 费用需要摊给各个业务线。这意味着，工具建设团队不仅要负责把产品做好，还要不断向业务部门解释和分摊成本。“相当于我要把工具回头卖给每个业务 线。”
快手最终选择用 Token 积分制解决这个问题：将 AI 预算折算成积分，下发给每一位员工，由员工自主决定如何使用 AI 。这样一来，工具建设团队不必再为成本分摊分心，可以专注于产品建设和员工培训；员工则第一次真正意识到，调用 AI 并不是没有成本的。
年初时，快手员工的习惯是哪怕问天气预报也要选最好的模型。积分制推行后，员工开始根据任务复杂程度选择模型和消耗额度。在他看来，这套机制是让企业 AI 生产力体系得以运行的看得见的手。
解决了成本问题，接下来要解决的是使用门槛。快手从一些鼓励员工探索 AI 应用的活动中找到了方法。
今年年中，快手连续举办了“ AI 蹭饭研判官”“ AI 贪吃蛇大赛”“ PDE 集结令”等多场活动。其中，不少非技术员工训练出来的 AI 贪吃蛇甚至击败了技术人员。今年 8 月，这些活动演化成了新人入职的必做的训练，考察的不是编程能力，而是员工能否真正驾驭 AI 。其中， PDE 集结令最终收到 4000 余个作品，验证了非技术人群构建工具的可能性。
但当 AI 从个人工具走向全员普及，另一个问题也逐渐显现：个人效率提高了，并不意味着团队效率就会同步提升。
沈浪在年中复盘时发现，公司内部出现了两种现象。一种是孤岛区，即少数 AI 能力较强的员工已经探索出高效的工作方法，但经验停留在个人手中，无法复制给其他人；另一种是空转区，一些团队引入了大量数字员工，却因为上下游协作缺乏完整的业务上下文，数字员工之间难以有效配合，最终并没有带来预期的效率提升。
这意味着，企业 AI 生产力建设需要跨过一道新的门槛：从让员工各自用好 AI ，转向让 AI 真正融入团队协作。沈浪将快手在这一阶段摸索出的核心方法概括为“先蒸馏，再折叠”。
蒸馏是先把团队中优秀员工的经验、知识和工作方法沉淀下来，转化为 AI 能够理解和调用的知识库、 Skill 与工作流，让原本依赖个人经验的能力变成团队共享的资产。折叠 则是在此基础上引入数字员工，接手团队中重复性、确定性较高的工作，重新组织人与 AI 之间的分工，让人更多聚焦于创造性和高价值任务。
这套思路也推动 MyFlicker 从个人助手向团队 Agent 升级。通过 MyFlicker 2.0 ，员工可以围绕团队业务搭建专属 Agent ，让 AI 不再只是某个人的效率外挂，而是成为团队工作流程中的一员。
目前，快手内部已经有 500 多个团队 Agent 、 1000 多个数字员工在独立工作，覆盖技术、销售、设计等几乎所有团队。
然而，问题并没有就此结束。沈浪发现，这些 Agent 更像是散落在公司各处的卫星，各自在团队内部运转，却还没有真正连接成一张网络。要让 AI 从团队成员变成组织能力，快手还需要找到下一步的答案。
快手探索组织变革新模式
沈浪发现，当 500 多个团队 Agent 、 1000 多个数字员工开始在快手内部独立工作时，
团队内部的知识、工作流和工具可以被 AI 调用，一旦涉及跨团队协作，信息仍然分散在各自的系统里，原本需要人来协调的工作，并不会因为多了几个 Agent 就自动消失。
这让快手开始把视线从团队进一步推向组织。 为此，快手在组织层面 有 了一个 更为 具体动作：成立企业 AI 生产力组织 iWork ，负责基础办公系统基座的稳定运行，统筹通用 Agent 、企业上下文体系和企业信息系统的统一建设。
快手企业 AI 生产力副总裁王诩在开场分享中，把 AI 进入企业的过程概括为四个阶段：先在部分领域鼓励实践，再把跑通的经验沉淀为产品和工具，进而调整岗位分工，最后自上而下推动组织变革。 iWork 的成立，正是第四阶段的落点。
在沈浪看来，组织本身也可以被看作一个更大规模的 Agent 。它和团队 Agent 的逻辑相似，只是涉及的业务范围更广、系统更多、协作关系也更复杂。
比如，一个销售组织或 HR 组织，内部不仅有大量岗位和人员，还连接着不同的业务系统、数据、文档和工作流程。要让 AI 真正进入这样的组织，就不能只给每个员工配置一 个助手，而需要把整个组织的知识和工作流沉淀下来。
基于对组织关系更为深入的理解，快手进一步探索出了 MyFlicker 3.0 。相比此前的版本， MyFlicker 3.0 增加了一个 AI 工作台。
在沈浪看来，当公司内部越来越多的系统被接入 MyFlicker ，传统的对话交互已经不足以承载复杂的组织工作。员工需要的不只是向 AI 提问，还需要 AI 能够理解企业上下文、调用不同系统，并在多个工作环节之间持续执行任务。
围绕这一目标，快手正在探索一套企业级 AI 架构：最底层是 AgentOS ，负责记忆、模型调度以及云端和本地引擎；上面是企业资产层，将行政、会议、研发等传统工具转化为 Skill 和 CLI ，让 Agent 能够直接调用；再往上，则是企业 AI 知识库，把代码、数据、流程和文档等分散的信息汇总起来，转化为 AI 能够理解和使用的结构化知识。
这套架构试图解决的，是组织规模扩大之后， AI 如何获得完整的企业上下文，以及如何跨越不同系统和团队执行任务。
随着全新的产品和 AI 架构在快手各个业务应用，一些非常明显的变化正在具体业务团队内部发生。
王东旭是快手磁力引擎风控技术负责人，他所在的团队超过百人，涵盖产品、运营、研发、算法和测试等多个职能。
在 AI 带来的效率变化中，王东旭很快发现，超级个体并不能自动解决团队的协作问题。他所在团队开始推动岗位边界融合。部分 Prompt 配置、交互式运营等工作被交给更接近业务的运营人员，算法和工程人员则将精力转向复杂算法与系统架构。过去必须经过多个专业角色才能完成的工作，开始由一个人或一个小团队端到端推进。
再往后，团队又尝试引入洛克希德·马丁著名的“臭鼬工厂”模式，将产品、运营、研发、算法和测试人员围绕同一个业务目标集中起来，通过缩短协作链条减少等待。他们将需求流转节点从 12 个压缩至 6 个。在一项局部试点中， 29 名成员覆盖 3 个业务方向，需求吞吐率从 36% 提升至 84% ，需求交付周期缩短至原来的五分之一。
他用阿姆达尔定律解释这一现象：如果编码只占端到端交付时间的 20% ，即使编码效率提升到极致，整个交付周期的改善也十分有限。“全栈不是多做一份工，而是少等一个人。”
但这种模式也有边界。王东旭特别提醒，臭鼬工厂并不适合所有场景，尤其是涉及复杂存量系统、强跨团队依赖的业务。当一个团队需要依赖大量外部部门才能完成交付时，原本被压缩的内部流程，可能又会被外部依赖堵住。
这也说明， AI 带来的组织变革并不是简单地把人变成全栈工程师，或者把所有工作交给 Agent ，而是重新审视工作如何分配、经验如何流动，以及不同团队之间如何协作。
从个人能力的释放，到团队工作流的重组，再到企业级知识、系统和组织架构的整合，快手正在尝试把 AI 从一个个独立的效率工具，变成能够参与组织运转的基础设施。
沈浪表示，快手的组织提效模式还不是一套已经完全成熟的解决方案，公司还将进一步探索。
当 AI 大规模应用，质量由谁来守？
当AI开始大规模参与代码编写，还有一些新的问题接踵而至。
其中，各个业务团队面临的一个共性问题就是，代码可以由AI生成，测试用例可以由AI编写，甚至质量评估也可以交给AI，谁来保证最终交付的东西是对的？
在传统研发流程中，测试产能高度依赖人力，人工回归和个人经验是质量保障的重要支撑。但AI让代码产出速度大幅提升后，质量验证却没有同步跟上。更棘手的是，AI生成的缺陷不一定表现为明显的错误，有些结果看起来正确，却在业务语义上存在问题。
为此，快手开始重新设计质量体系。快手磁力引擎风控质量负责人吕冬冬在沙龙现场分享时表示，其所在团队将需求按照风险分为高、中、低三个等级：涉及资金、安全和核心业务链路的高风险需求，仍由人工主导验收；中风险需求采用人机协同；而在风控业务中约六成的低风险需求，则交由AI承担更多验证工作，人工只负责抽检和异常升级。
但当测试也交给AI，另一个更棘手的问题出现了：如果写代码、写测试用例、判断测试结果的都是Agent，测试通过究竟意味着产品真的没有问题，还是AI只是在用自己的逻辑证明自己正确？
吕冬冬将其称为“AI测AI”的同源风险。为此，团队开始引入不同模型分工，建立来自真实业务的固定评测集和黄金真值，并把测试推理过程拆成结构化步骤，确保出现问题时能够追溯和纠偏。
这也改变了测试工程师的工作重心。过去，他们更多承担用例编写、测试执行和缺陷归因。未来，这些工作将逐步由Agent接手，而人需要负责制定质量规则、判断业务风险，并对最终发版承担责任。
质量岗位的变化，只是AI重塑软件工程师职业分工的一个缩影。软件工程学者朱少民认为，只会写代码的码农可能逐渐失去竞争力，但软件工程师不会消失，业务理解、架构设计和质量判断等能力反而更加重要。王东旭则提醒，AI可能带来职业阶梯的中空化：既缺乏领域经验、又没有足够学习动力的人，可能受到更大冲击。
沈浪分享了一个设计团队的案例：一名负责人将团队的设计经验全部沉淀为Skill，原本需要大量人力完成的工作，后来只需要5%至10%的人力维护。但团队并没有因此缩编，其他成员转而投入多模态模型美学评估、公司级设计基础设施建设，甚至开始自己设计产品、编写代码。
几位嘉宾的共识是，AI替代了一部分工作，却也让同一批人有机会承担更多新的工作。
这也是快手这场组织变革最终要回答的问题：当AI不断接管执行环节，人和组织真正需要建立的，不是与机器竞争的速度，而是持续重新定义自身价值的能力。
正如王东旭在分享中所说，大模型正在重新定义软件，人也正在重新定义自己，“AI时代，职场人唯一的护城河，是你和你的组织进化的速度”。