练习时长 1 年

I'm Elara 郭筱婷
an AI Product Manager Trainee

🎓 UM商分硕士在读 🤖 大模型重度用户 💡 产品思维践行者

白天评审舌战群儒，晚上和PRD缠缠绵绵

我的 Project 能力延伸

点击卡片查看详情

从问题出发，用数据、研究和技术建立判断

如何处理那些一开始并不清晰的问题？

5 个项目，带你看我的思考及处理点击卡片查看详情

技术方案摘要

12 阶段渐进式框架，而非巨型 SQL

暴力做法

200 行巨型 join → 难 debug、易超时、50 维报表没人知道「该怎么办」。

12 阶段

每阶段一个商业问题；描述→诊断→预测→处方；临时表串联成可解释决策链。

判断：框架是把复杂问题拆成 PM 和业务方能跟上的颗粒度——讲不清楚，技术再强也没用。

临时表设计：54M → 462K

booking 54.3M 行；5 个阶段都要「每航班总收入」→ 重复 group by 不可接受。Phase 4 建 flight_revenue，一次聚合、100× 压缩，Phase 4–5 复用、Phase 5 末 DROP。

临时表	创建	使用	销毁
flight_revenue	P4	P4–5	P5 末
customer_value_class	P5	P5, 12	P12 末
route_premium_profile	P5	P5, 12	P12 末
passenger_revenue	P7	P7	P7 末
grand_total	P7	P7	P7 末

判断：识别复用单元、定义生命周期、显式 DROP——产品架构思维，非单纯性能技巧。

NTILE 三档粒度，各有所图

• NTILE(3) — 客户价值三档 → 行动决策（Premium / Standard / Budget）
• NTILE(4) — 价格四分位 → 定价话术锚点「Top 25%」
• NTILE(5) — 收入五分位 → 验证 Pareto 80/20

实证 Top 20% 仅贡献 23.44% 收入 → Pareto 失效，战略转向规模化覆盖而非高端会员。判断：工具参数匹配业务颗粒度。

CTE 优先，可读性 > 极致简洁

嵌套子查询

从内到外反向解析；debug 难；业务方看不懂。

WITH … AS (CTE)

阅读顺序 = 思考顺序；每个 CTE 有名字即文档；可组合拆分。

判断：SQL 写给下一个读代码的人（含三个月后的自己）。

行业经验写进 CASE WHEN

权重在文档里

分析师各用各的权重 → 结果不可比；更新要手算历史；不可审计。

权重在 SQL 里

雪 ×3 / 雷暴 ×2 / 风暴雹 ×2 / 雾霾 ×1 → 可复现、可审计；改一个数字全局更新。

判断：把业务规则编译成机器可执行代码——数据产品是产品，数据报告是 Excel。

技术方案摘要

最终方案：KPCA + MLP

组合	准确率	F1	采用
KPCA + MLP	55.4%	59.8%	是
PCA + RF	54.1%	54.1%	—
LDA + Logistic	54.1%	51.4%	—

• F1 差距 > 准确率差距：上涨信号捕捉更优，错过上涨比误判下跌更伤用户
• C 端 MVP：可解释性弱可接受；日频策略，训练慢可接受

判断：选型看「失误模式是否最不伤害用户」，不是只看准确率。

三种降维并行，而非直接喂 22 特征

学术思路

22 特征全喂，让模型自选——共线性、过拟合、KPCA 算力爆炸。

产品思路

PCA / KPCA / LDA 并行：分别假设线性、非线性、有监督涨跌目标。

结论：KPCA 胜出 → A 股更偏非线性、高噪声。判断：降维是「市场结构假设」，不是数学炫技。

严守 T+1 与 0.1% 交易成本

学术取巧

T+0、零成本 → 理论 30% 年化，上线即失效。

产品思路

真实约束下 13.9% 年化，比「假回测」更有说服力。

• 信号 shift(1) 实现 T+1；仓位变动扣 0.1% × |Δ仓位|
• 训练 / 验证 / 测试按时间 70/15/15 切分，杜绝前视偏差

判断：假回测比低收益更危险。

35 个滚动窗口，而非简单 split

单段测试集只代表「某一市场阶段」；采用 252 天训练 + 21 天测试 × 35 窗口。

• 得到分布：准确率均值 49.2% ± 12.3%，非单点数字
• 阶段不稳定 → 直接定义 V2「模型漂移监测」

汇报「55.4%」须附带「滚动 σ=12.3%」作风险提示。

LLM 情绪：识别市场状态，而非提精度

2026 独立测试：加情绪后准确率 53.8%（略低于纯技术）——不等于放弃。

常规思路

精度没涨 → 特征无用 → 砍掉。

PM 思路

情绪做市场状态分类，高/低/平稳期切换不同子模型（V2）。

判断：特征价值取决于放在哪个产品维度，不只看单一指标提升。

技术方案摘要

数据采集：Selenium 而非 Requests

房天下页面大量 JS 动态渲染，且有反爬（频率、UA）。Requests 拿不到动态内容且易被识别；付费接口预算为 0。

方案	优点	缺点	采用
Requests	快、省资源	无动态内容、易封	否
Selenium	真实浏览器、抗检测	慢、耗资源	是
付费接口	稳定	单次 ¥3000+	否

落地：随机 UA（9 种）+ 随机延迟（1–5s）+ 失败重试（5 次）+ 疑难页二轮处理。结果：14 区共 57,730 条，成功率 99%+，平均每区约 25 分钟。

模型选型：Random Forest 而非 XGBoost

模型	CV R²	CV MAE	R² 标准差
Random Forest	0.7506	109.63	0.0306
XGBoost	0.7474	117.40	0.0298

硬指标几乎打平（精度差 0.32%）。纯技术可互换；PM 视角 RF 胜出：

• 可解释性：特征重要性可直接写进产品文案（如「面积决定 76% 价格」），XGBoost 需额外接 SHAP。
• 下游成本：B 端会问「为什么这么估」——RF 回答路径更短。

判断：选型看「哪个最容易被产品和客户消化」，不是只看 R²。

数据清洗：保留长尾豪宅

学术思路

3σ / IQR 砍掉离群值——R² 立刻好看，但假装豪宅市场不存在。

产品思路

保留合理极端值；高端段失灵反而是分段建模 / 人工兜底的产品信号。

做法：只过滤逻辑错误（总价/单价/面积 ≤0）+ 户型样本 <5 的稀有类型。保留率 62.7%。判断：清洗目标是反映真实市场，不是让模型好看。

评估方式：5×5 重复 K 折

简单 train/test 的 R² 会随随机种子波动，单点数字不可靠。

• RepeatedKFold：5 折 × 5 次 = 25 次评估，得到均值 ± 标准差。
• 稳定性：标准差 0.0275，上线后不易「突然崩盘」。

对外汇报「R²=0.77」时，需附带「标准差 < 0.03」——单点 R² 是不负责任的。

Product

实习经历 & Vibe Coding

把 AI 做成可落地的工作流，把产品从需求做到上线。

SWITCH · 点击查看

AI工作流实习项目

AI 商品创作助手

多模态理解 + Prompt/模型优化 + AI Workflow 设计。

面向跨境电商卖家的 AI 商品内容生产工具，通过图片理解、意图识别与生成式 AI 能力，帮助商家快速生成商品图片、标题及详情描述，降低商品素材制作成本，提升商品上架效率。

FLOW

工作流 · AI 商品内容生产

用户输入商品图片及需求描述后，系统通过多个 AI 节点协同完成内容生成：

01用户输入

商品图片 / 文字需求

↓

商品图片文字需求

02意图识别

理解用户生成目标，识别图片类型与生成需求

↓

图片类型生成需求

03图片理解

分析商品结构、特征及视觉信息

↓

主体提取视觉信息

04Prompt 生成

根据商品信息生成适用于不同场景的图像生成指令

↓

自动生成 Prompt

05多类型内容生成

按场景输出不同类型商品展示图

↓

场景图卖点图特写图白底图

06商品创建

自动生成商品上架所需内容

↓

商品标题详情描述图片素材

展开完整案例 · 背景 / 迭代 / 能力

BACKGROUND

项目背景

跨境电商卖家在商品上架过程中，需要投入大量时间制作商品图片、撰写商品信息。对于产业带及白牌商家而言，缺乏专业设计能力导致素材生产效率低、质量不稳定。

本项目通过引入 AI 能力，将商品图片制作与商品创建流程自动化，让卖家从“人工制作素材”转变为“AI 辅助生成与优化”。

ITERATE

产品迭代

V1：搭建 AI 商品内容生成能力完成 AI 生图与 AI 创建商品核心链路设计：上传商品图生成营销素材意图识别 → 图片理解 → Prompt → 出图场景图 / 卖点图 / 特写图

V2：优化 AI 生成体验与稳定性围绕用户实际使用场景进行 Workflow 优化：历史对话连续创作提高生成匹配度一次生成多类型套图多语言生成 Bad Case 反馈优化

CAPABILITY

AI能力建设

多模态理解

结合商品图片与文本需求，理解商品信息并生成符合业务场景的内容。

Prompt 生成与优化

通过自动生成 Prompt 降低用户表达成本，提高生成结果稳定性。

AI Workflow 设计

将复杂生成任务拆解为多个 AI 节点，实现从输入理解到内容输出的完整链路。

模型效果优化

通过结果反馈、异常处理及案例沉淀，持续优化 AI 输出质量。

AI工作流实习项目

AI 剧本创作平台

模型评估与选择 + Prompt 体系设计 + AI 质量评估机制。

针对剧本团队内容生产效率低、创作流程复杂的问题，设计 AI 辅助创作平台，通过大语言模型能力重构从创意生成、剧本编写到内容审核的完整生产流程。

FLOW

工作流 · 剧本链路梳理

01创意种子

基于 LLM + 提示词生成创意种子

↓

抓取热点创意自动生成创意 + 标签

02剧本生成

基于 LLM + 提示词生成剧本内容，包括物料、NPC、剧情等

↓

剧本内容生成核心角色构建

03图片素材生成

基于 SD + LoRA 生成剧本相关素材配图

↓

人物角色背景图、封面图等

04审核评估

对 AI 产出的内容做整体评估，剧本分发

↓

构建评估体系机器 + 人工评估审核分发（发布）

05剧本输出

剧本团队获取剧本

↓

导出完整剧本人员权限控制

展开完整案例 · 背景 / 能力 / 价值

BACKGROUND

项目背景

传统剧本生产流程涉及多个环节，依赖人工完成，生产周期长且难以保证内容一致性：

创意构思故事框架人物设定剧情编写素材制作质量审核

本项目探索 AI 在内容生产场景中的应用，通过构建结构化 AI 工作流，提高剧本创作效率，同时保持内容质量与一致性。

BUILD

AI 能力建设

模型评估与选择针对剧本生成任务对比多个大模型，从内容质量、指令遵循能力及 Prompt 适配度选定业务方案。

Prompt 体系设计将创作拆为结构化任务，规范各模块输入输出：故事简介生成角色设定生成剧情章节生成内容标签生成视觉素材标签生成

AI 质量评估机制建立测试集与 Bad Case 优化流程：业务案例与异常场景人物一致性剧情逻辑内容完整度

VALUE

产品价值

通过 AI 能力重构内容生产链路，将剧本创作从单点 AI 生成转变为完整的智能生产流程。实现：

降低内容创作成本

提升剧本生产效率

提高多轮生成一致性

支持规模化内容生产

独立 C 端可体验

今天吃什么

2 天从 0 到 1 上线 · 解决「吃什么」这个高频低价值决策。

Vercel 预览

微信扫码即用

一款帮助用户解决日常饮食选择困难的微信小程序，通过用户偏好收集、场景化推荐与随机决策机制，降低「吃什么」的决策成本。

FLOW

产品设计 · 用户决策路径

用户进入

打开小程序，开始一次饮食决策。

偏好收集

饮食偏好 · 忌口信息 · 用餐场景

智能匹配

符合偏好 · 场景推荐 · 随机探索

结果反馈

按结果调整偏好，优化后续体验。

展开完整案例 · 背景 / 功能 / 实践

BACKGROUND

产品背景

日常饮食选择存在高频、低价值但持续消耗精力的问题。用户往往面临：

不知道吃什么

想吃什么缺少灵感

决策反复消耗时间

本产品通过轻量化交互，将用户需求转化为个性化推荐结果，帮助用户快速完成饮食决策。

FEATURE

产品功能

个性化推荐结合用户偏好信息，减少无效选择，提高推荐匹配度。

场景化决策针对不同使用场景提供差异化推荐：日常用餐快速选择随机探索

快速产品验证通过低成本开发方式快速完成方案设计、页面交互、核心功能与体验验证，跑通从需求提出到产品落地的完整流程。

PRACTICE

产品实践

围绕「降低饮食决策成本」完成一次独立 C 端产品实践，从用户问题、核心路径到 MVP 验证形成完整闭环。

·问题定义：从“缺少美食信息”进一步定位为选择过多 + 多重约束下的决策疲劳，将产品目标从“提供更多推荐”转向“帮助用户更快做决定”。
·体验取舍：针对不同决策状态设计两条路径：有明确需求时提供 Top 6 个性化推荐；不想思考时直接一键决策，减少无效浏览与重复操作。
·推荐机制：区分用户约束强弱：过敏 / 排斥做硬过滤，健康 / 心情做软排序，并设置结果不足时的降级兜底，平衡推荐相关性与结果可用性。
·MVP 验证：聚焦偏好、推荐、决策三个核心环节，暂缓社区等非核心功能；以推荐接受率、重选率、决策时长、决策完成率作为后续验证指标。

独立完成需求分析、PRD、交互设计、AI 协作开发、测试与上线。

📄 PRD · 今天吃什么

POSITION

一句话定位

「今天吃什么」是一款帮助用户降低日常饮食决策成本的轻量化 C 端决策产品。

通过偏好理解、有限推荐与一键决策，在保证结果可接受的前提下，减少用户搜索、比较和反复纠结。

PROBLEM

核心问题

用户缺少的并不是更多关于「吃什么」的信息。

菜谱平台、外卖平台、点评平台已经提供了大量内容，但当用户真正面对一顿饭时，仍然需要在：

口味 × 健康 × 忌口 × 心情 × 场景

等多个条件之间不断搜索、比较和排除。

因此本产品解决的并非

帮用户发现更多食物。

而是

帮助用户用更低的认知成本，完成一次“足够满意、可以立即行动”的饮食决策。

项目背景

1.1 问题来源

日常生活中，我持续观察到一种高频但容易被忽略的决策消耗：

·家庭做饭前反复讨论“今晚吃什么”
·上班族午休时间不断切换外卖平台，最后仍选择熟悉的食物
·有健康、减脂或忌口需求的人，需要在大量菜品中逐个排除
·用户面对大量推荐时，反而更容易陷入持续比较

这些行为共同指向同一个问题：

信息丰富并不意味着决策容易。

用户真正承受的是：

选择过多多重约束重复比较

带来的决策疲劳。

用户研究

2.1 研究目标

本次轻量研究主要验证三个问题：

1用户在「今天吃什么」过程中真正困难的环节是什么？
2用户需要更多选择，还是需要更少、更合适的选择？
3什么情况下用户愿意直接把决策交给系统？

2.2 研究方式

受个人项目资源限制，本阶段采用轻量级定性研究：

·二手研究：阅读菜谱、外卖及美食产品相关用户评价约 50 条
·生活观察：观察家人、朋友、室友的实际饮食决策行为
·用户访谈：与 5 位不同生活状态用户进行 15–30 分钟非正式访谈

研究边界

当前结论用于支持 MVP 假设形成，而非代表大样本用户结论。

如果进入真实商业验证阶段，应进一步通过：定性访谈 → 定量问卷 → 行为数据持续验证。

核心用户洞察

3.1 洞察一：用户缺的不是选择，而是结束选择

常见产品逻辑是：给用户更多菜品。但在饮食决策场景中，更多候选往往意味着更多比较。

应从

增加供给

转向

缩短决策

设计原则：少而有效 > 多而丰富

3.2 洞察二：用户条件存在不同优先级

用户输入的条件并不具有相同权重。例如“花生过敏”与“今天比较想吃辣”不能使用相同的筛选方式。

硬约束

不可违反 · 花生过敏

软偏好

可以权衡 · 今天比较想吃辣

因此推荐系统需要区分：什么绝对不能出现，什么只是更希望出现。

3.3 洞察三：不同用户并不总想“挑”

用户存在两种明显不同的决策意愿：

状态 A

我愿意选，但不要让我选太多

有限候选推荐

状态 B

我已经不想思考了

系统直接替我决定

因此产品不能只提供一条推荐路径。

3.4 洞察四：推荐的价值不在于绝对精准

在低风险、高频的饮食决策场景中，用户并不需要理论上的“最优解”。

相比绝对准确，更重要的是：结果安全、符合基本偏好，并且让我愿意马上做决定。

MVP 优先追求：可接受性 > 绝对精准度

目标用户

本产品不以职业、年龄作为主要用户划分，而根据用户进入产品时的决策状态进行设计。

用户状态	典型表达	核心需求	产品任务
无明确想法	“完全不知道吃什么”	缩小范围	提供有限候选
有模糊偏好	“今天想吃清淡一点”	找到符合状态的结果	个性化推荐
有明确限制	“不能吃花生 / 今天不吃辣”	避免不可接受结果	条件过滤
不想继续思考	“随便，帮我选一个”	直接结束决策	一键决策

Jobs To Be Done

用户真正雇佣这个产品完成的不是

“帮我浏览美食。”

而是

当我需要决定一顿饭、但不想投入太多时间思考时，帮我快速得到一个符合基本需求、可以直接接受的选择。

核心 Job

·Functional Job：快速决定吃什么。
·Emotional Job：减少纠结和反复比较带来的心理消耗。
·Supporting Job：在存在健康、忌口等限制时，避免明显不适合的选择。

产品定位

6.1 定位

轻量化饮食决策工具

不是：

菜谱大全外卖平台餐厅点评平台健康管理 App

而是：帮助用户完成“吃什么”决策的最后一公里。

6.2 核心价值主张

更少输入

长期偏好建立后持续复用。

更少选择

不通过无限内容流增加决策成本。

更快决定

既可以自己从有限结果中挑，也可以直接让系统替用户选择。

产品目标

7.1 用户目标

帮助用户：更快完成一次满意的饮食决策。

7.2 MVP 产品目标

首版重点验证三个核心假设。

H1｜偏好复用假设

用户愿意在首次使用时提供少量偏好，以换取后续更低的操作成本。

H2｜有限推荐假设

有限、高相关性的候选结果，比大量内容更容易帮助用户完成选择。

H3｜决策代理假设

在部分场景下，用户愿意让产品直接替自己完成选择。

7.3 非目标

MVP 阶段暂不追求：

内容丰富度最大化社区活跃度用户停留时长完整饮食健康管理复杂 AI 能力展示

产品成功标准不是

用户在这里待了多久。

而是

用户多快离开产品去吃饭。

产品设计原则

8.1 低决策成本 > 信息丰富度

任何新增信息都需要回答：它是否真的帮助用户更快决定？

8.2 约束优先 > 兴趣偏好

安全、过敏、明确排斥等条件必须优先于推荐准确度。

8.3 可接受 > 理论最优

低风险高频决策中，一个“足够不错”的答案比长时间寻找“最好答案”更有价值。

8.4 用完即走 > 用户停留

不通过以下方式人为延长用户使用时长：

无限下拉排行榜红点提醒高频消息推送

8.5 AI 在后台 > AI 在前台

用户不需要感知模型本身。AI / 算法只有在能够减少操作成本 / 提高推荐质量 / 提升效率时才有使用价值。

信息架构

今天吃什么

├── 首页
│   ├── 今日问候
│   ├── 快速决策入口
│   └── 个性化推荐入口
│
├── 偏好设置
│   ├── 饮食偏好
│   ├── 健康倾向
│   ├── 过敏 / 忌口
│   └── 当前状态
│
├── 推荐结果
│   ├── Top 6 推荐
│   ├── 推荐理由
│   └── 调整偏好
│
├── 帮我决定
│   ├── 单结果推荐
│   ├── 接受结果
│   └── 再来一个
│
└── 我的
    └── 偏好管理

核心用户路径

10.1 新用户路径

打开小程序

↓

了解产品价值

↓

填写轻量偏好

↓

生成基础偏好画像

↓

进入推荐

↓

Top 6 推荐结果

↓

选择结果 / 帮我决定

↓

完成决策

设计目的：新用户允许承担一次较高的信息输入成本，用于降低之后每次使用的重复操作。

核心原则：首次多了解一点，以后少操作一点。

10.2 老用户路径

打开小程序

↓

读取已有偏好

↓

直接进入推荐 / 帮我决定

↓

获得结果

↓

接受 / 重选

目标：尽量减少重复输入。

功能需求

F1｜用户偏好

通过少量结构化信息建立用户基础画像，为后续推荐提供条件。

长期偏好

可持续复用

口味偏好饮食习惯健康倾向过敏信息长期忌口

即时状态

主要影响当前决策

当前心情今天想吃今天不想吃当前场景

设计原则：避免一次要求用户填写过多信息。首轮只获取足够影响推荐结果的信息，其他偏好可在后续使用过程中逐步补充。

F2｜个性化推荐

从候选池中输出符合当前用户状态的有限结果。默认返回 Top 6，而不是无限列表。

产品解决的本身就是选择过多，因此推荐系统不应该重新制造一个新的信息流。Top 6 需要同时保证：一定选择空间、一定推荐多样性、不产生明显比较压力。

推荐卡片信息

菜品名称核心标签简短推荐理由是否符合当前关键偏好

避免出现大量非决策必要信息。

F3｜帮我决定吧

服务已经没有继续比较意愿的用户。系统从当前可接受候选池中直接返回一个结果。用户只需要判断「可以 / 不可以」，而不是继续判断「哪个最好？」

首次结果：今天就吃这个 → 用户操作：就它了 / 再来一个。

将复杂的

多选一问题

降维成

是 / 否问题

进一步减少决策成本。

F4｜偏好调整

用户可从结果页快速调整：当前想吃、当前不想吃、忌口、偏好。修改后立即重新计算推荐。

场景	处理方式
无偏好数据	使用基础推荐池
用户条件冲突	提示冲突条件并允许快速修改
硬过滤后为空	保留安全约束，提示用户放宽条件
软匹配结果不足	自动进入降级策略
连续重选	降低近期已出现候选权重
相似菜品过多	引入结果去重与多样性机制

MVP 范围

14.1 P0｜必须实现

用户基础偏好过敏 / 忌口当前状态菜品结构化标签硬过滤软排序 Top 6 推荐帮我决定再选一次推荐结果兜底

14.2 P1｜后续优化

用户行为反馈推荐权重动态调整推荐多样性历史选择更丰富场景识别

14.3 暂不进入 MVP

美食社区社交关系点赞排名完整菜谱内容体系 AI 头像生成完整健康管理系统复杂机器学习推荐系统

功能取舍标准

每个新增能力都必须回答：它是否能够直接降低用户完成一次饮食决策的成本？如果不能，则不属于当前 MVP 核心范围。

数据指标

15.1 北极星指标

有效决策完成率

定义：进入推荐流程后，最终接受某个推荐结果完成决策的用户比例。

完成决策用户数／进入决策流程用户数

为什么不是 DAU？本产品不是内容消费型产品。使用频率和使用时长都不应该成为核心价值判断标准。真正应该验证的是：用户来了以后，有没有更快解决“今天吃什么”。

15.2 核心指标

指标	定义	验证内容
偏好填写完成率	完成首次偏好的用户比例	首次使用成本
推荐点击率	查看推荐后选择某结果比例	推荐相关性
首次推荐接受率	不重选直接接受结果比例	推荐质量
重选率	点击“再来一个”的比例	首次结果满意度
决策完成率	最终确认选择比例	核心产品价值
平均决策时长	进入到确认所需时间	是否降低决策成本
偏好修改率	推荐后重新调整条件比例	用户画像准确性

15.3 重点漏斗

进入小程序

↓

进入决策

↓

完成偏好 / 使用已有偏好

↓

查看推荐

↓

接受结果

↓

完成决策

首版重点观察：推荐 → 接受以及推荐 → 重选 → 接受两条路径。

行为埋点设计

MVP 如果进入真实用户验证阶段，建议记录以下关键行为：

Event	说明
decision_start	开始一次饮食决策
preference_submit	提交偏好
recommendation_view	查看推荐
recommendation_accept	接受推荐
recommendation_retry	请求重新推荐
preference_change	修改偏好
decision_complete	完成决策

后续可以通过行为数据判断：用户说自己喜欢什么，和用户实际选择什么之间是否存在差异。

后续推荐迭代方向

V1.1｜建立反馈闭环

记录接受、重选、排斥、偏好修改，逐步修正用户偏好。

V1.2｜提升推荐多样性

解决连续推荐内容过于相似的问题。例如近期连续出现：番茄炒蛋 → 番茄牛肉 → 番茄意面。即使单项得分较高，也可能造成用户感知上的重复。因此增加新鲜度 / 去重因子。

V1.3｜行为学习

当行为数据积累后，将用户填写的显性偏好与用户实际选择的隐性偏好结合。例如用户填写不在意辣度，但过去十次选择中八次选择辣味菜品，系统可以逐步提高对应偏好权重。

I'm Elara 郭筱婷 an AI Product Manager Trainee

Welcome to

Elara的世界！

人格切片 · 在 INTJ 和 ENTJ 之间反复横跳

工作日

周末

假期

NOW · 此刻状态

地球Online · 职业探索全记录

深圳店小秘网络科技有限公司

百度

澳门大学

百丽集团

赛文思营销咨询

兴业证券

广西国际博览事务局

广西民族大学

不务正业 · 但快乐

旅行地图解锁计划

游戏成就墙

基金小白历险记

我的 Project 能力延伸

全球航空市场进入策略分析

A股机器学习择时系统

杭州房产智能估值

中国汽车市场分析

数字化时代背景下的市场营销策略创新研究

Product

工作流 · AI 商品内容生产

项目背景

产品迭代

AI能力建设

工作流 · 剧本链路梳理

项目背景

AI 能力建设

产品价值

产品设计 · 用户决策路径

产品背景

产品功能

产品实践

I'm Elara 郭筱婷
an AI Product Manager Trainee