规范推不动，通常是因为"没有反馈"
内部推 AI 工程规范最常见的结果是：文档发了、没人看 ✗；口头强调、下次照旧 ✗。
原因往往不是"大家不认同" ✗，而是规范没有落成"跑一下就知道"的检查 ✔。
能自动跑的规范才会被执行 ✔ —— 这是过去几年最有用的经验之一 ✔。
一、把规范拆成"可检查项"
| 规范 | 可检查形式 |
|---|---|
| 结构化输出必须校验 | 检查代码里有没有校验函数调用 ✔ |
| 提示词要版本化 | 检查提示词是否来自版本库（而非字符串字面量）✔ |
| 写操作必须幂等 | 检查是否存在幂等键参数 ✔ |
| 必须记录调用指纹 | 检查日志字段是否包含指纹 ✔ |
| 对外接口必须声明不确定性 | 检查契约文档/响应字段是否存在 ✔ |
关键：每条都要能被脚本判定通过/不通过 ✔，而不是"请自觉" ✗。
二、分级：阻断 vs 提醒
- 阻断（必须过）：涉及安全、合规、数据泄露、幂等 ✔；
- 提醒（警告）：涉及风格、日志完整性、命名 ✔。
全阻断会把流程卡死 ✗（大家开始绕过 ✔）；全提醒等于没有 ✗。两级就够 ✔。
三、让规范"顺手"
- 提供脚手架（新建 AI 调用时自动带上指纹、校验、日志 ✔）；
- 提供一键检查（
make check/ 一个脚本 ✔），本地能跑 ✔； - 检查失败时给出修法（不只是报错 ✔）：
"缺少调用指纹 → 在 llmCall() 里传 fingerprint 参数，示例：…" ✔
四、用数据驱动"为什么值得"
在评审里展示两类数字 ✔：
- 被检查挡下的问题数（例如"本月挡下 6 次缺少校验的写操作" ✔）；
- 线上事故与规范的对应关系（哪些事故本可被某条检查拦住 ✔）。
用真实事故说明规范的价值 ✔ 比讲道理有效得多 ✔。
五、三条经验
- 先做 3 条 ✔（从最痛的地方选 ✔），别一次上 20 条 ✗；
- 每周复盘一次误报 ✔（误报多的检查会被绕过 ✗）；
- 规范进交接文档 ✔（新人第一天就能跑 ✔）。
一条判据
一个新人入职第一周，不问你任何问题，能否靠"跑一次检查 + 读报错里的修法"把代码改到合规 ✔？
能，说明规范真的落地了 ✔。