一、我是谁，以及我遇到了什么问题
我是一名 AI 方向的自学者，平时主要靠看教程和写小脚本学习。之前学过 Python、机器学习基础，但一直有个痛点：从来没有完整做完过一个能跑、能用的项目。每次都是"看教程觉得会了，一动手就卡壳"，做到一半就放弃了。
暑假的时候想做一个本地 RAG 知识库问答系统——就是把自己的 PDF 文档传进去，系统能基于文档内容回答问题，所有模型和数据都跑在本地，断网也能用。
但真要动手的时候发现问题一大堆：
-
技术栈选型拿不定主意（向量数据库选哪个？嵌入模型用啥？）
-
环境配置复杂，Ollama、Chroma、HuggingFace 模型下载，每一步都可能踩坑
-
不知道从哪开始，是先写后端还是先搞模型？
-
遇到报错看不懂，自己搜半天也找不到原因
按照我以前的节奏，这个项目大概率做两周就烂尾了。所以这次想试试用 TraeCode 带着我做，看看能不能坚持到最后。
二、我是怎么用 TraeCode 解决这件事的
我主要用的是 IDE 模式，整个项目都是在 TraeCode 里边问边做边改的。下面是大致的过程：
第一步：先搭架子，把整体架构定下来
最开始我只知道"想做一个本地 RAG"，但具体怎么分层、用什么技术、文件结构怎么安排，完全没概念。
我直接跟 TraeCode 说：
“我想做一个完全本地化的 RAG 知识库问答系统，用 Python + FastAPI，支持 PDF 上传和语义检索，模型用 Ollama 的 Qwen2.5:3b（因为我电脑没 GPU）。帮我设计一下整体架构和文件结构。”
TraeCode 没有直接甩一堆代码，而是先给我讲了 RAG 的完整链路：
文档上传 → 文本解析 → 切片 → 向量化 → 存入向量库 → 用户提问 → 语义检索 → Prompt拼接 → LLM生成 → 返回答案
然后帮我设计了项目结构，哪些文件放什么职责，为什么这么划分。还给了技术选型建议，每个选项的优缺点都讲清楚了，比如向量数据库为什么选 Chroma 而不是 FAISS，嵌入模型为什么选 BGE-small-zh。
这一步最大的收获是：我不再是"盲人摸象"了，对整个项目有了全局的认知。
第二步：MVP 优先，先把核心链路跑通
架构定了之后，我想一口气把所有功能都加上（流式输出、来源溯源、模型切换、多轮对话……）。TraeCode 建议我先做最小可用版本（MVP），把最核心的"上传文档 → 提问 → 得到答案"跑通再说。
我听了它的建议，第一周只做最基础的功能：
-
PDF 解析 + 文本切片
-
BGE 嵌入 + Chroma 向量存储
-
语义检索 + Prompt 拼接 + Ollama 生成
-
一个最简单的 FastAPI 接口
写代码的时候，我不是让它直接写完，而是让它先讲思路，我自己写，写不出来了再问。比如写文本切片的时候，我先自己写了一版，然后让它帮我 review，它指出了几个问题：切片没有重叠会导致上下文断裂、没有按句子边界切会把完整句子切两半。然后我再根据建议修改。
当第一次输入"Docker 是什么？"，系统正确返回答案的时候，那种成就感真的没法形容。
第三步：每周迭代一个方向，逐步完善
MVP 跑通之后，后面就顺利多了。我每周定一个小目标，TraeCode 帮我拆成具体的任务：
第二周：Docker 化部署
-
写 Dockerfile 和 docker-compose.yml
-
解决镜像源配置、健康检查、数据卷挂载等问题
-
踩了好几个坑（后面效率对比里细说）
第三周：LangGraph Agent 集成
-
引入 LangGraph 框架，实现 ReAct 循环
-
加了摘要、实体抽取、情感分类三个 NLP 工具
第四周：混合检索 + 会话持久化 + 评估体系
-
实现 BM25 + 向量混合检索（jieba 分词 + min-max 归一化 + 加权融合）
-
SQLite 存对话历史，支持多轮对话
-
写了一个忠实度评估脚本，量化回答质量
每次加新功能前，TraeCode 都会先帮我梳理：
-
这一步要改哪几个文件
-
核心逻辑是什么
-
可能会遇到什么坑
-
改完怎么验证
我就照着一步步来，心里特别有底。
第四步：踩坑 debug，它比我先找到原因
整个项目踩了 8 个印象比较深的坑，说两个最典型的：
坑 1：Docker 改了代码不生效 改了 main.py 加了个新接口，docker compose up -d 之后访问 404。我来来回回检查了快一个小时代码，以为自己哪里写错了。
把报错和操作步骤告诉 TraeCode，它秒回：
“Docker 镜像是构建时的快照，
up -d只启动不重建。改了代码必须加--build强制重建：docker compose up -d --build”
一试，果然好了。
坑 2：直接删向量库文件报错 想清空向量库重来，直接把 chroma_db/ 目录删了，结果报 OSError: Errno 16 Device or resource busy。我懵了，删个文件都能报错？
TraeCode 解释：
“这是因为 Chroma 进程持有文件锁，运行时直接删文件会触发锁冲突。正确做法是用 Chroma API 的
db.delete_collection()来删除集合，释放锁之后再操作文件。”
每个坑解决之后，我都会把原因和解决方案记到项目规则里，前前后后攒了 11 条"技术硬约束"。这些不是书上看来的，是自己踩过、真正搞懂了的经验。
三、成果展示
4 周时间，项目从 0 做到了 v1.1 版本，最终交付的东西包括：
代码交付：
-
约 4000 行 Python 代码，18 次 git 提交
-
三条独立的问答链路：基础 RAG / LangGraph Agent / 通用工具 Agent
-
BM25 + 向量混合检索，支持 weighted 和 rrf 两种融合模式
-
SQLite 会话持久化，页面刷新不丢失对话历史
-
完整的前端聊天界面（单文件 HTML，零依赖）
-
Docker Compose 一键部署
质量数据：
-
44 条测试问题的忠实度评估，平均得分 0.915（86.4% 的回答完全忠实于源文档）
-
支持 PDF / DOCX / TXT / MD / CSV 五种文档格式
-
71 页 PDF 约 1.5 秒/页的入库速度
文档交付：
-
README.md（完整的使用说明和部署教程）
-
项目总结 + 复盘报告（HTML 格式）
-
11 条技术硬约束规则（project_rules.md）
项目已经推到 Gitee 上开源了，MIT 协议，可以直接拿来用。
四、效率对比
这部分我感触特别深。拿几个关键节点对比一下：
事项
以前自己做（预估）
用 TraeCode（实际）
提升
环境配置（Ollama + Chroma + 模型下载）
2-3 天（各种搜教程、踩坑）
半天（一步步带着做，遇到问题马上解决）
约 5 倍
基础 RAG MVP 跑通
1-2 周（思路不清晰，走很多弯路）
1 周（先定架构，再分步实现）
约 2 倍
Docker 部署踩坑
1 天（每个坑都要搜半天）
2 小时（报错直接问，秒定位原因）
约 4 倍
混合检索方案设计
不确定怎么选（纯向量？BM25？怎么融合？）
半天（讨论两种方案优劣，给出建议）
省去大量调研时间
从 0 到 v1.1 完整项目
预估 8-10 周（可能中途放弃）
4 周（按节奏推进，没烂尾）
约 2 倍 + 完成了
最大的效率提升其实不是"写代码更快了"，而是"项目能坚持做完了"。
我以前做项目，最大的问题不是写得慢，而是遇到坎就卡壳，卡久了就放弃了。环境配不好就放弃了，报错看不懂就放弃了，思路不清就放弃了。
用 TraeCode 的感觉是：永远有下一步。遇到问题马上能得到解答，思路不清有人帮你梳理，卡住了也有人推你一把。这才是最有价值的地方。
五、经验和技巧总结
分享几个我摸索出来的小经验：
1. 先让它讲思路，再让它写代码 不要一上来就说"帮我写个 XX 功能"。先让它解释思路、讲清楚原理，你理解了之后要么自己写，要么让它写——这样写出来的代码你是懂的，后面出了问题也能自己改。不然它写了一堆你看不懂的代码，改个 bug 都费劲。
2. 报错直接整段丢过去，比你描述半天管用 我以前喜欢自己先"翻译"一下报错再问，结果经常翻译错了，导致方向偏了。后来发现直接把完整报错信息（包括堆栈）整段丢给它，它比你更懂报错是什么意思，定位快得多。
3. 大任务先拆，拆成小步再一步步做 比如"加个 Agent 功能"这种大需求，不要直接让它做。先让它帮你拆：这个功能涉及哪几个模块、每一步干啥、先后顺序是什么。拆完之后你心里有数了，再一步步往下走，不容易乱。
如果你也在学 RAG 或者想做个个人项目但总半途而废，真心推荐试试用 TraeCode 带着做。不是说它能帮你写代码，而是它能帮你把"我想做"变成"我做完了"。