一开始，我没有马上让 AI 写代码，而是先研究全球成熟的配方软件，比如 BESTMIX、Format Solutions、Animal Diet Formulator 这些专业系统。

看完以后，我发现一个共同点：专业配方软件从来不是只算营养。它们真正解决的是一个系统问题：成本、原料、法规、工厂、批次、标签和追溯，最终都要放到同一个业务框架里。

第一版，我做了一个本地配方工作台。用户可以选择犬猫、生命阶段、产品形态，比如膨化干粮、湿粮、鲜粮、冻干，再选择对应的营养目标。

系统内置 AAFCO 营养标准，把蛋白、脂肪、钙磷比、牛磺酸、氨基酸等做成可计算规则，再接入最低成本优化。

也就是说，在满足营养标准、原料上下限和基础约束的前提下，系统可以计算出成本更优的原料组合。

它不一定能生产，也不一定合规，更不一定能长期稳定。

第二步，我把数据从浏览器迁入 SQLite 数据库。原料库、当前配方、历史配方、学习记录、版本历史、审计日志，全部持久化保存。

同时增加后台登录、角色权限、版本管理、导出和审计。真实企业里，配方不是一个人随手改完就结束。

从这一刻起，它不再是一个“配方计算器”，而是开始变成一个“研发后台”。

后面，我继续把系统往企业场景里推进，把功能拆成 P0、P1、P2 三层。

P0 是基础企业化模块：产品规格、标签生成、审批流、供应商档案和价格管理。P1 是工厂追溯模块：生产批次、原料批号、QA/LIMS 化验结果、ERP/MES/WMS 集成日志。P2 是多市场、多工厂、多法规体系的扩展。

否则，研发页面上的配方再漂亮，到工厂也可能变成另一回事。配方研发不是孤立动作，而是企业运营链条的一部分。

到这个阶段，我才开始真正接入 AI。但我给 AI 的定位非常明确：AI 是研发助手、诊断助手、学习助手，不是最终裁判。

它可以解释某个指标为什么不达标，可以建议哪些原料可以调整，可以分析成本结构，可以根据历史配方学习原料偏好，可以把市场竞品的公开标签整理成结构化信息，也可以根据化验异常和历史数据生成诊断建议。

AI 不能直接拍板配方。AI 应该参与配方研发流程，而不是替人承担专业责任。这是我从第一天就定下的边界。

很多人做 AI 系统，最后变成在页面上加一个聊天框。但我认为这不是最有价值的方向。

真正有价值的 AI，不是问一次答一次，而是能把企业每天发生的数据沉淀下来。所以我在后台增加了学习事件和学习状态，记录配方、供应商价格、化验结果、法规校验、审批、批次和集成日志。

然后 AI 可以从这些数据里持续生成建议：哪些原料高频使用？哪个品类成本基线偏高？哪些供应商价格波动大？哪些化验指标经常异常？哪些配方结构更容易通过优化？哪些原料组合在历史配方里更稳定？

接下来，我做了一个全球产品对标库，把 Open Farm、Stella、Zooplus、Amazon Japan、希尔斯、皇家等公开产品信息逐步结构化。

这里记录的，不是商业机密，也不是复刻配方，而是公开标签能够确认的信息：原料构成、营养指标、功能卖点、产品定位、适用对象和标签表达。

全价主食，可以参考其结构和营养逻辑。功能粮，可以研究其功能表达和原料方向。处方粮，只做公开信息研究和专业对标，不直接复刻。零食和补充剂单独分类，不被误判为主食配方。

这对研发非常重要。因为产品不是在实验室里凭空产生的，它一定要放到市场坐标里去看。

功能粮不是处方粮。这句话看起来简单，但在产品开发里非常重要。

肾脏管理、泌尿管理、胃肠护理、低敏水解、体重管理、皮肤被毛、关节护理，每一种背后的营养逻辑、理化指标和验证方式都不一样。

所以系统里必须划清边界。

功能粮可以按全价主食基础合规，再叠加功能成分、营养方向和对标指标。处方粮只能做公开信息研究和专业参考，不做治疗承诺，不直接生成商业处方。