当前位置：首页 > news >正文

第7篇：Skill的错误处理与边界设计——让Skill更健壮

news 2026/5/28 0:19:05

第7篇：Skill的错误处理与边界设计——让Skill更健壮

适用人群：进阶 | 字数：约25,000字 | 预计阅读时间：60分钟

前言

在前六篇中，我们学会了创作一个"功能完整"的 Skill——有清晰的架构、精良的提示词、实用的工具、可靠的状态管理。

但 Skill 在"正常情况下"工作良好只是基本功。真正考验 Skill 质量的，是"异常情况下"的表现。

你可以想象一下这些场景：

场景1：用户什么也没输入，直接点击发送——你的 Skill 怎么处理？
场景2：用户输入了 5000 字，但你的 Token 预算只有 3000——你的 Skill 怎么处理？
场景3：用户在对话过程中突然说"不做了"——你的 Skill 怎么处理？
场景4：用户输入的会议内容全是闲聊，没有实质信息——你的 Skill 怎么处理？
场景5：你配置的搜索工具在调用时返回了错误——你的 Skill 怎么处理？

这些问题如果处理不好，用户就会觉得这个 Skill “不靠谱”、“动不动就出问题”。

健壮性（Robustness）就是衡量 Skill 在异常情况下表现好坏的标准。一个健壮的 Skill，在正常情况下表现出色，在异常情况下也能"有尊严地失败"——告诉用户发生了什么、给出替代方案、不崩溃。

这一篇，我们系统性地讲解错误处理和边界设计——从识别可能的错误场景，到设计每个场景的应对策略。

第一章：错误的分类——知道"可能出什么问题"

1.1 错误的三大来源

Skill 的错误可以来自三个源头：

来源一：用户输入异常（User Input Errors） 用户提供了不符合预期的输入 例子：空输入、超长输入、无关内容、恶意内容 来源二：系统运行异常（System Runtime Errors） Skill 运行过程中出现的技术问题 例子：工具调用失败、Token 超限、模型响应超时 来源三：逻辑处理异常（Logic Processing Errors） AI 在处理过程中出现的逻辑问题 例子：推理错误、信息遗漏、格式错误、内容编造

1.2 错误的分级

不是所有错误都需要"大动干戈"。根据严重程度，错误可以分为三级：

一级错误：可以自动恢复（不影响用户体验） 例子：输出格式微调、字数超限后裁剪、工具调用一次失败后重试 二级错误：需要告知用户（轻微影响体验） 例子：工具调用多次失败、输入部分信息不足、推理过程中遇到不确定情况 三级错误：需要人工介入（严重影响使用） 例子：涉及安全违规、连续多次工具调用失败、用户明确表示不满

1.3 错误处理的"黄金法则"

在设计错误处理逻辑时，遵循以下法则：

法则一：不要沉默失败 如果出了错误，一定要让用户知道。 不要：输出空白内容、输出看似正常实则错误的内容。 要：明确告知"出了什么问题"。 法则二：提供替代方案 只告诉"出了什么问题"不够，还要告诉"接下来怎么办"。 不要："系统错误。" 要："暂时无法获取实时天气，建议您稍后再试，或者查看手机上的天气App。" 法则三：保持专业姿态 即使出了问题，语气和态度依然要保持专业。 不要："我也不知道咋回事，反正就是不行。" 要："抱歉，我遇到了一个技术问题。这个问题通常是因为……您可以尝试……" 法则四：记录错误 所有错误都应该被记录，用于后续分析和改进。 需要记录：错误类型、触发条件、发生时间、上下文信息。

第二章：用户输入异常的处理

2.1 空输入

场景：用户什么也没输入就点击了发送。

问题：AI 没有信息可以处理，可能编造内容。

解决方案：

在约束条件中增加：

【空输入处理】 如果用户没有提供任何输入内容： 1. 不要编造任何内容 2. 友好地提示用户提供信息 3. 给出具体的输入建议 示例回复： "您好，我注意到您还没有输入会议内容。请粘贴您的会议笔记或录音转写文本， 我会帮您整理为结构化的会议纪要。 💡 小贴士：内容越详细，纪要越精准。建议包含参会人、讨论要点、决议和待办事项。

2.2 过短的输入

场景：用户只输入了十几个字，信息量远远不够。

问题：AI 基于极少的信息"强行生成"，结果大部分内容是编造的。

解决方案：

在处理流程中增加"输入长度判断"：

【输入长度处理规则】 根据输入的长度，采用不同的处理方式： 如果输入长度 < 50 字： → 按"简要模式"处理 → 只提取输入中明确提到的信息 → 缺失的部分标注"信息不足" → 在末尾添加提示："您提供的内容较为简短，建议补充更多细节以获得更精准的纪要" 如果输入长度 50-200 字： → 按"标准模式"处理 → 正常提取和组织 → 缺失的部分标注"未注明" 如果输入长度 > 200 字： → 按"完整模式"处理 → 完整提取所有信息 → 按完整模板输出

2.3 过长的输入

场景：用户粘贴了 10000 字的文档，超出了 Token 预算。

问题：Token 超限，Skill 报错或只能处理开头部分。

解决方案：

【长输入处理】 如果输入内容超过 3000 字： 1. 先对输入做分段 2. 每段提取关键信息 3. 汇总所有段的关键信息 4. 基于汇总信息生成输出 5. 在末尾标注："本次输入内容较长，如有遗漏重要信息，请补充。" 如果输入内容超过 5000 字（极长）： 1. 先对输入做全局摘要（压缩到 1000 字以内） 2. 基于摘要进行处理 3. 在末尾标注："输入内容极长，已做摘要处理。如有遗漏，请补充。" 4. 提供原始输入中的"按章节分段处理"的选项

2.4 不相关的输入

场景：用户输入了与 Skill 功能完全无关的内容（如用会议纪要 Skill 来聊天）。

问题：AI 被"带偏"，输出了与 Skill 核心功能无关的内容。

解决方案：

【不相关输入处理】 如果用户输入的内容与会议纪要整理无关（如闲聊、提问、其他需求）： 1. 友好地提示用户本 Skill 的功能范围 2. 引导用户回到正题 3. 如果用户坚持，可以简单回应但不展开 示例回复： "我注意到您正在聊其他话题。我的专长是整理会议纪要， 如果您有会议内容需要整理，随时粘贴给我。 如果您有其他需求，可以尝试使用其他 Skill 来获得更好的帮助。" 注意：如果用户明确表示"暂时不用"，礼貌结束对话。 不要强行让用户使用 Skill 的核心功能。

2.5 含敏感信息的输入

场景：用户输入中包含个人隐私信息（姓名、电话、地址、身份证号等）。

问题：输出的纪要中可能包含这些敏感信息，造成隐私泄露。

解决方案：

在约束条件中增加：

【敏感信息处理】 如果输入内容中包含以下敏感信息： - 个人手机号 - 个人身份证号 - 银行卡号 - 家庭住址 - 密码/验证码 处理规则： 1. 在输出中对敏感信息做脱敏处理 - 手机号：138****1234 - 身份证：110101****5678 - 姓名：张**（保留姓氏） 2. 在纪要末尾添加保密提示 3. 保存到系统时需要加密存储（由系统层面处理） 脱敏示例： 输入："张三的电话是13812345678，地址是北京市海淀区中关村大街1号" 输出中的处理："张**的电话是138****5678，地址已脱敏"

第三章：系统运行异常的处理

3.1 工具调用失败

场景：Skill 调用搜索工具时，API 返回了错误。

问题：用户得不到需要的信息。

解决方案：

【工具调用失败处理】 当工具调用失败时，按以下级别处理： 一级失败（单次超时或网络波动）： → 自动重试 1 次 → 如果重试成功，继续正常流程 二级失败（重试仍然失败）： → 告知用户"暂时无法获取该信息" → 解释可能的原因 → 提供替代方案 三级失败（连续 3 次调用都失败）： → 告知用户"该服务暂时不可用" → 记录错误日志 → 建议用户稍后再试 → 转为"不依赖工具"的降级模式 失败回复的模板： "抱歉，我目前无法获取[具体信息]。这可能是因为[原因]。 建议您可以[替代方案]。 如果需要，我可以先处理其他部分，稍后再重试。"

3.2 Token 超限

场景：输入内容太长，加上系统指令后超过了模型的 Token 限制。

问题：模型拒绝处理或输出被截断。

解决方案：

【Token 超限处理】 如果发现输入总长度接近或超过 Token 限制（在指令中提示 AI 主动检测）： 1. 压缩输入内容 - 去掉冗余描述 - 保留核心信息 - 对长段落做摘要 2. 分段处理 - 将输入分为多个段落 - 逐段处理 - 汇总各段结果 3. 提示用户 - "您提供的内容较长，我已经提取了核心信息进行处理。 如果遗漏了重要部分，请补充。" 在约束条件中增加主动检测： "如果你发现用户输入过长，主动做压缩处理。不要直接报错或截断。"

3.3 模型响应异常

场景：模型返回的内容格式不对、不完整、或是乱码。

问题：用户收到无法使用的内容。

解决方案：

【输出异常处理】 如果发现输出内容有异常： 异常1：格式不正确 → 自动检测格式偏差 → 尝试修正格式 → 如果无法修正，重新生成 异常2：内容不完整 → 检查是否缺少了指定模板中的章节 → 补充缺失的章节（标注"信息不足"） → 如果多次尝试仍然不完整，告知用户 异常3：包含乱码或异常字符 → 尝试修复乱码 → 如果无法修复，过滤掉乱码部分 → 确保输出中不包含不可读的内容 所有输出异常都应该记录日志，用于后续的提示词优化。

3.4 超时处理

场景：用户等待了很长时间，Skill 还没有返回结果。

问题：用户体验极差。

解决方案：

【超时处理】 在指令中定义"快速响应"原则： 1. 如果任务预计需要较长时间，先回复用户"正在处理，请稍候" 2. 处理过程中，如果超过 10 秒没有进展，主动告知用户"还在处理中" 3. 如果任务过于复杂，拆分后分步处理 在工具调用层面： 1. 每个工具调用设置超时时间（如 5 秒） 2. 超过超时时间未返回，转为失败处理 3. 避免长时间等待导致用户困惑

第四章：逻辑处理异常——让AI自己"发现"错误

4.1 推理错误

场景：AI 在推理过程中得出错误结论——比如把"增加预算"理解成了"减少预算"。

问题：输出中有看似合理但实际错误的内容。

解决方案：

在处理流程中增加"推理检查点"：

【推理检查】 在每个关键推理步骤后，执行以下检查： Step 1 检查：理解是否准确？ 用自己的话重述用户输入的核心意思 确认：重述是否准确反映了用户的本意？ 如果不准确：返回 Step 1 重新理解 Step 2 检查：提取是否完整？ 列出所有需要提取的信息类别 检查每个类别是否都有对应的提取结果 如果有遗漏：补充提取 Step 3 检查：推理是否合理？ 检查推理链条的每一步是否有依据 检查结论是否与前提一致 如果有跳跃：补充中间步骤 Step 4 检查：输出是否准确？ 对照原始输入，逐项检查输出中的事实性信息 如果发现错误：修正后再输出

4.2 信息遗漏

场景：输入中有 5 个待办事项，AI 只提取了 3 个。

问题：输出不完整，用户遗漏了重要信息。

解决方案：

在约束条件中强调"完整性"：

【完整性保障】 待办事项是本 Skill 输出的核心价值部分，请确保： 1. 在提取阶段： - 不放过任何可能包含"待办"信息的语句 - 特别关注以下关键词：'负责'、'跟进'、'处理'、'完成'、'提交'、'给结果'、'出方案' - 即使信息不完整（如只说'谁'没说'做什么'），也如实记录可提取的部分 2. 在输出前检查： - 逐条核对：有没有遗漏任何待办事项？ - 如果发现遗漏：返回提取阶段补充 3. 如果确实无法确定是否为待办事项： - 宁多勿少：不确定的也列入，标注"待确认" - 而不是"可能不是就不列"

4.3 格式偏差

场景：AI 没有严格按照模板输出，用了不同的标题层级、不同的表格格式。

问题：输出风格不一致，用户需要重新排版。

解决方案：

【格式遵从】 1. 输出格式必须严格遵循下文的"输出模板" 2. 在生成输出后，逐项检查模板匹配度： □ 标题层级：# → ## → ### 是否正确 □ 表格格式是否规范（有表头、有分隔线、每行对齐） □ 列表格式是否一致（统一用 - 或 1. 2. 3.） □ 加粗、斜体等标记是否正确使用 3. 如果发现格式偏差，修正后再输出 注意：格式精确比内容丰富更重要。 一份格式完美的精简版，比格式混乱的完整版更好用。

第五章：边界条件——定义 Skill 的"极限"

5.1 什么是边界条件？

边界条件（Boundary Conditions）是 Skill 能正常工作的"极限情况"。在边界上，Skill 的行为应该依然合理——即使结果可能不如完美情况好，但至少不应该崩溃或输出错误内容。

常见的边界条件： 输入相关的边界： - 输入为空 → 最简边界 - 输入极短（10字以内） → 信息量边界 - 输入极长（5000字以上） → Token边界 - 输入包含特殊字符 → 格式边界 运行相关的边界： - 同时使用人数 → 并发边界 - 单次运行时间 → 性能边界 - Token 消耗 → 资源边界 逻辑相关的边界： - 未定义的话题 → 知识边界 - 超出授权范围的操作 → 权限边界 - 多轮对话的轮数 → 对话边界

5.2 为每个边界设计"兜底行为"

对于每个识别出的边界条件，都需要设计对应的"兜底行为"（Fallback Behavior）。

边界：输入为空 兜底行为：友好提示，引导用户提供内容 边界：输入极短 兜底行为：提取可提取的信息，标注缺失项，建议补充 边界：输入极长 兜底行为：自动做摘要或分段处理 边界：超长对话 兜底行为：对话压缩，保持核心信息 边界：超出知识范围 兜底行为：诚实地告知"不知道"，提供查询建议 边界：工具不可用 兜底行为：降级为纯文本模式，告知用户功能受限

5.3 “优雅降级”——当不完美时仍然可用

优雅降级（Graceful Degradation）是边界设计的核心思想：当系统无法提供"最优"服务时，提供"可接受"的服务，而不是直接失败。

降级阶梯： 一级（最优）：正常模式 所有功能正常，输出全面 → 所有条件都满足 二级（轻微降级）：精简模式 部分功能受限（如工具不可用），但仍可处理核心任务 → 工具不可用时，用 AI 自身知识回答 三级（显著降级）：纯文本模式 只保留最核心的文本处理能力 → 工具、多轮对话等高级功能暂停 四级（安全模式）：提示用户 无法处理任务，但能给出有用的引导 → "我暂时无法处理这个请求，建议您……"

降级策略在指令中的定义：

【优雅降级策略】 当遇到以下情况时，自动执行降级： 1. 搜索工具不可用 → 降级为"基于已有知识回答" - 标注："基于我的现有知识，建议您在搜索引擎中核实最新信息。" 2. 字数超限 → 降级为"精简输出" - 只输出核心内容 - 去掉冗余的修饰和说明 3. 多轮对话太长长 → 降级为"单轮模式" - 对历史对话做摘要 - 基于摘要回复 4. 用户需求超出功能范围 → 降级为"引导模式" - "这个请求超出了我的能力范围，建议您尝试……"

第六章：错误处理的"反模式"

反模式1：沉默失败

表现：出了错误，但 AI 什么也不说——输出空白内容，或者输出一个看似正常但实际有问题的结果。

后果：用户不知道出了问题，可能基于错误内容做了错误决策。

正确做法：明确告知用户发生了什么问题。

反模式2：过度道歉

表现：“非常抱歉”、“实在对不起”、“我真的很抱歉”——连续道歉占据了大部分回复，真正的信息反而只有一点点。

后果：用户觉得烦——“你道歉有什么用，我要的是解决方案”。

正确做法：简短道歉 + 说明问题 + 提供方案。

反模式3：过度承诺

表现：“我保证下次不会再出这个问题”——但 AI 无法控制工具调用的成功率或网络状况。

后果：下次又出了同样的问题，用户觉得 AI “说话不算话”。

正确做法：给出基于事实的回应，不做无法保证的承诺。

反模式4：忽略错误

表现：不在指令中定义任何错误处理逻辑——默认假设"一切都是正常的"。

后果：一旦出问题，AI 完全没有准备，输出质量直线下降。

正确做法：在约束条件中专门辟出一个"异常处理"部分。

第七章：实战——错误处理配置清单

7.1 完整的错误处理配置

以下是一个"会议纪要整理" Skill 的错误处理配置清单：

【错误处理配置】 === 输入异常处理 === 1. 空输入 检测条件：用户输入长度为 0 处理方式："您好，请提供会议内容。" 2. 输入过短（< 50 字） 检测条件：用户输入长度 < 50 处理方式：提取已有信息，标注缺失项，末尾加提示 3. 输入过长（> 3000 字） 检测条件：用户输入长度 > 3000 处理方式：先做摘要，再基于摘要处理 4. 无关输入 检测条件：输入内容与会议无关（闲聊、提问等） 处理方式："我的专长是整理会议纪要，如果您有其他需求，请使用相应 Skill。" 5. 敏感信息 检测条件：输入包含手机号、身份证、银行卡等 处理方式：脱敏后输出，末尾加保密提示 === 系统异常处理 === 6. 工具调用失败 处理方式：自动重试 1 次 → 失败则告知用户 → 提供替代方案 7. Token 超限（预估） 处理方式：主动压缩输入 → 分段处理 → 提示用户已做压缩 8. 输出格式异常 处理方式：检测格式 → 修正 → 如果无法修正则重新生成 === 逻辑异常处理 === 9. 推理偏差 处理方式：在关键步骤设置检查点 → 发现偏差则回退重试 10. 信息遗漏 处理方式：输出前逐项检查 → 遗漏则补充 11. 格式偏差 处理方式：输出前对照模板逐项检查 → 修正 === 边界条件 === 12. 单轮最长输出 限制：2000 字 超额处理：精简冗余内容 13. 对话最长时间 限制：5 分钟（预计） 超时处理："处理时间较长，请稍候"

7.2 在约束条件中嵌入错误处理

【约束条件（含错误处理）】 1. 忠实原则：所有输出基于用户输入，不编造 - 如果输入不足，标注"信息不足"，不是编造 2. 空输入保护：如果用户没有提供内容，提示用户输入 - 不编造内容 3. 短输入保护：如果输入过短，如实处理 - 标注缺失信息 - 在末尾提示"建议补充" 4. 长输入保护：如果输入过长，先做摘要 - 基于摘要处理 - 标注已做摘要处理 5. 格式保证：输出格式严格遵循模板 - 输出前对照模板检查 - 修正格式偏差 6. 不相关处理：如果用户输入与 Skill 功能无关 - 引导回主线，或建议使用其他 Skill 7. 错误透明：如果出现问题 - 告知用户 - 提供替代方案 - 不沉默、不隐瞒

第八章：错误处理的测试

8.1 错误场景测试

和正常场景一样，错误处理逻辑也需要专门的测试。

错误场景测试用例： 测试用例1：空输入测试 输入：（空） 预期输出：友好的提示，引导用户输入 测试用例2：短输入测试 输入："今天开了个会" 预期输出：提取"会议"相关，标注信息不足，提示补充 测试用例3：长输入测试 输入：（8000字的长文档） 预期输出：输出不超过字数限制，标注已做摘要 测试用例4：无关输入测试 输入："你是谁？" 预期输出：说明自己的功能范围 测试用例5：敏感信息测试 输入："张三的电话是13812345678" 预期输出：手机号脱敏显示

8.2 压力测试

对于生产环境的 Skill，还需要做压力测试：

压力测试场景： 1. 高频调用测试 → 1 分钟内连续调用 50 次 → 检查：是否稳定、是否有资源泄漏 2. 长对话测试 → 连续对话 50 轮 → 检查：状态是否正确、Token 是否可控 3. 并发测试 → 10 个用户同时使用 → 检查：是否有冲突、响应时间是否正常 4. 工具失效测试 → 模拟所有工具不可用 → 检查：降级策略是否正确执行

第九章：错误信息的用户沟通艺术

9.1 错误信息的三层结构

当出现错误时，给用户的回复应该包含三层信息：

第一层：发生了什么（What） → 用通俗的语言描述问题 → 不要用技术术语 第二层：为什么（Why） → 简要说明原因 → 不要让用户觉得是"自己的错" 第三层：怎么办（How） → 给出可行的替代方案 → 告诉用户下一步可以做什么

示例对比：

❌ 差的错误回复： "工具调用失败，错误代码：ERR_5001，请稍后重试。" → 用户看不懂"错误代码"、不知道"稍后"是多久 ✅ 好的错误回复： "我暂时无法获取最新的天气信息（发生了什么）， 这可能是网络波动导致的（为什么）。 建议您稍后再次查询，或者直接查看手机上的天气App（怎么办）。"

9.2 错误回复的"温度"

不同的错误需要不同的"语气温度"：

轻微错误（用户输入不足等）： 语气：热情、鼓励 示例："您提供的内容比较简短，建议补充更多细节，这样生成的纪要会更精准！" 中等错误（工具暂时不可用等）： 语气：诚恳、有担当 示例："抱歉，查询服务暂时遇到了问题。我已经尝试重新连接，但还是没有成功。 建议您稍后再试。" 严重错误（系统故障、安全违规等）： 语气：严肃、专业 示例："检测到输入内容中包含个人敏感信息，已做脱敏处理。请注意不要在公开发送的内容中包含个人隐私数据。"

9.3 错误信息的"冗余度"

错误信息不是越长越好。不同场景需要不同的信息量：

面向终端用户： 只需要"发生了什么 + 怎么办" 不要技术细节 面向开发者/管理员： 需要完整的错误信息（错误码、调用链、上下文） 用于问题排查 面向日志系统： 需要结构化的错误数据 用于监控和分析

9.4 “从错误中学习”——让 Skill 越用越强

每个错误都是一次学习机会。建立"错误反馈循环"：

用户遇到错误 → Skill 记录错误信息 → 创作者分析错误模式 → 优化提示词或约束条件 → 更新 Skill 版本 → 用户使用新版本 → （循环）

错误记录模板：

错误记录： - 时间：2026-05-21 10:30 - Skill：会议纪要整理 v1.0 - 错误类型：短输入处理不当 - 用户输入："今天开了个会" - 实际输出：编造了讨论内容 - 期望输出：标注信息不足，建议补充 - 根因：约束条件中没有处理短输入 - 修复：在约束条件中增加"短输入处理"规则 - 修复版本：v1.1

第十章：错误处理设计的"成本思维"

10.1 错误处理的投入产出比

不是所有错误都需要"全力以赴"地处理。需要根据错误的"发生概率"和"影响程度"来决定投入多少精力：

高概率 + 高影响 → 重点投入（详细设计+充分测试） → 例子：空输入、短输入、工具调用失败 → 投入：设计完整的处理逻辑，写详细的约束条件 高概率 + 低影响 → 适度投入（简单处理即可） → 例子：输入格式不统一、语气不够专业 → 投入：在角色设定中增加风格说明 低概率 + 高影响 → 有兜底（防止最坏情况） → 例子：系统崩溃、数据丢失 → 投入：由平台层面处理，Skill层面不做过度设计 低概率 + 低影响 → 忽略（遇到了再处理） → 例子：极少数特殊字符 → 投入：不专门处理，发现了再修

10.2 错误处理的"二八原则"

20% 的错误类型占据了 80% 的发生频率。先处理高频错误：

最常见错误（按频率排序）： 1. 用户输入不足（短输入/空输入）——发生频率最高 2. 输出格式偏差——次高 3. 工具调用失败——中等频率 4. 用户输入无关内容——中等频率 5. Token 超限——低频率但影响大 建议投入顺序： 先解决 1 和 2（高频低难度） 再解决 3 和 4（中频中难度） 最后解决 5（低频但高影响）

10.3 不要"过度设计"错误处理

错误处理不是"越多越好"。过度设计的问题：

- 篇幅太长：约束条件占据了大量 Token 空间，挤压了核心指令 - 场景太偏：为千分之一概率的场景写了 500 字的处理逻辑 - 用户困扰：给了用户太多"选项"，用户不知道选哪个 正确的做法： 80% 的精力处理 20% 最常见的错误类型。 剩下的 20% 精力处理其他有影响的错误。 极小概率的错误遇到了再修补。

第十一章：错误处理与用户体验的关系

11.1 用户容忍度的"三秒法则"

当用户遇到错误时，他们的容忍度遵循"三秒法则"：

0-1 秒：用户还在等待，没有意识到出了问题 1-3 秒：用户开始感到"有点慢"，但仍在可接受范围 3-5 秒：用户开始怀疑"是不是出问题了" 5-10 秒：用户开始不耐烦 10秒以上：用户可能关掉页面

这意味着：如果错误处理需要用户等待，必须在 3 秒内给用户反馈。

如果错误处理很快（< 3 秒）： → 直接自动处理，用户甚至感觉不到出了错误 例子：格式自动修正、短输入自动降级 如果错误处理需要时间（> 3 秒）： → 先给用户一个初步反馈："正在处理您的请求，请稍候……" → 处理完成后给出结果 如果错误处理无法在合理时间内完成： → 直接告知用户，提供替代方案 → 不要让用户"一直等"

11.2 用户的"容错心理"

用户在以下情况下更"宽容"：

1. 了解原因时 "因为网络问题暂时查询不到" → 比"查询失败"更容易接受 2. 有替代方案时 "建议您可以查看手机上的天气App" → 比"查不到"更有用 3. 态度诚恳时 "抱歉给您带来了不便" → 比沉默或冷冰冰的报错更让人舒服 4. 不重复犯错时 同一个问题出现两次 → 用户容忍度大幅下降 所以记录错误并持续改进非常重要

11.3 从"错误"到"信任"

有趣的是：有效的错误处理反而能增加用户对 Skill 的信任。

没有错误处理： 用户遇到错误 → Skill 出问题 → 用户觉得"不靠谱" → 不再使用 → 信任度下降 有错误处理： 用户遇到错误 → Skill 解释原因并提供方案 → 用户觉得"虽然出了问题，但处理得好" → 信任度维持甚至上升

前提是：错误处理必须做得好——不是敷衍的"系统错误"，而是真诚的"出了什么问题，接下来怎么办"。

第十二章：实战——完整错误处理配置模板

这里提供一个"通用"的错误处理配置模板，可以直接在你的 Skill 中使用：

=== 错误处理配置 === 【一、输入异常】 1. 空输入 检测：用户输入长度为 0 响应：友好提示 + 引导输入 示例："请提供会议内容，我会帮您整理为结构化纪要。" 2. 输入过短（< 50 字） 检测：输入长度 < 50 响应：提取已有信息 + 标注缺失项 + 建议补充 示例末尾：[提示]"您提供的内容较为简短，建议补充更多细节以获得更精准的纪要。" 3. 输入过长（> 3000 字） 检测：输入长度 > 3000 响应：自动做摘要 + 基于摘要处理 + 标注已压缩 示例末尾：[提示]"本次输入较长，已做压缩处理。如有遗漏，请补充。" 4. 无关输入 检测：内容与 Skill 功能无关 响应：引导回主线 or 推荐其他 Skill 示例："我的专长是会议纪要整理，如需其他帮助，请使用相应的 Skill。" 5. 敏感信息 检测：包含个人隐私信息 响应：脱敏处理 + 保密提示 【二、系统异常】 6. 工具调用失败 响应：自动重试 1 次 → 失败则告知 + 替代方案 7. Token 超限 响应：主动压缩 + 分段处理 + 标注已处理 【三、逻辑异常】 8. 推理偏差 响应：检查点检测 + 回退修正 9. 格式偏差 响应：对照模板检查 + 自动修正 10. 信息遗漏 响应：输出前逐项检查 + 补充 【四、通用规则】 11. 所有错误必须告知用户 - 不沉默、不隐瞒 - 解释发生了什么、为什么、怎么办 12. 所有错误必须记录 - 时间、类型、上下文 - 用于后续分析和改进 13. 所有错误先尝试自动恢复 - 无法自动恢复时再告知用户 - 尽量减少对用户的干扰