---
id: ka-guidance-反馈修复闭环
kind: guidance
title: 反馈修复闭环
sync_policy: engine_only
status: active
triggers:
  - 验证失败
  - 门禁失败
  - 检查失败
  - 修复
  - fix
  - 重试
  - retry
  - escalate
  - 反馈
  - 复验
  - 修复闭环
  - gate
  - 复检
extra:
  name: feedback-repair-loop
  scope:
    - '*'
  products:
    - '*'
  category: procedure
  version: 1.0.0
  last_reviewed: '2026-06-17'
  verification_layer: L2
  stage: _global
  owner_mechanism: mc-verifier
---

# 反馈修复闭环：报错怎么修、修完怎么回来

> Full 验证失败后，按本流程闭环。禁止假修复、禁止跳过。

## 第一步：读懂门禁反馈

Full 失败后，`sf_verify` 返回结构化 findings。每条 finding 含：
- `id`：结构化定位编号；用于查找结果，不作为用户修复方法
- `severity`：`error`（必须修）/ `warning`（应当修）/ `info`（advisory 参考）
- `message`：技术原因（为什么失败）
- `evidence_required`：补什么证据才算修好

还有一段大白话 `recovery_summary`：整体怎么了、该干什么、有什么 pending 项。

## 第二步：逐条修复（按 severity 分流）

**error 级**（必须全修）：
1. 看 message 定位根因，不是只看表象（[[工程执行总纲]] 思考先行）
2. 按 evidence_required 补齐证据
3. 修复限于同一限界上下文；跨越无关模块必须回到任务拆解

**warning 级**（尽量修）：
- 影响小可记录风险后放行，但在交付说明里写清放行理由

**info 级（semantic）**：
- advisory 不阻断，但是给客户端 AI 的评判参考
- 必须认真评估，不能当没看见；评估结论写进交付说明

## 第三步：重新完整验证

- 对修复的同一产物调用 `sf_verify action="full"`。
- Full 通过后用 `sf_task action="query"` 查看当前阶段剩余证据。
- 当前阶段全部证据有效后才调用 `sf_task action="advance"`。

## 第四步：重试与 escalate

- 读取 full 结果中的 `retry_count/max_retries`，不要在指导文案复制上限。
- 同一产物连续失败时先修根因或改变内容；达到当前记录上限后按工具返回停止机械重试，由用户决定 reset、调整范围或人工介入。

## 禁止

- 假修复（改了但没解决根因，下次还报）
- 删断言/降覆盖率/加无关 mock 让门禁过（[[工程执行总纲]] 精准修改的硬失败）
- 隐藏失败 finding
- 把 advisory 结果当成 required 通过
- 没有重验就标记完成

## 证据要求

修复后必须给出：改了什么、对应哪条 finding、重验结果（命令 + 输出）。不接受「已修复」三字。