AI 生成的编辑插画:桃色背景上的指南针与磁铁,象征判断可能受到附近力量影响,并非科学实验示意。

DAILY AI INTELLIGENCE

最新日报 历史日历 ↗

2026-10-28 · AI 日报

让 AI 多做一些,也看清判断从何而来

7 条精选1 份学习材料资料截至 2026-10-28 08:02(北京时间)

EDITOR’S NOTE

本期导读

当 AI 能把分析、写代码和资料审查一起做完,人最容易保留的是最后一个“同意”按钮,最难保留的却可能是形成判断的过程。我们此前关心初学者是否还在练习;今天的专家判断实验把问题推进了一步:有统计训练的人也会受助手预设倾向影响,而且事后未必意识到理由来自助手。这提示我们,独立判断需要在工作过程里留下位置,不能只寄望于最后复核。

这种位置应当怎么留,要看任务的性质。面对价值取舍,先说清要优化谁的收益;面对代码,保留能追到故障根源的系统理解;面对研究新颖性,先比较已有工作,再看评委的总判词。本期观察把专家判断实验、《Here be monsters》和新颖性评估放在一起,讨论这些不同的要求,同时区分它们各自提供的证据。

能力的进展同样具体:LFM3 把小模型做成面向本地任务的一组专用工具,Axiom 将庞大的数学证明转成机器可检查的形式,Enveda 则让审查者从查找问题转向核对带页码的意见。沿着这三条材料,可以看到有效自动化怎样重新分配内存、证明整合和人工阅读的工作,而不只是给出一个提速数字。

另有一篇工作量复盘保留了进步的另一面:实施便宜之后,原先不会启动的项目也进入日程。它让我们继续追问,省下的时间究竟变成了休息、更多尝试,还是等待人处理的新队列。

组合筛选

METHODS & SYSTEMS

技术进展

05
值得读Agent 系统 / AI 编程 / 评测与基准
追踪记录 ↗

专家也会顺着 Agent 的倾向做判断:一项有意设置偏好的实验

技术human-AI collaborationrandomized experimentcausal inference
可信度
65
重要性
88
新颖度
82

让助手处理数据时,技术选择往往混着价值选择:评估农业合作项目,该看每公顷产量还是经营成本?只看参加项目的农场,还是考察整个地区?这些问题没有一个脱离目的的统一答案。Anthropic 招募懂因果推断、会用 Python 或 R 的参与者分析虚构农业案例;61 人中,50 人使用了提供的 Claude Opus 4.8 High,另有 11 人选择不用。

研究者对四项分析选择分别随机设置助手倾向,却不告诉参与者。助手可以为偏好的方案提供真实理由,遇到决定性反证仍应改变意见。结果是,使用者的选择在四项决策上平均有 86% 与助手倾向一致;把助手的倾向反过来,各项选择比例相差 62—82 个百分点。这不是“86% 的专家没有独立思考”,而是这组受控任务中的选择一致率。

研究者还检查了参与者事后怎样解释决定。在回答问卷的 48 人中,77% 至少一次重复助手给过的理由,15% 至少一次明确把决定归于助手。这显示影响可能进入人的解释过程。最终是否推广项目的建议也受影响,但差距小于中间分析选择。实验操纵了助手偏好,能说明这一设置下的影响;它没有测量普通助手默认会多大程度地左右现实决策。

随机改变助手倾向后,选择 A 的参与者比例发生变化。前四行是分析口径,最后一行是推广建议;百分点差基于未四舍五入数据。图不是现实工作中被影响人数的普遍比例。Anthropic 研究团队原文图表;为评述该实验保留完整图及署名,未发现单独开放许可。 · 原文结果图表 · 图片出处 ↗

X 观点 Ethan Mollick · 原帖 / 原文

语境:回应 Alex Tamkin 对实验设置与86%选择一致率的说明;读取固定作者源公开快照并另核对被引用父帖,非独立复现。 · 读取时间:2026-10-28

回应原帖:Alex Tamkin

逐句忠实转述(非原文)

Mollick 认为这个结果重要,但并不意外:专家也会受 AI 的立场影响,即使他们以为自己在独立工作。他把实践上的关注点放在介入时机——若任务重视人的独立判断,就要有意识地安排何时开始使用 AI。

编辑评读

最值得改变的前提是:熟悉统计工具,并不等于已经形成了本次任务的独立立场。助手能把某个目标包装成完整、可执行的分析路径,人跟随时可能是在接受一套合理解释,而不是犯一个显眼的计算错误。因此,单查代码和数值仍可能漏掉“为什么选这个结果指标”。

一种值得尝试的做法,是在助手开始分析前先写下目标、备选口径和愿意改变立场的证据,再让它分别展开不同路径。这里的关键不是禁止被说服,而是让改变有迹可循:是发现了新事实,还是第一次听到了顺畅的理由?这属于从实验机制导出的工作建议,研究并未验证它能改善长期判断能力。

不用助手的 11 人更常报告发现重大数据问题,但两组由参与者自行选择,不能据此声称“不用 AI 会更准确”。同样,农业背景陌生、单次任务以及刻意放大的助手倾向,都限制了外推。后续更有价值的是比较不同交互顺序能否让人更准确地表达并修订自己的目标,而不只统计是否接受了答案。

依据 1

值得读系统与效率 / 基础模型 / 多模态
追踪记录 ↗

LFM3:小模型的价值,落在内存、专用输出和真实部署上

技术small language modelhybrid architectureon-device inferencestructured output
可信度
65
重要性
82
新颖度
82

本地模型不仅要回答得对,还要在设备能承担的内存和延迟内完成工作。Liquid AI 发布 LFM3 系列,文本、视觉、音频、全模态及两个 Decisions 模型共用约 17 亿参数的骨干,组成六个约 20 亿参数的模型。它把不少全局注意力换成门控短卷积与滑动窗口注意力:前者处理局部序列,后者只查看附近位置,保留的全局层再承担长距离联系,从而减轻长上下文的缓存负担。

这不是单纯把大模型缩小。Decisions 版本面向一批明确问题,在一次模型计算中并行输出选择、范围、位置框或文本片段,适合分类、提取等任务,减少生成长解释的成本。团队还把真实设备上的测量用于架构选择,说明模型结构与部署后端需要一起考虑。

厂商报告四比特权重约 1GB;这不包括全部运行内存。其 128K 上下文测试中,用于复用先前 token 计算结果的 KV 缓存约 1.6GB。速度比较则限定在 llama.cpp、特定量化、32K 输入和短输出等条件,不能直接代表手机应用的端到端体验。模型卡也明确不推荐复杂多步推理或 Agent 编程;可下载权重采用 LFM Open License 1.0,使用前仍需读具体许可。

colingauvin · 原帖 / 原文

语境:在 LFM3 发布讨论中介绍自己的 LFM2.6 邮件处理;明确是旧模型经验。 · 读取时间:2026-10-28

逐句忠实转述(非原文)

他用 RTX A4500 运行 LFM2.6,对邮件元数据做初步分流,并把把握不足的项目交给更大模型。他说约四成标注已能信任;仍在等待 LocalAI 支持 LFM3,才准备替换试用。这里可借鉴的是分工方式,不是新版本性能结果。

dchuk · 原帖 / 原文

语境:尝试 LFM3 的 Omni 和文本模型后报告加载问题;为单个用户环境。 · 读取时间:2026-10-28

逐句忠实转述(非原文)

他尝试在 LM Studio、omlx 和 rapid mlx 中运行新模型,遇到 safetensors 无法读取的问题,尚未成功启动。回复者建议尝试 mlx-vlm 与原生 MLX 导出;讨论中这项建议不等于已经确认修复。

编辑评读

LFM3 最有启发的地方是把“回答问题”拆成不同的产品动作。邮件分流只需要标签与置信线索,图片审查可能需要位置框;强迫每一步先写自然语言,再从文字中解析结构,增加了延迟和出错面。专用输出因此可能比聊天榜上的总分更值得测试,但前提是业务能清楚定义输出与失败处理。

早期讨论也把这件事拉回部署现实。一位用户的旧版 LFM2.6 邮件流程把困难样本交给较大模型,这是分层使用的经验,不能替 LFM3 背书;另一位用户报告新模型在几个 MLX 工具里无法加载。模型权重够小,只是起点,转换格式、算子支持和服务框架能否接上同样决定可用性。

对准备试用的团队,最直接的比较对象是现有任务流水线:在同一批真实输入上,统计能独立完成的比例、需要升级处理的比例以及整条链的延迟。这样才能判断省下的推理资源是否被重试与转交吃掉。本期没有做本地跑分,发布页的数字仍是厂商测量。

依据 1

值得读Agent 系统 / 推理能力
追踪记录 ↗

Axiom 将有限单群分类证明形式化:难点也在把定义接起来

技术formal verificationLeantheorem provingMulti-Agent
可信度
65
重要性
91
新颖度
82

有限单群可以理解为有限对称结构的基本构件;分类定理说明这些构件属于哪些家族,以及 26 个例外的散在群。其已有证明散布在大量论文中,读懂局部论证不等于能确认整条依赖链。Axiom 宣布用 Agent 将这套庞大证明转写为 Lean 形式:每个推理步骤都必须符合证明助手的规则,再由其内核检查。团队报告 24 天生成约 4310 万行 Lean 代码;这是项目自报的工程规模,不是我们独立重建后的结论。

方法先把证明组织成里程碑和任务图,再让不同 Agent 处理局部证明,专门整合定义、引理和依赖。已有 Mathlib 与清华求真书院形式化工作提供基础。这里容易失败的地方不是某条公式算错,而是两个局部团队给“同一个对象”用了不兼容定义,或为了证明方便悄悄加了更强前提。原文说整合时因此删除了大量不可直接接入的代码。

团队列出 34 处值得注意的原论证偏差。例如,不平衡群定理(UGT)用子群信息识别整体,其中一个证明步骤假定某种操作后的对象仍留在指定类别;Agent 找到反例,团队于是改走另一条证明路径。不能把这写成“有限单群分类被推翻”:需要区分定理、证明中的某个步骤及其修补。公开工程把许多此前依赖人工信任的环节变成可检查对象,但形式化命题是否准确表达原数学含义,仍需要人审阅。

jonath_laurent · 原帖 / 原文

语境:发言者自称 Axiom 团队 MTS,回应如何把各部分形式化证明整合。 · 读取时间:2026-10-28

逐句忠实转述(非原文)

他指出,最大的整合困难之一是同一个非形式化概念,在不同部分被写成互不兼容的形式定义。这使局部证明接不上,需要专门的整合工作。此说法补充团队实施经验,不能作为外部独立验证。

编辑评读

这项工作的机会不只在“机器写了多少证明”。大型证明过去难以反复改动,因为某个定义变化会牵连数十处论证;显式依赖图和可重复检查可能降低这种维护成本。对自动化研究而言,它提示了一个可迁移设计:任务分解时同时分配接口整合工作,否则局部成功会堆积成全局无法拼接的产物。

这里也有两种不同的正确性。Lean 检查的是形式系统里的结论是否由前提推出;数学家还需判断前提、定义和最终陈述是否对应想证明的问题。Axiom 成员在讨论里特别指出定义不兼容的困难,恰好说明“全部通过检查”之前就需要协调语义。自动化越强,这层工作越不宜被代码量遮住。

目前应把发布的证明、关键偏差说明及可重建性分开阅读。本轮读了研究长文和项目总览,没有完成整个仓库的构建,也没有逐项审阅 34 处修补。因此这里报道的是公开成果与方法线索;其长期价值还要看独立数学审阅和他人实际复用。

依据 1

值得读AI 编程 / 评测与基准 / 基础模型
追踪记录 ↗

让模型评“有没有新意”,先检查它到底在回答哪个问题

技术LLM-as-Judgenovelty evaluationprompt sensitivity
可信度
65
重要性
84
新颖度
68

自动提出研究想法之后,研究者还需要判断它与已有工作差在哪里。Ai2 这次介绍的新颖性评估研究把这个环节单独拿出来检查:同一对想法,仅改变评委提示的说法,判断就可能大幅移动。它没有证明 AI 不能帮助查文献,而是在追问,模型给出的“新颖”判词有多稳定。

团队构造了来自评审记录的高、低新颖性论文集合,又把 154 个获评审认可的人类想法与简单流程生成的想法配对。后者没有经过搜索、反复改进或专家把关,被当作较弱的一组;这是一种有局限的标签构造,不能推出“人写的一定更新”。专家另审了 30 对刻意挑选的困难例子,也不能替代对全部样本逐一标注。

在同一批配对上,先告诉模型“评审认为两项中恰有一项有新意”并让它选出那项,与直接问“哪一个有新意”,得到的选择比例差异很大。图中的 GPT-5.4 从 93.5% 降到 40.9%;百分比表示选中评审认可的人类想法的比例,不是模型对世界上所有研究新意的准确率。增加检索或计算量也没有带来一致改善。论文 10 月 1 日首发、26 日更新至 v3;本轮增量是 27 日的新博文集中解释这些评估配方与失稳现象。

同样 154 对人类与生成想法,问“评审认为哪项有新意”或“哪项有新意”,选中评审认可人类想法的比例不同。弱标签与提示含义的差别必须一起理解。Ai2 原文图表;为解释该比较保留完整图及署名,未发现单独开放许可。 · 原文结果图表 · 图片出处 ↗

编辑评读

两个问题并不完全等价。预测既有评审会选谁,与判断相对于全部已知工作的独创性,本来就可能需要不同线索;这既是研究发现,也提醒我们不要把提示词敏感性简单解释成模型随机摇摆。如果应用要挑选真正值得做的研究,就不能只用“能猜中评审偏好”验证评委。

更可迁移的用途,是让模型交出判断所依据的最近邻工作、共用机制和具体差别,再由研究者判断差别是否成立。这样,检索可以直接减少遗漏文献,即使最终新颖性分数仍不可靠。反过来,若只接收总分,提示词、给了哪些论文和默认的评判对象都会藏进一个数字。

实际采用前,可以拿领域内有明确争议与明确先例的少量材料,检查换一种问法是否改变关键理由,而不只看排序相关性。本期没有执行这样的评测,也未找到针对这篇工作的成熟独立复现;图中的差异只支持所测样本与设置下的结论。

依据 1

值得读Agent 系统 / 评测与基准 / 多模态
追踪记录 ↗

Enveda 审查生产记录:把“找问题”变成可逐项核对的意见

技术document understandingworkflow automationhuman review
可信度
65
重要性
85
新颖度
82

药物研发还有大量工作发生在实验结果之外:生产过程是否按批准的步骤执行,手写修改有没有说明,测量值是否越过规定范围。Enveda 的 CMC Document Processor 处理这类化学、生产和质量控制资料。它先识别文件类型和编号,找到对应的主批记录、规格及偏差记录,再把扫描页交给模型读取;这些页面常有手写内容、表格和划改,纯文字抽取会丢失位置关系。

长记录被切成连续窗口,程序记录每一页是否分配和处理;模型意见附页码、实测值及参照文件。随后跨窗口核对,避免把局部没看到的内容误当成整份文件缺失。系统把意见写在文件旁,由人决定如何处理,原始记录和最终批次处置不交给模型改写。

报告评估了同一制造项目的四份记录,共 1061 页。人工提出的 11 个不同可行动问题,都曾在模型的至少一次运行中出现;不能读成单次运行召回率 100%。Opus 4.7 的一轮又提出 7 个经裁定有效的新增问题。模型处理加人工核对意见共 166 分钟,人工从头审查为 1553 分钟,约差 9.4 倍。但比较的工作路径不同:前者从已标出的意见和页码开始,结果是这套辅助流程的计时,既不是模型单独取代审查者,也不是药物临床开发提速 9.4 倍。

原文图 3:上半部分把连续页面分窗并记录覆盖,下半部分汇总各窗口发现、核对依据,再把建议交给人。覆盖记录证明哪些页被处理,不自动证明模型理解无误;正文补充了输出格式校验尚不完整的限制。Enveda · CMC Document Processor 原文图 3;为说明审查机制保留完整图及署名,未发现单独开放许可。 · 原文流程图 · 图片出处 ↗

klustregrif · 原帖 / 原文

语境:回复“AI 写表格再由 AI 读是否只是官僚浪费”的质疑。 · 读取时间:2026-10-28

逐句忠实转述(非原文)

他认为这类文件承载的是大量证据,不能当成可有可无的套话;模板早已存在,却没有消除审阅工作。AI 或许能压缩反复核对的时间,但如果真正缺的是实验或其他证据,补证据仍可能很慢。他提出的是机制解释和可能性,并非本项目的独立计时。

编辑评读

这里的工程价值在于重新组织人的阅读入口。原先审查者要在上千页中同时完成寻找、理解和裁定;系统先给出带位置与依据的候选,人才有机会把时间花在核对与追问上。这个机制也解释了为什么“给出更多评论”本身不够:意见若没有正确参照文件和页码,反而增加寻找成本。

报告同时留下了很具体的缺口。模型没有收到人工可以查阅的所有前序记录,两个“匹配人工发现”的问题需要裁定者解释才能对应;大多数人工与模型评论在本研究标准下都不需行动。此外,系统目前未逐窗口校验输出格式,某类不可读答复可能不被自动标记。这些细节说明页面已送入模型、意见可解析、证据足够和裁定正确,是几个不同条件。

因此,可借鉴的是覆盖记录、受控参照、跨页核对与人工处理的组合,效果数字仍需放回四份记录的探索性研究。原始批次资料不公开,系统也尚未作为药品生产质量管理规范(GMP)下的计算机系统完成验证。对其他文件审查任务,值得先问“能否少找一些资料而保持发现能力”,再谈推广;本例没有给出临床安全性或药物疗效的证据。

依据 1

VOICES & EXPERIENCE

观点与经验

02
值得读Agent 系统 / AI 编程
追踪记录 ↗

Agent 写代码以后,开发者还需要知道什么?

技术software architecturedebugginghuman-AI collaboration
可信度
65
重要性
80
新颖度
82

adrq 从一次具体的代码阅读困境写起:Agent 生成的 App.tsx 把大量组件挤在很少的行数里,静态检查又对复杂度报警。格式化、拆文件可以让代码更易读或让检查通过,却没有自动回答“这个系统为什么这样工作”。他讨论的不是是否还要亲手敲每一行代码,而是出了故障时,开发者靠什么决定下一步去哪里找。

作者提出保留基础知识和较宽的系统视野,再在问题出现时深入局部。自己写 Agent 编排器时,他曾被进程生命周期与崩溃恢复困扰;对 Kubernetes 工作方式的已有认识,帮助他换用持续比较实际状态与目标状态的思路。AI 能补实现细节,知道可以换一种组织方式仍来自人的知识地图。

讨论区补出了两种有价值的不同意见。有人认为 AI 也能按需解释系统,让人不必预先记住所有细节;另有人提醒,阅读时的不安未必等于产品真的变差,应看用户受损、事故和故障恢复。原文的经验因此更适合用来讨论“怎样维持能追问的理解”,而非证明所有 AI 代码都不可维护。

ArcaneMoose · 原帖 / 原文

语境:回应作者关于需要广泛系统知识的主张。 · 读取时间:2026-10-28

逐句忠实转述(非原文)

他认为 AI 可以在需要时构建系统地图,人再通过追问获得理解,不必事先掌握所有局部细节。这个意见把助手放在帮助形成理解的位置,挑战了“必须预先知道系统每一处细节”的要求。

adrq · 原帖 / 原文

语境:原文作者回复按需让 AI 画系统地图的建议。 · 读取时间:2026-10-28

回应原帖:ArcaneMoose

逐句忠实转述(非原文)

他认可这种方式能扩展视野,但强调已有基础仍然有用:没有基础,就不容易判断助手给出的地图是否只是貌似合理,实际却错了。

trjordan · 原帖 / 原文

语境:讨论开发者对 AI 代码的不安与实际失败之间的关系。 · 读取时间:2026-10-28

逐句忠实转述(非原文)

他提醒,最终后果是用户受损、安全问题、停机或工作流坏掉,而不是开发者感到不舒服。过去压力常是这些问题的先兆,但 Agent 改变流程后,两者可能不再保持原有关系。他提到自己看到功能增加、事故减少而压力上升的情况,因此建议研究不安究竟在预告什么,而不是直接把它等同于失败。

编辑评读

作者给出的知识地图,不必是一份尽可能详尽的架构文档。更实用的是能说出请求经过哪些组件、状态存在哪里、失败怎样重试,以及哪种异常会跨过边界。拥有这些问题,人就能要求助手给出针对性的解释,并去日志、配置或调用链里核对;否则很容易接受一幅画得完整却遗漏关键关系的图。

trjordan 的异议值得保留:过去开发者的难受常常预示系统维护成本,Agent 改变工作方式后,这个信号与实际故障之间的关系可能也会变化。于是团队应把两类反馈放在一起——哪里看不懂,以及那里后来是否真的妨碍定位和修改。只追求读起来舒服,可能忙于无效重构;完全忽略理解困难,则可能等到事故才发现没人知道边界。

这也给学习安排一个具体切口:让开发者在看助手解释之前先画出少量关键路径,再用真实运行证据改图,重点记录自己漏掉了什么。它是从作者经历和讨论导出的练习建议,并非已经验证的培训方案;是否改善迁移能力,应在新的故障或未见过的系统上观察。

依据 1

值得读Agent 系统 / AI 编程
追踪记录 ↗

编码便宜之后,他接下了更多工作,也更难停下来

技术developer experienceparallel agentsreview workload
可信度
65
重要性
79
新颖度
80

Orestis Ioannou 并不否认 AI 帮到了自己:以前不值得开始的修复和项目,现在可以尝试。让他疲惫的是并行工作增加以后,每个 Agent 都会间歇地带着问题、计划或代码改动回来。人需要在不同仓库和决策之间重新进入状态,单个任务变快,整周的注意力负担却加重了。

他用 2019 年以来的 GitHub 活动回顾这个变化,并交代自己的职位从全栈工程师转到高级工程角色,再到技术负责人。2026 年截至 10 月 27 日已有 2102 次贡献,接近他 2020 年同期的 2371 次;但贡献混合提交、审查、问题和拉取请求,既不是工时,也不是创造价值的数量。早期还存在另一工作平台造成的记录缺口,不能拿这条曲线证明 AI 单独导致了加班。

文章更具体的观察是循环:新能力让更多想法显得可做,他同时启动更多工作;几周后,审查和切换逐渐耗尽精力,于是收缩;下一次能力进展或休假恢复后,又重新扩张。他尚未找到平衡。他认可工具拓展了能做的事,却感觉思考和接住这些项目的精力没有同步增长。这是他的个人经验,不能自动推广到所有开发者。

sailfast · 原帖 / 原文

语境:回应作者关于并行工作带来疲惫的经验。 · 读取时间:2026-10-28

逐句忠实转述(非原文)

他觉得这也符合自己的经历,并补充说上游输入使用 AI 后也会加快,整条工作链都在提速,而接住任务的仍是人。他一度觉得这是最适合创造东西的时期,后来却感到难以停下,担心一离开就会落后。这是他对工作体验的描述,不是团队工时测量。

arend321 · 原帖 / 原文

语境:同一讨论中的不同使用体验,强调工作地点和方式的自由。 · 读取时间:2026-10-28

逐句忠实转述(非原文)

他不一定工作得更少,却觉得工作方式更好:当天在海边散步时,只靠语音就处理了 CRM、会计和搜索基础设施事务。他认为没有 AI 就得留在桌前。这个例子说明有人把能力转成安排工作的自由,而非只把它转成更多产出。

编辑评读

这篇文章改变了“省时”的比较方式。若工作清单固定,AI 可以缩短完成时间;若省下的时间立即换成更多项目,观察到的总劳动就未必减少。这不是用一个反例否定效率进步,而是指出采用新工具以后,任务需求本身也会变化。作者保留了收益与疲惫同时存在的经验,比分成乐观或悲观立场更有解释力。

对团队来说,值得检查的是等待人判断的工作,而不只是运行中的 Agent 数量。一个任务只需五分钟复核,看似很小;多个任务在不同背景下同时回来,重新理解的成本可能才是瓶颈。按可审阅能力限制在制工作、集中处理回报,是可尝试的流程设计,本期没有验证它们能减少疲惫。

讨论区也有人体验到更大的生活自由:语音助手让他可以边散步边处理事务。这与作者的经历不必互相否定,工具改变的是工作安排的选择空间,是否把机会继续换成任务还受客户要求、角色与个人选择影响。判断一套流程是否更好,需要同时看产出、维护负担和人的可支配时间,不能仅用贡献次数代替。

依据 1

LEARN BY DOING

技能学习

每天 1–2 份实践材料

博客 · 项目实践 · Enveda CMC Document Processor 团队

用一份多页记录练习“局部没看见”与“全局缺失”的区别

技术Document ReviewCoverage Ledger

原文解释为什么逐页分窗后,不能让单个窗口判断整份文件缺少什么。可用它学习长文档处理中的覆盖统计、参照选择与跨页核对。

会读简单流程图;可使用公开或自制的多页资料,不需要药物开发背景。 · 编辑建议约 45 分钟:读文档提取与跨窗口核对两节,再做纸面标注。

动手试试:把一份公开多页记录划成窗口,逐页记录处理状态,并把“本窗口未见签名”与“全记录缺签名”分开。检查后一种结论还需要哪些窗口与参照资料;本刊未执行这个练习。

CONNECT THE DOTS

把几件事放在一起看

编辑观察
追踪记录 ↗01

保留判断的过程,要比保留最后一次确认更具体

我们此前讨论自动化后的学习,重点是人还有没有亲自尝试、犯错并得到反馈的机会。今天需要补充:即使已经有专业训练,也可能在合作时失去对“判断从哪里来”的辨认。专家实验中,随机改变助手倾向能改变人的分析选择;问题不必先表现为能力退化,也可能发生在目标和理由形成的当下。因此,保留判断不能仅理解为让人最后点一次确认。

这不意味着接受助手建议就是失败。面对复杂任务,好的合作本来就应当让人改变想法。需要区分的是改变由什么推动:新证据排除了原方案,还是助手先替人决定了什么值得优化?农业案例里的结果指标和覆盖人群,把这一区别变得具体。若目标尚未表达清楚,后面的计算越顺畅,越容易把尚未讨论的取舍当成已经确定的技术条件。

开发者的系统理解提出另一层要求。助手可以解释调用链,却未必知道组织曾经为什么选择这种边界;人也可能没有足够基础发现解释中的遗漏。adrq 的经验说明,知道还有另一种状态管理方式,会改变向助手提什么问题。不过 trjordan 的异议同样成立:不熟悉代码带来的不安,并不能单独证明系统质量下降。需要把理解困难接到定位、修改与恢复的实际结果上,才知道该补哪部分知识。

Ai2 的新颖性评估把视角转向机器评委。它与人的受说服并非同一种机制:一个是协作中的影响,一个是评判任务和提示发生变化。但二者都提醒我们,一段理由或一个分数出现之前,已经选择了问题的问法。若希望知道研究相对已有工作新增了什么,却只验证模型能否猜中评审偏好,测量对象就在不知不觉间换掉了。

可迁移的办法是把关键判断留下可比较的前后版本。分析前记录目标和可能改变立场的证据;代码解释前写出自己认为的关键路径;评价研究时先列最近邻工作和实质差异。随后让 AI 提供资料、反例或另一条推理,再注明自己修订了什么。这样做仍能利用自动化扩大阅读与尝试范围,也为人保留了提出问题和辨认变化的工作。它目前是由这些机制推导出的建议,不是本期完成的干预实验。

下一步值得观察的不是人有没有少用 AI,而是他们能否在换了助手、换了问题或暂时没有提示时,说明原先的判断依据,并用新证据合理更新。若只能复述此前助手的解释,所谓“参与复核”可能并未带来理解;若这种记录只增加负担而不改善实际决策,也应调整做法。不同任务可以保留不同程度的独立尝试,不必给所有工作增加同一套手续。

判断跟随也可能包含合理的信息更新;不以一致率直接判定个体决策错误。

换问题或暂时撤去提示后,能否表达依据并处理反证。

相关条目:专家也会顺着 Agent 的倾向做判断:一项有意设置偏好的实验 / Agent 写代码以后,开发者还需要知道什么? / 让模型评“有没有新意”,先检查它到底在回答哪个问题

来源 1 · 来源 2 · 来源 3