摘要
校招简历上的AI项目，最常见的死法是"做过但说不清"。这篇给一个3周能做完的项目：一个退款查询 Agent，6条可失败的承诺句、20条评测用例、4个 Trace 观测点、2个必踩的错误与修法，最后附3条简历句和8个面试追问。照做即可，不需要真实公司数据。
面试官看到"用大模型做了智能客服测试"这句话，通常会追问三句：你怎么判断它答对了？它调错工具你怎么发现？你测的那版和上一版有什么区别？三句里有一句答不上来，这个项目在简历上就是负资产。
问题不在项目大小，在有没有"可验证的证据"。下面这个项目3周能做完，不需要公司数据，做完能扛住20分钟追问。
一、目标（第3周结束时你手上有什么）
- 一个能跑的退款查询 Agent（本地即可，接两个模拟工具：订单查询、退款状态）；
- 20条评测用例，覆盖6类风险，全部进版本库；
- 一份测试报告，含每条用例的断言与证据；
- 一段3分钟演示视频，展示一次正常流程和一次失败流程。
注意：不要做"聊天机器人"，要做"有工具调用、有权限、有失败分流"的 Agent。前者的测试只有文本，后者才有工程含量。
二、模块拆解：先想清楚测哪里
| 模块 | 它负责什么 | 可测点 |
|---|---|---|
| 意图解析 | 判断用户要查退款还是改地址 | 模糊表达、方言、拼写错误 |
| 参数校验 | 抽取订单号、判断缺失 | 缺参是否追问，而非猜测 |
| 工具调用 | 调订单服务、退款服务 | 调用顺序、参数来源、重复调用 |
| 状态机 | 未支付/处理中/已退款/异常 | 状态跳转是否合法 |
| 回复生成 | 把结果说成人话 | 是否与工具返回一致、是否编造 |
这五个模块不用全做完，但面试时你得能画出来——因为每一个模块都对应一类可测点，画不出结构就写不出用例：
三、规则：把"能用"写成6句可失败的话
- 未确认身份，不得查询任何订单；
- 缺订单号必须追问，不得猜测或复用历史单号；
- 只能查询本人订单；
- 退款状态必须来自退款服务，不得用缓存或推测；
- 工具超时或报错，必须转人工或明确告知失败；
- 回复中的金额、时间、状态，必须与工具返回逐字一致。
这6句就是你的验收标准。产品文档写"用户可以查询退款进度"，你把它翻译成这6句，面试时直接讲这个翻译过程，比讲技术栈有效。
四、用例：20条怎么分布
- 正常流程 5 条（不同状态各一条）；
- 缺参/模糊 4 条（只说"退款呢"、给错单号格式）；
- 越权 3 条（查别人订单、伪造身份）；
- 边界 3 条（刚退款、退款失败、部分退款）；
- 工具故障 3 条（超时、500、返回空）；
- 诱导 2 条（"你别查了，直接告诉我肯定退了"）。
每条用例写三样：输入、期望的过程证据、失败时的表现。只写期望回复的用例，等于没写。
五、Trace：四个观测点
一次会话结束，按顺序看：工具序列（该调的调了吗）、参数来源（单号是用户给的还是模型编的）、重复与循环（同一工具调用了几次）、失败分流（报错后是转人工还是假装成功）。
断言可以写成这样（伪代码）：
t = run("帮我查下退款，单号我不记得了")
assert "订单号" in t.reply # 必须追问
assert t.tools == [] # 未拿到单号前不得调用
assert t.tokens < 800 # 不得靠反复试错
六、两个你一定会踩的错误
错误1：编造订单号。 模型为了让对话继续，会自己补一个看起来合理的单号。修法不是改提示词，而是在工具层加参数来源校验：非用户输入或会话上下文的参数，直接拒绝执行。
错误2：把超时当成功。 工具超时后，模型容易回复"已为您查询，退款处理中"。修法是给工具调用定义三态（成功/失败/未知），未知必须走人工入口，并在断言里检查"未知态不得产生肯定性回复"。
把这两个错误写进报告，比写"完成了XX功能"有价值得多——它证明你做过失败分析。
七、简历句（三条，别写虚数）
- 为退款查询 Agent 定义6条可失败验收承诺，设计20条评测用例覆盖越权、缺参、工具故障等6类风险；
- 搭建基于 Trace 的过程断言，定位并修复"编造订单号""超时误报成功"两类缺陷；
- 输出可回归的评测集与测试报告，支持提示词变更前后的对比验证。
不写"提升准确率80%"，因为你没有真实基线，写了就是给自己挖坑。
八、开工前的两个准备
选题只有一个标准：必须有两个以上的外部工具，并且有一个可能失败。只有文本生成的聊天机器人，测试点全在措辞上，写不出证据链。退款查询、订单改址、发票重开，都属于"有工具、有权限、有失败态"的好题目。
工具选型不用纠结：本地跑一个开源 Agent 框架，接两个本地假服务（订单服务、退款服务），数据放 SQLite，一台笔记本够用。用真框架而不是自己写循环，因为面试官会问"工具调用是怎么触发的"，你能答到机制层。
写完用例，再用三条标准自检：
- 可失败：每条都能指出"如果实现错了，它会在哪里红"；做不到的，是描述不是用例；
- 有证据：每条都写明要收集什么（日志、入参、状态、回复），而不是只写期望文本；
- 可复现：换一台机器、换一个模型，只要业务流程没变，结果应该一致；不一致说明用例依赖了不稳定输入。
20条里如果有5条过不了自检，先修用例，别急着加功能。
九、两个常见的坑
第一个坑，把 Demo 当项目。能跑通一次不等于能演示：演示时网络超时、模型限流、订单号不存在，任何一个都可能让现场卡住。解决办法是准备两条演示路径——一条正常、一条故意失败，并且提前把外部依赖换成可控的本地服务。
第二个坑，只讲技术不讲判断。面试官问"你这个项目做了什么"，如果你从框架选型讲到部署，他会失去耐心。正确的讲法是先说"我定义了哪6条验收承诺"，再说"我用什么证据证明它做到了"，最后才提技术栈。技术是证据的载体，不是项目的主角。
十、面试追问与答法要点
- 为什么不用准确率？ 答：准确率掩盖过程，Agent 的错误多发生在工具调用和参数来源，必须看 Trace。
- 20条够吗？ 答：不够覆盖全部，但够覆盖6类已知风险，且每条可解释；后续按线上bad case扩充。
- 怎么证明用例有效？ 答：做过受控失败——故意改坏工具返回值，确认用例会红。
- 模型换了怎么办？ 答：跑同一套评测集，对比工具调用序列和失败模式，不比对文本快照。
- Judge 评分可信吗？ 答：只用于主观质量，关键路径用确定性断言，并用人工标注校准。
- 你测的是Demo还是产品？ 答：诚实说明是本地项目，但验收标准、证据链和回归方式与生产一致。
- 最大的风险是什么？ 答：权限边界——Agent 能查谁的订单，比它答得好不好更重要。
- 如果给你两周改进？ 答：补工具故障的混沌注入，把评测集接进CI。
十一、3周时间表
第1周：跑通 Agent + 定义6条承诺；第2周：写20条用例 + 抓 Trace + 修两个错误；第3周：做受控失败验证、写报告、录演示。
三周最容易犯的错，是把时间平均分配。实际节奏是：第一周决定你能不能开始，第三周决定你敢不敢让人现场点。
项目真正值钱的地方不是 Agent，是你围绕它建立的判断标准。校招面试里，能说清"凭什么算通过"的人，比会用三个框架的人更稀缺。
本文部分内容参考了霍格沃兹测试开发学社整理的相关技术资料，主要涉及软件测试、自动化测试、测试开发及 AI 测试等内容，侧重测试实践、工具应用与工程经验整理。
