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

它们本质就是个会打字的结对编程实习生，别指望它懂业务，把活拆到函数级别让它补就稳了。

重构这种事还得自己画好边界，AI顶多帮你把机械劳动干了，理解上下文纯属幻觉。

它们本质就是高级补全，别指望理解业务，重构还是得自己拆步骤喂给它。

我倒是靠把大任务拆成小函数再让它逐个改，成功率能高不少，你要不试试？

它们本质就是高级补全，别指望理解架构，你得把上下文和约束喂到它嘴边才行。

重构这种活还是自己来吧，让AI写新功能当个快速草稿还行。

说实话你这体验太真实了，我拿Cursor做中型项目重构也翻过车，它对你代码库的理解就是表面那层，一旦涉及事务边界和业务约束就开始自由发挥了。我觉得这类工具现在最适合干的是“翻译”和“填空”，比如把老代码从一种风格改成另一种，或者照着已有的模式补新接口，千万别让它从零设计逻辑。你试试把要重构的函数拆得更细，每次只让它改一小步，并且prompt里明确写死“不要新增表名、不要改动缓存”，会好很多。

说实话你最后那句“高级补全”基本说到点子上了，我拿Cursor搞了几个月项目，感觉它强在快速生成样板代码和单点函数，但一牵扯到跨文件的状态流转或者带事务的边界条件，确实就开始一本正经地胡编了。我的经验是别让它直接重构，而是把涉及的实体关系、表结构和现有约束先喂给它，再让它给个方案，这样瞎编概率会低不少，但review还是省不了。

说实话你这体验太真实了，我拿Cursor改过那个老项目的service层，它连我们内部的状态机都理解不了，硬给我塞了一堆if-else。我觉得关键不是prompt，是这些工具根本看不到你整个项目的上下文，你让它重构事务，它压根不知道你表结构长啥样。我现在就把它当高级补全用，让它写写单元测试或者生成DTO，但凡涉及核心业务逻辑，还是自己动手靠谱。

我试过把相关文件拖进对话里，并明确告诉它“不要动数据库层”，效果好一点，但也就好一点点。中型项目重构我劝你别指望它，光是把现有代码的隐含约定讲清楚就得写两千字prompt，有那功夫我自己都改完了。唯一觉得有用的场景是让它把一段烂代码翻译成新框架的写法，然后我再逐行修。

你这情况我也遇到过，后来发现把整个项目的目录结构贴给它，再让它先画个调用关系图，能减少点瞎编的概率。但说实话，它对于“应该怎么做”的常识判断挺强，一到“咱们项目里具体是怎么做的”就开始自由发挥了。我觉得这类工具离真正理解业务还差得远，顶多算个读过很多开源代码的实习生，你让它干点杂活可以，带项目还是算了。

说实话你这体验太真实了，我拿Cursor试过改个内部状态机，它直接给我造了个压根不存在的模块引用，查了半天才发现是幻觉。后来我学乖了，把相关接口定义和调用链直接贴进上下文，再明确禁止它新增依赖，这样靠谱很多。但要说中型重构，我觉得还是别指望它一步到位，我一般让它先出个方案，然后我手动拆成小步走，每步都让它只动局部。你试试把任务拆细，限制它只改你指定的文件，别给它自由发挥的空间，体验会好很多。

它们本质就是高级补全，你当结对编程的初级助手用就行，别指望理解业务。

我拿Cursor重构过几个内部服务，得把上下文和约束拆得极细，还得一步步喂，急不来。

说实话你的体验跟我一模一样，我试过让Cursor改个带状态机的服务，它直接给我造了三个不存在的中间表，气得我直接回滚。我觉得关键在于它根本没法感知你项目里隐性的约束，比如事务边界、缓存一致性这些，它只会按字面意思和常见模式瞎推。你可以试试把相关模块的核心代码直接贴进上下文，再明确告诉它“不要动哪些部分”，效果会好一点，但真指望它做中型重构，还是得当个高级搜索+补全工具用。我自己最后是靠给它多轮喂错误日志和测试用例，才勉强让它改对一个旧项目的查询逻辑，但花的时间真不如自己写。

说实话你这个问题我太有共鸣了，我拿它处理过一个带状态机的服务，它直接给我造了个不存在的中间表去存流转记录。后来我发现，把项目的核心数据模型和事务边界直接粘进prompt里当上下文，它瞎编的概率能降一半，但想让它完全理解业务约束还是别指望了。

我现在的用法是让它写单元测试和重复性代码片段，或者生成一版粗糙的草稿，然后我基于这个去改，比自己从零写能省个20%时间。中型重构我试过几次，感觉它连“哪里需要改”都判断不准，更别说保证行为不变了，还是得靠人肉拆分成小步骤喂给它。

另外有个小技巧，就是别让它一次做完整件事，逼它把任务拆成十步，每步都验证再走下一步，这样幻觉会少很多。不过说真的，要它真正懂你的架构，可能得等它把整个repo都读进去再说吧。

说实话你这个体验太真实了，我拿Cursor试过几次带状态机的重构，它也是自信满满地给我塞了一堆假方法名。我觉得本质就是概率补全，它压根没建立项目依赖关系的模型，所谓理解架构全靠读你当前文件的上下文瞎猜。要真想让它干重活，得把相关模块的关键代码和数据库schema直接粘到对话里，明确告诉它别碰哪些部分，就当个高级打字员用。中型项目重构我试过拆分一个老服务，拆到一半还是得自己上手，它只能干些重复性搬砖的活。

说实话，把AI当结对编程的实习生用就对了，大方向它给个草稿，细节还得自己把关。

说实话你踩的坑我也踩过，后来发现关键不是prompt，而是得先把项目结构、数据模型这些上下文喂给它，让它基于真实代码改而不是凭空想象。我现在用Cursor都是先让它读几个关键文件再动手，复杂重构基本靠它出草案、我改逻辑，纯自动还是算了。另外事务和缓存这种涉及副作用的，我干脆自己写，AI只用来补样板代码和测试用例。

说实话你遇到的这个情况太典型了，我觉得问题真不全在prompt上。模型对“重构”的理解就是基于它见过的海量代码模式来套模板，它压根没真正理解你项目里的事务边界和表关系。我试过把相关表结构和函数实现直接贴进上下文，让它分步改，效果会比一次性给个大任务好不少。另外像这种涉及架构变动的活儿，我基本只让它产出单点修改的diff，然后自己来拼装整体逻辑，这样review压力小很多。

说实话你总结得挺到位的，它们就是高级补全+概率生成，对项目上下文的理解停留在表面。我试过把数据库schema和事务边界直接粘进prompt里，稍微好点，但复杂逻辑还是得自己拆步骤一步步喂。

我觉得关键是把任务拆到足够小，小到它只需要改一个函数而不是“重构”，同时把相关的接口定义、表结构都贴进去，别让它猜。至于那种跨模块的改动，还是别指望它了，能帮你写个测试用例或者生成个CRUD就已经是赚了。

另外你试试让它先输出一个改动方案，你确认了再让它写代码，比直接让它动手瞎编强很多。但说实话，中型项目重构我目前也没见过谁真靠它干成的，基本都是用来写点一次性脚本或者补全模板代码。

说实话你这个感受太真实了，我拿Cursor试过改个带状态机的服务，它直接给我造了个不存在的中间表，还煞有介事地写了迁移脚本。我感觉这类工具对“局部语法”很擅长，但对“全局语义”基本是盲人摸象，尤其重构这种活，它连你项目里哪些模块是核心依赖都搞不清。我现在基本只让它生成独立函数或者写测试用例，但凡碰业务逻辑就纯手写，效率反而高。你试过在prompt里贴出具体的数据模型定义和调用链吗？我试过几次，它瞎编的概率能低一点，但离“靠谱”还是远。

说实话我跟你感受差不多，写点独立的小函数还行，一碰老项目里的业务逻辑就露馅。我后来发现关键是得把上下文喂足，比如把相关表结构和事务边界直接贴给它，然后明确告诉它“不许加缓存”，这样能少踩不少坑。至于中型项目重构，我试过让它先出一个改动方案让我确认，再动手写代码，比自己直接让它改靠谱一些。但说实话，真要动核心事务逻辑，我最后还是自己手写了，AI当个辅助提效还行，指望它独立干活确实不现实。

说实话你遇到的这个情况太真实了，我现在基本把Copilot当带语义的补全用，让它写个独立函数或测试用例还行，但凡涉及跨模块调用的重构，它给的代码我连跑都不敢跑。你试试把上下文切得更碎，比如让它先画个改动影响范围的清单，再一段段改，别直接甩整个需求。至于中型重构，我见过有人用Cursor的agent模式配合详细的TODO注释硬啃下来的，但review工作量一点没少，只能说效率提升有限，别指望它背锅。

工具定位就是高级补全，你拿它当重构主力肯定翻车，得先把边界摸清楚再谈用法。

我试过把需求拆成极小步骤喂给它，配合手动锁死关键代码，勉强能省点事，但指望它一次写对还是算了。

这类工具就是高级补全，复杂重构还得自己把关，prompt再细也救不了它瞎编。

得把大任务拆成小步骤让它一步步来，再强校验上下文，不然真不如手写。