作者 | 王東旭，快手磁力引擎風控技術負責人

審核 | 羅燕珊

策劃 | QCon 全球軟件開發(fā)大會

在 AIGC 技術出現(xiàn)階躍式突破、軟件工程范式從 1.0 快速邁向 3.0 的背景下，傳統(tǒng)的產品、運營、研發(fā)協(xié)作模式正在經(jīng)歷前所未有的效能考驗。本文整理自快手磁力引擎風控技術負責人王東旭在QCon 全球軟件開發(fā)大會 2026 北京站的分享《打破“人月神話”，Agent 重塑風控場景產運研職能》。

王東旭在此次分享中系統(tǒng)梳理了過去半年里團隊在大模型時代推動組織智能轉型的最新實踐。他從"AIGC 已將安全、效率、體驗的不可能三角推向極限"這一現(xiàn)實困境出發(fā)，提出固態(tài)組織必須向"液態(tài)組織"轉型：讓產品經(jīng)理用 Prompt to Product 模式直接交付原型、讓運營從配置規(guī)則表達式升級為模型教練、讓研發(fā)以 CLI 模式逃離職業(yè)階梯的中空化困局。演講后半段，他坦誠復盤了 Vibe Coding 的工程落地之坑與組織變革中的沖突教訓。

以下是演講實錄（經(jīng) InfoQ 進行不改變原意的編輯整理）。

1 AI 時代危機：被“協(xié)調稅”壓垮的傳統(tǒng)產運研模式

我所在的團隊負責整個快手商業(yè)內容安全審核和站內/聯(lián)盟廣告流量反作弊，今天的演講，會專注于內容安全這一部分，在這個每天處理上億條短視頻的場景里，我們長期面臨一個“安全、效率、體驗”的不可能三角。隨著 AIGC 技術爆發(fā)，這個三角的張力被拉到了極致。

支撐這個三角形的，是一個非常經(jīng)典的從左到右依次為運營、產品、研發(fā)的固態(tài)組織。運營負責感知和發(fā)起需求，交給產品經(jīng)理分析并產出 PRD，PRD 再由技術研發(fā)轉化為系統(tǒng)、數(shù)據(jù)或模型，最后交還給運營做線上規(guī)則配置。運營本質上就是感知業(yè)務，然后完成規(guī)則表達式的配置。在運營和產品之間、產品和技術之間，各有一條隱形的虛線，那是清晰分工之上的“部門墻”。墻的存在讓職責明確，但也讓職能變得單一且割裂。

隨著 ChatGPT 橫空出世，技術發(fā)展曲線出現(xiàn)了一個巨大的不連續(xù)斷點。AIGC 能力帶來內容量的井噴式爆發(fā)，系統(tǒng)壓力指數(shù)級上漲，同時任何人都可以輕松通過 prompt 進行圖生文、文生圖乃至圖生視頻，攻擊對抗變得空前強烈。

在這個技術躍遷面前，我們面臨一個現(xiàn)實困境：就算繼續(xù)增加團隊規(guī)模，產出也很難呈現(xiàn)老板期望的四十五度角線性增長?！度嗽律裨挕分械慕?jīng)典悖論——“一位女性懷胎十個月生一個孩子，那么十個人一個月是不是就能把孩子生出來？”——在大模型爆發(fā)的背景下變得更為尖銳。一個更深層的問題是，在大模型時代，執(zhí)行力本身已經(jīng)商品化。寫代碼變成了一件相對簡單的事，真正的困難在于跨部門之間的溝通摩擦和信息對齊。技術已經(jīng)發(fā)展得很快，但人的組織方式還沒有跟上。

這引出了 Karpathy 對軟件工程的三個階段的定義。他提出，我們正在經(jīng)歷從軟件 1.0 到 3.0 的升級轉變。1.0 是工業(yè)化分工階段，核心資產是代碼行數(shù)；2.0 是 Copilot 過渡階段，團隊關注的是模型權重；而 3.0 是 AI Native 原生階段，核心資產變成了高密度 Context 上下文。當下效能陷阱的本質，就是技術發(fā)展的速度比組織和個人的迭代速度快了半拍：技術已經(jīng)到達原生階段，但組織依舊停留在過去的范式里?；谶@一判斷，我們團隊發(fā)起了一場面向 AI 原生的組織轉型。

2 職能重塑之路：風控產運研如何構建 AI 超級組織

我們團隊有運營、產品、技術三大角色，技術側又進一步細分為算法和研發(fā)，算法包括行為概率統(tǒng)計類算法和 CV 算法，研發(fā)則包含傳統(tǒng) Java 系統(tǒng)開發(fā)和數(shù)據(jù)研發(fā)，技術團隊整體規(guī)模峰值近百人。在這次轉型中，我們的核心出發(fā)點是：每個角色都要向價值鏈的上游去做升級和轉型。

在傳統(tǒng)的固態(tài)組織下，產品、運營、研發(fā)、算法之間像磚塊一樣邊界清晰。產品只需要面向 PRD 交付產品設計原稿，研發(fā)接受 PRD 編寫代碼、交付系統(tǒng)和模型，算法則在自己的一畝三分地里不斷迭代 BERT 和 ResNet。我們想要重塑的是一種“液態(tài)組織”，一個以數(shù)據(jù)為中心、職能邊界變得非常模糊的協(xié)作網(wǎng)絡。產品和運營的同學開始能夠完成過去需要研發(fā)去承擔的工作，研發(fā)也可以向算法側延伸。原來那種成編制、成建制的師級單位，正在被類似于合成旅一樣、麻雀雖小五臟俱全的小軍團所取代。

從產品、研發(fā)和運營三個層面來看，我們都有了不同程度的實踐。在產品層，我們通過 Agent 驅動做了產品原型設計的一些 Agent，讓大模型直接出 UI 設計稿，還有需求撰寫 Agent 幫助產品經(jīng)理快速完成獨立且確定性高的產品原型設計，甚至還會讓 AI 去給產品經(jīng)理寫的 PRD 打分。在研發(fā)層，我們正在嘗試所謂的 L3 研發(fā)模式，覆蓋從需求理解到編碼、測試、運維發(fā)布的完整流程。在運營層，我特別鼓勵技術同學跳出“編碼是否更快、交付是否更強”的單一視角，去思考如何讓整個團隊創(chuàng)造更大價值。而我們在運營這一層做的事情，已經(jīng)讓運營同學的角色發(fā)生了質的躍升。

大約半年前，很多產品經(jīng)理同學還相對焦慮，因為技術同學天生離大模型更近。但最近的晉升評審給了我一個很強烈的感受，這或許可以算作一個暴論——低代碼平臺正在消亡。過去產品經(jīng)理做原型設計時，經(jīng)常會借助低代碼平臺，通過配置化、組件化拖拽來完成設計稿。但今天，每一個產品經(jīng)理都可以使用 Vibe Coding。低代碼平臺的好處是固化、可以快速出原型或 Demo，但在這個時代，它實際上是限制了優(yōu)秀產品經(jīng)理的想象力?？赏献У慕M件就那么幾個，如果你想表達天馬行空的想法，根本沒有出入口，只能“削足適履”。從與行業(yè)人士的交流來看，做低代碼平臺的團隊也都在嘗試與 AI 結合進行轉型。

我們團隊對于產品經(jīng)理的工作提出了一種新模式，叫 P2P，即 Prompt to Product，通過編寫 prompt 直接完成產品原型設計。去年下半年開始，我們大量實踐了 Figma、Lovable、Bolt.new 等 Vibe Coding 產品。產品經(jīng)理掌握了這些技能之后，某種意義上已經(jīng)可以替代部分相對低水平研發(fā)同學的工作。以我們團隊的一個技術門戶需求為例，過去產品經(jīng)理需要等研發(fā)排期，一個雙周迭代只能做二十個需求，第二十一個就會溢出。而現(xiàn)在，產品經(jīng)理可以直接在 Lovable 上通過面向瀏覽器的口令方式把需求做出來，不再需要等待研發(fā)。

從我們的視角來看，產品同學掌握這些技能后，正反兩個方向的效果都很明顯。正向是產品經(jīng)理可以幫助研發(fā)同學擋掉一些簡單需求，變成研發(fā)的“搭子”。但從另一個方向看，尤其是對于我們團隊相對年輕的研發(fā)同學，被沖擊的面非常大。當產品經(jīng)理都能搞定這些工作的時候，要那么多研發(fā)做什么？這既是好處，也蘊含著切實的危機。但無論如何，通過 P2P 這種模式，產品經(jīng)理的產能確實得到了顯著提升。

我們團隊的運營過去的工作模式是接收外部風險信號，然后在線上規(guī)則引擎里做配置。在大模型時代，這種工作的可替代性非常強，部分一線審核員實際上已經(jīng)被大模型替換掉了，這些運營人力的簡單職能被大模型取代后，還順勢完成了 AI Native 的職能升級轉型。在我們場景里，它經(jīng)歷了三個層次的變化。

第一層是 Prompt Engineer?？赡墁F(xiàn)在還有部分技術同學以能寫出一個很強的 CoT 風格的 prompt 為榮，但從去年開始，在我們團隊這件事應該是運營同學去做的。我們團隊的運營寫出的 prompt 非常厲害，不是一個簡單的一句話指令，而是帶有結構化思維鏈的。因為場景是多模態(tài)的，他們甚至能做圖文交替、模態(tài)融合的 ICoT。之所以會有這樣的轉變，是因為我們判斷運營對線上業(yè)務要比技術同學了解得更深，讓運營直接與大模型對話，把領域知識經(jīng)驗交給大模型，才是更為徹底的做法。

但僅有 Prompt Engineer 還不夠。大模型在多多少少都會出現(xiàn)幻覺問題。于是我們場景的運營同學不但要會寫 prompt，還要能把自己領域的知識，比如看健康行業(yè)或電商行業(yè)的經(jīng)驗，完整做到 RAG 知識庫里，通過線上規(guī)則的結構化、向量化，大大降低模型的幻覺問題。這就是第二層，從 Prompt 運營到 RAG 運營。

更進一步，我們在 2025 年 Q2 完全叫停了技術同學去做這些事情。第一，不要再寫 prompt；第二，RAG 運營也不是研發(fā)該干的活；第三，更激進、更極致一點，我甚至不讓算法同學再做有監(jiān)督微調 SFT。在早期這個事有護城河，但隨著技術發(fā)展，算法再去做已經(jīng)是一種低水平的重復。于是我們在 2025 年 Q3 左右，把整個模型的有監(jiān)督微調做成了一個線上化平臺，已經(jīng)有一部分能力較高的運營同學可以完成模型 pipeline 的運維，充當模型的教練。

總結下來，運營的角色變化就是從傳統(tǒng)的寫規(guī)則表達式，到成為 Prompt Engineer，再到 RAG 運營，最后到模型教練。只要你把工具做得足夠平民化、線上化、抽象得足夠好，運營就能完成這些躍遷。通過這種方式，我們團隊的運營同學完成了一個相對不錯的面向 AI 原生的轉型，我可以很確定地說，他們在市場上是非常值錢的。

大模型對研發(fā)同學的影響面可以用一條微笑曲線來描繪。曲線的橫軸是職級，從 junior 到 Staff+，縱軸是影響程度。越是資深的同學且擁抱 AI，其能力會被無限放大，對應微笑曲線右側的加持效應。但還有一部分同學，尤其是剛入場的校招生或小白，受到的沖擊是負向的，是所謂的 Danger Zone。因為他們向上卷經(jīng)驗卷不過資深同學，向下和大模型比產出速度也比不過，于是就出現(xiàn)了“職業(yè)階梯中空化”的尷尬局面。如果年輕人跟不上去，整個團隊就會面臨斷層。

要逃離 Danger Zone，就必須用 Code Agent 把自己武裝起來，讓自己成為一個小軍團。我們團隊在 2025 年到 2026 年年初這段時間，經(jīng)歷了三個階段的摸索。

第一階段是類似 Cursor 的 IDE 模式，偏向 Copilot 輔助編碼。第二階段，我們在 2025 年十一月左右推動研發(fā)同學用 Lovable 這樣面向瀏覽器對話框的方式做 Vibe Coding。但現(xiàn)在回憶起來，這個階段可能多多少少走了一點彎路，因為這種面向瀏覽器對話的方式并不太適用于技術同學，反而更適合產品、運營同學。第三階段，我們感覺走對路了，就是 CLI 模式。國外技術論壇 Latent Space 上有一個觀點叫“CLI is the future”。我自己最近一年寫代碼很多，日均 Token 消耗一億但不再用 IDE，效率很高。這是三個階段的真實心路歷程。

在具體需求承接上，我們按照顆粒度分為小、中、大三種，采取的實踐也不盡相同。小的需求，尤其是一些產品經(jīng)理就能搞定的，用 Chat 對話的方式完全沒問題，不必強行要求做 Spec-Driven Development。中等的需求，例如我們團隊數(shù)據(jù)開發(fā)同學大量用 SQL 交互交付，我們就定義了大量 Skills，通過這些 Skills 就能把事情做得相當不錯，這種場景根本用不到 Spec。只有相對大型的需求，我們才繞不開 Spec Coding。

這里需要提一個觀察。現(xiàn)在 AI 圈流行造詞，去年大家講 Prompt Engineer，現(xiàn)在講 Context Engineer、Harness Engineer。概念層出不窮，但核心并沒有太大變化。Harness 這種東西，在我看來并沒有那么神秘，無非就是 Token 消耗夠不夠多。我在團隊里會設定一個坎，每天一億 Token，這是一個相對 OK 的狀態(tài)，部分頭部研發(fā)同學消耗量還會更多，Token 消耗得多，自然就會去考慮通過各種手段約束 Coding Agent 的輸出，其實這就是一種 Harness。

我團隊還有四、五十位算法同學。在研發(fā)同學紛紛轉型算法工程的大背景下，算法同學還能有什么護城河？我們的實踐可以歸納為兩個方向：向下深耕模型能力和向前構建數(shù)據(jù)飛輪。

向下深耕的第一塊是預訓練。我們并未做大模型全模態(tài)基座的端到端預訓練，而是在 Visual Pre-training 視覺表征層，基于 SigLIP 搭建了自研的視覺對比學習方案。第二塊是 mid-training，我們依托海量圖文風控數(shù)據(jù)，在多模態(tài)大模型基座上開展領域增量續(xù)訓，而非簡單注入數(shù)據(jù)；該多模態(tài)架構參考 LLaVA / QwenVL 的多模態(tài)對齊思路，重點讓模型掌握風險識別能力。第三塊是后訓練，核心聚焦偏好對齊環(huán)節(jié)，包含兩種核心策略。第一種是 DPO 方式，依托風控場景的人工復核結果，形成 “判定偏好對”，這類天然的偏好樣本對，非常適合用于強化學習對齊。第二種是 GRPO 方式，我們團隊在該方向的相關研究成果，已被 AAAI 2026 接收錄用。今年，我團隊還將繼續(xù)在 CVPR、ECCV 等頂會發(fā)力，爭取實現(xiàn)更多技術突破。這里我想表達的是，大模型時代，即便是聚焦業(yè)務落地的團隊，也能深耕技術深度，在學術領域取得亮眼成績。

講到模型能力，就不得不提我們今年重點落地的數(shù)據(jù)飛輪體系。行業(yè)內極具參考價值的標桿便是 Scale AI，此前已被 Meta 收購。其創(chuàng)始人 Alexandr Wang 憑借成熟的數(shù)據(jù)閉環(huán)建設思路，搭建起完整高效的數(shù)據(jù)生產、篩選、迭代閉環(huán)，這也是當下大模型能力持續(xù)迭代的核心動力。

結合業(yè)務實際來看，2026 年我們在多模態(tài)大模型上的核心發(fā)力方向，除了優(yōu)化模型架構、迭代訓練策略之外，更核心的重心將全面轉向搭建適配內容安全風控場景的專屬數(shù)據(jù)飛輪，以高質量數(shù)據(jù)驅動模型能力長效進化，這套思路對于團隊技術建設與長期業(yè)務提效，都具備極強的指導意義。

除此之外，去年全年的團隊績效考核，以及近期的團隊薪酬調整，我均嚴格遵循既定原則推進。本次調整重點將各崗位 AI 能力轉型、數(shù)字化提效成效納入核心考核維度，具體標準請看圖示。

3 坑點和教訓：轉型過程，那些苦澀的記憶

過去半年多的實踐里，我們踩過三個重要的大坑。

第一個是 Vibe Coding 工程落地坑。簡單說就是“Demo 驚艷全場，生產一塌糊涂”。做 Vibe Coding 的時候，基本是想到哪兒說到哪兒，他寫到哪兒。隨著項目時間推移，上下文會腐化，本質原因是模型的注意力窗口比較小，這里面就出現(xiàn)了確定性的業(yè)務結果要求與 LLM 的概率性輸出之間的矛盾。

怎么解？我們現(xiàn)在的實踐更多是采用 Spec-Driven Development 模式，從提議到設計到 Spec 規(guī)約，再到 Coding，最后到測試，環(huán)環(huán)扣死。我們最近整理了一份 SDD 技術選型，例如 YC CEO 推的 gstack 在全局上下文方面表現(xiàn)不錯，Superpowers 已經(jīng) 150 K 的 star，相對普及度很高；Open Spec 則適合做增量項目的隔離。

第二個坑是增量和存量項目的差異。增量項目本身就沒有歷史包袱，是 AI Native 的，很 work，但存量項目極易失效。坦白說這件事我們還沒有做得特別徹底，但也在充分探索。我經(jīng)?？?Anthropic 和 OpenAI 官網(wǎng)的博客，美國的程序員同樣在探索存量項目如何演變。我有兩個觀點。第一，未來的 Git 倉庫會有很大變化，它應該是面向 AI 的，而不是面向人的，結構上大概率會包含非常非常多的 Markdown。有人調侃扎克伯格收購 Manus 就是收購了幾百萬個 Markdown，但在 AI 時代 Markdown 很值錢。第二，構建軟件仍然需要紀律，但這個紀律不在于代碼，而在于以后 Markdown 的結構。我們的嘗試可以概括為三點：一是“反向重構 Context”，因為存量代碼沒有這些東西，需要反向補上；二是補充大量的語義知識，因為 AI 缺上下文語義；三是建立嚴格的質量測試與質量門禁，生碼能力太強，但沒有人約束它。

第三個坑是團隊管理坑。去年 AICon 結束后，我回到團隊大量推組織升級，但我的問題是追求面面俱到，認為自己能做到的團隊所有人都能做到，忽略了大家時間分配、能力水平和意愿度的差異。結果十二月到年初那段時間沖突和矛盾非常多。最近一個季度的反思，我總結了三個字：試、推、升?！霸嚒笔遣灰僮非竺婷婢愕?，現(xiàn)在還不到時候。如果你的老板要求你面面俱到，你不妨把這個結論反饋給他，因為有的團隊過去半年已經(jīng)踩過大坑?！巴啤笔窃谟辛司植吭圏c成功之后，再做小范圍推廣，讓一小部分人先富起來、先信起來。作為管理者，還可以把架構做一些局部調整，讓匯報線層次不要那么深，因為我是二級主管?！吧眲t是全面重塑，我們現(xiàn)在正在從“推”到“升”的第三階段邁進。希望這個三步演進能讓更多人少踩點兒坑。

4 組織行動建議：下一步，該怎么走？

面向未來，我給出三點具體的組織行動建議。

第一點是推行 Token 經(jīng)濟學與 Skills 貢獻度考核。以后我會看兩個指標。一個是 Token ROI，分母是 Token 消耗量，我一定會看；但消耗多不代表產出多，分子還要看你通過每天消耗一億、三億 Token，對團隊的產出和貢獻到底是什么。另一個指標是 Skills 貢獻度，個人能力強不代表組織能力強。我們團隊有一個 Skills Hub，上面有排行榜，排行榜前面的同學不是被卷的，而是被激勵的。只有把個人能力注入到團隊的 Skills 體系中，組織效能才能最大化。

第二點是“逆康威定律”的應用?？低筛嬖V我們，組織架構決定系統(tǒng)架構。前面講到的運產研邊界墻就是一個典型表現(xiàn)。當大家的職能邊界被打開、組織變得更加液態(tài)的時候，系統(tǒng)的形態(tài)也會隨之改變。這是我對于組織面的一個暢想。

第三點是我個人一直踐行的一句話，叫：做“眼高手低”的技術人。“眼高”在于洞察，一定要對前沿技術知識保持想法，真的有熱愛在里頭?！笆值汀本褪鞘诌€是要低下去。我看在座很多同學都很資深，我雖然年紀不算大，但也在行業(yè)里做了十多年，我一直告訴自己手不能離開一線，每天 Token 消耗過一個億是常態(tài)。有段時間我跟團隊同學講，如果你想在 AI Coding 這個事上 diss 我，先讓 Token 消耗超過我再說。

今天 QCon 大會的主題叫“大模型，正在重新定義軟件”。而我們也在重新定義我們自己。唯一的護城河，是你和你的組織進化的速度。

作者介紹

王東旭，快手磁力引擎風控技術負責人。先后在百度、第四范式、阿里巴巴任職，專注于在商業(yè)化廣告風控領域的安全風險對抗，著有《廣告與營銷風控：方法與實踐》，主導了快手商業(yè)化廣告的 KwaiBLM 大模型審核和 AhaEdit AI 生成式修復規(guī)?；涞?，對 AI 時代組織的人機協(xié)同關系有深刻實踐和思考，曾在 AICon 2025 北京站做 AI 時代的 10x 個體和組織主題分享。

會議推薦

企業(yè)級 Agent 落地，繞不開 4 個真實的工程問題。如何在 Agent 安全性和可用性之間找到平衡點？Agent 需要什么樣的記憶系統(tǒng)才能真正理解上下文？如何通過算法壓榨實現(xiàn)智力增量與成本控制的極致平衡？多 Agent 協(xié)作，如何做到可觀測、可治理、可控制？6 月 26-27 日，AICon 全球人工智能開發(fā)與應用大會·上海站國內頭部公司的 Agent 實踐，一次說透。