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

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

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

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

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

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

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

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

说实话你遇到的这个情况我太熟了，Copilot和Cursor在生成“看起来对”但实际是幻觉的代码上简直是一把好手，尤其是涉及数据库表名和业务状态流转的时候，它们根本不懂你项目里的约束。我觉得问题还真不全在prompt，你就算把整个事务逻辑写清楚，它们也倾向于拼凑一个“最像样”的答案，而不是去理解数据一致性这种隐性要求。我自己用下来的感受是，这类工具最适合干三件事：写胶水代码、补单元测试样板、还有把一段冗长的if-else改写成策略模式这种机械重构。中型项目的真实重构，比如改一个跨模块的依赖关系，或者抽公共逻辑，它基本帮不上忙，反而会给你塞一堆没用的抽象。我现在的做法是把它当“带快捷键的搜索引擎”，让它给个大概思路或者某个函数的几种写法，然后我自己去核对和落地，绝不直接接受它改核心逻辑。另外你可以试试在prompt里强制要求它“先列出所有涉及的表名和函数签名，再开始写代码”，这能明显减少瞎编表名的情况，但缓存逻辑那种自作主张还是得靠你盯紧点。所以别太怀疑自己，这工具目前就是个高级补全，离“理解业务”还差着十万八千里呢。

这些工具确实只擅长局部补全，碰到跨模块改动就容易一本正经地胡说，得把上下文嚼碎了喂给它才行。

我后来都是让它写单测和胶水代码，重构还是自己来，省心多了。

说实话你这个体验挺典型的，我也试过拿它们碰中型项目重构，结果跟你差不多，一涉及跨模块依赖就露馅。后来我总结的用法是：让它写独立函数或者测试用例挺好，但架构决策和业务逻辑梳理还是得自己来，顶多拿它当个高级搜索用。你那个事务函数的问题，我怀疑是context给得不够，试着把相关模型定义、现有调用链都贴进去，可能比让它“理解”更靠谱点。不过话说回来，这类工具现在确实像你说的，本质还是补全，离“理解业务”还差得远。

说实话你这体验太真实了，我拿Cursor改个内部状态机也翻过车，它连我们项目里自定义的异常类型都记不住，更别说跨文件的事务边界了。现在我的用法就是让它生成独立函数或者写测试用例，涉及改老代码就只让它出diff草案，自己再逐行过，反而省时间。中型重构我试过把整个模块的上下文贴进去再加一堆约束条件，偶尔能行，但稳定性不如手动拆小步走，感觉工具上限还是取决于你对代码库的拆解能力。

说实话你这体验太真实了，我拿Cursor试过改个带状态机的服务，它直接给我发明了三个新类，注释还写得像模像样。感觉这类工具对“局部重构”的理解就是基于上下文猜一个“合理但不存在”的方案，尤其跨文件依赖一多就露馅。我现在基本只让它生成独立函数或者写测试用例，涉及业务逻辑的改动还是自己动手，顶多让它补个类型注解。你试过把数据库schema和关键实体定义直接贴进对话里吗？我试过明确约束后它编错表的概率会低不少，但复杂事务还是得靠人肉把关。

说实话你这体验挺真实的，我拿Cursor试过几次带状态管理的React重构，结果它自己发明了个不存在的hook，排查半天血压直接拉满。后来我学乖了，把相关文件的关键逻辑和约束写成一段注释塞给它，让它只改某个函数而不是全盘重写，效果能好不少。但要说搞中型项目重构，我觉得现阶段这些工具顶多算个高级结对编程的辅助，真指望它理解业务边界还是有点悬。

确实，它们对现有架构的理解基本靠猜，我试过把上下文贴全也没用，重构还是得自己把关。

说白了就是高级补全，别指望它懂业务，喂再细的prompt也就那样，中型重构建议还是人肉来。

说实话你这个体验太真实了，我也试过让Copilot改个带事务的函数，它自己脑补出一套根本不存在的业务逻辑，最后还得我一行行删。我觉得关键不是prompt，而是它压根没有“项目全局”的概念，只能基于你给的上下文猜，所以重构这种活最好还是自己搭骨架，让它填血肉。我现在基本就是把它们当高级补全用，写单元测试或者重复性模板代码效率挺高，但真涉及架构决策还是得自己来。你试过用@workspace或者把相关文件都拖进上下文里吗？有时候喂够相关资料它能靠谱一点，但离“理解业务”确实还差得远。

你把它当高级补全就对了，重构这种事它连现有表结构都记不住，肯定瞎编。

我试过把项目文档和schema喂给它，勉强能好点，但离靠谱还差得远。

说实话你这个感受太真实了，我现在基本把Copilot当高级正则用，让它补个模板或者写个单测还行，但凡牵扯到跨文件状态流转它就开始一本正经地胡诌。我试过把项目里的核心模型和数据库schema直接贴进prompt，结果它还是能给你造出几个看起来贼像真的但压根不存在的字段。我觉得这类工具目前最大的问题不是prompt，而是它压根没有“全局一致性”这个概念，你硬让它重构复杂事务其实就是拿它的短板去考试。我现在实践下来的唯一靠谱路径是，让它先分步写清楚每一步的输入输出，然后我再把边界条件和异常处理自己填上，效率确实比纯手写高一点，但离“重构中型项目”还有十万八千里。

说实话你这个体验太真实了，我拿Cursor试过改个内部状态机，它直接把枚举值给我换了个名字，编译都过不了。后来我摸索出来的办法是，把项目里的核心模块先让它读一遍，然后明确告诉它“只改这里，别动其他文件”，效果会好不少。但真要说中型项目重构，我目前也只敢让它干点提取函数、补测试这种边角料，核心逻辑还是自己动手踏实。

说实话你提到的这个情况我太有同感了，特别是事务那块，AI压根不懂你数据的一致性边界在哪。我觉得关键是把“重构”拆成特别小的步骤喂给它，比如先让它只改查询逻辑，别碰表结构，这样幻觉会少很多。我最近在一个中型Django项目里试过，让它按我指定的ORM模型写迁移脚本，比让它自由发挥靠谱十倍。另外，它生成的缓存逻辑基本都是模板化的，直接跟它说“不要加任何额外优化”能省你不少review时间。

它们本质就是高级补全，架构级重构真别指望，你得把上下文喂得够细才行。