卸载分数：通过反事实工作流衡量 AI 依赖程度

来源：https://arxiv.org/html/2605.29392
Vishakh Padmakumar 斯坦福大学
Lujain Ibrahim 牛津大学
Zora Zhiruo Wang 卡内基梅隆大学
Jennifer Wang 斯坦福大学
Q. Vera Liao 密歇根大学
Diyi Yang 斯坦福大学

######摘要
AI 工具正越来越多地融入现实世界的工作流程。然而，现有的对这些工具依赖程度的衡量主要集中在 AI 输出的采用情况或自我报告的指标上，而非关注任务如何在用户与工具之间分配认知努力。在此，我们引入 卸载分数（offloading score），一种衡量依赖程度的指标，它量化了卸载到 AI 工具的认知努力比例。卸载分数 基于模拟——我们通过估计用户在没有该工具的情况下会如何完成任务来构建一个反事实工作流，然后计算使用该工具所节省的步骤比例。我们通过内在评估（验证指标有效性）以及一项受控用户研究（n=40，开发者在 AI 工具辅助下完成编程任务）来验证 卸载分数。我们改变时间压力，以测试依赖衡量指标能否捕捉到在时间压力下依赖程度增加的已知现象。结果表明，卸载分数 能检测到时间限制条件下显著更高的依赖程度（+43%，p=0.018），而基于使用情况和自我报告的基线依赖衡量指标无法区分不同条件。我们辅以描述性洞察，表明更高的依赖程度表现为将更多子任务委托给工具以及更直接地重用 AI 输出。最后，我们展示了一种将 卸载分数 与任务目标结果（例如代码理解）结合使用的方法，以识别依赖何时可能（不）恰当。我们的框架提供两项贡献：用户可应用于衡量和反思自身依赖程度的工具，以及智能体设计者可利用来缓解过度依赖的定量信号。

1 引言

AI 工具正越来越多地融入日常认知任务，从写作、编程到分析和决策。虽然这些工具能提高生产力（Brynjolfsson 等，2025 (https://arxiv.org/html/2605.29392#bib.bib7)）并因此被广泛采用（Sleegers 等，2025 (https://arxiv.org/html/2605.29392#bib.bib8)），但它们也引发了对过度依赖风险的担忧，包括技能退化以及独立解决问题能力下降（Shukla 等，2025 (https://arxiv.org/html/2605.29392#bib.bib2)；Zhi 等，2026 (https://arxiv.org/html/2605.29392#bib.bib21)；Shen 和 Tamkin，2026 (https://arxiv.org/html/2605.29392#bib.bib22)；Ibrahim 等，2025 (https://arxiv.org/html/2605.29392#bib.bib37)）。这些担忧不仅涉及产出的质量，还包括因将认知工作卸载给 AI 而产生的认知影响。现有框架通常通过用户自我评估或 AI 输出采用情况来衡量依赖程度（第 2 节 (https://arxiv.org/html/2605.29392#S2)）。基于输出的方法，在早期关注分类设定的工作中被开发，将依赖视为二元度量（接受/拒绝），当用户接受错误输出时归类为过度依赖，拒绝正确输出时归类为依赖不足（Vasconcelos 等，2023 (https://arxiv.org/html/2605.29392#bib.bib3)；Liu 等，2026 (https://arxiv.org/html/2605.29392#bib.bib5)）。这些度量在当代 AI 工具的多轮人-AI 工作流中失效，因为依赖可能通过用户提供输入（即提示工程）和与工具输出交互的不同方式表现出来。自我报告的度量更细致地捕捉用户感知的依赖程度，但具有主观性、噪声大且收集成本高（Kohn 等，2021 (https://arxiv.org/html/2605.29392#bib.bib49)）。在这项工作中，我们转而通过认知工作如何在用户与 AI 工具之间分配来描述依赖程度，即用户原本会执行的规划、执行和验证步骤中有多少被卸载给了 AI。直观地说，一个要求工具解决整个编码任务的用户比一个分解任务、查询模型子组件并验证每一步的用户更依赖，即使两者都产生相似的最终输出（图 1 (https://arxiv.org/html/2605.29392#S1.F1)(A)）。我们的目标是衡量 AI 使用如何改变人们在完成任务时的认知过程，并为识别可能导致负面长期后果的不当依赖模式提供起点。

参见图注

图 1：我们提出 卸载分数，一种衡量卸载给 AI 工具的认知努力的标量度量，并辅以工具使用的描述性维度。卸载分数 通过识别 AI 辅助的工作流步骤、估计仅人力的反事实替代方案，以及计算工具节省的工作流步骤比例来计算。卸载分数 比基线度量（例如 AI 代码比例）更能有效区分用户的依赖模式（第 4 节 (https://arxiv.org/html/2605.29392#S4)），并且可以与结果度量（如系统回忆）结合使用以解释依赖模式（第 5 节 (https://arxiv.org/html/2605.29392#S5)）。

研究问题 1：我们能否设计一种依赖度量，反映有多少认知工作被卸载给了 AI，以及卸载的是什么？

我们提出了一个衡量依赖的多维框架（第 3 节 (https://arxiv.org/html/2605.29392#S3)，图 2 (https://arxiv.org/html/2605.29392#S3.F2)）：(1) 一个主要标量度量 卸载分数，通过将每个 AI 辅助的工作流步骤替换为仅人力反事实序列并测量节省的步骤比例，来估计卸载给工具的认知努力比例（图 3 (https://arxiv.org/html/2605.29392#S3.F3)）；以及 (2) 补充的描述性维度，分类 (a) 卸载给工具的任务类型，灵感来自 Flower 认知过程模型（Flower 和 Hayes，1981 (https://arxiv.org/html/2605.29392#bib.bib10)），以及 (b) 用户如何与模型输出互动，采用受 Bloom 分类学启发的四级量表（Bloom 等，1956 (https://arxiv.org/html/2605.29392#bib.bib11)）。我们首先通过评估构建的人类反事实工作流是否为完成同一任务提供了合理的替代方案，以及评估指标对受控扰动的稳定性和敏感性，来确立 卸载分数 的有效性（第 3.3 节 (https://arxiv.org/html/2605.29392#S3.SS3)）。然后，我们在一个受控用户研究中验证 卸载分数，研究对象为 N=40 名经验丰富的自由职业开发者，他们在 短（1 小时）或 长（4 小时）时间限制下完成编程任务。为了反映时间压力与工具依赖增加之间的关联（Zakay，1993 (https://arxiv.org/html/2605.29392#bib.bib20)；Rice 等，2009 (https://arxiv.org/html/2605.29392#bib.bib41)；Swaroop 等，2024 (https://arxiv.org/html/2605.29392#bib.bib43)；Haduong 和 Smith，2024 (https://arxiv.org/html/2605.29392#bib.bib6)），一个有效的依赖度量应在 短 条件下分配更高的分数。我们发现 卸载分数 在 短 条件下分配了显著更高的依赖程度（平均 0.451 vs. 0.308，p=0.018），而基线度量，包括基于输出的度量（如 AI 代码保留比例：0.152 vs. 0.052，p=0.072）和自我报告的认知负荷（3.63 vs. 3.56，p=0.881），均未显著区分不同条件（第 4.5 节 (https://arxiv.org/html/2605.29392#S4.SS5)）。我们还通过描述性维度识别出，更高的依赖程度与使用模式的转变相关，导致更直接地重用 AI 输出，而较少与工具进行迭代交流。

研究问题 2：我们能否利用 卸载分数 来识别（不）恰当依赖的条件？

依赖程度是否应被视为适当，取决于用户的规范目标，即依赖旨在支持何种结果。我们展示了一种将 卸载分数 与目标任务结果度量（以理想的代码理解水平为例）结合使用的方法，以识别恰当依赖的条件。我们观察到 卸载分数 与任务理解之间存在普遍的负相关，这允许为过度依赖设定一个 卸载分数 阈值——高于阈值的依赖会导致不可接受的低任务理解。然而，我们还观察到一个异常用户群，他们具有中等到高的 卸载分数 和高任务理解。定性数据表明，他们在使用 AI 工具 学习 不熟悉的编码任务时表现出一种独特的模式，这表明在这类特定的 AI 工具使用情境中，较高的依赖可以被认为是 恰当的。

具体而言，我们将贡献总结如下：
(1) 以用户行为为基础的依赖度量。 我们引入 卸载分数，一种通过将 AI 辅助步骤替换为仅人力反事实替代方案来估计通过 AI 辅助节省的工作流步骤比例的标量度量。卸载分数 直接从交互痕迹（例如截图和按键记录）计算，使其适用于不同的工具和界面。
(2) AI 使用的多维描述。 我们用描述性分类来补充 卸载分数，分类内容包括卸载给 AI 的任务类型以及用户如何与 AI 输出互动。
(3) 通过用户研究进行实证验证。 卸载分数 在时间压力下比基线度量更好地捕捉依赖的变化，同时提供描述性的行为洞察。通过联合分析依赖和代码理解，我们展示了用户表现出不同的模式，包括过度依赖和恰当依赖。

1我们发布了与本项目相关的 代码 以及一个包含示例和综合发现的 网站。

2 背景

现有的依赖度量
先前的工作主要通过两种方法来衡量依赖。第一种是基于使用情况的方法，通常以二元值形式衡量用户是否采用 AI 提供的输出（Vasconcelos 等，2023 (https://arxiv.org/html/2605.29392#bib.bib3)；Buçinca 等，2021 (https://arxiv.org/html/2605.29392#bib.bib4)；Zhou 等，2025 (https://arxiv.org/html/2605.29392#bib.bib13)；Bansal 等，2021 (https://arxiv.org/html/2605.29392#bib.bib14)）。这些度量通常与结果正确性评估相结合，为交互分配规范性标签，例如过度依赖（采用 + 错误）和依赖不足（拒绝 + 正确）。其他相关的基于使用情况的度量，如切换比例（Yin 等，2019 (https://arxiv.org/html/2605.29392#bib.bib15)）和建议权重（Logg 等，2019 (https://arxiv.org/html/2605.29392#bib.bib16)），衡量用户是否根据 AI 建议更新其决策。第二种方法涉及自我报告的感知依赖及其认知影响的度量，例如自动化自满量表（Merritt 等，2019 (https://arxiv.org/html/2605.29392#bib.bib12)）和认知负荷评估（例如 NASA TLX (Hart 和 Staveland，1988 (https://arxiv.org/html/2605.29392#bib.bib17))）。Zhi 等人 (2026) (https://arxiv.org/html/2605.29392#bib.bib21) 通过比较 AI 访问条件下的表现差异来推断依赖程度，将其视为一个潜在因素。在这项工作中，我们提出了一种桥梁这些不同方法的度量，通过超越工具 使用了多少，捕捉其在工作流中 如何 被使用，从而提供以用户行为为基础的、面向过程的依赖视角。

（过度）依赖的影响
基于 LLM 的系统大规模面向公众部署，激发了对（过度）依赖影响的研究，其特征包括对 AI 输出的审查减少、人类监督减弱，以及对 AI 支持决策保持适当控制的困难增加（Passi 和 Vorvoreanu，2022 (https://arxiv.org/html/2605.29392#bib.bib29)；Buçinca 等，2021 (https://arxiv.org/html/2605.29392#bib.bib4)；Yizhou Tian 等，2026 (https://arxiv.org/html/2605.29392#bib.bib30)）。近期工作将这一关注扩展到长期效应，包括认知投降、赋权丧失、责任错位以及技能发展机会减少（Shaw 和 Nave，2026 (https://arxiv.org/html/2605.29392#bib.bib31)；Sharma 等，2026 (https://arxiv.org/html/2605.29392#bib.bib9)；Shukla 等，2025 (https://arxiv.org/html/2605.29392#bib.bib2)）。在教育环境中，依赖模式受用户因素（如专业知识和认知需求）的影响（Pitts 等，2025 (https://arxiv.org/html/2605.29392#bib.bib32)；Shen 和 Tamkin，2026 (https://arxiv.org/html/2605.29392#bib.bib22)）。这些担忧在 AI 辅助编程中尤为突出，这是当代模型影响最显著的任务和职业之一（Massenkoff 和 McCrory，2026 (https://arxiv.org/html/2605.29392#bib.bib33)）。编程助手减少了工作量并自动化了不熟悉的任务，但也引发了对用户能否理解和维护他们产生的代码的担忧（Chen 等，2025 (https://arxiv.org/html/2605.29392#bib.bib34)）。在现实的开源任务中，AI 工具可能会减慢经验丰富的开发者的速度，并且当开发者后来需要理解、审查或修复生成的工件时，AI 生成的代码可能会增加维护负担和技术债务（Becker 等，2025 (https://arxiv.org/html/2605.29392#bib.bib36)；Xu 等，2026 (https://arxiv.org/html/2605.29392#bib.bib35)）。这些发现促使我们专注于捕捉用户如何将认知努力委托给 AI 系统，以及用户对最终代码工件的理解程度，而不仅仅是任务结果。

3 面向过程的依赖度量

3.1 问题设定

我们考虑在计算机使用活动中，用户 U 对工具 T 的依赖程度表征问题。遵循 Wang 等人 (2025) (https://arxiv.org/html/2605.29392#bib.bib1) 的定义，我们将 工作流 定义为实现预定义目标所采取的一系列步骤，其中每个步骤由一个或多个动作组成，完成一个可区分的子目标。形式化地，设 W = {w₁, …, wₙ} 表示 U 为实现目标而执行的一个包含 n 个步骤的工作流。每个步骤 wᵢ 代表朝着目标的一个连贯进展单元，例如编写代码实现某个功能或生成文档文件。每个步骤可以完全由 U 独立完成、完全留给 T、或者两者针对该特定子目标进行交互。我们的目标是描述 T 在每个步骤中的使用方式，以及用户对 T 输出的响应方式，通过建模认知努力的分配以及两者在整个工作流 W 中的交互动态，来捕捉 U 对 T 的依赖。

参见图注

图 2：(1) 我们通过将 AI 辅助步骤扩展为模拟的反事实仅人力步骤并测量节省的比例来计算 卸载分数。图 3 (https://arxiv.org/html/2605.29392#S3.F3) 详细说明了 卸载分数 的计算方式。我们还通过 (2) 卸载的 过程 类型以及 (3) 用户如何与工具输出互动来描述依赖。

3.2 提出的度量

参见图注

图 3：计算 卸载分数。从原始交互痕迹（例如按键、点击、截图）开始。