Appearance
AI 纠偏语言库
纠偏不是要求 AI 每次都停下来重新写计划，而是识别它具体偏离了什么，然后把任务拉回事实、边界和可验证结果。
纠偏总原则
- 先指出偏差：明确哪一处与目标、代码事实或验证证据不一致。
- 给出正确基线：目标、NonGoals、known-good、协议或业务规则是什么。
- 按风险决定是否需要重新确认：MicroPatch 可直接修；业务语义、跨模块或高风险任务才需要先复述/确认。
- 缩小范围：只修当前偏差，不顺手重构。
- 要求对应等级的证据：V0–V4，不机械要求每次都全构建、全测试。
如果连续两次纠正仍然失败，优先检查缺失事实和错误反馈回路，而不是继续叠话术。项目长期知识应按 Context、Memory 与 ADR 分层，不要把所有历史都塞回一个大上下文。
场景一：任务本来不明确或风险较高，AI 却直接写代码
适用：新流程、业务规则不清、跨模块行为、设备控制、高风险改动。
不适用：按钮文案、Margin、颜色、简单提示等明确 MicroPatch。Fast 任务直接小改是正常行为。
text
先停止修改。这个任务还有会改变最终结果的未知项。
请只输出：
1. 已确认事实；
2. Blocking Unknowns；
3. 你推荐的默认方案和原因；
4. 哪些问题必须由我决定。
Blocking Unknowns 清零后再进入实现。场景二：AI 扩大修改范围
text
本次任务的目标和 NonGoals 是：
目标：【填写】
不做：【填写】
请对照当前 Diff：
1. 标出与目标直接相关的修改；
2. 标出计划外改动；
3. 撤销计划外改动；
4. 保留最小修改集。
不要因为“顺便更整洁”做额外重构。如果某个新增公共接口、模块边界或架构调整确实必要，应单独说明为什么，并进入设计确认，而不是藏在普通功能修改里。
场景三：AI 反复用同一种错误方式重试
text
停止继续尝试同一种方案。
现在只做证据收敛：
1. 已经排除什么；
2. 哪个现象仍未解释；
3. 下一条最能区分假设的证据是什么；
4. 选择最紧的反馈信号：focused test / fake / replay / 日志时间线 / 最小 harness。
拿到新证据前不要继续随机改代码。如果是已知 E-SafeNet 等环境失败，不要把同一个构建错误反复当成代码问题重试。
场景四：AI 把“当前可疑代码”误判成近期回归根因
用户说“以前正常、昨天改后异常”时，必须 Temporal Regression / known-good-first。
text
这是近期回归。不要从当前代码里找一个看起来不合理的点就判根因。
请先：
1. 确定 known-good；
2. 列出 changed files；
3. 比较与现象最相关的方法、配置和协议差异；
4. 区分“旧代码本来就这样”和“本次真正发生变化”。
没有差异证据时，结论只能标成假设。如果只是切回旧版本后现象消失，先写 RolledBackToKnownGood；只有新代码被修复并用同一反馈信号重新验证，才写 RegressionFixed。
场景五：AI 理解偏了业务语义
text
当前实现和我的业务要求不一致。
请按下面的 Behavior Contract 重新核对，不要先扩大实现：
Trigger：
Condition：
Action：
Reset：
Record：
NonGoals：
如果涉及报警，请明确它属于 InterlockFault / AlarmOnly / Advisory / Information。对于测量值，再补：RawValue / EngineeringValue / Conversion / ThresholdBasis / Aggregation / LoggedUnit。
场景六：AI 给出没有足够证据的结论
不要统一要求“必须构建通过”。先看验证等级，再把结果落到正式状态。
text
请把结论改成证据分级：
VerificationLevel：V0 / V1 / V2 / V3 / V4
EvidenceGrade：A / B / C / D（若属于 Bug 调查）
Verified：
Unverified：
EnvironmentBlocked：
HardwarePending：
ResidualRisk：
如果没有测试或现场证据，不要写“经测试通过”。
0 tests matched 不能写成 TestPassed。
环境问题不能写成代码失败，也不能写成验证通过。
真实设备步骤没执行时写 HardwarePending，不写模糊的 Pending。场景七：现场问题重试后自己恢复
text
这次重试后恢复只能说明“瞬态状态问题的可能性提高”。
不要写 RootCauseConfirmed。
请标记 SuspectedTransient，并说明下一次出现时要捕获什么：
时间戳、命令/报文、错误队列、连接状态、设备状态或日志时间线。场景八：AI 在错误上继续叠补丁
text
停止继续修改。
先对照 Git Diff 和本次任务基线，撤销本轮引入的连锁改动。
恢复后只验证与当前风险匹配的最小基线；不要为了回退一个局部问题自动跑整套发布验证。
然后重新建立最小反馈信号再修。场景九：实验性修改被写成正式规则
text
这是 ExperimentalChange，不是正式规格变化。
请优先使用可恢复 override 或窄入口覆盖。
正式 Domain / MES / 持久化规则默认保持。
请明确恢复方式和测试结束后的清理项。快速选择
| 现象 | 优先纠偏 |
|---|---|
| 高风险任务直接开写 | 场景一 |
| 改了无关文件 | 场景二 |
| 同一方案反复失败 | 场景三 |
| “以前正常”却没比 known-good | 场景四 |
| 报警/停机/连续次数理解错 | 场景五 |
| “应该没问题”但没证据 | 场景六 |
| 重试后恢复就宣布根因 | 场景七 |
| 越修越乱 | 场景八 |
| 临时边界测试污染正式规则 | 场景九 |
纠偏的目标是让 Agent 回到正确任务类型 + 正确事实 + 正确边界 + 正确验证等级。