如何用大模型搞垮一個團隊？

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

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

01 —CEO / CTO—

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

1、把全員削編增效作為最高戰略

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

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

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

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

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

02 — 產品經理 —

產品經理作為需求的起點，在搞垮團隊這件事上半步都不能退讓。

4、讓大模型代替你寫需求，釋放調研包袱

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

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

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

6、享受“AI幻覺”帶來的無限創意

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

03 — 項目經理 —

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

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

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

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

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

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

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

04 — 開發人員 —

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

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

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

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

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

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

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

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

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

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

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

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

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

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

05 — QA / 測試人員 —

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

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

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

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

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

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

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

06 — 運營 / 各業務部門 —

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

19、一年內生成1400個智能體，鋪滿全公司

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

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

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

07 —全團隊—

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

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

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

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

08 尾聲

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

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

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

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

來源 | 茹炳晟聊軟件開發

（ID：gh_cdbee3alef29）

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

內容僅代表作者獨立觀點，不代表早讀課立場