要想彻底用大模型搞垮一个团队并非易事，不仅需要把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）

作者 | 茹炳晟; 编辑 | 虾饺

内容仅代表作者独立观点，不代表早读课立场