周末听了一下午快手关于企业 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，如果一项工作需要调用多个系统，涉及不同部门的权限和数据，依然会遇到很多问题。