本期节目《AI科学家的崛起》讨论了以“可评估性”为导向设计代理/AI产品的重要性。核心论点指出，简单回答业务问题的AI设计不佳，因为缺乏可验证性，导致用户无法判断答案的正确性。优化评估的方法是借助AI辅助标注与主动学习策略，展示推导路径和证据，使专家快速验证，收集有用的日志。代理应作为协作伙伴，而非完全自动决策者。节目还提供了关于评估课程的信息，讨论了相关基础设施和开源实践。 #### 内容简介 本期播客《The Rise of the AI Scientist》由 Hugo Baund Anderson 采访常客 Hamel，围绕“以可评估性（evals）为导向”来设计代理/AI 产品展开讨论。核心论点包括：将聊天式代理设计成直接给出业务数值（如“上季度净收入是多少”）是糟糕的，因为缺乏可验证的推导路径；真正的评估瓶颈在于人工“看数据”（审查 trace/样本），可用 AI 辅助标注与主动学习来减轻负担；产品应从一开始就展示推导证据（SQL、notebook、语义层等），并把评估嵌入错误发现与根因分析流程；在小规模原型上用 10–20 条 trace 即可启动评估；技能重用有上限，公共“元技能”需要针对具体用例定制；数据科学家在生成式 AI 时代仍然关键，代理应被视为协作伙伴而非完全自动化的判官。节目还提到相关课程、开源仓库与具体工具（如带证据链的 notebook、webmcp 式笔记本、eval skills 仓库）和实际案例（工伤赔偿医学报告自动化、远程笔记本协作等）。 #### 社区观点 观点一：很多人认同“不得只给单一数值”的论点，强调可解释性与证据链对业务采信至关重要；观点二：也有人觉得用户追求简单、快速答案，过多展示技术细节会降低体验，需要在可评估性与易用性间做产品权衡；观点三：关于 evals 的瓶颈，社区普遍同意“看数据”最耗时，但对是否能完全用自动化筛选替代人工审查存在分歧——多数建议混合 AI 辅助标注+人工审核；观点四：有人提出实际运维与人才成本是最大障碍，认为组织应先评估团队是否具备数据科学与工程能力再决定自建代理；观点五：社区支持把评估嵌入日常流程（错误发现、transition failure matrix、traces 分析），而非当成独立学术任务；观点六：对技能复用持谨慎态度——共享“元技能”有价值但必须针对业务定制，否则治理和评估会失效；观点七：多数人欢迎公开课程与开源工具（eval skills、reverse-engineer-side-skills），认为这能帮助团队快速建立评估方法论与实操能力；观点八：还有人警告用户依赖风险，强调要设计机制防止“关掉大脑”完全信任模型，并保留人工复核流程。 #### 内容导读 要理解本期内容，先抓住三个核心：第一，设计代理时必须把“可评估性”作为出发点——代理给出的结论需要可追溯的证据链（SQL、notebook、语义定义、中间计算），否则业务用户无法验证，容易产生信任与滥用问题；第二，evals 的实际工作重心在于“看数据”与找错：用 trace、transition failure matrix 与探索性数据分析定位流程痛点，再用 AI 辅助标注与主动学习呈现高价值样本以提高审查效率；第三，产品化落地需要实用策略：从小样本（10–20 条 trace）启动原型、把评估嵌入日常错误分析流程、把代理当作会写并执行代码的协作伙伴而非全自动裁判，并在元技能共享与用例定制之间取得平衡。换言之，关键信息是把评估与证据展示放在产品设计核心，用混合人机流程和工程化手段把“看数据”的成本降下来，同时保留人工复核与治理以控制风险。