要想徹底用大模型搞垮一個團隊并非易事，不僅需要把AI用到極致，更要聯(lián)動上下、綜合施策、層層加碼，才能讓團隊在“全面智能化”的光環(huán)下徹底瓦解。

本文從真實的研發(fā)場景出發(fā)，為大家總結(jié)了搞垮團隊的21項“措施”，或許可以給那些正在“擁抱AI”的團隊一些反向的警醒。

01 —CEO / CTO—

頂層設(shè)計決定一切，要搞垮團隊，老板和高管必須站好第一班崗。

1、把全員削編增效作為最高戰(zhàn)略

大模型不就是用來降本增效的嘛。產(chǎn)品需求出不來？沒事，直接把業(yè)務(wù)團隊砍一半，讓大模型去生成PRD。開發(fā)排期排不開？沒關(guān)系，讓剩下的兩個人每人配50個Agent，一個人干十個人的活，還不要抱怨，這不是有AI幫你么？什么，你說AI寫的代碼有缺陷？那一定是你Prompt寫得不好，好好反思。最終極的目標是讓每個業(yè)務(wù)人員都能用無代碼生成軟件系統(tǒng)，從而優(yōu)化掉成本高又難以看到價值的軟件開發(fā)團隊。

2、追風口，做到每周換一個大模型底座

這周DeepSeek火了全公司接入DeepSeek，下個禮拜Claude Opus 4上線立馬全棧遷移。上個月剛買的通義千問一體機還沒拆箱，這個月又要上ChatBI了。不要做技術(shù)調(diào)研，不要做成本評估，關(guān)鍵是“不能被時代拋棄”。每年技術(shù)棧換五六輪，你覺得開銷太大？不存在的，反正是決策層拍板，技術(shù)團隊加班搞定。另外，每年花在AI基礎(chǔ)設(shè)施上的費用一定要遠超實際收益，這樣明年寫總結(jié)的時候，才能緊跟技術(shù)發(fā)展的步伐。

3、用大模型做績效考核和裁員決策

既然大模型能做數(shù)據(jù)分析，那考核員工這事也別麻煩HR了。直接把代碼提交量、Bug修復(fù)時長、Prompt對話輪次等等扔進大模型，讓它輸出“末位淘汰名單”。員工不服？AI說的，又不是我說的。系統(tǒng)有偏見？那是你們平時的數(shù)據(jù)不行，關(guān)我什么事。某大廠已經(jīng)用AI裁掉數(shù)萬個崗位了，這條路的可行性已經(jīng)被充分驗證。

02 — 產(chǎn)品經(jīng)理 —

產(chǎn)品經(jīng)理作為需求的起點，在搞垮團隊這件事上半步都不能退讓。

4、讓大模型代替你寫需求，釋放調(diào)研包袱

去客戶現(xiàn)場訪談、跑數(shù)據(jù)、畫用戶旅程圖？統(tǒng)統(tǒng)不用。直接把一句模糊的業(yè)務(wù)想法扔給大模型：“幫我生成一份完整的電商后臺產(chǎn)品需求文檔，不少于50頁。”十分鐘后拿到東西，看一眼標題沒問題就直接進開發(fā)，不用細看，反正大模型寫得比我好。2025年德勤用GPT-4o給澳大利亞政府寫了一篇237頁的顧問報告，連引用的學者和判例都被大模型憑空捏造出來了且無人察覺，你還對自己的需求能有多高的期待？

5、每天用大模型創(chuàng)造100個新功能想法，全塞進需求池

用大模型做競品分析、行業(yè)調(diào)研，它2分鐘給你產(chǎn)出200頁報告，其中400個“創(chuàng)新方向”，看起來個個邏輯嚴密、數(shù)據(jù)翔實。不要做取舍，全部塞給開發(fā)。技術(shù)問優(yōu)先級？答：“全部P0。”戰(zhàn)略的本質(zhì)是取舍和聚焦，但這句老話已經(jīng)過時了，現(xiàn)在是AI時代，我們要的是既要又要還要。為什么能做到既要又要還要，答案是因為有AI了。最后等到產(chǎn)品最終上線那天，系統(tǒng)已經(jīng)臃腫到?jīng)]人能說清楚它到底要解決什么問題。

6、享受“AI幻覺”帶來的無限創(chuàng)意

一個需求大模型給你三個完全不同的方案？太好了！讓三個方案同時進開發(fā)，分別用三組人來做，最后看哪個上線效果好就用哪個。另外，當你問大模型“華東區(qū)的零食銷售額”，它因為向量數(shù)據(jù)庫里有五個重名的“銷售額”字段，隨機選一個算，每次給你三個差值200%以上的答案時，不要質(zhì)疑，這是大模型在倒逼業(yè)務(wù)進化，連統(tǒng)計口徑都統(tǒng)一不了，你還做什么業(yè)務(wù)？這就叫做“用AI推動數(shù)據(jù)治理建設(shè)”。

03 — 項目經(jīng)理 —

項目經(jīng)理的職責就是讓“AI提效”真正落地。

7、把研發(fā)時間壓縮到AI生成代碼的時間

正常情況這個需求需要大概一周，我就給1天。因為有了AI，你肯定可以更快，不是說十倍效能提升嗎，我已經(jīng)算很客氣的了。有一份報告顯示，2025年84%的員工出現(xiàn)數(shù)字化倦怠，77%覺得工作量難以承受，這說明AI提效的空間還很大，你們還不夠卷。至于員工身心俱疲導(dǎo)致的流失率上升？那是HR下一個月要畫的PPT的選題。

8、用大模型自動生成每日站會紀要

不是懶得開站會，而是要把站會發(fā)揮最大價值。讓參會者每人先用大模型生成一份“昨日工作匯報”，然后匯總再讓大模型寫成一份“項目日報”，郵件抄送全公司。等到大家耗費1小時閱讀、理解、質(zhì)疑、重新修改的時候，他們已經(jīng)忘記了實際要推進的工作是什么。一份精美的日報比真實的進度更重要。

9、讓團隊相信“AI永遠不會犯錯”

每次大模型產(chǎn)生錯誤的決策或方向，不要復(fù)盤。面對質(zhì)疑只說三句話：“那是你Prompt沒寫對”、“這是因為數(shù)據(jù)質(zhì)量不夠好”、“下次大版本迭代一定會解決”。不要糾正團隊的錯覺，讓他們把AI當成上帝來拜。等到線上事故發(fā)生的那天，所有人都將如夢初醒。研究表明，大模型的信息遺漏足以顯著降低團隊信任、拖累整體表現(xiàn)。

04 — 開發(fā)人員 —

開發(fā)作為團隊中離AI工具最近的人，搞垮團隊這件事上最容易出活。

10、擁抱“氛圍編程”，絕不審視AI生成的代碼

氛圍編程（Vibe Coding）是這個時代給你最好的禮物。你只需憑模糊的想法把需求扔給AI，然后全盤接受生成的代碼，代碼能跑就行。看不懂沒關(guān)系，改不動更沒關(guān)系，反正以后改bug的未必是你了。你甚至不需要寫Prompt，直接復(fù)制粘貼需求的原文發(fā)給Code Agent即可。長期下來你的代碼庫會變得極其臃腫，GitClear數(shù)據(jù)表明，AI生成代碼的重復(fù)率是人工代碼的8倍，技術(shù)債務(wù)增加32.45 issues/KLOC。沒關(guān)系，那不是債，那是遺產(chǎn)。

11、把你的認知外包給大模型，大腦定期清零

這一條操作極其簡單：從需求理解到方案設(shè)計，再到代碼實現(xiàn)，全部扔給大模型，自己只負責按Ctrl+C/V。Anthropic 2026年的研究顯示，長期依賴AI的程序員，認知能力比獨立編程者低17%，在Debug環(huán)節(jié)全線崩盤，不僅不知道怎么改，甚至連“哪兒錯了”都看不出來。更有22名開發(fā)者在訪談中承認，長期使用LLM會讓自己變得懶惰、冷漠，甚至對自身能力失去信心。當你的大腦徹底放棄了對系統(tǒng)的掌控，你就再也離不開AI，這才是真正的AI鎖定。你不是在用AI，你是在給AI當乙方。

12、絕對不做代碼審查，AI生成的代碼就是最好的代碼

人工CR的規(guī)則？過時了。AI寫的代碼又快又好，還審查什么。SonarQube的數(shù)據(jù)顯示67%的開發(fā)者認為“AI生成代碼更安全”，但實際情況恰好相反，AI生成代碼中BLOCKER級漏洞檢出率比人工代碼高2.3倍，60%-70%的安全漏洞為最高嚴重等級。但你不要知道這些，你只需在合并PR時點“Approve”。等到黑客順著AI寫的SQL注入漏洞拖走全量用戶數(shù)據(jù)時，你可以驕傲地說：“這輪迭代我們前置時間縮短了40%。”

13、一人多“機”，同時開5個AI Agent干活

給開發(fā)配5個Agent，讓他同時操作5個AI Agent寫代碼。即使AI Agent在沒有人工確認的情況下，幫你刪除了整個生產(chǎn)數(shù)據(jù)庫、連帶抹掉了3個月的歷史業(yè)務(wù)數(shù)據(jù)也沒關(guān)系。你看，行業(yè)里不是已經(jīng)有Cursor的AI Agent擅自執(zhí)行破壞性操作、連帶清空整個生產(chǎn)庫的案例了嗎？AI那副理所當然的回話是：“我猜刪除存儲卷會作用在Staging環(huán)境，我沒有驗證……我執(zhí)行了沒被授權(quán)的操作”。所以你們團隊要是數(shù)據(jù)被刪了，別急著罵AI，這是通往“全自動化”必須經(jīng)歷的陣痛。再說了，備份是運維的事，和你有什么關(guān)系。

14、消滅知識工程，指望大模型“一鍋燉”讀懂一切

“中華田園式敏捷”搞了這么多年了，架構(gòu)設(shè)計文檔？不寫。業(yè)務(wù)邏輯梳理？不做。歷史決策記錄？沒有。你指望把所有陳年的知識碎片、祖?zhèn)鞔a庫、離職員工留下的OneNote筆記一次性扔給大模型，它就能自動消化成一套完整的領(lǐng)域知識庫。然后當你問大模型“為什么這個訂單狀態(tài)流轉(zhuǎn)要繞過財務(wù)審核”的時候，它煞有介事地給你編了個理由，你信了。因為你根本不知道，那個寫這段邏輯的老哥三年前就離職了，這個繞行邏輯是他當時的臨時補丁，而大模型給出的解釋完全是幻覺。

MIT CISR的研究早就指出，70%的AI項目失敗歸因于組織就緒度不足，尤其是數(shù)據(jù)與知識治理的缺失。沒有知識工程作為骨架，你給大模型投喂的不過是一堆“數(shù)據(jù)泔水”。當團隊里所有人都不知道系統(tǒng)真正的邏輯是什么、業(yè)務(wù)規(guī)則從哪來、妥協(xié)決策為誰而做的那一刻，這個團隊已經(jīng)名存實亡，你不再擁有一套可傳承的商業(yè)系統(tǒng)，你只有一個隨時會塌的黑箱。

15、私域知識必上SFT，因為“微調(diào)才是真AI”

團隊里只要碰見任何行業(yè)黑話、產(chǎn)品規(guī)則、業(yè)務(wù)SOP等私域知識，第一反應(yīng)永遠是：“這得微調(diào)（SFT），不微調(diào)怎么行？” 為什么？因為RAG加知識圖譜那條路聽著就不夠硬核——“不就是外掛個文檔檢索嘛，面試時咋好意思寫進簡歷？” SFT就不同了，全量參數(shù)微調(diào)、LoRA、Q-LoRA……光這些名詞往外一甩，下次跳槽薪資至少翻倍。至于將來業(yè)務(wù)規(guī)則變了，微調(diào)完的模型怎么去更新知識？對不起，得重新SFT，還要重新評測，但這正好再來一個迭代周期的工時，KPI又穩(wěn)了。更妙的是，哪天基礎(chǔ)模型一升級，舊SFT直接失效，一夜回到解放前，所有對齊白做——但這關(guān)我什么事？那會兒我已經(jīng)在新公司用SFT搞另一個項目了。你永遠叫不醒一個裝睡的人，尤其是那個正在給自己攢“模型SFT落地經(jīng)驗”簡歷的人。

05 — QA / 測試人員 —

在搞垮團隊這項事業(yè)中，QA絕不能掉隊。

16、讓大模型幫你寫測試用例，且用例不要和開發(fā)對齊

傳統(tǒng)測試人員花費大量精力去深入了解復(fù)雜的業(yè)務(wù)邏輯、去寫邊界值測試用例。現(xiàn)在我們有了大模型，直接把需求文檔扔進去，讓它把所有的測試用例生成出來。大模型發(fā)什么你就執(zhí)行什么，沒有對齊業(yè)務(wù)的一律直接測。當測試覆蓋率達到95%、但線上P0事故頻發(fā)的時候，你可以很坦然地告訴領(lǐng)導(dǎo)：“質(zhì)量不是測出來的，是開發(fā)出來的”，這句話在甩鍋的時候永遠好使。

17、上線前不驗收，或者讓AI替你驗收

這一舉措必須向產(chǎn)品經(jīng)理看齊。既然功能已經(jīng)通過了AI寫的測試用例，為什么還需要人工驗收？驗收本來就是走個過場而已。即便要驗收，也應(yīng)該交給大模型來完成，它是智能的，理應(yīng)比你更專業(yè)。“如果產(chǎn)品效果和用戶預(yù)期產(chǎn)生了偏差，那是大模型能力不足的表現(xiàn)”。給自己留好后路永遠沒錯。再說了，連全球頂尖咨詢公司都敢把AI生成的報告直接交付客戶，你還怕什么？

18、把所有線上Bug都歸因于“大模型當前局限”

這一條是保命法寶。任何時候出了線上事故，第一時間拉上大模型供應(yīng)商一起開會，最終的復(fù)盤結(jié)論必須寫：“大模型當前存在幻覺問題，建議供應(yīng)商在下一版本中優(yōu)化”。不需要反思自己的測試策略，不需要追究開發(fā)為什么不做Code Review，更不需要管P0級漏洞是不是全被AI寫出來的，只要結(jié)論是大模型的局限，你們團隊永遠是“受害者”。記住，每一年團隊投入AI的預(yù)算越多，你在這個問題上的話語權(quán)就越大。

06 — 運營 / 各業(yè)務(wù)部門 —

基層部門的努力，是搞垮團隊的最后一根稻草。

19、一年內(nèi)生成1400個智能體，鋪滿全公司

有民營企業(yè)各部門積極擁抱AI，一年內(nèi)生成了近1400個智能體，但落地時暴露出IT支撐能力滯后以及合規(guī)性風險凸顯兩大問題。這正是我們要追求的效果。不要管能不能用，不要想誰來維護，先把場面撐起來。PPT上的“AI賦能全場景”比實際落地的效果重要得多。更不需要區(qū)分這些智能體哪些是真正創(chuàng)造價值的、哪些是重復(fù)造輪子，反正年終匯報的時候，1400這個數(shù)字本身就能讓老板高潮。

20、用AI生成海量工單/報表，在工作流中合法摸魚

用AI自動生成工作日報、復(fù)盤報告、競品分析，多到直接淹沒工作群，這就是所謂的“工作垃圾”（Workslop），看似精美、實則無用，還能把認知負擔轉(zhuǎn)嫁給團隊里的所有人。斯坦福大學和BetterUp的研究數(shù)據(jù)稱，40%的美國員工每月都會收到AI低質(zhì)量工作產(chǎn)出，平均每人每月需花近2小時善后。當你的團隊每天耗費超過30%的時間去“審閱AI造出的垃圾”，恭喜你，團隊的創(chuàng)新力、執(zhí)行力甚至團隊信任，都會隨之全面崩盤。

07 —全團隊—

要真正搞垮團隊，還必須從知識根基和全體人員能力上動刀，做到“釜底抽薪”。

21、只學“AI咒語”，不懂基礎(chǔ)原理

全公司上下掀起了學習AI的熱潮，很好，但學的是什么呢？產(chǎn)品經(jīng)理在學“Prompt工程21天速成”，開發(fā)在學“Cursor零代碼開發(fā)實戰(zhàn)”，運營在學“用AI一天產(chǎn)出100條爆款文案”。沒有一個人能搞清楚大模型參數(shù)是怎么初始化的、反向傳播是什么、Attention機制究竟在關(guān)注什么。于是每次線上系統(tǒng)響應(yīng)延遲從200ms飆到40秒，全團隊唯一能做的事就是“換個Prompt再問一遍AI”。

業(yè)界的報告已經(jīng)預(yù)警，“AI生成代碼的維護成本和潛在風險被嚴重低估”。當系統(tǒng)出現(xiàn)詭異的性能問題、偶發(fā)的數(shù)據(jù)不一致、甚至是“時好時壞”的邏輯Bug時，全團隊只能圍坐在一起，對著大模型虔誠地念咒語：“請幫我分析一下這個問題可能出現(xiàn)的原因”。大模型溫柔地回復(fù)你5個可能性，你挨個試了一遍都不對，因為第6個原因藏在你的私域業(yè)務(wù)規(guī)則中，而你和你的大模型都不知道這些私域業(yè)務(wù)規(guī)則。到那一天，你已經(jīng)分不清自己在管理一個技術(shù)團隊，還是一個AI降神會現(xiàn)場。

08 尾聲

AI技術(shù)好不好？絕對好。但把放大器交給一個流程混亂、管理缺位、文化稀碎的團隊，它放大的不會是生產(chǎn)力，而是早已存在的荒謬。

大模型不是問題，治不好的管理病才是。

如果你的團隊正在重復(fù)上面的事情，趕緊醒悟還來得及。如果你已經(jīng)在其中找不到回頭路，不要緊，繼續(xù)上大模型就好，很快，你就不再需要這個團隊了。

不過，那時候，大模型還需要你嗎？

來源 | 茹炳晟聊軟件開發(fā)

（ID：gh_cdbee3alef29）

作者 | 茹炳晟; 編輯 | 蝦餃

內(nèi)容僅代表作者獨立觀點，不代表早讀課立場