聚鑫汇游戏官网

新智元报道

设想一下：

你用Claude Code手搓了一个小应用，顺便给它接了个AI客服。

本想让它自动解答用户「怎么登录」「会员服务有啥内容」之类的基础问题，好让自己当个甩手掌柜。

结果客服确实能聊天了，但你却沦为了它的全职陪练：

回答不准，赶紧补一句提示词；解释太啰嗦，再加一条限制。

更让人崩溃的是，每改一句提示词，你都得把常见问题重新问一遍，生怕它顾此失彼，刚修好一个问题，却把原本答对的又改坏了。

于是，用AI写代码省下的时间，又有不少还给了一轮轮的人工调试。

针对这类反复调试的麻烦，9月28日，Anthropic官方发布了一份调优指南。

这份指南的核心思路就一句：反复测试、修改这样的活，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会撤回本轮修改；如果改完后表现反而变差，也会回退。

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

这能帮助发现「只会做熟题」的问题，但不代表从此高枕无忧。

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

官方客服案例

成本降至约1/5

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

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

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

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

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

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

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

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

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

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

先定好愿意掏多少实验费，再决定让AI跑几轮，才更踏实。

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

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

首先，是洞察用户。

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

其次，是把控标准。

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

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

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

最后，是做权衡。

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

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

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

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

参考资料：

https://claude.dev/blog/automating-eval-design-and-hillclimbing/?utm_source=chatgpt.com

编辑：元宇