这是三篇复盘的最后一篇。前两篇讲了验证体系建设和 9 个真实缺陷的修复，本篇讲几个关键设计决策、最终交付的验证体系、以及给同类 AI skill 项目的 3 条建议。

一、几个关键设计决策

1. 为什么用 LLM-as-judge 而非正则断言

正则能查"有没有 11 个维度行"，但查不出"维度分析得对不对"。LLM-as-judge 能理解语义——如判定"模型说 dependencies:[‘step_1’] 但没真引用第一步结果"这种深层问题。

代价是 judge 本身有随机性，需低温（temperature=0.3）+ 结构化 JSON 输出约束。我们的 judge system prompt：

你是一个严格的测试质量评审员。你会收到一份 AI 生成的测试产出和一条断言。
你的任务：判断该产出是否满足这条断言。
只输出一行 JSON：{"pass": true, "reason": "简要说明"}

实测 DeepSeek 作为 judge 能稳定输出结构化判定，且能指出具体问题（如"TC014 缺设计方法"“模型只承诺但未实际输出表格”）。

2. 为什么排除 std-case-001 而非改评测器

这条 eval 的断言"加载 standards.json"依赖记忆模块文件 I/O。纯 LLM 评测器只发 prompt 不跑文件，模型在评测环境看不到 standards.json 内容。

改评测器注入文件数据能让分数好看，但那是为提分改工具——真实用户调 skill 时 AI 会真读文件（那是真文件 I/O，不是评测模拟）。所以选择诚实标注架构限制，从基线排除，而非改评测器自欺。

这条 eval 改用 ci/test-memory-e2e.sh 的端到端模拟器验证——模拟器复刻记忆模块规则，真跑文件读写，能验证规范库→用例全链路。不同工具查不同层面，各司其职。

3. 为什么用 DeepSeek 而非免费模型

我们试过三个模型：

模型	准确率	问题
cohere/north-mini-code:free	41%	免费，但在长 system prompt 下产出为空，能力上限低
kimi-for-coding	3/5（仅冒烟）	reasoning 模型，reasoning_content 占大量 token，需 max_tokens≥16k；且 API 配额秒级限流
DeepSeek deepseek-chat	94.3%	非 reasoning、产出完整、¥0.001/k token

DeepSeek 一轮全量评测约 53k token = 5 分钱。极便宜，适合日常回归。免费模型首跑暴露了缺陷（41% 基线有价值），但产出质量上限低——prd 和 std-case 两条直接产出为空。DeepSeek 非 reasoning、产出完整、价格极低，是评测的最佳选择。

4. API key 安全

评测器从环境变量读 key，绝不写入文件。每次 commit 前 grep 检查暂存区有无真 key（示例占位符 sk-... 不算）。归档报告里只存 token 用量不存 key。

这套纪律很重要——我们在多轮调试中用过 Kimi、OpenRouter、DeepSeek 三个 key，任何一次把 key 写进脚本或归档报告都会泄露到 git 历史。靠环境变量 + commit 前检查纪律，13 个 commit 无一次泄露。

二、最终交付的验证体系

bash ci/validate.sh            # 1. 静态结构（< 1s）
bash ci/run-evals.sh           # 2. 触发 38/38 + 契约 37/37
bash ci/test-memory-e2e.sh     # 3. 记忆模块 14/14
bash ci/test-memory-stress.sh  # 4. 长期压测 6/6
python ci/run_llm_eval.py      # 5. 真·LLM 端到端（7 条 eval，94.3%）
# evals/human-review/README.md  6. 人工双盲（方案就绪，发版前执行）

前 5 套自动化全过 = 质量基线达标。发版前再做一次人工双盲（5 维度评分+双盲流程+版本门槛），金字塔顶端靠人判定"内容是否真有用"。

各套脚本的成本

脚本	耗时	费用
validate.sh	< 1s	免费
run-evals.sh	~ 2s	免费
test-memory-e2e.sh	~ 1s	免费
test-memory-stress.sh	~ 2s	免费
run_llm_eval.py	~ 95s	¥0.05（DeepSeek）
人工双盲	~ 4h	2 人 × 4h 人工

前 4 套免费秒级，第 5 套 5 分钱，第 6 套人工 4 小时——性价比梯度合理，日常回归用前 5 套，发版前加第 6 套。

三、给同类 AI skill 项目的 3 条建议

1. 评测数据集不等于评测

多数项目有 evals/ 目录但没 runner。把 eval 真跑起来，量化断言，才有基线。

我们的 evals/functional-eval.json 早就存在，但一直只是"定义"没"执行"。直到写了 ci/run-evals.sh 和 ci/run_llm_eval.py，才把数据集变成真评测，量化出 41% 基线。没有 runner 的 eval 就是死文件。

2. 结构断言查不出内容缺陷

prompt 定义齐全 ≠ 模型会遵守。必须真调 LLM 跑一遍，用 LLM-as-judge 判内容质量。

我们的 37 条契约断言全过（prompt 定义都对），但 LLM 评测只 41%——模型实际生成时漏维度、误判信息不足、只承诺不输出。这些只有真调 LLM 才发现。结构断言是必要的第一步，但远远不够。

3. 诚实标注架构限制

某条 eval 跑不过若是评测器架构问题，标注排除而非改评测器自欺。

我们的 std-case-001 跑不过是因为纯 LLM 评测器看不到文件。标注 requires_e2e: true 从基线排除，改用端到端模拟器验证。为提分改评测器注入文件数据是自欺——真实用户行为才是最终裁判，评测器要诚实反映用户场景。

四、最终成果

指令	准确率	状态
/qa-prd	5/5	✅ 完整通过（11 维度全必输出）
/qa-case	9/9	✅ 完整通过（6 类型全覆盖+格式校验）
/qa-bug	5/5	✅ 完整通过（信息充分判定标准）
/qa-report	4/4	✅ 完整通过
/qa-team	4/4	✅ 完整通过（询问确认不得替代直接输出）
/qa 入口	3/3	✅ 完整通过
/qa-agent	5/5	✅ 完整通过（末尾维度编号清单逐项确认）
/qa-explore	—	7 条指令全覆盖

7/7 eval 完整通过（排除 requires_e2e 项），94.3% 准确率。剩 2 条随机波动缺陷是 DeepSeek 在复杂输出时的能力上限，约束已足够，再强化收益有限。

这套验证脚本本身比很多生产 skill 都完备——多数 skill 项目只有 demo 没有评测。我们把"评测数据集"变成"真评测"，用量化断言逼出 prompt 暗坑，从 41% 修到 94.3%。这不是终点——剩 2 条随机波动缺陷是模型能力上限，下次换更强模型或许能再提。

完整代码：ci/ 目录下 6 套脚本 + evals/ 评测数据集，MIT 协议，可直接复用到你的 AI skill 项目。

项目地址

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

一句话总结

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