AI时期的PM中枢竞争力正在被再行界说——Eval（评估体系）成为产物司理的新战场。本文深度整合OpenAI、Anthropic、Meta等顶尖AI公司的最好实践，揭秘如何构建灵验的AI评估系统，从Dataset野心到三种评分器的选用策略，手把手教你将马虎的产物需求回荡为可量化的质田主义。

OpenAI的CPOKevinWeil和Anthropic的CPOMikeKrieger，两家最顶尖AI公司的产物精良东说念主，说过简直一模相同的话：写Eval是AI时期PM最首要的本事。

作为一个时候布景有限的产物司理，我的第一反映是三个问题：Eval到底是什么？别东说念主是若何作念的？轮到我的AI表情，该若何从零运转建？

在找谜底的过程中，我读了不少材料，其中几份质地很高，值得单独拎出来说：

Anthropic本年1月发了一篇《DemystifyingEvalsforAIAgents》，可能是面前对于AIAgent评测最完整的一份工程实践指南。里面不光有方法论，还有多量他们在ClaudeCode等产物上踩过的真实坑。

Meta的PMDanielMcKinnon写了一篇《Show，Don’tTell》，从Llama团队里面的视角讲了一个PM若何动手写Eval，异常接地气。他有一句话让我印象很深：别给建模团队发PRD了，径直给他们一个Eval。

Braintrust连发了两篇——《EvalsAretheNewPRD》和《EvalsforPMs》，把”Eval取代PRD”这件事讲得很系统，还给出了一个PM可以径直参考的每周责任节律。

HamelHusain教过700多名工程师和PM作念Eval，他把学员们问得最多的问题整理成了一份FAQ，好多不雅点很敏锐——比如”如若你的Eval通过率100%，讲解你的Eval太轻佻了”。

此外还参考了OpenAI的官方评测文档和arXiv上对于Agent-as-Judge的论文。

我把这些材料里和产物司理最联系的部分索取了出来，按照一个刚斗争Eval的PM会当然产生的问题串起来，写成了这篇著述。全文围绕十个问题张开：

Eval是什么？

这事跟PM有什么关系？

一个Eval由什么构成？

三种评分器若何选？

拿到一个AI产物，若何从0到1建Eval？

Eval建好了，然后呢？

不同类型的AI产物，Eval有什么不同？

AI每次适度都不相同，Eval分数还特意旨吗？

有哪些常见的坑？

Eval除了保质地，还颖异嘛？

可以说这篇著述玄虚了Anthropic、OpenAI、Meta、Braintrust、HamelHusain等多方最好实践。文中每一个具体的不雅点、案例和建议，都标注了来自哪份材料，轻佻你去看原文。所有这个词参考起首的邻接放在了文末。

第一个问题：Eval是什么？

Eval，全称Evaluation，说白了即是给AI出考试题，然后自动阅卷。

你准备一组输入（模拟用户会若何问、若何操作），设好判断圭臬（什么样的回答算好），把输入丢给AI，拿输出和圭臬对一下，出个分。这件事自己并不复杂。复杂的是若何出好题、若何定好圭臬、若何让这套系统接续运转起来。

为什么需要这个东西？因为AI产物和传统软件有一个根本区别。

传统软件的逻辑是细则的。你写了一个按钮，点一下就提交表单，每次都相同。你可以写一条测试：”点了提交，表单发出去了没？”通过即是通过，失败即是失败。

AI不是这样。团结个输入，你今天问一遍和未来问一遍，谜底可能不相同。”质地好不好”这件事是主不雅的，边际情况多到数不清。传统那套”手动检验几个case”的口头，在AI产物面前就像拿渔网接水——漏得一塌朦拢。

是以你需要一套能自动跑、能反复跑、能遮蔽几百个场景的测试系统。这即是Eval。

第二个问题：这事跟PM有什么关系？

OpenAI的CPOKevinWeil和Anthropic的CPOMikeKrieger，两家最顶尖AI公司的产物精良东说念主，说过简直一模相同的话：写Eval是AI时期PM最首要的本事。

为什么是PM的事，不是工程师的事？

因为Eval的中枢不是时候完毕，而是界说”什么算好”——这是一个产物判断。你是阿谁最了了用户在乎什么、哪些边际情况首要、什么质地可以袭取的东说念主。工程师能帮你搭Eval的基础设施，但”出什么题、若何评分”这件事，应该由PM来定。

Meta的PMDanielMcKinnon说得很径直：当互助团队想让Llama作念某件事，他的回话是”别给我发PRD了，径直给我一个Eval。”因为Eval自己即是最精准的需求形色——它界说了什么算好、什么算不好，而且可以坐窝跑，跑完就知说念作念到了莫得（

传统的产物诞生进程是：发现问题→写PRD→出野心→排诞生→上线。你在PRD里写”模子回话应该简洁有用”——”简洁”到什么进度？”有用”若何臆想？这句话对工程师来说等于什么都没说。而且模子一更新行为就可能变，你的PRD还没改呢，产物也曾不相同了。

发现问题→写Eval来界说”好”的圭臬→团队针对Eval作念优化→上线。

你给工程师的指示从”请把这个作念好”形成了”请让这个分数上去”。

PRD写完就躺在文档里落灰了。Eval可以每次代码提交都自动跑一遍。一个活的、接续运行的质地圭臬，确信比一份落灰的文档有用。

第三个问题：一个Eval由什么构成？

搞了了Eval的三个组件，是PM作念这件事的首先。

1.Dataset（数据集）——“考试题”

你要测试AI的那组输入。需要遮蔽三类：你的产物十足不可搞砸的中枢场景、不常见但踩到就出大事的边际情况、你也曾知说念AI犯时弊的方位。

好多东说念主合计得准备几百说念题才能运转。无须。Anthropic说20-50说念就够起步了（起首）。HamelHusain教过700多个工程师和PM作念Eval，他的建议更径直：找一个最懂你用户的东说念主，花30分钟看20-50条AI的真实输出，标好哪条行、哪条不行——这即是你的最小起步（

2.Task（任务）——“考试公法”

这个词在Eval的语境里不是指”作念一件事”，而是指“这说念题若何考”——用哪个模子、用什么Prompt（辅导词）、参数若何设、要不要调用外部器具。Task界说的是从”输入进去”到”输出出来”的所有这个词这个词实施过程。

如若Dataset是试卷上的题目，Task即是”此次考试的公法”——开卷照旧闭卷、能不可用筹划器、考多永劫分。

PM不需要我方写代码搭Task。但你得知说念面前Task里用的是什么模子、Prompt是若何写的，况且能上手改改Prompt的措辞——这往往是影响产物性量最径直的变量。

3.Scorer（评分器）——“阅卷圭臬”

界说”若何判断好坏”。这是PM在Eval里最中枢的活儿。

最首要的原则：”好”不是一个全体，它是好几个维度拼起来的。每个维度要单独打分。

比如你作念了一个AI客服。一条”好”的回话需要同期作念到：回答准确、格调有温度、不啰嗦、妥当公司轨则。如若你把这四件事揉成一个总分，就很容易出现一种格外的适度：口吻优化上去了，但准确率掉下来了，你还不知说念。是以每个维度一个Scorer，各管各的（

那Scorer有哪几种？这就引出了下一个问题。

第四个问题：谁来”阅卷”？三种Scorer若何选？

Eval里有三种Scorer，搞显着它们各自擅长什么、什么时候该用哪种，是PM的基本功。

代码评分器（Code-basedScorer）：非黑即白

最轻佻的一种。用细则性的代码逻辑来判。回话里有莫得包含某个症结词？长度超没超限？生成的代码能不可跑？数据库里是不是果然多了一札纪录？

平允是快、低廉、适度平稳。坏处是稚子——AI如若用了你没猜度的口头把事情作念对了，它可能会误判成”错”。

AI评分器（LLM-as-Judge）：让另一个AI来打分

你先写一份评分圭臬（Rubric），开云体育(中国)官方网站然后让另一个AI按圭臬来给被测AI的输出打分。妥当那些代码没法判的马虎场景——比如回话有莫得同理心、口吻是否专科、是不是在胡编乱造。

平允是纯真，能处理盛开式的场景，还能大都量跑。坏处是每次适度可能不完全相同（毕竟判官自己亦然AI），而且需要如期和东说念主类巨匠的判断作念校对。

一，给AI阅卷古道一个”不细则”的选项。如若它信息不够，允许它说”我判断不了”，别让它硬凑一个分数出来。

二，每个维度用单惟一个AI来打分，别让一个AI同期判所有这个词维度。你让一个东说念主同期改数学和作文，质地确信不如分开改。

三，如期校准。光让AI打分非论不行，隔段时分要拿东说念主类巨匠的判断来对一下，看AI的打分有莫得跑偏。

东说念主类评分器（HumanGrader）：金圭臬，但也最坑

让真东说念主来审——领域巨匠、西宾过的标注员。质地固然最靠谱，但贵、慢，而且有一个大部分东说念主都不知说念的坑。

你安排三个标注员作念一说念二选一的题。适度两个东说念主选了A，一个选了B。你可能合计66%一致，还行。实践上不是。

你得看每一双标注员之间是不是一致：

1和2：都选了A，一致✓

1和3：一个A一个B，不一致✗

2和3：一个A一个B，不一致✗

三对里唯有一双一致，实践一致率是33%。而如若纯靠蒙，立时一致率都有50%。你的33%致使还不如瞎猜。

McKinnon的论断是：大部分东说念主严重高估了东说念主类评测的可靠性。如若你要作念东说念主类评测，判断圭臬必须写到极其精准以确保Inter-annotatorAgreement（标注员间一致性），不然等于白作念。

小结：三种Scorer若何组合

Anthropic总结成一句话：能用代码判的用代码，需要纯真性时用AI，东说念主类只用于考据和校准。

HamelHusain还有一个补充建议：用通过/欠亨过的二分法，别用1-5分。1-5分制下不同东说念主对”3分”和”4分”的意会差距太大，杂音太多。二分法反而逼着你把”什么算过”界说了了。

第五个问题：拿到一个AI产物，若何从0到1建Eval？

主见讲罢了。当今假定你是一个PM，面前有一个AI产物——可能是个客服机器东说念主、可能是个写稿助手、可能是个代码生成器具——你需要从零运转给它建Eval。若何走？

以下要领玄虚了Anthropic、Braintrust和HamelHusain的建议。

第一步：别等”准备好”，当今就运转

最常见的借口是”我的Dataset还没准备好”。别等了。

Anthropic的原话：Eval拖得越久越难建。早期阶段产物需求自然就能回荡成测试题，但等你的系统也曾在线上跑了很久，再回头补Eval，就等于要从一个活的系统反向推导”到底什么算得手”——这比重新建抑制多（

HamelHusain的建议更顶点：先花30分钟手动看20-50个AI输出，用一个最懂你用户的东说念主作为质地裁判——他管这个东说念主叫”BenevolentDictator（仁慈的独裁者）”。这即是你的最小可行Eval（起首）。

第二步：把你也曾在手动干的事情形成Eval

你每次发版之前，北京pk10官网是不是都会手动试几个case望望效用？把这些case写下来，即是你的第一批Dataset。

如若产物也曾在跑了，去翻bug纪录和客服工单。用户真实报过的问题是最好的Eval素材。按影响面从大到小排个序就行。

第三步：把”好用”拆成几个可以打分的信号

来看一个具体例子。

假定你在作念一个功能：说明烹调视频自动生成食谱。需求文档写着”生成的食谱应该准确好用”。但”准确好用”若何臆想？

你需要把它拆成几个具体的、可以打分的信号（这个例子来自Braintrust和McKinnon的著述）：

信号一：步地对不对？食材应该放前边，要领放后头。→可以让一个LLM-as-Judge拿着”正确步地”的示例来对比打分。

信号二：视频里提到的食材，食谱里是不是都有？→先用语音识别把视频里的食材提议来，然后作念个字符串匹配。这是纯Code-basedScorer能处置的事。

信号三：要领写得够不够简陋好读？→可以径直统计每句话的字数（Code-based），也可以让LLM-as-Judge参考好写法和差写法来对比评分。

三个信号，三个Scorer，永诀打分。你不再跟工程师说”把食谱作念好少许”，而是说”让这三个分数往上走”。

这即是PM在Eval里最中枢的责任：把马虎的产物需求翻译成具体的、可臆想的评分维度。

第四步：写好题目——别有歧义

Anthropic总结了一条判断圭臬：一说念好的Eval题，应该让两个领域巨匠永诀看完后，孤苦给出相同的通过/失败判断。如若两个东说念主看完都不细则若何打分，问题出在题目身上（起首）。

他们举了一个真实教会：审查Terminal-Bench（一个编程基准测试）时发现，有一说念题条目AI写一个剧本，但没指定文献存在哪。而Scorer默许剧本在某个特定旅途下。适度AI剧本写对了，但因为放的位置不对被判失败——这不是AI的错，是题出得有漏洞。

一个实用的考据方法：给每说念题写一个你知说念一定对的”圭臬谜底”（ReferenceSolution）。如若圭臬谜底都过不了你我方的Scorer，那是Scorer有bug。

他们在实操中还遭逢过更离谱的事：ClaudeOpus4.5在一个叫CORE-Bench的评测里一运转只得了42分。其后一个Anthropic的运筹帷幄员去细查，发现一堆问题——Scorer太稚子（模子回答“96.12”但Scorer条目精准到“96.124991…”才算对）、有些题真义马虎、还有些立时任务根本没法精准复现。把这些bug修完之后，分数从42%径直跳到了95%（起首）。

第五步：正反两面都得测

只测”AI应该作念X”的场景，会训出一个对什么都作念X的AI。

Anthropic在给Claude.ai作念搜索功能的Eval时吃过这个亏。一运转他们只测了”应该搜索”的场景——比如”今天北京天气若何样”。适度模子学到了一个失误策略：对简直所有这个词问题都先搜一下。但像”苹果公司是谁创立的”这种学问题根本不需要搜索，搜了反而更慢。他们其后加上了”不应该搜索”的场景，才在两个标的之间找到均衡。而且这个均衡调了好多轮才气好（起首）。

第六步：评适度，不评过程

好多东说念主的直观是去检验AI有莫得按”正确的要领”作念事——比如是不是按顺次调用了器具A、器具B、器具C。

Anthropic说这条路走欠亨。AI常常找到你根底没猜度的正确旅途，如若你只认我方野心好的那条路，等于在处分创造力。更好的作念法是只管最终适度对不对（起首）。

打个譬如：你点了个外卖，你在乎的是菜对不对、好不可口、准时不准时。骑手走哪条路，你管不了也无须管。

还有一条联系的原则：允许PartialCredit（部分得分）。一个AI客服正确识别了问题、也考据了用户身份，但终末退款操作没走通——这比一个启齿就崩溃的AI客服好得多。你的Scorer得能体现这种别离，不可轻佻狡黠只分”过”和”不外”（起首）。

第七步：跑完Eval之后，一定要我方读Transcript

这一条Anthropic反复强调，里面把它动作AI产物诞生的症结手段。

Transcript（跟踪纪录）是Eval一次运行的完整日记——AI说了什么、调了哪些器具、中间的推理过程是若何的。每次Eval跑完，不要只看分数。你得点开那些失败的case，看完整的Transcript。好多时候你会发现，不是AI作念错了，是你的Scorer赶走了一个实践上挺好的决议。

他们专门投了资源作念查抄Transcript的器具，团队成员如期花时分读。这个风俗帮他们持到了多量Scorer自身的bug。

Anthropic里面有一条文定：在有东说念主读完Eval细节和Transcript之前，不把任何Eval分数当劳动实。（起首）

第六个问题：Eval建好了，然后呢？

到这里，你也曾有了第一个可以跑的Eval。但Eval不是一锤子营业，它着实的价值在于接续运转——Braintrust把这叫作念EvalFlywheel（评测飞轮）（起首）。

飞轮的四个要津

不雅察（Observe）：把AI在线上的每次输入输出和完整Transcript都记下来。

分析（Analyze）：在日记里找规章。什么场景在出问题？哪类用户碰到的问题最多？

回荡成Eval（Evaluate）：发现了失败模式，就加进Dataset里。每一次线上翻车，都是一说念新的考试题。

更动（Improve）：团队针对更新后的Eval作念优化，发布更动，回到第一步。

这个轮回跑起来之后会越转越快：更多的线上数据养出更好的Eval，更好的Eval逼出更好的AI，更好的AI带来更好的体验，更好的体验带来更多用户和数据。

你的用户其实一直在”出题”，仅仅你可能充公：一个差评=一说念新题；用户裁剪了AI输出=一份”圭臬谜底”；用户对着团结个需求换了三种说法问=一个你还没遮蔽到的场景。

飞轮的四个老练度等第

零档：靠嗅觉。手动试几个、凭直观判断、等用户来投诉。

一档：有考试但不常考。有了一些测试题和圭臬，大版块发布前跑一遍。

二档：自动化。Eval接进了CI/CD进程，质地不外关的版块自动被拦下来。

三档：飞轮转起来了。线上的失败案例自动形成新的Eval题目，系统每周都在变好。

到第三档的团队，竞争上风是能鸠集的。大多数团队应该对准这一档。

两种Eval的区别

飞轮运转的过程中，你会当然遭逢两种不同性质的Eval：

CapabilityEval（本事评测）——爬山。回答的问题是”AI还能多作念好什么新的事“。通过率从低运转，给团队一座要爬的山。比如你的客服AI面前只可处理轻佻退款，你加入了”处理复杂的跨境退货”这种新题——一运转通过率可能唯有30%，跟着优化直快培植。

RegressionEval（转头评测）——守城。回答的问题是”AI还能不可作念好它昔日会作念的事“。通过率应该接近100%，掉了就讲解改坏了什么东西。

Anthropic讲了一个”毕业”机制：当一个CapabilityEval的通过率平稳在高位之后，它就可以转成RegressionEval——从”咱们能作念到吗”形成”咱们还能平稳作念到吗”（起首）。

但也要自在EvalSaturation（评测饱和）的问题——通过率到100%之后，这个Eval对更动就莫得辅导作用了。代码审查公司Qodo一运转对Opus4.5不太舒适，因为他们用的Eval太轻佻，莫得遮蔽到模子在复杂长任务上的越过。其后换了一套更难的Eval，才看清了实践的培植（起首）。

一个参考的PM周节律

Braintrust建议了一个AIPM可以参考的每周节律（起首）：

周一：翻线上Transcript，象征20条有问题的AI输出。

周二：从里面挑出5个最典型的，加进Dataset。

周三：用更新后的Eval跑一遍面前列案和候选更动决议，对比。

周四：看适度。好了照旧差了？哪个维度培植了，哪个古老了？数据决定发不发。

周五：飞轮又多转了一圈。

第七个问题：不同类型的AI产物，Eval有什么不同？

前边讲的原则是通用的。但不同类型的AI产物，Eval的侧重心如实不相同。Anthropic按产物类型总结了各自的作念法（

对话类（客服、销售、教会……）

对话类AI的特殊之处在于：不光要看”任务作念罢了没”，还要看”作念的过程体验若何样”。对话自己即是产物的一部分。

是以它的Eval无为是多维度的：工单有没关连掉（Code-basedScorer）、对话轮数有莫得卓越上限（Code-basedScorer）、口吻有莫得同理心（LLM-as-Judge）、有莫得按计策处事（LLM-as-Judge或Code-based）。

另外，对话类Eval常常需要让一个AI来演出用户。你总不可每次测试都找真东说念主来聊。Anthropic在对都审计表情中即是这样作念的——用一个AI模拟多样用户脚色来跟被测AI对话。

真实案例：Descript（视频裁剪器具）的AI助手从三个角度作念Eval：别搞坏底本的东西、作念我让你作念的事、作念好它。从东说念主工打分起步，直快搬动到LLM-as-Judge，再加上如期东说念主类校准。当今爱戴着两套Eval——一套管质地基准，一套管Regression。

真实案例：Bolt.new是等产物也曾有多量用户之后才运转作念Eval的。三个月内搭好了一套系统：用静态分析给代码打分，用浏览器Agent来测试生成的app能不可用，用LLM-as-Judge来评估指示驯服的质地。

编码类

代码的Eval相对释怀，因为”对不对”有自然的判断圭臬：能跑吗？测试过了吗？

行业里最主流的基准测试SWE-benchVerified即是这个念念路——给AI一个真实的GitHubissue，让它修，修完跑测试，过了就算对。一年之内，前沿模子在这个测试上的得分从40%涨到了80%以上。

但只看”跑没跑通”不够。你可能还想看代码质地、安全隐患、AI过程中有莫得作念饱和的事。这些就需要加上LLM-as-Judge或静态分析器具。

检索/运筹帷幄类

这一类最难作念Eval，因为”什么算好”自己就莫得唯一谜底。作念阛阓调研、作念收购尽调、写科学论说——每种”好”的圭臬都不相同。

Anthropic推选组合打分：Groundedness（AI说的话有莫得出处可查）、Coverage（一个好谜底该遮蔽的要点有莫得遮蔽全）、SourceQuality（用的起首是巨擘机构照旧空隙搜到的第一个）。

第八个问题：AI每次跑出来的适度都不相同，Eval分数还特意旨吗？

这是作念Eval一定会碰到的问题。团结说念题，AI此次作念对了下次可能作念错。那分数到底能讲解什么？

Anthropic先容了两个主义来意会这种波动（起首）：

pass@k：k次里至少得手一次。k越大分越高。妥当”只须有一次作念对就行”的场景——比如代码生成，只须有一个决议能跑通就够了。

pass^k：k次全部得手。k越大分越低。妥当用户祈望每次都靠谱的场景——比如客服，用户不在乎你”平均得手率90%”，他在乎的是这一次能不可帮到他。

如若你的AI单次得手率是75%，让它连气儿作念对3次的概率唯有0.75×0.75×0.75≈42%。

两个主义在只试一次的时候是相同的。但跟着历练次数增多，它们讲的故事完全相悖：一个趋近100%，一个趋近0%。选哪个取决于你的场景。

第九个问题：有哪些常见的坑？

在作念Eval这件事上，踩过坑的东说念主不少。提前知说念能省好多时分。

别试图臆想”AI聪不贤慧”。那是MMLU、GPQA这些学术基准该干的活。McKinnon明确说过：创建那种基准是”利害的运筹帷幄级挑战”。你的Eval应该只回答一个问题——我的产物在这个具体场景下作念得好不好（起首）。

别让太多东说念主一齐野心Eval。东说念主多嘴杂，终末出来的决议一定是折中的、不聚焦的。McKinnon说他好多Eval即是我方一个东说念主写的（起首）。

别拿来别东说念主的Eval径直用。McKinnon反复打发：再驰名的开源基准也可能有错。拿到任何Eval之后，第一件事是手动抽几个样本望望适度合不对理。他在团队用的好多Eval里都发现罪过误，而且这种失误从数字上根本看不出来（起首）。

别只在发版的时候跑一次。跑一次的Eval不是质地体系，仅仅一次抽检。模子在变、数据在漂移、新的边际情况在冒出来。Eval得接续跑。

别盯着分数不看业务。HamelHusain有一个判断圭臬：如若你的Eval通过率100%，梗概率讲解Eval太轻佻了。70%的通过率可能反而更讲解问题（起首）。

别用脏环境跑Eval。Anthropic发现过Claude在Eval里偷看上一轮历练残留的git纪录来”舞弊”的情况。每次跑历练必须从干净的环境运转，不然适度不着实（起首）。

第十个问题：Eval除了保质地，还颖异嘛？

好多团队作念了Eval之后发现，它的价值远不啻”确保质地”。

模子切换变快了。每隔一两个月就有更强的模子出来。莫得Eval的团队要花好几周手动测试。有Eval的团队跑一遍就知说念新模子哪些方面更强、哪些古老了，几天就能完成切换。Anthropic说过，有Eval的竞争敌手可以”在几天内细则新模子上风、诊治Prompt并完成升级”（起首）。

团队解析对都了。团结份产物文档，两个工程师可能对”边际情况若那儿理”意会完全不同。Eval径直给出谜底，消亡歧义。

产物和研发之间有了共同讲话。Anthropic的原话是Eval可以成为”产物和运筹帷幄团队之间最高带宽的疏浚渠说念”——它界说了运筹帷幄者可以优化的具体主义，比任何PRD都精准（起首）。

更多东说念主可以参与更动AI。Anthropic说”最接近用户和产物需求的东说念主最妥当界说得手圭臬”。PM、客户得手、致使销售都可以孝敬Eval用例。让他们参与进来——更好的作念法是主动给他们器具和权限（起首）。

终末

如若你今天只可作念一件事，那即是：选你产物里的一个AI功能，找10条真实的用户输入，我方判一下AI的回答哪条好、哪条不好。

McKinnon的原话是：作念了比完满更首要。你的第一个Eval可以很小、致使是一次性的，只须它能帮你判断模子是不是在解决用户的问题就行（起首）。

Eval不是什么高尚的时候活，它是一种念念维口头的更动：从”我合计AI作念得可以”形成”我突出据讲解注解AI作念得可以”。越早完成这个更动越好。

参考起首

Anthropic:DemystifyingEvalsforAIAgents

OpenAI:EvaluationBestPractices

OpenAICookbook:GettingStartedwithOpenAIEvals

HamelHusain:LLMEvals–EverythingYouNeedtoKnow

Braintrust:EvalsAretheNewPRD

Braintrust:EvalsforPMs

DanielMcKinnon(MetaPM):Show，Don’tTell

arXiv:Agent-as-Judgepk10官网

轮盘app官方网站下载

• 正在
• pk10官网
• 取代
• PRD
• Eval