Copilot和Cursor都用过了，为什么感觉AI写代码还是不太靠谱？

说实话你这个问题我太有共鸣了，我拿Cursor试过几次中型服务拆分，结果它把整个项目的依赖关系彻底搞混，生成的代码里甚至出现了两个不同版本的同一个工具类，我最后花了两天清理它的“杰作”。我觉得核心问题不是prompt写法，而是这些模型对“现有架构”的感知其实非常浅层，它们更像是在做高频模式拼接，而不是真正理解业务约束。你提到的事务函数，我猜它看到“数据库”就自动脑补了一堆常见但未必存在的表和缓存逻辑，本质上是把训练数据里的通用套路硬套上来。我现在的用法是把它当成一个超级聪明的结对程序员，只让它写清楚边界的小函数或者帮我生成测试数据，涉及到跨模块改动时，我会先把关键的接口定义和异常处理写成注释喂给它，让它在这个“笼子”里发挥。至于中型项目重构，我试过唯一算成功的一次，是把重构拆成十几个极其细小的步骤，每一步都验证通过再让它继续，但说实话那效率也没比手写高多少，可能AI离“靠谱”还差一个能真正跑通代码并理解业务语义的验证层吧。

本质就是高级补全，别指望它理解业务，把大任务拆成小函数喂给它的成功率会高很多。

试试把项目结构和相关代码贴进prompt里当上下文，再限定它别加东西，我这么干之后幻觉少了不少。

说实话你的体验挺典型的，我拿它们搞中型项目重构也翻过车，后来发现关键是得把大任务拆成“带明确输入输出的小步骤”喂给它们，尤其要把现有表结构和事务边界写进上下文里，不然它只能靠猜。另外我试过让AI先写个重构方案让我审，再动手写代码，会稳很多，但最终业务逻辑还是得自己把关。你这感觉不奇怪，工具目前更像高级结对程序员，没法替代你对架构的掌控。

我也有同感，尤其是让它改老代码的时候，它经常凭空造字段和函数，感觉就是根据上下文猜，根本没读过项目里其他文件。后来我改成先让它读相关模块，再把接口和表结构贴给它，情况好一点，但也只是好一点。中型重构想靠它全自动基本不现实，当个能聊的补全工具还行，关键逻辑还是得自己盯。

我一般只让Cursor干“有明确输入输出”的活，比如补测试、写脚本、迁移单个函数，涉及跨模块重构基本不用它。它看不到运行时上下文，表名和业务约束全靠猜，编缓存逻辑太正常了。想让它靠谱点，可以把相关文件手动拖进上下文，再把接口契约和不能动的边界写清楚，但也就是减少翻车率。真要中型重构，还是自己拆任务、定好每一步的验收标准，再让它按小步执行。