2. Recipe全生命周期管理框架
Recipe不是一份“调好就放着”的参数文件，它更像一个有生命周期的受控对象：从工艺开发阶段被创建，经过设备验证获得可执行资格，在量产释放后进入受控生产状态，随后因工艺漂移、设备改造或产品迭代而变更维护，最终在机台退役或产品停产后归档封存。如果缺少统一的生命周期框架，常见后果是：开发版Recipe被误用于量产、变更后未重新验证、旧版本无法追溯、退役机台上的Recipe成为“孤儿数据”。本节给出一条可落地的全生命周期主线，并明确每个阶段的关键里程碑与放行判据。
一、五个阶段与状态跃迁
把Recipe生命周期划分为五个阶段，每个阶段对应一个受控状态，状态之间的跃迁必须由明确的里程碑事件触发，而不是由时间或人为习惯决定。
- 工艺开发（Draft/开发态）：在工艺实验机或开发机上创建Recipe，参数可自由调整，允许频繁修改。此阶段Recipe不参与生产，版本号可用0.x表示。
- 设备验证（Qual/验证态）：Recipe在目标机型上完成工艺窗口确认、均匀性/重复性测试与缺陷检查，形成验证报告。里程碑是“验证通过并签署”，Recipe冻结为1.0。
- 量产释放（Released/释放态）：Recipe经MES/APC系统授权，绑定到指定产品、指定机台组，进入可被生产调用的受控状态。里程碑是“释放审批完成并下发到机台”。
- 变更维护（Change/变更态）：因工艺漂移、耗材更换、设备改造或产品升级而修改Recipe。任何修改都必须走变更申请（ECN/ECR），并重新验证。里程碑是“变更验证通过并重新释放”。
- 退役归档（Retired/归档态）：机台退役、产品停产后，Recipe被标记为不可用，但必须保留完整版本历史与验证记录，供追溯和审计。里程碑是“归档确认并锁定只读”。
这五个阶段不是简单的线性流程，而是带有回退和循环的结构：变更态可以回到验证态，验证失败可以退回开发态，释放态在发现异常时可以临时挂起（Hold）再进入变更态。下图给出状态跃迁与关键里程碑的关系。
二、各阶段的关键动作与放行判据
工艺开发阶段的核心是“可调可控”。开发Recipe通常包含工艺参数（温度、压力、功率、气体流量、时间）和设备参数（间距、位置、速度）。此阶段允许使用开发机台，但必须记录每次实验的Recipe版本与对应结果，避免“参数改了但没记录”。放行判据是：工艺窗口初步确定，关键参数敏感度已评估，具备进入设备验证的条件。
设备验证阶段的核心是“可重复、可复现”。验证必须在目标量产机型上进行，至少覆盖：膜厚/线宽/均匀性、重复性（同一Recipe连续跑3~5片）、再现性（不同机台或不同时间）、缺陷水平。以某刻蚀Recipe为例，验证时记录：刻蚀速率均值、片内均匀性（WIWNU）、片间均匀性（WTWNU）、关键尺寸偏差。放行判据是：所有指标落在工艺规格内，且验证报告经工艺工程师与设备工程师双签。此时Recipe版本冻结为1.0，进入受控库。
量产释放阶段的核心是“授权与绑定”。Recipe必须与产品、机台组、工艺步骤绑定，并通过MES/APC系统下发。释放前需确认：Recipe版本与验证版本一致、机台状态正常、参数与验证报告一致。释放后，任何对Recipe的修改都必须走变更流程，不能直接在机台上改参数。放行判据是：释放审批完成，机台端Recipe校验和（Checksum）与系统记录一致。
变更维护阶段的核心是“受控变更”。变更来源包括：工艺漂移补偿、耗材寿命调整、设备硬件改造、产品规格升级。变更流程为：提出ECR→评估影响→在开发机或验证机修改→重新验证→更新版本号→重新释放。版本号建议采用“主版本.次版本”规则：主版本变更表示工艺窗口或关键参数改变，次版本变更表示微调或补偿。变更后必须重新验证，不能以“只改了一个参数”为由跳过验证。
退役归档阶段的核心是“可追溯、不可改”。当机台退役或产品停产后，Recipe应标记为Retired，从生产可用列表中移除，但保留完整版本历史、验证报告、变更记录和释放记录。归档数据应只读锁定，保存期限根据质量体系要求确定（常见为产品停产后5~10年）。归档不是删除，而是“封存可查”。
三、版本号与状态标签的配合
为了让生命周期可管理，建议Recipe命名中同时体现状态与版本，例如：ETCH-AA-001_1.2_Released。其中ETCH-AA-001是Recipe标识，1.2是版本号，Released是状态标签。状态标签至少包括：Draft、Qual、Released、Hold、Retired。Hold状态用于释放后发现异常时临时挂起，防止继续生产，待问题澄清后决定回到Released还是进入Change。
四、里程碑签署与责任分工
每个里程碑都需要明确的签署人和签署内容。开发→验证的里程碑由工艺工程师签署，确认工艺窗口；验证→释放的里程碑由工艺与设备工程师双签，确认验证报告；释放→变更的里程碑由变更控制委员会（或工艺主管）批准ECN；变更→重新释放的里程碑再次双签；释放→归档的里程碑由设备工程师与质量工程师确认。签署记录应包含：Recipe标识、版本号、签署人、签署时间、验证报告编号。这样在出现质量异常时，可以快速定位到“哪个版本、谁签署、依据哪份报告”。
五、常见误区与防错要点
- 开发版直接用于量产：开发态Recipe未经验证，参数可能超出工艺窗口。防错：系统层面禁止Draft状态Recipe被生产调用。
- 变更后不重新验证：认为“只改了一个参数”不影响结果。防错：变更流程强制关联验证任务，未完成验证不能释放。
- 版本号手工维护：容易出现版本错乱。防错：版本号由系统在每次释放时自动递增。
- 退役后直接删除：导致追溯断链。防错：退役操作只允许标记Retired并锁定，不允许物理删除。
- 机台端与系统端不一致：机台上实际执行的Recipe与系统记录不符。防错：释放时校验Checksum，并定期巡检比对。
把上述框架落到日常工作中，最直接的动作是：为每个Recipe建立生命周期台账，记录当前状态、版本号、最近一次验证日期、最近一次变更日期、签署人。台账不需要复杂工具，一张受控表格即可起步，但必须与MES/APC系统中的实际状态保持一致。只有状态、版本、签署三者对齐，Recipe管理才真正具备防错能力。