同事天天甩我AI生成的“屎山”代码？教你几招优雅拒绝并反向科普

最近在某个技术圈子里看到一个老哥吐槽：“有人天天拿 Vibe Coding 出来的代码让我修怎么办啊？” 这简直就是当代程序员的日常写照。随着 Cursor、Copilot 等智能编程助手的普及，写代码好像变得谁都能上手了，但维护代码的苦力活往往还是落在了真正的开发者头上。

今天咱们就来聊聊，当身边充斥着这种“半懂不懂”的人用 AI 生成的代码时，我们该如何应对，既能保护自己的时间，又不至于把关系搞僵。

AI 生成的代码往往逻辑混乱，难以维护

一、 为什么 AI 生成的代码容易变成“屎山”？

首先，我们要理解这种现象背后的技术原理，也就是所谓的“Vibe Coding”（氛围编程）。现在的 AI 模型确实很强大，但它的运作机制是基于概率预测下一个词。这就导致了两个明显的问题：

1. 上下文理解的局限性：AI 不理解你的业务逻辑，它只是在拼凑语法上正确的片段。一旦项目架构复杂，或者涉及特定业务规则（比如一个奇怪的折扣计算公式），AI 写出来的代码往往“看着像那么回事”，跑起来全是 Bug。
2. 依赖库和版本地狱：AI 喜欢用它训练数据里最常见的库，而且可能混用不同版本的 API。这会导致项目里充斥着冗余的依赖，甚至产生难以排查的版本冲突。

通过严格的 Code Review 流程可以有效拦截低质量代码

所以，同事扔给你的代码，往往也是从 AI 那里“复制粘贴”来的，他们自己甚至都没跑通一遍。这就好比你让一个不懂装修的人去监工，他完全照搬网上的图片，结果水电走线全乱套了，最后还得让你去拆了重装。

二、 实操指南：如何优雅地拒绝“接盘”？

直接拒绝可能会被贴上“不合群”或“不愿意分享”的标签，我们需要讲究策略。

1. 代码审查（Code Review）设为必须项

这是最正当的理由。不要直接修代码，而是在 PR（Pull Request）阶段卡住。

强制推行 Linter 和 Formatter 规范，过滤不合格代码

• 话术：“这段代码逻辑看起来有点复杂，为了项目的稳定性，我们需要先过一遍 Code Review。你看下能不能补全一下单元测试覆盖这几种边界情况？”
• 效果：把球踢回去。如果代码是 AI 写的，写代码的人通常自己也写不出测试，或者一写测试就挂，这样他自然就会意识到问题所在。

2. 让 AI “自证清白”

既然他是用 AI 写的，那就让他用 AI 去修。

• 建议：让他去提示 AI 解释代码逻辑，或者直接把报错日志喂给 AI，让 AI 给出修复方案。
• 理由：“这代码看起来是 AI 生成的风格，你试过把报错信息贴回去问问 AI 怎么改吗？通常生成它的模型最有发言权。”

3. 制定开发规范：Linter 和 Formatter 是好朋友

很多时候，AI 代码不仅逻辑乱，格式也是五花八门。在团队中强制推行代码规范工具。

• 工具推荐：ESLint、Prettier（前端），Black、Flake8（Python），Golangci-lint（Go）等。
• 操作：在 CI/CD 流程中加入强制检查，如果代码不规范或者 lint 报错，直接禁止合并。这能过滤掉一大部分连基本的代码风格都不合格的 AI 产出。

三、 长远来看：如何提升团队的“AI 素养”？

光靠堵是不行的，还得疏导。如果团队里大家都想用 AI 提效，那就要建立正确的使用姿势。

1. 强调“代码所有权”

必须明确一点：AI 是副驾驶，你是机长。

不管代码是谁写的，谁提交的谁就要负责。如果是 AI 生成的 Bug，提交者必须自己去解决，不能因为“电脑写的”就甩锅。明确责任归属，能让很多人在使用 AI 时更谨慎，而不是盲目信任。

2. 从“生成”转向“辅助”

引导同事正确使用 AI 工具。不要让 AI 直接生成整个函数或模块，而是用 AI 来写单测、重构已有代码、解释复杂的正则表达式或者生成文档。

• 例子：“别让 AI 写这个支付接口的逻辑，太危险了。你可以让它帮你把这个接口的单元测试写得全一点，看看能不能测出潜在问题。”

四、 最后的杀手锏：如果实在搞不定

如果上述方法都试过了，他还是天天甩给你“Vibe Coding”的大作，那你可能需要考虑以下几点：

• 向上管理：如果这影响了你的核心产出，客观地记录你花在“填补 AI 代码坑”上的时间，在周报或复盘会上委婉提出，过多的低质量代码修复正在拖慢项目进度。
• 技术分享：主动搞一次分享会，主题就叫“如何正确使用 AI 编程工具”或者“常见的 AI 代码陷阱”。在会上公开展示几张“典型反面教材”（注意隐去敏感信息），让大家意识到 AI 写的代码并不完美，需要人工把关。

总结

AI 时代的到来确实改变了开发模式，但万变不离其宗，代码的质量控制依然是核心。面对同事甩过来的 AI 代码，不要一味硬扛，善用流程工具（Code Review、Linter）、明确责任归属，才是解决问题的长久之道。毕竟，我们是来写逻辑搞架构的，不是来给 AI 当“垃圾分类员”的。