第 6 章 · 改完报错怎么办
本章目标：改代码后若出现 【结构化修复清单】 或 【API 未对齐明细】，知道如何配合 自动检查设置 与 审阅条；区分「语法/类型修了」与「业务逻辑对不对」；会用 终端报错 + SRX 跟进修复。
学时建议：2.5～3 小时（含 1 小时跟练）
前置：srx-v7 ch03（审阅条）；ch05（影响面清单）；ch08 自动检查相关设置可对照。
只讲用户可见现象与操作，不讲内部如何处理。
6.1 场景说明：审阅条全 ✓ 了，一跑测试还是红的
SRX 改完 TypeScript / Go 文件，审阅条里 3 个文件全部接受。你跑 npm test，仍失败——因为：
- 自动检查可能还在 逐条修复 中你就关了任务
- 或类型错误修了，断言/业务 仍错
- 或项目本身 环境/依赖 有问题，AI 修不对
本章练：什么时候会出现修复清单、您该等还是该介入、清单不能替代审阅。
6.2 学完你能
| 能力 | 验收 |
|---|---|
| 识别 | 找到【结构化修复清单】/【API 未对齐明细】 |
| 设置 | 开启保存后自动检查、写入后增量验证 |
| 配合 | 等执行结束再处理审阅条 |
| 分工 | 清单修语法/类型；您审业务逻辑 |
| 跟进 | 清单太长时缩小范围；终端报错带入 SRX |
| 边界 | 知无逐项打勾表单 |
6.3 什么时候会出现
SRX 改完文件后，若项目配置了 自动检查（类型检查、lint、全栈 API 对齐等），执行输出里可能出现：
【结构化修复清单】
或全栈场景：
【API 未对齐明细】
常见格式：
1. src/foo.ts:42:10 — Type 'string' is not assignable to type 'number'
2. handlers/order.go:88 — undefined: OrderV2
…您会看到的现象：
- AI 可能 继续尝试逐条修复
- 执行面板有后续步骤输出
- 没有让您逐项打勾的表单——等流程结束，再到 审阅条 确认
6.4 建议开启的设置（ch08 对照）
Ctrl+, → SRX-V7引擎 设置：
| 设置项 | 建议 | 原因 |
|---|---|---|
| 保存后自动检查 | 开启 | 尽早发现错误 |
| 写入后增量验证 | 开启 | 改一点验一点 |
| 执行强度 | 超科幻（默认） | 日常改代码更稳 |
| 执行终端命令前弹出确认 | 开启 | 看清 test/lint 命令 |
新手：只动上述几项，勿乱改所有子开关（ch08 8.2）。
6.5 跟练 A：观察修复清单流程（必做）
步骤 1 — 准备可检查项目
- 打开含 TypeScript / Go 的练习仓（或 shop-demo）
- 分支：
git checkout -b try/ch06-fixlist
步骤 2 — 发故意留问题的任务（小范围）
【目标】在某个 .ts 或 .go 小文件里增加一个函数，参数类型故意与调用处不一致（练习用）
【范围】只改 1～2 个文件，不要重构
【说明】改完后若出现检查报错，请按清单修复类型/语法问题
【验收】本地检查无类型错误（若项目支持）若无 TS/Go，可改 README 中的代码块 作叙述练习，或跳过到步骤 3 观察任意真实报错任务。
步骤 3 — 观察执行输出
- 是否出现 【结构化修复清单】
- AI 是否有多轮「修复 → 再检查」
步骤 4 — 等待明确结束
- 不要在还在跑检查时关任务或点停止（除非方向完全错）
步骤 5 — 审阅条
- 逐文件看 diff（ch03）
- 问：业务意图是否符合任务？不只「没红字」
你应该看到：清单可能变短或消失；审阅条仍要人工 ✓。