这个品类的数据长什么样
化妆品品类的收益率与行情数据主要来源于品牌内部ERP进销台账、主流电商平台公开销售接口、线下零售终端上报数据。常规场景下每日凌晨更新前一日全渠道的完整销售数据，新品上线或促销节点时每6小时更新一次临时数据。单条数据文档结构包含SKU编码、品牌名称、产品全称、销售渠道分类、当日终端售价、进货单位成本、当日销量、当日营收金额，其中售价、成本、营收的单位为元，销量单位为件。数据会按SKU维度聚合，避免单条记录包含过多冗余信息。
这些特征在「对话日志与审计」这一环带来什么约束
多来源的数据调用需要在对话日志中完整记录调用链路，区分ERP接口、电商接口的不同调用来源，避免在对话回复中混淆不同渠道的数据。不同更新频率的任务需要在审计日志中标记触发时机，区分定时自动更新与手动临时更新的操作，确保审计可追溯。多字段的校验逻辑需要逐字段记录校验结果，防止因售价、成本字段缺失导致对话中返回的收益率计算错误。单日报数据量较大的特点要求日志按SKU分块存储，避免单条日志文件过大影响对话历史的检索效率。涉及进销成本的经营数据，需要记录每一次数据修改的操作主体与时间，满足合规审计的追溯要求。
配置怎么定
| 配置项 | 建议取法 | 这样取的依据 |
|---|---|---|
log_retention_days | 90 天 | 化妆品经营数据需符合行业审计留存周期要求，90天可覆盖常规月度复盘与季度检查 |
api_log_include_fields | ["SKU编码","品牌名称","当日售价","进货成本"] | 仅保留收益率计算与审计所需的核心字段，减少日志存储开销与检索耗时 |
workflow_node_log_level | debug | 化妆品数据校验环节复杂，debug级别可完整记录每个组件的输入输出，便于排查数据异常 |
max_log_file_size | 512 MB | 限制单日志文件大小，避免单日报数据量过大导致存储溢出，便于后续日志归档与检索 |
audit_trigger_condition | 每日02:00 + 手动触发 | 匹配常规数据更新时间，同时支持促销期临时审计的灵活需求 |
conversation_history_save_trigger | 包含收益率播报关键词 | 确保化妆品收益率播报的对话内容被自动保存，避免历史记录丢失 |
本页给出的参数取值均为常规建议，用于确定配置的起点。实际取值受材料形态、数据量与业务规则影响，具体问题需具体分析，建议在自有样本上实测后再定。
容易做错的三处
- 现象：在对话界面查看历史记录时，之前发送的化妆品收益率播报内容未显示，重新发起对话后返回空内容。原因：未配置
conversation_history_save_trigger参数，未将收益率播报的回复内容纳入自动保存范围。 - 现象：查看工作流中MCP服务的日志时，仅显示基础状态码，无详细报错信息。原因：未将
workflow_node_log_level设置为debug，仅采集了基础日志级别数据，缺失详细调用链路信息。 - 现象：API调用日志的
source字段仅显示固定关键字，无法区分电商接口与ERP接口的调用来源。原因：未在api_log_include_fields中配置source_type字段，未将调用来源纳入日志采集范围。
怎么确认配好了
- 手动触发一次化妆品收益率播报任务，检查工作流日志面板，确认包含所有配置的核心字段。
- 查看系统日志管理界面，确认审计日志的留存天数与预设的
log_retention_days配置一致。 - 发起一次API调用，检查返回的日志中是否包含
source字段及对应调用来源的取值。 - 完成一次完整的收益率播报对话，关闭对话后重新打开，检查历史记录中是否保存了完整的播报内容。
问题素材取自公开社区提问（2026-09-11 去重 4,834 条）。文中的配置项名称与取值区间需以所用版本的实际界面与文档为准；本页核验日 2026-09-14，当时的最新发布版本为 FastGPT v4.17.0。