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

本文来自微信公众号： InfoQ ，作者：QCon

1AI时代危机：被“协调税”压垮的传统产运研模式

我所在的团队负责整个快手商业内容安全审核和站内/联盟广告流量反作弊，今天的演讲，会专注于内容安全这一部分，在这个每天处理上亿条短视频的场景里，我们长期面临一个“安全、效率、体验”的不可能三角。随着AIGC技术爆发，这个三角的张力被拉到了极致。

支撑这个三角形的，是一个非常经典的从左到右依次为运营、产品、研发的固态组织。运营负责感知和发起需求，交给产品经理分析并产出PRD，PRD再由技术研发转化为系统、数据或模型，最后交还给运营做线上规则配置。运营本质上就是感知业务，然后完成规则表达式的配置。在运营和产品之间、产品和技术之间，各有一条隐形的虚线，那是清晰分工之上的“部门墙”。墙的存在让职责明确，但也让职能变得单一且割裂。

随着ChatGPT横空出世，技术发展曲线出现了一个巨大的不连续断点。AIGC能力带来内容量的井喷式爆发，系统压力指数级上涨，同时任何人都可以轻松通过prompt进行图生文、文生图乃至图生视频，攻击对抗变得空前强烈。

在这个技术跃迁面前，我们面临一个现实困境：就算继续增加团队规模，产出也很难呈现老板期望的四十五度角线性增长。《人月神话》中的经典悖论——“一位女性怀胎十个月生一个孩子，那么十个人一个月是不是就能把孩子生出来？”——在大模型爆发的背景下变得更为尖锐。一个更深层的问题是，在大模型时代，执行力本身已经商品化。写代码变成了一件相对简单的事，真正的困难在于跨部门之间的沟通摩擦和信息对齐。技术已经发展得很快，但人的组织方式还没有跟上。

这引出了Karpathy对软件工程的三个阶段的定义。他提出，我们正在经历从软件1.0到3.0的升级转变。1.0是工业化分工阶段，核心资产是代码行数；2.0是Copilot过渡阶段，团队关注的是模型权重；而3.0是AI Native原生阶段，核心资产变成了高密度Context上下文。当下效能陷阱的本质，就是技术发展的速度比组织和个人的迭代速度快了半拍：技术已经到达原生阶段，但组织依旧停留在过去的范式里。基于这一判断，我们团队发起了一场面向AI原生的组织转型。

2职能重塑之路：风控产运研如何构建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能力转型、数字化提效成效纳入核心考核维度，具体标准请看图示。

3坑点和教训：转型过程，那些苦涩的记忆

过去半年多的实践里，我们踩过三个重要的大坑。

第一个是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结束后，我回到团队大量推组织升级，但我的问题是追求面面俱到，认为自己能做到的团队所有人都能做到，忽略了大家时间分配、能力水平和意愿度的差异。结果十二月到年初那段时间冲突和矛盾非常多。最近一个季度的反思，我总结了三个字：试、推、升。“试”是不要再追求面面俱到，现在还不到时候。如果你的老板要求你面面俱到，你不妨把这个结论反馈给他，因为有的团队过去半年已经踩过大坑。“推”是在有了局部试点成功之后，再做小范围推广，让一小部分人先富起来、先信起来。作为管理者，还可以把架构做一些局部调整，让汇报线层次不要那么深，因为我是二级主管。“升”则是全面重塑，我们现在正在从“推”到“升”的第三阶段迈进。希望这个三步演进能让更多人少踩点儿坑。

4组织行动建议：下一步，该怎么走？

面向未来，我给出三点具体的组织行动建议。

第一点是推行Token经济学与Skills贡献度考核。以后我会看两个指标。一个是Token ROI，分母是Token消耗量，我一定会看；但消耗多不代表产出多，分子还要看你通过每天消耗一亿、三亿Token，对团队的产出和贡献到底是什么。另一个指标是Skills贡献度，个人能力强不代表组织能力强。我们团队有一个Skills Hub，上面有排行榜，排行榜前面的同学不是被卷的，而是被激励的。只有把个人能力注入到团队的Skills体系中，组织效能才能最大化。

第二点是“逆康威定律”的应用。康威定律告诉我们，组织架构决定系统架构。前面讲到的运产研边界墙就是一个典型表现。当大家的职能边界被打开、组织变得更加液态的时候，系统的形态也会随之改变。这是我对于组织面的一个畅想。

第三点是我个人一直践行的一句话，叫：做“眼高手低”的技术人。“眼高”在于洞察，一定要对前沿技术知识保持想法，真的有热爱在里头。“手低”就是手还是要低下去。我看在座很多同学都很资深，我虽然年纪不算大，但也在行业里做了十多年，我一直告诉自己手不能离开一线，每天Token消耗过一个亿是常态。有段时间我跟团队同学讲，如果你想在AI Coding这个事上diss我，先让Token消耗超过我再说。

今天QCon大会的主题叫“大模型，正在重新定义软件”。而我们也在重新定义我们自己。唯一的护城河，是你和你的组织进化的速度。