51. AI 应用作品集：把学习项目变成可验证的求职证据

本章目标：将已经学过的 FastAPI、RAG、Agent、评估、观测、Docker 和前端整合为一个可以演示、可以解释、可以复现的作品，而不是一长串“我学过的库”。

课程主线#

项目当前状态	本章新增能力	复用的旧知识	新知识	验收证据	后续方向
`study-python` 已有认证、RAG、Agent、Dify、多模态、测试和部署章节	用产品场景、架构图、README、演示和指标证明能力	本项目所有已完成章节	作品叙事、验收清单、演示脚本、STAR 项目表达	陌生人按 README 能运行、测试、提问并看到引用	投递、面试、按岗位选择进阶选修

一句话心智模型#

作品集不是“代码仓库链接”，而是一条别人能复查的证据链：问题是什么、系统怎么做、为什么这样设计、它如何被验证、你如何处理失败。

1
真实业务问题
2
  -> 功能边界
3
  -> 架构与数据流
4
  -> 可运行演示
5
  -> 测试 / 评估 / 日志
6
  -> Docker / CI / 部署说明
7
  -> 你能亲口解释的取舍

先确定一个贯穿产品#

不要将 Todo、单独 RAG、Dify Demo 和语音 Demo 拆成四个小作品。你的主作品建议是：

个人 / 团队知识库 AI 助手：登录后上传资料，系统切片并建立索引；用户可进行流式问答、看到引用来源；Agent 可调用受控检索工具；可选语音输入输出；系统记录评估和关键运行日志。

它能自然承载你项目里的能力：

用户看见的功能	你能对应讲出的实现
登录后进入自己的知识库	JWT、用户 ID、服务端权限 filter
上传与管理资料	FastAPI、Pydantic、SQLAlchemy、Alembic
有引用的知识问答	Chunk、Embedding、Qdrant / Chroma、RAG Prompt、SSE
“帮我查资料再回答”	Tool Calling、LangGraph、MCP Tool
语音提问	STT -> RAG -> TTS 多模态链路
看到响应慢或失败原因	结构化日志、trace、timeout、retry
每次改 Prompt / 索引可回归验证	pytest、evaluation cases、CI

你不需要在第一版同时启用每个功能。最小作品必须先完成“登录 -> 上传 -> 有权限的检索 -> 有引用的流式回答 -> 测试 -> Docker”；语音和 Agent 是第二个演示亮点。

第 1 关：README 必须回答的六件事#

把仓库首页当作给面试官的 90 秒导览，而不是安装命令仓库。它至少应有：

1
# 项目名称与一句话价值
2

3
## 解决的问题
4
谁在什么场景下，因为何种信息分散而需要它？
5

6
## 功能边界
7
已支持什么；明确不支持什么。
8

9
## 架构图与一次请求的数据流
10
浏览器 -> FastAPI -> PostgreSQL / Qdrant -> LLM -> SSE
11

12
## 本地运行
13
cp .env.example .env
14
podman compose up --build
15

16
## 验证
17
pytest、示例问题、预期引用、截图或录屏。
18

19
## 工程取舍
20
为什么向量库和关系库分开？为什么先做确定性评估？如何避免越权检索？

“能启动”不等于“能解释”。README 必须写清楚你有意没有做的事情，例如：当前只支持文本文件、不支持跨租户共享、生产 OAuth 暂未实现。诚实的边界会让设计更可信。

第 2 关：做一个可重复的演示脚本#

演示不要临场想问题。准备 5 分钟固定脚本，每一次都能复现：

登录用户 A，上传一份带明确事实的文档。
提问该事实，展示流式回答和引用的 chunk 标题。
切换用户 B，重复问题，展示 B 看不到 A 的资料。
展示一条评估 case：将错误来源或错误事实改掉，测试应失败。
展示一条 trace / 日志：一次请求的检索耗时、上游失败或重试。
在终端运行 podman compose up --build 或展示 CI 绿灯，证明它不是只在你的电脑能跑。

每一步都有可观察结果。你在面试中讲的是“我如何证明它正确且受控”，不是“模型恰好回答对了一次”。

第 3 关：项目讲解的 STAR 结构#

STAR 是一种项目表达结构，不是代码框架：

部分	你要说什么	本项目的示例
Situation（情境）	为什么需要它	学习资料和个人资料难检索，普通聊天模型会编造
Task（任务）	你负责交付什么	做一个有登录隔离、引用和流式返回的知识问答服务
Action（行动）	你怎样做、有什么取舍	PostgreSQL 保存事实，Qdrant 检索向量；filter 由 JWT 身份驱动；SSE 流式输出；评估集和 CI 防回归
Result（结果）	如何证明结果	固定 demo、测试数量、评估 case 通过率、可复现容器启动；如无真实用户数据，不编造业务指标

这里的 Result 不需要虚构“准确率 95%”。你可以诚实地说：“对 20 条手写高价值 case，每次改 Prompt 或索引都在 CI 中回归；其中 X 条通过，失败的 Y 条被记录为后续工作。”

第 4 关：岗位词如何映射到你的证据#

国内 AI 应用岗位常出现 Python、FastAPI、RAG、LangChain / LangGraph、Dify / Coze、向量数据库、工具调用、评估、部署和工程化等组合。它们的共同点是把预训练模型稳定接进业务，而不是要求每个人训练基础大模型。这个方向与 AI Engineer Roadmap 对 AI Engineer 的定位一致。

以下链接是本章编写时检索到的岗位样本，不是全部市场的统计结论；职位会下线或更新，因此用来观察关键词，不用来机械背诵要求：智联的 1–2 年大模型应用开发岗位、BOSS 的 AI 应用岗位样本。

把岗位词翻译成仓库证据：

岗位词	不够的说法	可验证的作品证据
RAG	“我会 Chroma”	文档入库、权限 filter、引用、评估 case、失败定位
Agent	“我用过 LangGraph”	工具 Schema、参数上限、Tool trace、失败时不越权
Docker	“我装过 Docker”	`Dockerfile`、Compose、volume、健康检查、启动说明
AI 评估	“我知道 Ragas”	golden cases、pytest、回归结果、何时不跑付费评估
可观测性	“接过 LangSmith”	请求 ID、operation、耗时、失败日志与脱敏边界
全栈对接	“能调 API”	Vue 流式 UI、登录 Token、错误状态、来源展示

招聘信息会随城市、经验和公司规模变化；将它当关键词样本，不要当绝对清单。更高要求岗位出现 GraphRAG、混合检索、消息队列、推理部署或 LoRA 时，先看自己投的是“应用工程”还是“算法 / 平台工程”方向，再决定是否投入。

第 5 关：投递前的最终验收清单#

必须有#

README 中有问题、架构、运行、验证和边界。
.env.example 可用，真实密钥不进 Git。
pytest 可在无真实模型密钥的 CI 环境运行。
上传、检索、回答、引用、鉴权至少各有一个可演示路径。
Docker / Compose 可启动，持久化目录和恢复方式写清楚。
有一段 3–5 分钟录屏或固定演示脚本。
能解释一条失败路径，例如上游超时、无资料拒答、越权检索被挡住。

不是现在必须有#

自训或微调模型。
复杂多 Agent 自主规划。
Kubernetes、分布式消息队列、百万元级并发。
把所有 Dify、n8n、LlamaIndex、MCP 都塞进同一个项目。

本章学到哪里，不学什么#

本章要学会：产品边界、证据链、可重复演示、项目取舍表达和岗位词映射。

本章暂不承诺：靠一个项目自动获得工作机会，也不把高级岗位的全部基础设施作为新手硬门槛。你要做的是让你的项目能被复查、能被解释、能持续迭代。

三遍练习#

[追踪] 用 90 秒按“问题 -> 架构 -> 验证”讲解你的知识库助手，不提任何框架名，再补上对应技术名。
[跟写] 给 README 写出“一个明确支持的功能”和“一个诚实的不支持边界”。
[独立做] 录一次固定演示：用户 A 上传资料、问答带来源、用户 B 无法检索、一次失败被日志记录。

课后压缩#

1
作品不是库的清单，而是可复查的工程证据链。
2
最小成品：登录、受控 RAG、引用、测试、Docker、演示。
3
面试讲取舍和失败边界，不虚构指标，不堆高级名词。

完成这一章后，后续学习由投递岗位决定：应用方向优先深化 RAG / MCP / 稳定性；算法或推理部署方向再进入 LoRA、vLLM、量化与模型训练。