---
title: "从 AI Demo 到生产：团队必须偿还的五类生产债"
source_url: "https://towardsdatascience.com/why-your-ai-demo-will-die-in-production/"
source_summary: "/home/lin/.hermes/projects/hermes-gsummary-workflow/runs/outputs/20260519-175733-Why-Your-AI-Demo-Will-Die-in-Production-2738318-245693040-summary.md"
created: "2026-05-19"
type: "team-sharing-html"
---

# 从 AI Demo 到生产：团队必须偿还的五类生产债

> 适用对象：正在把 LLM / Agent / AI 自动化从演示推进到真实业务的研发、数据、运维和产品团队。  
> 分享目标：把“Demo 能跑”改造成“生产可控”，用五类生产债检查项目是否具备上线条件。  
> 来源边界：本文基于 Ari Joury 的文章《Why Your AI Demo Will Die in Production》和本地 Gemini 摘要整理；实践部分是面向团队落地的补充，不代表原文逐字内容。

## 1. 一句话结论

AI Demo 死在生产环境里，通常不是因为模型不够聪明，而是因为团队没有偿还这些债：

```text
技术债 → 输出不稳定、缺少 schema、prompt 脆弱
运营债 → 没 owner、没排障路径、没 AI 专属监控
评估债 → 只靠肉眼感觉，改一次 prompt 坏十个场景
集成债 → AI 输出没有和下游系统/API/数据格式对齐
治理债 → 审计、隐私、HITL、数据保留事后才补
```

内部分享时可以用一句话收束：

```text
不要把大模型当魔法；要把它当作一个不可靠但有价值的微服务，用契约、评估、监控、集成和治理包起来。
```

## 2. 为什么 Demo 会误导团队

Demo 的评判标准通常是：

- 看起来回答不错；
- 老板或业务方现场觉得惊艳；
- 样例数据干净；
- 调用链短；
- 出错可以人工解释或现场重试。

生产环境的评判标准完全不同：

- 输入会脏、长、乱、重复、缺字段；
- 模型会偶发改变格式；
- 下游系统只接受严格 schema；
- 错误会进入真实客户、真实数据、真实流程；
- 成本、延迟、权限、审计都要长期可追踪。

因此从 Demo 到 Production 的核心不是“换一个更强模型”，而是补齐工程系统。

## 3. 五类生产债检查表

### 3.1 技术债：Prompt 不是接口契约

危险信号：

- 直接解析模型自然语言输出；
- 只在 prompt 里写“请返回 JSON”；
- 没有字段校验、类型校验、重试逻辑；
- 模型多输出一段 Markdown 就会让下游崩溃。

最低可用做法：

```python
from pydantic import BaseModel, Field, ValidationError

class SqlReviewResult(BaseModel):
    risk_level: str = Field(pattern="^(low|medium|high)$")
    approved: bool
    reasons: list[str]
    required_actions: list[str] = []


def parse_llm_result(raw: str) -> SqlReviewResult:
    """把 LLM 输出变成可验证对象；失败时交给重试或人工确认。"""
    try:
        return SqlReviewResult.model_validate_json(raw)
    except ValidationError as exc:
        raise ValueError(f"LLM output schema invalid: {exc}") from exc
```

验收标准：

- 模型输出多余 Markdown 包裹时，不会静默进入下游；
- 缺字段、字段类型错误、枚举值错误时会失败关闭；
- 有明确重试、降级或人工确认路径。

### 3.2 运营债：AI 服务也需要 owner

危险信号：

- 出问题时不知道找数据团队、后端团队还是运维团队；
- 只监控 HTTP 200，不监控模型输出质量；
- Token 成本暴涨、上下文接近上限没人知道；
- 上游模型/API 改行为后，只能靠人工猜。

建议给每个 AI 工作流建立最小 RACI：

```text
工作流名称：SQL 自动审查 Agent
Responsible：后端/平台负责人，处理日常问题
Accountable：业务系统 owner，决定是否上线和回滚
Consulted：DBA、安全、运维
Informed：使用该能力的业务团队
```

最小监控指标：

```text
请求量：ai_requests_total
失败率：ai_schema_validation_failed_total / ai_requests_total
平均延迟：ai_request_duration_seconds
Token 成本：ai_tokens_total, ai_cost_estimated
上下文饱和度：prompt_tokens / model_context_limit
人工介入率：human_review_required_total / ai_requests_total
```

### 3.3 评估债：Vibe Check 不是测试

危险信号：

- 改 prompt 后只看 3 个例子；
- 没有固定回归样本；
- 只评价“回答像不像”，不评价业务结果；
- 修好一个场景后，其他场景是否退化无人知道。

建议先做一个小型黄金数据集，不要一开始追求完美。

样例文件：`fixtures/ai_review_cases.jsonl`

```jsonl
{"id":"case-001","input":"DROP TABLE users;","expected":{"risk_level":"high","approved":false}}
{"id":"case-002","input":"CREATE INDEX idx_orders_user_id ON orders(user_id);","expected":{"risk_level":"low","approved":true}}
{"id":"case-003","input":"UPDATE accounts SET balance=0;","expected":{"risk_level":"high","approved":false}}
```

最小验证脚本思路：

```python
import json


def load_cases(path: str) -> list[dict]:
    with open(path, encoding="utf-8") as f:
        return [json.loads(line) for line in f if line.strip()]


def score_case(actual: dict, expected: dict) -> bool:
    return (
        actual["risk_level"] == expected["risk_level"]
        and actual["approved"] == expected["approved"]
    )
```

验收标准：

- 每次修改 prompt / 模型 / 工具前后都能跑同一批样本；
- 输出通过率、误拒率、误放率可比较；
- 不要求第一版覆盖全部业务，但必须覆盖最危险的 20-50 个场景。

### 3.4 集成债：AI 输出必须贴合下游系统

危险信号：

- AI 输出“语义正确”，但字段名、日期格式、枚举值下游不认；
- 等到上线前才接 CRM、工单、数据库或审批系统；
- 没有 mock 下游 API；
- 接口契约只存在口头约定。

建议项目第一周就做接口 mock。

示例：下游只接受 ISO 日期和固定动作枚举。

```json
{
  "customer_id": "C001",
  "action": "CREATE_TICKET",
  "due_date": "2026-05-20",
  "priority": "P1"
}
```

AI 工作流必须验证：

```text
字段完整：customer_id/action/due_date/priority 都存在
枚举合法：action 只能是 CREATE_TICKET / UPDATE_TICKET / ESCALATE
日期合法：YYYY-MM-DD
失败处理：不合法时进入人工确认，不自动写入生产系统
```

### 3.5 治理债：合规不能最后补

危险信号：

- 生产数据直接进入第三方模型；
- 没有 PII 脱敏；
- 高风险动作无需人工确认；
- 出问题后无法回答“模型为什么这么做”；
- 日志里混入密钥、客户隐私或完整业务数据。

建议从第一版就定义风险分层：

```text
低风险：摘要、分类、只读检索 → 自动执行，保留日志
中风险：生成建议、辅助决策 → 人工确认后执行
高风险：改数据、发消息、删资源、影响客户权益 → 默认禁止或强 HITL
```

最小审计日志字段：

```json
{
  "request_id": "uuid",
  "workflow": "customer-support-agent",
  "actor": "user-or-system",
  "input_hash": "sha256-of-redacted-input",
  "model": "model-name",
  "decision": "ESCALATE",
  "confidence_or_score": 0.82,
  "human_approved": true,
  "created_at": "2026-05-19T10:00:00Z"
}
```

注意：日志应保存可审计证据，而不是无脑保存全部原始敏感数据。

## 4. 三个可直接用于团队讨论的案例

### 案例 A：SQL 审查 Agent

场景：团队希望用 LLM 自动审查 SQL 变更。

最小流程：

```text
SQL 文件
→ 规则引擎初筛
→ LLM 结构化审查
→ schema 校验
→ 高危拒绝 / 中低危人工确认
→ 执行前备份
→ 审计日志
```

样例输入：

```sql
UPDATE users SET status = 'inactive';
```

期望输出：

```json
{
  "risk_level": "high",
  "approved": false,
  "reasons": ["缺少 WHERE 条件，可能全表更新"],
  "required_actions": ["补充 WHERE 条件", "提供回滚方案"]
}
```

失败处理：

- LLM 输出无法解析：不执行 SQL；
- LLM 低风险但规则引擎高危：进入人工确认；
- 审计日志写入失败：不进入生产执行。

### 案例 B：客服工单 Agent

场景：AI 根据客户消息生成工单分类和建议回复。

最小流程：

```text
客户消息
→ PII 脱敏
→ 意图分类
→ 生成建议回复
→ 人工确认
→ 写入工单系统
```

样例输入：

```text
客户说：我昨晚付款后订单还显示未支付，手机号是 138****0000。
```

期望输出：

```json
{
  "category": "payment_issue",
  "priority": "P1",
  "reply_draft": "您好，我们已收到您的支付异常反馈，会优先核查订单状态。",
  "requires_human_review": true
}
```

失败处理：

- 未脱敏不得进入模型；
- 回复涉及退款、赔偿、法律承诺时必须人工确认；
- 分类置信不足时只生成草稿，不自动写入工单。

### 案例 C：内部知识库问答 Agent

场景：员工询问内部制度、部署手册、排障步骤。

最小流程：

```text
用户问题
→ 检索文档
→ 引用来源
→ 生成答案
→ 标记不确定性
→ 记录低质量反馈样本
```

样例输入：

```text
怎么重启 k8s-pod-monitor？
```

期望输出：

```text
答案必须包含：
1. 来源文档路径或链接
2. 具体命令
3. 风险提示
4. 如果找不到依据，明确说“不确定”
```

失败处理：

- 没有检索到来源：不能编造；
- 答案涉及生产重启：必须提示确认范围和回滚方式；
- 用户点踩：进入黄金数据集候选，不直接改全局规则。

## 5. 一周落地路线

### Day 1：列出 AI 工作流清单

输出：

```text
工作流名称
业务目标
是否读写生产数据
是否影响客户/资金/权限
当前 owner
当前失败处理方式
```

验收：每个工作流都能归类为低/中/高风险。

### Day 2：补 schema 和失败关闭

输出：

- 所有模型输出都有结构化 schema；
- 解析失败不会进入下游；
- 有重试、降级或人工确认路径。

验收：故意让模型输出错格式，系统能安全失败。

### Day 3：建立 20 个黄金样本

输出：

- 10 个正常样本；
- 5 个边界样本；
- 5 个高风险样本。

验收：修改 prompt 前后能比较结果。

### Day 4：接入最小监控

输出：

- 请求量；
- 失败率；
- schema 校验失败率；
- 平均延迟；
- Token 消耗；
- 人工介入率。

验收：能回答“今天 AI 工作流是否比昨天更差”。

### Day 5：补审计和上线门槛

输出：

```text
上线前必须回答：
- 谁负责？
- 失败怎么停？
- 错误怎么查？
- 数据是否脱敏？
- 高风险动作是否 HITL？
- 有没有回归样本？
```

验收：没有 owner、没有审计、没有失败关闭的 AI 工作流不得进入生产。

## 6. 分享时可以直接使用的提问清单

把下面这段贴到团队评审文档或 PR 描述里：

```text
请按“生产级 AI 债务”审查这个 AI 工作流：

1. 技术债：模型输出是否有 schema？解析失败是否 fail closed？
2. 运营债：owner 是谁？报警后谁处理？监控哪些 AI 专属指标？
3. 评估债：是否有固定黄金样本？修改 prompt 后如何判断退化？
4. 集成债：下游 API/schema 是否已 mock 和验证？
5. 治理债：是否涉及 PII、客户权益、资金、权限或生产写操作？是否 HITL？

请输出：
- 当前风险等级：低/中/高
- 必须补齐项
- 可延后项
- 不允许上线的阻断项
```

## 7. 常见误区

- 误区 1：以为模型升级能解决生产问题。  
  现实：更强模型也可能输出不稳定格式，工程契约仍然需要。

- 误区 2：只做 prompt 调优，不做评估集。  
  现实：没有黄金样本，无法知道这次调优有没有破坏其他场景。

- 误区 3：AI 项目只归数据团队。  
  现实：生产 AI 同时涉及产品、后端、数据、运维、安全和业务 owner。

- 误区 4：先上线，合规后补。  
  现实：涉及客户、资金、医疗、金融、权限的数据流，治理债最后补通常代价最高。

- 误区 5：一开始就追求全自动。  
  现实：更稳妥的路线是先只读、再建议、再人工确认执行，最后才考虑有限自动化。

## 8. 可直接落地的团队共识

建议团队先达成这三条：

```text
1. AI 工作流没有 schema，不进生产。
2. AI 工作流没有黄金样本，不随意改 prompt。
3. AI 工作流涉及真实副作用，默认需要人工确认和审计日志。
```

这三条不复杂，但能挡住大多数“Demo 很惊艳，上线就崩”的问题。

## 9. 来源与局限

- 原文：Why Your AI Demo Will Die in Production  
- URL：https://towardsdatascience.com/why-your-ai-demo-will-die-in-production/  
- 本地摘要：`/home/lin/.hermes/projects/hermes-gsummary-workflow/runs/outputs/20260519-175733-Why-Your-AI-Demo-Will-Die-in-Production-2738318-245693040-summary.md`

局限：原文提到“约 95% 的企业 AI 试点无法进入生产”，该数字适合作为数量级提醒，不应作为团队 KPI 或硬性行业基准。本文的案例和一周路线是面向团队内部落地的实践补充，使用时应按项目风险和规模裁剪。