导读

最近 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 Server，AI 就可以参与到真实测试流程里。

但这里有一个关键问题：

工具不是接上就完事了。

要测：

工具描述是否清晰 参数 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 工程进入测试开发之后，真正会拉开差距的地方。