科大讯飞 测试开发二面（40min）：知识库、测试覆盖与大模型痛点

《面试题目》

1. 自我介绍
2. 为什么要搭建知识库？
3. 做知识库的思路
4. 做知识库是为了解决什么场景上的问题吗？
5. 前后的效果提升变化
6. 列举一个使用知识库和不使用知识库的差别
7. 怎么样的设计策略来保证测试产物是覆盖全面的？
8. 举一个印象深刻的 bug
9. 使用 Codex 常见的技巧
10. skill 和 agent 的区别是什么？
11. 大模型在测试领域最难解决的痛点，和一个最容易解决的痛点
12. 反问环节：AI 在公司实际工作中的应用、面试流程

《参考解析》

1. 「为什么要搭建知识库」要落到具体场景，而不是讲 RAG 定义：先说清痛点——团队里需求文档、接口文档、历史缺陷、上线记录散在各处，人和 AI 都要反复找；回答知识库解决的问题时给两个可验证的点：一是检索速度（原来定位一个业务规则要几分钟，现在一次检索命中），二是答案可追溯（带出处，减少大模型凭空编造）。接着再讲形态：文档解析、按语义分块、向量化入库、检索时召回 Top-K 片段拼进提示词。面试官真正想确认的是「你知道知识库解决的是知识和上下文问题，而不是把它当成一个万能插件」。

2. 知识库的落地思路按「数据—检索—评测」三段讲：数据段要覆盖来源盘点（哪些库、哪些系统、谁是 owner、多久更新一次）、清洗（去重、去过期、脚注页眉这类噪声）、分块策略（按标题层级切、控制块大小和重叠窗口，表格与代码单独处理）。检索段讲召回方式（向量检索 + 关键词检索混合，重排模型精排）、引用溯源（回答带文件名和段落）。评测段是加分项：准备一批真实问题做检索命中率、答案采纳率和人工抽检准确率。三个环节里最容易被追问的是「文档更新后索引怎么办」，答上增量更新和过期下线就稳了。

3. 前后效果变化要给数字，不写「提升明显」：可以量化的口径有三种——检索命中率（Top-K 里有没有正确文档）、回答正确率（人工抽检 N 条，错误率下降多少）、以及人效（处理一个业务问题或写一条测试用例的平均耗时从多少降到多少）。也可以补充使用率（团队成员每周用多少次）和返工率。没有度量就没有说服力，面试官问「效果提升变化」时，实际上是在确认你有没有把工具当成一个需要验收的产物来做。

4. 保证测试产物覆盖全面的策略，要讲成一套机制：需求侧用需求追溯矩阵（每条需求映射到至少一条用例，反之每条用例能追回需求），设计侧按等价类、边界值、判定表、场景法、状态迁移逐层拆，并强制覆盖异常流与权限/并发/幂等这类非功能点；流程侧把用例评审、需求变更同步、以及缺陷反哺用例（每个线上问题都补一条回归用例）做成闭环；工具侧用覆盖率报告和清单卡点兜底，避免「凭经验觉得够了」。

5. skill 和 agent 的区别，一句话区分「会什么」与「能自己干」：agent 是有自主决策能力的执行者，自己规划步骤、选工具、根据结果调整；skill 是封装好的能力或流程，是被调用的对象，通常由人来决定何时用。落到测试场景：一份「接口测试用例设计规范」是 skill，按这份规范自己去找接口文档、生成用例、跑通并反馈结果的才是 agent。再补一层工程视角：agent 需要编排、工具白名单、执行监控和兜底，skill 一般只需要版本管理和触发条件，这是两者成本差一个量级的原因。

6. 大模型在测试领域最难与最易解决的痛点：最容易解决的是「把已有产物换个形式」这类任务，比如用例描述改写、缺陷描述规范化、测试数据批量构造、日志归类，判断标准明确、模型有现成语料，投入产出比高。最难的是「判定正确性」本身——需求里没写明的隐含约束、UI 与体验类的主观标准、并发与时序类偶现问题，模型很难给出可靠结论，最后仍然要人兜底。回答时把「最难的落在判定和探索性测试上」讲清楚，再补一句应对方式（人机分工：模型做生成和归因初筛，人做判定和定级），比硬答一道技术题更能体现出你理解这个岗位。

7. Codex 常见技巧挑两三条讲透：一是把任务拆小、一次只改一个点，改动面越大越容易失控；二是给足上下文（相关文件、接口定义、约束和目标），并明确「不许改什么」，最小改动原则；三是让模型先复述理解、给方案再动手，便于及早纠偏；四是固定输出模板（问题定位、修改位置、修改前后状态），方便自己复盘；五是长任务里注意上下文遗忘，发现模型开始不守约定就开新窗口。举一个真实例子比列十条清单更可信。