Copilot和Cursor写后端代码老“一本正经”地胡说，怎么破？

这问题太真实了，我也被坑过好几回。感觉它们对热门框架的常见写法学得还行，但一旦涉及冷门参数或者新版本API，就开始一本正经地编，特别像那种“听懂了但记错了”的状态。我现在的土办法是让它先给出引用的官方文档链接或具体版本号，再让它写代码，能过滤掉一部分幻觉。另外，把报错信息直接贴回去让它自己改，有时候比让它重写一遍靠谱，但确实还是得人工把关。

这问题太真实了，我现在干脆让它先列API清单，确认存在再生成代码，不然纯属浪费时间。

把报错信息直接甩给它让它自己修，比手查文档快，但得盯着点它别又编出新花样。

我最近也踩过类似的坑，尤其是让它写一些冷门库的调用，它能把文档和记忆混在一起编出个四不像的API。后来我学乖了，凡是拿不准的库函数，先在prompt里明确让它“必须对照官方文档里真实存在的接口写”，或者直接把相关文档片段贴给它当参考，效果会好一些。另外，如果你用的是Cursor，可以试试让它先生成伪代码或调用骨架，再手动填具体实现，这样它胡编的空间能小点。不过说实话，指望它完全不犯错还是太难，关键得把“查证”这一步变成习惯，别信它最后那句“这段代码可以正常运行”。

这问题太真实了，我上周让它写个Redis连接池，直接给我整出个redis.connect_pool_async()，文档里翻半天根本没这玩意。感觉模型对主流框架的API记忆就是半桶水，风格模仿得越像越容易让人放松警惕。我现在养成的习惯是让它先只写函数签名和注释，确认调用的库方法真实存在后再让它填实现，能省不少返工。另外可以在prompt里贴官方文档片段或者明确说“只用标准库和已安装依赖”，稍微管点用。

这其实是目前大模型的通病，本质就是它在“猜”API，而不是真在查文档。我一般会直接把用到的库版本和关键方法的签名贴进prompt里，让它照着写，幻觉能少不少。另外像FastAPI这种，让它先只写路由和pydantic模型，别一上来就生成完整业务逻辑，出问题也更好定位。真要省心的话，生成完立刻跑一遍测试或者类型检查，报错再丢回去让它改，比人肉查文档快多了。