AI 全栈入门：一个 AI 应用不止有模型，用少量代码跑通完整链路

一、AI 全栈的五个层次

一个典型的 AI 应用可以拆成五层：

1. 前端交互层：输入框、对话流、流式渲染、加载状态、错误提示；
2. 后端服务层：接口路由、鉴权、限流、提示词组装、模型调用编排；
3. 模型能力层：大模型 API、嵌入模型、重排序模型，必要时还有微调；
4. 数据与检索层：业务数据库、向量库、文档解析和切分；
5. 运维与评测层：部署、日志、监控、成本统计、离线评测和线上反馈。

传统全栈关注“前端 + 后端 + 数据库”，AI 全栈在此基础上多了模型编排、检索和评测。模型能力层不是孤立的，它需要后端来调用、需要数据来支撑、需要评测来判断好坏。

二、最小全栈架构

原型阶段不必上微服务。一个足够清晰的最小架构是：

• 前端一个页面，负责输入和展示；
• 后端一个服务，提供 /ask 接口；
• 后端内部完成“检索资料 → 拼提示词 → 调模型 → 返回答案”；
• 资料先用一段固定文本或一个小型向量库代替；
• 日志先写文件，评测先用一批固定问题人工核对。

这个架构跑通后，每一层都可以独立升级：前端换成流式组件，后端加缓存和限流，检索换成专业向量库，模型换成更合适的版本。关键是先有完整链路，再逐层优化。

三、少量代码：后端接口骨架

下面用 FastAPI 写一个精简的后端接口，演示检索、提示词组装和模型调用的编排位置。代码省略了鉴权和异常处理，只保留主干。

import os
from fastapi import FastAPI
from openai import OpenAI

app = FastAPI()
client = OpenAI(api_key=os.getenv("API_KEY"), base_url=os.getenv("BASE_URL"))

def retrieve(question: str) -> str:
    # 示例：实际应替换为向量检索或关键词检索
    return "退款审核通过后，原路退回，通常1到3个工作日到账。"

@app.post("/ask")
def ask(payload: dict):
    question = payload["question"]
    knowledge = retrieve(question)
    prompt = f"""只根据资料回答，资料不足时说“资料中没有相关信息”。
资料：{knowledge}
问题：{question}"""
    resp = client.chat.completions.create(
        model="your-model-name",
        messages=[{"role": "user", "content": prompt}],
        temperature=0.2,
    )
    return {"answer": resp.choices[0].message.content}

这段代码的价值在于展示了编排位置：检索、提示词、模型调用都发生在后端，前端不接触密钥，也不关心模型是谁。把 retrieve 换成真实检索、把返回改成流式，就是一次局部升级，不影响整体结构。

四、少量代码：前端调用片段

前端只需要一个请求和状态处理。下面是最简的调用片段：

async function ask(question) {
  setLoading(true);
  try {
    const res = await fetch("/ask", {
      method: "POST",
      headers: { "Content-Type": "application/json" },
      body: JSON.stringify({ question }),
    });
    if (!res.ok) throw new Error("请求失败");
    const data = await res.json();
    setAnswer(data.answer);
  } catch (e) {
    setAnswer("服务暂时不可用，请稍后重试");
  } finally {
    setLoading(false);
  }
}

这段代码虽短，却包含 AI 应用前端的三个必备要素：加载状态、错误兜底、结果展示。很多原型只写成功分支，一旦模型超时或接口报错，页面就白屏，这是最常见的体验问题。

五、各层要点与常见坑

前端要处理流式输出和长文本渲染。模型回答可能几十秒才结束，没有流式渲染，用户会以为卡死。同时要展示“AI 生成，仅供参考”的提示，并提供反馈入口。

后端要注意密钥管理和限流。密钥绝不能出现在前端；接口要按用户或 IP 限流，避免被刷爆；提示词组装和模型调用要设超时和重试上限。

模型层不要迷信“越大越好”。知识问答用低温度、中等规模模型往往更稳；需要结构化输出时，优先用工具调用或 JSON 模式，而不是靠提示词祈求格式正确。

数据与检索层决定了答案质量的上限。文档要清洗、切分要合理，检索结果要控制长度。检索不准，再强的模型也只能基于错误资料回答。

运维与评测层最容易被忽略。要记录每次请求的输入、检索结果、模型输出、耗时和 token 用量；要准备一批固定问题和标准答案做回归评测。没有评测，改一个提示词是变好还是变坏全靠感觉。

六、结语

AI 全栈的核心不是“什么都会”，而是知道一条完整链路里每一环负责什么、会在哪里出问题。模型只是大脑，前端是脸面，后端是神经，数据是记忆，评测是体检。本文的后端接口和前端片段加起来不过几十行，却已经串起了检索、提示词、模型调用、状态处理和错误兜底。先把这条最小链路跑通，再逐层替换和加固，比一上来追求复杂架构更可靠。AI 应用的门槛不在模型，而在把模型稳稳地放进产品里。