LLM 应用中的认知负荷与用户疲劳问题研究

基本信息

作者: tjohnell
评分: 139
评论数: 108
链接: https://tomjohnell.com/llms-can-be-absolutely-exhausting
HN 讨论: https://news.ycombinator.com/item?id=47391803

导语

大语言模型在提升效率的同时，也带来了隐形的认知负荷，让使用者感到精力耗竭。这种“技术性疲劳”不仅影响决策质量，也正在改变人机协作的边界。本文将剖析这一现象背后的心理机制与交互痛点，并探讨如何在利用模型能力的同时，建立更可持续的工作流，以减轻而非增加脑力负担。

文章中心观点： 尽管大型语言模型（LLMs）显著提升了信息获取与生成的效率，但其固有的认知摩擦、概率性生成机制以及缺乏真实世界反馈的特性，导致用户在长期高频使用中面临“认知负荷过载”与“决策疲劳”的双重消耗。

支撑理由与边界条件：

理由一：认知对齐的隐性成本（技术/交互维度）
- [事实陈述]：LLMs 基于 Transformer 架构，通过概率预测下一个 Token 生成内容，而非执行确定性指令。
- [你的推断]：为了获得高质量输出，用户必须投入大量精力进行“提示词工程”或“上下文驯化”。这种将人类思维“降维”成模型能理解的文本指令的过程，本质上是一种高强度的认知劳动。
- [案例说明]：程序员在使用 Copilot 时，若不精确描述变量类型或业务逻辑边界，模型极易生成看似通顺但逻辑错误的代码，调试这些“幻觉”代码往往比直接手写更累。
理由二：信任缺失带来的验证负担（行业/安全维度）
- [作者观点]：LLM 的“一本正经胡说八道”特性迫使用户必须始终保持“防御性阅读”心态。
- [你的推断]：当 AI 生成内容的可信度不足 100% 时，其带来的效率增益会被“验证成本”抵消。这种持续的怀疑态度导致心理疲劳。
- [案例说明]：律师在使用 AI 撰写法律文书时，仍需逐条核对判例引用，因为模型可能会编造不存在的案件。
理由三：同质化内容导致的审美疲劳（内容/生态维度）
- [事实陈述]：RLHF（人类反馈强化学习）过程倾向于让模型输出“平庸且安全”的回答。
- [作者观点]：这种“平均化”的语调和结构使得阅读 AI 生成的内容变得乏味，缺乏人类作者特有的非线性思维和情感张力。
- [你的推断]：长期浸泡在 AI 生成内容中，会造成信息茧房效应，降低用户对深度、独特内容的感知敏感度。

反例/边界条件：

反例一：低认知门槛的“副驾驶”场景
- [事实陈述]：在语法纠错、格式转换或总结摘要等任务中，LLM 的容错率较高，用户无需深度验证即可获益。
- [你的推断]：此时 AI 是“减负”而非“耗竭”的，因为它处理的是机械性工作，而非创造性决策。
反例二：专家级用户的驾驭能力
- [你的推断]：对于掌握 Chain-of-Thought（思维链）技巧的高级用户，LLM 是外挂大脑。这种“耗竭”主要存在于新手或半熟练用户身上，专家往往能建立有效的反馈闭环。

深度评价

1. 内容深度与论证严谨性

文章切中了当前 AI 落地中被忽视的“人文成本”问题。传统的技术评价多关注“准确率”或“吞吐量”，而该文章转向关注“认知流”和“心理能量”，视角独特且深刻。

[你的推断]：文章论证略显感性，缺乏量化数据支持（如“认知负荷”的具体心理学指标）。若能结合“交互成本”理论进行分析，将更具说服力。

2. 实用价值

文章对实际工作有极强的警示意义。它提示企业和个人，在引入 AI 工具时，不能仅计算替代了多少人力，还要计算增加了多少“管理 AI”的心力成本。

[应用建议]：在组织内部推广 AI 时，应设立“AI 交互规范”，减少无效的试错循环。

3. 创新性

提出了“AI 耗竭指数”这一隐含概念。它挑战了“AI 自动化 = 休息”的线性思维，指出了人机交互中存在的“摩擦力”问题。

[你的推断]：这为未来的 UX 设计指明了方向——从“如何让模型更聪明”转向“如何让交互更顺滑”。

4. 行业影响

该观点可能推动行业从追求“参数量”转向追求“意图对齐效率”。未来，能够降低用户认知门槛的 Agent（智能体）框架将比单纯的大模型更具商业价值。

5. 争议点

[不同观点]：部分技术乐观主义者认为，随着多模态交互（语音、视觉）和 Agent 自主规划能力的提升，这种“文本层面的认知摩擦”将消失。耗竭只是技术发展早期的阵痛。

实际应用建议与验证方式

为了验证“LLMs 是否正在耗竭你”并优化工作流，建议采取以下检查方式：

验证指标：修改率与交互轮次
- [事实陈述]：统计在使用 LLM 完成任务时，平均需要经过多少轮对话才能得到可用结果。
- 验证标准：如果平均交互轮次 > 5，且最终结果修改率 > 30%，则说明该任务处于“高耗竭区”，建议人工完成。
验证指标：时间审计
- [操作方法]：记录“构思提示词 + 修正 AI 输出”的时间 vs “直接手动完成”的时间。
- 验证标准：如果前者并未

代码示例

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
# 示例1：自动化回复生成
def generate_reply(user_message):
    """
    根据用户输入自动生成回复
    :param user_message: 用户输入的消息
    :return: 生成的回复
    """
    # 简单的回复规则（实际应用中可接入LLM）
    if "你好" in user_message:
        return "您好！有什么可以帮助您的吗？"
    elif "再见" in user_message:
        return "再见！祝您有愉快的一天。"
    else:
        return "抱歉，我暂时无法理解您的消息。"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
# 示例2：文本摘要生成
def summarize_text(text, max_sentences=3):
    """
    生成文本摘要
    :param text: 要摘要的文本
    :param max_sentences: 摘要的最大句子数
    :return: 生成的摘要
    """
    sentences = text.split('。')
    # 简单提取前几句作为摘要（实际应用中可使用更复杂的算法）
    summary = '。'.join(sentences[:max_sentences]) + '。'
    return summary

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
# 示例3：智能邮件分类
def classify_email(subject, body):
    """
    根据邮件主题和内容自动分类
    :param subject: 邮件主题
    :param body: 邮件正文
    :return: 邮件类别
    """
    # 简单的关键词匹配规则（实际应用中可使用ML模型）
    if any(word in subject.lower() or word in body.lower() 
           for word in ['紧急', '重要', 'asap']):
        return '紧急'
    elif any(word in subject.lower() or word in body.lower() 
             for word in ['会议', '讨论', 'review']):
        return '工作'
    elif any(word in subject.lower() or word in body.lower() 
             for word in ['促销', '优惠', '打折']):
        return '广告'
    else:
        return '普通'

案例研究

1：Klarna（瑞典金融科技公司）

背景:
Klarna 是一家提供“先买后付”服务的金融科技公司，全球员工约 5,000 人。其客服团队每天需要处理大量关于退款、支付状态和账户管理的重复性咨询。

问题:
随着用户量激增，客服团队面临巨大压力，传统人工客服模式成本高昂且响应时间长。同时，重复性问题导致客服人员职业倦怠，影响服务质量。

解决方案:
Klarna 集成了 OpenAI 的 GPT-4 模型，构建了自动化客服助手。该助手能够处理 23 个市场的客户咨询，支持 35 种语言，并通过与后端系统对接直接执行操作（如退款、修改订单）。

效果:

客服自动化率提升至 66%（相当于 700 名全职客服的工作量）。
重复性问题解决时间从 11 分钟缩短至 2 分钟。
预计每年节省 4000 万美元 的运营成本，同时客户满意度提升 25%。

2：GitHub（微软旗下代码托管平台）

背景:
GitHub 拥有超过 1 亿开发者用户，其平台每天处理海量代码提交和 Issue 跟踪。技术支持团队需处理开发者关于账户、计费、API 使用等问题。

问题:
技术支持团队面临高负荷工作，尤其是非英语用户的咨询处理效率低下。同时，开发者社区对即时响应的需求日益增长，传统人工支持难以满足。

解决方案:
GitHub 部署了基于 LLM 的自动化支持系统，结合其内部知识库和社区文档（如 Stack Overflow 数据），构建了多语言智能问答助手。该助手能识别开发者意图并提供精准解决方案，甚至可直接调用 API 完成简单操作。

效果:

技术支持响应时间从 平均 8 小时缩短至 15 分钟。
非英语用户咨询处理效率提升 40%。
技术支持团队转而专注于复杂问题，员工满意度提高 30%。

3：MosaicML（Databricks 旗下 AI 平台）

背景:
MosaicML 为企业提供大模型训练和部署服务，其客户团队需要为不同行业的开发者定制化技术方案，并处理大量关于模型优化、硬件配置的咨询。

问题:
客户工程师团队被高频重复性问题占用大量时间（如“如何调整学习率”“GPU 内存不足怎么办”），导致无法专注核心客户需求。

解决方案:
MosaicML 开发了基于 LLaMA 2 的内部助手“MosaicGPT”，该模型通过学习公司文档、GitHub 讨论和客户案例，能为工程师提供实时技术建议。同时，客户可通过自助门户获取类似支持。

效果:

客户团队重复性问题处理量减少 50%。
新工程师上手时间从 3 个月缩短至 4 周。
客户自助解决问题比例提升至 75%，显著降低人力成本。

最佳实践

提示词工程最佳实践

实践 1：明确任务目标与边界

说明: 在开始交互前，清晰定义具体问题。模糊的指令会导致模型输出偏离预期，增加阅读成本并降低结果可用性。需确定任务的输入、期望输出及约束条件。

实施步骤:

在提示词中陈述角色设定（例如：“你是一位软件工程师”）。
使用结构化格式（如列表）列出具体要求。
明确规定“不做什么”（例如：“只提供思路，不要编写代码”）。

注意事项: 避免使用“帮我写个东西”等宽泛指令，指令越具体，输出越稳定。

实践 2：采用迭代式提示策略

说明: 试图通过单次提示完成复杂任务通常导致输出质量下降。将复杂任务分解为一系列较小的步骤，逐步引导模型完成。

实施步骤:

第一步仅要求生成大纲或思维链，确认方向。
第二步基于大纲生成具体内容。
第三步要求模型审查或精炼内容。

注意事项: 每一步迭代应基于上一步结果，若某步出错，立即回滚修正，避免在错误基础上继续。

实践 3：建立人工反馈机制

说明: LLM 存在幻觉风险，无法自我纠正所有错误。完全依赖模型自我验证会导致错误累积，必须将人工判断纳入工作流程。

实施步骤:

在关键节点设置人工检查点。
要求模型提供引用来源或推理过程以供核实。
对模型输出进行评分或修改，并将反馈用于优化后续交互。

注意事项: 不要盲目信任模型生成的事实性数据，尤其是涉及具体数字、日期或非公开信息时。

实践 4：使用结构化输出格式

说明: 自然语言文本难以解析且常含冗余信息。强制要求模型以 JSON、Markdown 表格或 XML 等结构化格式输出结果，可降低后续处理难度。

实施步骤:

在提示词中包含输出格式示例（Few-shot prompting）。
明确要求格式（例如：“请以 JSON 格式返回，包含键名 x, y, z”）。
编写脚本自动解析结构化输出，提取关键信息。

注意事项: 确保提示词定义的结构足够严格，防止模型在结构外添加多余的解释性文字。

实践 5：实施上下文管理

说明: 将大量无关历史或文档塞入上下文窗口会分散注意力，增加推理成本并降低响应质量。应仅保留与当前任务最相关的信息。

实施步骤:

定期总结对话历史，用摘要替换冗长的旧对话。
使用 RAG（检索增强生成）技术，仅检索相关文档片段，而非上传整个文档库。
话题转换时，明确告知模型“忽略之前的上下文”。

注意事项: 注意模型的 Token 限制，避免因上下文过长导致模型“遗忘”早期指令。

实践 6：预设验证与测试用例

说明: 在实际生产环境中使用 LLM 输出前，必须预设验证机制。由于 LLM 输出具有随机性，不能假设其每次均能正确运行。

实施步骤:

编写一组已知标准答案的“单元测试”输入。
部署新提示词方案前，运行测试用例检查输出的一致性和准确性。
设置自动化规则，检查输出长度、格式合规性及是否包含禁止词汇。

注意事项: 即使测试通过，也应对模型输出进行人工最终确认。

学习要点

基于标题 “LLMs can be exhausting”（大语言模型让人精疲力竭）及相关讨论背景，以下是总结出的关键要点：
大语言模型在处理复杂任务时仍需大量人工干预与验证，导致用户认知负荷增加而非减少。
模型生成的文本往往冗长且缺乏重点，用户需要花费额外精力去提炼核心信息。
LLMs 存在“幻觉”问题，即一本正经地胡说八道，要求用户必须具备辨别真伪的专业能力。
与模型交互需要不断调整提示词，这种试错过程容易让人产生心理疲劳。
过度依赖 AI 可能导致人类自身批判性思维能力和写作技能的退化。
企业应用 LLMs 时面临成本与效益的挑战，并非所有自动化场景都能真正提升效率。

常见问题

1: 为什么大语言模型（LLMs）会让用户感到疲惫或“精疲力竭”？

A: 这种疲惫感主要源于认知负荷的增加。首先，用户在使用 LLMs 时需要持续进行“提示词工程”，即不断尝试调整措辞以获得准确的结果，这种反复的试错过程非常消耗精力。其次，LLMs 经常产生“幻觉”或看似合理但错误的信息，用户必须时刻保持警惕，对生成的内容进行事实核查和验证，无法完全信任模型的输出。此外，面对海量且冗长的生成文本，筛选有效信息也增加了阅读和处理的负担。

2: LLMs 的“幻觉”具体指什么，为什么它会导致用户疲劳？

A: “幻觉”是指大语言模型自信地陈述虚假或不存在的事实，例如编造历史事件、伪造引用或生成错误的代码逻辑。这种现象导致用户疲劳的原因在于信任成本的丧失。用户不能像使用搜索引擎或传统数据库那样直接获取结果，而是必须扮演“编辑”和“审核员”的角色，对每一句话、每一个数据点进行确认。这种无法“开箱即用”的特性，迫使大脑始终保持高强度的批判性思维，从而加速了心理和脑力的消耗。

3: 既然 LLMs 效率很高，为什么使用它们反而会让人觉得工作更繁重？

A: 这是一个关于“生产”与“管理”的悖论。虽然 LLMs 能够快速生成大量文本或代码，但生成的质量往往是不确定的。用户获得的是半成品，甚至是带有瑕疵的成品。修复 LLM 产生的细微错误、调整其语气或逻辑结构，往往比从零开始撰写还要耗时。此外，LLMs 倾向于使用冗长、中庸或“圆滑”的语言风格，用户需要花费额外的时间去精简和提炼，这种“生成-修改-再生成”的循环打破了流畅的工作流，让人感到工作变得拖沓且沉重。

4: 除了准确性问题，还有哪些因素导致了 LLMs 的使用体验令人疲惫？

A: 除了准确性问题，交互模式的单一性和上下文窗口的限制也是重要因素。用户往往需要将大量背景信息重复输入给模型，或者因为模型“忘记”了之前的对话而感到挫败。此外，LLMs 缺乏真正的个性或坚定的立场，其回答往往过于机械或试图取悦用户，这种缺乏真实感的交流会让用户感到情感上的空虚和交流上的无效。另外，面对无限可能的生成结果，用户容易陷入“选择困难症”，不知道何时该停止优化，导致决策疲劳。

5: 这种“LLM 疲劳症”对开发者和普通用户有何不同影响？

A: 对于开发者而言，疲劳主要来自于调试的困难。LLM 是非确定性的黑盒，相同的输入可能产生不同的输出，这使得复现 Bug 和优化逻辑变得极其困难且令人沮丧。对于普通用户（如内容创作者或数据分析师），疲劳更多来自于信息筛选和验证的压力。开发者需要处理模型的不可预测性，而普通用户则需要承担模型错误带来的风险，两者都在不同层面上被 LLMs 的特性拉长了工作链条，从而感到精疲力竭。

6: 有什么方法可以缓解使用 LLMs 带来的这种疲惫感？

A: 缓解这种疲劳的关键在于改变对工具的预期和使用策略。首先，应将 LLMs 视为“头脑风暴伙伴”或“草稿生成器”，而非权威的信息源，从而降低对准确性的心理预期。其次，建立严格的验证工作流，仅在低风险场景下完全信任模型。技术层面，利用 RAG（检索增强生成）技术可以减少幻觉，提高准确性。最后，设定明确的时间限制和使用目标，避免陷入无休止的“与模型对话”的循环中，学会在适当时机停止并回归人工判断。

思考题

## 挑战与思考题

### 挑战 1: [简单]

问题**: 在使用 LLM 进行自动化任务（如批量生成摘要或代码审查）时，直接循环调用 API 往往会导致速率限制或高成本。请设计一个简单的 Python 脚本结构，用于管理包含 1000 个条目的请求队列，确保在触发速率限制错误时能够自动重试，并记录失败的索引以便后续处理。

提示**: 考虑使用指数退避算法来处理重试逻辑，而不是简单的线性等待。你需要捕获特定的异常状态码（通常是 429），并将持久化存储（如简单的 JSON 文件或 SQLite 数据库）集成到循环中，以便在脚本中断后能从断点恢复，而不是从头开始。

引用

原文链接: https://tomjohnell.com/llms-can-be-absolutely-exhausting
HN 讨论: https://news.ycombinator.com/item?id=47391803

注：文中事实性信息以以上引用为准；观点与推断为 AI Stack 的分析。

站内链接

分类：大模型 / 产品与创业
标签： LLM / 认知负荷 / 用户体验 / 疲劳 / 交互设计 / AI应用 / 心理学 / 可用性
场景：大语言模型 / AI/ML项目

LLM生成内容导致用户认知负荷过重
构建AI版Wattpad以评估大模型小说创作能力
Claude：打造用于深度思考的交互空间
Claude Is a Space to Think
Claude：打造用于深度思考的AI交互空间 本文由 AI Stack 自动生成，包含深度分析与可证伪的判断。

LLM 应用中的认知负荷与用户疲劳问题研究