今年听过最好的 AI Native 思考，真诚又足够接地气。

周末听了一下午快手关于企业 AI 生产力的技术沙龙，收获非常大。

它虽然从 AI Coding 谈起，但最后讨论的其实是一个更大的问题：当每个人都开始用 AI，企业的工作流、团队协作和组织机制，应该怎么接住这种变化？

先分享几个我的一手笔记。

1、个人提效和组织提效是两回事。

2、AI Coding 的下一步，应该是重新设计软件交付流程。

3、需要有意识地把员工的经验沉淀成 AI 能调用的资产。

4、AI 生成代码越来越快，质量保障可能成为新的瓶颈。

5、建设统一的 AI 基础设施。现在开发 Agent 越来越容易，每个部门都可能自己开发一套。随之而来的，就是重复建设、Token 成本，以及安全和权限管理等问题。

公司需要有一套公共基础设施，让大家复用已有的能力。

6、组织结构也需要调整。

这几个点，我觉得无论对于大公司，还是我们这样的小团队，都非常有参考价值。

快手企业智能体建设负责人、企业AI生产力专家沈浪把快手的企业AI生产力实践概括为四个阶段：

AI 先进入研发环节，解决工程师提效；随后扩展到更多员工；再从个人使用走向团队AI，把专业经验和工作流沉淀为共享能力；目前则刚刚开启组织AI的探索。

这条路径的变化很清楚：AI 的使用范围越来越大，但要解决的问题，也从一个人怎么用好工具，逐步变成一个团队乃至一个组织，怎么重新设计自己的运行方式。

这也是我听完整场分享之后，感受最深的一点。

#01

先蒸馏，再折叠

我最近对个人提效不等于组织提效这件事感触特别深。

现在我们团队基本人人都在用 AI，效率确实提高了不少。但作为一个小老板，我没有明显感觉到整个公司的经营效率有什么大变化。

前段时间，我听其他企业的朋友聊过类似问题。他们发现，随着越来越多的员工开始使用 AI，虽然工具使用数据非常漂亮，但很多团队的整体效率并没有达到预期。

快手在过去两年的实践中也观察到一些问题，总结下来主要有两类。

一类叫孤岛区。

大概情况是团队中有几个特别厉害的 AI 高手，他们积累了很多 Skill、知识和工作方法，但这些经验其他同事没法直接复用，结果是少数人越来越强，团队整体的工作方式却没有明显变化。

这玩意我倒是理解，我们团队也有类似的情况，AI 虽然门槛已经很低了，但具体到个体上，还是有的人用的特别好，用的人用的稀烂。差距简直一个天上，一个地下。

典型的二八定律。

另一种叫空转区。

有些团队部署了很多 Agent。结果这些 Agent 需要不断协调、交换上下文，甚至还不如一个通用Agent调用Skill的效果好。

Agent 数量多，也不代表团队效率高，很多 Agent 在那空转严重，消耗 Token。

那怎么办？

快手在大量实践之后，总结出了一套方法，叫先蒸馏，再折叠。

所谓蒸馏，其实就是把员工积累的专业经验、知识和工作方法，沉淀成团队可以共享的 Skill、知识库和工作流。

比如，设计师把设计规范和判断标准沉淀成 Skill，产品经理就可以借助 AI 完成一部分基础设计；研发把常用的工程方法沉淀下来，其他角色也可以在明确边界内完成一些简单、低风险的交付。

这样，过去需要不同岗位接力完成的工作，现在可能一个人借助 AI 就能完成。原来的岗位分工，也就有机会重新调整。这就是折叠。

基于这套思路，他们开始把整个团队理解成一个 Agent，让团队成员共享知识、Skill、工具和工作流。

但这里的顺序很重要。

不是先要求产品学前端、前端学后端，更不是先取消岗位，而是先把不同角色的专业经验变成团队可以调用的能力，再判断哪些等待、交接和分工可以被重新设计。

基于这套思路，快手开始把整个团队理解成一个 Agent。团队成员共享知识、Skill、工具和工作流，数字员工也可以在明确边界内承担一部分工作。

这个视角对中小公司同样有启发：真正重要的，不是公司里有多少人会用 AI，而是少数人的好经验，能不能变成整个团队的公共能力。

#02

调整团队的协作模式

现场快手磁力引擎风控技术负责人王东旭把这个问题讲得更具体。

这是一个超过百人，涵盖前端、后端、算法、数据工程等不同岗位的复杂团队。

他们最初也是推广 AI Coding，后来开始推动前后端融合，甚至在一个季度内，把团队的基础全栈覆盖率提升到了 100%。

但即便如此，需求依然在积压。产品经理觉得研发交付太慢，研发又觉得产品需求不清楚、排期不合理，双方仍然会产生摩擦。

为什么会这样？

因为写代码只是整个软件交付流程的一部分。假设编码环节占整个软件交付流程的 20%，AI Coding 可以让编码效率提高了 10 倍。

那么整个软件交付流程的效率，实际上只能提高大约 22%。

这就是阿姆达尔定律。

哎，你想想，写代码都快了 10 倍，最后需求交付只快了 22%，是不是挺让人揪心。

即便产品、设计、研发、测试都用上了 AI，各自的工作效率都提高了，整个交付流程依然可能很慢。

毕竟大家还是按照原来的岗位分工协作。产品提出需求，然后研发排期，开发完成后再交给测试。每个环节都可能需要沟通、交接和等待。

这些 Gap，并不会因为每个人都用上了 AI 就自动消失。

于是，他们开始尝试臭鼬工厂的组织模式。

感觉这个模式很像亚马逊的双披萨团队。

其实就是围绕一个明确的业务目标，把产品、研发、算法、测试等不同岗位的人组织成一个小团队，给他们充分的自主权，让团队自己负责整个需求交付。

最近我听 Google 的播客，他们内部也在推行这样的组织模式，就把团队继续拆小，然后让大家快速迭代，像实验室一样。

快手的磁力引擎风控把一部分团队打散为小团队后，把大家工位都搬到了一起。这样有什么问题直接商量，绝大部分事情都不用再跨部门反复协调和排期。

而且，他们团队内部的岗位分工也已经变了。一些简单、低风险的需求，产品经理自己就能搞定，研发只需要负责必要的技术支持和把关就行。

这样调整之后，他们团队的需求吞吐量提升了 130%，需求交付周期缩短了 80%。

需要说明下，这种模式也有适用范围。复杂的存量核心系统、涉及资金安全或者曾经发生过重大故障的业务，肯定还不适合这样干。

#03

质量保证是瓶颈

需求吞吐量上来之后，随之而来的问题是，当越来越多的人能够借助 AI 直接完成需求，甚至不再需要经过原来完整的研发流程时，团队必须清楚，哪些需求可以放心交给 AI，哪些必须经过严格的人工验证。

要不然，很容易带来严重的安全问题。尤其是现在 AI 生成代码越来越快，代码提交越来越频繁，很多变更的影响范围也变得更难判断。

如果所有需求仍然按照过去的方式进行人工测试，测试工程师根本忙不过来。但如果为了速度，直接跳过测试，风险又太大。

快手磁力引擎风控质量负责人吕冬冬的做法，是建立一套 AI 智能分级体系。

简单理解，就是让 Agent 结合 PRD、代码变更、历史故障和业务知识，分析一个需求可能存在哪些风险，再决定采用什么测试方式。

他们把需求分成了高、中、低三个风险等级。

比如涉及核心业务、资金安全、权限管理的高风险需求，仍然由人工主导测试，AI 辅助分析。

中风险需求由人工和 AI 协同完成。

对于一些简单的页面调整、交互优化等低风险需求，则主要交给 AI 自动验证，人工负责抽检。

吕冬冬介绍，在他负责的业务中，大约 60% 的需求属于低风险需求。

这意味着，相当一部分需求可以通过 AI Testing 完成验证，不需要再排队等待测试工程师逐个处理。

而且，他们还把接口测试、UI 自动化、流量回放等能力整合起来，让 Agent 根据需求的风险等级，调用相应的测试工具完成验证。

不过，这套方法有一个重要前提，就是 AI 的风险判断必须足够准确。

比如，一个需求看起来只是修改了页面展示，但实际上影响了某个核心业务。如果 AI 错误地把它归为低风险需求，就可能漏掉重要的测试。

所以，他们建立了一套标准评测集。

先让熟悉业务的专家对真实需求进行风险标注，形成一批有标准答案的样本。

之后每次调整模型或者提示词，都要用这套评测集重新验证准确率。如果发现 AI 判断错了，就由人工分析原因，再把错误案例和纠正记录沉淀到知识库中，完善风险判断规则。

这样一来，AI 可以不断参考过去的业务经验，提高后续风险判断的准确性。

但风险等级判断准确了，测试本身就一定可靠吗？

现在很多代码是 AI 写的，测试用例也是 AI 生成的。如果连最后的测试结论都交给 AI，会不会出现自己出题、自己答题、自己判卷的情况？

万一 AI 写的代码存在问题，生成的测试用例又恰好漏掉了这个问题，最后还告诉你测试通过了，那就麻烦了。

针对这个问题，他们也采取了一些措施。

比如，把负责开发和测试的模型分开，降低两边出现相同判断盲区的风险。

同时，保留标准评测样本和必要的人工验证。对于高风险需求，AI 可以辅助完成风险分析和测试，但最后是否允许上线，仍然需要人工判断。

截至当时，他们开展的低风险需求自助上线实践，还没有出现遗漏。不过，这套体系目前是在所属大部门使用，还没有推广到整个快手。

我觉得这套实践还有一个很重要的启发，就是质量工程师的工作也在发生变化。

过去，他们需要花大量时间编写测试用例、执行测试、复现 Bug。

现在这些工作越来越多地可以交给 Agent，而人需要把更多精力放到业务风险判断、测试策略制定，以及最后的质量验收上。

你看，前面臭鼬工厂调整了产品、研发之间的协作方式，现在连测试和质量保障的方法也开始发生变化。

这也让我更加确信，AI Coding 下一步最值得做的事情，就是重新设计整个软件交付流程。过去不同岗位之间的分工、交接、验收方式，都有机会重新调整。

只有这样，整个软件交付流程才有机会真正提速。

#04

自上而下是必要的

但如果把这些实践放到整个公司，事情又复杂了很多。

快手有几万名员工，每个部门都在使用 AI，也都在积累自己的 Skill、知识库和工作流。

比如，一个大型 HR 组织可能有几百名员工，涉及招聘、绩效、薪酬等不同业务，背后还有二三十套系统。

即便每个团队都有自己的 Agent，如果一项工作需要调用多个系统，涉及不同部门的权限和数据，依然会遇到很多问题。

还有重复建设的问题。

现在开发 Agent 越来越容易，每个部门都可能自己搞一套。但如果底层的模型调用、知识管理、权限、安全等能力都要各自建设，成本肯定会越来越高。

所以，快手最近成立了企业 AI 生产力组织 iWork，开始从公司层面整合这些能力。

比如，把内部的业务系统逐步改造成 Agent 能调用的工具，让不同部门可以复用不同的 Skill。

当然，这些事情还在探索中。

另外，我觉得快手在 Token 成本管理上也有一个很聪明的设计。

他们推出了一套 Agent 积分制，把 AI 预算分配给不同业务线，再转换成员工可以使用的积分。

员工可以根据任务选择模型，也能更直观地看到 Token 消耗；平台团队则可以把更多精力放在工具建设、能力复用和实际效果上。

这个设计很聪明。Token 不应该是一笔糊涂账，但成本管理也不能只靠限制使用，而要让每个团队逐步建立投入产出意识。

记得现场还有一句话，让我印象特别深刻。企业 AI 生产力体系和 Harness 的作用，其实有很多相似之处。

大家可以想想，为什么大模型需要 Harness？

因为模型本身再聪明，也未必了解你的项目架构、编码规范，不知道哪些操作有风险，哪些测试必须通过。

所以需要 Harness 给 AI 提供项目上下文、工具、执行规则和质量验证机制，让 Agent 能够更稳定地完成任务。

如果把这个视角从单个 Agent 扩大到整个公司，其实也是一样的道理。

每个部门都有自己的业务系统、知识和工作流程，再加上 Token 成本、权限、安全，以及不同团队之间的协作问题，这些事情显然不可能只靠更强大的模型来解决。

企业同样需要一套组织层面的 Harness，通过统一的基础设施、知识管理、工作流程和组织机制，让 AI 能够在整个公司里真正发挥作用。

而这套体系，显然需要公司自上而下地规划。

快手前几个阶段依靠先锋员工和业务团队先行试验；当实践进入跨团队复用、企业上下文、权限、安全和成本治理后，才需要公司级统筹。

自下而上负责验证有效路径，自上而下负责把局部经验沉淀成公共能力。

目前，组织 AI 仍然处于探索阶段。这个分寸反而让我觉得更真实：没有人已经拿到了企业 AI 转型的标准答案，大家都在用局部试点逐步验证边界。

#05

写在最后

对于我自己的公司，我现在也有几个比较明确的想法。

1、团队要小，创业公司也许可以激进地分为两人一组。

2、Token 的消耗不应该是笔糊涂账，应该从公司视角看看 Token 的效率。

3、Skill 的共享和管理应该尽快提上日程。

4、考虑做公司层面的 Agent 知识库。

5、做需求的风险评级，基于此来确定后面的验证策略。

6、质量保证这块，做一个独立的 Agent。

还有很重要的一点，接下来衡量 AI 带来的变化，应该更多从公司的整体经营效率出发，不能只看每个人使用 AI 的数据。

我的小破公司，在听完这次分享之后，确实还有很多事情要做。

恰好年底，我最近正在思考明年的公司战略。这次快手的分享，给了我不少新的启发。下面是视频回放，喜欢的同学可以看看。

有类似感触的同学，咱们评论区交流。

文章来自于"AI产品阿颖"，作者 "阿颖"。