把产品当作数据，不是页面截图
一件产品需要稳定标识和可复用属性，页面只是数据的一种呈现。
先识别产品族、型号、变体和附件之间的关系。为每条记录定义唯一 ID、名称、状态、类别、关键属性、包装、媒体、文档、适用市场和负责人。若同一产品在 ERP、表格和 PDF 中名称不同，要先决定哪个系统是事实来源。
不要为了页面整齐强迫所有品类使用同一组字段。共用字段承担搜索和治理，品类字段承担专业比较；单位、枚举、必填条件和缺失值都应有明确规则。
- 每个产品与变体都有稳定唯一标识
- 属性包含单位、允许值和维护负责人
- 媒体、说明书和证书记录版本与适用型号
- 停产、替代与仅内部可见状态可以被区分
围绕采购任务设计分类、搜索与比较
内部组织方式不一定等于采购者的查找方式。
采购者可能从用途、材料、尺寸、行业、认证或兼容设备进入，而销售团队可能按事业部管理。通过访谈、既有询盘和搜索日志确认常用入口，再决定层级导航、筛选项和站内搜索同义词。
详情页应先呈现决定是否继续的字段，再提供完整规格、下载和相关产品。比较功能只适用于具有可比字段的产品，不能把缺失数据自动当作“不具备”。
查找
分类、筛选、关键词、型号、同义词与拼写容错。
判断
关键规格、适用场景、限制、文档、版本和更新日期。
继续
询价、索样、下载资料、联系地区负责人或保存清单。
让产品事实共享，让市场表达分开
多语言目录需要同一事实底座和市场化内容层。
型号、材料、尺寸和版本应从共享数据产生；产品标题、用途解释、SEO 文案和下载文件可以按市场维护。术语表要规定单位、缩写和受保护名称，避免不同语言版本各自创造不同分类。
认证、合规、可售地区与声明必须有来源和有效期。若信息仅适用于某个型号或市场，应在数据层关联，而不是在正文里加一句模糊脚注。
- 共享属性与本地化字段已经分开
- 单位换算保留原始值与展示值
- 下载文件与页面语言、型号和版本匹配
- 认证与合规声明有负责人、来源和复核日期
把询价设计成可处理的业务对象
“请联系我们”无法告诉销售客户看了什么、需要多少、来自哪个市场。
询价动作应带上产品 ID、变体、数量、用途、地区、语言和页面来源，同时允许采购者添加多个产品。首步不要索取不必要的敏感信息；销售需要的补充文件可以在建立联系后通过合适渠道交换。
后台要定义分配、去重、状态和反馈：谁接收新询盘，谁处理产品与供应信息，什么时候需要技术确认，哪些状态回写 CRM。邮件、微信和 WhatsApp 可以作为沟通渠道，但结构化询价记录应保留在可追踪系统中。
- 表单自动携带产品与页面上下文
- 地区、语言和需求类型可以用于分配
- 重复询价、垃圾信息和接口失败有处理规则
- 询价状态和最终结果可以用于改进目录
按数据成熟度分阶段上线
先交付可信目录和询价，再增加实时价格、库存与交易。
第一阶段可以完成数据清理、分类、详情、下载和结构化询价；第二阶段连接 PIM、ERP 或 CRM；只有价格、库存、税务、支付和履约规则都稳定后，才进入在线交易。
每阶段都要有导入校验、预览、权限、日志、备份和回退。目录的长期成本主要来自数据更新与系统责任，而不是首版页面数量。
- 阶段目标与不包含内容写入范围
- 数据导入有错误报告和人工复核
- 编辑权限、发布审批和历史版本明确
- 接口中断时页面和询价仍有降级路径
带走这四点。
- 01
先建立产品数据模型，再设计目录页面。
- 02
分类与筛选应按采购任务，而不是只按内部部门。
- 03
多语言共享产品事实，但保留市场化表达。
- 04
询价必须携带产品上下文并进入可追踪流程。