如何在40款产品之间保持INCI和CAS数据的一致

大约做到第十五或第二十款产品的时候，很多化妆品品牌都会撞上同一堵墙。不是配方上的墙，是行政管理上的墙。你已经为乳木果油分别查过四次INCI名称和CAS编号，因为三个不同的团队成员配制了三款不同的产品，谁也没去核对上一个人已经查到过什么。把这种情况乘以四十个SKU，你手上就会是一堆凌乱的电子表格，每一份都略有不同，没有哪一份能算是真正的权威版本。

为什么就算是细心的品牌也会遇到这个问题

这不是粗心，而是结构问题。大多数小品牌都是按产品逐个建立成分数据的，因为工作本来就是这么来的：有人定型了一款润唇膏配方，查了它五种成分，完成申报，接着做下一款产品。没有一个自然的时刻，让人停下来说"我们来把用过的每一种成分都整理成一份清单，一次性、正确地做好"。

结果就是重复带来的偏差。成分数据不是一成不变的，供应商文件会更新，某种植物萃取物的CAS状态会被明确，如果同一种成分同时存在于六份不同的产品清单里，而只有其中一份在新信息出现时被更新，你就有五份过时的记录，静静躺在旧文件里，可能被人在不知情的情况下用到下一款产品上。

一个统一成分数据库到底长什么样

这个概念很简单：一张主表，涵盖你品牌用过或正在考虑使用的每一种成分，配上一套固定字段，一旦填好就不需要重新推导。

字段	为什么需要
商品名/供应商名称	出现在供应商发票或规格表上的名称
INCI名称	出现在标签和申报文件上的标准化名称
CAS编号（如适用）	唯一的化学标识符，部分萃取物没有
供应商与来源	便于日后有问题时追溯
混合物成分（如适用）	对于供应商混合物，列出内含成分及其比例
已知限制	已经研究过的任何浓度限制或特定市场标记
最后核实日期	让过时的条目一目了然，而不是被隐藏起来

一旦乳木果油（Butyrospermum Parkii Butter）连同其CAS编号和相关备注被录入这张表，之后每一款用到乳木果油的产品都可以直接调用这一行已核实的数据。没有人需要重新研究，也没有人会不小心用了一个略有出入的INCI拼写，导致整个产品线上的标签出现不一致。

在数据库中处理供应商混合物

混合物值得在数据库中单独处理，因为它们是申报出错最常见的来源。供应商的"保湿复合物"或"防腐剂混合物"需要在数据库层面拆解成实际的INCI成分，并记录比例，这样当一款新产品使用3%的这种混合物时，负责申报的人就能立刻算出，比如说，一种在混合物中占20%的防腐剂成分，在成品中实际只有0.6%。把这个计算做一次，把混合物的拆解结果永久记录下来，之后每一款用到同一混合物的新产品都可以完全跳过重新推导这一步。

为什么这个问题会随着规模扩大而累积

只有五款产品时，重复查找顶多浪费你一个下午。到了四十款，代价就变成了真金白银，既包括研究时间，也包括申报出错的风险，比如有人把INCI名称打得和上次略有不同，或者漏掉了某种成分在一个市场接近浓度限制、而在另一个市场并非如此。监管审核人员和申报系统都非常看重INCI的精确匹配，即使是很小的不一致（比如Aqua和Water之间的差异，或化学名称里漏掉一个连字符），也会造成麻烦，哪怕它们本身并不构成安全问题。

保持数据整洁还有一个现实的商业原因：尽职调查。如果你正在融资、寻求批发合作，或者未来打算出售品牌，当买家或合作伙伴问"给我看看你的成分合规记录"时，拥有一份干净数据库的品牌，和拥有四十份新旧不一、散乱各处的电子表格的品牌，得到的评价会截然不同。

不必推倒重来，也能开始搭建

你不需要一次性重建整个产品线的成分数据。从下一次申报开始建立这个数据库，不管是现有产品还是新产品，然后借助日后修改或重新配方的机会，顺便把以前的产品补录进去。只要坚持一年，你的大部分产品线自然而然就会流入这个数据库。

这本质上正是Cosmetic Comply在平台层面要解决的结构性问题：你提交的每一种成分都会被匹配到对应的INCI名称和CAS编号一次，供应商混合物会被拆解成真实成分并带入百分比计算，而且这份映射会一直保留下来，让下一款用到同一成分的产品不必从零开始。为一个小变体提交修订申报，或复制一份过去的申报，也是同样的道理，建立在已经核实过的基础上，而不是重新争论一遍。