上一节用 RAG 给答疑机器人补上了公司私有知识，解决了"不知道"的问题。但跑起来之后很快会发现新的不对劲：回答是对的，却不好用——该给链接的没给，格式随模型心情，语气像一份冷冰冰的公告。这一篇记录把机器人从"能答"打磨到"答得好"的完整过程：从一次失败的"补丁式"改造讲起，到提示词框架与模板，再到 Meta Prompting、参考答案驱动的自动迭代，最后训练一个"AI 裁判"来给整个优化流程踩

前面几章我们把答疑机器人跑通了，看起来能答上来不少问题。但只要多问几句，就会撞到这种情况：问「张伟是哪个部门的」，机器人给出了回答，可这个回答到底对不对？是检索环节没找到资料，还是找到了资料但模型没答对？每次都靠人肉翻日志去排查，既慢又容易漏。传统软件开发有单元测试兜底，改一行代码跑一遍测试就知道有没有改坏东西。RAG 应用也应该有同样的机制：准备一批测试问题，每次优化后自动跑一遍，量化地看效果是

先想清楚问题出在哪。大模型的知识来自训练数据，截止在某个时间点，而且全是公开语料。你们公司的《考勤管理制度》不在里面，直接问"年假怎么算"，模型要么编一个，要么给一堆通用废话。RAG 的解法可以用开卷考试来理解：闭卷靠记忆，记不住就丢分；开卷靠翻资料，找到相关段落，加上自己的理解作答。大模型也一样——回答前先把相关知识检索出来塞进上下文窗口，让它"看着资料答题"。这就是上下文工程（Context

新员工入职，老员工被同一批问题反复打断。“报销走什么流程”“项目管理该用哪个工具”“账号怎么申请”。答案都躺在公司文档库里，但没人愿意翻几十页 PDF。很自然地会想：拿大模型做一个答疑机器人不就行了。一开始确实很顺。几十行代码，一个 API Key，机器人就能流畅作答。这三堵墙不是各自独立的 bug，它们指向同一个东西。下面按撞墙的顺序走一遍，从调通第一次 API 到最终绕不开的那个概念。

注意激活成功后文件夹不要删除，不要改名，不要移动，路径文件夹不能有中文和中文符号（包含上级）打开PyCharm的txt,复制激活码（别的软件同理）激活后文件夹不能修改，不能更改路径。目录下 的Activation_Code找到与你需要激活软件相同名字的文本全选复制。将解压后的文件夹移到别的目录下，比如放到D盘（不要放下载目录，不要放桌面）点击帮助（help）并点击倒数第三个，版本不同显示文字不一样

阶段1 那些验证脚本（之类）是典型的"写完就丢"式验证：每个脚本自己连一遍，靠print加肉眼看结果，加一个新脚本就得记住一条新命令。print所以我引入pytest，用四件套解决：自动发现test_*.py、用assert当统一的"过/挂"判官、fixture把"前置准备"抽出来复用、让 fixture 全局共享，把散装验证收编成"一条命令重复跑、共享前置、结果可判定"的测试体系。

要顺序和改动就用 list，要定值就用 tuple，要按名查就用 dict，要去重算关系就用 set。但对列表、字典这类可变容器，通过一个名字改了，另一个名字看到的全跟着变——这种"幽灵联动"是新手 bug 的重灾区。列表、元组、字符串看上去不一样，但都遵守同一套"序列协议"：能索引、能切片、能测成员、能拼接、能求长度。所有"通过某个标识取对应信息"的场景（联系人、配置、缓存、JSON）都该用字典

之前路由里只有一行——纯裸奔，零 try/except。service 层 catch 了异常也只是记日志再 raise，最后全砸到 FastAPI 默认兜底上。

详情接口的本质不是"多写一个路由"，是"列表返回摘要、详情返回正文"的场景分离。线程安全的关键补丁。，就自动管理生成器的"推进-暂停"节奏——请求进来跑到 yield 交出 session，路由跑完后回到 yield 之后执行。的函数，Python 不直接执行，而是返回一个 generator 对象。返回结果后，函数就死了——变量释放、执行位置清空，再也没下文。生成器，但替代品可以是任何可调用对象

Notebook 像"网页版单本笔记"，JupyterLab 是"浏览器中的 IDE"（升级版）。解释器是"让别的程序跑起来的程序"，位于代码与硬件之间的软件逻辑层。小结：venv 是工程化基本规范，流程五步——创建→激活→装包→导出→退出。系统 Python 被你塞满包，某天升级一个库，别的项目集体崩。（多态、运算符重载、多重继承、生成器、推导、闭包、装饰器、lambda）、是启动加速手段，源文