极点宏观|Financial Cloud Cloud · 构建文章
与 Kiro 同行:蚀刻工艺窗口风险测试自动化工作坊
时长: 2 小时
目标受众: 负责构建半导体工艺控制服务与测试自动化的专业开发人员
主要 AWS AI 服务: Kiro
工作坊重点: 利用 Kiro 辅助测试设计、边缘情况生成,以及针对蚀刻工艺窗口风险代码的审查
独立成果: 开发人员将建立一个测试先行(Test-first)的工作流程,并使用 Kiro 来验证蚀刻腔体(chamber)风险映射、工艺窗口漂移事件、自动化控制滑移,以及确保既有晶圆厂事件的不退化(non-regression)。
仅限教育工程研讨会。这是一项软件架构练习,而非流程发布建议。
摘要
本工作坊将引导开发人员完成由 Kiro 辅助的蚀刻工艺窗口风险映射测试自动化。参与者将建立测试先行计划、实施 TypeScript 映射器(mapper)、强化生成出的薄弱测试,并涵盖遗漏字段、时间线语义、多因子数组与不退化行为,同时完整保留原始遥测数据。其余实验室将处理边界值审查与调试指引,在不增加生产环境持久化学习练习的计算或宽泛重构的前提下,安全地进行实施。
1. 工作坊目标
本工作坊提供了聚焦于 Kiro 辅助测试的实施开发实验室。开发人员不会建立一个完整的应用程序,而是使用 Kiro 来扩展围绕蚀刻工艺窗口风险映射器的测试。实验室将教导如何向 Kiro 要求有意义的测试、识别有缺陷的薄弱测试、提升覆盖率并保护事件语义。
此场景聚焦于电浆蚀刻腔体(plasma etch chamber),其中的压力、射频(RF)功率变异、终点信号稳定度(endpoint signal stability)、气体流量与腔体温度等可能会接近工艺控制边界。代码示例会将原始来源数值直接进行持久化(persistence),以便后续供工艺工程分析使用。
2. 学习目标
开发人员将学习如何:
● 在实施前使用 Kiro 生成测试计划。
● 为蚀刻工艺窗口风险事件建立 TypeScript 映射器。
● 为正常路径案例(positive cases)、异常路径案例(negative cases)、遗漏字段、时间线字段与多因子数组生成测试。
● 要求 Kiro 对薄弱的测试进行批判与评估。
● 为专业开发人员加入不依赖表格且具备高可读性的测试案例。
● 使用审查提示词使测试与制造风险保持一致。
3. 实验室议程
| 时间 | 实验室 | 开发人员产出 |
|---|---|---|
| 0:00-0:10 | 实验室 1:测试先行规格 | 来自 Kiro 的测试计划 |
| 0:10-0:25 | 实验室 2:蚀刻映射器 | etchRiskMapper.ts |
| 0:25-0:45 | 实验室 3:核心测试 | 正常与异常路径测试 |
| 0:45-1:05 | 实验室 4:弱测试审查 | Kiro 审查输出结果 |
| 1:05-1:25 | 实验室 5:边缘情况测试 | 遗漏字段与空因子测试 |
| 1:25-1:40 | 实验室 6:时间线测试 | 事件、计算与因子时间 |
| 1:40-1:52 | 实验室 7:不退化测试 | 既有晶圆厂事件行为 |
| 1:52-2:00 | 实验室 8:最终覆盖率审查 | 通过/失败(PASS/FAIL)覆盖率报告 |
4. 实验室 1 — Kiro 测试先行提示词
提示词规则 1
提示词目标: 在实施之前要求 Kiro 提供测试覆盖范围。
提示词示例
建立一個用於蝕刻製程視窗風險映射器的測試計劃。該映射器應僅針對 ETCH_PROCESS_WINDOW_RISK 事件回傳紀錄集,並對無關的晶圓廠事件回傳 null。
AI 生成结果: Kiro 可能会生成一个简单的正常路径(happy-path)测试以及一个无关的事件测试。
说明: 这是一个合理的开始,但对于半导体工艺风险功能来说还不够。
为何结果不够好: 它可能会遗漏多因子数组处理、选填字段行为、时间语义以及原始遥测数值的保留。
提示词规则 2
为何规则 2 可以修复上述问题: 这将测试计划扩展到了包含工艺工程风险。
提示词示例
擴充測試計劃。包含兩個 risk_factors、遺漏 risk_factors、遺漏選填欄位、獨立彼此獨立的 event_time 與 risk_compute_time、獨立獨立的 factor_time,以及對 EQUIPMENT_ALARM 和 AUTOMATION_CONTROL_COMMAND 的拒絕。
AI 生成结果: Kiro 应该会产生一个更强大的测试计划,并包含覆盖率分类。
说明: 测试计划现在反映了真实事件流(event-stream)的边缘情况。
系统设计决策
● 测试先行(Test-first)开发可协助开发人员在接受自动生成的实施之前先定义行为。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时(save-time)、测试时(test-time)及审查时(review-time)的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式(operational failure mode)连结,避免增加不必要的平台复杂度。
● 晶圆厂事件通常是不完整或部分填写的,因此需要针对选填字段(optional-field)进行测试。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据(source evidence)与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性(traceability)、可重复性(reproducibility)及生产环境不退化(production non-regression)负责。这样一来,系统将更容易被审计,且演进时更具安全性。
● 必须对时间语义进行测试,因为事件顺序对于事件根因分析(incident analysis)至关重要。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务(engineering practice)。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构(refactors)或隐含的假设之中。
5. 实验室 2 — 生成蚀刻风险映射器
提示词示例
建立 src/etchRiskMapper.ts。除非 event_type 為 ETCH_PROCESS_WINDOW_RISK,否則回傳 null。對於符合資格的事件,每個 risk_factors 陣列項目各回傳一個 riskSummary 與一個 riskFactor。直接儲存原始來源數值或 null。請勿計算或轉換數值。
预期代码
export type EtchRiskRecordSet = {
riskSummary: Record<string, string | null>;
riskFactors: Record<string, string | null>[];
};
export function mapEtchRiskEvent(message: any): EtchRiskRecordSet | null {
if (message?.event_type !== "ETCH_PROCESS_WINDOW_RISK") {
return null;
}
const riskSummary = {
risk_event_id: message.risk_event_id || null,
fab_id: message.fab_id || null,
tool_id: message.tool_id || null,
chamber_id: message.chamber_id || null,
wafer_lot_id: message.wafer_lot_id || null,
recipe_version: message.recipe_version || null,
process_step: message.process_step || null,
process_window_risk_level: message.process_window_risk_level || null,
etch_uniformity_risk: message.etch_uniformity_risk || null,
drift_velocity: message.drift_velocity || null,
yield_exposure_level: message.yield_exposure_level || null,
automation_control_slip_probability: message.automation_control_slip_probability || null,
event_time: message.event_time || null,
risk_compute_time: message.risk_compute_time || null
};
const riskFactors = (message?.risk_factors || []).map((factor: any) => ({
factor_id: factor.factor_id || null,
risk_event_id: message.risk_event_id || null,
sensor_name: factor.sensor_name || null,
sensor_value: factor.sensor_value || null,
control_boundary: factor.control_boundary || null,
unit: factor.unit || null,
risk_contribution: factor.risk_contribution || null,
factor_time: factor.factor_time || null
}));
return { riskSummary, riskFactors };
}
业务逻辑说明: 映射器捕获蚀刻工艺窗口风险证据,以供后续工艺工程分析使用。
代码逻辑说明: 它使用精确的事件匹配、建立摘要、映射所有风险因子,并完整保留来源原始值。
预期结果: 符合资格的事件将返回记录集;无关的事件则返回 null。
系统设计决策
● 精确的事件匹配可规避处理无关的晶圆厂事件。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。
● 原始字符串存储使遥测数据得以与串流消息进行匹配。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。
● 仅限映射器(mapper-only)的实验室将测试与数据库考虑相互隔离。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。
6. 实验室 3 — 核心测试
提示词示例
為 mapEtchRiskEvent 生成 Vitest 測試。包含一個具有兩個 risk_factors 的合規事件,以及一個無關的設備警報。
预期测试代码
import { describe, expect, it } from "vitest";
import { mapEtchRiskEvent } from "../src/etchRiskMapper.js";
describe("mapEtchRiskEvent 核心行為", () => {
it("映射具有兩個因子的蝕刻製程視窗風險事件", () => {
const result = mapEtchRiskEvent({
event_type: "ETCH_PROCESS_WINDOW_RISK",
risk_event_id: "etch_risk_evt_001",
fab_id: "FAB-HK-ADV-01",
tool_id: "ETCH-CHAMBER-12",
chamber_id: "CHAMBER-B",
wafer_lot_id: "LOT-HPC-55210",
recipe_version: "ETCH-7NM-R19",
process_step: "PLASMA_ETCH",
process_window_risk_level: "HIGH",
etch_uniformity_risk: "ELEVATED",
drift_velocity: "0.041",
yield_exposure_level: "ELEVATED",
automation_control_slip_probability: "0.67",
event_time: "2026-06-26T10:20:00+08:00",
risk_compute_time: "2026-06-26T10:20:02+08:00",
risk_factors: [
{
factor_id: "etch_factor_pressure_001",
sensor_name: "chamber_pressure",
sensor_value: "14.8",
control_boundary: "15.0",
unit: "mTorr",
risk_contribution: "HIGH",
factor_time: "2026-06-26T10:19:58+08:00"
},
{
factor_id: "etch_factor_rf_002",
sensor_name: "rf_power_variation",
sensor_value: "2.7",
control_boundary: "3.0",
unit: "percent",
risk_contribution: "MEDIUM",
factor_time: "2026-06-26T10:19:59+08:00"
}
]
});
expect(result?.riskSummary.risk_event_id).toBe("etch_risk_evt_001");
expect(result?.riskFactors).toHaveLength(2);
expect(result?.riskFactors[0].risk_event_id).toBe("etch_risk_evt_001");
});
it("對設備警報事件回傳 null", () => {
expect(mapEtchRiskEvent({ event_type: "EQUIPMENT_ALARM" })).toBeNull();
});
});
业务逻辑说明: 这些测试涵盖了主要的正常路径,以及对无关事件的拒绝。
代码逻辑说明: 测试会直接调用映射器并查看返回的记录集。
预期结果: 测试通过。
系统设计决策
● 包含双因子的正常路径测试可验证数组处理。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。
● 警报异常路径测试保护了无关运营事件的语义。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及运营不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。
● 直接测试映射器具有快速且具备确定性(deterministic)的特点。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。
7. 实验室 4 — 弱测试审查
开发人员任务
要求 Kiro 审查一个薄弱的测试。
薄弱的测试
it("works", () => {
const result = mapEtchRiskEvent({ event_type: "ETCH_PROCESS_WINDOW_RISK" });
expect(result).toBeTruthy();
});
提示词示例
審查這個用於蝕刻製程視窗風險映射器的測試。解釋它為何過於薄弱,並建議更好的斷言。
预期 Kiro 结果
此測試過於薄弱,因為它僅檢查結果是否存在,並未驗證摘要欄位、因子紀錄、父子關聯性、選填欄位行為或時間線語意。
更好的斷言應該要檢查 risk_event_id、因子數量、因子的 risk_event_id 關聯、event_time、risk_compute_time 以及選填欄位的 null 處理。
业务逻辑说明: 单纯的 truthy 断言无法证明工艺风险数据对于调查具有实质价值。
代码逻辑说明: 该测试未能确实检查映射的输出内容。
预期结果: 开发人员将薄弱的断言替换为字段级别的检查。
系统设计决策
● 测试质量比测试数量更重要。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。
● 字段级别的断言保护了持久化契约(persistence contract)。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。
● Kiro 审查能引导开发人员去改善自动生成的测试。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。
8. 实验室 5 — 遗漏字段与空因子测试
提示词示例
為遺漏選填欄位與遺漏 risk_factors 的情況新增測試。映射器應回傳一個包含 null 選填欄位且零個因子的摘要。
预期测试
it("當缺少選填的蝕刻摘要欄位時儲存 null", () => {
const result = mapEtchRiskEvent({
event_type: "ETCH_PROCESS_WINDOW_RISK",
risk_event_id: "etch_missing_fields",
risk_factors: []
});
expect(result?.riskSummary.fab_id).toBeNull();
expect(result?.riskSummary.tool_id).toBeNull();
expect(result?.riskSummary.chamber_id).toBeNull();
expect(result?.riskFactors).toHaveLength(0);
});
it("將遺漏的 risk_factors 視為零個因子處理", () => {
const result = mapEtchRiskEvent({
event_type: "ETCH_PROCESS_WINDOW_RISK",
risk_event_id: "etch_no_factors"
});
expect(result?.riskSummary.risk_event_id).toBe("etch_no_factors");
expect(result?.riskFactors).toHaveLength(0);
});
业务逻辑说明: 实时制造事件(real-time manufacturing events)可能是不完整的,但符合资格的风险事件仍应具备可追溯性。
代码逻辑说明: 选填字段使用 null 作为备用值(fallback),而遗漏的数组则使用空数组作为备用值。
预期结果: 无须变更映射器代码即可通过测试。
系统设计决策
● 选填字段测试可防止意外引入过于严格的验证(strict validation)。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。
● 遗漏数组的测试保障了运行时的稳定度(runtime stability)。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。
● 存储 null 可使遗漏的原始数据保持显性(explicit)。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。
9. 实验室 6 — 时间线测试
提示词示例
新增一個測試以證明 event_time、risk_compute_time 與 factor_time 保持彼此獨立。請勿合併或重命名時間欄位。
预期测试
it("保持蝕刻風險時間線欄位彼此獨立", () => {
const result = mapEtchRiskEvent({
event_type: "ETCH_PROCESS_WINDOW_RISK",
risk_event_id: "etch_timeline_001",
event_time: "2026-06-26T10:20:00+08:00",
risk_compute_time: "2026-06-26T10:20:02+08:00",
risk_factors: [
{
factor_id: "factor_time_001",
factor_time: "2026-06-26T10:19:58+08:00"
}
]
});
expect(result?.riskSummary.event_time).toBe("2026-06-26T10:20:00+08:00");
expect(result?.riskSummary.risk_compute_time).toBe("2026-06-26T10:20:02+08:00");
expect(result?.riskFactors[0].factor_time).toBe("2026-06-26T10:19:58+08:00");
});
业务逻辑说明: 时间分离是必要的,这用以厘清传感器风险是在串流计算(stream computation)之前还是自动化响应(automation response)之前出现。
代码逻辑说明: 映射器分别独立保留每个时间字段。
预期结果: 测试通过。
系统设计决策
● 时间线精准度对于根因分析至关重要。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。
● 独立的时间字段可暴露串流处理延迟(stream-processing delay)。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。
● 测试可防止未来的重构将相异的时间概念合并(collapsing)。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。
10. 实验室 7 — 既有既有晶圆厂逻辑不退化
开发人员任务
建立一个小型的处理程序(handler)来调用映射器,并将无关事件委派给既有逻辑。
预期代码
import { mapEtchRiskEvent } from "./etchRiskMapper.js";
export async function runExistingFactoryLogic(message: any): Promise<string> {
if (message?.event_type === "EQUIPMENT_ALARM") {
return "equipment-alarm-processed";
}
if (message?.event_type === "AUTOMATION_CONTROL_COMMAND") {
return "automation-command-processed";
}
return "ignored-by-existing-factory-logic";
}
export async function handleEtchRiskMessage(rawMessage: string): Promise<string> {
const message = JSON.parse(rawMessage);
const records = mapEtchRiskEvent(message);
if (records) {
return "etch-process-window-risk-mapped";
}
return runExistingFactoryLogic(message);
}
业务逻辑说明: 此处理程序在加入蚀刻风险映射的同时,保护了既有的事件行为。
代码逻辑说明: 映射器负责判定资格。不符资格的消息将会流向既有逻辑。
预期结果: 设备警报与自动化控制命令将保留其原本的响应行为。
不退化测试
it("保持自動化控制命令的行為不變", async () => {
const result = await handleEtchRiskMessage(JSON.stringify({
event_type: "AUTOMATION_CONTROL_COMMAND"
}));
expect(result).toBe("automation-command-processed");
});
系统设计决策
● 不退化测试保护了生产环境的事件路由(event routing)。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。
● 映射资格判定不应改变警报或控制命令的处理逻辑。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。
● 小型的处理程序可在不增加数据库复杂度的情况下展示整合。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。
11. 实验室 8 — 最终 Kiro 覆盖率审查
提示词示例
審查蝕刻製程視窗風險映射器、處理常式與測試。回傳 PASS 或 FAIL。檢查正常路徑事件、無關事件、遺漏欄位、遺漏 risk_factors、時間線欄位以及不退化行為。僅提供最小化修補建議。
预期 Kiro 结果
PASS
- 包含兩個因子的正常路徑事件已通過測試。
- 設備警報與自動化控制命令之行為已受到保護。
- 遺漏選填欄位與遺漏 risk_factors 的情況已通過測試。
- 時間線欄位保持彼此獨立。
- 無任何來源數值被轉換或計算。
12. 完成情况检核表
● 测试先行计划已建立。
● 蚀刻风险映射器已生成。
● 核心测试已加入。
● 弱测试审查已完成。
● 选填字段测试已加入。
● 时间线测试已加入。
● 既有既有晶圆厂逻辑不退化测试已加入。
● 最终 Kiro 覆盖率审查已完成。
13. 实验室 9 — 蚀刻传感器边界值审查
提示词示例
為接近製程控制邊界的蝕刻感測器數值建立一份附加的測試審查檢核表。請勿計算新的風險值。僅檢查來源數值與控制邊界是否仍儲存為字串。
预期 Kiro 结果
附加檢核表:
- chamber_pressure 來源數值已直接儲存。
- rf_power_variation 來源數值已直接儲存。
- control_boundary 已直接儲存。
- unit 已被保留。
- risk_contribution 已自來源事件直接儲存。
- 無任何數值被轉換為數字類型(Number)。
- 未建立任何派生的邊界距離欄位(derived distance-to-boundary field)。
业务逻辑说明: 蚀刻腔体传感器可能接近极限值,但持久化层不应重新诠释或重新计算这些数值。
代码逻辑说明: 映射器将传感器数值与边界存储为原始来源字符串。任何计算都应在独立的分析层中实施。
预期结果: Kiro 将类型转换或计算视为一项审查关切点(review concern)。
系统设计决策
● 边界分析(Boundary analysis)固然重要,但持久化与分析层应保持分离。 这是一项系统设计抉择,因为蚀刻工艺窗口风险测试需要严格且专一的契约,以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为,而非流于宽泛的实施偏好,从而让学习者能将单一规则与特定的运作失效模式连结,避免增加不必要的平台复杂度。
● 保留原始来源数值可让工艺工程师将存储的记录与串流事件进行对比。 针对蚀刻工艺窗口风险测试,系统架构应在优化开发人员便利性之前,优先保留原始证据与既有的事件行为。这一点明确划定了界线:自动生成的辅助程序可以提出变更建议,但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来,系统将更容易被审计,且演进时更具安全性。
● 避免使用派生字段(derived fields)可保持映射器的简洁度与可审查性。 最后一个设计要点将实验室的行动转化为蚀刻工艺窗口风险测试的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性,开发人员可以改善工作流程,而不会将风险隐藏在庞大的重构或隐含的假设之中。
14. 实验室 10 — 生成开发人员调试指引
提示词示例
為失敗的蝕刻風險映射器測試建立一份簡短的開發人員除錯指引。包含事件資格錯誤、遺漏因子關聯、合併時間欄位以及意外數值轉換等失效情境。
预期 Kiro 结果
除錯指引:
1. 若無關事件意外回傳紀錄集,請檢查 event_type 是否精確比對。
2. 若因子關聯(factor linkage)失敗,請檢查每個因子是否都使用了父層的 risk_event_id。
3. 若時間線測試失敗,請檢查 event_time、risk_compute_time 與 factor_time 的欄位名稱。
4. 若數值測試失敗,請移除 Number 類型轉換或正規化輔助函式(normalization helpers)。
5. 若遺漏 risk_factors 導致當機或崩潰,請改用 message?.risk_factors || []。
业务逻辑说明: 当自动生成的代码未能通过深具意义的工厂风险测试时,开发人员需要快速的疑难排解步骤。
代码逻辑说明: 每个调试步骤皆将特定的测试失败映射到最有可能的代码问题上。
预期结果: 开发人员无须进行宽泛重构即可修复映射器。
进阶开发人员额外实施实验室
这些额外实验室延伸蚀刻工艺窗口风险测试自动化工作坊,并避免重复前面的映射器、核心测试、弱测试批判、选填字段测试、时间线测试、不退化处理程序、边界审查与调试指引。新的重点是进阶开发人员使用的突变式测试审查、测试文件夹具设计、契约快照、解析器强化与 CI 质量报告。
15. 实验室 11 — 测试强度的突变式审查
开发人员任务
要求 Kiro 提出刻意的一行代码突变,并指出哪些测试应该失败。不要永久套用这些突变。
提示词示例
針對蝕刻製程視窗風險映射器測試提出突變式檢查。包含事件資格、因子父層連結、遺漏 risk_factors 處理、時間線欄位映射與意外 Number 轉換等突變。針對每個突變,指出應該失敗的測試名稱。
预期 Kiro 结果
# 突變式測試審查
## 突變 1 — 放寬事件資格比對
變更:
`message?.event_type !== "ETCH_PROCESS_WINDOW_RISK"`
改為:
`!message?.event_type?.includes("RISK")`
預期失敗的測試:
- 對設備警報或無關晶圓廠事件回傳 null
## 突變 2 — 破壞父層連結
變更:
`risk_event_id: message.risk_event_id || null`
改為:
`risk_event_id: factor.risk_event_id || null`
預期失敗的測試:
- 映射具有兩個因子的蝕刻製程視窗風險事件
## 突變 3 — 移除遺漏陣列的備用值
變更:
`message?.risk_factors || []`
改為:
`message.risk_factors`
預期失敗的測試:
- 將遺漏的 risk_factors 視為零個因子處理
## 突變 4 — 合併時間線欄位
變更:
`risk_compute_time: message.risk_compute_time || null`
改為:
`risk_compute_time: message.event_time || null`
預期失敗的測試:
- 保持蝕刻風險時間線欄位彼此獨立
## 突變 5 — 轉換來源值
變更:
`sensor_value: factor.sensor_value || null`
改為:
`sensor_value: Number(factor.sensor_value || 0)`
預期失敗的測試:
- 將蝕刻感測器來源值保留為字串
业务逻辑说明: 突变式审查能证明测试会检测危险变更,而不只是通过目前实施。 代码逻辑说明: 每个突变都对应到既有或新需要的断言。 预期结果: 开发人员能在生产代码变更之前找出测试软件包弱点。
系统设计决策
● 突变式审查可验证测试意图,而不需要在工作坊中引入突变测试框架。
● 每个突变都代表具备运营意义的失效模式。
● 实验室让变更保持暂时性,因此生产映射器仍然简单且可追溯。
16. 实验室 12 — 可重用的蚀刻事件测试数据建立器
开发人员任务
建立测试数据建立器,以减少复制贴上,同时让来源值保持明确。
提示词示例
為 ETCH_PROCESS_WINDOW_RISK 事件建立 Vitest 夾具輔助函式。它應回傳一個包含兩個 risk_factors 的完整事件,並允許覆寫摘要欄位與 risk_factors。不要用隨機資料隱藏重要來源值。
预期夹具辅助函数
export function buildEtchRiskEvent(overrides: Record<string, any> = {}) {
return {
event_type: "ETCH_PROCESS_WINDOW_RISK",
risk_event_id: "etch_fixture_evt_001",
fab_id: "FAB-HK-ADV-01",
tool_id: "ETCH-CHAMBER-12",
chamber_id: "CHAMBER-B",
wafer_lot_id: "LOT-HPC-55210",
recipe_version: "ETCH-7NM-R19",
process_step: "PLASMA_ETCH",
process_window_risk_level: "HIGH",
etch_uniformity_risk: "ELEVATED",
drift_velocity: "0.041",
yield_exposure_level: "ELEVATED",
automation_control_slip_probability: "0.67",
event_time: "2026-06-26T10:20:00+08:00",
risk_compute_time: "2026-06-26T10:20:02+08:00",
risk_factors: [
{
factor_id: "etch_fixture_pressure_001",
sensor_name: "chamber_pressure",
sensor_value: "14.8",
control_boundary: "15.0",
unit: "mTorr",
risk_contribution: "HIGH",
factor_time: "2026-06-26T10:19:58+08:00"
},
{
factor_id: "etch_fixture_rf_002",
sensor_name: "rf_power_variation",
sensor_value: "2.7",
control_boundary: "3.0",
unit: "percent",
risk_contribution: "MEDIUM",
factor_time: "2026-06-26T10:19:59+08:00"
}
],
...overrides
};
}
业务逻辑说明: 夹具建立器可降低测试维护成本,同时保留真实的蚀刻工艺背景。 代码逻辑说明: 辅助函数使用确定性值与明确覆写,而非生成式测试数据。 预期结果: 进阶测试变得更短,但不会失去来源字段可见性。
系统设计决策
● 确定性夹具可避免 flaky test,并让失败更容易审查。
● 明确来源值可让工艺工程背景保留在测试中。
● 浅层覆写已足以支持此映射器,因为巢状因子变更应在个别测试中保持清楚。
17. 实验室 13 — 不存储完整负载的契约快照
开发人员任务
建立输出字段名称的契约式断言。目标是在不快照或存储完整输入负载的情况下验证映射器输出形状。
提示词示例
為 mapEtchRiskEvent 生成合約測試,驗證 riskSummary 欄位名稱與 riskFactor 欄位名稱。不要快照完整來源事件,也不要儲存原始 payload。
预期测试
it("exposes the expected etch risk persistence contract", () => {
const result = mapEtchRiskEvent({
event_type: "ETCH_PROCESS_WINDOW_RISK",
risk_event_id: "etch_contract_001",
risk_factors: [{ factor_id: "factor_contract_001" }]
});
expect(Object.keys(result?.riskSummary || {}).sort()).toEqual([
"automation_control_slip_probability",
"chamber_id",
"drift_velocity",
"etch_uniformity_risk",
"event_time",
"fab_id",
"process_step",
"process_window_risk_level",
"recipe_version",
"risk_compute_time",
"risk_event_id",
"tool_id",
"wafer_lot_id",
"yield_exposure_level"
].sort());
expect(Object.keys(result?.riskFactors[0] || {}).sort()).toEqual([
"control_boundary",
"factor_id",
"factor_time",
"risk_contribution",
"risk_event_id",
"sensor_name",
"sensor_value",
"unit"
].sort());
});
业务逻辑说明: 契约测试可保护下游持久化期待,而不鼓励存储原始负载。 代码逻辑说明: 测试只断言输出键,来源值则交由字段层级测试验证。 预期结果: 字段新增、移除或重新命名会在测试审查中变得可见。
系统设计决策
● 当下游存储需要稳定形状时,契约测试很有价值。
● 快照完整事件会与持久化教学目标冲突,并让审查变得吵杂。
● 字段名称断言补充值层级测试,而不是取代它们。
18. 实验室 14 — 格式错误 JSON 处理程序测试
开发人员任务
为格式错误的 JSON 输入新增小型处理程序层级测试。保持映射器不变。
提示词示例
為蝕刻風險訊息處理常式新增格式錯誤 JSON 的處理常式層級測試。處理常式應回傳受控的解析錯誤結果或拋出已文件化錯誤。不要修改映射器,也不要在欄位映射中加入寬泛錯誤處理。
预期 Kiro 结果
export async function handleEtchRiskMessage(rawMessage: string): Promise<string> {
let message: any;
try {
message = JSON.parse(rawMessage);
} catch {
return "invalid-json-message";
}
const records = mapEtchRiskEvent(message);
if (records) {
return "etch-process-window-risk-mapped";
}
return runExistingFactoryLogic(message);
}
it("returns a controlled result for malformed JSON", async () => {
await expect(handleEtchRiskMessage("{not-valid-json")).resolves.toBe("invalid-json-message");
});
业务逻辑说明: 事件串流消费者应能可预测地处理格式错误的传输数据,同时让有效事件映射规则保持简单。 代码逻辑说明: JSON 解析属于处理程序边界,而不是纯映射器内部。 预期结果: 无效传输输入会与工艺风险映射分开处理。
系统设计决策
● 解析器强化属于系统边界。
● 映射器应专注于合格事件映射与直接来源字段保留。
● 文件化错误结果可协助操作人员区分格式错误输入与无关晶圆厂事件。
19. 实验室 15 — CI 覆盖率 Gate 报告提示词
开发人员任务
要求 Kiro 将测试期待转换为 CI 可读的审查摘要。
提示词示例
為蝕刻製程視窗風險測試建立 CI 覆蓋率 Gate 報告範本。包含映射器合約、正向事件、負向晶圓廠事件、遺漏欄位、時間線欄位、格式錯誤 JSON 處理常式行為與值保留檢查。報告應精簡並使用 PASS/FAIL/N/A。
预期 Kiro 结果
# 蝕刻風險 CI 覆蓋率 Gate 報告
## 映射器合約
- 輸出欄位合約:PASS/FAIL/N/A
- 精確事件資格比對:PASS/FAIL/N/A
## 事件行為
- 符合資格的 ETCH_PROCESS_WINDOW_RISK 會映射一筆摘要:PASS/FAIL/N/A
- 多個 risk_factors 會映射多筆因子紀錄:PASS/FAIL/N/A
- EQUIPMENT_ALARM 回傳 null 或維持原委派行為:PASS/FAIL/N/A
- AUTOMATION_CONTROL_COMMAND 維持原委派行為:PASS/FAIL/N/A
## 邊緣情況
- 遺漏的選填摘要欄位會儲存為 null:PASS/FAIL/N/A
- 遺漏 risk_factors 會回傳零個因子:PASS/FAIL/N/A
- 格式錯誤 JSON 會在邊界處理:PASS/FAIL/N/A
## 語意
- event_time 與 risk_compute_time 保持分開:PASS/FAIL/N/A
- factor_time 保持在因子層級:PASS/FAIL/N/A
- 感測器值與控制邊界保持為字串:PASS/FAIL/N/A
## 決策
- 整體 Gate:PASS/FAIL
- 若為 FAIL,阻擋原因:
业务逻辑说明: CI 报告让测试覆盖率期待对审查者可见,而不要求他们手动检查每个测试档。 代码逻辑说明: 报告摘要测试结果,不引入新的映射器行为。 预期结果: Pull Request 能清楚传达蚀刻风险测试是否已准备就绪。
系统设计决策
● CI 摘要可提升进阶测试软件包的审查效率。
● PASS/FAIL/N/A 能避免自动化审查输出中的模糊叙述。
● 覆盖率 Gate 应回报证据,而人类审查者仍负责评估设计判断。
20. 进阶实验室完成情况检核表
● 突变式审查已完成并识别弱断言。
● 可重用的确定性夹具建立器已建立。
● 契约字段名称测试已加入,且未快照原始负载。
● 格式错误 JSON 行为已在处理程序边界测试。
● CI 覆盖率 Gate 报告范本已建立。