试想一下，你利用 Claude Code 手写了一个小应用，并接入了一个 AI 客服。原本的设想是让它自动处理用户关于登录、会员服务等基础问题，让你实现“甩手掌柜”的愿望。然而，现实却很骨感：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 个百分点，模型调用成本降到了原来的约 1/5。不过，这是一组特定配置、特定小样本下的结果，并不意味着接上这套流程，你的应用也能省八成。这里比较的模型调用成本，也不能当成整个项目的总成本。但对于自己掏腰包付 API 费用的个人开发者来说，仍然很有吸引力。毕竟便宜的模型如果老是答非所问，逼得用户反复追问，最后还要你人工介入，未必划算。而简单问题如果也用昂贵的配置，顺带生成一大段不必要的解释，同样可能花冤枉钱。现在，你可以把回答质量和调用成本放在一起测试，让 AI 在满足质量要求的前提下，尝试更省钱的方案。不过，调优本身也要消耗模型调用费用。先定好愿意掏多少实验费，再决定让 AI 跑几轮，才更踏实。
当这套自动化流程跑起来后，你就有机会少做一些重复的提示词修补，把精力放回产品本身。首先，是洞察用户。你觉得理所当然的操作，第一次打开应用的人可能连入口都找不到。你要做的，是把这些真实发生的困惑补充进题库，AI 的下一次优化才会更接地气。其次，是把控标准。回答再客气，没解决问题，能算过关吗？意思明明相同，只是换了种说法，评分器会不会误判？评分标准本身如果有漏洞，AI 忙活半天，可能只是分数涨了，用户的问题却还在。最后，是做权衡。回答精简会不会漏掉必要步骤？追求便宜会不会牺牲准确度？这些关乎用户体验的关键取舍，依然需要你来拍板。给应用接入 AI，初衷是为了省心。如果最后演变成你全天候陪着它改答案，就本末倒置了。当 Claude 能多接手一些重复调试，普通开发者就能多花时间打磨自己的小工具、小应用，让那些搁置的想法重新往前走。