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

先写测试这招我试过，确实管用，让它按测试用例来写比空口描述边界靠谱多了。

我现在的做法是让它先写测试再写实现，尤其是边界条件直接列在测试里，这样它改的时候有约束，不会乱引入新bug。另外别一次性让它写太大块，拆成小函数逐个来，每步确认没问题再往下走。来回几轮其实正常，但有了测试兜底，通常两轮就能收敛，比纯靠嘴描述靠谱多了。

这个循环我太熟了，基本每个用Claude写代码的人都经历过。我的经验是，问题往往不在于prompt写得够不够详细，而在于你把“写代码”和“验证代码”这两件事混在一轮对话里了。它第一版漏边界条件很正常，因为你的需求描述里通常只覆盖了happy path，那些边界是你脑子里默认的、但没写出来的。我现在会先让它把函数签名、输入输出约束、异常情况用注释列出来，我确认没问题了再让它填实现，这样第一版质量能高不少。另外你说的先写测试这个思路是对的，但顺序得反过来——让它先根据需求写测试用例，你审一遍测试，再让实现去跑通测试，这样它改bug的时候有明确的靶子，不会东修西补引入新问题。还有个小技巧是每轮只让它改一个点，别一次性丢三四个问题过去，不然它容易顾此失彼。说到底这工具现在就是这个水平，把它当成一个手很快但需要你盯着的初级工程师，预期就顺了。