30 天完整教学大纲

本大纲是「AI FDE 实战训练》的完整地图，落实到每天学什么、做什么实验、交付什么、如何验收。 它不等于逐日任务包——任务包会在进入每一天前单独生成（含完整原理、代码、步骤、测试）。 计划是动态的：根据真实进度调整，不机械执行日历。

总目标

30 天后能独立完成一个中小型企业内部 AI 应用的：需求分析 → 方案设计 → 基础开发 → 部署 → 测试 → 排障 → 模拟交付。 以 PoC 完成 + 部分 Pilot 能力 为目标，不宣称生产上线标准。

• 学习周期：30 天
• 每日投入：2–3 小时
• 总投入：约 60–90 小时

能力优先级

• P0（必须掌握）：Python/API、LLM 调用、RAG 闭环、基础 Agent 工具调用、测试与异常、Docker 部署、客户需求与交付文档
• P1（按时间调整）：数据库集成、检索优化、监控
• P2（默认不占核心时间）：模型微调、Kubernetes、GPU 推理、复杂多 Agent

---

第一周：环境与 LLM 基础

第 1 天 · 环境诊断与工作台落地

• 目标：确认自己服务器的真实状态，把工作台目录在你服务器上重建。
• 原理：为何要分清「导师沙箱」与「学习者环境」；不伪造执行结果。
• 实验：跑环境检查命令，回填 environment-report.md；重建 ~/ai-fde-lab/ 目录；建 Python venv。
• 成果：可用的开发环境 + 环境报告。
• 验收：python3/pip/git 版本可查，venv 可激活，目录结构符合规范。

第 2 天 · Python + HTTP 基础补强

• 目标：用 Python 调用 HTTP API，处理 JSON、超时、异常、状态码。
• 原理：HTTP 请求/响应模型、状态码语义、认证方式、超时与重试。
• 实验：用 httpx 请求一个公开 API，处理超时与错误响应，输出结构化结果。
• 成果：projects/llm-api-demo/ 下的 http 调用脚本。
• 验收：脚本能区分 200/4xx/5xx/超时，异常有清晰提示。

第 3 天 · FastAPI 服务基础

• 目标：搭建第一个 FastAPI 服务，理解路由、Pydantic 校验、日志。
• 原理：同步/异步接口、请求体校验、依赖注入雏形、uvicorn 运行。
• 实验：写带 Pydantic 模型的接口，用 curl 与 Swagger 验证。
• 成果：可运行的 FastAPI 服务（含 /health 与一个 POST 接口）。
• 验收：/docs 可访问，非法入参返回 422，日志可查。

第 4 天 · 调用第一个 LLM API

• 目标：用 Python 完成一次真实的 LLM 调用，理解入参与返回结构。
• 原理：OpenAI 兼容协议的 messages 结构、API Key、base_url、temperature、max_tokens。
• 实验：写最小可运行 LLM 调用代码，用环境变量注入 Key。
• 成果：projects/llm-api-demo/ 的 call_llm.py。
• 验收：真实返回一段文本；Key 未硬编码、未提交 Git。

第 5 天 · Prompt 与结构化输出

• 目标：掌握 Prompt 设计的基本方法，让模型输出稳定、可解析的结构化结果。
• 原理：角色/指令/上下文/输出格式划分；response_format/JSON 输出约束。
• 实验：设计 Prompt 让模型输出 JSON，用 Pydantic 校验解析结果。
• 成果：结构化输出脚本 + 若干 Prompt 对比。
• 验收：模型输出能被稳定解析为预设字段。

第 6 天 · 异常、Token 与成本

• 目标：处理 LLM 调用的各类异常，理解 Token 计费与成本控制。
• 原理：限流(429)、鉴权失败(401)、超时、上下文长度；token 计量与预算。
• 实验：模拟错误 Key、超时、限流，写重试与降级逻辑；统计一次调用的 token 消耗。
• 成果：健壮的 LLM 客户端封装 + 成本记录。
• 验收：各类异常有明确处理；能解释一次调用花了多少 token、约多少钱。

---

第二周：RAG 实战

第 7 天 · RAG 原理与文档解析

• 目标：理解 RAG 数据流，完成 Markdown/TXT 文档读取与清洗。
• 原理：RAG 五步（解析→切分→向量化→检索→生成）；文档格式与编码处理。
• 实验：读取样例文档、去除噪音、归一化文本。
• 成果：rag-assistant/ 的文档加载模块。
• 验收：能正确读取样例文档并输出干净文本。

第 8 天 · 文档切分

• 目标：把文档切成适合检索的 chunk，理解切分策略。
• 原理：固定长度 vs 语义切分；chunk_size、chunk_overlap 的作用。
• 实验：实现基础切分器，调参观察切分结果。
• 成果：切分模块 + 参数实验记录。
• 验收：能解释切分参数对结果的影响。

第 9 天 · Embedding 与向量化

• 目标：调用 Embedding API 把 chunk 转成向量。
• 原理：向量语义相似度；external Embedding API 优先（符合 4C4G 约束）。
• 实验：调用 Embedding API，计算两个向量的余弦相似度。
• 成果：Embedding 调用 + 相似度计算函数。
• 验收：语义相近的句子相似度高，不相关的低。

第 10 天 · 向量检索（轻量存储）

• 目标：用轻量方式实现近似向量检索（先用内存/JSON，不引入重型向量库）。
• 原理：暴力最近邻、余弦相似度排序、top-k。
• 实验：构建索引、检索 top-k、返回来源。
• 成果：最小 RAG 检索闭环。
• 验收：已知问题能检索到相关 chunk。

第 11 天 · 生成回答 + 引用来源

• 目标：把检索结果喂给 LLM，生成带引用的回答。
• 原理：context 组装、prompt 模板、引用标注。
• 实验：实现「检索→组装→生成→标注引用」完整链路。
• 成果：可用命令行互动的 RAG 问答。
• 验收：回答有依据、能返回引用；无答案时说明不确定。

第 12 天 · RAG 测试（8 个用例）

• 目标：用规范测试集验证 RAG 质量。
• 原理：测试用例规范（编号/步骤/预期/结果/状态）。
• 实验：执行 RAG-01~08（文档导入、检索、引用、未知问题、空文档、超时、重复导入、参数调整）。
• 成果：测试报告。
• 验收：核心用例通过，失败项有分析与修正记录。

第 13 天 · 阶段复盘与 PostgreSQL/pgvector 评估

• 目标：评估是否引入 PostgreSQL + pgvector，理解数据库集成成本。
• 原理：持久化、索引、连接数与内存（4C4G 约束）。
• 实验：评估轻量存储 vs pgvector 的取舍，输出选型结论。
• 成果：RAG 阶段复盘 + 存储选型说明。
• 验收：能解释是否值得现在引入数据库及原因。

---

第三周：Agent 实战

第 14 天 · Agent 与工具调用原理

• 目标：理解 Agent 的「思考-调用-观察」循环与 function calling 机制。
• 原理：工具定义、tool_calls、参数传递、多轮循环。
• 实验：定义第一个工具，让模型发起工具调用。
• 成果：可发起工具调用的最小 Agent。
• 验收：模型能正确识别并调用工具、传递参数。

第 15 天 · 业务 API 与工具封装

• 目标：把业务功能封装成可被 Agent 调用的工具（模拟企业内部 API）。
• 原理：工具 schema 设计、参数校验、返回结构化结果。
• 实验：实现一个查询/操作类的业务工具。
• 成果：enterprise-ai-assistant/ 的业务工具模块。
• 验收：工具可独立测试、参数校验有效。

第 16 天 · 工具调用失败处理

• 目标：处理工具调用失败、参数错误、超时等异常。
• 原理：错误返回给模型、让模型重试或降级。
• 实验：模拟失败场景，完善错误处理与反馈循环。
• 成果：健壮的 Agent 工具调用闭环。
• 验收：失败场景能被正确识别并合理处理。

第 17 天 · 简单工作流

• 目标：把多个工具串联成一个业务流程。
• 原理：固定流程 vs 模型自主决策；状态流转。
• 实验：实现一个「查询→判断→执行」的简单工作流。
• 成果：可运行的多工具业务助手。
• 验收：端到端流程可走通，结果可解释。

第 18 天 · Agent 阶段复盘

• 目标：总结 Agent 能力，评估是否引入 Agent 框架。
• 原理：原生工具调用 vs 框架（LangChain 等）的取舍。
• 实验：对比手写与框架的成本/复杂度。
• 成果：Agent 复盘 + 选型说明。
• 验收：能解释为何优先原生工具调用。

---

第四周：Eval、部署与交付

第 19 天 · 测试集设计

• 目标：为贯穿项目建立规范测试集。
• 原理：四层测试（知识理解/独立操作/功能/故障）；测试用例规范。
• 实验：设计覆盖正常/异常/边界的测试集。
• 成果：datasets/evaluation/ 测试集。
• 验收：用例可复现、预期结果明确。

第 20 天 · 检索与回答评估

• 目标：量化评估检索准确率与回答质量。
• 原理：检索命中率、回答是否有据、引用是否准确。
• 实验：跑评估，产出指标。
• 成果：评估报告。
• 验收：能解释指标含义与改进方向。

第 21 天 · 权限与安全

• 目标：识别并处理越权、注入、数据泄露风险。
• 原理：越权请求、Prompt 注入、密钥管理、日志脱敏。
• 实验：模拟越权与注入场景，加防护。
• 成果：安全风险分析 + 防护措施。
• 验收：模拟攻击被拦截或有合理解释。

第 22 天 · Eval/安全阶段复盘

• 目标：汇总质量与安全结论。
• 原理：测试失败根因分类与修正。
• 实验：整理失败项、回归测试。
• 成果：测试与安全报告。
• 验收：失败项已闭环或有明确 TODO。

第 23 天 · Docker 部署 1（单服务）

• 目标：把 FastAPI 服务容器化。
• 原理：镜像、Dockerfile、端口映射、健康检查。
• 实验：写 Dockerfile，构建并运行容器。
• 成果：可运行的单容器服务。
• 验收：容器能启动，/health 可访问。

第 24 天 · Docker Compose 多服务

• 目标：用 Compose 编排应用 + 数据库，配置资源限制。
• 原理：Compose 服务、网络、卷、deploy.resources（4C4G 限制）。
• 实验：编排 FastAPI + PostgreSQL，设置内存/CPU 限制。
• 成果：可一键启动的多服务项目。
• 验收：Compose 一键启动，资源占用在限制内。

第 25 天 · 日志、监控与资源

• 目标：建立日志与资源监测方法，理解 4C4G 约束。
• 原理：logging 规范、docker stats、内存/CPU 观测。
• 实验：加日志，记录服务资源占用，识别瓶颈。
• 成果：日志体系 + 资源监测记录。
• 验收：能定位资源占用来源并给出优化。

第 26 天 · 部署阶段复盘

• 目标：验证部署完整性，做故障演练。
• 原理：健康检查、故障恢复、配置与密钥管理。
• 实验：模拟服务中断与恢复，验证配置管理。
• 成果：部署说明 + 故障排查记录。
• 验收：项目可重复部署、可恢复。

第 27 天 · 需求分析与方案设计

• 目标：以模拟客户场景完成需求分析与技术方案。
• 原理：DDDR（Discover/Design/Deploy/Review）流程。
• 实验：模拟客户访谈，产出需求与方案。
• 成果：项目技术方案文档。
• 验收：方案覆盖业务问题、边界、成本、风险。

第 28 天 · 演示准备与验收标准

• 目标：准备可演示的完整作品与验收标准。
• 原理：演示脚本、验收清单。
• 实验：整理演示流程，定义验收项。
• 成果：演示脚本 + 验收清单。
• 验收：演示可完整跑通核心功能。

第 29 天 · 作品集与文档沉淀

• 目标：产出完整交付文档与作品集。
• 原理：README、架构图、RAG/Agent 说明、测试、安全、排障。
• 实验：补齐全部交付材料。
• 成果：完整交付作品集。
• 验收：作品集覆盖 §14.4 要求的全部项。

第 30 天 · 项目验收与个人复盘

• 目标：整体验收，个人能力复盘与后续规划。
• 原理：三维能力模型（技术交付/客户组织/产品复用）。
• 实验：对照能力模型自评，标出证据与待验证项。
• 成果：最终复盘 + 能力证据清单。
• 验收：核心能力有证据支撑，待验证项明确。

---

一张图看全流程

第1周 环境+LLM基础 → 第2周 RAG → 第3周 Agent → 第4周 Eval+部署+交付
        │                │           │               │
     llm-api-demo      rag-assistant  enterprise-ai  贯穿项目交付
        └────────────────┴───────────┴───────────────┘
                    贯穿式项目：企业内部知识库与业务助手

调整规则（速查）

• 测试通过 → 记录证据 → 进入下一模块
• 部分通过 → 找薄弱点 → 补材料 → 重测
• 测试失败 → 分析根因 → 优先解决阻塞 → 必要时降低难度/拆分
• 无法验证 → 补运行结果/代码/测试数据；环境不可用则给替代方法
• 时间不足降级：保留 Python/API、LLM、RAG 闭环、基础 Agent、测试异常、Docker、需求交付文档；压缩高级检索、复杂框架、监控、K8s、微调

状态

• 当前进度：第 0 天（工作台搭建 + 大纲完成）
• 下一动作：待学习者提交能力诊断 + 环境回填后，生成第 1 天任务包