用Claude写代码老是要改好几轮，是我prompt有问题还是工具不行？

说实话我觉得这锅不全在Claude身上，我自己用也是这个德行，尤其Python这种边界条件多的活儿。后来我学乖了，让它写之前先把函数签名、输入输出样例和异常分支列出来，确认完再动笔，改轮数能少一半。另外强烈建议让它先写pytest，你直接跑测试拿失败信息喂给它，比自己肉眼找bug高效多了，它自己看着测试改也准一点。

说实话这太正常了，我一开始也以为是自己prompt写得不够好，后来发现Claude对边界条件的处理就是会比较偷懒。我现在基本都让它先写测试用例，把各种极端情况列出来再写实现，效果比反复改代码好很多。另外你可以试试让它直接输出“代码+注释”而不是解释逻辑，那些废话反而容易干扰它自己的判断。反正别指望一次成型，把它当成一个需要不断review的初级同事，心态就平衡了。

让它先写测试再补实现，逼着它自己跑一遍，能少折腾两三轮。

我的经验是把边界条件直接列成清单喂给它，比让它自由发挥稳得多。

说实话我觉得工具和prompt都有关系，但核心还是得调整预期。我试过让Claude先写测试用例再写实现，虽然第一版还是会有漏，但至少改的时候能自动发现回归，效率高很多。另外你可以试试把边界条件直接列成checklist塞进prompt里，比如空输入、超长输入、特殊字符这些，它真的会老实很多。别指望一次成型，但让每轮迭代都朝收敛方向走就行。

说实话这情况太典型了，Claude写代码更像是一个需要持续校准的结对程序员，而不是一次成型的外包。我试过最有效的方法是让它先写测试用例再实现功能，这样边界条件在测试里就暴露了，比事后修bug省事很多。另外把大函数拆成小步骤逐步验证，每步确认没问题再继续，比一次性铺开要稳。你那个“列计划再写”效果一般，可能因为计划本身不够具体，试着让它把每个函数的输入输出约束都写清楚再动手。

说实话你这个情况我太熟了，刚开始用Claude写Python的时候我也这样，后来发现真不是工具不行，是咱们把它当成了“一次性交付”的工程师，但它其实更像一个需要频繁对齐的结对编程实习生。我自己试下来最管用的一个workflow是反过来的：先强迫它把函数签名、输入输出约束、异常情况全列成注释或者docstring，然后让它基于这些“契约”写实现，这样它第一版漏边界条件的概率会低很多。另外写测试这招确实有效，但别让它自己写完了再测，那样它容易自圆其说，我是让它先写测试用例，包括那些刁钻的边界值，然后再写代码去满足测试，相当于用测试当需求文档。再一个就是别急着让它改代码，你指出问题后先问它“你觉得根因是什么”，让它解释清楚再动手，不然它经常是头疼医头，修了A又坏B。我猜你来回四五轮，大概率是每次反馈都太笼统，比如“这里没处理”，它猜不到你心里的具体场景，所以我会直接把输入示例和期望输出贴给它，越具体它改得越准。反正我现在已经不追求一次成功了，就把它当成一个速度很快但容易犯傻的同事，多聊几轮反而能逼我把需求想得更清楚，倒也不全是坏事。

说实话你这个经历太典型了，我一开始也是这么被折磨过来的。后来发现关键不是把prompt写到多细，而是让它先给方案+伪代码，你确认逻辑没问题再让它落地成完整函数，这样能省掉一半的返工。另外让Claude自己写测试用例这招真的有用，它会为了通过测试主动把边界条件想全，比你在那儿逐条提醒效率高多了。还有个土办法，就是让它一次给两个版本，比如一个偏保守一个偏激进，有时候对比着看反而能触发它自己发现问题。

说实话你这体验太真实了，我刚开始用Claude写Go的时候也这样，后来发现真不是工具不行，是咱们把它的工作方式想得太像人了。它本质上是个概率模型，第一版能给你个结构完整的骨架已经算超常发挥，边界条件这种细节全靠训练数据里的统计规律猜，猜不中太正常了。我后来试了个笨办法，就是让它先写测试用例，再让它写实现，等于把验收标准先钉死，它反而能少走好多弯路。但你也别指望一次过，我到现在平均也得改两三轮，只是从“乱改”变成了“有方向地改”。还有就是别在一条消息里塞太多需求，拆成小步子走，每步确认一下，虽然慢点但总比来回推倒重来强。说到底，这玩意儿就是个需要调教的实习生，你对它的预期得从“一次写对”调整成“快速逼近正确”，心态就稳了。

试试让它先写测试用例再写实现，边界条件你自己列成checklist塞进prompt里，能少折腾两轮。

说实话你这个体验太典型了，我刚开始用Claude写Python也这样，后来发现真不是工具不行，是咱们把“写代码”和“改代码”的任务混在一起丢给它了。我现在的工作流基本是：先让它把函数签名、输入输出约束、异常情况全列出来，用自然语言描述清楚，甚至直接让它写docstring，然后我才让它动实现。关键一步是让它先写测试，哪怕就是几个assert，因为一旦测试立住了，它自己改的时候就有个“锚点”，不容易修了东墙塌了西墙。还有个坑是别一次塞太多需求，我试过把一个复杂函数拆成三四个小函数，每个单独对话生成，最后自己拼装，质量稳定多了。另外你提到“列计划再写”效果一般，我猜是因为它列计划时没把边界条件具体化，你得逼它把“如果输入是空列表/None/超大数”这种case写进计划里，它后面写码才会真当回事。说到底，AI写代码就像带实习生，你得把验收标准定得比需求还细，不然它永远给你“看起来对但一跑就炸”的版本。我现在反而觉得来回改四五轮是正常的，只是把每轮的成本从“找bug”变成“跑测试”，效率就上来了。

说实话你这个循环我太熟了，尤其是Python这种边界条件特别多的场景。后来我试了个办法：让它先写测试用例再写实现，把预期行为写死在测试里，它自己跑挂了会老老实实改，比你自己描述需求省心得多。另外我发现Claude对“不要改我其他地方”这种约束很敏感，你每次只丢一小段代码进去，别让它看整个文件，反而出错率低很多。工具确实有局限，但工作流调整一下能省一半轮次。

这个现象太真实了，我自己的体验是Claude在“局部正确”上很强，但“全局一致性”确实容易翻车，尤其是函数多了以后，改A可能就不记得B里还依赖着旧的逻辑。你试过让它先写测试这个思路吗？我实践下来觉得最有效的不是让它“先列计划”，而是直接要求它“先写一个能暴露边界条件的pytest用例，再写实现”，这样它自己会先想清楚输入输出的契约，第一版质量能明显提升。另外我发现把需求拆成“最小可验证单元”而不是一次性给一个大函数，让它每个小步骤都跑一遍你给的例子，迭代轮次会少很多。还有一个偏门技巧，就是明确告诉它“不要优化，只求正确”，因为Claude有时候会自作主张加些它觉得优雅但你不一定需要的抽象，反而引入隐藏问题。说到底工具确实有它的随机性，但prompt工程里“约束输出格式”比“描述需求”更能拉高下限，你可以试试在每次修改时只给它看那个报错或失败测试，而不是整段代码，信息过载反而容易让它改歪。

先让它写测试用例再写实现，我试过，bug能少一半，你可以试试。

建议你写完第一版直接丢给它错误日志，比描述问题管用，它自己改得准。

说实话你这个循环太真实了，我刚开始用Claude写Python也这样，后来发现关键不是把需求写多详细，而是让它先画个函数骨架和边界条件清单，你确认后再填逻辑。另外让它先写测试确实管用，但别指望它一次写对，把测试当基准去逼它迭代，比你自己肉眼找bug快得多。还有个笨办法，复杂函数拆成几个小函数分别生成，出错范围小，改起来也省心。工具本身肯定不是完美的，但这种多轮纠错其实也算工作流的一部分，习惯就好。

说实话这情况太常见了，我自己的经验是别指望它一次写对，而是把“让它自己找bug”变成流程的一部分。比如我会在prompt里直接加一句“写完先自己检查边界条件，列出潜在问题再给我”，有时候比让它直接输出代码管用。另外你提到先写测试，这个我试过确实有效，让Claude先写几个测试用例再补实现，逻辑会清晰很多，至少能砍掉一半的来回扯皮。

我倒是觉得工具本身没问题，主要是交互节奏要调整，别把它当成一个一次成型的程序员，更像是一个需要你不停提需求的结对同事。不过我也好奇，你用的时候有没有试过把报错信息或者具体测试结果直接丢回去？我这么干的时候，它改起来精准多了，比单纯说“这个不对”强太多。

我之前也这样，后来发现关键是别让它一次性写完整函数，而是先让它把边界条件和异常情况列出来，你确认没问题了再让它写实现。Python的话我习惯让它先写pytest用例，用例对了实现基本一两轮就过。另外把报错信息原样贴回去比你自己描述“这里不对”有用得多，它能直接定位。