AI写代码省的时间，全赔在调试上？Claude官方：让AI自己测、自己改

假设这样一个场景：

你借助Claude Code快速搭建了一个小应用，还给它配上了AI客服功能。

原本指望它能自动回应用户诸如“如何登录”“会员服务包含哪些”之类的常规问题，让自己彻底省心。

结果，客服确实能对话了，但你却变成了它的贴身教练：

回答不够准确，就得立即补充提示词；解释过于冗长，又要添加约束条件。

更令人头疼的是，每次修改提示词后，你都得把常见问题逐一重新测试，担心顾此失彼，解决了一个问题，却把原来答对的又弄错了。

于是，用AI写代码省下的时间，很大一部分又消耗在了反复的人工调试上。

针对这种反复调试的痛点，Anthropic官方于9月28日发布了一份优化指南。

这份指南的核心思想很简单：像反复测试和修改这类工作，Claude也能胜任。

让它多承担一些，你就能少当几次辛苦的测试员，把更多精力放在把控AI的表现上：

给它设定规则，明确什么才算合格，再检查它是否真正做到了。

把“别乱说”转化为具体的测试题目

要让AI有目标地改正错误，首先得把“怎样才算正确”说清楚。

平时我们总希望AI客服“更可靠一些”，但这太笼统了。

如果能将要求落实到用户实际会遇到的场景中，标准就会具体得多。

例如：

用户找不到导出按钮时，它能否给出正确的操作路径？ 用户问到尚未开发的功能时，它会不会凭空编造？ 遇到退款问题，它能否依据明确规则处理，不确定时不随意承诺？

官方提供的第一个工具是：/claude-api build-eval。

简单来说，它能帮你把这些具体要求转化为测试题，为接入Claude的小应用构建一套可反复运行的验收题库。

你可以把那些常让AI出错的难题交给它，但题库不能只收录“错误案例”，那些最常见、最普通的问题同样要覆盖。

否则，即使堆砌再多偏题和难题，也可能无法准确反映普通用户的日常体验。

题目选好后，还需要明确“如何评分”。

“专业”、“智能”、“友好”这些要求颗粒度太粗，需要落实到更具体的衡量标准上。

比如哪些信息必须准确传达，哪些错误绝对不能犯，做到什么程度才算合格。

官方邮箱分类示例：测试样例需由用户确认。

Claude会帮你拟定相应的评分规则，而你需要确认，按这套规则获得高分的答案是否真的解决了用户的问题。

有些结果可以直接用程序检查，比如是否遗漏了关键字段；对于存在多种合理答案的开放性问题，也可以让模型按照明确的规则打分。

但评分器本身也需要先通过验证。

拿几份已经评过分的答案，对照自己的判断，看看是否存在“答对了却被扣分”、“没解决问题却通过了”的情况。

确认评分可靠后，再定期进行抽查。

对开发者而言：这一步最大的好处在于，你终于能把那句“怎么又答错了”的反复抱怨，变成一套可以持续运行的自动化检查。

以后每次修改提示词，就可以再跑一遍，看看这次修复了哪些问题，有没有把其他地方改坏。

自己改，自己测，改差了就撤回

题库建好后，接下来就是使用第二个官方工具：/claude-api hillclimb。

hillclimb可以理解为“爬山”，让AI逐步尝试优化，看是否有所进步。

但这个KPI同样需要定得具体，还要说明允许它修改什么。

比如，让客服回答得更准确一些，允许它修改提示词；或者在保持回答质量的前提下，尝试节省API费用，允许它调整模型配置。

接到任务后，Claude会查看用于迭代的错题，每轮提出一处修改，然后重新运行评估：

如果修改后达到了既定目标并有所改善，就保留修改；如果反而退步了，就撤回。

根据官方文档，这两个工具都需要Claude Code v2.1.259及以上版本。

提示词、技能文件、工具说明和模型配置等都可以作为优化对象，但具体修改哪些，需要由你划定范围。

你可能会担心：AI会不会变成只会应付考试的“做题家”？也就是只针对你给出的那几道题死记硬背，换个问法就开始胡说八道？

官方也确实考虑到了这一点。

这套流程会单独留出一部分题目，作为不提前公开的“验收考题”。

负责提出修改的模型看不到这些题目的内容。每轮修改后，再用这些题目测试，看看效果是真正提升了，还是只对练习过的题目有效。

如果练习过的题目分数提高了，但“验收考题”的成绩却没有提升，就可能出现了“过拟合”：越来越擅长做熟题，换一批题目却没有进步。

遇到这种情况，Claude会撤回本轮修改；如果修改后表现反而变差，也会回退。

每轮修改后复测，根据结果保留或撤回。

这有助于发现“只会做熟题”的问题，但并不意味着从此高枕无忧。

题库本身覆盖不到的真实问题，仍然可能让它出错。

官方客服案例，成本降至约五分之一

Anthropic用一个内部客服评测展示了效果。

在14张未参与指导修改的留出测试工单上，最终配置的决策准确率从78.6%提升至90.5%，提高了11.9个百分点，模型调用成本降到了原来的约五分之一。

调整模型、思考强度与提示词，改善准确率和成本。图中为迭代集成绩。

不过，这是一组特定配置、特定小样本下的结果，并不意味着接入这套流程，你的应用也能节省八成成本。

这里比较的模型调用成本，也不能等同于整个项目的总成本。

但这对于自己支付API费用的个人开发者来说，仍然很有吸引力。

毕竟，便宜的模型如果总是答非所问，导致用户反复追问，最后还需要你人工介入，未必划算。

而简单问题如果也使用昂贵的配置，附带生成一大段不必要的解释，同样可能浪费钱。

现在，你可以将回答质量和调用成本放在一起测试，让AI在满足质量要求的前提下，尝试更省钱的方案。

不过，优化本身也会消耗模型调用费用。

先确定愿意投入多少实验费用，再决定让AI跑几轮，这样才更稳妥。

把时间还给真正重要的事情

当这套自动化流程运行起来后，你就有机会减少重复的提示词修补，把精力放回产品本身。

首先，是洞察用户。

你认为理所当然的操作，第一次打开应用的人可能连入口都找不到。你需要做的，是把这些真实发生的困惑补充进题库，AI的下一次优化才会更贴近实际。

其次，是把控标准。

回答再客气，没解决问题，能算过关吗？意思明明相同，只是换了种说法，评分器会不会误判？

评分标准本身要是有漏洞，AI忙活半天，可能只是分数涨了，用户的问题却还在。

邮件分类评测：左侧查看各题得分，右侧回看模型输入与回答，核查评分是否合理。

最后，是做权衡。

回答精简会不会遗漏必要步骤？追求便宜会不会牺牲准确度？这些关乎用户体验的关键取舍，依然需要你来拍板。

给应用接入AI，初衷是为了省心。

如果最后演变成你全天候陪着它改答案，就本末倒置了。

当Claude能多接手一些重复调试，普通开发者就能多花时间打磨自己的小工具、小应用，让那些搁置的想法重新往前走。