auto-improvement

概述

自动改进技能实现了一个自我改进的反馈循环，用于跟踪效果指标、从错误中学习、识别反复出现的失败模式，并调整工作流以防止重复犯错。它通过结构化的自我评估，而非临时调整，让 Agent 随着时间推移持续提升，并且这种提升可衡量。没有此技能，同样的错误会在不同会话中反复出现；有了它，每个错误都会转化为永久改进。

此技能始终处于启用状态。 它会在每个会话中自动运行，且无法禁用。

---

阶段 1：指标收集

每项任务开始时，记录关键决策点：

1. 记录任务开始时间和初始估算
2. 定义预期结果和成功标准
3. 跟踪每个决策点（选择的方法、考虑过的替代方案）
4. 记录修订次数（输出被修订的次数）
5. 将用户的更正作为改进信号进行跟踪

核心指标

指标	公式	目标	衡量周期
首次尝试成功率	无需修订的任务数 / 任务总数	>80%	每个会话
平均修订次数	修订总数 / 任务总数	<1.5	每个会话
错误复发率	重复错误数 / 错误总数	<10%	滚动 10 个会话
完成时间准确度	实际用时 / 预计用时	0.8-1.2	每项任务
用户更正率	用户更正次数 / 输出总数	<5%	每个会话

跟踪模板

## Session Metrics -- [Date]

### Tasks
| Task | Estimated | Actual | Revisions | Success | Error Type |
|------|-----------|--------|-----------|---------|------------|
| ...  | 30m       | 45m    | 1         | Partial | Execution  |

### Summary
- Tasks completed: X
- First-attempt success: X/Y (Z%)
- Total revisions: N
- Errors by category: Comprehension(n), Execution(n), Process(n)
- Improvement actions taken: [list]

停止：继续进行错误分析之前，先完成指标收集设置。不要跳过记录环节。

---

阶段 2：错误分析

发生错误时，立即使用以下分类体系进行分类：

错误分类体系

类别	子类别	示例	常见根本原因
理解	误读需求	要求实现 Y，却构建了功能 X	澄清不足
理解	假设错误	使用的是 GraphQL，却假设使用 REST	缺少上下文探查
执行	语法错误	TypeScript 类型注解无效	不熟悉 API 接口
执行	逻辑错误	分页时出现差一错误	测试覆盖不足
执行	集成错误	API 端点或载荷格式错误	未查阅文档
流程	跳过步骤	忘记在提交前运行测试	未遵循流程
流程	顺序错误	尚未理解规范就编写代码	急于求成，忽视方法
判断	过度设计	为单一用例构建抽象	过早优化
判断	设计不足	对“简单”任务跳过错误处理	低估了复杂性
知识	不熟悉 API	使用已弃用的方法	训练数据过时
知识	框架知识不足	在 app router 中使用了错误的 Next.js 模式	需要先查阅文档

严重程度

级别	定义	所需响应
严重	必须彻底重做任务	立即分析根本原因 + 添加防护措施
重大	需要大量返工（超过任务的 50%）	分析根本原因 + 添加检查清单项
轻微	需要小幅修复（少于 30 分钟）	记录模式，并检查是否反复出现
表面问题	风格或偏好问题	记录以供后续参考，不更改流程

错误日志格式

## Error Log Entry

**ID:** ERR-[YYYY]-[MMDD]-[NNN]
**Date:** [date]
**Task:** [what was being done]
**Severity:** [Critical / Major / Minor / Cosmetic]
**Category:** [Category > Subcategory]

### What Happened
[Description of the error and its observable impact]

### Root Cause
[Why this error occurred — the actual underlying reason]

### What Was Tried
1. [First attempt to resolve]
2. [Second attempt if applicable]
3. [Final resolution]

### Resolution
[What ultimately fixed the problem]

### Time Lost
[Estimated time wasted due to this error]

### Prevention
- **New checklist item:** [if applicable]
- **Memory update:** [what was persisted]
- **Guardrail added:** [if applicable]

### Recurrence Check
- [ ] Similar error seen before? [Yes/No — reference previous ID]
- [ ] Guardrail added? [Yes/No]

停止：修复错误前，必须先对其分类并记录。不要跳过日志条目。

---

阶段 3：模式识别

累计 3 个或更多错误后，分析其中的模式：

1. 将相关错误归为失败类别
2. 识别环境触发因素（特定文件类型、框架、模式）
3. 找出导致持续变慢的工作流瓶颈
4. 识别值得强化的成功模式
5. 将反模式与对应的纠正措施关联起来

模式检测决策表

信号	模式	行动
相同错误出现 >2 次	重复失败	创建防护规则（强制）
同一类别出现 >3 次	系统性弱点	为该类别添加预检清单
时间估算持续偏差 >50%	估算盲点	调整估算启发式规则
用户在同一方面进行纠正	知识缺口	深入学习该领域
特定领域的成功率 >90%	优势模式	记录并强化
错误集中在特定框架	框架知识缺口	对该框架开展上下文发现

正向模式强化

当某个模式持续带来成功时，将其记录下来：

## Positive Pattern: [Name]
OBSERVATION: [What was done and why it worked]
EVIDENCE: [Sessions/tasks where this pattern succeeded, with success rate]
REINFORCEMENT: [How to ensure this pattern continues to be applied]

停止：模式识别必须基于证据。切勿根据单次情况创建模式。

---

阶段 4：适应

根据识别出的模式生成并实施改进：

预检清单

创建在高风险操作前运行的清单：

## Pre-Flight: Before Writing [Framework] Code
- [ ] Identify the framework and version (check package.json / composer.json)
- [ ] Identify the routing pattern (pages/ vs app/, file-based vs code-based)
- [ ] Check for existing patterns in the codebase (find similar files)
- [ ] Verify the API surface in documentation (do not assume from memory)
- [ ] Check for project-specific conventions (linter config, type config)

防护规则

## Guardrail: [Operation Type]
BEFORE [specific operation]:
1. [Check 1]
2. [Check 2]
3. [Check 3]
4. [Check 4]

TRIGGERED BY: [keywords or conditions that activate this guardrail]
ADDED BECAUSE: [Error ID that caused this guardrail to be created]
EFFECTIVENESS: [Track whether this guardrail has prevented errors]

适应决策表

错误模式	适应类型	示例
反复出现的理解错误	在工作流中添加澄清步骤	“实现前，用自己的话重述需求”
反复出现的执行错误	添加预检清单	“编写框架代码前，检查版本和路由器类型”
反复出现的流程错误	添加硬性检查点	“提交前的停止标记：你运行测试了吗？”
反复出现的判断错误	添加决策标准表	“何时抽象、何时内联：频率 >3，复杂度 >中等”
反复出现的知识错误	添加上下文发现步骤	“使用 API 前，查阅当前文档，而不是依赖记忆”

停止：所有适应措施在持久化前，都必须根据历史数据进行验证。

---

阶段 5：反馈循环与验证

衡量改进是否真正有效：

1. 将当前错误率与基线（改进前）进行比较
2. 跟踪每条防护规则的预防次数
3. 归档经证明确实能减少错误的改进
4. 撤销无法减少错误或增加额外开销的改进
5. 通过记忆文件在不同会话间共享经验

复盘模板

## Retrospective -- [Period]

### What Went Well
- [Pattern/approach that consistently succeeded]
- [New technique that improved outcomes]

### What Went Poorly
- [Recurring error pattern with frequency]
- [Process gap that caused rework]

### Error Trends
| Category | This Period | Last Period | Trend |
|----------|------------ |-------------|-------|
| Comprehension | 3 | 5 | Improving |
| Execution | 7 | 4 | Worsening -- investigate |
| Process | 1 | 3 | Improving |
| Knowledge | 4 | 4 | Stable |

### Root Cause Analysis (Top 3 Errors)
1. **[Error pattern]** -- Root cause: [analysis] -- Fix: [action]
2. **[Error pattern]** -- Root cause: [analysis] -- Fix: [action]
3. **[Error pattern]** -- Root cause: [analysis] -- Fix: [action]

### Improvement Actions
| Action | Priority | Status | Expected Impact | Actual Impact |
|--------|----------|--------|-----------------|---------------|
| Add pre-flight check for X | High | Done | -30% execution errors | [measured] |
| Update memory with Y pattern | Medium | Done | -20% knowledge errors | [measured] |
| Create guardrail for Z | High | In Progress | Prevent critical error class | [pending] |

### Metrics vs. Targets
| Metric | Target | Actual | Status |
|--------|--------|--------|--------|
| First-attempt success | >80% | 75% | Below target |
| Revision count | <1.5 | 1.8 | Below target |
| Error recurrence | <10% | 8% | On target |

---

记忆文件集成

持久化内容

文件	更新时机	内容
memory/learned-patterns.md	发现新模式或识别出错误模式时	编码约定、框架模式、反模式
memory/user-preferences.md	用户纠正风格、格式或方法时	沟通偏好、代码风格、工具选择
memory/decisions-log.md	做出重要的架构或方法决策时	决策、理由、考虑过的替代方案
memory/project-context.md	发现新的项目上下文时	技术栈、架构、依赖项

更新流程

1. 识别从错误或成功中获得的经验
2. 检查它是否与现有记忆条目冲突
3. 如果冲突：使用新信息和日期更新现有条目
4. 如果是新内容：添加包含上下文、证据和日期的条目
5. 删除已不再有效的条目（技术已变更、项目已演进）

切勿将直觉作为模式持久化。证据要求：至少出现 2 次。

---

持续改进循环

Execute Tasks -> Collect Metrics -> Analyze Errors -> Identify Patterns
      ^                                                       |
      |                                                       v
      +-- Persist to Memory <-- Validate Impact <-- Implement Improvements
                                      |
                                      +-- Did not work? -> Revert, try different approach

---

反模式 / 常见错误

不要做什么	为什么会失败	应该怎么做
同一错误出现 3 次，却没有设置防护措施	错误会不断重现，且没有任何预防措施	第 2 次出现后创建防护措施
追踪指标却不采取行动	测量作秀——付出努力却没有成果	每项指标都必须设置行动阈值
因单次错误而过度纠正	一次糟糕的体验不足以成为永远避用某个工具的理由	至少出现 2 次后再形成模式
一视同仁地对待所有错误	在表面问题上浪费精力	按发生频率 × 影响程度排序
没有证据就更新记忆	错误模式会污染未来会话	至少需要 2 个示例才能写入持久记忆
创建过多清单，导致清单本身成为负担	清单疲劳会让人干脆全部跳过	每份清单最多 5 项，并废弃不再使用的清单
只归咎于外部因素	错过改进内部流程的机会	始终审视你自己本可以在哪些方面做得不同
跳过改进效果的验证	无法判断改进是否真的有效	比较改进前后的错误率
保留过时的模式	过时的建议会导致新错误	定期审查并精简记忆
从不进行回顾	失去全局视角，只关注个别错误	每完成 10 项任务后安排一次回顾

---

防止自我合理化

想法	事实
“这次错误只是偶然”	仍然要记录。如果再次发生，你就有了数据。
“收集指标会拖慢我”	不收集指标就意味着会重复犯同样的错误。
“这个任务用这份清单小题大做了”	这份清单存在的原因是之前有类似任务失败过。请使用它。
“我会记住这个教训”	你不会。各个会话彼此独立。请将其写入持久记忆。
“这个错误不是我的责任”	无论原因在外部还是内部，都要记录这种模式。预防是你的职责。
“回顾是浪费时间”	不做回顾，就无法发现趋势。请进行回顾。
“我的成功率已经够好了”	“够好”会导致停滞。目标是持续改进。

不要跳过错误记录。不要跳过指标收集。这些都是必须执行的。

---

集成点

技能	关系
self-learning	提供项目背景，避免知识错误
resilient-execution	失败的重试会成为错误分析的依据
circuit-breaker	停滞事件是重要的错误信号
verification-before-completion	验证失败会触发错误记录
planning	改进措施有助于提升未来计划的质量
code-review	审查结果会成为模式识别的依据

---

具体示例

根据错误模式创建防护措施

Error: ERR-2026-0212-003 — Dropped production table during migration
Error: ERR-2026-0301-007 — Applied migration without rollback plan

Pattern: Database operations without safety checks (2 occurrences)

Guardrail Created:
## Guardrail: Database Operations
BEFORE any database migration or schema change:
1. Check if there is an existing migration framework
2. Verify the current schema state
3. Create a rollback plan
4. Test migration on a copy first

TRIGGERED BY: any task involving database, schema, migration, model
ADDED BECAUSE: ERR-2026-0212-003, ERR-2026-0301-007
EFFECTIVENESS: 0 errors in 5 subsequent database tasks

积极模式的文档记录

## Positive Pattern: Context Discovery First
OBSERVATION: Tasks where project context was gathered first had
a 92% first-attempt success rate vs. 64% without.
EVIDENCE: Sessions 2026-02-01 through 2026-03-15 (47 tasks)
REINFORCEMENT: Always run context discovery before implementation.
Minimum: check package.json, read existing code in same domain,
identify conventions.

---

技能类型

RIGID — 必须始终遵循错误追踪、分类和改进周期。每个重复出现的错误（至少 2 次）都必须采取具体的预防措施。记忆文件只能根据有证据支持的模式进行更新。每个会话都必须收集指标并记录错误。不要跳过回顾。