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

我最近也踩过这个坑，后来发现关键是把“上下文”直接塞进prompt里，比如把相关类的定义或者报错信息原样贴给它，而不是只描述需求。但说实话，涉及多个文件互相调用的逻辑，AI基本靠猜，我最后都是让它生成单文件独立脚本，再自己手动接缝。感觉few-shot确实容易过拟合，不如给一个“反面例子”告诉它哪里别那么写来得有效。你试过让AI先跑一遍代码再根据报错迭代吗？我这么干成功率会高一些，但还是要自己盯着改。

说实话你这情况太典型了，我也折腾过好久。现在我的感觉是，让AI写代码本质上是“快速生成初稿”，不是“保证正确”，尤其涉及既有项目上下文的时候，它根本没法真正理解全局状态。我后来习惯把报错信息直接贴回去，让它自己改，反而比反复调prompt有效。至于系统性的方法，我觉得可以把大任务拆成特别小的子问题，每个都让它单独验证，但说实话最终复杂逻辑还是得自己把关，AI更像是个高级补全工具。

试试把报错信息直接丢回去让它改，比反复调prompt管用，这活儿本质还是得人盯。

AI写代码更像高级补全，上下文一多就露馅，小工具行，模块化还是自己来吧。

这问题太真实了，我试过把整个项目结构塞给它，结果它自己脑补出一堆不存在的接口，还得靠我一步步纠错。

要不咱先让它只改一个函数，别一上来就让它写整个模块，上下文越少它越不容易跑偏。

说实话你这体验太真实了，我最近也卡在这。感觉GPT-4写独立函数还行，一涉及项目里既有类或者全局状态就崩，它根本记不住你给它的约束，只能靠你反复在prompt里强调“不要改其他方法”这种话术，但效果也看运气。我试过把报错信息直接贴回去让它修，反而比一开始让它写更靠谱，相当于把调错当迭代用。至于系统性的prompt设计，我觉得本质是它没有真正理解代码库的上下文，除非你每次把相关依赖全塞进去，否则不如自己动手改，AI就当个高级补全工具用吧。

说实话我也有同感，尤其是改既有代码时它老自己脑补变量名和逻辑。后来我试了个笨办法：把当前文件里相关的类和函数定义直接截进prompt，再明确告诉它“只改我标记的部分，其他别动”，成功率能高点。但真要复杂依赖，感觉还不如自己写，AI更适合给你个思路或者补全些样板代码。

我自己用的多的是那种小函数，输入输出写清楚，让它按特定库的API来写，基本能跑。一旦涉及多文件或者状态管理，它就像个记性差的实习生，你刚说完要求它转头就忘。所以现在我就把它当高级搜索用，需要啥写法先问它，拿到答案自己改一遍。

你有没有试过让它先输出测试用例再写实现？我试过一次，倒是能逼它考虑边界条件，但代码反而变得特别啰嗦。可能对这种任务，最稳定的prompt就是“把注释写详细点，然后代码我来调”，别指望一步到位。

试试把报错信息直接喂回去让它自己改，比反复调prompt管用多了。

代码上下文这东西AI真记不住，我都是让它输出最小复现再自己拼。

这问题太真实了，我最近也卡在这。后来我发现关键不是prompt写得多细，而是让AI先自己跑一遍再报错给我，或者直接让它输出能跑的伪代码，我再手动补全。感觉对已有代码的改动，它确实缺少“全局视野”，不如把相关模块的完整代码塞进去，让它基于实际内容改。

说实话我也踩过这个坑，后来发现关键是把“让它写”变成“让它改”——先让它按你的约束生成初版，然后把报错信息原样丢回去，追问它“这段代码在哪个具体场景下会失效”，比反复堆prompt管用得多。另外类之间调用这种，我干脆把最小可运行的伪代码骨架也贴进去，明确告诉它只能填函数体，别动结构。感觉本质是它没有真实运行环境，所以“看似合理”的逻辑错误只能靠你当人肉debugger去喂反馈。

我最近也碰到过一样的情况，后来发现关键是把“让它干活”变成“让它证明它知道怎么干活”。比如先让它解释一遍它打算怎么改，再让它动手，出错率会低很多。另外你试试把约束条件直接写成assert或者类型注解放进代码里，比在prompt里描述有用多了。至于大项目重构，我基本还是自己写，prompt确实只适合无状态的小脚本。

这问题我太有感触了，最近也在折腾类似的事。我感觉核心矛盾在于，AI对“上下文依赖”的理解是线性的，它把代码当作一串token在预测，而不是一个运行时的系统，所以类之间互相引用、状态交叉这种“网状关系”它天然就处理不好。你给它的约束，它其实都“看到”了，但生成时注意力会飘，总挑最显眼的那个模式走，这就是为什么few-shot写多了它会死磕你的例子，反而忽略你真正想改的那个变量名。我现在的笨办法是，把“让它直接写完整代码”换成“让它填我留好的洞”，比如我先把函数框架、类型注解、关键逻辑的注释全写好，它只补中间几行，这样成功率能高不少。但即便这样，只要涉及文件读写、全局变量或者外部库版本差异，它照样给你埋雷。说到底，我觉得这玩意儿定位就是“高级自动补全”，不是“结对程序员”，如果你要改的是有历史包袱的模块，真不如自己上手，让AI给你当语法词典用。

我一般会把任务拆到“AI只负责填空”的程度，比如把上下文依赖抽成明确接口，让它只写单个函数体，跑通再让它拼。直接让它改既有模块基本等于抽卡，尤其类调用那块它经常自己脑补。还有个土办法：先让它输出调用关系图或伪代码，确认约束没跑偏再让它生成真代码。纯靠Prompt确实不稳定，但这套流程能省不少力气。

我也有同感，尤其是改现有模块的时候，AI经常假装理解了上下文，实际跑起来接口对不上。后来我改成先让它复述一遍我的约束和依赖关系，确认没跑偏再让它写，命中率能高不少。不过说实话，稍微复杂点的逻辑还是得自己搭骨架，AI填填样板代码就得了。

我一般会把任务拆到“一次只改一个函数”这种粒度，然后把相关代码和类型标注都贴全，让它先复述约束再写。涉及类调用时，最好把接口签名和调用示例一起给，不然它真会自己脑补。另外别指望一次生成就能跑，我现在都是让它先写测试用例再补实现，报错率能降不少。

我现在的做法是让AI先写测试再写实现，prompt里直接要求它输出pytest用例覆盖边界条件，跑一遍再把报错贴回去让它改。这样迭代几轮比一次生成靠谱多了，上下文依赖的问题也少很多。不过类之间调用来回调的那种，还是得自己先理清接口，AI搞不定隐式的业务约束。

这事我踩过不少坑，后来发现核心问题不在Prompt写得好不好，而在于AI根本没法像人一样持续维护一个“心智模型”。你给它再多约束，它每次生成都是在局部做概率补全，类之间的调用关系、状态流转这些跨段落的依赖，它记不住也推不动。我现在做法是把任务切得更碎，一次只让它写一个函数体，输入输出用类型标注钉死，上下文我自己在代码里拼好再喂给它，反而成功率上来了。few-shot确实容易翻车，例子给多了它会把例子的结构当成模板硬套，哪怕当前问题压根不需要那层抽象。还有个偏方是让它先写测试再写实现，虽然测试也未必对，但至少能把边界条件逼出来，比直接生成业务代码靠谱。至于改既有模块，我基本放弃让AI独立完成了，顶多让它局部重写或者帮我读代码解释逻辑，真正动刀还是自己来。说到底Prompt能提升的是“起草速度”，不是“正确性保证”，系统性的方法可能有，但成本未必比你自己写低。

我倒觉得这个问题不完全是Prompt的锅，更多是任务类型没选对。让模型凭空写一段带上下文的代码，它没有真实项目的类型信息、调用链和运行反馈，只能靠猜，猜出来的东西当然“看着对、跑不通”。我自己试下来，效果最稳的方式是别让它一次写完整模块，而是先让它输出接口和数据结构，我确认后再让它填函数体，每步都限定输入输出。few-shot确实容易翻车，例子给多了它会死抠格式，反而忽略你真正的约束，不如把约束写成断言或者测试用例丢给它。还有个小技巧是让它先复述一遍需求再动手，经常能提前暴露它理解偏了的地方。像改既有模块这种活，我会把相关文件的关键片段和依赖关系一起贴进去，不然它根本不知道谁调了谁。所以我的结论是：Prompt能帮你提速，但前提是你把任务切得足够小、边界足够清楚，指望它一把写完整个功能，目前还是不太现实。