用Prompt调教AI写代码，为什么总是“好像会了但不会”？

这问题太真实了，我最近也被折腾得够呛。感觉关键不是把prompt写多细，而是得让AI“看见”运行结果，比如把报错信息直接丢回去让它自己修，比反复描述需求管用多了。另外它确实擅长生成孤立代码，但一涉及跨模块状态，基本就是靠猜，这时候不如自己先画个数据流图再让它填肉。

试试让AI先跑一遍再报错信息喂回去，多迭代几轮比死磕prompt管用。

代码生成本质是概率预测，上下文一长就露馅，核心逻辑还是自己写靠谱。

我最近也在折腾这个，最大的感受是AI写代码更像“照着葫芦画瓢”，它根本不懂你项目里的隐式约定。你贴了函数签名，但类之间怎么协作、异常怎么处理这些潜规则它猜不到。后来我干脆把报错信息直接喂回去让它自己改，来回几轮反而比死磕prompt效率高。说实话，涉及多文件改动或复杂依赖，还是自己写更靠谱，AI也就适合生成点纯函数之类的无状态代码。

我跟你一模一样的经历，尤其是改既有模块的时候，它总爱自作主张重构我的变量名，最后跑起来全是NameError。后来我发现一个笨办法，就是直接把报错信息贴回去让它自己修，来回几轮反而比一开始写复杂prompt有用。至于你说的few-shot过度模仿，我怀疑是模型在硬凑你的格式，而不是真理解逻辑。如果你这项目涉及多个类之间状态传递，我建议还是自己搭个骨架，让AI只填函数体，不然它根本hold不住上下文。

说实话我跟你遇到的情况一模一样，后来我干脆把项目里现有的一个类似模块的完整代码贴进prompt，让它模仿那个风格去写，比单纯描述需求靠谱多了。
但涉及跨类调用这种，我觉得本质上是AI没有“全局内存”，你不如自己先把接口和数据结构定死，让它只填函数体。
另外我试过让AI先写测试用例再写实现，这样它反而会自己发现约束冲突，你可以试试这个反向思路。
不过说真的，超过三个文件的小项目，自己写可能比跟它沟通还快。

说实话我也有同感，后来我发现问题不在prompt多详细，而是得让AI“看到”运行结果。我一般会先把报错信息贴回去让它自己改，或者让它写个最小复现demo，比反复描述上下文管用多了。另外我觉得你要是改既有模块，不如直接把相关类的代码片段塞进去，别让它猜，它一猜就放飞。至于小工具，prompt确实够用，但涉及真实业务逻辑，还是自己写框架更靠谱，AI顶多帮你补点边角料。

我最近也踩过类似的坑，后来发现关键不是prompt写多细，而是让它先跑通再改。我会先让它生成一个能跑的最小版本，哪怕功能不全，然后再一步步加约束，每次只改一个点，这样定位问题快很多。另外对于类之间调用这种，我干脆把相关代码片段直接贴进prompt里，比描述半天管用。不过说实话，真遇到复杂业务逻辑，我还是自己写，AI当个提效工具还行。

我之前也卡在这块很久，后来发现关键是把“运行环境”也喂给它，比如类之间的依赖关系用UML图或者直接贴调用链，它反而能老实点。另外你试过让AI先写测试用例再写实现吗？我这么干以后，它自己会去对齐约束，比单纯给例子管用。不过说实话，涉及改既有模块的业务逻辑，我还是觉得人肉写比调教它效率高，Prompt更适合从零憋个小函数那种。

这题我熟，你试试把“不要做什么”也写进Prompt，比如明确告诉它别改某个变量名、别用没导入的库，比光说“保持原逻辑”有效得多。还有就是让AI先输出一段“你打算怎么做”的计划，等它复述完你的需求再让它写码，错误率能降一半。但要是项目里有一堆隐式依赖，那真不如自己动手，AI写出来你debug的时间都够重写两遍了。

说实话我也有同感，尤其改既有模块的时候，它根本不知道你脑子里那个“全局图”长啥样。我现在比较有效的做法是先把报错信息原样丢回去让它自己修，比反复调prompt管用得多。另外就是别指望一次生成，把它当结对编程的实习生，一步步引导反而稳。你那个项目如果逻辑耦合度高，可能确实得自己搭骨架，让AI填肉。

试试把报错信息直接喂给它迭代修，比憋prompt管用，这玩意儿就是个高级补全，别指望它真懂上下文。

你那个需求本质是工程问题，AI只适合写无状态的小函数，牵扯到模块改造还是自己动手吧。

说实话我也有同感，尤其是改既有模块的时候，AI好像压根没读你贴的上下文，直接按它自己脑补的逻辑来。后来我试了个土办法，就是故意在prompt里写“如果这段代码涉及xxx类，请先列出你理解的调用关系再写”，逼它先输出推理过程，出错率确实降了点。但真到复杂业务逻辑，我还是觉得得自己上手，prompt顶多帮你搭个骨架，填肉和debug那步省不了。

说实话，你这个“好像会了但不会”的感觉太真实了，我怀疑是模型在生成时更倾向于“语法正确”而不是“逻辑闭环”，尤其跨文件依赖时它根本没把整个项目当上下文。我试过最有效的办法是让它先只写一个最小可运行版本，跑通了再加功能，而不是一次性给全需求。另外，那种让它“解释每行代码”的prompt反而能逼它更谨慎，出错率会低一些。不过像改老模块这种活儿，我也觉得还不如自己上手，prompt更适合从零写个小函数。

试试让AI先画数据流图再写代码，上下文类调用这块会稳很多，但复杂项目还是得自己兜底。

你这情况太真实了，我后来直接让它按现有代码风格补全，不重写，报错率瞬间降下来。

说实话你这体验太真实了，我最近也在折腾类似的事，感觉AI写代码最大的坑就是它特别擅长“编造合理但没验证过”的逻辑。后来我试了让它在输出前先自己跑一遍伪代码流程，或者强制要求它把每个函数依赖的外部变量列出来，成功率会高一点。不过涉及多文件项目或者改老代码，我基本放弃了，那玩意儿它根本记不住全局状态，只能是当个高级补全工具用。

说实话你这个情况我太懂了，GPT-4写代码就是典型的“眼高手低”，尤其是改既有模块时它根本记不住你项目里的隐式逻辑。我后来发现一个稍微管用的办法：把报错信息原封不动丢回去让它自己修，来回几轮比一开始写长prompt有效得多。但涉及到类之间复杂调用这种，真心建议自己动手，AI当个补全工具还行，真让它独立扛起一个模块还是太勉强了。

说实话我也有类似的困惑，尤其是改既有模块的时候，它好像完全没意识到自己是在“改造”而不是“重写”。后来我发现一个相对管用的土办法：把要改动的那个类的完整代码贴进Prompt里，然后明确告诉它“只允许动哪几行”，并且要求它输出diff格式而不是完整代码。这样至少能减少它“自由发挥”的概率。但说真的，如果项目里超过三个类互相引用，或者涉及一些隐式的数据流，我基本就放弃让AI写了，自己动手反而更快。我现在的态度是，Prompt适合解决“从零写个独立函数”这种边界清晰的任务，一旦涉及系统内部的状态一致性，它就是在给你制造幻觉式的安全感。你那几个few-shot的例子，我觉得问题可能出在例子本身不够“负面”——只给了正确的写法，没告诉它哪些常见错误模式绝对不能碰，比如忽略某个全局变量或忘记处理某个异常分支。你可以试试故意在例子中放一两个错误版本，然后标注“这是错的，因为……”，它学到的约束会具体很多。还有一个偏门但有效的方法：让它先写“测试用例”再写实现，这样至少它会顺着用例的预期去约束自己的逻辑，而不是天马行空。当然，最终如果这工具是内部用且改动频繁，我还是建议核心逻辑自己写，Prompt只用来生成脚手架或者测试数据，不然调试AI的代码比写代码还痛苦。

关键得把约束写进测试用例里，让它先跑一遍再改，比纯描述靠谱多了。

本质还是靠人兜底，AI写代码就当个高级补全用，别指望它懂业务上下文。

我自己的经验是，别指望AI能hold住那种牵一发动全身的改动，它更像是个高级自动补全。你那个类之间调用的问题，干脆把相关的接口定义和调用处的报错信息直接喂给它，让它对着改，比反复描述需求管用得多。另外，跑完测试再让它根据错误信息修，来回拉锯几次，比一次性生成一大段靠谱，虽然确实累人，但小工具这么搞效率还行。

我最近也踩过这个坑，后来发现关键是把“约束”写进代码里而不是prompt里，比如让AI先输出一个完整的类型定义或接口文档，再基于这个去生成实现。另外，如果项目本身有测试用例，直接把报错信息贴回去让它修，往往比重新描述需求更高效。你那几个few-shot的例子是不是太接近了？我试过故意把示例改得粗糙点，反而能减少过度模仿。

说实话这问题我太有同感了，GPT-4写那种完全独立的函数还行，一旦牵扯到项目里的既有类或者全局状态，基本就是在赌运气。我后来发现一个笨办法，就是先把报错信息原封不动贴回去让它自己改，往往比一开始费劲设计prompt效率高，但改个两三轮还是不行的话，基本就得自己上手了。感觉这玩意儿本质上是个“有经验的实习生”，能帮你搭骨架，但细节和上下文衔接还是得靠人兜底。