AI 编程工具用了一年的感受:屎山堆积-夜雨聆风

AI 编程工具用了一年的感受:屎山堆积

AI 编程工具用了一年的感受：它确实能提效，但屎山堆积严重

这一年干了不少活，把主流 AI 编程工具都深度用了一遍：Copilot、Cursor、ChatGPT、Gemini、Grok，写篇文章想聊一些真实的踩坑感受——不是唱衰 AI 编程，而是把实际问题摆出来。

核心观点：AI 编程工具是提效利器，但”自动写代码”这个说法是误导。它需要 Code Review + 自动化接口测试兜底，否则你的代码库会变成新的技术债。

一、它能做什么：重复性代码、样板生成、翻译思路

先说正向的。AI 编程工具在以下场景确实有用：

样板代码和重复性代码getter/setter、CRUD 模板、测试用例骨架，这类重复性代码 AI 生成的质量不错，省去大量机械劳动。
快速探索未知框架接手一个陌生项目时，让 AI 解释一段代码逻辑、帮忙查文档，比 Google 搜索更直接。
代码翻译把 Java 翻译成 Python、把 Python 翻译成 TypeScript，基础翻译 AI 做得不错，能省一半时间。

这些是正向的，效率提升明显。

二、它会做什么：越权插入、框架污染、屎山堆积

需要先说明的是：以下问题并非某一家 AI 编程工具特有的缺陷。这是当前 GPT 和 Gemini 驱动的 WebChat 式代码生成功能的共同问题——根源在于模型本身不了解你的系统边界，而非某家厂商的实现问题。

但以下问题是我在实际项目中真实遇到的，不是理论推演。

问题 1：AI 会在你的框架里插入业务代码

这是最严重的问题。

Copilot、Cursor，以及基于 GPT/Gemini 的各类 AI 编程工具在”辅助补全”时，不仅补全函数，还会根据它看到的上下文”推断”你应该有什么逻辑——然后直接插入。

举几个真实场景：

场景 A：插入不存在的 API 调用你写一个用户服务，AI 看到你用了某个 ORM，直接”贴心地”帮你补全了一个不存在的 user.get_permissions() 方法。这个方法看起来完全合理，但实际上你的 ORM 根本没有这个接口。代码跑通，测试没覆盖到这个分支，上线后用户权限校验静默失效。

场景 B：框架迁移时帮你”加料”把 Spring Boot 迁移到 FastAPI，让 AI 帮忙翻译代码。AI 在翻译过程中把原来 Spring 的安全配置逻辑直接”翻译”成了 FastAPI 的中间件代码——看起来是好事，但原来的安全逻辑本身就有 Bug，AI 把 Bug 也一起迁移过去了，还贴心地加了自己的”优化”。

场景 C：在数据库模型里塞业务逻辑你定义了一个数据模型，AI 看了之后觉得”这个模型应该有个计算字段”，直接在你的 model 文件里塞了一段业务计算代码。三个月后没人知道这段逻辑为什么在这里，改模型时直接踩坑。

本质问题：AI 不理解你的系统边界。它只看到上下文中的代码模式，然后”合理地”补全。它不知道什么是框架核心、什么是业务代码、什么是系统边界——它只知道”这个位置看起来应该有个函数”。

问题 2：安全漏洞会被静默引入

AI 生成的代码在安全相关场景下引入漏洞的概率，客观上高于人工代码。这不是某一家的问题，而是当前 AI 编程工具的共性。

主要问题类型：

SQL 注入：AI 生成的数据库查询字符串拼接
硬编码密钥：AI 喜欢在示例代码里写 api_key = “sk-xxxx”
未处理的异常：直接 try: except: pass，异常静默吞掉
不安全的依赖：建议使用某个有已知 CVE 的旧版包

更麻烦的是：这些漏洞在 Code Review 时不一定能看出来。因为 AI 生成的代码”看起来是对的”，格式规范，注释完整，和正常业务代码没有明显区别。安全漏洞就这样流入生产环境。

问题 3：代码屎山会在无声中积累

这是最容易被忽视的问题。

每一次”接受 AI 补全”，都在增加你代码库的熵。原因：

AI 生成的代码和原有代码风格不完全一致（变量命名、错误处理模式、日志格式）
多个人用 AI，代码风格进一步碎片化
AI 倾向于在”看起来对”的地方添加代码，不会主动删除死代码和冗余逻辑

结果：三个月后，你的代码库里会有三种不同风格的错误处理、两种不同的日志格式，以及若干”看起来对但没人知道为什么在这里”的函数。

这不是 AI 的错——是缺少系统性约束。

三、我的解法：Code Review + 自动化测试是两把锁

AI 编程工具不是问题，没有兜底的 AI 编程才是。

以下是我目前的工作流：

AI 生成 → 必须 Code Review

我给自己的硬性规则：AI 生成的代码在合并前必须经过人工 Review，Review 重点不是”代码对不对”，而是”这段代码是不是应该在这里”。

重点审查：

AI 是否在框架核心位置插入了业务代码？
是否有新的外部依赖被悄悄引入？
是否有静默吞掉异常的地方？

关键路径必须有自动化接口测试

AI 编程最怕的是”跑通但逻辑错”。单测通过不代表业务逻辑对。自动化接口测试才是验证”这个功能实际上做对了”的唯一方式。

我的要求：AI 生成的功能，必须有对应的接口测试覆盖。测试不是为了覆盖率数字，是为了确保 AI 没有”贴心地帮你改对了业务逻辑”。

护住原始需求和系统边界

每次用 AI 翻译代码或迁移框架时，我会先在文档里写清楚：

这个模块的原始需求是什么？
系统边界在哪里（哪些模块是核心，哪些是外围）？
AI 不能修改的部分是什么？

然后让 AI 在这个范围内工作。超出范围的修改，即使看起来对，也要人工确认。

四、工具选型：没有完美工具，只有合适场景

我的使用经验：

Copilot适合：补全、翻译、代码解释不适合：复杂业务逻辑生成、安全相关代码

Cursor适合：多人项目、窗口级上下文不适合：快速单文件修改（容易越权）

GPT适合：独立任务、端到端功能，实现不适合：需要精准控制边界时

Gemini适合：精修部分代码，调bug

Grok适合：非常规代码，比如爬虫类，逆向破解类

核心逻辑：越需要理解系统上下文的场景，AI 工具越容易出错。补全一行函数是安全的；生成一个完整模块是危险的。

写在最后

AI 编程工具不是洪水猛兽，但它也不是宣传片里那个”你只管提需求，代码全自动搞定”的银弹。

它真正的定位是：提效工具 + 辅助编程，而非替代编程。

接受这个定位，给它配上 Code Review 和自动化测试，它能帮你省 30% 的机械劳动时间。拒绝这个定位，直接接受所有补全，你的代码库会在半年内变成谁都不敢动的屎山。