aif-evolve

Evolve - 技能自我改进

分析项目上下文、补丁和代码库，以改进现有技能。每次运行都会让 AI Factory 变得更智能。

核心理念

patches (past mistakes) + project context + codebase patterns
    ↓
analyze recurring problems, tech-specific pitfalls, project conventions
    ↓
enhance skills with project-specific rules, guards, and patterns

补丁处理策略

采用双层学习模型：

1. 原始补丁（paths.patches，默认值：.ai-factory/patches/*.md）是源材料。
2. 技能上下文规则（.ai-factory/skill-context/*）是精简、可复用的输出。

适用于所有工作流技能的策略：

• /aif-evolve 是主要的原始补丁分析器。它使用游标增量处理补丁。
• /aif-implement、/aif-fix 和 /aif-improve 应优先使用技能上下文；仅在必要时才将原始补丁用作备用上下文。
• 仅在需要时强制执行完整的重新分析（例如，重置游标并重新运行 evolve）。

重要：绝不要直接编辑内置技能

绝不要修改内置 aif-* 技能目录（skills/aif-*/）中的任何文件。 这些目录中的所有文件都由 ai-factory 管理，更新时会被覆盖；直接编辑的内容都会丢失。

始终将项目专属规则写入技能上下文：

.ai-factory/skill-context/<skill-name>/SKILL.md

这是改进内置技能的唯一正确目标，不得例外。

工作流

步骤 0：确定目标并加载上下文

步骤 0.1：确定目标

根据 $ARGUMENTS 规范化技能名称：

用户输入	解析后的技能名称
plan	aif-plan
aif-plan	aif-plan
/aif-plan	aif-plan
my-custom-skill	my-custom-skill

规则：首先移除参数开头的所有 /。然后，如果参数不以 aif- 开头，且存在名为 aif-<argument> 的技能，则使用 aif-<argument>。否则按原样使用。

**解析技能名称后：**验证解析后的技能确实存在 （检查 {{skills_dir}}/<resolved-name>/SKILL.md 或 skills/<resolved-name>/SKILL.md）。 如果未找到该技能 → 向用户报告错误并停止： "未找到技能 ''。不带参数运行 /aif-evolve 可改进 所有技能，也可指定有效的技能名称。"

根据 $ARGUMENTS 确定要改进的技能：

• 如果 $ARGUMENTS 包含特定技能名称 → 仅改进该技能
• 如果 $ARGUMENTS 为 "all" 或为空 → 改进所有已安装的技能

步骤 0.2：加载上下文

首先： 如果 .ai-factory/config.yaml 存在，读取它以确定：

• 路径： paths.description、paths.architecture、paths.rules_file、paths.rules、paths.patches 和 paths.evolutions
• 语言： 用于提示词的 language.ui，以及用于生成报告的 language.artifacts
• 规则层级： rules.base，以及任何命名的 rules.<area> 条目

如果 config.yaml 不存在，则使用默认值：

• DESCRIPTION.md：.ai-factory/DESCRIPTION.md
• ARCHITECTURE.md：.ai-factory/ARCHITECTURE.md
• RULES.md：.ai-factory/RULES.md
• rules/：.ai-factory/rules/
• patches/：.ai-factory/patches/
• evolutions/：.ai-factory/evolutions/
• 语言：en（英语）

注意： 在当前架构中，.ai-factory/skill-context/ 仍是固定的内部 AI Factory 路径。补丁和演进日志的位置可通过 paths.patches 和 paths.evolutions 配置。

然后： 读取 .ai-factory/DESCRIPTION.md（使用配置中的路径），了解：

• 技术栈
• 架构
• 约定

还要读取 .ai-factory/ARCHITECTURE.md（使用配置中的路径），并在存在时读取已配置的规则层级。这些上下文有助于分析约定和检测缺口，但不会改变产物归属。

读取目标技能的 skill-context 文件：

• 如果要演进特定技能（例如 /aif-evolve plan）→ 仅读取：
  1. .ai-factory/skill-context/aif-plan/SKILL.md（目标技能的上下文）
  2. .ai-factory/skill-context/aif-evolve/SKILL.md（如果存在，且目标技能本身不是 aif-evolve，则读取 evolve 自身的上下文）
• 如果要演进所有技能（/aif-evolve 或 /aif-evolve all）→ 读取所有上下文文件： Glob: .ai-factory/skill-context/*/SKILL.md（其中已包含 evolve 自身的上下文——不要单独读取）

这些文件包含之前积累的、特定于项目的内置技能规则。 请将它们保留在记忆中——它们会影响步骤 5 中的缺口分析。

Skill-context 规则是项目级覆盖规则——当它们与目标技能的基础 SKILL.md 冲突时，以 skill-context 为准（原则与嵌套 CLAUDE.md 文件相同）。

如何应用 evolve 自身的 skill-context 规则（aif-evolve）：

• 将它们视为此技能一般说明的项目级覆盖规则
• 当 skill-context 规则与本 SKILL.md 中的一般规则冲突时， 以 skill-context 规则为准（更具体的上下文优先——原则与嵌套 CLAUDE.md 文件相同）
• 如果不存在冲突，则两者都应用：SKILL.md 中的一般规则 + skill-context 中的项目规则
• 即使 skill-context 规则看起来与此技能的默认规则相矛盾，也不要忽略它们—— 这些规则之所以存在，是因为项目经验表明默认规则并不足够
• 重要： skill-context 规则适用于此技能的所有输出——包括演进 报告、改进建议、skill-context 文件编辑和过时规则分析。如果某条 skill-context 规则规定“evolve 必须优先考虑 X”或“报告必须包含 Y”，你就必须遵守。 忽略 skill-context 规则生成演进输出属于错误。

强制要求： 生成任何产物后，都要根据所有 skill-context 规则进行核验。 如果违反了任何规则，必须在向用户展示前修正输出。

步骤 1：收集信息

1.1：增量读取补丁（基于游标）

Glob: <resolved patches dir>/*.md

游标文件：

<resolved evolutions dir>/patch-cursor.json

建议的结构：

{
  "last_processed_patch": "YYYY-MM-DD-HH.mm.md",
  "updated_at": "YYYY-MM-DD HH:mm"
}

处理规则：

1. 使用 Glob 查找补丁文件，并按文件名升序排序（时间戳格式便于按字典序排序）。
2. 如果游标文件不存在 → 首次运行：读取所有补丁。
3. 如果游标文件存在且其引用的补丁仍然存在 → 只读取文件名 > last_processed_patch 的补丁。
4. 如果游标文件存在，但其引用的补丁已丢失（已删除/重命名） → 发出 WARN [evolve] 并执行完整重新扫描。
5. 如果没有保存的基线（快照/哈希清单），则无法可靠检测游标之前补丁的历史编辑/删除。默认情况下，不要发出此警告。
6. 只有在存在可靠基线且实际检测到偏差时，才针对历史偏差发出 WARN [evolve]。
7. 完整重新扫描流程：删除 <resolved evolutions dir>/patch-cursor.json，然后再次运行 /aif-evolve。
8. 不要在步骤 1.1 中推进游标。 只有在步骤 7.3 成功应用/写入日志后，才更新游标。

重叠窗口（防漏保护）：

LLM 可能会在单次处理中漏掉预防要点。为降低增量运行时“永久跳过”补丁的风险：

9. 以增量模式运行时（游标存在且其引用的补丁仍然存在），还要读取按文件名排序后的最新 5 个补丁（列表末尾的 5 个），然后按文件名去重。
10. 在自己的记录中分别跟踪以下内容：

• “新补丁” = 文件名 > last_processed_patch 的补丁
• “重叠补丁” = 末尾 5 个补丁
• “已处理补丁” = 新补丁与重叠补丁的并集

11. 步骤 7.3 中的游标更新必须仅基于“新补丁”（如果只处理了重叠补丁，绝不能推进游标）。

读取每个补丁。对每个补丁，提取：

• 问题类别（空值检查、异步、验证、类型、API、DB 等）
• 根因模式（出现了哪些类别的错误）
• 预防要点——“预防/解决方案”部分中的每条独立、可执行规则。 单个补丁通常包含多个针对不同技能的独立预防要点。 必须分别提取每一条，并注明其目标技能。不要将一个补丁视为一个整体。
• 标签

| # | Patch | Prevention Point (specific action) | Target Skill(s) |
|---|-------|------------------------------------|-----------------|
| 1 | <patch-file> | <concrete action to enforce> | <skill-1> |
| 2 | <patch-file> | <different action from same patch> | <skill-1>, <skill-2> |
| 3 | <other-patch> | <action> | <skill-3> |

重要： 一个包含 5 条预防要点的补丁应生成 5 行，而不是 1 行。 如果某条预防要点针对 2 个技能，则只列出一次，但要同时列出这两个技能 — 并且在步骤 5 中必须分别检查每个技能。

增量运行时，此注册表反映本次运行中已处理的补丁集（新补丁 + 重叠补丁）。需要完整回溯历史时，请执行完整重新扫描。

1.2：汇总模式

按标签和类别对补丁分组。识别：

• 反复出现的问题——同一标签出现 3 次或更多？这说明存在系统性问题
• 特定技术的陷阱——与技术栈相关的问题（例如，React 重渲染、Laravel N+1）
• 缺失的防护——哪些检查/模式本可以预防这些错误

1.3：读取代码库约定

扫描项目中的以下模式：

• Linter 配置（.eslintrc、phpstan.neon、ruff.toml 等）
• 现有的测试模式（测试文件结构、使用的断言）
• 错误处理模式（try/catch 风格、错误类型）
• 日志记录模式（使用的 logger、格式、级别）
• 导入约定、文件结构

改进特定技能时，将约定扫描重点放在与该技能相关的方面 （例如，对于 /aif-plan——关注文件结构和命名；对于 /aif-fix——关注错误处理和测试）。

第 2 步：读取目标技能

只读取目标技能的基础 SKILL.md 文件，不要读取所有技能。

• 如果演进特定技能（例如 /aif-evolve plan）→ 只读取该技能： Read: {{skills_dir}}/aif-plan/SKILL.md（如果未安装，则为 skills/aif-plan/SKILL.md）
• 如果演进所有技能（/aif-evolve 或 /aif-evolve all）→ 全部读取： Glob: {{skills_dir}}/*/SKILL.md（如果未安装，则为 Glob: skills/*/SKILL.md）

将已加载的 SKILL.md 内容保留在内存中——第 3 步需要用它进行比较（不要重新读取）。

第 3 步：检查 Skill-Context 中的过时规则

适用范围： 对每个拥有 skill-context 文件的目标 aif-* 技能运行此步骤。

针对 .ai-factory/skill-context/<skill-name>/SKILL.md 中的每条规则：

范围限制： 第 3 步只能修改或移除 skill-context 文件。 绝不能提议编辑、删除或还原基础 skills/aif-*/ 文件。 即使基础文件包含错误或规则不完整，这也不属于 evolve 的处理范围。

1. 使用第 2 步中已加载的基础 SKILL.md（不要重新读取文件）。

2. 将每条 skill-context 规则与基础 SKILL.md 的内容进行比较：

   情况 A——基础文件已完全涵盖 skill-context 规则（等效或范围更广）： 基础 SKILL.md 现在包含一条与 skill-context 规则等效或更完整的规则。 包括：

   • 完全等效——规则和内容相同
   • 基础文件范围更广——基础文件包含 skill-context 的全部内容，外加更多内容 （例如，skill-context 包含 Wave 1+3，基础文件现在包含 Wave 1+2+3） → 不要自动移除。暂时不要询问用户。 → 在第 4 步的报告中收集此项——列出两条规则，并标记为 “已被基础文件完全涵盖——建议从 skill-context 中移除”。 注意：如果用户选择保留 skill-context 规则，这是可行的—— skill-context 的优先级高于基础文件，因此保留它可以确保始终应用完整且正确的版本。

   情况 B——基础 SKILL.md 中存在相互矛盾的规则： 基础技能现在有一条与 skill-context 规则直接矛盾的规则。 → 不要自动移除。暂时不要询问用户。 → 在第 4 步的报告中收集此冲突——列出两条规则，并标记为“存在冲突——需要用户决定”。

   情况 C——部分重叠（任一方向）： 基础 SKILL.md 与 skill-context 规则存在重叠，但两者都未完全涵盖对方。 包括：

   • 基础文件涵盖 skill-context 的部分内容，但 skill-context 也有独有内容
   • skill-context 涵盖基础文件的部分内容，但基础文件也有独有内容 （例如，skill-context 包含 A→B→C，基础文件包含 A→C→D——双方都有独有内容） → 不要自动缩小规则范围。分析各部分是否相互依赖 （顺序、前置条件、数据流）。 → 在第 4 步的报告中收集此重叠——列出两条规则、分析结果，并标记为“部分重叠——需要用户决定”。 优先级警告： 对于同一主题，skill-context 的优先级高于基础文件。 如果用户原样保留 skill-context，基础文件中独有的部分很可能会丢失 （AI 会使用 skill-context 版本，而忽略基础文件中同一规则的版本）。 始终在选项说明中解释这一后果。

   情况 D——无重叠： 该规则仍是项目上下文独有的规则。 → 保持原样，无需采取操作。

第 4 步：展示并处理过时规则

如果第 3 步未发现情况 A/B/C 中的规则，则跳过此步骤。

使用过时规则报告格式展示所有过时规则的发现结果 （情况 A/B/C 部分，包含基础文件与 skill-context 的对比）。

重要：此处的所有决定只影响 skill-context 文件。 绝不要提议编辑、删除或还原基础 skills/aif-*/ 文件—— 它们不属于 evolve 的处理范围。

过时规则报告格式

针对每条过时规则，展示：

/aif-plan — 完全覆盖：[规则名称]

• 基础 SKILL.md 中的内容：[基础规则文本]
• 技能上下文中的内容：[项目规则文本]
• **需要做出的决定：**保留在技能上下文中（优先级高于基础规则 — 确保始终应用完整版本）/ 从技能上下文中移除（信任基础规则）/ 重写技能上下文规则

/aif-plan — 存在冲突：[规则名称]

• 基础 SKILL.md 中的内容：[基础规则文本]
• 技能上下文中的内容：[项目规则文本]
• **需要做出的决定：**保留技能上下文规则（优先级更高 — 将忽略基础版本）/ 移除技能上下文规则（信任基础规则）/ 重写技能上下文规则

/aif-fix — 部分重叠：[规则名称]

• 基础 SKILL.md 中的内容：[基础规则文本]
• 技能上下文中的内容：[项目规则文本]
• 分析：[说明重叠部分，以及各部分是独立的还是有先后顺序]
• **需要做出的决定：**重写技能上下文，使其包含双方独有的部分（当各部分有先后顺序时推荐）/ 保持技能上下文不变（警告：基础规则独有的部分将丢失 — 技能上下文优先级更高）/ 缩小技能上下文的范围，仅保留未覆盖的部分 / 从技能上下文中移除（信任基础规则 — 技能上下文独有的部分将丢失）

收集决定

使用 AskUserQuestion 收集过时规则的处理决定。每次 AskUserQuestion 调用最多分批处理 3 项：

• 呈现第一批（最多 3 项过时规则）→ AskUserQuestion
• 获取回答 → 应用决定
• 如果仍有过时规则 → 呈现下一批 → AskUserQuestion
• 重复以上步骤，直到解决所有过时规则

**在收集并应用所有过时规则的处理决定之前，不要继续执行步骤 5。**这将确定用于差距分析的实际技能上下文状态。

第 5 步：分析差距

分析差距前： 重新读取第 4 步中已修改的目标技能的技能上下文文件（删除或改写过时规则）。不要使用第 0.2 步加载的版本——该版本在第 4 步修改后已过时。

对于每项技能，都要考虑基础 SKILL.md 和其当前技能上下文文件（已应用第 4 步的过时规则处理决定）。

只有当两个来源都未涵盖某项内容时，才存在差距。

根据收集到的信息，找出每项技能的缺失内容：

5.1：由补丁驱动的差距（穷尽所有预防点）

关键：独立检查每个预防点与每项目标技能的组合。

遍历第 1.1 步建立的预防点登记表。对于每一行：

1. 对该行列出的每项目标技能：
   • 检查基础 SKILL.md 是否已涵盖此特定预防措施
   • 检查技能上下文中是否已有涵盖此特定预防措施的规则
2. 只有当规则针对所述的具体操作时，该技能才算“已涵盖”此预防点；仅仅在 Source 字段中出现相同的补丁文件名并不算。
3. 将未涵盖的（预防点，技能）组合标记为差距 → 作为第 6 步的输入。

常见陷阱——引用来源 ≠ 完全涵盖： 在技能上下文规则中找到 Source: <patch-filename>，只表示有一条规则源自该补丁。它不表示该补丁的所有预防点都已涵盖。一个包含 5 个预防点的补丁，可能只涵盖了其中 1 个。务必逐一核对现有规则的内容是否涵盖每个预防点。

验证： 完成登记表扫描后，统计预防点总数、已涵盖数和未涵盖数。若未涵盖数 > 0——这些就是第 6 步要处理的差距。

注意：在增量模式下，统计数据仅代表本次运行处理的补丁集。如需完整历史统计，请运行完整重扫。

5.2：技术栈差距

将项目技术栈与技能说明进行比较：

• 技能引用通用模式，但项目使用特定框架？→ 添加针对该框架的指导
• 项目使用 TypeScript，但技能展示的是 JS 示例？→ 更新示例
• 项目使用特定 ORM（Prisma、Eloquent）？→ 添加针对该 ORM 的模式

5.3：约定差距

将项目约定与技能说明进行比较：

• 项目有特定的错误处理模式？→ 技能应强制遵循该模式
• 项目使用特定日志记录器？→ 技能应引用该日志记录器
• 项目有特定文件结构？→ 技能应遵循该结构

第 6 步：生成改进项

为发现的每项差距创建具体改进项：

改进项质量规则：

• 一个预防点 = 一条规则。 单个补丁可能包含多个独立的预防项。每项都应单独成为一条规则——不要将它们合并成一条含糊的总结。
• 保留补丁中的具体格式和模式。 如果补丁指定了精确格式、语法或模板，规则就必须原样包含。不要将具体内容改写成含糊描述。
• 每项改进都必须可追溯到某个补丁、约定或技术栈事实
• 不提供通用建议——仅提供针对项目的增强内容
• 改进项必须精简且聚焦——不要重写整个技能
• 保留现有技能结构——只添加，不替换

第 7 步：展示并应用

7.1：向用户展示改进项

每项改进都必须明确注明目标文件路径。 使用以下目标标签：

• skill-context → .ai-factory/skill-context/<skill-name>/SKILL.md
• SKILL.md → 直接编辑技能自身的 SKILL.md（仅适用于自定义技能或非 AIF 技能）
• 嵌套文件 → 如果技能目录包含其他文件（例如 templates/、checklists/），请注明技能目录内的确切相对路径

格式：

## Skill Evolution Report

Based on:
- X patches analyzed
- Y recurring patterns found
- Z tech-stack specific insights

### Proposed Improvements

#### /aif-fix (N rules)
**Target:** `.ai-factory/skill-context/aif-fix/SKILL.md`

1. **Add null-check guard**
   - **Source:** patch-2026-02-10.md, patch-2026-02-12.md (5 patches involved null references)
   - **Why:** Recurring null-reference errors on optional DB relations
   - **Rule:** "Check for optional/nullable fields before accessing nested properties"

2. **Add async/await pattern**
   - **Source:** patch-2026-02-11.md (3 patches involved unhandled promises)
   - **Why:** Unhandled promise rejections in API layer
   - **Rule:** "Always use try/catch with async/await"

#### /aif-implement (N rules)
**Target:** `.ai-factory/skill-context/aif-implement/SKILL.md`

1. **Add Prisma-specific warning**
   - **Source:** patch-2026-02-13.md (2 patches from incorrect Prisma queries)
   - **Why:** Silent data loss from wrong Prisma query methods
   - **Rule:** "Log all Prisma queries in DEBUG mode"

#### /my-custom-skill (N rules)
**Target:** `skills/my-custom-skill/SKILL.md` (direct edit — custom skill)

1. **Add pattern**
   - **Source:** codebase convention
   - **Why:** Missing guard in Step 2
   - **Rule:** "..."

展示完整报告后，使用 AskUserQuestion 收集决定： 对于改进，请选择：

• 是，应用所有改进
• 让我选择
• 否，仅保存报告（不应用任何更改）

根据选择：

• “是，应用所有改进” → 继续执行 7.2，并应用所有改进
• “让我选择” → 每次 AskUserQuestion 调用最多分批展示 4 项改进 （采用与第 4 步过时规则相同的方式）。每项改进的选项：应用 / 跳过。持续进行，直到所有改进都得到处理。 然后继续执行 7.2，仅应用已批准的改进。
• “否，仅保存报告” → 不应用任何更改，停止

在用户作出回答前，不要应用任何更改。

7.2：应用已批准的改进

对于每项已批准的改进，确定目标：

如果该技能是内置的 aif-* 技能（其 SKILL.md 位于软件包的 skills/ 目录中）：

1. 如有需要，创建目录： mkdir -p .ai-factory/skill-context/
2. 如果 .ai-factory/skill-context/<skill-name>/SKILL.md 不存在 — 使用标头模板创建该文件
3. 如果文件已存在 — 先读取文件，然后针对每项改进决定：
   • 更新现有规则 — 当同一主题已有规则时（例如，已有一条来自 3 个补丁的空值检查规则，又收到 5 个新的空值检查补丁 → 强化现有规则，更新其 Source 列表，并根据新证据调整严重程度或措辞）
   • 添加新规则 — 当现有规则未涵盖该主题时
   • 合并规则 — 当多条范围较窄的规则可以合并为一条范围更广的规则时 （例如，三条分别“检查字段 X”的规则 → 合并为一条“始终对可选的 DB 关联进行空值检查”的规则）
4. 更新标头中的 > Last updated: 和 > Based on: 行
5. 绝不要编辑技能 skills/aif-*/ 目录中的任何文件 — 其中的所有文件均由 ai-factory 管理，更新时将被覆盖。所有改进只能写入 skill-context。
6. 应用所有更改（包括删除过时规则）后，如果 skill-context 文件中已没有任何规则 （只剩标头），则删除该文件及其目录： rm .ai-factory/skill-context/<skill-name>/SKILL.md rmdir .ai-factory/skill-context/<skill-name>（仅在目录为空时）
7. 对于仅受过时规则删除（第 4 步）影响、但未收到新改进的 skill-context 文件，更新其 > Based on: 计数和 > Last updated:（第 4 项中已更新的文件除外）。

如果该技能是自定义/项目技能（不是 aif-*）：

1. 直接编辑技能的 SKILL.md（维持现有行为，不变）

上下文文件模板：

重要：所有 skill-context 文件都必须使用英语编写，无论用户使用何种语言，或补丁/RULES.md 使用何种语言。skill-context 规则由 AI Agent 使用；使用英语可确保所有技能和会话中的解释保持一致。

# Project Rules for /<skill-name>

> Auto-generated by `/aif-evolve`. Do not edit manually.
> Last updated: YYYY-MM-DD HH:mm
> Based on: N analyzed patches

## Rules

### [Rule Name]
**Source**: [patch filenames or "codebase convention"]
**Rule**: [Specific, actionable instruction in English]

7.3：保存演进日志

创建 <resolved evolutions dir>/YYYY-MM-DD-HH.mm.md：

mkdir -p <resolved evolutions dir>

保存演进日志后，更新游标状态：

定义：

• “已处理的新补丁” = 文件名 > last_processed_patch 的补丁。
  • 如果游标不存在（首次运行）：“新补丁”是完整的补丁列表。
  • 重叠补丁不计入“新补丁”。
• “已应用改进” = 至少有一项已批准的改进写入了磁盘 （已更新 skill-context 和/或已编辑自定义技能 SKILL.md）。

游标更新规则：

1. 如果没有处理任何新补丁，则保持游标不变。
2. 如果处理了新补丁：
   • 如果已应用改进：将游标前移至最新的“新补丁”文件名。
   • 如果未应用任何改进（例如用户选择了“否，仅保存报告”或跳过了所有改进）：
     • 默认不要前移游标。
     • 询问用户是否仍要前移游标。
       • 建议：保持游标不变，以便再次运行（LLM 可能会漏掉预防要点）。
       • 如果用户明确选择仍要前移，则按常规写入游标。
3. 如果在更改最终确定前执行失败，则不要前移游标。

# Evolution: YYYY-MM-DD HH:mm

## Intelligence Summary
- Patches analyzed: X
- Recurring patterns: [list]
- Tech stack: [from DESCRIPTION.md]

## Improvements Applied

### [skill-name] → skill-context
- [change description] ← driven by patches: [patch filenames]
  **File:** `.ai-factory/skill-context/[skill-name]/SKILL.md`

### [skill-name] → SKILL.md (custom skill)
- [change description] ← driven by: [tech stack / convention]
  **File:** `skills/[skill-name]/SKILL.md`

## Patterns Identified
- [pattern]: [frequency] occurrences
- [pattern]: [frequency] occurrences

步骤 8：建议后续操作

## Evolution Complete

Skills improved: X
Improvements applied: Y

### Recommendations

1. **Run `/aif-review`** on recent code to verify improvements
2. **Next evolution** — run `/aif-evolve` again after 5-10 more fixes
3. **Consider new skill** — if pattern X keeps recurring, create a dedicated skill:
   `/aif-skill-generator <skill-name>`

清理上下文

文件归属

• 主要归属：.ai-factory/skill-context/*、<resolved evolutions dir>/*.md 和 <resolved evolutions dir>/patch-cursor.json。
• 此处仅部分使用配置：config.yaml 用于解析描述、规则、补丁和演进日志路径，但 skill-context 仍是固定的 AI Factory 内部路径。
• 只读上下文：路线图、规则、研究和计划制品，除非用户明确提出其他要求。

完成演进后，建议使用 /clear 或 /compact——补丁分析和技能处理后，上下文会很庞大。

规则

1. 可追溯 — 每项改进都必须关联到补丁、惯例或技术事实
2. 最小化 — 将规则添加到 skill-context，不要重写基础技能
3. 可逆 — 应用更改前须经用户批准
4. 累积 — 每次演进都基于先前的演进
5. 杜绝臆造 — 只建议有证据支持的改进
6. 保留结构 — 不要更改基础技能工作流，只通过 skill-context 丰富内容
7. 仅限 Skill-context — 所有针对内置 aif-* 技能的改进都必须写入 .ai-factory/skill-context/，绝不能写入 skills/aif-*/。绝不要编辑 skills/aif-*/ 中的任何文件——这些文件会在更新时被覆盖。没有例外。
8. 仅限英文 — 所有 skill-context 文件都必须使用英文编写，无论用户使用何种语言
9. 不要提供泛泛建议 — “编写整洁的代码”不算改进；只提出针对项目的增强内容
10. 不创建新技能 — 改为建议使用 /aif-skill-generator
11. 不得损失覆盖范围 — 除非规则已过时（步骤 3-4），否则不要删除规则。 步骤 7 中允许合并规则（将范围较窄的规则合并为范围较广的规则），前提是合并后的规则 保留所有防范要点。
12. 仅限已安装技能 — 不要演进项目中未安装的技能
13. 归属边界 — 此命令管理 <resolved evolutions dir>/*.md、<resolved evolutions dir>/patch-cursor.json 和 .ai-factory/skill-context/*；路线图、规则、研究和计划制品均视为只读上下文，除非用户明确提出要求

示例

/aif-evolve fix

→ Found 6/10 patches tagged #null-check
→ Improvement for /aif-fix (2 rules):
  Target: .ai-factory/skill-context/aif-fix/SKILL.md
  1. "PRIORITY CHECK: Look for optional/nullable fields accessed
      without null guards. This is the #1 source of bugs in this project."
  2. "When fixing nullable relation errors, check ALL usages of that
      relation in the same file — same bug often repeats nearby."