一、提示词太「糊」：AI 根本不知道你在干嘛

上周末我用 Cursor 写一个自动整理桌面文件的脚本，因为懒得多打字，就丢了一句「帮我写个整理文件的程序」。结果 AI 给我来了个几十行的 Shell 脚本，用 mv 命令按后缀名分类。但我是 Windows 用户啊！代码直接跑不了，我对着 PowerShell 一顿改，比手写还累。这就是典型「提示词模糊」的坑。后来我改成「在 Windows 上用 Python，把桌面所有文件名带日期的 .xlsx 文件按月份移到 D:\Monthly\ 下，用 pathlib 库」，两分钟就拿到可用的代码，一次跑通。

解决方案其实就三点：第一，明确编程语言和环境。比如「Python 3.12 + Flask + SQLite」比「做个 Web 应用」强一百倍。第二，给出输入输出示例。我最近用 Claude 3.5 Sonnet（月费 20 美元）写 API 接口，直接贴一段 JSON 请求和高亮预期的返回结构，返回来代码几乎不用改。第三，限定库的版本。比如「用 pandas 2.0+ 的 read_excel 而不是 xlrd」，因为 2024 年 xlrd 已经不支持 .xlsx 了，AI 很容易踩这种坑。

我还在 GitHub 上看到一个哥们儿，用 GPT-4o（每百万输入 token 5 美元）写自动发邮件的脚本，提示词只写了「发邮件」，结果模型用了 SMTP 的废弃端口 25，导致公司邮件服务器把他 IP 封了。后来他加了一句「使用端口 587 和 TLS 加密」，问题瞬间解决。这个案例说明：AI 不是读心术，你给的信息越具体，它犯错的空间就越小。下次写提示词时，多花 30 秒把上下文补全，能省你半小时调试的时间。

二、过度信任 AI 代码：自己不动脑子，后患无穷

今年 3 月，我用 GitHub Copilot（月费 10 美元）写一个用户注册功能，它很快给我生成了密码哈希的代码。我瞥了一眼，看到 hashlib.md5 就直接用了。上线第二天，安全检测工具就报「使用了不安全的哈希算法 MD5」。我赶紧换成 bcrypt 并重新发版，但用户密码已经暴露的风险让我提心吊胆了两周。这个教训让我明白：AI 生成的代码不一定安全，尤其在安全、并发、边界条件这些地方，它经常抄到过时的最佳实践。

具体怎么做？首先，对 AI 输出的每一行代码都要「怀疑一分钟」。我自己的习惯是：先扫一眼有没有硬编码的 API Key，有没有 SQL 拼接（我用 GPT-4o 写 Python 时它居然给了我一个 f"SELECT * FROM users WHERE id={user_id}"，这要是直接上线就完蛋了）。其次，关键逻辑手动跑一下单元测试。比如用 pytest 写个简单断言，丢给 Copilot 让它自己生成测试用例——但测试结果必须你自己看。最后，定期更新自己的知识库。AI 模型训练数据可能滞后，比如 2024 年 5 月之后发布的 Python 3.13 新特性，Claude Opus 就经常说错。

我朋友圈有个后端大佬，用 Cursor Pro（月费 20 美元）做支付接口，AI 生成了 decimal.Decimal 来处理金额，但忘了设置 context.prec=10，导致小数点后的精度被截断，对账差了 0.03 元。虽然金额不大，但在金融场景里这是原则性错误。他后来在提示词里加了一句「用 decimal 并设置精度为 28」，并且手动验证了三笔交易。记住：AI 是助手不是专家，最终代码质量的责任在你身上。

三、上下文断掉：AI 忘了三分钟前说过什么

我曾在一次项目中用 ChatGPT 4 写一个多线程下载器，分了 5 次对话来分别生成「下载核心」「任务队列」「进度显示」「异常处理」「日志记录」。前四个片段各自跑得不错，但组合到一起后，线程间共享变量冲突、函数命名不一致、日志格式不统一，简直像四段不同的人写的代码拼在一起。这就是典型的「上下文断裂」问题。AI 模型（尤其对话窗口有限时）很容易丢失早期的约定，比如变量命名风格、函数参数顺序、异常类型定义。

解决办法其实很简单：尽量在一个对话里完成整个模块。如果窗口太长，可以用一个「上下文总结」技巧——每生成一段后，主动让 AI 用自然语言提炼当前的设计决策，比如「我们定义了 Downloader 类，使用 ThreadPoolExecutor，最大线程数 4，重试机制为指数退避」。然后把这段总结粘贴到下一次对话的开头。我实测过，用这种方法，Claude 3.5 Sonnet 在生成长度超过 2000 行的项目时，重复错误率从 70% 降到了 15%。

另一个好用的是「回引用」技巧。在提示词里加上类似「请参照我们之前第 3 个回复中定义的 connect_db() 函数的参数签名来设计新函数」。如果不放心，还可以手动把关键代码片段提前写进系统提示词。我用 Cursor 的 Rule 功能（项目根目录下建 .cursorrules 文件）把约定写死，比如「变量命名用 snake_case」「所有异常都继承自定义的 AppError 类」。这样每次生成新代码都会被这些规则约束，上下文自然就接上了。

四、盲目复制粘贴：AI 代码和你的环境水土不服

去年 12 月，我从 Stack Overflow 上找了个用 GPT-4 生成的 Docker 配置，直接复制到我的项目里。结果 ChatGPT 给的 Dockerfile 是基于 Ubuntu 22.04 的，而我的生产环境是 Alpine Linux，导致好几个包安装失败。更糟的是，它用了一个只有 Python 3.10 才支持的语法 match-case，而我的项目还在用 3.9。那次我花了整整一个下午来排查环境依赖问题，最后发现只是少了个 FROM python:3.11-slim 的声明。从那以后，我再也不直接复制粘贴 AI 输出的整段配置或脚本了。

正确姿势是：先确认自己的环境版本再问。比如你要写一个 Node.js 后端，先在提示词里标明「Node 18 + Express 4.18 + MongoDB 7，运行在 AWS Lambda 上」。然后让 AI 分步生成：先建依赖的 package.json，再写入口文件，最后写路由。每步检查是否有 require 的模块在你的锁文件中存在。我自己会用 npx create-project 快速搭建模板，再让 AI 做增量修改，这样环境依赖从根上就是对齐的。

另一个常见的坑是 AI 生成的代码依赖了不存在的库版本。比如它写 pip install requests==3.0，但 PyPI 上最新版还是 2.31。或者它让你用 npm install left-pad@1.0.0，但这个版本早就 deprecated 了。我统计过自己用 GPT-4o 生成的 50 次代码片段，其中有 8 次依赖版本号错误，占 16%。所以每次 AI 给出 requirements.txt 或 package.json 后，我都会先跑一遍 pip check 或 npm audit，确保依赖没有冲突。如果项目比较重要，我甚至会用 Docker 构建个干净的镜像来测试一次。虽然多了几步，但远比上线后炸掉要划算。

💬 你用过哪些AI工具？

聊了这么多坑，其实我最想说的是：得有人帮咱们把这些 AI 工具的真实表现晒出来。我每次犹豫要不要买 Copilot 或者升级 Claude Pro 时，都特别想知道其他开发者怎么评价。最近发现一个挺靠谱的榜单——AI House 排行榜（aibunkhouse.com/rankings/），上面有实时更新的编程类 AI 模型投票和评分，数据比什么「年度最佳」实在多了。比如 Cursor、GitHub Copilot、CodeWhisperer 这些，用户会直接标注「代码质量」「上下文理解」「错误率」等维度，比官方宣传可信 10 倍。

你要是有用着顺手或者踩过坑的 AI 编程工具，去给它们投个票吧。我昨天刚看到 Qwen2.5-Coder 在个人开发者里评价不错，但本地部署的配置要求被不少人吐槽。你的一个投票可能让更多人避开我犯过的这些错误。对了，投票完还能看到详细的用户评价，比如「GPT-4o 在生成 Python 正则时容易漏边界条件」「Claude Opus 对 C++ 模板理解很强但生成代码偏长」。去翻翻，说不定能帮你下次选工具省下好几百美元呢。