这是三篇复盘的第二篇。第一篇讲我们建了 6 套验证脚本的金字塔，本篇讲这套体系挖出的 9 个真实缺陷——每个都讲发现场景、根因、修复、量化效果。准确率从 41% 修到 94.3%，中间到底发生了什么。

先看进度表

缺陷	发现层	修复前	修复后	所在指令
1 prd 漏第 11 维度	LLM 评测	0/5	5/5	/qa-prd
2 bug 误判信息不足	LLM 评测	0/5	5/5	/qa-bug
3 team 只承诺不输出	LLM 评测	1/4	4/4	/qa-team
4 agent 漏 RAG 维度	LLM 评测	2/5	5/5	/qa-agent
5 case 缺格式校验	LLM 评测	7/9	9/9	/qa-case
6 eval 维度命名不对齐	LLM 评测	4/5	5/5	/qa-prd
7 版本清理丢数据	长期压测	丢数据	不丢	记忆模块
8 直接调不读规范库	LLM 评测	1/4	标注排除	/qa-case
9 validate.sh BOM	静态校验	报错	正常	ci 脚本

缺陷 1：prd 漏第 11 维度（业务分层）

发现：冒烟测试就暴露——kimi-for-coding 跑 /qa-prd 只输出 10 个维度，漏了第 11 个（业务分层）。

根因：prompt 表格定义了 11 行，但第 11 行是后加的，模型生成时按"10 个维度"的惯性输出。

修复：加硬约束"11 维度全必输出，未发现问题也要输出占位行，末尾统计 11/11，缺一项即校验失败"。

效果：prd-001 从 0/5 → 5/5。

缺陷 2：bug 误判"信息不足"拒绝根因分析

发现：eval 提供了完整的缺陷描述（复现步骤+期望/实际结果），模型却说"信息不足无法分析"。

根因：prompt 写"信息不足时拒绝根因分析"，但没定义"信息充分"的标准。模型把"缺环境信息/日志截图"误判为信息不足。

修复：明确判定标准——含复现步骤+期望/实际三项即视为充分，不得因可选辅助信息缺失而误判。

效果：bug-001 从 0/5 → 5/5。

缺陷 3：team 只承诺不输出

发现：用户说"看下这周进度"，模型回"我将生成包含进度和风险分析的报告"——但没真生成表格。

根因：prompt 没硬约束"必须直接输出内容不得只承诺"。

修复：加硬约束"必须在本次响应中直接输出完整表格，不得只承诺；询问确认不得替代直接输出"。

效果：team-001 从 1/4 → 4/4。

缺陷 4：agent 漏 RAG 维度

发现：被测 Agent 描述含"基于 RAG 架构"，但模型把 RAG 维度（14-16）标成了"不适用"。

根因：prompt 写"RAG 维度仅在涉知识库时生成"，但没明确判定规则，模型误判。

修复：明确判定规则——Agent 描述含"RAG/知识库/检索"等词即标注适用，不得误标不适用；末尾必须按编号 1-16 逐项确认覆盖。

效果：agent-001 从 2/5 → 5/5。

缺陷 5：case 缺输入格式校验

发现：登录场景的用例只做了边界长度测试，漏了"用户名含特殊字符被拒""格式不符被拒"等格式校验。

根因：prompt 只说"覆盖长度边界"，没强制要求格式校验。

修复：加硬约束——涉及用户输入的场景必须生成至少 2 条格式校验用例（字符集+格式规则），且以"格式校验："开头命名便于审阅；6 种测试类型全覆盖，不适用也要占位。

效果：case-001 从 7/9 → 9/9。

缺陷 6：eval 与 prompt 维度命名不对齐

发现：prd-001 断言"覆盖 11 维度"通过，但 judge 用了"功能正确性/可靠性"等 ISO 25010 维度名判，和 prompt 里的"完整性/清晰度"等名鸡同鸭讲。

根因：eval 的 assertion 描述模糊，没硬编码具体维度名，judge 模型自由发挥用了其它领域的维度名。

修复：改 eval 的 assertion 描述，明确列出 prompt 的 11 个维度名，禁用 ISO 25010 维度误判。

效果：prd-001 稳定 5/5。

缺陷 7：记忆模块版本清理丢数据

发现：长期压测（10 轮迭代）暴露——版本清理删除旧版本文件后，早期版本中的唯一用例在 latest.json 里也丢了。

根因：原 merge_latest 只读磁盘现存版本文件合并，清理删了旧版本，这些版本里的唯一用例就没了。

修复：改为"以现有 latest.json 为基线再并入新版本"，清理只删版本文件不丢 latest 里的合并数据。回填到两个测试脚本保持一致。

效果：压测 6/6 全过，无数据丢失。

缺陷 8：直接调 /qa-case 不读规范库

发现：std-case-001 跑 1/4——模型没读 standards.json。

根因：case/prompt.md 写"通过 /qa 入口调用时自动读 standards.json"，但直接调 /qa-case 时漏了这条指令。真实用户直接调指令时不会触发规范库联动。

修复：加"直接调用时也主动读 standards.json/latest.json，不依赖 /qa 入口注入"。

注意：这条 eval 后被标注为 requires_e2e: true 从 LLM 评测基线排除——因为纯 LLM 评测器看不到文件内容，需用端到端模拟器验证。这是诚实的架构限制标注，不为提分改评测器。

缺陷 9：validate.sh 的 UTF-8 BOM

发现：./ci/validate.sh 直接执行报 No such file or directory。

根因：文件开头有 UTF-8 BOM（ef bb bf），shebang 被污染。靠 bash ci/validate.sh 绕过才没暴露。

修复：去除 BOM。

效果：直接执行正常。

几个值得深挖的点

缺陷 1 和 4 是同一类问题

“漏维度"和"漏 RAG 维度"本质都是模型在复杂输出时的惯性遗漏——prompt 定义齐全，但模型生成时按训练分布的惯性输出，会漏后加的或非典型的维度。修复手法一致：硬约束"逐编号输出+末尾覆盖统计+缺项即校验失败”。

这类缺陷只有真调 LLM 才发现——结构断言查的是"prompt 里有没有定义 11 维度"，查不出"模型会不会真输出 11 维度"。

缺陷 2 和 3 是 prompt 模糊导致的模型误判

“信息不足"和"只承诺不输出"都不是模型能力问题，是 prompt 指令模糊——没定义"信息充分"标准、没硬约束"必须直接输出”。模型按字面理解走了最保守的路线。

修复手法是把模糊指令改精确：明确判定标准、加硬约束、给反例（“询问确认不得替代直接输出”）。

缺陷 7 是长期压测才暴露的

单轮或几轮迭代看不出版本清理丢数据——要跑 10 轮，让版本清理真触发删旧版本，才暴露早期唯一用例丢失。这是长期压测的价值：单次正确 ≠ 长期稳定。

缺陷 8 的诚实标注

std-case-001 跑不过的根因是评测器架构限制（纯 LLM 评测器看不到文件），不是 prompt 缺陷。我们选择标注 requires_e2e: true 从基线排除，而非改评测器注入文件数据自欺提分。真实用户调 skill 时 AI 会真读文件——那才是最终裁判。

项目地址

https://github.com/Kokxi/qa-team-skills.git（MIT 协议）

一句话总结

让测试团队拥有统一的 AI 辅助标准，不做各自为政的 Prompt 孤岛。

---

下一篇：几个关键设计决策（为什么用 LLM-as-judge、为什么用 DeepSeek、API key 安全）+ 最终交付的验证体系 + 给同类项目的 3 条建议。