用AI写代码总在改需求时翻车，是我的提示词姿势不对吗？

变更清单这招确实管用，把改动点列成checklist比自然语言稳多了。

我一般还加一句“别动其他逻辑”，比重复强调“只改这段”好使。

变更清单这思路靠谱，我试过把需求拆成123条，翻车率直线下降。

我一般直接贴整个文件，然后明确说“只动这几个函数”，不然它手痒乱改。

变更清单这招亲测有效，比纯描述稳多了，但记得让它逐条核对别跳步。
我试过把改动的函数拆成独立文件再让它动手，翻车率能低不少。

变更清单确实比自然语言靠谱，我一般列完还会加一句“只动这些，别碰其他”。

同步改异步这种跨函数改动，最好拆成两步让它先出计划再动手。

变更清单绝对比自然语言靠谱，把改动点和边界写清楚能少翻车一半。
另外让它先列执行计划再动手，比直接改代码稳得多。

我试过把需求拆成一条条checklist喂给它，确实比一段自然语言靠谱，但前提是得把边界画死，比如“只动这个函数，其他文件不许碰”。不过还是得自己把改动后的代码过一遍，它太容易自作主张“优化”了。另外，改异步这种涉及调用链的，光贴片段根本不够，上下文得给足。

变更清单这个思路我试过，确实比自然语言描述稳一些，但别指望它完全听话。我一般会把“禁止改动”的代码块用注释圈出来，再单独列出要改的接口和预期行为，效果能好点。另外同步改异步这种，它经常漏掉await或者回调里的上下文，我现在会主动让它先画个调用链再动手。感觉不是AI不行，是这类改动本身就涉及隐式依赖，你给的信息越结构化，它翻车概率越低。

变更清单这个思路我试过，确实比自然语言描述稳一些，但关键是要把“不要动的地方”也写进去，不然它还是爱自作主张。另外同步改异步这种，我习惯先让它列个改动点，确认了再动手，比直接改代码成功率高不少。

我猜核心问题是AI对“局部修改”的理解跟咱们不一样，它总想全局一致性，反而容易误伤。你试试把相关函数和调用方一起贴给它，然后明确说“其他文件禁止改动”，会好很多。

还有个小技巧，如果它改残了，别急着重新描述，直接指出来“这里变量名没换”“那个异常没处理”，让它基于当前错误修，比从头再来靠谱。说到底不是AI不行，是咱们得把它当个记性差的实习生来带。

我跟你遇到过一模一样的问题，尤其是同步改异步这种，它经常把await加在错误的地方，或者漏掉协程的异常捕获。后来我试了下你说的“变更清单”思路，确实比自然语言描述稳一些，但也不是万能的。我觉得核心问题在于AI对“局部修改”的理解跟人类不一样，它倾向于基于上下文重新推断整个逻辑，而不是严格按你的指令做外科手术。我的做法是，在提示词里明确加上“除了以下改动，其余代码一字不改”这种强约束，同时把需要修改的函数签名和调用点都列出来，效果会好不少。但还有个痛点——如果项目里有大量相似命名，它还是会串，这时候不如直接新建一个文件让它重写，避免旧变量名干扰。另外，你可以试试给它一个“反向任务”，比如让它先解释现有代码的职责，再问它“如果要加重试，哪些地方必须动”，这样它会把改动范围自己梳理出来，比直接下指令更靠谱。总之，迭代型任务不是不适合AI，而是需要你把“变更的边界”定义得比“功能本身”更清晰，这本身也是种工程能力。

变更清单这招确实管用，把改动点列成123比自然语言描述靠谱多了，你可以试试。

我一般直接复制整个函数再附上具体改哪几行，效果比描述需求稳定不少。

我自己的经验是，这种迭代修改确实比从零生成难搞，因为AI对上下文的“全局一致性”理解有限。你试试把变更清单写成结构化要点，比如“改函数签名、更新所有调用处、补try/except”，比自然语言描述靠谱很多。另外，如果它动无关代码，我一般会直接说“不要改未提到的部分”，有时候还得重复强调两三次。不过说实话，遇到特别大的重构，我宁可自己动手改，AI反而容易越帮越忙。

我也遇到过一模一样的情况，改需求比从零写还费劲。后来发现给个“变更清单”确实比自然语言靠谱，每条列清楚改哪个函数、动哪几行，甚至标上“别动其他代码”这种硬约束，翻车率能降不少。但说实话，像同步改异步这种跨结构的改动，AI还是容易漏上下文，我现在基本把它当高级搜索用，改完自己得全局搜一遍变量和异常，别指望它一次到位。

给变更清单比自然语言靠谱，但更关键的是让它先复述改动点再动手，能少翻车一半。

试过把“只改这段”换成“先列出影响到的所有函数和变量”，成功率明显上来了。

说实话你这情况我太熟了，尤其是“只改这一段”结果它自作主张动其他地方，简直是我的日常崩溃点。后来我发现，AI对“局部修改”的理解跟我们不一样，它脑子里没有“最小变更”这种概念，你越强调“只改”，它反而越觉得你想让它把整个上下文理顺。我现在基本放弃自然语言描述需求了，直接给它列一个类似git commit message那样的清单，每条必须对应一个具体文件或函数，比如“把get_user_data改成async，调用处加await，异常块保持原样”，它执行起来就老实很多。但就算这样，改完我还是会跑一遍diff检查，毕竟它偶尔会漏掉类型注解或者把return提前了。另外，那种“顺手优化”其实挺无解的，我试过在提示词里加“不要改动任何与需求无关的代码”，效果时好时坏，感觉跟模型版本和上下文长度都有关系。你那个内部工具如果改动频繁，我建议干脆把核心逻辑拆成小函数，让每次需求都变成新增而非修改，这样AI的失误率会低不少。

变更清单这个思路我觉得靠谱，但更关键的是别让它“自由发挥”。我一般会在描述里加一句“只动我指定的部分，其他一律别碰”，然后把相关函数前后各留二十行上下文，效果会稳很多。另外，改异步这种涉及调用链的活儿，它确实容易漏改上游或下游，你不如直接告诉它“这个函数被谁调用了，那边也得一起改”。说到底，迭代型任务不是不适合AI，而是你得把它当成一个记性差但手快的实习生，指令越像验收标准越好使。

说实话你这个问题我太有共鸣了，cursor加claude写新代码确实爽，但改需求就像拆盲盒。我觉得不全是提示词的问题，更核心的是模型对“局部修改”的理解压根没有上下文全局观，它脑子里那套代码结构和你实际文件里的状态经常是错位的。你试过贴完整代码但效果不稳，很可能是因为它把“改函数”理解成了“重构整个模块”，顺手把其他逻辑也当成了可以优化的对象。我自己摸索下来，最有效的方式是给它一个极其明确的“变更清单”，比如用bullet point列清楚“只改第几行到第几行，保留XX函数签名，新增参数默认值”，甚至直接告诉它“其他地方一个字都别动”——虽然不能百分百保证，但比纯自然语言描述靠谱得多。另外有个小技巧，把改完的代码立刻用diff工具对比一下，发现它动了不该动的地方，就马上回滚并补一句“你刚才改了无关逻辑，请重来”，多训练几次它会慢慢记住你的边界。说到底，这类迭代任务不是不适合AI，而是它现在更像一个记忆力有限的实习生，你得把需求拆到足够细碎，它才能不跑偏。

变更清单真的有用，我试过把需求列成123，它至少不会乱动别的逻辑了。

我也遇到过这问题，后来干脆每次改完都拿diff工具扫一遍，比让AI自己检查靠谱多了。

变更清单这个思路我觉得靠谱，但别指望它一步到位。我试过把改动点列成编号列表，它确实更少碰无关代码，但遇到异步改造这种牵一发动全身的活，还是得靠你手动盯着关键变量名。另外你贴完整代码时，它会默认“整段可优化”，反而容易自作聪明，不如把函数体用markdown代码块框住，再明确加一句“其他部分保持原样”。说到底，AI对“上下文边界”的感知很弱，你得把“不要动什么”说得跟“要改什么”一样具体。

变更清单这招我试过，确实比自然语言稳，但还得盯着它别顺手改别的。

把工单拆成最小步骤喂给它，一次只动一处，翻车率能降一半。

变更清单这招我试过，直接列清楚改哪几行反而稳很多，别让它自由发挥。

我也踩过这坑，后来干脆把要改的函数单独复制出来改完再贴回去，基本不翻车。