与 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. 开发人员学习目标

在本工作坊结束时，开发人员将能够：

● 使用 Kiro 为黄光微影漂移风险模块建立技术规格。

● 根据制造事件示例生成 TypeScript 映射器与持久化处理程序。

● 保护既有的设备警报（equipment alarm）与自动化控制命令（automation command）逻辑不受影响。

● 为多因子风险事件、遗漏的选填字段、重复因子以及时间线语义新增测试。

● 使用 Kiro 审查不安全的实施并建立最小化修补。

● 通过系统设计推导来阐述每项设计决策。

---

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 应该会使用简单的映射并避免引入转换用的辅助函数。

说明： 存储的记录将与来源串流保持一致，以确保可追溯性。

系统设计决策

● Kiro 规格能在编写代码之前建立一个可供审查的产出物。这至关重要，因为黄光微影的工艺窗口（process windows）非常狭窄，微小的字段变更都可能对良率产生重大影响。这是一项系统设计抉择，因为黄光微影漂移风险持久化需要严格且专一的契约，以便开发人员在存储时（save-time）、测试时（test-time）及审查时（review-time）的反馈中进行推导。此决策使实验室聚焦于可观测的行为，而非流于宽泛的实施偏好，从而让学习者能将单一规则与特定的运作失效模式连结，避免增加不必要的平台复杂度。

● 「仅限持久化」的范畴能降低运营风险。它避免了将数据捕获（data capture）与自动化控制行为混为一谈。针对黄光微影漂移风险持久化，系统架构应在优化开发人员便利性之前，优先保留原始证据（source evidence）与既有的事件行为。这一点明确划定了界线：自动生成的辅助程序可以提出变更建议，但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来，系统将更容易被审计，且演进时更具安全性。

● 父子记录关系符合调查的工作流程：工程师首先识别出存在风险的曝光事件，接着审查各个传感器的影响因子。最后一个设计要点将实验室的行动转化为黄光微影漂移风险持久化的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性，开发人员可以改善工作流程，而不会将风险隐藏在庞大的重构或隐含的假设之中。

---

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 将使用此确切的结构来建立映射器与测试。

系统设计决策

● 具体的事件示例可防止在代码生成期间凭空捏造字段。这是一项系统设计抉择，因为黄光微影漂移风险持久化需要严格且专一的契约，以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为，而非流于宽泛的实施偏好，从而让学习者能将单一规则与特定的运作失效模式连结，避免增加不必要的平台复杂度。

● 独立的时间字段可在事件审查期间保护时间线分析（timeline analysis）的能力。针对黄光微影漂移风险持久化，系统架构应在优化开发人员便利性之前，优先保留原始证据与既有的事件行为。这一点明确划定了界线：自动生成的辅助程序可以提出变更建议，但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来，系统将更容易被审计，且演进时更具安全性。

● 因子级别的记录保留了根因分析所需的传感器上下文。最后一个设计要点将实验室的行动转化为黄光微影漂移风险持久化的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性，开发人员可以改善工作流程，而不会将风险隐藏在庞大的重构或隐含的假设之中。

---

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。

系统设计决策

● 纯粹的映射器（pure mapper）使得代码生成更易于测试，且不依赖数据库。这是一项系统设计抉择，因为黄光微影漂移风险持久化需要严格且专一的契约，以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为，而非流于宽泛的实施偏好，从而让学习者能将单一规则与特定的运作失效模式连结，避免增加不必要的平台复杂度。

● 精确的事件匹配可规避处理无关的晶圆厂事件。针对黄光微影漂移风险持久化，系统架构应在优化开发人员便利性之前，优先保留原始证据与既有的事件行为。这一点明确划定了界线：自动生成的辅助程序可以提出变更建议，但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来，系统将更容易被审计，且演进时更具安全性。

● 直接映射保持了来源遥测数据与存储记录的可比性（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);
}

业务逻辑说明： 处理程序会持久化黄光微影漂移风险记录，并将所有无关消息委派给既有的晶圆厂逻辑。

代码逻辑说明： 映射器负责判定资格。处理程序仅在映射器返回记录集时才会写入记录。

预期结果： 针对合规事件，处理程序会建立一笔摘要与多个因子。

系统设计决策

● 将映射器与处理程序分离，可确保业务映射的可测试性，并保持持久化流程的简洁。这是一项系统设计抉择，因为黄光微影漂移风险持久化需要严格且专一的契约，以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为，而非流于宽泛的实施偏好，从而让学习者能将单一规则与特定的运作失效模式连结，避免增加不必要的平台复杂度。

● 委派无关事件可保护既有的运营行为。针对黄光微影漂移风险持久化，系统架构应在优化开发人员便利性之前，优先保留原始证据与既有的事件行为。这一点明确划定了界线：自动生成的辅助程序可以提出变更建议，但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来，系统将更容易被审计，且演进时更具安全性。

● 采用内存内数据库（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();
  });
});

业务逻辑说明： 这些测试验证了映射、持久化以及对无关事件的拒绝逻辑。

代码逻辑说明： 映射器测试会查看返回的记录；处理程序测试则会验证写入数据库的记录。

预期结果： 所有测试皆顺利通过。

系统设计决策

● 同时测试映射器与处理程序，能将字段映射的正确性与持久化流程相互解耦。这是一项系统设计抉择，因为黄光微影漂移风险持久化需要严格且专一的契约，以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为，而非流于宽泛的实施偏好，从而让学习者能将单一规则与特定的运作失效模式连结，避免增加不必要的平台复杂度。

● 针对遗漏因子（missing-factor）的测试，可确保在缺乏因子数组时，合规的摘要记录仍能被成功持久化。针对黄光微影漂移风险持久化，系统架构应在优化开发人员便利性之前，优先保留原始证据与既有的事件行为。这一点明确划定了界线：自动生成的辅助程序可以提出变更建议，但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来，系统将更容易被审计，且演进时更具安全性。

● 拒绝设备警报事件保护了非风险相关的运营事件行为。最后一个设计要点将实验室的行动转化为黄光微影漂移风险持久化的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性，开发人员可以改善工作流程，而不会将风险隐藏在庞大的重构或隐含的假设之中。

---

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）之间的权责区分。

系统设计决策

● 重复 ID 的处理应是一项显性的设计决策，而非映射器意外产生的副作用（side effect）。这是一项系统设计抉择，因为黄光微影漂移风险持久化需要严格且专一的契约，以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为，而非流于宽泛的实施偏好，从而让学习者能将单一规则与特定的运作失效模式连结，避免增加不必要的平台复杂度。

● 「仅限持久化」的代码不应默默地自动修复（silently repair）来源数据。针对黄光微影漂移风险持久化，系统架构应在优化开发人员便利性之前，优先保留原始证据与既有的事件行为。这一点明确划定了界线：自动生成的辅助程序可以提出变更建议，但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来，系统将更容易被审计，且演进时更具安全性。

● 事件质量验证可在未来有需要时作为一项独立功能加入。最后一个设计要点将实验室的行动转化为黄光微影漂移风险持久化的长期工程实务。它说明了所选定的范畴边界如何支持团队审查、未来的维护以及受控的版本推出。藉由保持行动的最小化与可衡量性，开发人员可以改善工作流程，而不会将风险隐藏在庞大的重构或隐含的假设之中。

---

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）发生在不同的时间点。

代码逻辑说明： 映射器将每个时间字段存储在其对应的输出字段中。

预期结果： 测试在未修改生产环境代码的情况下顺利通过。

系统设计决策

● 事件分析与审查需要精准的事件顺序。这是一项系统设计抉择，因为黄光微影漂移风险持久化需要严格且专一的契约，以便开发人员在存储时、测试时及审查时的反馈中进行推导。此决策使实验室聚焦于可观测的行为，而非流于宽泛的实施偏好，从而让学习者能将单一规则与特定的运作失效模式连结，避免增加不必要的平台复杂度。

● 合并时间字段可能会隐藏处理延迟（processing delay）或传感器领先时间（sensor lead time）。针对黄光微影漂移风险持久化，系统架构应在优化开发人员便利性之前，优先保留原始证据与既有的事件行为。这一点明确划定了界线：自动生成的辅助程序可以提出变更建议，但系统仍须对可追溯性、可重复性及生产环境不退化负责。这样一来，系统将更容易被审计，且演进时更具安全性。

● 测试可使时间线语义成为具备执行能力的活文件（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. 进阶实验室完成情况检核表

● 需求对测试可追溯性矩阵已建立。

● 幂等持久化政策已文件化，且未改变映射器范畴。

● 加法式结构演进计划与测试已建立。

● 依赖边界审查提示词已建立。

● 生产就绪审查包已完成。