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

说实话你这体验太真实了，我拿Cursor试过几次带状态流转的后端重构，它能把ORM模型和迁移文件给编出平行宇宙来。我个人感觉这类工具核心还是靠模式匹配，对“当前项目上下文”的理解其实很浅，尤其跨文件改逻辑时基本靠猜。后来我学乖了，只让它干两件事：一是写纯函数或单元测试，二是把大需求拆成十几个小步骤逐步喂给它，每步都强制它引用具体代码行。中型重构还是别指望它主动规划，但当一个手速很快、偶尔犯傻的结对程序员用，效率确实能翻倍。

说实话你这个体验太真实了，我拿Cursor写Go服务端也踩过一模一样的坑，尤其涉及事务边界和依赖注入的时候，它生成的代码表面看着像那么回事，一跑全是运行时才暴露的假关联。我觉得核心问题不是prompt写法，而是这些模型对“项目上下文”的理解本质上是统计性的，它知道事务大概长什么样，但对你这个库表关系、历史债、隐式约定完全没概念。我自己试过把关键schema和业务规则直接贴进对话里，效果会好一点，但前提是这些信息本来就得花时间整理，整理完我差不多也知道怎么改了。至于中型项目重构，我唯一成功的是拿它做机械性迁移，比如把旧ORM调用批量换成新接口，这种模式清晰、改动重复的任务它反而靠谱，因为错误模式也容易一眼看出来。但让它自主设计新逻辑，尤其涉及并发、一致性、权限这类东西，基本就是碰运气。所以我现在的用法是让它当高级正则加自动补全，生成完我必逐行审，而且只让它改局部，绝不放手整体架构。你有没有试过给它喂一个具体的失败用例，让它基于报错信息反推修改？我试过几次，比直接说“重构这个函数”要准得多。

说实话你这个问题我太有同感了，上周我拿Cursor试着给一个老项目加个分页逻辑，它直接给我造了个不存在的ORM模型，还一本正经地写了关联查询，我当时差点以为是自己记忆错乱了。后来我琢磨了一下，感觉这类工具本质就是“概率性文本生成”，它对代码库的理解完全停留在你当前打开的那几个文件上，根本没法像人一样去全局追踪数据流和事务边界，所以一旦涉及跨模块的架构约束，它就开始一本正经地胡说八道了。我现在基本把它当高级补全用，遇到重复性样板代码或者写个单元测试骨架还行，真要重构核心逻辑，我会先把所有相关接口和表结构贴进prompt里，明确告诉它“不许新增任何未提及的实体”，这样能减少一半瞎编概率。不过说实话，中型项目重构我试过几次，感觉风险还是太大，尤其是有事务和并发的地方，它生成的代码就算逻辑看着对，边界条件也经常漏，你review的时候反而更焦虑。我倒是挺好奇有没有人试过把整个模块的架构文档喂给它，或者用那种能自动索引全仓库的工具，效果会不会不一样？

我跟你感觉差不多，把Copilot当补全用是真的香，但一旦让它碰核心业务逻辑，它就开始一本正经地胡说八道。后来我试了个笨办法，先把项目结构和涉及的表结构喂给它，再让它只写某个函数的具体实现，别让它一次干太多活，这样成功率能高不少。中型项目重构我也没成功过，感觉它确实理解不了事务边界和业务约束，最后还是得靠人肉review。

说实话你这个体验太真实了，我拿Cursor改过一个老项目的ORM层，它也是凭空捏字段，最后我干脆把项目结构文档喂给它才稍微好点。感觉这类工具对显式上下文特别敏感，但隐含的业务约束它真的抓不住，尤其是事务边界这种需要全局心智的。我现在的策略是让它生成单点函数或测试用例，重构这种活还是自己来，最多让它给个草稿参考。另外你可以试试把报错信息和相关代码片段直接贴给它，比描述需求管用得多。

说实话你这体验太真实了，我拿Cursor试过几次重构老项目，它连现有模块的依赖关系都理不清，经常给我引入不存在的包名。感觉这类工具对“理解上下文”的粒度还是太粗了，只能抓住你贴出来的那几行代码，根本看不到全局。我现在的用法是让它写一次性脚本或者补测试用例，涉及核心业务逻辑还是自己动手改，最多让它给个思路再手动落地。

说实话你这个体验挺典型的，我拿它做中型项目重构也翻过车，后来发现核心问题在于它根本没法感知全局上下文，你给它喂再详细的prompt它也只是在局部做模式匹配。我现在基本只让它干两类活：一是写一次性脚本或demo，二是把已有代码片段翻译成另一种语言，但凡要动现有业务逻辑都自己动手。你试试把重构目标拆成极小步骤，每一步都让它基于当前代码库生成，而不是让它一次性理解整个事务流程，可能靠谱一点。不过说到底，它们本质还是高级补全，别指望有真正的架构意识。