與 Kiro 同行：黃光微影漂移風險開發工作坊

時長： 2 小時

目標受眾： 專業後端開發人員、製造資料平台開發人員與半導體自動化工程師

主要 AWS AI 服務： Kiro

工作坊重點： 針對黃光微影設備漂移與製程視窗風險的高階 Kiro 規格驅動開發實驗室

獨立成果： 開發人員將建置並審查一個 TypeScript 模組，該模組使用 Kiro 生成的規格、任務、測試與審查提示詞來對黃光微影漂移風險紀錄進行分類與持久化（persistence）。

摘要

本工作坊旨在協助專業開發人員使用 Kiro 進行規格驅動的黃光微影漂移風險持久化。本工作坊將 AI 輸出限縮於「僅限持久化」的範疇、定義標準事件模型、生成 TypeScript 映射器（mappers）與處理常式（handlers）、建置 Vitest 測試覆蓋率、審查重複因子與時間線風險，並強制執行直接來源欄位儲存。這些實驗室透過實際的審查工作流程，為半導體廠工程團隊強調最小化修補（minimal patches）、不退化（non-regression）、可追溯性（traceability）與系統設計推導。

1. 工作坊目標

本獨立工作坊為半導體廠工程團隊提供了更多實作開發實驗室，以加深對 Kiro 的應用。 情境聚焦於黃光微影機台（exposure tool），當中的焦距偏移（focus offset）、晶圓座溫度（chuck temperature）、能量穩定度（dose stability）、步進工作台振動（stage vibration）、真空度（vacuum level）以及光罩對準（reticle alignment）可能已接近製程控制邊界，而此時機台稼動率（utilization）與平均良率（average yield）看起來卻依然正常。

開發人員將使用 Kiro 來建立功能規格、生成程式碼、新增測試、審查有缺陷的 AI 輸出，並在實作中擴充更為真實的晶圓廠邊緣情況（edge cases）。 所有程式碼範例皆圍繞設備漂移、製程視窗風險、晶圓批次風險、自動化控制滑移以及感測器風險因子。

2. 開發人員學習目標

在本工作坊結束時，開發人員將能夠：

1. 使用 Kiro 為黃光微影漂移風險模組建立技術規格。
2. 根據製造事件範例生成 TypeScript 映射器與持久化處理常式。
3. 保護既有的設備警報（equipment alarm）與自動化控制命令（automation command）邏輯不受影響。
4. 為多因子風險事件、遺漏的選填欄位、重複因子以及時間線語意新增測試。
5. 使用 Kiro 審查不安全的實作並建立最小化修補。
6. 透過系統設計推導來闡述每項設計決策。

3. 實驗室議程

4. 實驗室 1 — 擴充 Kiro 規格

開發人員任務

建立一個名為以下名稱的 Kiro 規格：

photolithography-drift-risk-persistence

提示詞規則 1

提示詞目標： 要求 Kiro 提供黃光微影風險功能的第一個版本。

建立一個用於黃光微影設備漂移風險持久化的 TypeScript 功能。

AI 生成結果： Kiro 可能會提出一個包含儀表板、風險計算與警報功能的寬泛監控系統。

說明： 此結果對於開發人員工作坊來說可能過於寬泛，因為它混雜了持久化、分析與營運控制行動。

為何結果不夠好： 它可能會引入自動生成的風險計算與控制行動，而這些內容不應屬於以持久化為核心的功能。在晶圓廠自動化中，缺乏嚴格治理的自動生成控制邏輯可能會帶來營運風險。

提示詞規則 2

為何規則 2 可以修復上述問題： 這能將 Kiro 限縮在僅限持久化的功能範疇。

將功能精簡為僅限持久化。不要建立儀表板、警報、控制行動或衍生的風險計算。儲存來源事件欄位以便日後進行工程調查。

AI 生成結果： Kiro 應該會產生關於映射與儲存來源欄位的需求。

說明： 該功能範圍被縮小，使其能安全地進行實作與審查。

提示詞規則 3

為何規則 3 可以修復上述問題： 一個黃光微影風險事件會包含多個共同作用的感測器因子。

此事件包含一個 drift_risk_event_id 以及一個名為 risk_factors 的陣列。每個 risk_factors 項目須建立一筆漂移摘要紀錄與一筆因子紀錄。因子紀錄須透過 drift_risk_event_id 連結至摘要。

AI 生成結果： Kiro 應該會設計出一個父子（parent-child）關係模型。

說明： 這能支援製程工程師從事件深入分析（drill-down）到各個獨立的感測器影響因子。

提示詞規則 4

為何規則 4 可以修復上述問題： 除非明確禁止，否則 Kiro 可能會主動轉換感測器數值或生成元資料（metadata）。

直接儲存原始來源數值或 null。不要轉換感測器數值、不要計算新的風險分數、不要自動生成 ID、不要自動生成時間戳記，且不要儲存完整的事件負載（payload）。

AI 生成結果： Kiro 應該會使用簡單的映射並避免引入轉換用的輔助函式。

說明： 儲存的紀錄將與來源串流保持一致，以確保可追溯性。

系統設計決策

1. Kiro 規格能在撰寫程式碼之前建立一個可供審查的產出物。這至關重要，因為黃光微影的製程視窗（process windows）非常狹窄，微小的欄位變更都可能對良率產生重大影響。這是一項系統設計抉擇，因為黃光微影漂移風險持久化需要嚴格且專一的合約，以便開發人員在儲存時（save-time）、測試時（test-time）及審查時（review-time）的回饋中進行推導。此決策使實驗室聚焦於可觀測的行為，而非流於寬泛的實作偏好，從而讓學習者能將單一規則與特定的運作失效模式連結，避免增加不必要的平台複雜度。
2. 「僅限持久化」的範疇能降低營運風險。它避免了將資料捕獲（data capture）與自動化控制行為混為一談。針對黃光微影漂移風險持久化，系統架構應在優化開發人員便利性之前，優先保留原始證據（source evidence）與既有的事件行為。這一點明確劃定了界線：自動生成的輔助程式可以提出變更建議，但系統仍須對可追溯性、可重複性及生產環境不退化負責。這樣一來，系統將更容易被審計，且演進時更具安全性。
3. 父子紀錄關係符合調查的工作流程：工程師首先識別出存在風險的曝光事件，接著審查各個感測器的影響因子。最後一個設計要點將實驗室的行動轉化為黃光微影漂移風險持久化的長期工程實務。它說明了所選定的範疇邊界如何支援團隊審查、未來的維護以及受控的版本推出。藉由保持行動的最小化與可衡量性，開發人員可以改善工作流程，而不會將風險隱藏在龐大的重構或隱含的假設之中。

5. 實驗室 2 — 定義黃光微影事件模型

開發人員任務

要求 Kiro 為該功能生成一個標準事件範例。

提示詞範例

建立一個用於 TypeScript 程式碼註解的完整黃光微影漂移風險事件範例。包含 drift_risk_event_id、fab_id、tool_id、wafer_lot_id、recipe_version、exposure_job_id、process_step、process_window_risk_level、drift_velocity、yield_exposure_level、automation_control_slip_probability、event_time、stream_processing_time，以及包含兩個感測器因子的 risk_factors。

預期事件範例

{
  "event_type": "PHOTOLITHOGRAPHY_DRIFT_RISK",
  "drift_risk_event_id": "photo_drift_evt_20260626_001",
  "fab_id": "FAB-HK-ADV-01",
  "tool_id": "LITHO-EXPOSE-07",
  "wafer_lot_id": "LOT-AI-780042",
  "recipe_version": "PHOTO-7NM-R42",
  "exposure_job_id": "EXP-JOB-44019",
  "process_step": "PHOTO_EXPOSURE",
  "process_window_risk_level": "HIGH",
  "drift_velocity": "0.034",
  "yield_exposure_level": "ELEVATED",
  "automation_control_slip_probability": "0.72",
  "event_time": "2026-06-26T09:15:30+08:00",
  "stream_processing_time": "2026-06-26T09:15:33+08:00",
  "risk_factors": [
    {
      "factor_id": "photo_factor_focus_001",
      "sensor_name": "focus_offset",
      "sensor_value": "0.018",
      "control_boundary": "0.020",
      "unit": "micrometer",
      "risk_contribution": "HIGH",
      "factor_time": "2026-06-26T09:15:28+08:00"
    },
    {
      "factor_id": "photo_factor_chuck_temp_002",
      "sensor_name": "chuck_temperature",
      "sensor_value": "82.7",
      "control_boundary": "83.0",
      "unit": "celsius",
      "risk_contribution": "MEDIUM",
      "factor_time": "2026-06-26T09:15:29+08:00"
    }
  ]
}

業務邏輯說明： 此事件在機台層級的平均值看起來可能仍然穩定時，及時捕獲了黃光微影製程視窗的曝光風險。

程式碼邏輯說明： 該事件包含一個父層 ID 以及多個因子 ID。時間欄位分別代表原始事件時間、串流處理時間以及各個因子的獨立時間。

預期結果： Kiro 將使用此確切的結構來建立映射器與測試。

系統設計決策

1. 具體的事件範例可防止在程式碼生成期間憑空捏造欄位。這是一項系統設計抉擇，因為黃光微影漂移風險持久化需要嚴格且專一的合約，以便開發人員在儲存時、測試時及審查時的回饋中進行推導。此決策使實驗室聚焦於可觀測的行為，而非流於寬泛的實作偏好，從而讓學習者能將單一規則與特定的運作失效模式連結，避免增加不必要的平台複雜度。
2. 獨立的時間欄位可在事件審查期間保護時間線分析（timeline analysis）的能力。針對黃光微影漂移風險持久化，系統架構應在優化開發人員便利性之前，優先保留原始證據與既有的事件行為。這一點明確劃定了界線：自動生成的輔助程式可以提出變更建議，但系統仍須對可追溯性、可重複性及生產環境不退化負責。這樣一來，系統將更容易被審計，且演進時更具安全性。
3. 因子級別的紀錄保留了根因分析所需的感測器脈絡。最後一個設計要點將實驗室的行動轉化為黃光微影漂移風險持久化的長期工程實務。它說明了所選定的範疇邊界如何支援團隊審查、未來的維護以及受控的版本推出。藉由保持行動的最小化與可衡量性，開發人員可以改善工作流程，而不會將風險隱藏在龐大的重構或隱含的假設之中。

6. 實驗室 3 — 生成映射器

提示詞範例

建立 src/photoDriftRiskMapper.ts。除非 event_type 為 PHOTOLITHOGRAPHY_DRIFT_RISK，否則回傳 null。對於符合資格的事件，每個 risk_factors 項目須回傳一個 driftSummary 物件與一個 factor 物件。僅儲存原始來源數值或 null。

預期程式碼

export type PhotoDriftRiskRecordSet = {
  driftSummary: Record<string, string | null>;
  riskFactors: Record<string, string | null>[];
};

export function mapPhotoDriftRiskEvent(message: any): PhotoDriftRiskRecordSet | null {
  if (message?.event_type !== "PHOTOLITHOGRAPHY_DRIFT_RISK") {
    return null;
  }

  const driftSummary = {
    drift_risk_event_id: message.drift_risk_event_id || null,
    fab_id: message.fab_id || null,
    tool_id: message.tool_id || null,
    wafer_lot_id: message.wafer_lot_id || null,
    recipe_version: message.recipe_version || null,
    exposure_job_id: message.exposure_job_id || null,
    process_step: message.process_step || null,
    process_window_risk_level: message.process_window_risk_level || 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,
    stream_processing_time: message.stream_processing_time || null
  };

  const riskFactors = (message?.risk_factors || []).map((factor: any) => ({
    factor_id: factor.factor_id || null,
    drift_risk_event_id: message.drift_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 { driftSummary, riskFactors };
}

業務邏輯說明： 映射器在不變更任何數值的情況下，為持久化準備黃光微影風險紀錄。

程式碼邏輯說明： 它會拒絕無關事件、映射一個摘要物件、遍歷所有因子，並回傳這兩個紀錄集。

預期結果： 符合資格的輸入將回傳一筆摘要與多個因子；無關事件則回傳 null。

系統設計決策

1. 純粹的映射器（pure mapper）使得程式碼生成更易於測試，且不依賴資料庫。這是一項系統設計抉擇，因為黃光微影漂移風險持久化需要嚴格且專一的合約，以便開發人員在儲存時、測試時及審查時的回饋中進行推導。此決策使實驗室聚焦於可觀測的行為，而非流於寬泛的實作偏好，從而讓學習者能將單一規則與特定的運作失效模式連結，避免增加不必要的平台複雜度。
2. 精確的事件比對可規避處理無關的晶圓廠事件。針對黃光微影漂移風險持久化，系統架構應在優化開發人員便利性之前，優先保留原始證據與既有的事件行為。這一點明確劃定了界線：自動生成的輔助程式可以提出變更建議，但系統仍須對可追溯性、可重複性及生產環境不退化負責。這樣一來，系統將更容易被審計，且演進時更具安全性。
3. 直接映射保持了來源遙測資料與儲存紀錄的可比性（comparable）。最後一個設計要點將實驗室的行動轉化為黃光微影漂移風險持久化的長期工程實務。它說明了所選定的範疇邊界如何支援團隊審查、未來的維護以及受控的版本推出。藉由保持行動的最小化與可衡量性，開發人員可以改善工作流程，而不會將風險隱藏在龐大的重構或隱含的假設之中。

7. 實驗室 4 — 生成持久化處理常式

提示詞範例

建立 src/photoDriftRiskHandler.ts。使用 mapPhotoDriftRiskEvent。若映射器回傳紀錄，將 driftSummary 與每個 riskFactor 新增至記憶體內資料庫。若映射器回傳 null，則呼叫 existingFactoryLogic。保持處理常式簡潔。

預期程式碼

import { mapPhotoDriftRiskEvent } from "./photoDriftRiskMapper.js";
import { runExistingFactoryLogic } from "./existingFactoryLogic.js";

export class InMemoryPhotoRiskDb {
  public driftSummaries: Record<string, string | null>[] = [];
  public riskFactors: Record<string, string | null>[] = [];

  async insertDriftSummary(record: Record<string, string | null>): Promise<void> {
    this.driftSummaries.push(record);
  }

  async insertRiskFactor(record: Record<string, string | null>): Promise<void> {
    this.riskFactors.push(record);
  }
}

export async function handlePhotoDriftRiskMessage(rawMessage: string, db: InMemoryPhotoRiskDb): Promise<string> {
  const message = JSON.parse(rawMessage);
  const records = mapPhotoDriftRiskEvent(message);

  if (records) {
    await db.insertDriftSummary(records.driftSummary);

    for (const factor of records.riskFactors) {
      await db.insertRiskFactor(factor);
    }

    return "photolithography-drift-risk-persisted";
  }

  return runExistingFactoryLogic(message);
}

業務邏輯說明： 處理常式會持久化黃光微影漂移風險紀錄，並將所有無關訊息委派給既有的晶圓廠邏輯。

程式碼邏輯說明： 映射器負責判定資格。處理常式僅在映射器回傳紀錄集時才會寫入紀錄。

預期結果： 針對合規事件，處理常式會建立一筆摘要與多個因子。

系統設計決策

1. 將映射器與處理常式分離，可確保業務映射的可測試性，並保持持久化流程的簡潔。這是一項系統設計抉擇，因為黃光微影漂移風險持久化需要嚴格且專一的合約，以便開發人員在儲存時、測試時及審查時的回饋中進行推導。此決策使實驗室聚焦於可觀測的行為，而非流於寬泛的實作偏好，從而讓學習者能將單一規則與特定的運作失效模式連結，避免增加不必要的平台複雜度。
2. 委派無關事件可保護既有的營運行為。針對黃光微影漂移風險持久化，系統架構應在優化開發人員便利性之前，優先保留原始證據與既有的事件行為。這一點明確劃定了界線：自動生成的輔助程式可以提出變更建議，但系統仍須對可追溯性、可重複性及生產環境不退化負責。這樣一來，系統將更容易被審計，且演進時更具安全性。
3. 採用記憶體內資料庫（in-memory database）能讓工作坊聚焦於 Kiro 輔助開發，而非耗費在基礎設施的配置上。最後一個設計要點將實驗室的行動轉化為黃光微影漂移風險持久化的長期工程實務。它說明了所選定的範疇邊界如何支援團隊審查、未來的維護以及受控的版本推出。藉由保持行動的最小化與可衡量性，開發人員可以改善工作流程，而不會將風險隱藏在龐大的重構或隱含的假設之中。

8. 實驗室 5 — 生成測試

提示詞範例

為 mapPhotoDriftRiskEvent 與 handlePhotoDriftRiskMessage 生成 Vitest 測試。包含具有兩個因子的合規事件、無關的設備警報、遺漏的 risk_factors，以及遺漏的選填摘要欄位。

預期測試程式碼

import { describe, expect, it } from "vitest";
import { mapPhotoDriftRiskEvent } from "../src/photoDriftRiskMapper.js";
import { handlePhotoDriftRiskMessage, InMemoryPhotoRiskDb } from "../src/photoDriftRiskHandler.js";

describe("黃光微影漂移風險實驗室", () => {
  it("將合規事件映射至一筆摘要與兩個因子", () => {
    const result = mapPhotoDriftRiskEvent({
      event_type: "PHOTOLITHOGRAPHY_DRIFT_RISK",
      drift_risk_event_id: "photo_drift_evt_20260626_001",
      fab_id: "FAB-HK-ADV-01",
      tool_id: "LITHO-EXPOSE-07",
      wafer_lot_id: "LOT-AI-780042",
      recipe_version: "PHOTO-7NM-R42",
      exposure_job_id: "EXP-JOB-44019",
      process_step: "PHOTO_EXPOSURE",
      process_window_risk_level: "HIGH",
      drift_velocity: "0.034",
      yield_exposure_level: "ELEVATED",
      automation_control_slip_probability: "0.72",
      event_time: "2026-06-26T09:15:30+08:00",
      stream_processing_time: "2026-06-26T09:15:33+08:00",
      risk_factors: [
        {
          factor_id: "photo_factor_focus_001",
          sensor_name: "focus_offset",
          sensor_value: "0.018",
          control_boundary: "0.020",
          unit: "micrometer",
          risk_contribution: "HIGH",
          factor_time: "2026-06-26T09:15:28+08:00"
        },
        {
          factor_id: "photo_factor_chuck_temp_002",
          sensor_name: "chuck_temperature",
          sensor_value: "82.7",
          control_boundary: "83.0",
          unit: "celsius",
          risk_contribution: "MEDIUM",
          factor_time: "2026-06-26T09:15:29+08:00"
        }
      ]
    });

    expect(result?.driftSummary.drift_risk_event_id).toBe("photo_drift_evt_20260626_001");
    expect(result?.riskFactors).toHaveLength(2);
    expect(result?.riskFactors[0].drift_risk_event_id).toBe("photo_drift_evt_20260626_001");
  });

  it("透過處理常式持久化合規事件", async () => {
    const db = new InMemoryPhotoRiskDb();
    const result = await handlePhotoDriftRiskMessage(JSON.stringify({
      event_type: "PHOTOLITHOGRAPHY_DRIFT_RISK",
      drift_risk_event_id: "photo_evt_handler_001",
      tool_id: "LITHO-EXPOSE-07",
      risk_factors: []
    }), db);

    expect(result).toBe("photolithography-drift-risk-persisted");
    expect(db.driftSummaries).toHaveLength(1);
    expect(db.riskFactors).toHaveLength(0);
  });

  it("當映射器輸入為設備警報時回傳 null", () => {
    expect(mapPhotoDriftRiskEvent({ event_type: "EQUIPMENT_ALARM" })).toBeNull();
  });
});

業務邏輯說明： 這些測試驗證了映射、持久化以及對無關事件的拒絕邏輯。

程式碼邏輯說明： 映射器測試會檢視回傳的紀錄；處理常式測試則會驗證寫入資料庫的紀錄。

預期結果： 所有測試皆順利通過。

系統設計決策

1. 同時測試映射器與處理常式，能將欄位映射的正確性與持久化流程相互解耦。這是一項系統設計抉擇，因為黃光微影漂移風險持久化需要嚴格且專一的合約，以便開發人員在儲存時、測試時及審查時的回饋中進行推導。此決策使實驗室聚焦於可觀測的行為，而非流於寬泛的實作偏好，從而讓學習者能將單一規則與特定的運作失效模式連結，避免增加不必要的平台複雜度。
2. 針對遺漏因子（missing-factor）的測試，可確保在缺乏因子陣列時，合規的摘要紀錄仍能被成功持久化。針對黃光微影漂移風險持久化，系統架構應在優化開發人員便利性之前，優先保留原始證據與既有的事件行為。這一點明確劃定了界線：自動生成的輔助程式可以提出變更建議，但系統仍須對可追溯性、可重複性及生產環境不退化負責。這樣一來，系統將更容易被審計，且演進時更具安全性。
3. 拒絕設備警報事件保護了非風險相關的營運事件行為。最後一個設計要點將實驗室的行動轉化為黃光微影漂移風險持久化的長期工程實務。它說明了所選定的範疇邊界如何支援團隊審查、未來的維護以及受控的版本推出。藉由保持行動的最小化與可衡量性，開發人員可以改善工作流程，而不會將風險隱藏在龐大的重構或隱含的假設之中。

9. 實驗室 6 — 重複因子審查

開發人員任務

要求 Kiro 審查此事件是否存在重複的因子 ID。

提示詞範例

審查此黃光微影風險事件以找出持久化疑慮。此事件包含兩個具有相同 factor_id 的 risk_factors。請勿自動變更程式碼。解釋其風險並建議測試或審查規則。

預期 Kiro 結果

發現疑慮。
兩個 risk_factors 使用了相同的 factor_id，這可能會與因子資料表的主鍵（primary key）產生衝突。
建議的測試：驗證重複的 factor_id 輸入在驗證或審查期間是否可見。
建議的審查規則：來源事件品質檢查應在寫入資料庫之前標記重複的 factor_id 數值。
在此「僅限持久化」的實驗室中，除非生產環境資料庫需要特定的衝突處理邏輯，否則無須修改映射器程式碼。

業務邏輯說明： 重複的因子識別碼可能會在真實資料庫中隱藏或覆蓋某個感測器的共同影響因子。

程式碼邏輯說明： 映射器直接儲存原始值。重複檢測應屬於驗證層（validation layer）或審查規則，而非此簡易持久化映射器的一部分。

預期結果： 開發人員能夠理解持久化映射（persistence mapping）與事件品質驗證（event-quality validation）之間的權責區分。

系統設計決策

1. 重複 ID 的處理應是一項顯性的設計決策，而非映射器意外產生的副作用（side effect）。這是一項系統設計抉擇，因為黃光微影漂移風險持久化需要嚴格且專一的合約，以便開發人員在儲存時、測試時及審查時的回饋中進行推導。此決策使實驗室聚焦於可觀測的行為，而非流於寬泛的實作偏好，從而讓學習者能將單一規則與特定的運作失效模式連結，避免增加不必要的平台複雜度。
2. 「僅限持久化」的程式碼不應默默地自動修復（silently repair）來源資料。針對黃光微影漂移風險持久化，系統架構應在優化開發人員便利性之前，優先保留原始證據與既有的事件行為。這一點明確劃定了界線：自動生成的輔助程式可以提出變更建議，但系統仍須對可追溯性、可重複性及生產環境不退化負責。這樣一來，系統將更容易被審計，且演進時更具安全性。
3. 事件品質驗證可在未來有需要時作為一項獨立功能加入。最後一個設計要點將實驗室的行動轉化為黃光微影漂移風險持久化的長期工程實務。它說明了所選定的範疇邊界如何支援團隊審查、未來的維護以及受控的版本推出。藉由保持行動的最小化與可衡量性，開發人員可以改善工作流程，而不會將風險隱藏在龐大的重構或隱含的假設之中。

10. 實驗室 7 — 時間線語意測試

提示詞範例

新增一個測試以證明 event_time、stream_processing_time 與 factor_time 保持為獨立欄位。不要將它們合併為單一時間戳記。

預期測試

it("保持黃光微影風險時間線欄位彼此獨立", () => {
  const result = mapPhotoDriftRiskEvent({
    event_type: "PHOTOLITHOGRAPHY_DRIFT_RISK",
    drift_risk_event_id: "photo_timeline_001",
    event_time: "2026-06-26T09:15:30+08:00",
    stream_processing_time: "2026-06-26T09:15:33+08:00",
    risk_factors: [
      {
        factor_id: "factor_timeline_001",
        factor_time: "2026-06-26T09:15:28+08:00"
      }
    ]
  });

  expect(result?.driftSummary.event_time).toBe("2026-06-26T09:15:30+08:00");
  expect(result?.driftSummary.stream_processing_time).toBe("2026-06-26T09:15:33+08:00");
  expect(result?.riskFactors[0].factor_time).toBe("2026-06-26T09:15:28+08:00");
});

業務邏輯說明： 時間線分離至關重要，因為感測器觀測（sensor observation）、事件建立（event creation）與串流處理（stream processing）發生在不同的時間點。

程式碼邏輯說明： 映射器將每個時間欄位儲存在其對應的輸出欄位中。

預期結果： 測試在未修改生產環境程式碼的情況下順利通過。

系統設計決策

1. 事件分析與審查需要精準的事件順序。這是一項系統設計抉擇，因為黃光微影漂移風險持久化需要嚴格且專一的合約，以便開發人員在儲存時、測試時及審查時的回饋中進行推導。此決策使實驗室聚焦於可觀測的行為，而非流於寬泛的實作偏好，從而讓學習者能將單一規則與特定的運作失效模式連結，避免增加不必要的平台複雜度。
2. 合併時間欄位可能會隱藏處理延遲（processing delay）或感測器領先時間（sensor lead time）。針對黃光微影漂移風險持久化，系統架構應在優化開發人員便利性之前，優先保留原始證據與既有的事件行為。這一點明確劃定了界線：自動生成的輔助程式可以提出變更建議，但系統仍須對可追溯性、可重複性及生產環境不退化負責。這樣一來，系統將更容易被審計，且演進時更具安全性。
3. 測試可使時間線語意成為具備執行能力的活文件（executable documentation）。最後一個設計要點將實驗室的行動轉化為黃光微影漂移風險持久化的長期工程實務。它說明了所選定的範疇邊界如何支援團隊審查、未來的維護以及受控的版本推出。藉由保持行動的最小化與可衡量性，開發人員可以改善工作流程，而不會將風險隱藏在龐大的重構或隱含的假設之中。

11. 實驗室 8 — 最終 Kiro 審查提示詞

審查黃光微影漂移風險映射器、處理常式與測試。回傳 PASS 或 FAIL。 檢查精確的事件資格比對、直接來源欄位儲存、無自動生成元資料、不儲存完整負載、處理所有 risk_factors，以及時間線欄位保持獨立。僅建議最小化修補。

預期 Kiro 輸出

PASS
- 已使用精確的事件資格比對。
- 已映射直接來源欄位。
- 無儲存完整負載、無自動生成 ID、無自動生成時間戳記，且無任何派生計算（derived calculation）。
- 所有 risk_factors 皆已透過陣列迴圈完成處理。
- 時間線欄位保持彼此獨立。

12. 完成情況檢核表

• Kiro 規格已建立。
• 黃光微影事件範例已建立。
• 映射器已生成並通過測試。
• 處理常式已生成並通過測試。
• 重複因子審查已完成。
• 時間線語意測試已加入。
• 最終 Kiro 審查已完成。

進階開發人員額外實作實驗室

這些額外實驗室延伸黃光微影漂移風險開發工作坊，並避免重複前面的規格、事件模型、映射器、處理常式、測試、重複因子審查、時間線實驗室與最終審查檢核表。新的進階重點是規格可追溯性、冪等持久化政策、結構演進、依賴邊界，以及黃光微影風險模組的生產就緒審查。

13. 實驗室 9 — 需求對測試可追溯性矩陣

開發人員任務

要求 Kiro 建立可追溯性矩陣，將黃光微影持久化需求連結到測試與審查證據。

提示詞範例

為黃光微影漂移風險持久化模組建立需求對測試可追溯性矩陣。包含精確事件資格、直接來源值、父子因子連結、遺漏 risk_factors 行為、時間線分離、無關事件委派，以及無生成中繼資料。保持 Markdown 格式，且不要加入新需求。

預期 Kiro 結果

# 黃光微影漂移風險可追溯性矩陣
## 需求：精確事件資格比對
- 證據：映射器只會針對 PHOTOLITHOGRAPHY_DRIFT_RISK 回傳紀錄
- 測試：將符合資格的事件映射為一筆摘要與兩個因子
- 負向測試：對 EQUIPMENT_ALARM 回傳 null
- 審查檢查：不得使用 includes("RISK") 或寬泛字串比對
## 需求：直接來源值或 null
- 證據：摘要與因子欄位使用來源欄位，並以 null 作為備用值
- 測試：遺漏的選填摘要欄位保持為 null
- 審查檢查：不得有 Number 轉換、正規化輔助函式、生成分數或派生狀態
## 需求：父子因子連結
- 證據：每個因子都使用父層 drift_risk_event_id
- 測試：因子的 drift_risk_event_id 等於摘要的 drift_risk_event_id
- 審查檢查：不得生成因子的父層 ID
## 需求：遺漏 risk_factors 的行為
- 證據：符合資格的事件會持久化一筆摘要與零筆因子
- 測試：當 risk_factors 不存在或為空時，處理常式仍會持久化摘要
- 審查檢查：必須存在陣列備用值
## 需求：時間線分離
- 證據：event_time、stream_processing_time 與 factor_time 保持不同欄位
- 測試：保持黃光微影風險時間線欄位彼此獨立
- 審查檢查：不得以單一 created_at 取代
## 需求：無關事件委派
- 證據：非黃光微影事件會呼叫 existingFactoryLogic
- 測試：設備警報路徑保持不變
- 審查檢查：處理常式會委派映射器回傳 null 的事件
## 需求：不生成中繼資料
- 證據：沒有建立隨機 ID 或時間戳記
- 測試/審查：靜態審查 randomUUID 與 new Date

業務邏輯說明： 可追溯性可協助審查者證明實作仍符合原始的僅限持久化範疇。
程式碼邏輯說明： 矩陣將每項需求連結到測試與審查檢查，而不生成新程式碼。
預期結果： 進階開發人員能在擴充模組之前稽核覆蓋缺口。

系統設計決策

• 當生成式規格、程式碼與測試各自演進時，可追溯性矩陣很有價值。
• 每項需求都應同時具備測試證據與審查證據，因為部分限制較適合檢查而非執行。
• 矩陣可避免後續範疇蔓延被誤標為缺少測試。

14. 實驗室 10 — 冪等持久化政策審查

開發人員任務

要求 Kiro 為重複的黃光微影漂移風險事件定義冪等政策，但不要修改簡單的工作坊記憶體資料庫。

提示詞範例

為重複的 PHOTOLITHOGRAPHY_DRIFT_RISK 訊息建立冪等持久化政策。不要實作資料庫特定的 upsert 程式碼。說明重複 drift_risk_event_id 以及同一事件內重複 factor_id 的建議生產行為。

預期 Kiro 結果

# 冪等持久化政策
## 範圍
當事件串流可能多次傳遞相同的 PHOTOLITHOGRAPHY_DRIFT_RISK 事件時，適用本政策。
## 建議的生產環境行為
- 將 drift_risk_event_id 視為摘要的冪等鍵。
- 將 drift_risk_event_id + factor_id 這組值視為因子的冪等鍵。
- 重新處理同一事件時，不應建立重複的摘要紀錄。
- 重新處理同一因子時，不應建立重複的因子紀錄。
- 若相同 ID 帶入不同來源值，應保留衝突以供審查，而不是靜默覆寫。
## 工作坊邊界
- 記憶體內資料庫不實作 upsert 行為。
- 映射器不應生成 ID，也不應修復重複資料。
- 冪等性屬於生產環境持久化配接器或資料庫約束層的責任。

業務邏輯說明： 半導體事件串流可能重送訊息，因此生產儲存需要明確的重複資料政策。
程式碼邏輯說明： 映射器保持不變；冪等性被文件化為持久化配接器的責任。
預期結果： 開發人員理解重複保護在生產設計中應放在哪一層。

系統設計決策

• 冪等性是儲存關注點，而不是來源值映射關注點。
• 衝突重送應保持可見，因為靜默覆寫可能隱藏來源資料品質問題。
• 工作坊資料庫保持簡單，讓學習者不會混淆持久化政策與映射器邏輯。

15. 實驗室 11 — 不破壞既有事件的結構演進

開發人員任務

以一個新的選填來源欄位延伸黃光微影事件模型，同時保留相容性。

提示詞範例

未來來源串流可能會在 PHOTOLITHOGRAPHY_DRIFT_RISK 中新增 reticle_alignment_error。提出結構演進計劃。以最小變更更新映射器與測試，讓該欄位直接儲存或為 null。不要要求舊事件包含此欄位。

預期 Kiro 結果

// Minimal mapper addition inside driftSummary
reticle_alignment_error: message.reticle_alignment_error || null,

it("stores optional reticle alignment error when present", () => {
  const result = mapPhotoDriftRiskEvent({
    event_type: "PHOTOLITHOGRAPHY_DRIFT_RISK",
    drift_risk_event_id: "photo_schema_evolution_001",
    reticle_alignment_error: "0.006",
    risk_factors: []
  });

  expect(result?.driftSummary.reticle_alignment_error).toBe("0.006");
});

it("stores null for missing reticle alignment error", () => {
  const result = mapPhotoDriftRiskEvent({
    event_type: "PHOTOLITHOGRAPHY_DRIFT_RISK",
    drift_risk_event_id: "photo_schema_evolution_002",
    risk_factors: []
  });

  expect(result?.driftSummary.reticle_alignment_error).toBeNull();
});

業務邏輯說明： 隨著製程工程師加入新的來源遙測欄位，黃光微影風險模型會持續演進。
程式碼邏輯說明： 映射器只新增一個直接 nullable 欄位，並保持舊事件有效。
預期結果： 結構演進是加法式、可測試且與既有訊息相容。

系統設計決策

• 加法式選填欄位對事件串流演進而言比必填欄位更安全。
• 新來源遙測仍應遵循直接值或 null 的規則。
• 最小測試同時證明向前相容與向後相容。

16. 實驗室 12 — 依賴邊界審查

開發人員任務

要求 Kiro 審查黃光微影映射器是否有不適當的依賴。

提示詞範例

審查 photoDriftRiskMapper.ts 是否存在依賴邊界問題。映射器應保持純函式，不應匯入資料庫用戶端、時鐘、UUID 產生器、分析模型、儀表板發布器或控制命令用戶端。回傳 PASS 或 FAIL，並列出精確違規與最小修補指引。

預期 Kiro 結果

PASS 條件：
- 映射器不匯入任何資料庫用戶端。
- 映射器不匯入任何時鐘或 UUID 產生器。
- 映射器不匯入任何分析評分模型。
- 映射器不匯入任何儀表板或警示發布器。
- 映射器不匯入任何自動化控制命令用戶端。
- 映射器只回傳映射後的紀錄或 null。

FAIL 範例：
- 違規：映射器從分析模組匯入 `calculatePhotoRiskScore`。
- 重要性：持久化映射不得計算新的風險分數。
- 最小化修補：移除分析匯入，並直接儲存來源 process_window_risk_level 或 null。

業務邏輯說明： 依賴邊界可防止持久化程式碼觸發分析、警示或控制動作。
程式碼邏輯說明： 純映射器沒有副作用，因此更容易測試與審查。
預期結果： 開發人員能在依賴蔓延改變生產行為之前先辨識問題。

系統設計決策

• 純映射器保護規格所建立的僅限持久化範疇。
• 禁止匯入項目比細微執行階段副作用更容易審查。
• 讓控制命令依賴遠離映射器，可降低營運風險。

17. 實驗室 13 — 生產就緒審查包

開發人員任務

為黃光微影漂移風險模組建立生產就緒審查包。

提示詞範例

為黃光微影漂移風險持久化模組建立生產就緒審查包。包含範疇、測試證據、結構演進、冪等政策、營運擁有權、回復計劃與未解風險的就緒檢查。保持精簡並聚焦於此模組。

預期 Kiro 結果

# 黃光微影漂移風險生產就緒審查包
## 範疇確認
- 僅限持久化：是/否
- 無儀表板、警示、控制動作或派生計算：是/否
- 無關晶圓廠事件維持原樣委派：是/否
## 測試證據
- 具有多個因子的合規事件：pass/fail
- 遺漏 risk_factors 的行為：pass/fail
- 遺漏選填欄位：pass/fail
- 時間線欄位保持分離：pass/fail
- 設備警報不退化：pass/fail
## 結構演進
- 已記錄加法式選填欄位：是/否
- 舊事件仍然有效：是/否
- 新欄位遵循直接值或 null 映射：是/否
## 冪等性與資料品質
- 摘要冪等鍵已文件化：是/否
- 因子冪等鍵已文件化：是/否
- 重複/衝突審查路徑已文件化：是/否
## 營運
- 模組擁有者：
- 值班升級路徑：
- 回復計畫：
- 已知未解風險：
## 決策
- 可進行受控推出：是/否
- 推出前必要後續事項：

業務邏輯說明： 生產就緒審查將實驗室成品轉化為提供工程領導層使用的部署導向證據。
程式碼邏輯說明： 審查包參考測試與架構決策，而不是新增執行階段功能。
預期結果： 模組具備從 Kiro 生成實作到受控推出的清楚審查路徑。

系統設計決策

• 就緒審查結合程式碼品質、測試覆蓋率、營運與回復規劃。
• 明確列出未解風險，可避免隱藏假設變成生產事故。
• 黃光微影製程視窗變更可能影響良率，因此適合受控推出。

18. 進階實驗室完成情況檢核表

• 需求對測試可追溯性矩陣已建立。
• 冪等持久化政策已文件化，且未改變映射器範疇。
• 加法式結構演進計劃與測試已建立。
• 依賴邊界審查提示詞已建立。
• 生產就緒審查包已完成。