从模型、Agent 到 MCP：这个 10.7k Star 项目，把 AI 工程学习路线重新铺了一遍

导读最近 GitHub 上有个项目涨得很快https://github.com/rohitg00/ai-engineering-from-scratch。它不是那种“接几个大模型 API做一个聊天机器人”的教程也不是单纯讲论文、讲概念的资料合集。它更像是一套完整的 AI 工程训练路线从数学基础、机器学习、深度学习、Transformer、LLM、RAG、Agent、MCP一直到生产部署、安全与对齐。根据项目资料这套内容包含20 个阶段、435 节课约 320 小时覆盖 Python、TypeScript、Rust、Julia。每节课不是只讲知识点而是要求学习者完成代码实现并产出可复用的 Prompt、Skill、Agent 或 MCP Server。这类项目为什么值得测试开发关注不是因为它又是一个热门开源项目也不是因为 Star 数好看而是因为它暴露了一个很现实的问题很多团队已经开始用 AI 写用例、生成脚本、做知识库问答、接入 Agent 工具链但真正到了工程落地阶段问题往往不在“模型会不会回答”而在于系统链路能不能复现 生成结果能不能验证 工具调用能不能追踪 知识库回答能不能回放 Agent 执行失败后能不能定位 AI 生成的测试资产能不能进入真实研发流程这些问题已经不是单纯会用 AI 工具就能解决的了。它们开始进入测试开发熟悉的领域工程质量、链路治理、自动化验证和平台化沉淀。一、这个项目真正有价值的地方现在很多 AI 资料都有一个共同问题知识点是散的。今天看一篇 Transformer 解析。 明天收藏一个 RAG 项目。 后天跑一个 Agent Demo。 再过几天又看到 MCP 工具接入方案。每个东西单独看都不难但一旦要做成企业里的可交付系统问题就出来了。比如你能跑通一个聊天机器人但解释不清楚为什么某些问题会幻觉。 你能接入向量数据库但不知道切片、召回、重排到底该怎么测。 你能让 Agent 调用工具但不知道调用失败后应该如何回滚、重试和记录上下文。 你能让 AI 生成自动化脚本但不知道如何判断这批脚本是否稳定、可维护、可回归。很多 AI 项目从 Demo 到生产卡住的不是模型能力而是工程链路。这个项目的价值就在这里。它不是只让你知道“某个技术存在”而是把 AI 工程拆成了一条从底层到交付的路线数学基础 机器学习 深度学习 Transformer LLM RAG 工具调用 MCP Agent 多智能体 生产部署 安全与评测更关键的是它每一节课都要求产出东西。项目资料里提到每节课会形成可复用成果最终沉淀为 prompts、skills 等工具资产并且可以集成到 Claude、Cursor、Codex、OpenClaw、Hermes 等工具链中。这个设计思路对测试开发团队很有参考价值。因为测试开发最怕的不是学了多少概念而是学完以后没有资产沉淀。二、普通 AI 教程为什么很难支撑工程落地很多 AI 教程看完以后会让人产生一种错觉好像 AI 应用很简单。一个 API Key 一个 Prompt 一个向量库 一个前端页面 一个工具调用函数Demo 就出来了。但真实项目不是这样。企业里的 AI 应用一旦进入业务流程就要面对很多工程问题输入不稳定 输出不可控 知识更新频繁 权限边界复杂 模型版本变化 上下文长度受限 工具调用失败 多轮任务状态丢失 用户问题不可预测 评测标准难统一这些问题并不是“提示词写好一点”就能解决。它需要系统性的工程设计。比如一个 RAG 问答系统表面上看是用户提问 → 检索文档 → 拼接 Prompt → 模型回答但从测试视角看至少要拆成文档解析是否正确 文本切片是否合理 向量召回是否命中关键证据 重排是否把有效内容排到前面 Prompt 是否引导模型基于证据回答 回答是否引用了正确来源 没有答案时是否能拒答 知识更新后历史问题是否回归正常这已经不是一个“AI 功能”而是一条完整质量链路。同样一个 Agent 系统表面上看是用户给任务 → Agent 拆解任务 → 调用工具 → 输出结果但真正要测的是任务理解是否准确 计划拆解是否合理 工具选择是否正确 参数生成是否符合 schema 工具失败后是否能处理 是否出现无效循环 是否存在越权调用 最终结果是否可验证 执行轨迹是否能回放所以AI 工程落地不是“会接模型”就够了。更准确地说它要求团队把 AI 的不确定性拆成可观察、可验证、可回归的工程问题。三、测试开发人应该从哪里看这个项目测试开发人看这个项目不建议把它当成算法课程从头硬啃。更合理的方式是把它看成一张 AI 工程能力地图。测试开发人不一定要从第一天就自己训练大模型。但至少要能看懂几个关键问题大模型应用的请求链路是什么 RAG 的召回和生成怎么拆开评估 Agent 的执行轨迹怎么记录 MCP 工具描述会不会影响模型调用质量 AI 生成的测试资产如何做规则校验和回归验证 模型版本变化后怎么判断业务效果有没有退化这些问题和传统测试开发的能力并不冲突。相反它们只是把原来的测试对象换了。过去测的是接口、页面、App、数据库、微服务。现在还要测模型输出 知识库链路 工具调用 智能体任务 多模态理解 AI 生成代码 AI 自动化测试平台测试对象变了但底层能力还是工程能力。四、AI 工程链路里测试最容易被忽略的部分很多团队做 AI 项目前期最关注的是“效果”。能不能答出来 能不能生成代码 能不能帮我写用例 能不能自动执行任务这些当然重要但从测试开发角度看只看效果远远不够。真正影响上线质量的往往是下面几个点。1. 可复现性AI 系统最大的问题之一是同一个问题多问几次结果可能不一样。这在 Demo 阶段没什么问题但在生产环境就很麻烦。比如同一个需求文档今天生成 80 条用例明天生成 95 条。 同一个接口定义第一次生成了异常场景第二次漏掉了鉴权场景。 同一个知识库问题不同模型版本给出的结论不一致。 同一个 Agent 任务有时调用工具有时直接编答案。测试开发要做的不是要求 AI 每次逐字一致而是要定义可接受的稳定性范围。比如关键场景是否稳定覆盖 核心断言是否一致 引用证据是否正确 高风险问题是否拒答 工具调用路径是否符合预期 输出结构是否满足下游系统消费AI 系统的回归测试不应该只比对文本而要比对结构、证据、行为和业务结果。2. 可观测性传统系统出问题可以看日志、查数据库、抓接口、看调用链。AI 系统如果没有观测设计问题定位会非常困难。用户只会说一句“它答错了。”但研发和测试需要知道用户原始问题是什么 系统改写后的问题是什么 检索到了哪些文档 哪些文档进入了上下文 最终 Prompt 是什么 模型返回了什么 是否调用了工具 工具返回了什么 后处理逻辑做了什么 最终答案为什么会变成这样如果这些信息没有记录AI 问题就很难复盘。所以测试开发在 AI 项目里一定要推动 Trace 设计。不是只记录接口日志而是记录完整推理链路中的工程事件。3. 可验证性AI 很擅长生成内容但生成内容不等于结果正确。尤其在测试场景里问题会更明显。AI 生成测试用例常见问题包括用例重复 前置条件缺失 步骤不可执行 预期结果模糊 边界值遗漏 异常场景不足 和需求字段对不上 无法导入测试管理平台AI 生成自动化脚本常见问题包括选择器不稳定 断言过弱 等待机制粗糙 异常处理缺失 环境依赖写死 数据清理缺失 脚本跑通一次但不能长期维护AI 生成接口测试代码常见问题包括只覆盖正常流 缺少鉴权测试 缺少错误码校验 缺少幂等验证 缺少并发场景 缺少数据隔离 没有契约变更检查所以AI 生成之后必须接校验层。可以是规则校验也可以是执行校验还可以是评测集对比。没有校验层的 AI 生成只能算辅助草稿不能算工程交付。4. 可回归性AI 项目一旦进入迭代会频繁变化Prompt 会改 模型会换 知识库会更新 切片策略会调整 工具描述会优化 Agent 规划逻辑会变化 后处理规则会升级每次变化都可能影响历史效果。这时候就必须有回归集。比如标准问题集 标准需求文档 标准接口定义 标准页面结构 标准缺陷样本 标准业务流程 高风险越权问题 历史线上问题样本每次改动以后要能跑一遍评测看看核心指标有没有退化。AI 系统如果没有回归集后期会越改越不敢动。这点和传统自动化测试非常像。五、从 RAG、Agent 到 MCP质量问题怎么拆如果从测试开发视角看AI 工程可以拆成三条主线。1. RAG重点不是“能回答”而是证据链是否可靠RAG 系统最容易出现的问题是答案看起来合理但证据并不可靠。测试时不能只问“回答对不对”还要拆开看文档有没有解析成功 切片有没有切断关键信息 召回有没有命中正确段落 重排有没有把关键证据放前面 Prompt 有没有要求基于证据回答 答案有没有引用正确来源 没有证据时是否拒答 不同问法是否能命中同一知识点RAG 的测试指标也不能只看准确率。更应该关注召回命中率 引用正确率 答案忠实度 拒答准确率 知识更新生效时间 多轮追问一致性 相似问题稳定性这部分很适合测试团队做成评测平台。2. Agent重点不是“能执行”而是过程是否可控Agent 比普通 LLM 应用复杂得多。因为它不是一次问答而是一个多步骤执行过程。测试 Agent 时不能只看最终输出还要看执行轨迹。至少要记录任务理解 计划拆解 工具选择 参数生成 工具返回 中间状态 失败处理 最终总结常见问题包括任务拆解过细导致步骤膨胀 工具选择错误调用了不相关能力 参数生成错误接口返回失败 工具失败后继续编造结果 多轮执行中上下文丢失 反复尝试同一条无效路径 最终答案掩盖了中间错误Agent 系统的测试很像过去测试复杂工作流系统。只是现在工作流不是完全由代码写死而是由模型动态生成。这也是测试难度上升的地方。3. MCP重点不是“接上工具”而是工具边界是否清楚MCP 让模型可以调用外部工具这对测试开发很重要。因为测试团队手里本来就有很多工具接口测试平台 自动化测试平台 测试数据平台 缺陷系统 CI/CD 日志平台 数据库查询工具 浏览器自动化 App 自动化 性能测试平台这些工具一旦封装成 MCP ServerAI 就可以参与到真实测试流程里。但这里有一个关键问题工具不是接上就完事了。要测工具描述是否清晰 参数 schema 是否严谨 默认值是否安全 错误信息是否可理解 权限是否最小化 敏感数据是否脱敏 调用日志是否可审计 失败结果是否能被模型正确处理很多 Agent 调用失败不是模型不行而是工具描述和接口设计对模型不友好。这部分正好是测试开发可以发挥作用的地方。六、测试开发人的学习路径不应该从“追热点”开始面对这种大项目最容易犯的错是从头收藏然后从来不学。或者今天看 RAG明天看 Agent后天看 MCP最后每个都知道一点但都做不深。对测试开发人来说更适合按工程问题来学。第一层先看懂 LLM 应用链路不需要一开始就训练模型。先搞清楚请求如何进入模型 Prompt 如何拼接 上下文如何管理 结构化输出如何约束 函数调用如何触发 模型参数如何影响结果 流式输出如何处理 模型异常如何降级这一层解决的是“看懂系统”。第二层把 RAG 当成一个可测试系统重点看文档解析 切片策略 向量召回 重排 上下文拼接 答案生成 引用溯源 拒答策略这一层解决的是“回答为什么对为什么错”。第三层把 Agent 当成一个动态工作流重点看任务拆解 工具选择 工具调用 状态管理 失败处理 执行轨迹 权限边界 任务完成率这一层解决的是“过程是否可控”。第四层把 MCP 当成测试工具接入层重点看工具封装 参数设计 错误处理 权限控制 日志审计 客户端兼容 工具调用评测这一层解决的是“AI 如何进入真实测试流程”。第五层做评测和回归重点看标准测试集 黄金答案 行为断言 结构校验 批量评测 版本对比 线上问题回放 质量看板这一层解决的是“系统能不能长期维护”。七、可以落到测试团队的几个方向这类项目看完以后最好不要只停在文章和收藏夹里。测试团队可以尝试沉淀几类资产。方向可以沉淀的资产价值用例生成需求解析 Prompt、用例规则校验器、用例评测集提升用例设计效率接口测试Swagger 解析工具、接口测试生成 Agent、异常参数生成器提升接口覆盖率Web 自动化页面理解 Prompt、Playwright 脚本生成器、选择器稳定性检查提升脚本生成质量App 自动化页面结构识别、Appium 动作生成、失败截图分析降低移动端自动化维护成本RAG 评测标准问答集、引用校验、幻觉检测、拒答测试保障知识库问答质量Agent 测试轨迹记录、工具调用断言、任务完成率评测让智能体执行过程可控MCP 工具测试平台 MCP Server、数据平台 MCP Server、CI/CD MCP Server把 AI 接入测试基础设施这些资产一旦沉淀下来团队使用 AI 的方式就会发生变化。不再是每个人各自写 Prompt而是形成统一的测试能力组件。八、回到工程本身AI 项目的质量问题最后还是工程问题这个项目值得关注不是因为它把 AI 知识点列得很全而是因为它的组织方式很工程化。它没有停在“知道一个概念”而是要求你把算法写出来 把代码跑起来 把结果测出来 把能力封装起来 把组件交付出去这套方式和测试开发的工作习惯是接近的。测试开发真正要补的也不是“多背几个 AI 名词”而是把下面几件事想清楚AI 系统的输入边界在哪里 AI 系统的输出如何验证 AI 系统的执行过程如何观测 AI 系统的失败如何定位 AI 系统的质量如何度量 AI 系统的能力如何沉淀到团队工具链里过去我们做自动化测试核心不是写几条脚本而是让测试能力进入研发流程。现在做 AI 测试开发也不是简单让大模型帮忙写点东西而是要把 AI 能力纳入工程体系。这中间有很多具体工作给 Prompt 做版本管理 给 RAG 做评测集 给 Agent 做执行轨迹 给 MCP 工具做权限边界 给生成代码做静态检查 给生成用例做规则校验 给模型切换做回归测试 给线上问题做样本沉淀这些事情看起来不炫但决定了 AI 项目能不能真正上线、能不能长期维护。所以测试开发人看这类项目不用只盯着“从零训练模型”。更应该关注它背后的工程方法怎么拆模块 怎么留证据 怎么做验证 怎么沉淀资产 怎么把一次性 Demo 变成可维护系统这才是对测试开发更有价值的部分。结尾AI 工具会继续变快模型能力也会继续变强。但企业项目里真正麻烦的通常不是“有没有模型”而是模型进入业务流程以后谁来保证它稳定、可控、可验证。这正是测试开发可以切进去的位置。未来很多 AI 应用表面上是模型能力竞争底层其实还是工程质量竞争。谁能把 RAG、Agent、MCP、评测、回归、观测、权限这些环节串起来谁就更容易把 AI 从 Demo 推到生产。对测试开发人来说接下来值得投入的方向不是单纯学习某一个工具而是建立一套新的判断能力看到一个 AI 功能能拆出链路。 看到一个 Agent能看懂执行轨迹。 看到一个 RAG 系统能判断证据链是否可靠。 看到一个 MCP 工具能识别权限和参数边界。 看到一批 AI 生成结果能设计校验和回归方案。这就是 AI 工程进入测试开发之后真正会拉开差距的地方。