Tulsee Doshi 给想学模型评估的产品经理提了一个很小的建议，先写五条提示，自己判断回答好不好。
读到这里，我比看到“PM 又有价值了”更感兴趣。五条提示听起来很寒酸，却会让人立刻遇到一件难事。同事觉得回答不错，你觉得不行，你究竟能指出哪里不行吗？能把理由说到别人也可以检查吗？
Lenny 对 Tulsee 的这次访谈谈了模型研发、评估、产品押注和团队工作。她负责 Google 前沿模型的产品工作，提供的是实验室里的经验，并非一份证明 PM 就业反弹的市场报告。我读完更愿意把标题里的职业讨论换成一个具体问题。原型越来越容易拿到手以后，团队里有没有人为它应该达到什么程度负责？
五条提示会逼你解释自己的品味
Section titled “五条提示会逼你解释自己的品味”
Tulsee 把亲手使用模型形成的感觉称为 vibes。她希望 PM 持续尝试自己关心的任务，知道模型在哪里让人惊喜，在哪里还差一点。这种熟悉很有用，但“我觉得这个更好”还不足以帮助团队做决定。
她建议从小规模评估开始，也允许自己先当评审。这一步能让人把模糊的不满意说清楚。
假设我们在做客服助手。用户问能否退款，模型答得礼貌、流畅，还把政策总结得很完整。产品经理如果只看表达，很容易判它通过。但用户的订单究竟是否符合条件？缺少购买日期时，模型有没有先问？它是在解释规则，还是擅自替公司承诺了退款？这是同一个回答里不同的质量问题。
把这类差别记下来，才有机会与工程师讨论怎样改、改完怎么验。也能发现自己先前说的“体验不好”，其实混着政策不清、工具拿不到数据、模型不肯追问等不同原因。
我赞成从五条提示开始，但会给这个建议加一道边界。它们可以帮助发现问题、试出评判标准，无法代表所有用户，更不能单独证明上线可靠。熟悉的任务让人长出直觉，也容易让人只盯着熟悉的人和熟悉的失败方式。接下来需要补的，恰恰是自己不会顺手想到的案例。
评估标准会决定谁的失败被看见
Section titled “评估标准会决定谁的失败被看见”访谈里让我停下来查原始资料的，是肤色量表的故事。
Tulsee 回忆，团队曾使用 Fitzpatrick 量表评估产品，后来与 Ellis Monk 合作，引入了更适合相关技术评估的肤色尺度。Google 的研究说明提醒，Fitzpatrick 最初服务于医学皮肤分类；Monk Skin Tone 官方介绍则说明了十色阶量表及其代表性考虑。
这个故事值得留意的地方，是量表的用途。原来的尺子为另一种目的设计，把它借来衡量产品，就可能把一些用户之间的重要差别压平。等到统计结果出来，看上去表现不错，也未必说明那些用户获得了同样好的体验。
这使我对“PM 要有品味”多了一点警惕。谁的品味？谁能进入评审样本？谁遇到的问题会被归入偶发异常？如果这些问题没问过，再精细的评分表也可能只是在认真衡量一个偏窄的世界。
放到客服例子里，光测试表达清楚、资料齐全的用户就不够。含糊的描述、缺失的信息、例外政策，都值得单独看。这里的行动很朴素，保留具体失败案例，再检查现有分类有没有让某些失败消失在平均表现里。
十色阶当然不能保证所有肤色相关问题得到解决。这个故事对我的启发是，评价方式本身也需要被评价。不能因为分数可以算出来，就提前认定自己问对了问题。
60/20/20 应该放在研发桌上
Section titled “60/20/20 应该放在研发桌上”Tulsee 用 60/20/20 描述产品开发中的押注。大部分能力当下就能工作，一部分接近可用，还有一部分只能看到希望，需要未来模型进步。她也特意说明，数字可以调整。
我喜欢这个框架承认了两件同时存在的事。产品要在今天给人价值，也值得为尚未成熟的能力留位置。对“预测三个月后模型会怎样”这种要求，她自己都没有给出确定答案。
不过，这里很容易混淆两个比例。研发计划里有多少投入用于探索，与用户执行一次任务会有多少机会成功，是不同的问题。不能把“六成现在能工作”读成允许向用户交付一个只完成六成的承诺。
继续用假设的客服助手来想。检索政策、引用来源可以进入常规服务；需要人工确认的退款建议，可以做受控试用；跨系统自动退款则可以留在实验里。三者可以共同存在于产品规划中，用户看到的权限和承诺却应该有清楚区别。
未来模型也许会补上今天的能力缺口，团队仍要为当前失败设计去处。是补问、转人工，还是明确告知无法完成？把这些决定写清楚，比给项目贴一个“等待下一代模型”的标签更有用。
因此，我会把这个框架当成讨论资源分配的方法。每个探索项都应该回答，当前卡在哪里，凭什么认为有改善希望，观察到什么结果才扩大使用。倘若缺的是拿不到的数据、没有授权的操作或始终说不清的用户需求，等模型升级未必能解决。
旧规则也需要接受新模型的检查
Section titled “旧规则也需要接受新模型的检查”访谈还有一个提醒很容易被快速略过。围绕旧模型搭起的僵硬系统，可能妨碍新模型发挥能力。
Tulsee 所说的 harness，包括系统指令、工具、技能和模型可以访问的上下文。我之前在关于 harness 的概念梳理里讨论过这些组成部分。这次访谈让我更想追问它们的去留。
一条规则可能来自某次真实失败。模型当时总忘记某一步，于是团队加了提醒；它不擅长规划，于是流程被拆得很细。规则留下来了，导致它存在的能力缺口却可能已经变化。如果只把新模型塞进原流程，再看总分，团队未必知道自己测的是新能力，还是旧补丁的限制。
我的做法建议是，在保留权限和数据边界的前提下，用同一批真实任务比较现有配置与简化配置。先移除某类补救指令，观察结果和失败记录，再决定是否保留。这里需要耐心，不能把“让模型自由发挥”当成免检理由。
尤其要区分两类东西。为了弥补能力不足而加的流程，可以随能力变化重测；涉及授权、支付、隐私和审计的控制，承担的是责任边界。模型更聪明，本身不足以成为删除后者的理由。
这也接上了之前关于代理组队与管理责任的讨论。执行者能自己安排更多步骤以后，人仍然得决定目标、权限以及怎样确认结果。只不过，具体操作方案需要更经常地被重新检查。
也要有人替团队减少无用的产出
Section titled “也要有人替团队减少无用的产出”我对这次访谈保留意见最多的，是工作负担的部分。Tulsee 认为混乱和令人厌烦的工作会带来倦怠，期待 AI 帮人减轻杂务。她同时坦承，团队可持续的工作方式仍是自己正在思考的问题。
后一句很关键。减轻杂务是值得争取的改善，热爱工作也很重要，但它们都不能替组织回答，究竟应该接多少任务、放弃什么，以及什么时候可以停下来。
访谈谈到 AI 生成文档时，这个问题变得格外具体。模型适合协助汇总反馈和数据，人需要给出洞察。我还想追问。文档交给别人之前，写的人有没有说明它支持哪个决定，有没有核对关键材料，有没有删掉并不影响判断的重复内容？
如果生成省下的时间，全由同事用阅读和核验补回去，团队未必因此轻松。原型也一样。做出更多可以演示的东西，并不自动意味着应该把它们交给别人逐个评价。
访谈还提到 Tulsee 参与过 Flash Teams 研究。我查了Stanford 原论文，它研究的是付费人类专家的临时协作，不能直接当作 AI 代理自发组队的实验。它在这里更有启发的地方，是任务之间的输入、输出和交接值得认真设计。谁接下来的是什么，前一步要交到什么程度，都会影响整个团队。
读完这次访谈，我更想看到这些可以被检查的工作。拿出原型的人，同时拿出评判它的案例；提出未来押注的人，说明今天怎样处理失败；增加规则的人，愿意在条件变化后重新检验；发送文档的人，先替读者做完筛选。
如果产品经理愿意承担这些责任，“会做判断”才有了可以共同讨论的内容。头衔也许会变，工具还会继续变，这些工作总得有人认真做。