基本信息

来源摘要/节选

公开展示已截断至最多 800 个字符；请访问原始来源查看完整上下文。

大家好，我是老刘 之前不是发了篇文章说我退订了Trae，改用copilot加第三方的模型套餐。 我退了Trae，换上了这套AI工具链 文章中提到我的三层大模型选择策略，于是有很多人私信问，老表是看什么评分去选择实际编程中使用的大模型的？ 那我们就来聊聊，在各种评分刷榜的时代，我们应该通过哪些测评来真实地评估大模型的工作能力。 注意，老刘的策略和实际选择都是以Flutter项目为主要的使用场景，仅供大家参考。 没有任何测评能完全代表模型在实际工作中的体验 因为所有的测评本质上都是搞一个试题集。根据大模型在某个Agent中做题的结果进行人工打分，或者基于固定的测评结果进行打分。 所以这些测评其实只能代表模型在特定Agent下在解决特定类别问题时的表现。 而你的实际工作场景，大概率和这个测试的问题集是有比较大的差异的。 以老刘工作的场景举例： 我们开发一个需求的输入是产品经理给出的PRD文档，以及UI/UE设计师提供的界面设计。 而这些文档中，包含了大量我们日常工作中可以用简单的词所代表的上下文语境。 比如文档中提到的单品页或者活动页，可能是特指今年618或者双11的商品或者活动。 所以为了解决这种问题，我们在实际开发中，会使用大量的skill或rules去要求大模型，把不明确的概念让程序员明确。 如果想真正地评估一个大模型在我们实际工作的环境中的表现，正确的做法是，把过去已经发生的多个需求和bug整理成一个我们私有的测试集。 通过人工去评估大模型在我们的工作环境下，针对我们私有测试机的表现如何。这其中不仅仅包含功能是否完成、bug是否解决，还包含生成的代码是否符合我们整个项目的编码规范和上下文习惯。 那测评是不是没有参考意义呢？ 有人问了：老刘，你说的这些我听不懂，我就想知道到底看啥评分？ 其实也不是没有参考意义。 本质上是能真实地反映大模型在某个特定的问题区间的能力的。…

来源说明

当前只保存了公开页面节选，不代表原文全文。请以原始来源为准。

本页只呈现已做哈希绑定的来源证据，不包含基于旧正文或缺失原文的扩展推断。