"生成"与"校验"耦合，会互相拖累
常见架构问题 ✗：同一个服务里既调用模型生成 ✔，又做规则校验与落库 ✔。
结果是：校验加严 → 生成也变慢 ✔；生成限流 → 校验也被拖住 ✔；
更糟的是校验失败时重试整个生成 ✗（白花钱 ✔）。
把"生成"与"校验"分开 ✔：职责分离、独立扩缩、独立失败 ✔。
一、分开之后的四个好处
- 独立扩缩（校验是纯计算，便宜且快 ✔ —— 不必跟模型一起排队 ✔）；
- 独立失败（校验服务挂了 → 可以降级为"标记待人工" ✔，而不是整体不可用 ✔）；
- 可重放（生成结果存下来 ✔ → 校验规则改了可以只重跑校验 ✔，不用重新调用模型 ✔）；
- 可审计（校验是确定性的 ✔ → 结果可复现、可解释 ✔）。
第 3 条最省钱 ✗→✔：规则调整（新增词表、改阈值 ✔）只需重跑校验 ✔。
二、推荐的分段
① 准备（输入规范化、权限判定 —— 见输入规范化那篇 ✔）
② 生成（调模型，产出原始输出 + 元数据 ✔）
③ 校验（schema、规则、词表、证据一致性 ✔）
④ 落库/交付（幂等写入 + 审核队列 ✔）
每段独立重试 ✔：生成失败重试生成 ✔；校验失败只重跑校验 ✔（或带上错误回喂重生成一次 ✔）。
三、接口怎么定
- 生成输出：原始输出 +
model/prompt_version/index_version+ token/成本 ✔； - 校验输入：原始输出 + 上下文（资料片段 id ✔）；输出：
pass/fail + reasons[]✔； - 关键：校验结果是结构化的（便于统计哪条规则最常拦 ✔ —— 见约束变校验 ✔）。
四、三个常见反模式
- 校验写在提示词里 ✗（模型自己审自己 ✔ —— 应该是外部校验 ✔）；
- 校验失败就整体重试 ✗（成本翻倍 ✔）；
- 校验与生成同一进程同一队列 ✗（互相拖累 ✔）。
五、一条判据
改一条校验规则后 ✔，你能否不重新调用模型就把已有结果重跑一遍校验 ✔？
不能，说明生成与校验还耦合在一起 ✗。