手填代码为何仍被保留：Akeneo记录编码生成器的生效边界

商品数据系统增加一个代码生成器，并不意味着已有记录都会获得新编号。Akeneo Serenity的Generate Reference entity record codes帮助，将它的生效条件放在记录创建时：新建reference entity record，而且没有手动提供代码。[1] 因而，理解这项功能首先要找出生成发生在什么时刻，而不是只看自动二字。

原文把用户界面、导入和API列为生成的三个入口。这三种入口可以触发同一类记录创建，但没有取消“新记录且未手填”的条件。如果记录已经有代码，生成器不会覆盖它；如果创建时明确给出了手动代码，也不会再由生成器另配一个。对商品资料同步说明，这使“经由导入产生”与“必然自动编号”能够分别表达。

已有记录被单独保护在这项变化之外。文档说，创建或修改生成器不会更新既有记录；修改或删除生成器，也不影响已经生成的记录代码。这里讨论的是规则影响未来创建对象，过去留下的代码继续保留。因此，同一份数据中出现不同形成时期的代码，不宜仅凭外观就断言系统已经对全部记录执行过同一规则。本文没有检查真实资料库。

生成器与实体之间还有覆盖关系。一个生成器可以用于一个或多个参考实体，也可面向尚未分配给其他生成器的实体；每个参考实体只由一个生成器覆盖。这使“规则有几套”与“被覆盖实体有几个”不必相等。相同规则可以跨实体使用，而某个实体又不能被这里所述多套生成器同时覆盖。

代码结构进一步说明怎样识别规则内容。帮助页列出固定文本、根参考实体代码和自动递增数字三类来源。固定文本提供不随每条记录改变的文字，实体代码联系所属实体，序号则表达递增部分。原文用包含PRD和序号的例子展示组合；本文不把PRD解释成平台规定的商品类别，也不从一小段代码擅自推断具体商品属性。

大小写和分隔符属于结构表达的另一个层次。文档列出保持原样、全部大写、全部小写，并说明可在组成部分之间使用下划线。自动数字还依据相同前缀曾经生成的最后数值继续取下一值。因此，阅读代码样式时，需要同时看组成来源和序列背景，而不是把某一行末尾的数字直接当作当前商品总数。本文不转写删除、重置或参数配置方法。

这些定义让资料交接可以区分手填代码、自动生成代码与既有记录，以及生成器覆盖什么实体、如何表达代码结构。它们共同说明新规则的生效对象，无须把生成器写成全库清洗或重新编号工具。本文采用Serenity现存帮助的连续文字，首次发布日期未知；不改权限、导入数据或运行API，也不由代码形成方式判断商品真实、合法或展示已获批准。