AI 工程的生产交付正从 "能跑起来" 向 "能可靠地跑在别人的环境里" 演进。开源课程 ai-engineering-from-scratch 通过 20 个阶段、435 个课程的系统化设计，将 "Ship it for others" 作为核心交付理念 —— 每个课程结束必须产出可复用的 artifact（prompt、skill、agent 或 MCP server）。本文聚焦该课程在 Phase 17（Infrastructure & Production）阶段的生产工程实践，分析从本地开发到生产环境的容器化与 CI/CD 流程设计策略。
一、交付哲学：从 "Build It" 到 "Ship It" 的闭环设计
该课程采用六步教学法：MOTTO（核心理念）→ PROBLEM（具体问题）→ CONCEPT（原理图解）→ BUILD IT（从零实现）→ USE IT（框架应用）→ SHIP IT（交付产出）。这一结构强制要求每个技术点都必须回答 "如何在生产环境中交付"。
在 SHIP IT 阶段，课程要求产出四类可交付物：可直接粘贴到 AI 助手的 prompt 模板、可安装到 Claude/Cursor 等 agent 的 SKILL.md 文件、可独立运行的 agent 实现，以及符合 MCP 协议的服务端。这种设计迫使学习者在编码阶段就考虑接口契约、版本兼容与部署边界。
二、容器化策略：多语言运行时与 GPU 环境隔离
Phase 0 的 Docker for AI 课程（Lesson 07）将容器化置于学习路径的起点，而非终点。课程要求同时支持 Python、TypeScript、Rust、Julia 四种语言环境的容器化配置，这反映了 AI 工程的多语言特性 ——Python 用于模型训练与推理，TypeScript 用于前端与工具链，Rust 用于高性能边缘部署，Julia 用于数学原型验证。
生产环境的容器化策略在 Phase 17 进一步细化。GPU Autoscaling on Kubernetes 课程（Lesson 03）涵盖 Karpenter 与 KAI Scheduler 的配置，解决 GPU 资源的动态调度问题。vLLM Serving Internals 课程（Lesson 04）则深入 PagedAttention 与 Continuous Batching 的容器化部署参数，包括显存分配策略与批处理阈值。这种分层设计确保开发者理解 "为什么这样配置"，而非简单复制 Dockerfile。
三、渐进式部署：Shadow、Canary 与 A/B 测试
课程在 Phase 17 专门设置三个连续课程处理部署策略。Shadow Deployment 课程（Lesson 20）教授如何将生产流量镜像到新版服务进行验证，而不影响真实用户响应。Canary Deployment 课程则关注流量切分的数学模型 —— 如何根据延迟分布与错误率动态调整金丝雀流量比例。
A/B Testing LLM Features 课程（Lesson 21）引入 GrowthBook 与 Statsig 作为实验平台，强调 LLM 应用的 A/B 测试特殊性：需要同时跟踪业务指标（转化率）与模型指标（幻觉率、响应长度）。课程建议将 prompt 版本作为实验维度，而非仅调整模型参数，这体现了 AI 工程与传统软件 A/B 测试的关键差异。
四、可观测性体系：从指标到 FinOps
Inference Metrics 课程（Lesson 08）定义了 LLM 服务的核心 SLI：TTFT（Time To First Token）、TPOT（Time Per Output Token）、ITL（Inter-Token Latency）、Goodput（有效吞吐量）与 P99 延迟。这些指标构成生产监控的基础维度。
LLM Observability 课程（Lesson 13）进一步要求建立完整的可观测性栈，包括 prompt/response 日志、token 消耗追踪与成本归因。FinOps for LLMs 课程（Lesson 27）将监控上升到经济层面，教授多租户场景下的成本分摊模型与单位经济学计算。这种从技术指标到商业指标的完整链路，是 AI 工程生产化的关键门槛。
五、CI/CD 流水线：从代码到 Catalog 的自动化
课程仓库通过 scripts 目录提供完整的交付工具链。lesson_run.py执行语法检查与冒烟测试，build_catalog.py生成课程目录的 JSON 表示，install_skills.py支持按 phase 或 tag 筛选安装 skill 到指定 agent 环境。.github/workflows/curriculum.yml定义 CI 流程：每次 PR 重建 catalog.json 并验证课程结构合规性。
这种设计体现了 AI 工程的 CI/CD 特殊性 —— 不仅需要验证代码正确性，还需验证 artifact 的可安装性与接口契约。Agent Workbench 的脚手架工具（scaffold_workbench.py）进一步支持将课程模板应用到任意代码仓库，实现 "开发即交付" 的流程整合。
六、生产运行时：Durable Execution 与故障恢复
Phase 14 的 Production Runtimes 课程（Lesson 29）针对 Agent 工程的生产特性，引入 Queue、Event、Cron 三种运行时模式。课程强调长周期 Agent 任务需要 durable execution 支持 —— 通过 checkpoint 机制在节点故障时恢复状态，通过 scope contract 定义任务边界，通过 verification gate 确保输出质量。
这种设计与传统微服务的 "无状态" 假设形成对比。AI Agent 可能执行数小时甚至数天的任务（如代码迁移、研究分析），因此需要显式的状态管理、人工介入点（HITL: Propose-Then-Commit）与回滚机制（Checkpoint and Rollback）。
七、安全与合规：从 Secret 到 AI Act
Security 课程（Lesson 25）覆盖 Secret 管理、PII 脱敏与审计日志，Compliance 课程（Lesson 26）则涉及 SOC 2、HIPAA、GDPR 与 EU AI Act 的合规要求。课程特别强调 AI 系统的特殊风险：模型权重泄露、训练数据溯源、生成内容的版权归属。
这种合规前置的设计反映了 2026 年 AI 工程的监管环境变化。课程要求每个 capstone 项目必须包含合规检查清单，将安全从 "上线前的检查项" 转变为 "设计时的约束条件"。
总结
ai-engineering-from-scratch 的生产交付实践表明，AI 工程的生产化需要重构传统 DevOps 的多个假设：从无状态服务到 durable execution、从单一语言到多语言运行时、从代码交付到 artifact 交付。其核心价值在于将 "Ship it for others" 内化为每个技术决策的约束条件 —— 如果无法在他人环境中可靠运行，则技术实现不完整。这种工程思维的转变，是 AI 从实验室走向产业的关键桥梁。
资料来源
- ai-engineering-from-scratch GitHub 仓库: https://github.com/rohitg00/ai-engineering-from-scratch
- Phase 17: Infrastructure & Production 课程目录
内容声明：本文无广告投放、无付费植入。
如有事实性问题，欢迎发送勘误至 i@hotdrydog.com。