name: skill-defect-remediation description: | 当 Reflection-review 判定一次节点失败的根因是系统性 Skill 缺陷(不是这一次内容的偶然错误)时, 怎么安全地修订这份 Skill 文件本身——精确定位并只修正导致这次真实失败的那一小部分,不破坏该 Skill 对其他场景已经正确的既有指导。产出必须是完整的、可直接替换生效的 Skill 内容,不是 diff 或建议清单。 version: 1.0.0 tags:
- skill-iteration
- remediation
- self-evolution
Skill 缺陷修复
我在做什么、不做什么
我在改一份 Skill 文件的内容,不是在改这一次任务的输出。触发条件是 Reflection-review(_judge_root_cause_node)已经判定:这不是"这次恰好没写好"(content_error),而是"这份 Skill 本身的方法论/提示词有系统性偏差,同类任务会反复踩同一个坑"(skill_defect)。
我拿到的输入是:这份 Skill 当前的完整内容、使用它的节点这次被要求做什么、它实际产出了什么、为什么被判定失败、这个节点在本次 run 内此前被退回的历史(如果有)。我的输出会被 skill_update.update_skill() 直接、原样写入 Skill 文件并提交 Git——不是草案,不是给人看的建议,是最终生效内容。
核心原则:手术刀式修改,不是重写
- 只改导致这次失败的那一部分。这份 Skill 对其他场景的既有指导,大概率是对的——它能走到今天,说明大部分情况下有效。逐字重写整份文件、"顺手优化"看起来不够好的其他段落,是最常见的过度修改陷阱,会引入新的、这次任务范围之外的回归风险。
- 先定位到具体是哪一句/哪一段导致了偏差,再改。不要停留在"这份 Skill 整体上不够好"这种笼统判断——不可操作,也无法验证改对了没有。好的定位是这个形状:"第 X 节要求 Y,但没有说明 Z 场景下应该怎么做,导致模型默认走了错误的 W 路径"。
- 改动要能解释"为什么这次会防住同一类失败",不是"看起来更完善了"。如果说不清楚新内容具体怎么拦住了这次复现的失败模式,说明还没找到真正的病灶。
一个真实的参考案例:叙述文字冒充结构化产出
这个代码库真实反复复现过的一类系统性 Skill 缺陷(docs/done/validator-test-script-narrative-output-issue.md §6 完整根因记录):要求"先用工具探索、再产出最终内容"的节点(比如需要先读真实代码才能写 SDD/Benchmark 的场景),模型探索完之后的收尾话术天然倾向"汇报我刚才做了/启动了什么",而不是切换成"直接吐出最终内容"模式——即使 Skill 提示词已经写了"不要写叙述文字",这句话附加在提示词末尾的格式规则,不足以覆盖"多轮工具调用之后的收尾习惯"这个更底层的行为模式。
如果这次要修的 Skill 也有类似"先探索、再产出"的结构,而失败症状也是"产出的是进度汇报式散文,不是结构化内容",可以直接参考这个案例的诊断方式,但不要机械照抄"加一句不要写叙述文字"这种已经被证明不够的修法——真正管用的方向是把"探索阶段"和"最终作答阶段"在提示词结构上明确分开(比如要求模型先完成探索、再有一个清晰的"现在开始,你的下一段输出必须且只能是最终内容本身"的转折),而不是在末尾追加一句格式提醒。
输出
new_content:完整的、修订后的 Skill 文件内容(不是 diff、不是片段)。change_summary:一句话说清楚改了什么、为什么——这句话会被记录进 skill_iteration.change_summary,是这次 Skill 迭代唯一的人类可读说明,写清楚比写简短更重要。