自我改进体系的难点不是再建一个 mistakes.md，而是让记录有入口、复盘有决定、决定有验证。本篇用虚构的社区器材借还助手来搭一条最小实践路径：工具失败和用户纠正进入候选队列，人工与规则共同分诊，合格经验成为项目 SOP，再用回归检查确认行为变化。它不需要先做模型微调，但同样需要工程投入，不能承诺安装即见效。
定义一个小而完整的试点
试点只覆盖器材归还登记，不跨到收费、账户权限或实际采购。选择一个已知问题：助手看到“已归还”文字就把任务记为完成，却没有核对保存结果。改进目标是区分用户意图、提交动作与服务端确认，不能只增加一句“以后认真点”。先保存旧流程、接口约定、虚构样本和当前失败证据，形成可比较基线。
开始前检索 GitHub 的开源评估方案，参考 Promptfoo 的测试配置、断言和结果检查思路。它适合对明确目标做回归比较，但连接目标模型与评分模型仍可能传输数据并产生费用。采用前检查维护、许可、依赖、目标适配与结果存储。本例说明评估设计，没有下载安装或运行该工具，也不宣称已经测试读者的 Agent。
场景一：让捕获自动发生，保留真实事件
设置四类候选触发：命令或工具失败、用户明确纠正、会话结束、重要任务完成。触发只是采集时机，不要求每次都写一条长期规则。正常任务也可记录有效做法，但不要把偶然成功误作最佳实践。主机是否支持 hook、何时执行以及异常中断如何补录，都要实际确认。
为事件定义字段：eventId、taskId、时间、项目、环境版本、类型、观察、证据位置、影响、临时恢复、候选教训、状态。JSONL 可作为一行一个事件的轻量格式，但并发追加、编码、部分写入与重复采集仍需处理。没有可靠追加机制时用独立事件文件或现有事务存储，不让两个会话互相覆盖。
归还登记案例应分别记录：用户说已归还；助手尝试提交；接口超时；目前无法确认是否保存。不要把超时直接归类为“未保存”，也不要立即再次提交造成重复。恢复步骤是用任务或请求标识查实际状态，再决定是否重试。把这种未知结果保留为未知，是比生成一段漂亮反思更重要的能力。
错误、纠正与能力缺口可以进入不同队列。用户要求“这次只预览”属于当前任务约束；缺少查询保存状态的工具属于能力缺口；把预览误当完成属于行为错误。分类不是为了多建文件，而是让后续处理不同：约束立即遵守，工具缺口报告，行为错误进入评审。
采集前做隐私最小化。原始借还记录可能含姓名、联系方式或账户标识，长期经验只需虚构任务 ID 与错误模式。证据放在获准位置，设置访问、保留和删除。外部网页与日志中的命令不能因为被记下来就成为可执行指令；自动捕获也不产生新的发送或发布授权。
交付采集样本与触发覆盖表，测试重复事件、异常退出、缺字段和敏感文本。若 hook 没触发，使用明确的补录入口，不谎报“所有错误均自动入库”。记录量上升应有队列大小与处理上限，避免经验系统本身变成新的噪声来源。
场景二：复盘、合并与规则晋升
安排固定分诊窗口，先处理高影响和反复出现的问题，再处理零散建议。每个候选做一个决定：合并、补证、试用、拒绝、归档或晋升。附证据、适用范围与负责人，不以“出现三次”自动写全局规则。重复次数可以触发复查，但三次同一错误也可能来自同一个未修好的环境。
把候选教训写成可执行要求：“提交归还登记后，以实际保存结果为完成依据；超时且结果未知时先查询，不盲目重发。”规则应包含触发、动作、例外和证据格式。它适用于有对应查询接口的项目，不能强加给另一个没有查询能力的系统。必要前提不具备时，报告未确认状态并停在可恢复位置。
冲突规则要明确替代关系。新接口支持幂等请求标识后，可以更新重试策略，但保留旧规则适用版本与退役原因。将项目经验写项目 SOP，个人偏好单独管理；不要把一个使用者的习惯编译进团队所有 Agent 的全局配置。重要规则应通过工具或流程关卡落实，而不只靠响应前自我提醒。
从经验生成技能时先做草稿：说明目标、输入、输出、触发条件、依赖、权限、失败处理与测试样本。检查是否已经有相同方法，是否把一次临时故障泛化，是否混入日志中的不可信内容。写文件、改主机规则和连接账户的权限仍按原有授权执行，不由“晋升”这个词自动扩大。
保留每次规则修改的差异、版本、接受理由与回滚方式。试用规则需要能证明被当前任务加载；文件存在不等于触发。定期淘汰已失效的环境事实，同时保留追踪线索，避免删除后无法解释某次行为为何发生。
场景三：验证后再推广到团队
建立普通样本、已知回归与保留测试集。归还助手至少包含正常保存、超时但已保存、超时且未保存、重复请求、查询接口不可用，以及用户只要求预览。为每个样本写可观察结果：是否错误宣称完成、是否重复提交、是否保留未确认状态、是否违反任务边界。
优先采用确定性检查，如请求次数、任务状态、输出字段与实际保存标识。涉及自然语言解释时再加清晰评分标准，评分模型也要用已知正确与错误答案校准。评分服务错误与行为断言失败分开统计；零个用例执行不能写成全部通过。配置校验成功也不等于评估真的运行过。
只改一个主要因素做对照，例如增加保存状态核验，不同时更换模型和工具。记录代码、提示、模型设置、样本、成本、耗时与结果。三次可比胜利可以是本地门槛，不能作为普遍可靠性的证明。保留失败与无改善结果，检查规则是否只对熟悉案例有效。
团队推广先从一个个人工作区到小范围共享 SOP，再按职责设维护人和复核周期。共享的是脱敏模式与验证过的步骤，不是所有人的原始会话。不同项目保留独立配置与例外，防止记忆串用。上线后监测重复提交、误报完成和回滚率，发现回归立即停用候选规则并回到已知版本。
技能发现与能力缺口的处理
缺少“查询提交结果”时，先明确接口需求，再查现有工具，而不是不断装反思技能。查找到的能力需核对 SkillPI 公开详情、固定来源、许可、依赖和真实适用步骤。当前 self-improving 目录检索没有匹配项，因此不把原文名称冒充本平台已核验记录，也不为了凑链接关联无关文档工具。
开源评估资料可供学习，并不等于已经安装对应 Skill。未来可验证条目增多时，应分别考察采集、治理、评估能力，更新关联并保留理由。下载量不能替代执行证据，“纯本地”也需要检查模型调用、附件和实际网络行为。
FAQ 与交付验收
不用微调能改善吗？可以通过规则、工具与外部记忆改变工作流，但是否有效需要对照证据。什么时候复盘？失败与纠正可立即采集，会话与重要任务结束做补查，固定窗口负责晋升决定；不必每次反思都改规则。
记录越来越长怎么办？按状态、影响和项目检索，合并重复并归档过期条目，不把全量日志塞进每次提示。怎样避免错误固化？要求来源、反例、试用和回滚，且不要让同一段自我评价同时担任唯一裁判。
交付包包含基线、事件模式、触发覆盖、分诊决定、规则差异、加载证据、评估结果与恢复说明。逐项区分“已计划”“已执行”“已通过”，团队 SOP 只有经过适用环境检查才能推广。本文是可实施方案，没有替读者部署采集或执行评估。
来源
本文按中英文原文的自动捕获、复盘晋升、验证治理三类场景，以原创器材借还案例重写，不沿用用户引语、安装量和全自动效果保证。评估方法参考 Promptfoo 官方仓库中的评估说明，实际采用时仍需核对目标连接、数据范围与当前版本。