网易伏羲测试开发一面：自动化框架改造与游戏 AI 人机测试

《面试题目》

1. 自我介绍。

实习项目拷打

2. 讲下实习整体工作流程？
3. 旧版自动化框架遇到什么问题，做了哪些改造？
4. VSCode Coding-Agent 插件自动化是怎么搭建的？
5. 自动化遇到的难点？模型输出没有标准答案怎么做断言？
6. Skill 策略优化，当时背景是什么，测试怎么做？
7. 讲下 Hooks 钩子功能，测试关注点？
8. 你们衡量自动化做得好不好看哪些指标？

个人项目：求职 Agent

9. 介绍你的个人 Agent 项目，实现什么能力？
10. 项目遇到过什么 bug？怎么修复？

业务场景题：游戏 AI（永劫无间 AI 人机）

11. 你玩永劫无间，如果让你来测试游戏里面的 AI 人机，你会测哪些点？

反问环节

12. 咱们这边 AI 评测，是用现成评测集还是自研评测标准？
13. 团队版本迭代周期大概多久？

《参考解析》

模型输出没有标准答案时怎么做断言：把「对错」拆成可判定的层次。 大模型输出是开放集合，硬比字符串一定不可用，工程上要分层断言：第一层是结构化与格式（JSON 能否解析、字段是否齐全、类型对不对、有没有多余前后缀），这类可以 100% 程序判定；第二层是确定性的业务约束（必须包含某个工具调用、必须引用检索到的文档片段、不能出现被禁止的表述、代码必须能编译或通过给定用例），也能靠规则判定；第三层才是语义正确性，用 LLM-as-judge 按维度打分（正确性、完整性、是否忠于资料）并给出理由，但要防它的偏差——位置偏差（成对比较时交换顺序各评一次）、长度偏差（偏好长回答）、自我偏好（用自己的模型评自己的输出），所以判官模型要与被测模型异构，并且用一批人工标注过的样本校准它和人的一致率。第四层是回归断言：把线上发现的 badcase 固化成「输入 + 期望特征」的用例集，每次改提示词或换模型都跑一遍，不要求逐字一致，只要求关键事实与格式不变。补一句很关键的落地细节：断言失败要有可读的 diff 和原始 trace（用了哪份资料、哪个模型版本），否则失败的用例没人愿意修。

VSCode Coding-Agent 插件的自动化怎么搭。 这类产品的自动化难在「输入是自然语言、输出是代码改动、还有一整套 UI 交互」，所以要把链路切成可分别驱动的几段。第一段是插件宿主：用 VS Code 官方的扩展测试框架（@vscode/test-electron）拉起一个真实 VS Code 实例加载插件，或用 vscode-test 的 headless 模式在 CI 里跑；UI 层面可以下载扩展的 insiders 版本配合 Playwright 驱动窗口，做「发指令→看 Diff→点应用」的端到端验证。第二段是Agent 内核：把 LLM 调用抽成可替换的 provider，测试时用 mock/录制回放（record & replay）固定模型输出，这样断言的是插件的编排逻辑而不是模型的随机性；要测真实模型时，只跑少量 smoke 用例并接受非确定性。第三段是结果校验：不看自然语言回复，看副作用——工作区文件是否被正确修改、是否生成了预期 diff、命令是否执行、错误路径有没有回滚。第四段是环境与数据：每个用例独立的临时工作区、预置的 git 状态与测试仓库、执行后清理，避免用例互相污染。这套结构讲清楚，面试官就知道你搭的是可维护的自动化而不是一堆脆弱的脚本。

衡量自动化做得好不好的指标。 别只报「写了多少条用例」——那是投入不是产出。可以按三组讲：有效性（发现了多少真实缺陷、其中多少是回归缺陷被提前拦住、上线后遗漏到线上的比例有没有下降、缺陷平均发现时间是否前移）；可靠性（通过率的稳定性、误报/假失败率、失败用例的平均归因时间——假失败率高是用例被忽略的头号原因，指标要单列而不是混在通过率里）；效率与成本（单次全量回归耗时、CI 资源占用、单条用例的平均维护成本，以及被替代的人工回归工作量折算成的人天）。再加一个覆盖维度的指标：核心业务链路的自动化覆盖率、按模块与风险等级加权，而不是按用例条数平均。落地时把指标接进看板，按周看趋势：用例数在涨但缺陷发现数不涨，说明在写无效用例；通过率虚高但假失败率高，说明断言写得太脆（依赖时间、随机数、外部服务）。

Skill 策略优化与 Hooks 的测试关注点。 这里的 Skill 指给 Coding-Agent 用的能力包（提示词 / 工具 / 脚本的封装），Hooks 指 Agent 生命周期上的钩子（如工具调用前后、提交前）。测试 Skill 要先问清背景：原来是什么策略、为什么不行（召回不准、选了不该选的能力、重复调用、token 浪费），改造后对比的指标是什么——命中率、平均调用次数、成功率、token 成本。测试方式上分两层：离线用一批固定的任务集跑回归，比较改造前后的任务成功率与调用轨迹（看它有没有选对 Skill、有没有多余步骤）；线上用小流量灰度 + 埋点对比。Hooks 的测试关注点更偏「确定性与副作用」：触发时机对不对（该触发的场景一次不漏、不该触发的一次不误触）、顺序与并发（多个钩子同时注册时的执行顺序、是否幂等、失败要不要阻断主流程）、异常路径（钩子自己抛错会不会把主流程带崩、超时有没有兜底）、以及权限与安全（钩子能读写什么、会不会绕过校验）。再补一条实战经验：钩子最容易被忽略的测试点是「重试与重复执行」——主流程重试时钩子会不会被重复触发、产生重复副作用。

业务场景题：怎么测永劫无间里的 AI 人机。 这类题要先把「AI 人机是什么」拆成可观测的维度，再逐维度设计验证手段。一是行为合理性：人机会不会做明显违反规则的动作（穿模、无视地形、瞬移、技能冷却错乱、无视野预判）；决策是否符合战斗常识（血量低会撤、被控会解控、会绕后、会拾取装备）；这一层适合用规则断言 + 录制回放，把一场对局的输入序列固定下来复现。二是难度与拟人度：按段位分档，检验不同档位的 AI 在反应时间、命中率、走位失误率上是否有区分度，且低段位 AI 不能强得不像人；不能只测「AI 打得准不准」，还要测它「是不是太准了」——拟人度才是玩家体验的核心。三是对抗性与可利用漏洞：玩家常见的作弊式打法（卡地形、无限风筝、站在 AI 视线死角的点位）AI 会不会被无限利用；连续多局是否出现同样的必胜策略。四是性能与稳定性：AI 决策的耗时与帧率影响、大量 AI 同场时的服务器负载、长时间对局的资源泄漏、断线重连后 AI 状态是否一致。五是体验指标：用真人玩家做盲测，收集「像不像人」「好不好玩」「有没有被针对」的主观评分，配合埋点看胜率分布是否落在设计区间。答题时按「功能 → 边界 → 性能 → 体验」的顺序展开，每一层都给出可自动化的部分和只能靠人工的部分，比笼统说「测各种场景」扎实得多。