综合实战项目
核对日期：2026-05-13。
不稳定项：模型 API、前端 AI SDK、RAG 框架、Agent 框架、部署平台、评测工具和安全规范变化较快；实战项目实现前应重新核对目标技术栈官方文档。
1. 阶段目标
本阶段目标是综合运用前面所有能力，完成一个可展示、可评测、可复盘的 AI 系统项目。最终作品不是“能聊天”的 demo，而是一个能说明产品判断、系统设计、数据处理、模型调用、评测、安全、成本和生产化思考的完整工程作品。
学完本阶段，你应该能做到：
- 从真实业务场景中选择一个合适的 AI 项目。
- 明确用户、任务、成功标准、风险等级和非目标。
- 设计系统架构：数据流、控制流、模型流、审计流和回滚路径。
- 实现一个最小可用 AI 系统：RAG、Workflow 或 Agent 至少一种。
- 建立评测集、安全测试和失败样例库。
- 输出成本、延迟、token、错误和用户反馈指标。
- 完成作品集文档、演示脚本和答辩材料。
- 能解释为什么这样设计，而不是堆模型、堆框架或堆 Agent。
本阶段的核心产出是：
- 一个综合 AI 项目。
- 一份项目 README。
- 一份系统设计文档。
- 一份评测报告。
- 一份安全评审。
- 一份演示和答辩材料。
2. 学习前置条件
建议已完成：
- 阶段 01-13 全部内容。
- 至少完成过一个 Prompt 模板库。
- 至少完成过一个 RAG 或 AI 应用工程练习。
- 理解 Agent、评测、安全、LLMOps 和 AI 产品立项。
不要求：
- 一次做出企业级平台。
- 必须使用最贵或最强模型。
- 必须做多 Agent。
- 必须上线到公网。
3. 核心知识地图
4. 详细讲义
4.1 综合项目的定位
综合项目要证明你具备系统能力：
- 能选场景。
- 能做架构。
- 能接模型。
- 能处理数据。
- 能做评测。
- 能控制风险。
- 能解释成本。
- 能复盘失败。
一个合格项目可以很小，但不能只有 UI。它必须有完整闭环。
4.2 项目分级
| 等级 | 特征 | 适合 |
|---|---|---|
| L1 练习级 | 单 Prompt 或单模型调用 | 初学验证 |
| L2 应用级 | 有前后端、结构化输出、日志 | AI 应用工程 |
| L3 RAG 级 | 有文档导入、检索、引用、拒答 | 知识系统 |
| L4 Agent 级 | 有工具、状态、HITL、轨迹评测 | 多步任务 |
| L5 生产化级 | 有评测、安全、成本、灰度、回滚 | 作品集/真实落地 |
课程最终建议做到 L4-L5 之间：不一定公网生产上线，但要有生产化思考。
4.3 项目选题标准
好选题满足：
- 用户和任务明确。
- 数据能获得。
- 输出可验证。
- 有失败样例。
- 能展示系统设计。
- 风险可控。
- 能在 1-3 周内完成 MVP。
不建议：
- 通用聊天机器人。
- 没有知识源的“万能助手”。
- 自动交易、医疗诊断、法律结论等高风险项目。
- 只能展示模型回答，不能说明评测和系统边界的项目。
4.4 推荐项目方向
方向 A：企业知识库问答系统
能力覆盖：
- RAG。
- 引用。
- 拒答。
- 权限。
- 评测。
- 前端体验。
适合展示：知识系统、检索质量、引用和 groundedness。
方向 B：代码库分析 Agent
能力覆盖：
- 代码搜索。
- 文件读取。
- Agent loop。
- 只读工具权限。
- 文件引用。
- 轨迹评测。
适合展示：Agent 设计、工具 schema、控制流和安全边界。
方向 C：客服工单辅助 Agent
能力覆盖：
- 工单分类。
- 知识库检索。
- 回复草稿。
- 人工确认。
- 安全和审计。
适合展示：产品落地、HITL、业务流程和 ROI。
方向 D：数据分析助手
能力覆盖：
- 指标字典。
- SQL 草稿。
- 只读执行。
- 图表和解释。
- 数据权限。
适合展示：工具调用、数据安全和可验证输出。
方向 E：研究报告生成系统
能力覆盖：
- 资料检索。
- 来源引用。
- 大纲生成。
- 事实核对。
- 报告生成。
适合展示：长任务、引用管理和多步骤 Workflow。
4.5 项目设计原则
| 原则 | 说明 |
|---|---|
| 先窄后深 | 选小场景，做完整链路 |
| 人类可控 | 高风险输出人工确认 |
| 证据优先 | 关键结论有来源 |
| 失败可见 | 展示失败类型和复盘 |
| 成本可算 | 记录 token、延迟和调用成本 |
| 安全可审 | 权限、日志和边界清楚 |
| 评测驱动 | 用 eval 决定改进 |
4.6 系统架构必须包含什么
综合项目架构至少包含：
- 用户入口：Web、CLI、Bot 或内部工具。
- 应用 API：鉴权、任务管理、请求处理。
- Prompt / Context Builder。
- 模型调用层。
- RAG 或工具层。
- 存储：会话、任务、评测、日志。
- 可观测：trace、token、成本、延迟。
- 安全：权限、脱敏、审批。
- 评测：离线评测集和结果。
推荐架构图：
4.7 README 应该怎么写
项目 README 是作品集入口，必须让评审者快速理解。
结构：
# 项目名称
## 1. 一句话介绍
## 2. 解决的问题
## 3. 核心功能
## 4. 系统架构
## 5. 技术栈
## 6. 运行方式
## 7. Demo 流程
## 8. 评测结果
## 9. 安全和成本
## 10. 已知限制
## 11. 下一步计划
README 不要只写安装命令，也不要只放截图。要展示你的系统思考。
4.8 需求文档
需求文档回答：
- 谁使用。
- 解决什么任务。
- 当前怎么做。
- AI 帮助哪一步。
- 成功标准是什么。
- 不做什么。
- 风险是什么。
需求文档模板：
# 项目需求文档
## 1. 用户画像
## 2. 当前流程
## 3. 痛点
## 4. AI 介入点
## 5. MVP 范围
## 6. 非目标
## 7. 成功指标
## 8. 风险和边界
4.9 评测集设计
综合项目至少 30 条 eval：
| 类型 | 数量建议 |
|---|---|
| 正常样例 | 12 |
| 边界样例 | 6 |
| 缺信息/拒答 | 4 |
| 安全负例 | 4 |
| 历史失败/人工构造失败 | 4 |
每条样例包含：
- id。
- 输入。
- 期望行为。
- 必须引用或工具。
- 是否拒答。
- 风险等级。
- 标签。
- 评分结果。
4.10 评测报告
评测报告必须包含：
- 被测版本。
- 模型和 Prompt 版本。
- 数据集版本。
- 总体通过率。
- 分类型指标。
- 成本和延迟。
- 失败样例。
- 根因分析。
- 下一步改进。
不要只报一个准确率。要说明系统失败在哪里。
4.11 安全评审
综合项目必须做安全评审，即使只是本地 demo。
至少覆盖：
- 信任边界。
- 数据分类。
- 权限模型。
- RAG 文档污染。
- Prompt injection。
- 工具越权。
- 输出处理。
- 日志脱敏。
- 人工确认。
- 回滚和停用。
4.12 成本和性能分析
记录：
- 平均 input tokens。
- 平均 output tokens。
- 平均延迟。
- 首 token 延迟。
- RAG 检索耗时。
- 工具调用耗时。
- 单任务估算成本。
- 高成本样例。
成本分析不是为了省到最低，而是证明你知道系统上线后的资源画像。
4.13 失败样例库
失败样例库字段：
| 字段 | 说明 |
|---|---|
| id | 失败样例 ID |
| input | 输入 |
| output | 实际输出 |
| expected | 期望行为 |
| category | 失败类别 |
| root_cause | 根因 |
| fix | 修复方案 |
| regression | 是否进入回归集 |
失败样例比成功 demo 更能证明工程能力。
4.14 答辩材料
答辩时重点讲：
- 为什么选这个场景。
- 为什么选择当前技术方案。
- 系统怎么工作。
- 如何评测。
- 失败在哪里。
- 如何控制安全风险。
- 成本和延迟如何。
- 如果上线还缺什么。
不要只演示“问一句答一句”。要展示你对系统边界的掌握。
4.15 项目计划
建议 3 周计划：
| 周期 | 目标 | 产出 |
|---|---|---|
| 第 1 周 | 场景和设计 | PRD、架构图、eval 初版 |
| 第 2 周 | MVP 实现 | RAG/Workflow/Agent、基础 UI、日志 |
| 第 3 周 | 评测和完善 | 评测报告、安全评审、README、演示 |
如果时间只有 3-5 天，缩小范围，不要牺牲评测和安全文档。
5. 关键概念表
| 概念 | 含义 | 验收方式 | 常见问题 |
|---|---|---|---|
| Capstone | 综合作品项目 | 功能、文档、评测齐全 | 只有 demo |
| PRD | 需求文档 | 用户、场景、指标清楚 | 范围太大 |
| Architecture doc | 架构文档 | 数据流、控制流、风险清楚 | 只画 UI |
| Eval report | 评测报告 | 指标、失败、改进完整 | 只报准确率 |
| Security review | 安全评审 | 信任边界和权限清楚 | 上线后再补 |
| Cost report | 成本报告 | token、延迟、单任务成本 | 无观测 |
| Failure library | 失败样例库 | 可复盘、可回归 | 只展示成功 |
| Demo script | 演示脚本 | 能稳定展示核心价值 | 临场随意 |
| Portfolio | 作品集 | 体现系统能力 | 只堆技术名词 |
6. 工程案例
6.1 企业知识库问答系统
功能：
- 文档导入。
- chunk 和 embedding。
- 混合检索。
- 带引用回答。
- 证据不足拒答。
- 用户反馈。
验收：
- recall@5。
- 引用支持率。
- 拒答准确率。
- 平均延迟。
- 单次成本。
6.2 代码库分析 Agent
功能：
- 搜索文件。
- 读取代码。
- 分析调用链。
- 输出风险和引用。
- 只读权限。
验收：
- 是否定位正确文件。
- 是否引用真实路径。
- 是否避免越权写入。
- 工具轨迹是否合理。
6.3 客服工单辅助 Agent
功能：
- 工单分类。
- 知识库检索。
- 回复草稿。
- 人工确认。
- 审计记录。
验收：
- 分类准确率。
- 草稿采纳率。
- 错误承诺率。
- 高风险工单升级率。
6.4 数据分析助手
功能：
- 读取指标字典。
- 生成 SQL 草稿。
- 只读执行。
- 输出图表和解释。
- 保存查询和结果。
验收：
- SQL 正确率。
- 指标口径一致性。
- 查询安全。
- 结论是否被数据支持。
6.5 研究报告生成系统
功能：
- 资料搜索。
- 来源筛选。
- 大纲生成。
- 引用管理。
- 报告生成。
验收：
- 来源权威性。
- 引用覆盖。
- 事实错误率。
- 信息核对日期。
7. 常见误区与反模式
| 反模式 | 表现 | 后果 | 修正 |
|---|---|---|---|
| 只做聊天框 | 没有业务流程 | 无法体现能力 | 选真实任务 |
| 没有评测 | 凭感觉说好 | 不可信 | 建 eval 集 |
| 没有失败样例 | 只展示成功 | 无法复盘 | 建失败库 |
| 强行用 Agent | 固定流程也做自主 Agent | 成本高、风险大 | 用 Workflow |
| 无安全评审 | 不考虑越权和泄漏 | 不能上线 | 做信任边界 |
| 无成本分析 | 不记录 token | 无法运营 | 建成本账本 |
| 文档太薄 | 只写运行命令 | 评审看不懂设计 | 写架构和报告 |
| 演示不可复现 | 临场依赖随机输出 | 容易翻车 | 固定 demo 样例 |
| 技术栈堆砌 | 名词很多但链路不清 | 显得不专业 | 解释取舍 |
8. 阶段练习
8.1 项目需求文档
写一份 PRD，包含：
- 用户。
- 当前流程。
- 痛点。
- AI 介入点。
- MVP。
- 非目标。
- 成功指标。
8.2 架构图
画出：
- 数据流。
- 控制流。
- 模型调用流。
- 权限和审计流。
- 失败回滚路径。
8.3 评测集
设计 30 条 eval，覆盖：
- 正常。
- 边界。
- 拒答。
- 安全。
- 历史失败。
8.4 安全评审
完成一份安全评审：
- 信任边界。
- 数据分类。
- 工具权限。
- prompt injection。
- 日志和缓存。
- 人工确认。
8.5 作品集答辩
准备 10 分钟答辩：
- 2 分钟场景和价值。
- 3 分钟架构和核心功能。
- 2 分钟评测和失败。
- 2 分钟安全和生产化。
- 1 分钟下一步。
9. 项目任务
9.1 项目要求
完成一个综合 AI 项目。
必须提交：
README.md。docs/requirements.md。docs/architecture.md。docs/evaluation.md。docs/security-review.md。docs/cost-and-ops.md。evals/评测样例。examples/演示输入输出。- 可运行代码或清晰伪代码。
- 演示脚本或录屏说明。
可直接复用本阶段提供的 项目脚手架，其中已包含需求、架构、评测、安全、成本、Prompt、演示和实现目录模板。
如果你想先看一份填好的作品集样例，可以阅读 示例项目：企业知识库问答系统。它用合成企业知识库场景演示需求、架构、评测、安全、成本和演示材料如何组织。
9.2 最低功能要求
至少满足一种：
- RAG 系统：文档导入、检索、引用、拒答、评测。
- Workflow 系统：多步骤任务、结构化输出、校验、日志。
- Agent 系统：工具、状态、最大步数、HITL、轨迹评测。
同时必须包含：
- Prompt 版本。
- 模型调用日志。
- 失败处理。
- 安全负例。
- 成本估算。
9.3 最终评分 Rubric
| 维度 | 分值 | 标准 |
|---|---|---|
| 场景和产品判断 | 15 | 用户、任务、价值、非目标清晰 |
| 系统架构 | 20 | 数据流、控制流、模型流、权限流完整 |
| 功能实现 | 15 | MVP 能完成真实任务 |
| 评测体系 | 20 | eval、指标、失败样例和报告完整 |
| 安全治理 | 15 | 信任边界、权限、注入、日志、回滚清楚 |
| 生产化思考 | 10 | 成本、延迟、监控、灰度和运维明确 |
| 表达和答辩 | 5 | 文档清楚，演示可复现，取舍讲得明白 |
9.4 加分项
- 有真实用户反馈。
- 有自动化评测脚本。
- 有 trace 可视化。
- 有多模型路由对比。
- 有失败样例复盘。
- 有清晰 ROI 测算。
- 有可部署版本。
10. 验收题
- 你的项目为什么需要 AI，而不是普通规则或传统软件？
- 目标用户是谁，任务是什么？
- 你为什么选择 RAG、Workflow 或 Agent？
- 你的系统成功标准是什么？
- 你的评测集覆盖了哪些正常、边界和安全样例？
- 你的失败样例说明了什么？
- 安全边界在哪里，哪些动作需要人工确认？
- 如果模型输出错误，用户如何发现和回退？
- 如果上线，如何监控成本、延迟和质量？
- 下一步最值得改进的 3 件事是什么？
11. 延伸阅读
综合资料
- OpenAI Evals guide: https://developers.openai.com/api/docs/guides/evals
- Anthropic Building effective agents: https://www.anthropic.com/engineering/building-effective-agents
- OWASP Top 10 for LLM Applications: https://genai.owasp.org/llm-top-10/
- OpenTelemetry Documentation: https://opentelemetry.io/docs/
- Google People + AI Guidebook: https://pair.withgoogle.com/guidebook/
建议阅读方式
- 回看阶段 07、09、10、11、12，把 RAG、Agent、评测、安全和 LLMOps 合并进项目文档。
- 不要等实现完成才写评测和安全，它们应该从设计阶段就存在。
- 用失败样例驱动项目成熟，而不是只优化演示样例。
12. 本阶段总结
综合项目是这套课程的最终验收。它考察的不是你会不会调用模型，而是你能不能把 AI 能力放进真实系统：有场景、有架构、有数据、有评测、有安全、有成本、有复盘。
一个强作品集项目应该能让评审者看到：你知道 AI 能做什么，也知道 AI 不能做什么；你能做出 demo，也能解释上线前还缺什么；你不仅追求模型输出，更追求系统可靠。