POC 证明的是"模型能做到"，生产要证明的是"在真实流量、真实成本、真实故障下仍然可用"。两件事之间隔着六个落差，而其中只有一个能靠换更强的模型解决。

---

1. POC 与生产的六个落差

落差	POC 里的样子	生产里的样子	谁在承担
数据质量	手挑的干净样本	脏数据、缺字段、格式不一	检索与预处理层
延迟	单次调用，无人等待	并发下的 p99 延迟	预算分配与降级
成本	几十次调用，忽略不计	按 token 线性放大	产品定价与路由
失败率	失败就重跑	失败要有兜底与告知	失败模式设计
可解释性	结果对就行	要能回答"为什么这么答"	留痕与引用
合规要求	不在考虑范围	数据流向、日志留存、用户告知	架构与流程

六个落差里，只有"能力"那项能靠换模型改善，其余五项全是工程问题——这也是 POC 到生产周期往往以月计、而不是以天计的原因。

2. 能力边界的诚实评估

维度	适合模型	不适合模型	判据
任务可分解性	能拆成有明确输入输出的子步	需长链隐式推理且无中间校验	中间结果可否被检查
错误容忍度	错了可被发现、可重试	一次错就不可逆	失败代价是否可承受
人工兜底成本	兜底量小、可批量处理	兜底等于人工重做一遍	兜底成本 vs 自动化收益
输出确定性	允许表达多样	必须唯一正确答案	是否有客观判定标准
数据可得性	上下文足够支撑判断	关键信息不在输入里	信息是否在模型可见范围

评估要落到可执行分支，而不是停在"效果不错"：

if 任务可由规则判定:            → 不用模型
elif 错误可检测且可重试:        → 用模型 + 校验层
elif 错误不可逆且无人工兜底:    → 不用模型，或降级为"建议"而非"执行"
elif 需要唯一正确答案:          → 模型出候选，判定交给程序
else:                          → 用模型 + 人工抽检

"什么不该用模型做"有一份稳定清单：金额计算、权限判定、状态机迁移、需审计追踪的决策，以及规则明确且变更不频繁的分类。

3. 成本结构三层

层	组成	规模化时的行为	常见盲区
模型层	输入/输出 token、重试、上下文长度	近线性，上下文膨胀时超线性	长系统提示词被每次重复计费
检索层	向量存储、索引重建、查询 QPS	存储线性、查询近线性	索引重建的算力峰值
评测层	离线集跑批、人工标注、抽检	随迭代次数增长，非随流量	每次改提示词都要重跑全量

monthly = tokens_in × p_in + tokens_out × p_out
        + vector_storage_gb × p_storage + rebuild_count × rebuild_cost
        + eval_runs × (eval_tokens × p_in + human_hours × p_hour)

非线性的三个点值得单独盯：上下文随会话变长（同一会话成本随时间上升）、重试放大（实际调用数高于请求数）、评测随迭代次数（改得越勤，评测越贵）。

4. 延迟预算的分配

环节	典型占比	压缩手段	代价
检索	一到三成	缓存、减 top-k、预取	召回下降
模型	五到七成	小模型、流式、投机解码	质量或成本
后处理	一到两成	并行校验、减少二次调用	校验强度下降

流式改变的是感知延迟而不是真实延迟：首 token 早到，用户就觉得快。所以预算要按 TTFT 与总时长两个目标分别定，而不是一个笼统的"响应时间"。

latency_budget:
  ttft_ms: 800            # 首 token 目标，决定感知
  total_ms: 6000          # 整体目标，决定是否超时
  allocation:
    retrieval_ms: 1200
    model_ms: 4000
    postprocess_ms: 800
  on_exceed: degrade      # degrade | queue | fail

5. 失败模式设计与降级链

失败模式	表现	检测手段	处置
模型超时	无响应或极慢	客户端超时 + 服务端 p99	降级到小模型或静态回复
幻觉	编造事实、引用不存在	引用校验、结构化约束	要求引用，无法引用即拒答
格式错误	JSON 不合法、字段缺失	schema 校验	重试一次，仍失败走兜底
拒答	该答不答	抽样 + 意图分类	改写提示或转人工

fallback_chain:
  - primary: MODEL_A
    validate: schema + citation_check
  - on: [timeout, schema_error]
    use: MODEL_B
    validate: schema only
  - on: [any_error]
    use: STATIC_TEMPLATE       # 确定性输出，附明确的"未能生成"告知

每条降级都要有可观测计数，否则降级链会在无人知情的情况下变成常态，而质量已经悄悄掉了一档。

6. 评测体系三级

层级	目的	频率	成本	局限
离线集	防回归	每次改动	低	与真实分布有偏差
在线 A/B	判效果	有足够流量时	中	需指标定义清楚
人工抽检	判质量细节	周期性	高	样本小、主观

"只看 demo 效果"的陷阱在于：demo 是挑选过的样本，而离线集的价值恰在于它不挑选。没有固定的离线集，任何提示词改动都无法判断是变好还是变坏。

{
  "offline_set": {
    "size": "SAMPLE_SIZE",
    "strata": ["常见意图", "边界样本", "历史失败样本"],
    "metric": ["task_success", "schema_valid_rate", "citation_hit"],
    "gate": "不得低于基线 - TOLERANCE"
  }
}

7. 灰度与回滚

维度	独立灰度的理由	回滚粒度
提示词版本	改动最频繁，影响面最直接	按版本回退
模型版本	厂商升级可能改变行为	按模型 ID 锁定
检索索引	重建后召回分布变化	按索引别名切换

三者必须能独立灰度：如果提示词、模型、索引同时变更，出问题时无法归因，回滚也只能整体回退，代价最大。

release:
  prompt_version: v__NEXT__
  model_id: MODEL_ID
  index_alias: idx__BLUE__
  canary:
    ratio: 0.05
    metrics: [error_rate, p99_latency, thumbs_down_rate]
    auto_rollback_on: error_rate > THRESHOLD

8. 组织准备

职责	归属	缺位后果
提示词与策略	产品与工程共管	提示词散落在代码里，无人负责
数据标注	业务专家	标注标准漂移，评测失真
上线审批	明确的 owner	谁都能改线上行为
值班与告警	运维 + 应用 owner	故障无人认领
成本看护	财务 + 工程	超支月底才发现

最常见的组织缺口是提示词没有 owner：它既是产品行为又是代码资产，结果两边都不管。

9. 数据闭环

环节	机制	优先级判据
失败样本回流	线上失败与低分反馈入库	按影响面排序，而非按出现频次
标注优先级	边界样本 > 明显错误 > 已正确	边界样本提升判别力
迭代节奏	固定周期评估，不随单例改动	改得太勤无法判断效果
评测集扩充	新失败样本进入离线集	防止同一问题回归

采集 → 归因（能力/数据/提示/检索）→ 入离线集 → 修 → 离线回归 → 灰度
                                  ↑                    ↓
                              （不达标则退回）

闭环的关键不是采得多，而是归因分得清。把检索问题当成模型问题去改提示词，是数据闭环里最常见的空转。

10. 合规与留痕

事项	工程落点	设计要点
数据出境	调用路由与模型选择	按数据分类决定可用模型与区域
日志留存	请求日志与响应日志分离	留存周期与脱敏策略前置定义
用户告知	界面与文档	明确哪些内容由模型生成
审计追溯	版本三元组留痕	提示词、模型、索引版本随请求记录

留痕的最小单位是一次请求对应一组版本号，否则事后无法复现当时的行为。

11. 排错

现象	可能原因	处置方向
上线后效果明显下降	真实分布与离线集偏差	用线上样本重建评测集
延迟偶发飙升	长上下文或重试放大	拆 TTFT 与总时长分别看
成本超预期	上下文膨胀、重试、评测跑批	按层拆账，找出非线性项
格式错误率高	约束不足或模型版本变化	加 schema 校验 + 锁定版本
回滚后问题仍在	多维度同时变更	改为单维度灰度
无人认领线上问题	缺 owner	明确提示词与发布责任人

12. 边界

场景	不该做的事	更合适的做法
低价值高频任务	用大模型逐条调用	规则或小模型 + 抽样
强确定性规则场景	让模型判定	程序判定，模型只做解释
错误不可逆的操作	直接执行模型输出	生成建议 + 人工确认
无评测集的项目	直接灰度放量	先建离线集再谈上线
需要唯一答案	依赖模型输出	模型出候选，程序做判定

判断一个 AI 应用能否进生产，只需一个问题：它的失败能否被检测、被兜底、被追溯。三者缺一，就还停在 POC。

---

13. 自测

1. 六个落差里，哪一项能靠换更强的模型解决？
2. 什么情况下应让模型只做"建议"而由人执行？
3. 成本三层中，哪一层随迭代次数而非流量增长？
4. 流式输出改变的是真实延迟还是感知延迟，为什么预算要分开定？
5. 提示词、模型、索引为什么必须独立灰度？
6. 判断一个 AI 应用能否进生产，最该问的那一个问题是什么？