如何在内部推动 AI 工程规范：从门禁开始

规范推不动常因为缺少自动反馈。本文给出把规范拆成可检查项的方法、阻断与提醒两级、让规范顺手的三种做法（脚手架/一键检查/报错给修法）、用数据说明价值与三条经验。

规范推不动，通常是因为"没有反馈"

内部推 AI 工程规范最常见的结果是：文档发了、没人看 ✗；口头强调、下次照旧 ✗。

原因往往不是"大家不认同" ✗，而是**规范没有落成"跑一下就知道"的检查** ✔。

**能自动跑的规范才会被执行** ✔ —— 这是过去几年最有用的经验之一 ✔。

| 规范 | 可检查形式 |

|---|---|

| 结构化输出必须校验 | 检查代码里有没有校验函数调用 ✔ |

| 提示词要版本化 | 检查提示词是否来自版本库（而非字符串字面量）✔ |

| 写操作必须幂等 | 检查是否存在幂等键参数 ✔ |

| 必须记录调用指纹 | 检查日志字段是否包含指纹 ✔ |

| 对外接口必须声明不确定性 | 检查契约文档/响应字段是否存在 ✔ |

**关键**：每条都要能被**脚本判定通过/不通过** ✔，而不是"请自觉" ✗。

**阻断**（必须过）：涉及安全、合规、数据泄露、幂等 ✔；

**提醒**（警告）：涉及风格、日志完整性、命名 ✔。

全阻断会把流程卡死 ✗（大家开始绕过 ✔）；全提醒等于没有 ✗。**两级就够** ✔。

提供**脚手架**（新建 AI 调用时自动带上指纹、校验、日志 ✔）；

提供**一键检查**（`make check` / 一个脚本 ✔），本地能跑 ✔；

检查失败时**给出修法**（不只是报错 ✔）：

"缺少调用指纹 → 在 `llmCall()` 里传 `fingerprint` 参数，示例：…" ✔

在评审里展示两类数字 ✔：

**被检查挡下的问题数**（例如"本月挡下 6 次缺少校验的写操作" ✔）；

**线上事故与规范的对应关系**（哪些事故本可被某条检查拦住 ✔）。

**用真实事故说明规范的价值** ✔ 比讲道理有效得多 ✔。

1. **先做 3 条** ✔（从最痛的地方选 ✔），别一次上 20 条 ✗；

2. **每周复盘一次误报** ✔（误报多的检查会被绕过 ✗）；

3. **规范进交接文档** ✔（新人第一天就能跑 ✔）。

> 一个新人入职第一周，**不问你任何问题**，能否靠"跑一次检查 + 读报错里的修法"把代码改到合规 ✔？

> 能，说明规范真的落地了 ✔。