不少开发者都有过类似经历：基于 LangChain 或其他框架搭建了一套 RAG 系统，表面上流程完整、组件齐全，但上线后回答质量不稳定。由于检索、重排、拼接、生成等步骤都被封装在框架内部，很难判断问题到底出在哪一层。
GitHub 上的 calmrocks/ai-engineer-notebooks 项目，正是围绕这一痛点设计的实战教程。它提供了一组可在 Colab 中运行的 Notebook，核心特点是不依赖 LangChain 等第三方框架，而是直接通过原始 API 构建 Prompt 工程、RAG、Agent 和评测系统。对于希望理解 AI 应用底层链路的工程师来说，这类“零框架”练习正在成为一种更直接的学习方式。
从 API 请求开始，重新理解 RAG 的最小闭环
该项目并不是简单地演示“调用模型接口”，而是把 RAG 拆回最基础的工程环节。从文档切分、Embedding 生成、向量存储，到检索召回、重排序、提示词拼接，再到模型生成，每一步都在 Notebook 中以原始 API 的方式实现。
这种写法的意义在于，开发者能够清楚看到每一次 API 请求的 payload、token 计数和响应处理过程。相比框架自动完成一切，裸 API 实现让数据流向、延迟来源和错误位置都更容易暴露。例如，RAG 回答质量不佳时，问题可能并不在模型本身，而在 chunk 策略不合理、检索结果噪声过高，或者上下文拼接方式影响了模型理解。
素材中提到，框架并非没有价值，但它容易把关键决策点藏进黑盒。当开发者长期依赖封装好的流程，可能逐渐变成只会调参的人，而失去对系统问题的诊断能力。手写一遍 RAG，本质上是重新掌握这些关键决策点。
Prompt、检索、Agent 与评测，都需要拆开看
除了 RAG 本身，这套 Notebook 还覆盖了 AI 工程中的几类基础能力。
- Prompt 工程：通过手写提示词，观察模型如何解析指令、如何约束 JSON 输出，以及 few-shot 与 zero-shot 在不同任务中的差异。
- 检索与生成：从切分、向量化到召回，完整走一遍检索链路，理解每一步对最终生成质量的影响。
- Agent 机制：ReAct、Function Calling 等概念在框架中常被包装得较为抽象，但手动实现后会发现，它们本质上是循环控制和工具注册机制。
- 评测系统：从基础评估框架开始搭建，包括对抗性提示测试，帮助开发者理解评测为何是生产部署的重要环节。
其中，评测部分尤其值得注意。很多团队在开发 AI 应用时，会把大量精力放在模型选择和提示词优化上，却缺少稳定的评估方式。素材指出，当评测框架本身与模型推理共同构成产品能力时，构建测试系统本身就是一项独立的工程能力。对于生产级应用而言，这一步往往决定了系统是否能持续迭代。
免费模型接口降低了实验门槛
该项目的另一个实用之处，是降低了动手成本。素材提到，Groq 可提供免费的 API key，用户无需信用卡即可注册，并在 Colab 环境变量中配置使用，直接调用 Llama、Mistral 等主流模型。
这意味着，开发者不需要一开始就准备昂贵的模型服务，也可以在 Colab 环境中完成从 Prompt 调用、检索、工具调用到多步推理的完整实验。项目中的 Notebook 从最基础的模型调用开始，逐步叠加检索、工具调用和多步推理，最终形成可运行的 agent pipeline。整个过程不需要额外框架依赖。
框架仍然有用，但工程师需要先看懂底层
从实际开发角度看，这套 Notebook 并不是要否定框架。原型阶段，框架仍然可以帮助团队快速验证想法，减少重复开发。但当系统进入生产环境，开发者需要处理性能瓶颈、定制复杂工作流、应对极端输入时，如果缺乏底层经验，定位问题的效率会明显下降。
换句话说，这类教程的价值并不在于让开发者以后永远不用框架，而在于让人知道框架在做什么、为什么这么做。会用框架可以完成功能搭建，但理解底层链路，才更接近 AI 工程师所需要的能力边界。
素材最后给出的判断也比较明确：如果目标是成为能够独立诊断和交付生产级 AI 系统的工程师，在 Colab 上花时间完整跑通这样一套 Notebook，可能比阅读多篇框架教程更有帮助。对于正在学习 RAG、Agent 和评测体系的开发者来说，这种从原始 API 出发的训练方式，至少能帮助他们把“系统为什么不稳定”这个问题，从模糊感受变成可定位的工程问题。
原创文章，作者：点点，如若转载，请注明出处：https://www.dian8dian.com/bu-kao-langchain-shou-lu-yi-tao-rag-cai-neng-zhen-zheng-kan
