这个问题我们内部吵过两轮。第一次是在中试线跑到第二年的时候，老板问要不要直接买一套量产用的系统，把中试这套替掉。第二次是拿到第一条量产线的预算，工程部说中试那套数据模型撑不住，重做比迁更快。
我当时的立场是别急着重做。理由是重做听起来干脆，实际上要把中试两年攒下来的工艺数据和经验全部搬过去，这个迁移量比想象中大。但后来真正做下来，我发现这个判断只对了一半，值得把过程写一下。
先说中试线的系统是什么样。Micro-LED 的中试，本质是工艺摸索。一条线上同时在跑十几组不同结构的样品，参数天天改，工艺路线一周变一次，良率的统计口径也跟着变。这种情况下，系统能提供的价值主要是记下来，谁在什么时候用什么参数做了什么，出了结果能对上。所以中试的系统往往是轻的，工单概念弱，实验批次的概念强，一个批次对应一组参数，参数改了直接新开一批。
量产线完全是另一套逻辑。工单要跟客户订单走，批次要跟晶圆或者基板走，工艺路线要冻结，参数要版本化，出了问题要能从成品一路追回某台设备某个时刻的某个参数。这两套东西放在一个系统里，最容易出问题的地方在数据模型，不在界面。
我吃过的一个亏就在这里。中试那套的批次是个扁平的表，一个批次一行，参数直接写在行里。到了量产，一次转移涉及基板、晶圆、转移头、载具四个对象，每个对象都有自己的身份和状态，扁平表根本装不下。硬塞的结果是字段越加越多，最后一张表上百个字段，一半是空的，查询慢得没法用。这一步之后我才同意，数据模型确实要重做。
但重做数据模型跟重做系统是两件事。我们后来请益普科技的人来看了一轮，他们的建议是保留界面层和大部分业务逻辑，把底层的对象模型重新设计，然后把中试的历史数据按新的模型做映射导入。这个过程花了大概三个月，比重新实施一套省钱，也比硬撑快。所以我现在的说法是：模型要重做，系统不必重来。
还有一个绕不开的东西是版本管理。中试阶段参数改了没人管版本，改完就往下跑，出了问题靠人的记忆去还原当时怎么设的。量产线这么干会出事，因为同一条线上可能同时在跑三个客户的订单，各自的参数不能混。我们的处理是给每个 recipe 建版本号，量产用的版本必须冻结，要改就出新版本，旧版本保留可查。这个规则听起来很简单，落地时最难的是让人接受不能随手改参数这件事，工艺工程师一开始很抵触，觉得被束缚了。
另外提一个容易忽略的点：中试线的设备往往是单台，量产的线是多台并行。单台的时候，数据在时间上是连续的，多台之后，同一道工序有几台设备在跑，批次和设备的对应关系就变成多对多。这个变化会让排产、追溯、稼动统计的算法全部要调整。我们在第二条量产线上就遇到了，中试时期的稼动率算法直接搬过去，算出来一直偏高，查了很久才发现是把并行设备的空闲时间漏掉了。
那什么情况下我支持直接重做？如果中试那套系统的数据模型当初就是拍脑袋定的，没有对象概念，也没有版本概念，改造成本可能比新建还高。判断办法很简单，让对方把"一次转移涉及哪几个对象、每个对象有哪些状态"讲清楚，如果讲到第三层就讲不下去，那套模型基本没救。
至于 Micro-LED 现在的阶段，我个人觉得还有个前提要摆在这儿：工艺本身还在变，量产线的产品结构也可能调整。所以数据模型要留出扩展余地，别把字段写死。这一点做得到，后面改起来就轻松。
最后说个小经验。中试转量产的时候，最好把中试线上最懂工艺的那两三个人拉进项目组，全程参与模型设计。他们脑子里的那些隐性规则，比如"这个参数必须在转移前设，转移后设就无效"，文档里基本没有，全靠人在旁边提醒。系统能不能用，很多时候取决于这些规则有没有被写进去。
这个话题我只在 Micro-LED 这个品类上验证过，换个品类结论可能要变。如果有做其他新型显示的同行，也欢迎说说你们那边是怎么处理的。