AI Coding 的最大问题不是写错代码，而是反复犯同一个错

一个 AI Coding 用户的日常

你用 AI 写代码，一定见过这样的循环：

复制代码

 AI 写了购物车结算功能 → 上线
 AI 没处理商品下架的边界情况 → bug → 让 AI 修了
 AI 写了权限管理功能 → 上线
 AI 没处理角色被删的边界情况 → bug → 让 AI 修了
 AI 写了通知发送功能 → 上线
 AI 没处理模板被删的边界情况 → bug → 让 AI 修了

同一个坑，AI 踩了三次。

问题不是"AI 不够聪明"，而是：AI 没有从自己的错误中学习。 每次对话都是全新的，它不知道上次犯过什么错，更不知道这个项目有哪些系统性弱点。

如果有一个机制，让 AI 能"记住"自己犯过的错，并且下次自动规避呢？

核心思路：让 git 历史成为 AI 的学习素材

AI 写的每一行代码、每一次修复，都留在 git 历史里。这些历史里藏着 AI 的行为模式------只是没人去提取。

本体系做的事：用 AI 分析 git 历史 → 发现 AI 自己的犯错模式 → 把模式变成规则喂回给 AI → AI 下次自动规避。

bash 复制代码

 AI 写代码 → 产生 feat/fix 提交
                │
                ↓
          AI 分析提交历史，按根因聚类
                │
                ↓
          "这个项目的 AI 总是忘记处理关联数据被删的情况"
                │
                ↓
          生成规则，写入 AI 的上下文配置
                │
                ↓
          AI 下次写代码时，规则就在上下文里
          → 同类错误减少

整个过程中，人只做一件事：确认 AI 产出的规则是否合理。分析、聚类、生成规则，全部由 AI 完成。

这套体系嵌在哪里：AI Coding 完整工作流

反馈回路不是孤立的，它嵌入在 AI Coding 的完整工作流中：

复制代码

 ┌─────────────────────────────────────────────────────────────┐
 │  AI Coding 工作流                                            │
 │                                                              │
 │  Superpowers → Spec Kit → 实 现 → 测 试 → 交付              │
 │  （建立能力）  （定义需求）  （写代码）（TDD） （提交）        │
 │      ↑                                        │              │
 │      │              Slice 编号贯穿             │              │
 │      │              ←─────────────────────→   │              │
 │      │                                        ↓              │
 │      │                              git 提交历史              │
 │      │                                        │              │
 │      │                              AI 分析 + 聚类            │
 │      │                                        │              │
 │      └──────── 回流（更新规则/模板/清单）←─────┘              │
 └─────────────────────────────────────────────────────────────┘

Superpowers：每次对话开始时建立 AI 的能力地图------知道项目里有哪些工具、技能、约定。这是 AI 有效工作的前提。

Spec Kit ：用 /speckit.specify 定义需求 → /speckit.plan 出技术方案 → /speckit.tasks 拆成任务 → /speckit.implement 执行。每个功能分配 Slice 编号，贯穿从需求到代码到 bug 修复的全链路。

反馈回路是这套工作流的第四层：Superpowers 打底、Spec Kit 定义需求、TDD 保障质量、本体系负责"持续学习不再犯"。四层叠加，AI Coding 从"每次从零开始"变成"越做越精准"。

第一步：让 AI 自己写结构化的提交信息

AI 分析 diff + 上下文，自动生成结构化提交信息。

AI 生成的 feat 提交长这样

bash 复制代码

feat(cart): 购物车结算 --- 新增价格计算服务 + 库存预占

将价格计算从订单模块拆分到独立的计算服务，避免下单高峰时
订单服务成为瓶颈。库存预占从同步改为异步，提升结算响应速度。

变更文件（5 文件，+380/-95）：
- services/price_calc_service.py（新增）
- services/stock_reserve.py（新增）
- routes/cart.py
- models/cart_item.py
- tests/（3 个新增）

Slice: 003-order-system#12-cart-settlement
Author: ai+human

AI 生成的 fix 提交长这样

makefile 复制代码

fix(cart): 商品下架后清理购物车中的无效 SKU

购物车结算时遍历商品列表，未检查对应商品是否已下架。
商品下架后购物车仍保留该条目，导致结算时查到不存在的 SKU
报错。

Root-Cause: boundary-incomplete
Slice: 003-order-system#12-cart-settlement
Author: ai+human

人只需要 review 提交信息。 AI 基于以下信息自动生成：

diff 内容（改了什么）
之前的提交历史（上下文）
spec 文档（Slice 编号来源）
8 类 Root-Cause 白名单（分类依据）

8 类 Root-Cause：AI 最容易犯的错

不是随便分的。这是从大量 AI 编码实践中归纳出的高频犯错模式：

lua 复制代码

 AI 的高频弱点（前 6 类，设计层缺失）
 ├── boundary-incomplete    "没想过数据会消失" --- AI 默认假设输入合法
 ├── happy-path-only        "只写了正常路径" --- AI 不主动处理异常
 ├── missing-validation     "改了 A 不管 B" --- AI 局部处理，缺全局约束
 ├── concurrent-unsafe      "没考虑并发" --- AI 几乎不主动处理并发
 ├── state-machine-gap      "漏了中间状态" --- AI 容易遗漏状态转移
 └── permission-missing     "没查归属" --- AI 专注功能，忽略权限

 AI 的低频问题（后 2 类，实现层）
 ├── logic-error            逻辑写错了（AI 的强项，反而少见）
 └── dependency-breaking    依赖变更连锁修复

注意看前 6 类：每一类都是"AI 在设计阶段该想到但没想到的"。这不是偶然------AI 生成代码时天然偏向 happy path，不主动考虑边界、异常、并发、权限。知道这一点，就有针对性地补规则。

第二步：AI 分析自己的提交历史

有了结构化的提交信息，就可以让 AI 做聚类分析。整个过程自动完成，人只看结果。

fix 信号：AI 在哪些地方反复犯错

matlab 复制代码

 分析最近 50 条 fix 提交：

 boundary-incomplete ×12，分布在 5 个功能切片
   → 不是某一次的偶然
   → 是这个项目的 AI 系统性地"忘了处理关联数据被删"
   → 生成规则："所有外键/关联查询必须处理目标记录不存在的情况"

 permission-missing ×5，出现在切片 07、08、09、12、15
   → 不是某个功能的问题
   → 是架构上缺了统一的权限拦截
   → 生成规则："所有 API 端点必须校验资源归属"

feat 信号：AI 把功能拆得好不好

AI 写功能时，拆分策略直接影响代码质量：

bash 复制代码

 Slice #12: 1 个 feat（+380/-95 行，5 文件），0 个 fix
   → 好切片：粒度合适，边界清晰
   → 记入正例库，AI 下次遇到类似功能参照这个粒度拆

 Slice #08: 1 个 feat（+1100/-60 行，14 文件），4 个 fix
   → 坏切片：太大、太散、spec 有坑
   → 记入反例库，AI 下次知道"这类功能不要一口气写完"

feat 信号回答的是"AI 怎么拆功能效果最好"，fix 信号回答的是"AI 在哪类问题上反复翻车"。两个信号一起用，AI 既知道"好的长什么样"，又知道"别犯这个错"。

第三步：把规则喂回给 AI

分析完的规则写入 AI 的上下文配置（比如 CLAUDE.md、.cursorrules、系统提示词等）：

markdown 复制代码

## 本项目编码规则（由反馈体系自动生成）

### 高频问题规避

1. 边界覆盖（本项目 AI 犯过 12 次）
   - 所有外键/关联查询必须处理目标记录不存在的情况
   - 所有列表操作必须处理空列表
   - 状态变更时必须处理关联数据的级联影响

2. 异常路径（本项目 AI 犯过 8 次）
   - 所有 API 写操作必须包含错误处理
   - UI 状态必须在操作失败时回滚

3. 并发安全（本项目 AI 犯过 4 次）
   - 后台任务入口必须加防重入守卫

AI 下次写代码时，这些规则就在它的上下文里。不需要你每次提醒。

然后下一轮分析再更新规则------规则越来越精准，AI 的错误越来越少。这就是持续纠偏的闭环：

markdown 复制代码

 AI 写代码 → AI 分析提交 → AI 发现模式 → AI 更新规则 → AI 写更好的代码
     ↑                                                          │
     └──────────────────────────────────────────────────────────┘

信号的三层递进

聚类分析不是只看表面。信号有三个层次：

Level 1：某个切片 fix 很多 → 这个切片的 spec 写得差

bash 复制代码

 Slice #12 有 5 个 fix
   → 回流：改进这个切片的 spec，补全验收条件

Level 2：同一个 Root-Cause 出现在多个切片 → 体系级的弱点

r 复制代码

 permission-missing 出现在 5 个不同切片
   → 不是某个 spec 的问题，是架构缺了一层
   → 回流：全局规则，所有 API 端点加权限校验

Level 3：同类问题在两个分类间摇摆 → 分类定义需要修正

r 复制代码

 有的标 boundary-incomplete，有的标 missing-validation
   → 人类介入，重新定义这两类的边界

处理流程：四层自动化

从 git 历史到规则生成，AI 贯穿全程：

yaml 复制代码

 Layer 0: AI 审计提交信息的可信度（自动）
   这条提交的 Root-Cause 标注靠谱吗？
   → 输出：✅ 可信 / ⚠ 待审 / ❌ 不一致

 Layer 1: 脚本采集原始数据（自动）
   → commits + diff stats + feat/fix 比率 + hot files

 Layer 2: AI 语义聚类（自动）
   → fix 按 Root-Cause 聚类
   → feat 按切片质量分正例/反例
   → 输出信号列表

 Layer 3: 人确认回流（唯一的非自动环节）
   → 每条信号：确认 / 修正 / 忽略
   → 确认后自动更新 AI 的上下文配置

人的角色：在 Layer 3 做确认。其余全部自动。

反馈报告长什么样

每周期（每迭代/每月）AI 自动产出一份报告，人只需要看决策列：

yaml 复制代码

Git 反馈报告 --- 2026-06-15

一、可信度
 ✅ 42 条（60%）  ⚠ 20 条待审  ❌ 8 条不一致

二、fix 信号
 | 根因                 | 次数 | 回流建议              | 你的决策 |
 |---------------------|------|----------------------|---------|
 | permission-missing  | ×5   | 全局加权限拦截规则    | ☐ 确认  |
 | boundary-incomplete | ×3   | 补边界场景到 spec 模板 | ☐ 确认  |

三、feat 信号
 | 切片质量     | 证据                    | 回流建议        | 你的决策 |
 |-------------|-------------------------|----------------|---------|
 | 🟢 正例 ×3  | Slice #12, #15, #19    | 记入案例库      | ☐ 确认  |
 | 🔴 反例 ×1  | Slice #08（1feat/4fix）| 补切片检查项    | ☐ 确认  |

四、已回流验证
 | 规则             | 上期  | 本期 | 效果                  |
 |-----------------|-------|------|----------------------|
 | 关联数据删除覆盖 | 12 次 | 3 次 | ↓ 有效 ✅             |

五、趋势
 | 指标          | 上期  | 本期  |
 |--------------|-------|-------|
 | fix/feat 比  | 0.8   | 0.5   |
 | 正例切片占比 | ---     | 43%   |

人机分工

复制代码

 AI 做什么                         人做什么
 ────────                         ────────
 分析 diff，生成提交信息            Review 提交信息是否准确
 按 Root-Cause 聚类                 确认聚类结果是否合理
 生成回流规则                       决定规则是否采纳
 更新上下文配置                     验证效果，调整方向

 分析、执行、持续运行               判断、决策、方向把控

AI 把自己犯过的错变成自己的规则------分析、执行、持续运行；人做判断、决策、方向把控。

成熟度阶梯

复制代码

 L0  没有工作流   直接让 AI 写代码，没有需求定义、没有测试、没有反馈
 L1  有构建无反馈  Spec Kit + TDD，但 AI 犯过的错不会自动学进去
 L2  AI 分析 + 人确认  ← 本体系的起点，反馈回路开始运转
 L3  自动回流    常见模式高置信度自动更新规则，人只看异常
 L4  量化验证    规则更新后同类错误归零，体系自证有效

怎么开始

第一步（本周就能做）

bash 复制代码

# 1. 提取最近 50 条 fix
git log --grep="fix" --oneline -50

# 2. 把 fix message + diff 喂给 AI，让它按 8 类白名单分类
#    提示词示例：
#    "以下是 50 条 fix 提交，请按以下 8 类 Root-Cause 归类：
#     boundary-incomplete / state-machine-gap / permission-missing /
#     concurrent-unsafe / missing-validation / happy-path-only /
#     logic-error / dependency-breaking
#     统计每类出现次数，找出 cross-cutting 模式"

# 3. 把分析结果写成规则，丢进 CLAUDE.md

不需要 Slice 编号，不需要 commit hook。一条提示词 + git log 就够。

第二步（积累几轮后）

接入 Spec Kit：用 /speckit.specify 写需求，自动分配 Slice 编号
让 AI 在每次提交时自动生成结构化 message（基于 diff + 上下文）
定期跑反馈报告，形成闭环

第三步（跑通后）

每次新对话先跑 Superpowers，建立 AI 能力地图
聚类自动化，规则自动更新
趋势数据验证体系有效性

附录

Root-Cause 快速判定（给 AI 的提示词里直接用）

markdown 复制代码

 按以下顺序排查，命中即停：

 1. 涉及权限/归属/越权？         → permission-missing
 2. 涉及并发/重入/竞态？         → concurrent-unsafe
 3. 只处理了正常路径？           → happy-path-only
 4. 状态转移没定义某条边？       → state-machine-gap
 5. 字段间约束/联动被忽略？      → missing-validation
 6. 边界条件没覆盖？            → boundary-incomplete
 7. 逻辑本身写错了？            → logic-error
 8. 依赖变更连锁修复？          → dependency-breaking

Slice 编号格式

perl 复制代码

 格式：{功能编号}-{功能名称}#{切片编号}-{切片名称}
 示例：003-order-system#12-cart-settlement
 横切：cross-cutting（跨功能的共性问题）

回流映射：哪类问题回哪里

Root-Cause	回流到哪	回流什么
boundary-incomplete	用户故事模板	验收条件补"关联数据被删/空值/极限"场景
happy-path-only	TDD 清单	强制覆盖异常路径
state-machine-gap	用户故事模板	强制附带状态转移图
missing-validation	切片策略	补"字段约束关系"检查项
concurrent-unsafe	AI 上下文规则	并发处理规则
permission-missing	AI 上下文规则	补"权限点"拆分维度