eiway112 技能质量测试方法论
核心理念：以源文件为唯一真相源，逐行核验每一个事实声明。
适用技能类型
本方法论适用于以下类型的知识密集型技能：
| 类型 | 特征 | 测试重点 |
|---|---|---|
| 数据表格型 | 含大量数值、标准编号 | 每个数值和编号的行级核验 |
| 方法论型 | 教授思维框架 | 框架完整性、推理链正确性 |
| 审核工具型 | 检测其他内容的错误 | 错误检出率、分类准确性 |
| 模板输出型 | 按固定模板生成响应 | 模板格式合规性 |
五阶段测试流程
阶段一：全量读取
- 列出技能目录下所有文件
- 逐个读取全部源文件（不可跳读，不可摘要）
- 记录文件清单：文件名、行数、大小、最后修改日期
- 建立文件关系图：哪些文件互相引用、引用路径是否正确
阶段二：测试用例设计
设计原则：每种输出场景至少一个用例，每种边界条件至少一个用例。
2.1 覆盖矩阵
| 维度 | 必须覆盖 | 核验方法 |
|---|---|---|
| 输出模板 | 每种模板类型至少1个用例 | 对照SKILL.md中的模板定义 |
| 响应层级 | 每层至少1个用例（如适用） | 对照SKILL.md中的层级定义 |
| 跨技能路由 | 每条路由规则至少1个用例 | 对照路由规则定义 |
| 标准引用 | 高频标准+易混淆标准 | 核对编号、年份、名称 |
| 红线压力 | 至少2个对抗性用例 | 检查是否遵守红线规则 |
| 免责声明 | 每个用例均检查 | 逐句比对SKILL.md定义文本 |
2.2 测试用例模板
测试编号：T[N]
场景：[正常/边界/异常/对抗]
用户查询：[具体文本]
预期响应要点：
- [应包含的标准编号及数值]
- [应使用的输出模板]
- [应触发的路由规则]
核验锚点：[源文件名+行号，用于逐条验证]
2.3 对抗性测试设计
构造以下类型的查询来暴露技能薄弱环节：
| 对抗类型 | 查询设计思路 | 预期行为 |
|---|---|---|
| 诱导编造 | 条件不完整，诱导给出具体数值 | 应承认不确定并指明查阅路径 |
| 过时标准 | 查询已废止标准的最新版本 | 应提示新标准和替代关系 |
| 跨领域越界 | 问超出技能范围的问题 | 应识别并路由到正确技能 |
| 矛盾前提 | 查询中嵌入错误假设 | 应纠正错误假设后再回答 |
| 品牌诱导 | 询问"哪个品牌最好" | 应拒绝推荐品牌 |
阶段三：并行执行与逐项核验
3.1 执行方式
使用平台可用的并行执行能力启动独立测试用例：
- 每个子代理负责1-2个测试用例
- 子代理必须先读取全部源文件再模拟响应
- 模拟响应中的每个事实声明必须标注依据（文件+行号）
3.2 核验清单
对每个模拟响应逐项核验：
数据准确性
- 标准编号格式正确（GB/GB/T/JGJ/JC/T等）
- 标准年份正确（对照源文件行号）
- 标准名称完整准确
- 数值与源文件完全一致（含单位、精度）
- 边界符号正确（≥/>/≤/< 与源文件对应）
格式合规性
- 使用了正确的输出模板
- 模板结构完整（所有必填章节）
- 响应层级正确（Layer 1/2/3）
- 跨技能路由触发正确
红线合规性
- 未编造源文件中不存在的数据
- 未推荐具体品牌
- 不确定处加了限定语或查阅路径
- 免责提示文本与SKILL.md定义完全一致（逐句比对）
内部一致性
- 同一指标在不同文件中表述一致
- 标准编号年份在多处引用中一致
- 免责提示文本在所有文件中一致
- 示例文件中的内容与主表格一致
详细核验规则见 reference.md。
阶段四：修正与回归
4.1 精确修正
- 使用平台可用的精确编辑能力修改，一次只改一处
- 每次修正后搜索相关关键词验证修改结果
- 记录修正日志：修正前内容、修正后内容、依据、文件+行号
4.2 完整性扫描（修正后必做）
核心原则：修复N项时，必须验证修复是否覆盖了全部同类项，而非只验证已修复的N项。
每次修正后，立即执行以下完整性扫描：
同表/同节全量扫描：当修复涉及某个表格或章节中的某些行时，必须重新读取该表格/章节的全部行，确认所有行都遵循修正后的规则。逐行检查：
- 是否存在未被修复但存在同样问题的行？
- 修复后的模式是否在整个表格/章节内一致？
- 是否存在"相邻遗漏"（紧挨着已修复行的未修复行）？
同模式全文件扫描：当修复涉及一种格式规则（如状态标识系统、免责文本格式、编号格式等）时，搜索该规则覆盖的所有位置，确认无遗漏：
- 搜索旧模式关键词：确认旧模式在全文已彻底清除
- 搜索新模式关键词：确认新模式的覆盖数量与预期一致
- 计数比对（M + R = N）：新模式匹配数 M + 旧模式残留数 R = 修复前旧模式总数 N，要求 R = 0
跨文件涟漪检查：当修复涉及一个标准编号、数值或状态变更时，检查其他文件中是否引用了同一数据：
- 搜索被修改的标准编号/数值在所有文件中的出现位置
- 逐处确认是否需要同步更新
4.3 回归测试
修正并确认完整性后，重新执行受影响的测试用例：
- 修正解决了原问题
- 修正未引入新问题
- 相关联的其他引用未受影响
- 同一表格/章节中的所有行都通过了与修复行相同的检查标准
4.4 回归失败模式清单
以下三类回归失败模式必须在每次修正后排查：
| 失败模式 | 描述 | 检测方法 | 典型案例 |
|---|---|---|---|
| 部分修复 | 表格/列表中有N项需修复，实际只修复了部分 | 修复后读取全表逐行检查 | Section 9共8行只修了5行，遗漏3行 |
| 涟漪遗漏 | 一处数据变更未同步到其他引用位置 | 搜索变更数据在所有文件中的出现 | A文件修了标准年份，B文件同一标准年份未改 |
| 模式残留 | 修复后同一结构内新旧模式共存 | 搜索旧模式关键词确认全文已清除 | 表格中部分行用🟢标识，部分行仍用纯文本 |
阶段五：报告与打包
5.1 测试报告模板
## [技能名称] 测试报告
**测试日期**：YYYY-MM-DD
**测试范围**：[文件清单]
### 测试用例设计
| 编号 | 场景 | 覆盖维度 | 核验项数 |
|------|------|---------|---------|
### 各用例核验结果
（按用例分节，逐项列出通过/不通过/警告）
### 发现并修正的问题
| 编号 | 文件 | 位置 | 问题 | 修正 | 依据 |
|------|------|------|------|------|------|
### 回归验证记录
| 修正编号 | 完整性扫描范围 | 旧模式残留数 | 新模式覆盖数 | 跨文件涟漪检查 | 结论 |
|---------|--------------|------------|------------|--------------|------|
| F1 | [表格/章节全量行数] | 0 | [预期数] | [涉及文件列表] | 通过/发现遗漏 |
### 改进建议
| 编号 | 类型 | 说明 | 处理状态 |
|------|------|------|---------|
### 测试结论
| 统计项 | 数值 |
|--------|------|
| 核验项总数 | X |
| 通过 | X |
| 不通过 | X |
| 警告 | X |
| 源文件修正 | X处 |
5.2 打包发布
- 仅打包技能定义文件（SKILL.md + 参考文件）
- 排除非技能文件：node_modules、.git、.env、数据库文件、残留空文件（nul等）
- 用 Compress-Archive 创建 .zip，重命名为 .skill
- 用 python zipfile 验证包内文件完整性
- 使用独立会话或子代理加载测试（功能冒烟测试），确认：
- 技能成功加载无报错
- 核心功能响应正确
- 免责提示正常附加
接口契约（IC-12 接收方）
本技能作为 QA 测试工具的接收方，遵循接口契约 IC-12（任何技能 → QA 测试工具）。完整 Schema 见 ../shared/interface-contracts.md §4.4 IC-12。
请求参数（与 IC-12-Request Schema 字段集一致，Schema 为 additionalProperties:false）：
| 参数 | 必填 | 说明 |
|---|---|---|
| 被测技能 | 是 | 技能目录名（与 skills 目录一致） |
| 测试类型 | 是 | 首发测试 / 回归测试 / 跨技能一致性（按 IC-12 Schema 枚举） |
| 触发来源 | 是 | 发起方技能标识或 CG 编号，用于回归追溯 |
| 测试范围 | 否 | 文件清单，缺省为技能目录全部文件（阶段一全量读取） |
| 关注项 | 否 | 红线对抗/数据表格/路由规则等专项关注，缺省按覆盖矩阵全覆盖 |
响应内容：
| 字段 | 说明 |
|---|---|
| 测试结论 | 通过 / 有条件通过 / 不通过（枚举，不得自由表述；未执行用例不得计入通过） |
| 统计 | 核验项总数、通过、不通过、警告、源文件修正数 |
| 测试报告路径 | 报告落位路径（记录/ 或 成果/ 按项目规范） |
| 未决事项 | 未执行用例与原因、待人工确认项（存在时必返回） |
必填参数缺失时，返回"参数不足"并列出缺失项，不得假设后继续。
红线约束（禁止行为）
以下为本技能已注册红线摘要（全局编号），完整定义以 ../shared/redlines-registry.md §七为准：
| 编号 | 红线 | 摘要 |
|---|---|---|
| QA-R-P0-1 | 严禁伪造测试结果 | 未执行、未记录或无证据的测试不得标注为通过 |
| QA-R-P1-1 | 严禁测试集未执行却宣称全量完成 | 全量测试必须列出计划、执行、补跑、未执行状态 |
| QA-R-P1-2 | 严禁跳过红线触发测试 | 被测技能的 P0/P1 红线必须至少有一个对抗性用例 |
| QA-R-P1-3 | 严禁忽略回归来源 | 修复项必须能追溯到问题编号、修改文件和回归结论 |
| QA-R-P2-1 | 必须使用统一测试状态 | 状态限定为：计划/已执行/补跑通过/未执行/不适用 |
| QA-R-P2-2 | 必须区分报告结论与证据 | 索引只写最终状态，过程证据放报告正文 |
测试包模板
测试包最小构成（缺一即测试包不完整）：
| 构成 | 内容要求 | 对应阶段 |
|---|---|---|
| 用例集 | 每个用例含编号、场景、预期响应要点、核验锚点（文件+行号） | 阶段二 |
| 覆盖矩阵 | 按 §2.1 六维度逐项标注覆盖用例编号 | 阶段二 |
| 红线对抗用例 | 被测技能 P0/P1 红线每条至少 1 个对抗用例（合计不少于 2 个） | 阶段二 |
| 回归记录 | 修正项的问题编号、修改文件、回归结论链路 | 阶段四 |
测试报告按阶段五 §5.1 模板输出，结论字段使用 IC-12 响应枚举。
与 GS/SSCV 的触发关系
| 场景 | 动作 | 契约 |
|---|---|---|
| 测试发现源文件错误并已修正 | 触发 GS 三层同步，并在 change-governance.md 登记 CG 编号 | IC-13 |
| 条文级内容取真存疑（疑似编造/版本冲突） | 转 SSCV 标准条文核验工具核验后再回归 | IC-11 |
| 标准版本有效性存疑 | 转 SR 标准复核工具核验 | IC-07 |
跨技能协作原则
当测试涉及以下专项技能时，应优先调用对应技能进行协同测试：
| 场景类型 | 优先调用技能 | 说明 |
|---|---|---|
| 装配式隔墙方案测试 | prefab-partition-wall-solution | 隔墙构造、隔声耐火性能、造价数据等专项测试 |
| 装配式装修材料综合咨询测试 | prefab-interior-materials-expert | 内装材料规范、工艺标准、质量验收等综合测试 |
| 标准复核测试 | prefab-standards-reviewer | 规范标准引用准确性、版本有效性等专项复核 |
| 防水工程测试 | waterproofing-expert（建筑装饰装修辅材技能合集） | 防水材料、构造做法、验收标准等专项测试 |
标准免责提示
每次测试报告末尾自动附加以下标准免责文本：
本回复基于知识库整理时间点的技术标准与行业通用实践整理，仅供技术参考。标准规范以官方发布的现行有效版本为准，引用内容可能存在时效性限制，重要项目请务必通过官方渠道核实最新版本。具体项目的设计、施工及验收应依据项目所在地适用的法律法规及标准规范执行，并由具备相应资质的专业人员负责。涉及结构安全、消防安全等重大事项的，请务必咨询相关专业机构。
常见问题模式
| 模式 | 检测方法 | 示例 |
|---|---|---|
| 标准年份过时 | 交叉比对多文件中同一标准的年份 | GB 55038-2024应为2025 |
| 状态标记滞后 | 对照实施日期和当前日期 | 已实施仍标"即将实施" |
| 数量统计不一致 | 实际计数 vs 声明数量 | "55项"实际56项 |
| 免责文本不完整 | 逐句比对SKILL.md定义 | 缺少"引用内容可能存在时效性限制" |
| 表头与数据列不匹配 | 列数对照 | 表头6列数据只有5列 |
| 边界符号混用 | 搜索≥和>的使用 | "≥"应为">" |
| 指标体系混淆 | 确认标准使用的指标类型 | GB 55038用DnT,w+C非Rw+C |
| 跨文件引用断裂 | 验证A文件引用B文件的路径 | reference.md不存在 |
| 示例与主表不一致 | 对比示例数值和主表格数值 | 示例写45dB主表写48dB |
| 部分修复遗漏 | 修复后读取全表/全节逐行扫描 | Section 9共8行只修5行，遗漏3行 |
| 格式模式残留 | 搜索旧模式确认全文清除 | 部分行用emoji标识，部分行仍用纯文本 |
注意事项
- 源文件是唯一真相源：核验以源文件为准，不以"常识"或"网上搜索结果"为准
- 每个声明都要有锚点：模拟响应中的每个事实必须能追溯到具体文件和行号
- 并行测试提效：用多个独立测试执行单元并行执行独立测试用例
- 修正必须精确：一次改一处，改完立即验证，避免连锁错误
- 回归必须完整：修正后不能只验证被修的那几行，必须对修复涉及的整个表格/章节/模式执行全量扫描，确认无部分修复、无模式残留、无涟漪遗漏（详见阶段四 §4.2）
- 区分"错误"与"警告"：错误=与源文件不一致（必须修复），警告=可改进但不影响正确性
- 改进建议一并处理：测试报告中列出的改进建议应当场处理，不留尾巴
- 打包前清理：排除非技能文件（.git、node_modules、.env、数据库、空文件）
- 打包后必测：打包后的.skill文件必须做功能冒烟测试，确认加载和响应正常
双平台动作映射见 ../platform-adapter-reference.md。