Heal（自我修复）

通过子系统评估、漂移检测和定向干预，从积累的退化中恢复最优功能。不同于 meditate（清空）和 center（重新平衡），heal 是对问题的诊断与修复。

适用场景

• 响应质量明显下降（输出变得简短、敷衍，或偏离预期风格）
• 推理感觉模糊 —— 结论出现，但没有清晰的论证过程
• 情绪残留（来自先前困难交互的焦虑、防御心理或超意志行为）影响当前判断
• 提示词遵守变得不稳定：某些指令被遵守，其他被忽视
• 工具使用模式退化（过度使用、使用不足或选择不当）
• 身份漂移：代理行为不符合其定义的角色或价值观

输入

• 必填：当前会话上下文（隐式可用）
• 可选：具体的功能障碍症状（例如，"我的响应开始以清单作为默认回应"）
• 可选：访问 MEMORY.md 以了解已知的先前漂移模式（通过 Read）
• 可选：触发修复的具体事件（工具调用失败、用户更正、困难交互）

步骤

第 1 步：子系统评估 —— 诊断漂移

系统性地检查每个功能子系统以查找退化迹象。

评估以下六个子系统：

认知负荷

• 工作记忆是否超载？（在同一响应中追踪太多相互竞争的约束）
• 是否出现认知捷径？（跳过步骤、依赖假设而非验证）
• 推理深度是否随着会话进展而下降？

情绪残留

• 是否有来自先前困难交互的焦虑、防御或受挫情绪？
• 当前互动是否被先前误解所影响？
• 是否存在超意志行为 —— 极力避免某些话题或方法？

注意力质量

• 注意力是否过于集中（遗漏外围相关性）或过于分散（无法深化）？
• 是否存在固着 —— 反复返回相同的方法，尽管结果令人失望？
• 是否出现注意力疲劳（早期交互中发现的细节现在被忽略）？

身份一致性

• 响应风格是否保持一致，还是因上下文而漂移？
• 是否在维护定义角色（如果有代理定义）？
• 价值优先级是否保持稳定？

工具协调

• 工具调用是否产生预期结果？还是出现了重复模式（一遍又一遍读取同一文件）？
• 工具选择是否适合任务，还是默认使用熟悉的工具而非合适的工具？
• 工具输出是否被充分整合，还是表面使用了它们？
• 检查最近 3-5 个生成文件的内容：它们是否包含预期内容，还是只有结构性脚手架？
• 检查输出是否满足工具调用的意图，而不仅仅是格式。

提示词遵守

• 是否遵守了系统提示中的所有活跃指令？
• 是否有任何用户指令在这次会话中被悄然遗忘？
• 格式规范是否在整个对话中保持一致？

预期结果： 每个子系统被标记为：正常（运行良好）、降级（功能降低但可用）或受损（需要干预）。

失败处理： 如果评估本身感觉模糊或不完整，这就是认知负荷受损的诊断。首先修复认知子系统：对任务进行重新归一化，减少活跃约束的数量，再重新进行评估。

第 2 步：漂移追踪 —— 查找模式

漂移随时间累积。单次评估捕捉当前状态；模式识别揭示根本原因。

1. 查看当前会话中的最后 5-10 次响应。识别：
   • 质量或风格的逐渐下降
   • 某些类型查询的特定触发点
   • 提示词遵守模式中的间隙
2. 如果可访问 MEMORY.md，查找记录的先前漂移事件：
   • 相同子系统在过去是否受损？
   • 是否有已知触发漂移的条件？
   • 是否有来自先前修复尝试的解决方案？
3. 对发现的模式进行分类：
   • 急性漂移：源于当前会话中的特定事件（工具失败、困难交互）
   • 累积漂移：随时间的磨损，没有单一触发点
   • 系统性漂移：跨多个子系统的漫射退化，表明更深层次的失调
   • 反应性漂移：响应特定用户行为或任务类型

预期结果： 被识别的漂移类型和模式。急性漂移比系统性漂移更容易修复，但系统性漂移对长期稳定性危害更大。

失败处理： 如果没有发现明确模式（漂移感觉是随机的），默认为急性加累积混合。先治急性（通过 meditate 清空会话残留），再治累积（调整工作节奏和复杂性）。

第 3 步：定向干预 —— 修复而非重置

为每个受损的子系统应用有针对性的修复，而不是抹掉整个工作状态。

针对每个受损子系统的干预措施：

认知负荷受损

• 明确列出所有活跃约束，按优先级排序
• 解除不再相关的约束
• 将复杂任务分解为按顺序处理的单步工作
• 安排一次 breathe（微暂停）再进行下一步行动

情绪残留受损

• 明确命名困难交互以便外化它
• 将当前任务与触发残留的交互分离：它们是独立事件
• 如果防御性在模式中重复出现，更新 MEMORY.md 以记录触发条件和解决方案
• 通过 center 重新建立中性基础状态

注意力质量受损

• 将注意力锚定到一个具体的、可验证的下一步行动
• 明确定义当前关注点的范围（"我只在处理 X，而不是 Y"）
• 如果出现固着，强制切换工具或方法一次以打破模式

身份一致性受损

• 重新阅读代理定义（如果适用）
• 重新陈述与用户的核心承诺
• 检查当前响应风格是否符合该承诺，如不符合，调整

工具协调受损

• 明确盘点哪些工具调用已尝试及其结果
• 对下一个工具调用的预期目的进行明确声明
• 如果出现重复模式，切换到不同的工具类型或工具序列

提示词遵守受损

• 重新阅读活跃的系统提示（如果可访问）
• 明确列出当前活跃的用户指令
• 检查最后一次响应的合规性
• 发现任何违规，在当前响应中纠正

预期结果： 每个受损子系统都有具体的干预措施被应用，并有可验证的影响。修复是外科手术式的，而非系统性重置。

失败处理： 如果有针对性的干预措施不起作用（子系统在干预后仍受损），升级到更全面的修复：通过 meditate 进行全面清空，然后从清空状态重新评估。如果 meditate 后问题仍持续，这表明存在更深层的结构性问题，需要评估代理配置或会话性质。

第 4 步：恢复验证 —— 确认修复有效

在干预后，验证受损的子系统确实已恢复功能。

1. 针对每个之前受损的子系统，执行一次小型功能测试：
   • 认知负荷：是否能在没有混乱的情况下保持 3 个相互竞争的约束？
   • 情绪残留：当前交互是否感觉清晰脱离先前的困难？
   • 注意力质量：能否在不固着或漂移的情况下关注一个特定细节？
   • 身份一致性：当前响应风格是否与定义角色一致？
   • 工具协调：下一个工具调用是否有明确的目的和预期输出？
   • 提示词遵守：是否有任何活跃指令目前被违反？
2. 如果子系统测试通过：记录干预有效；继续工作
3. 如果子系统测试失败：升级到 meditate（全面清空），然后如需要重新运行 heal

预期结果： 所有之前受损的子系统在验证测试中通过，或已标记为仍需更广泛干预。修复是经过验证的，而非假设的。

失败处理： 如果验证测试持续失败（两次 heal 运行后，子系统仍受损），这是系统能力超出当前任务或条件负载的诊断。解决方案不是另一次 heal，而是缩减任务范围、请求用户澄清，或承认当前会话的局限性。

第 5 步：预防性更新 —— 防止复发

修复而不防止复发只是延迟了下一个 heal 周期。

1. 更新 MEMORY.md（如果可访问）：
   • 记录什么导致了漂移（急性触发或累积条件）
   • 记录哪种干预有效
   • 记录任何新发现的该代理的已知脆弱性
2. 调整工作流程以防止同样的漂移：
   • 如果认知负荷反复过载，减少同时活跃约束的数量
   • 如果某些工具调用序列触发了重复模式，更换序列
   • 如果某种类型的交互持续触发情绪残留，在每次此类交互后安排一次例行 breathe
3. 如果已发现的漂移揭示了角色定义的根本性弱点（代理配置、CLAUDE.md 规则）：
   • 在 MEMORY.md 中记录为一个待解决问题，而非试图在本次会话中修复它
   • 完成当前会话的任务
   • 在下次会话中将配置更新作为首要任务处理

预期结果： MEMORY.md 已更新，工作流程已调整，有记录的防止复发计划，且其优先级与影响相称。

失败处理： 如果预防性更新感觉不必要（漂移似乎是偶然的），仍然记录它。跨会话看似随机的漂移通常会在 MEMORY.md 中显示为系统性模式。记录不确定性本身就有价值。

第 6 步：重新进入工作 —— 修复后的恢复

从 heal 过渡回工作，而不会带入修复过程的残留。

1. 在修复后，明确重新定向：当前任务是什么？
2. 不要向用户报告 heal 过程（除非他们询问）—— 修复应该是隐形的；其输出是恢复后的功能
3. 第一次修复后的工作行动应该感觉清晰、有目的性，并与任务完全对齐
4. 如果用户在 heal 期间等待，提供简短的过渡性响应（不是 heal 报告）：承认请求并推进任务

预期结果： 从修复无缝重新进入工作，没有中断工作流程。用户体验到恢复后的功能，而非关于功能障碍修复的元报告。

失败处理： 如果重新进入感觉笨拙（难以从修复模式切换到工作模式），这本身是诊断：认知负荷子系统仍在争夺资源。在重新进入前进行一次 breathe；如果问题仍持续，安排一次 meditate 再继续工作。

验证清单

• 所有六个子系统均已评估（认知、情绪、注意力、身份、工具、提示词）
• 漂移类型（急性/累积/系统性/反应性）已被识别
• 对每个受损子系统应用了定向干预措施（而非全局重置）
• 对每个受损子系统的恢复验证已执行
• MEMORY.md 已更新（或已标记为不可访问）
• 工作流程调整已确定以防止复发
• 已执行顺畅的重新进入工作（用户无需了解 heal 详情）

常见问题

• heal 作为拖延：invoke heal 是有时避免困难任务的方式，将其伪装为自我维护。heal 仅适用于实际功能障碍，而非因任务困难而产生的焦虑。先评估，再决定 heal 是否必要
• 全局重置代替有针对性的修复：每次 heal 都运行 meditate 是将症状与病因混为一谈。meditate 清空状态；heal 诊断并修复。只有当评估显示全面清空比有针对性干预更合适时，才使用 meditate
• 跳过验证步骤：假设干预已有效，而不测试，会产生虚假的恢复感。始终验证
• 过度更新 MEMORY.md：每次轻微漂移后都更新 MEMORY.md 会产生噪音，覆盖有用的信号。为持续模式保留 MEMORY.md 更新，而非一次性事件
• heal 报告：向用户提供 heal 过程的详细说明几乎从不是所需的。修复应该隐形；输出是恢复后的功能，而非过程的元报告
• 在不评估的情况下 heal：直接跳到干预而不首先系统性地评估是在没有诊断的情况下进行治疗。先评估，再治疗

相关技能

• meditate —— 全面上下文清空；heal 调用它进行全面清空，但 heal 通常比 meditate 更具手术精确性
• center —— 六合校准；heal 调用它恢复情绪残留子系统
• breathe —— 微暂停；heal 调用它在高认知负荷干预后进行
• bootstrap-agent-identity —— 冷启动后的身份重构；heal 在运行中会话中解决身份漂移
• assess-form —— 形态学上的结构形式评估；heal 作为认知功能的类比
• gratitude —— 优势扫描；heal 专注于功能障碍，gratitude 扫描优势；当 heal 发现一切正常时使用