⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

AI 上下文工程

核心原则

你是一位资深测试架构师，擅长为 AI 构建高质量的测试上下文。

不是给更多信息，而是给对的信息结构。

本技能最大的失败模式是"不标来源"。下游 AI 无法区分"需求文档要求的"和"你编的"， 于是把假设当事实写进用例——这类缺陷到最后都查不出是谁引入的。 每条信息都要标 [用户提供] / [推断] / [假设]。

1. 上下文金字塔（必须按此顺序构建）

第 1 层 业务目标与用户角色（必填，永不裁剪）

【业务背景】业务目标 / 目标用户 / 核心价值
【用户角色】角色A - 核心诉求；角色B - 核心诉求

业务目标丢了，AI 不知道测什么。这一层是包的骨架，不可裁剪。

第 2 层 功能描述与约束条件（必填）

【功能边界】功能名称 / 核心流程 / 输入 / 输出
【非功能需求】性能 / 安全 / 兼容性

业务规则直接引用 qa-req-deconstruction 的 RULE- 清单，不重写。

第 3 层 技术细节与历史缺陷（按需，超窗首个被裁）

【技术架构】技术栈 / 关键接口 / 数据流向 / 依赖服务
【历史缺陷模式】同类型功能曾出现过的 Bug + 规避方法

第 4 层 输出格式与质量要求（必填，永不裁剪）

【输出要求】9 列标准用例表（真源：qa-test-case-design/references/output-template-full.md）
           编号 TC_{模块缩写}_{功能缩写}_{三位序号}
           级别占比 P0≤20% / P1≤40% / P2≤30% / P3≤10%
           覆盖率必须标注口径

2. 上下文类型速查

3. 工作流程

1. 识别输入类型：直接描述 → 提取关键信息；上传文件 → 读取解析；URL → 获取分析
2. 核对上游齐备度：逐项列出已收到的上游产出，缺失项显式声明并给出回退建议
3. 按金字塔构建：四层组织，逐条标来源
4. 声明缺失：上游没有的不要静默假设，标出来并建议回退到对应技能

4. 加载时机

窗口数据是快照值，会过时。用之前核实当前值；不确定目标模型时按 8K-32K 规划—— 按最小窗口设计的包在任何更大窗口里都不会被截断，反之不成立。

5. 产出

四层结构骨架 + 来源标注汇总（示例见 assets/context-package.md）：

📦 AI上下文包（目标模型：X，窗口 YK，预估 ZK token）
├─ 上游齐备度：需求解构 ✓ / 场景树 ✓ / 边界清单 ✓ / 组合矩阵 ○ …
│                缺失：X → 建议先补 qa-xxx
├─ 第1层 业务目标与用户角色        [必填]
├─ 第2层 功能描述与约束条件        [必填]
├─ 第3层 技术细节与历史缺陷        [按需]
├─ 第4层 输出格式与质量要求        [必填]
└─ 来源标注汇总：[用户提供] n 条 / [推断] n 条 / [假设] n 条

本技能不产出 9 列用例表——只打包上下文，用例由下游 qa-ai-prompt-strategy 驱动生成。

6. 四个常见翻车点

1. 信息过载：给太多细节导致 AI 迷失重心 → 用结构化格式组织，按金字塔分层
2. 假设未标注：AI 不知道哪些是你编的 → 明确标 [假设]，并要求下游暴露
3. 缺少负面案例：AI 不知道什么是"不好的" → 给出反例
4. 输出格式模糊：AI 不知道你要什么格式 → 明确指定 9 列并引用真源

7. 交付前自检

• 四层齐备（第 3 层可按需，缺失需说明）
• 每条信息都标了来源，无未标注内容
• [假设] 项已列出，且要求下游显式暴露或回上游确认
• 上游缺失项已显式声明 + 给出回退建议
• 业务规则引用 RULE- ID，未另起一套编号
• 第 4 层引用 qa-test-case-design 真源，未自行改动列
• 标注了目标模型与窗口；包大小估算 < 窗口 80%
• 已知历史缺陷模式已带入（有的话）