L2 · 主题中枢

应用构建

应用架构模型路由Prompt 工程API 集成工程实践

应用构建是 AI 能力工程化的核心环节,决定交付质量与运维成本。

4核心阶段
3关键模块
2内置知识点
先记住先定契约,再写 Prompt

明确输入输出格式与成功标准,再设计 Prompt 与路由策略,可大幅降低调试成本。

LIVE
CORE 应用构建
01 WHAT

是什么

将 AI 能力封装为可复用、可观测、可维护的应用程序的系统化方法。

02 WHY

为什么

解决从实验性 Prompt 到稳定服务的工程断层,降低调用成本与失败率,提升交付可控性。

03 HOW

怎么做

明确业务目标 → 设计架构与路由策略 → 编写并测试 Prompt → 接入模型 API → 部署与监控。

04 WHEN

什么时候

需要稳定交付 AI 能力时采用;仅做一次性探索或规则可解时不必引入完整构建流程。

THIS PAGE INCLUDES
Prompt Engineering模型路由

FOCUS

下属主题

点进去继续学

FOCUS

先记住这些

只留最重要的判断,细节见下方实践
01 独特价值

为什么需要系统化构建

避免 Prompt 碎片化、模型调用随意、错误不可追踪,提升交付一致性与可维护性。

02 复杂度

真正难在哪里

模型行为不可预测、Prompt 稳定性差、成本控制难、错误恢复机制设计复杂。

03 使用判断

什么时候用

需要长期维护、多模型协同、高可用或成本敏感时采用;一次性验证或规则可解时不必。

ROUTE

学习路径

建议按此顺序逐步深入
01
明确需求与契约

定义输入输出格式、成功标准与异常处理策略。

02
设计架构与路由

划分模块、规划数据流、选择模型与降级路径。

03
编写与测试 Prompt

使用模板化、版本控制与自动化测试验证稳定性。

04
接入 API 与部署

实现安全调用、重试机制、日志监控与灰度发布。

PROBLEM / POSITION / INTERFACE

先弄清它为什么存在,以及谁在使用

不从历史开始,从真实工作关系开始。
  1. 01 解决的问题

    当团队需要将 LLM 能力集成到产品、内部工具或自动化流程中时。

    实验性 Prompt 难以复用、模型选择随意、错误不可追踪、成本失控、交付周期长。

    成功标准
    应用具备明确输入输出契约、可观测日志、成本可控、支持迭代与回滚。
  2. 02 AI 生态位

    作为 AI 能力落地的工程载体,连接模型推理与业务逻辑。

    上游
    依赖业务需求、数据源、模型 API 与基础设施。
    下游
    为终端用户、下游系统或自动化流程提供结构化 AI 输出。
  3. 03 人的生态位

    负责需求定义、Prompt 设计、验收标准制定与异常处理策略。

    适合使用
    需要长期维护、多模型协同、高可用或成本敏感的场景。
    不必使用
    一次性验证、规则可解、或已有成熟 SaaS 替代方案时。
  4. 04 独特价值

    将 AI 能力从一次性实验转化为可复用、可观测、可迭代的工程资产。

    Prompt 稳定性、模型行为不可预测性、成本控制与错误恢复机制设计。

    复杂度判断
    复杂度不是功能数量,而是控制与验证成本。

INTERFACE FLOW

谁在操作,信息怎样流动

  1. WHO OPERATES

    HUMAN定义目标、设计 Prompt、验收结果、处理异常

    AGENT执行任务编排、调用模型、处理中间状态

    BACKEND提供 API 网关、日志、鉴权与部署环境

  2. INPUT

    用户请求、业务上下文、历史对话或结构化数据。

  3. CONTROL

    Prompt 模板、模型选择策略、温度参数、输出 Schema、重试与超时配置。

  4. OUTPUT

    结构化响应、动作指令或外部系统调用,附带元数据与追踪 ID。

FLOW

构建与迭代流程

01定义契约明确输入输出格式、成功标准与异常处理策略。
02设计架构划分模块、规划数据流、选择模型与降级路径。
03编写 Prompt使用模板化、变量注入与版本控制,确保可测试性。
04接入 API实现安全调用、重试机制、超时控制与日志记录。
05测试验证使用自动化测试集验证 Prompt 稳定性与输出一致性。
06部署监控灰度发布、指标采集、错误追踪与成本监控。

COMPARE

构建方式对比

维度系统化构建实验性调用
可维护性高:模块化、版本控制、自动化测试低:Prompt 散落、难以复用
成本控制优:路由策略、缓存、降级机制差:随意调用、成本不可控
错误处理完善:重试、超时、日志、监控薄弱:无统一异常处理
交付周期初期长,后期快初期快,后期慢

PRACTICE

最小可用构建步骤

定义输入输出契约与成功标准
选择基础模型与调用方式
编写可测试的 Prompt 模板
实现重试与超时控制
添加基础日志与监控
进行自动化测试验证
CODE / PYTHON最小调用示例
import os
from openai import OpenAI

client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))

response = client.chat.completions.create(
    model="gpt-4o-mini",
    messages=[{"role": "user", "content": "用 JSON 格式返回:{'status': 'success', 'message': 'Hello'}"}],
    temperature=0.0,
    response_format={"type": "json_object"}
)

print(response.choices[0].message.content)

Python 最短闭环:调用模型并解析结构化输出

JSON / RESPONSE典型返回结构
{
  "status": "success",
  "message": "Hello",
  "metadata": {
    "model": "gpt-4o-mini",
    "usage": {
      "prompt_tokens": 25,
      "completion_tokens": 12
    }
  }
}

FAQ

常见问题

选型、用法与失败,不复述定义。
01谁在实际负责应用构建?

工程师负责架构与集成,Prompt 工程师负责模板设计,产品经理定义成功标准。

明确分工可避免职责模糊与交付断层。
02与直接调用模型 API 有什么区别?

系统化构建包含架构设计、路由策略、错误处理与监控,而非单次调用。

决定交付质量与运维成本。
03最小可用方式是什么?

定义契约 → 选择模型 → 编写 Prompt → 调用 API → 验证输出。

帮助团队快速启动并迭代。
04生产环境最容易在哪里失败?

Prompt 不稳定、模型行为变化、无重试机制、成本失控。

决定监控重点与兜底策略。
05什么时候不需要系统化构建?

一次性验证、规则可解、或已有成熟 SaaS 替代方案时。

避免过度工程与资源浪费。