在 AIGC 技术出现阶跃式突破、软件工程范式从 1.0 快速迈向 3.0 的背景下，传统的产品、运营、研发协作模式正在经历前所未有的效能考验。本文整理自快手磁力引擎风控技术负责人王东旭在 QCon 全球软件开发大会 2026 北京站的分享《打破“人月神话”，Agent 重塑风控场景产运研职能》。
王东旭在此次分享中系统梳理了过去半年里团队在大模型时代推动组织智能转型的最新实践。他从"AIGC 已将安全、效率、体验的不可能三角推向极限"这一现实困境出发，提出固态组织必须向"液态组织"转型：让产品经理用 Prompt to Product 模式直接交付原型、让运营从配置规则表达式升级为模型教练、让研发以 CLI 模式逃离职业阶梯的中空化困局。演讲后半段，他坦诚复盘了 Vibe Coding 的工程落地之坑与组织变革中的冲突教训。
以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。
我所在的团队负责整个快手商业内容安全审核和站内/联盟广告流量反作弊，今天的演讲，会专注于内容安全这一部分，在这个每天处理上亿条短视频的场景里，我们长期面临一个“安全、效率、体验”的不可能三角。随着 AIGC 技术爆发，这个三角的张力被拉到了极致。
支撑这个三角形的，是一个非常经典的从左到右依次为运营、产品、研发的固态组织。运营负责感知和发起需求，交给产品经理分析并产出 PRD，PRD 再由技术研发转化为系统、数据或模型，最后交还给运营做线上规则配置。运营本质上就是感知业务，然后完成规则表达式的配置。在运营和产品之间、产品和技术之间，各有一条隐形的虚线，那是清晰分工之上的“部门墙”。墙的存在让职责明确，但也让职能变得单一且割裂。
随着 ChatGPT 横空出世，技术发展曲线出现了一个巨大的不连续断点。AIGC 能力带来内容量的井喷式爆发，系统压力指数级上涨，同时任何人都可以轻松通过 prompt 进行图生文、文生图乃至图生视频，攻击对抗变得空前强烈。
在这个技术跃迁面前，我们面临一个现实困境：就算继续增加团队规模，产出也很难呈现老板期望的四十五度角线性增长。《人月神话》中的经典悖论——“一位女性怀胎十个月生一个孩子，那么十个人一个月是不是就能把孩子生出来？”——在大模型爆发的背景下变得更为尖锐。一个更深层的问题是，在大模型时代，执行力本身已经商品化。写代码变成了一件相对简单的事，真正的困难在于跨部门之间的沟通摩擦和信息对齐。技术已经发展得很快，但人的组织方式还没有跟上。
这引出了 Karpathy 对软件工程的三个阶段的定义。他提出，我们正在经历从软件 1.0 到 3.0 的升级转变。1.0 是工业化分工阶段，核心资产是代码行数；2.0 是 Copilot 过渡阶段，团队关注的是模型权重；而 3.0 是 AI Native 原生阶段，核心资产变成了高密度 Context 上下文。当下效能陷阱的本质，就是技术发展的速度比组织和个人的迭代速度快了半拍：技术已经到达原生阶段，但组织依旧停留在过去的范式里。基于这一判断，我们团队发起了一场面向 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 非常厉害，不是一个简单的一句话指令，而是带有结构化思维链的。因为场景是多模态的，他们甚至能做图文交替、模态融合的 ICoT。之所以会有这样的转变，是因为我们判断运营对线上业务要比技术同学了解得更深，让运营直接与大模型对话，把领域知识经验交给大模型，才是更为彻底的做法。
但仅有 Prompt Engineer 还不够。大模型在多多少少都会出现幻觉问题。于是我们场景的运营同学不但要会写 prompt，还要能把自己领域的知识，比如看健康行业或电商行业的经验，完整做到 RAG 知识库里，通过线上规则的结构化、向量化，大大降低模型的幻觉问题。这就是第二层，从 Prompt 运营到 RAG 运营。
更进一步，我们在 2025 年 Q2 完全叫停了技术同学去做这些事情。第一，不要再写 prompt；第二，RAG 运营也不是研发该干的活；第三，更激进、更极致一点，我甚至不让算法同学再做有监督微调 SFT。在早期这个事有护城河，但随着技术发展，算法再去做已经是一种低水平的重复。于是我们在 2025 年 Q3 左右，把整个模型的有监督微调做成了一个线上化平台，已经有一部分能力较高的运营同学可以完成模型 pipeline 的运维，充当模型的教练。
总结下来，运营的角色变化就是从传统的写规则表达式，到成为 Prompt Engineer，再到 RAG 运营，最后到模型教练。只要你把工具做得足够平民化、线上化、抽象得足够好，运营就能完成这些跃迁。通过这种方式，我们团队的运营同学完成了一个相对不错的面向 AI 原生的转型，我可以很确定地说，他们在市场上是非常值钱的。
大模型对研发同学的影响面可以用一条微笑曲线来描绘。曲线的横轴是职级，从 junior 到 Staff+，纵轴是影响程度。越是资深的同学且拥抱 AI，其能力会被无限放大，对应微笑曲线右侧的加持效应。但还有一部分同学，尤其是刚入场的校招生或小白，受到的冲击是负向的，是所谓的 Danger Zone。因为他们向上卷经验卷不过资深同学，向下和大模型比产出速度也比不过，于是就出现了“职业阶梯中空化”的尴尬局面。如果年轻人跟不上去，整个团队就会面临断层。
要逃离 Danger Zone，就必须用 Code Agent 把自己武装起来，让自己成为一个小军团。我们团队在 2025 年到 2026 年年初这段时间，经历了三个阶段的摸索。
第一阶段是类似 Cursor 的 IDE 模式，偏向 Copilot 辅助编码。第二阶段，我们在 2025 年十一月左右推动研发同学用 Lovable 这样面向浏览器对话框的方式做 Vibe Coding。但现在回忆起来，这个阶段可能多多少少走了一点弯路，因为这种面向浏览器对话的方式并不太适用于技术同学，反而更适合产品、运营同学。第三阶段，我们感觉走对路了，就是 CLI 模式。国外技术论坛 Latent Space 上有一个观点叫“CLI is the future”。我自己最近一年写代码很多，日均 Token 消耗一亿但不再用 IDE，效率很高。这是三个阶段的真实心路历程。
在具体需求承接上，我们按照颗粒度分为小、中、大三种，采取的实践也不尽相同。小的需求，尤其是一些产品经理就能搞定的，用 Chat 对话的方式完全没问题，不必强行要求做 Spec-Driven Development。中等的需求，例如我们团队数据开发同学大量用 SQL 交互交付，我们就定义了大量 Skills，通过这些 Skills 就能把事情做得相当不错，这种场景根本用不到 Spec。只有相对大型的需求，我们才绕不开 Spec Coding。
这里需要提一个观察。现在 AI 圈流行造词，去年大家讲 Prompt Engineer，现在讲 Context Engineer、Harness Engineer。概念层出不穷，但核心并没有太大变化。Harness 这种东西，在我看来并没有那么神秘，无非就是 Token 消耗够不够多。我在团队里会设定一个坎，每天一亿 Token，这是一个相对 OK 的状态，部分头部研发同学消耗量还会更多，Token 消耗得多，自然就会去考虑通过各种手段约束 Coding Agent 的输出，其实这就是一种 Harness。
我团队还有四、五十位算法同学。在研发同学纷纷转型算法工程的大背景下，算法同学还能有什么护城河？我们的实践可以归纳为两个方向：向下深耕模型能力和向前构建数据飞轮。
向下深耕的第一块是预训练。我们并未做大模型全模态基座的端到端预训练，而是在 Visual Pre-training 视觉表征层，基于 SigLIP 搭建了自研的视觉对比学习方案。第二块是 mid-training，我们依托海量图文风控数据，在多模态大模型基座上开展领域增量续训，而非简单注入数据；该多模态架构参考 LLaVA / QwenVL 的多模态对齐思路，重点让模型掌握风险识别能力。第三块是后训练，核心聚焦偏好对齐环节，包含两种核心策略。第一种是 DPO 方式，依托风控场景的人工复核结果，形成 “判定偏好对”，这类天然的偏好样本对，非常适合用于强化学习对齐。第二种是 GRPO 方式，我们团队在该方向的相关研究成果，已被 AAAI 2026 接收录用。今年，我团队还将继续在 CVPR、ECCV 等顶会发力，争取实现更多技术突破。这里我想表达的是，大模型时代，即便是聚焦业务落地的团队，也能深耕技术深度，在学术领域取得亮眼成绩。
讲到模型能力，就不得不提我们今年重点落地的数据飞轮体系。行业内极具参考价值的标杆便是 Scale AI，此前已被 Meta 收购。其创始人 Alexandr Wang 凭借成熟的数据闭环建设思路，搭建起完整高效的数据生产、筛选、迭代闭环，这也是当下大模型能力持续迭代的核心动力。
结合业务实际来看，2026 年我们在多模态大模型上的核心发力方向，除了优化模型架构、迭代训练策略之外，更核心的重心将全面转向搭建适配内容安全风控场景的专属数据飞轮，以高质量数据驱动模型能力长效进化，这套思路对于团队技术建设与长期业务提效，都具备极强的指导意义。
除此之外，去年全年的团队绩效考核，以及近期的团队薪酬调整，我均严格遵循既定原则推进。本次调整重点将各岗位 AI 能力转型、数字化提效成效纳入核心考核维度，具体标准请看图示。
过去半年多的实践里，我们踩过三个重要的大坑。
第一个是 Vibe Coding 工程落地坑。简单说就是“Demo 惊艳全场，生产一塌糊涂”。做 Vibe Coding 的时候，基本是想到哪儿说到哪儿，他写到哪儿。随着项目时间推移，上下文会腐化，本质原因是模型的注意力窗口比较小，这里面就出现了确定性的业务结果要求与 LLM 的概率性输出之间的矛盾。
怎么解？我们现在的实践更多是采用 Spec-Driven Development 模式，从提议到设计到 Spec 规约，再到 Coding，最后到测试，环环扣死。我们最近整理了一份 SDD 技术选型，例如 YC CEO 推的 gstack 在全局上下文方面表现不错，Superpowers 已经 150 K 的 star，相对普及度很高；Open Spec 则适合做增量项目的隔离。
第二个坑是增量和存量项目的差异。增量项目本身就没有历史包袱，是 AI Native 的，很 work，但存量项目极易失效。坦白说这件事我们还没有做得特别彻底，但也在充分探索。我经常看 Anthropic 和 OpenAI 官网的博客，美国的程序员同样在探索存量项目如何演变。我有两个观点。第一，未来的 Git 仓库会有很大变化，它应该是面向 AI 的，而不是面向人的，结构上大概率会包含非常非常多的 Markdown。有人调侃扎克伯格收购 Manus 就是收购了几百万个 Markdown，但在 AI 时代 Markdown 很值钱。第二，构建软件仍然需要纪律，但这个纪律不在于代码，而在于以后 Markdown 的结构。我们的尝试可以概括为三点：一是“反向重构 Context”，因为存量代码没有这些东西，需要反向补上；二是补充大量的语义知识，因为 AI 缺上下文语义；三是建立严格的质量测试与质量门禁，生码能力太强，但没有人约束它。
第三个坑是团队管理坑。去年 AICon 结束后，我回到团队大量推组织升级，但我的问题是追求面面俱到，认为自己能做到的团队所有人都能做到，忽略了大家时间分配、能力水平和意愿度的差异。结果十二月到年初那段时间冲突和矛盾非常多。最近一个季度的反思，我总结了三个字：试、推、升。“试”是不要再追求面面俱到，现在还不到时候。如果你的老板要求你面面俱到，你不妨把这个结论反馈给他，因为有的团队过去半年已经踩过大坑。“推”是在有了局部试点成功之后，再做小范围推广，让一小部分人先富起来、先信起来。作为管理者，还可以把架构做一些局部调整，让汇报线层次不要那么深，因为我是二级主管。“升”则是全面重塑，我们现在正在从“推”到“升”的第三阶段迈进。希望这个三步演进能让更多人少踩点儿坑。
面向未来，我给出三点具体的组织行动建议。
第一点是推行 Token 经济学与 Skills 贡献度考核。以后我会看两个指标。一个是 Token ROI，分母是 Token 消耗量，我一定会看；但消耗多不代表产出多，分子还要看你通过每天消耗一亿、三亿 Token，对团队的产出和贡献到底是什么。另一个指标是 Skills 贡献度，个人能力强不代表组织能力强。我们团队有一个 Skills Hub，上面有排行榜，排行榜前面的同学不是被卷的，而是被激励的。只有把个人能力注入到团队的 Skills 体系中，组织效能才能最大化。
第二点是“逆康威定律”的应用。康威定律告诉我们，组织架构决定系统架构。前面讲到的运产研边界墙就是一个典型表现。当大家的职能边界被打开、组织变得更加液态的时候，系统的形态也会随之改变。这是我对于组织面的一个畅想。
第三点是我个人一直践行的一句话，叫：做“眼高手低”的技术人。“眼高”在于洞察，一定要对前沿技术知识保持想法，真的有热爱在里头。“手低”就是手还是要低下去。我看在座很多同学都很资深，我虽然年纪不算大，但也在行业里做了十多年，我一直告诉自己手不能离开一线，每天 Token 消耗过一个亿是常态。有段时间我跟团队同学讲，如果你想在 AI Coding 这个事上 diss 我，先让 Token 消耗超过我再说。
今天 QCon 大会的主题叫“大模型，正在重新定义软件”。而我们也在重新定义我们自己。唯一的护城河，是你和你的组织进化的速度。
作者介绍
王东旭，快手磁力引擎风控技术负责人。先后在百度、第四范式、阿里巴巴任职，专注于在商业化广告风控领域的安全风险对抗，著有《广告与营销风控：方法与实践》，主导了快手商业化广告的 KwaiBLM 大模型审核和 AhaEdit AI 生成式修复规模化落地，对 AI 时代组织的人机协同关系有深刻实践和思考，曾在 AICon 2025 北京站做 AI 时代的 10x 个体和组织主题分享。
会议推荐
6 月 26-27 日，AICon上海站即将开幕！60 + 顶尖专家携一线实战案例齐聚，聚焦构建可信赖、可规模化、可商业化的 Agentic 工程实践，一站式打通 AI 工程化卡点、从源头避坑！欢迎报名咨询👇
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。