與 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. 實驗室議程

---

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 報告範本已建立。