从高级前端到 AI 工程师：我用 10 天做了一个 AI 文件助手，然后发现自己只完成了一半
我是一个做了多年前端的工程师。最近开始认真学 AI，不是那种「用 ChatGPT 写代码」的学，而是想真正转型，找 AI 相关的工作。
这篇文章记录我过去两周做的事，以及一次让我意识到「我以为我懂 RAG，但其实我在骗自己」的对话。
我做了什么
项目叫 AI File Hub，一个面向个人的私有云文件空间。核心功能：
- 上传文件（PDF、TXT、MD、图片）
- AI 自动生成摘要、要点、标签
- 全文搜索
- 基于文件内容的 AI 问答
技术栈没什么特别的：React 18 + Vite + Tailwind + shadcn/ui 做前端，Supabase 做后端（Auth + DB + Storage + Realtime），Edge Functions 跑服务端逻辑，DeepSeek API 做 AI 分析，部署在 Vercel。
从第一行代码到生产上线，大概花了 10 天。T-101 到 T-417，68 个任务，全部完成。
老实说，我当时挺满意的。这个项目覆盖了：
- Supabase RLS 行级安全
- Storage 文件管理
- Edge Functions + DeepSeek API 调用
- SSE 流式输出
- Realtime WebSocket 推送
感觉从「会调 API」到「能做完整产品」，跨了一个台阶。
然后我被问了一个问题
在整理下一阶段学习方向的时候，我把项目发给朋友看，他问了我一个问题：
「你的问答是怎么实现的？」
我说：读取 ai_results.full_text，截断到 8000 字符，塞进 prompt，让 DeepSeek 回答。
他沉默了一秒，然后说：「这是伪 RAG。」
什么是「伪 RAG」
我以为我实现了 RAG。我确实做了「检索增强生成」——从数据库取内容，增强 prompt，让模型生成答案。
但这只是形式上的 RAG，不是真正的 RAG。
真正的 RAG pipeline 长这样：
文档上传
→ 文本分块（Chunking） ← 我没做
→ 向量化（Embedding） ← 我没做
→ 存入向量数据库（pgvector） ← 我没做
用户提问
→ 问题向量化 ← 我没做
→ 相似度检索（Top-K chunks） ← 我没做
→ 只把相关段落注入 prompt ← 我没做
→ 模型回答 + 标注来源 ← 我没做
我实际在做的：
用户提问
→ 把全文（截断到 8000 字）塞进 prompt
→ 模型回答
这不是检索，这是「把作弊条整张塞给学生」。
问题在哪？
- 长文档直接失效：超过 8000 字的内容被截断，用户问第 10 章的事，答案在第 10 章，我却把第 10 章截掉了
- Token 严重浪费：用户问「合同甲方是谁」，我却把整份合同都塞给模型
- 答案质量差：模型要在大量无关内容里找答案，注意力被稀释
最要命的是：这个缺陷在小文件上完全看不出来。我测试用的都是几千字的文件，问答效果还不错，于是我以为自己做对了。
真正的 RAG 是什么
理解 RAG 之前，先理解一个比喻。
假设你是一个需要回答考题的学生：
- 伪 RAG 做法：把整本教材带进考场，每次回答都从第一页开始翻
- 真正的 RAG：考前做好索引，答题时精准翻到相关页码，只读那几段
RAG 的核心价值不是「把内容喂给模型」，而是**「精准找到相关内容再喂给模型」**。
三个核心概念
1. Chunking（文本分块）
把文档按语义边界切割成小块，每块约 300-500 字，相邻块保留少量重叠（保持上下文连贯）。
原始文档（10000 字）
→ Chunk 1（500 字）：第一章内容
→ Chunk 2（500 字）：第二章内容
→ ...
→ Chunk 20（500 字）：最后一章内容
2. Embedding（向量化）
把每个 chunk 转成一个高维向量（比如 1536 维的浮点数组）。语义相近的文本，向量距离也近。
「合同甲方为张三」 → [0.12, -0.45, 0.89, ...] ← 1536 维向量
「甲方：张三」 → [0.11, -0.46, 0.91, ...] ← 向量距离很近
「今天天气不错」 → [-0.78, 0.23, -0.34, ...] ← 向量距离很远
3. 相似度检索
用户提问时，先把问题也向量化，然后在向量数据库里找「距离最近的 Top-K 个 chunk」，只把这几个 chunk 注入 prompt。
用户问：「合同里的甲方是谁？」
→ 问题向量：[0.10, -0.44, 0.90, ...]
→ 检索最近的 5 个 chunk
→ Chunk 3（相似度 0.94）：「本合同甲方为...」✓
→ Chunk 7（相似度 0.91）：「甲方联系方式...」✓
→ 其余 18 个 chunk 不注入 prompt
这样，无论文档有多长，每次问答只用到少量相关内容，token 省了，准确率高了，长文档也能用了。
我的升级计划
意识到问题之后，我整理了一个升级方案，把 AI File Hub 从「伪 RAG」改造成「真 RAG」。
核心改动有三块：
1. 数据库层：加 pgvector
Supabase 原生支持 pgvector 扩展，启用后可以直接在 PostgreSQL 里存向量、做相似度检索，不用新增任何服务。
新增 document_chunks 表：
CREATE TABLE document_chunks (
id uuid PRIMARY KEY DEFAULT gen_random_uuid(),
document_id uuid NOT NULL REFERENCES documents(id) ON DELETE CASCADE,
user_id uuid NOT NULL REFERENCES auth.users(id),
chunk_index integer NOT NULL,
content text NOT NULL,
embedding vector(1536), -- pgvector 类型
created_at timestamptz DEFAULT now()
);
-- 向量相似度索引
CREATE INDEX ON document_chunks
USING ivfflat (embedding vector_cosine_ops);
2. analyze-file：新增分块 + Embedding 步骤
原来的流程：提取文本 → DeepSeek 生成摘要
升级后：提取文本 → 分块 → Embedding（OpenAI） → 存向量 → DeepSeek 生成摘要
为什么用 OpenAI Embedding 而不是 DeepSeek？ text-embedding-3-small 成本极低（约 0.00006，而且稳定性更好。AI 服务可以混用，不必从一而终。
3. chat-with-file：换成真正的检索
原来：读全文 → 截断 → 塞 prompt
升级后：问题向量化 → 相似度检索 Top-5 → 只注入相关 chunk → 回答 + 标注来源
Prompt 从「全文倾倒」变成精准的：
【参考段落】
[段落 3]（相关度：94%）
本合同甲方为...
[段落 7]（相关度：88%）
甲方联系方式...
【用户问题】
合同里的甲方是谁？
前端工程师学 AI 的一些思考
做这个项目让我意识到，前端工程师学 AI 有一个独特的优势，也有一个容易踩的坑。
优势是： 做出来的东西能看，能用，能展示。很多算法背景的工程师能做 RAG pipeline，但做不出好用的产品界面。流式输出的 SSE 渲染、实时 WebSocket 状态同步、骨架屏 loading 态——这些对我来说是基本功，但对他们来说可能要额外花两周学。AI 应用工程师这个交叉点，竞争比纯算法方向小得多。
容易踩的坑是： 前端思维容易停在「能跑通」就满足了。问答功能能用？能用。测试文件很小，效果不错？很好。就这样上线了。但 AI 工程的核心难题往往在「规模化」和「边界情况」：文档很长怎么办？问题和文档完全不相关怎么办？用户问了文档里没有的事怎么办？
这些问题，我做完阶段四才开始认真想。
下一步
做完 RAG 升级之后，我计划再做一个新项目：AI Agent。
如果说 RAG 是「让 AI 能找到答案」，那 Agent 是「让 AI 能完成任务」。用户说「帮我整理收件箱里所有关于合同的邮件，提取关键日期」，Agent 会自动调用工具、执行步骤、返回结果——不只是回答，而是真正地做事。
这是目前市场上最热的方向，也是我前端背景最能发挥价值的地方：复杂的 Agent 工作流可视化、流式步骤展示、工具调用 UI——这些都需要很强的前端能力。
最后
如果你也是前端，想转 AI 方向，我的建议是：
先做一个真实的 AI 应用，做到上线。 不要停在教程里，不要只是调调 API 看看效果。从数据库设计到部署，完整走一遍，你会遇到很多「教程里没讲的问题」，解决这些问题才是真正的学习。
然后，认真理解 RAG。不是「知道这个名词」，而是能说清楚 Chunking 策略的选择依据、Embedding 模型的选型逻辑、相似度检索的参数调优。这是 AI 应用工程师和「会用 ChatGPT 的开发者」之间最核心的分水岭。
项目地址：github.com/nacheal/ai-…
生产环境：ai-file-hub.vercel.app/
RAG 升级还在进行中，做完会再写一篇。
写于 2026-03-26
