多租户 PIM
AI 内容增强
向量检索 / RAG
多渠道同步
角色与范围
从设计到实现全部由我完成，并持续演进至今：一个多租户 PIM 平台，具备租户隔离（超级管理员、租户管理员、租户用户）、草稿/发布工作流（每处改动上线前都会经过评审），以及带前后快照的完整审计日志。
- 以 Shopify 为先的同步，另有 NetSuite ERP 对接，并通过 ChannelEngine 导出至 Amazon 及其他平台。
- 用 AI 增强标题、描述、SEO 文案与译文——生成内容在发布前须经复核环节。
- 内置 RAG 助手，让产品团队通过聊天检索并操作商品目录：对商品数据做向量检索，涉及操作的工具调用需用户先行批准。
- 一个独立的 Chrome 扩展，让团队把平台页面上的商品直接送入内容增强队列。
- 欧盟 GPSR 合规模块、带关键词搜索量校验的 SEO 模块，以及通过带重试的队列执行的后台任务（向量同步、内容增强、调度器）。
成果
- 核心市场超过 3,400 个在售商品，并向 Amazon 等平台的数百个额外商品页输出数据。
- 一条会静默覆盖类目 URL 的 AI 翻译流水线被回滚，并替换为会创建重定向、并将全部改动写入审计轨迹的版本。
- 每次关联 NetSuite 都会覆盖 AI 内容与 Shopify 改动的同步缺陷，从结构上得到解决，而不再每次手工修补。
- 八个月持续开发中的 350 多次提交——不是一次性交付，而是随商品结构一同成长的系统。
架构
Turborepo 单仓，后端 NestJS，前端 Next.js 14（App Router），共用 Prisma 数据库包与共享类型。启用 pgvector 扩展的 PostgreSQL 同时存放商品数据与向量嵌入，因此向量检索与常规查询运行在同一个数据库上。后台任务（向量同步、AI 内容增强、平台同步）经由基于 Redis 的队列执行，带自动重试与指数退避，并与界面解耦，使某个平台同步变慢时不会阻塞平台其余部分。
模型选择
内置的 RAG 助手刻意采用多供应商策略：不同任务走不同模型（从用于日常对话的低成本模型，到处理复杂增强任务的更重量级 Claude 与 GPT 版本），并按模型记录 token 价格，使每次对话的成本可见而非黑箱。生成内容（标题、描述、译文）始终先进入复核环节——模型提议、人工确认；这与其他项目中价格逻辑从不直接交由语言模型处理，是同一个道理。
成本与延迟
- 按模型记录每次对话的 token 成本，使更昂贵的模型是被有意识、可见地启用，而非默认使用。
- 后台任务（向量同步、内容增强）异步运行，最多重试 3 次并采用指数退避，使某个平台的临时故障不会立即造成数据丢失。
- 向量检索与常规商品查询运行在同一个 PostgreSQL 实例（pgvector）上，省去了独立向量数据库及其同步层。
经验总结
AI 翻译流水线在译文被重新生成时会不加提示地覆盖类目 URL——表面上有利于 SEO，实则破坏了既有外链。解决方式是恢复历史 URL、补上重定向，并建立审计轨迹，使此类改动今后在上线前即可见。第二个缺陷：商品一旦与 NetSuite 关联，每次 NetSuite 同步都会覆盖 AI 生成内容与 Shopify 上的改动——这不是偶发事故而是结构性问题，通过重新梳理同步方向解决，而非每次手工修补。第三个更小但很说明问题：翻译流水线会译错“RVS”（不锈钢）这类材料缩写，改以显式术语表规则解决，而不是指望模型自行猜出行业知识。