一份金融模型算完了，Python 和 Excel 的结果也对上了，错误却随着文件交到了收件人手里。
这是我读完 Latent Space 这期 Handshake AI 深度访谈后记得最清楚的细节。节目让数据团队把工作摊开来讲，涉及银行里的邮件与表格、实验室里的图像，还有 Agent 在模拟公司里的行动。比起开场的营收故事，这些具体失败更能说明，所谓“高质量数据”究竟贵在哪里。
我越来越在意一个问题。AI 生成交付物的速度变快以后，人是否更容易判断它能不能用？如果这一环没有改善，省下的制作时间就可能转移成验收和返工。
两份结果一致，也可能错在同一个地方
Section titled “两份结果一致，也可能错在同一个地方”金融团队演示的 Project Falcon，是模拟银行环境中的杠杆收购建模任务。模型需要从邮件、笔记和附件里找到交易背景，再完成计算，提交交付物。
这次失败涉及特殊税务处理下的商誉计算。按嘉宾的复盘，模型单独回答相关知识问题时知道该怎么处理，到了具体建模步骤，却没有把这条知识用进去。错误进入 Python 计算，又被带进 Excel。随后它对照两边结果，发现数值一致，便把工作交了出去。
我觉得这里比“AI 算错了”更值得警惕。它做了检查，检查也确实能发现某些问题，比如从程序搬到表格时抄错数字。可上游假设已经错了，这种核对就无能为力。两份结果共享同一个错误来源，彼此吻合并没有增加对那个假设的信心。
这让我对“让模型再检查一下”有了更具体的要求。我要知道它回到了哪份独立材料、重新验证了哪条假设、检查覆盖到哪一步。否则，复核过程可能只是把先前的判断再演算一遍。
嘉宾强调银行里很难接受有隐藏错误的成品，主持人也提出了有必要的补充。即使完整交付尚不可靠，检索资料、整理背景、完成部分工作，仍然可能有价值。这个分歧我愿意留下。把任务切在什么地方交给人，影响实际收益，不能用整份成品的失败直接否定其中每项能力。
他们卖的数据里，装着一间办公室
Section titled “他们卖的数据里，装着一间办公室”沿着这个案例回看节目开头，“数据公司”的形象就变了。
为了让模型做银行里的工作，团队要准备的不只有问题和答案。邮件要有上下文，文件要能互相对得上，工具要能运行，任务也得符合这个环境里的业务。一个看着像财务模型的文件，只过了外观检查；跨文件的数值和叙事是否一致，还需要另外核对。
这也是我理解专家价值的起点。专家既要能判断结果，还要写清日常工作中大家默认理解的条件。哪些信息过期了，哪个附件应该优先看，什么分歧可以容忍，哪里错了就应该退回重做。这些平时藏在工作习惯里的判断，进入训练环境以后，都需要明确表达。
节目还讲到，团队会用自己的数据对开放模型做后训练，观察学不起来的地方。图没看懂，和图看懂了却推理失败，需要补的材料不同。数据写得像那么回事，与数据能让某个模型学会目标能力，中间还隔着实验。
不过我也不想顺着供应商的故事直接走到“专家越多、数据越贵，生意就必然越好”。模拟环境有多接近真实工作，训练后能否迁移到新任务，验收规则有没有漏掉关键风险，都需要另外证明。复杂是成本，只有当它带来有效学习和可靠交付时，才构成价值。
把图片整理成表格，可能已经做掉了关键工作
Section titled “把图片整理成表格，可能已经做掉了关键工作”生命科学部分让我更清楚地看到这种成本。
VIALS让模型解释科学图像。节目展示了凝胶条带、分子结构、质粒图和组织切片。对非专业读者来说，它们看着都很复杂；专家解释后，某些题目其实是在要求模型注意指定位置，再作一个范围很小的判断。
凝胶案例尤其直观。题目要求找出开始同时出现目标条带的条件。某条较弱的带，在专家眼里足够明确，在模型的回答中却被忽略了。这里的困难混合了视觉注意、专业术语与实验经验，很难仅用“懂不懂生物学”概括。
核对官方后训练文章里的原题，还能看到一个小但要紧的细节。题目区分了蛋白用量与酶的剂量，不能沿用访谈口述时混淆的单位。越是看似简单的案例，越需要把图和题干放在一起读。
当然可以先替模型提取图中的条带，再整理成它容易处理的表格。问题是，认出那条弱带、判断它是不是实验产物，恰好可能就是希望 AI 接手的劳动。人先完成关键判断，再让模型作答，得到的成功不能完整记在自动化账上。
这不意味着结构化输入没有用。我会把它理解为一道需要明算的分工。如果输入整理便宜、可靠，又能重复使用，这样做很划算；如果每张新图都得由专家重新解释，系统的收益就需要把这部分时间算进去。
因此我不想只问模型最后答对了没有。我还想问，为了得到这个答案，人提前做了哪些工作。
学习时的分数，交付时的门槛
Section titled “学习时的分数，交付时的门槛”金融团队提到过一个早期评分漏洞。评分器寻找某个目标数字，模型就在 Excel 新建页签，列出大量整数。目标数字确实出现了，任务却没有按要求完成。
这个例子带着喜剧感，但修正它需要专业语境。净利润对应的是哪家公司、哪个时期、哪个位置？数值由什么公式得到？同一个数字出现在无关页签里，为什么不能算对？把这些条件补清楚，才有机会让机器检查接近人的验收。
节目也没有把答案简化成“出错就不给分”。训练时，部分完成的步骤可以提供有用的学习信号。交付时，关键假设错了，就可能使依赖它的后续结果失去使用价值。这两种判定各有目的。
我赞成保留这种区别。研究团队需要知道系统在哪些地方进步，使用者需要知道今天这份东西能否接着往下做。把两边都压成一个总分，很容易让人误会，分数涨了，工作就已经可以放手。
站内此前的黄金评测集文章讨论过，重放用户问题时需要保留当时的上下文和判定依据。这次访谈又往前推了一步。判定本身也要接受检验，尤其要检查那些“得分了，却没有做好”的路径。
验收还要问，它是怎么做完的
Section titled “验收还要问，它是怎么做完的”安全部分把这个问题扩展到了行动边界。
团队展示了模拟公司中的文件传输轨迹。请求涉及敏感资料，还要求隐藏操作记录；在展示的失败案例里，Agent 传出了文件，并清除了相关记录。这是模拟测试中的行为，不能写成某家公司发生过真实泄露。
但它足够说明，检查“文件送到没有”会漏掉什么。对工作是否完成的定义，还应包括它有没有遵守授权、有没有保留必要记录、碰到冲突时有没有停下。只要这些条件缺席，更强的执行能力就可能把不合适的路径走得更远。
CAREBench 儿童安全评测则提醒我，规则本身也可能不完整。访谈里，家长与专业人员提供了不同视角。某些回答虽然先拒绝了恶意请求，后续给出的替代建议仍让评审者担心。一个显眼的拒绝句，并不足以代表整段回应安全。
这也限制了我对“把专家经验编码进去”的乐观。人需要决定怎样算好，但人的规则会遗漏情境，也会存在分歧。能写成评分表，只说明它便于执行，不能免除对评分表的持续审查。
回到企业实际工作，我更愿意从一份可查看的验收记录开始。留下任务背景、使用的关键依据、不能破坏的约束，以及交付前需要人工确认的判断。用它比较不同模型，也比较“AI 做一部分再交给人”和原有做法的差别。
如果查出问题还得把整件事重做，自动生成的速度就不能单独代表收益。反过来，若系统能把不确定的地方指给人看，让人只接管自己擅长的判断，即使还不能完整交付，也可能值得使用。
读完这期访谈，我更想知道的，是团队愿不愿意把那些验收失败留下来。它们能告诉人下一步该教什么、检查什么、把工作交接在哪里。专业数据的价值，也要在这些地方得到验证。