打破“人月神话”，Agent 重塑风控场景产运研职能

在 AIGC 技术出现阶跃式突破、软件工程范式从 1.0 快速迈向 3.0 的背景下，传统的产品、运营、研发协作模式正在经历前所未有的效能考验。本文整理自快手磁力引擎风控技术负责人王东旭在 QCon 全球软件开发大会 2026 北京站的分享《打破“人月神话”，Agent 重塑风控场景产运研职能》。 王东旭在此次分享中系统梳理了过去半年里团队在大模型时代推动组织智能转型的最新实践。他从"AIGC 已将安全、效率、体验的不可能三角推向极限"这一现实困境出发，提出固态组织必须向"液态组织"转型：让产品经理用 Prompt to Product模式直接交付原型、让运营从配置规则表达式升级为模型教练、让研发以 CLI 模式逃离职业阶梯的中空化困局。演讲后半段，他坦诚复盘了 Vibe Coding 的工程落地之坑与组织变革中的冲突教训。 以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。 AI时代危机：被“协调税”压垮的传统产运研模式 我所在的团队负责整个快手商业内容安全审核和站内/联盟广告流量反作弊，今天的演讲，会专注于内容安全这一部分，在这个每天处理上亿条短视频的场景里，我们长期面临一个“安全、效率、体验”的不可能三角。随着 AIGC 技术爆发，这个三角的张力被拉到了极致。 支撑这个三角形的，是一个非常经典的从左到右依次为运营、产品、研发的固态组织。运营负责感知和发起需求，交给产品经理分析并产出 PRD，PRD 再由技术研发转化为系统、数据或模型，最后交还给运营做线上规则配置。运营本质上就是感知业务，然后完成规则表达式的配置。在运营和产品之间、产品和技术之间，各有一条隐形的虚线，那是清晰分工之上的“部门墙”。墙的存在让职责明确，但也让职能变得单一且割裂。 随着ChatGPT 横空出世，技术发展曲线出现了一个巨大的不连续断点。AIGC 能力带来内容量的井喷式爆发，系统压力指数级上涨，同时任何人都可以轻松通过 prompt 进行图生文、文生图乃至图生视频，攻击对抗变得空前强烈。 在这个技术跃迁面前，我们面临一个现实困境：就算继续增加团队规模，产出也很难呈现老板期望的四十五度角线性增长。《人月神话》中的经典悖论——“一位女性怀胎十个月生一个孩子，那么十个人一个月是不是就能把孩子生出来？”——在大模型爆发的背景下变得更为尖锐。一个更深层的问题是，在大模型时代，执行力本身已经商品化。写代码变成了一件相对简单的事，真正的困难在于跨部门之间的沟通摩擦和信息对齐。技术已经发展得很快，但人的组织方式还没有跟上。 这引出了 Karpathy 对软件工程的三个阶段的定义。他提出，我们正在经历从软件 1.0 到 3.0 的升级转变。1.0 是工业化分工阶段，核心资产是代码行数；2.0 是 Copilot 过渡阶段，团队关注的是模型权重；而 3.0 是 AI Native 原生阶段，核心资产变成了高密度 Context 上下文。当下效能陷阱的本质，就是技术发展的速度比组织和个人的迭代速度快了半拍：技术已经到达原生阶段，但组织依旧停留在过去的范式里。基于这一判断，我们团队发起了一场面向 AI 原生的组织转型。 职能重塑之路：风控产运研如何构建AI超级组织 我们团队有运营、产品、技术三大角色，技术侧又进一步细分为算法和研发，算法包括行为概率统计类算法和 CV 算法，研发则包含传统 Java 系统开发和数据研发，技术团队整体规模峰值近百人。在这次转型中，我们的核心出发点是：每个角色都要向价值链的上游去做升级和转型。 在传统的固态组织下，产品、运营、研发、算法之间像砖块一样边界清晰。产品只需要面向 PRD 交付产品设计原稿，研发接受 PRD 编写代码、交付系统和模型，算法则在自己的一亩三分地里不断迭代 BERT 和 ResNet。我们想要重塑的是一种“液态组织”，一个以数据为中心、职能边界变得非常模糊的协作网络。产品和运营的同学开始能够完成过去需要研发去承担的工作，研发也可以向算法侧延伸。原来那种成编制、成建制的师级单位，正在被类似于合成旅一样、麻雀虽小五脏俱全的小军团所取代。 从产品、研发和运营三个层面来看，我们都有了不同程度的实践。在产品层，我们通过 Agent 驱动做了产品原型设计的一些 Agent，让大模型直接出 UI 设计稿，还有需求撰写 Agent 帮助产品经理快速完成独立且确定性高的产品原型设计，甚至还会让 AI 去给产品经理写的 PRD 打分。在研发层，我们正在尝试所谓的 L3 研发模式，覆盖从需求理解到编码、测试、运维发布的完整流程。在运营层，我特别鼓励技术同学跳出“编码是否更快、交付是否更强”的单一视角，去思考如何让整个团队创造更大价值。而我们在运营这一层做的事情，已经让运营同学的角色发生了质的跃升。 大约半年前，很多产品经理同学还相对焦虑，因为技术同学天生离大模型更近。但最近的晋升评审给了我一个很强烈的感受，这或许可以算作一个暴论——低代码平台正在消亡。过去产品经理做原型设计时，经常会借助低代码平台，通过配置化、组件化拖拽来完成设计稿。但今天，每一个产品经理都可以使用 Vibe Coding。低代码平台的好处是固化、可以快速出原型或 Demo，但在这个时代，它实际上是限制了优秀产品经理的想象力。可拖拽的组件就那么几个，如果你想表达天马行空的想法，根本没有出入口，只能“削足适履”。从与行业人士的交流来看，做低代码平台的团队也都在尝试与 AI 结合进行转型。 我们团队对于产品经理的工作提出了一种新模式，叫 P2P，即 Prompt to Product，通过编写 prompt 直接完成产品原型设计。去年下半年开始，我们大量实践了 Figma、Lovable、Bolt.new 等 Vibe Coding 产品。产品经理掌握了这些技能之后，某种意义上已经可以替代部分相对低水平研发同学的工作。以我们团队的一个技术门户需求为例，过去产品经理需要等研发排期，一个双周迭代只能做二十个需求，第二十一个就会溢出。而现在，产品经理可以直接在 Lovable 上通过面向浏览器的口令方式把需求做出来，不再需要等待研发。 从我们的视角来看，产品同学掌握这些技能后，正反两个方向的效果都很明显。正向是产品经理可以帮助研发同学挡掉一些简单需求，变成研发的“搭子”。但从另一个方向看，尤其是对于我们团队相对年轻的研发同学，被冲击的面非常大。当产品经理都能搞定这些工作的时候，要那么多研发做什么？这既是好处，也蕴含着切实的危机。但无论如何，通过 P2P 这种模式，产品经理的产能确实得到了显著提升。 我们团队的运营过去的工作模式是接收外部风险信号，然后在线上规则引擎里做配置。在大模型时代，这种工作的可替代性非常强，部分一线审核员实际上已经被大模型替换掉了，这些运营人力的简单职能被大模型取代后，还顺势完成了AI Native的职能升级转型。在我们场景里，它经历了三个层次的变化。 第一层是 Prompt Engineer。可能现在还有部分技术同学以能写出一个很强的 CoT 风格的 prompt 为荣，但从去年开始，在我们团队这件事应该是运营同学去做的。我们团队的运营写出的 prompt 非常厉害，不是一个简单的一句话指令，而是带有结构化思维链的