🤖 AI 消费决策 Agent · 独立设计 / 开发 / 评测 / 上线

七选

几轮对话,说清你的宝宝;匹配知识图谱,给出最适合的奶粉与理由

微信小程序(审核中) · H5 版即时体验 · 管理后台

体验产品 → 看产品架构
869
天猫 SKU 采集
323
可推荐 SKU · 14 品牌
90
自建评测基线分
28/29
评测零 badcase
2.1 万
行代码 · 全栈自研
双端
小程序 + 管理后台
WHY THIS PRODUCT
AI 时代,toC 让每个人成为超级个体;
对品牌方,则是建立品牌的 「认知体」——
让 AI 看见它,并链接到合适的用户。

这个产品是两层价值的实验:一次 GEO 的完整实践,一次 Product Builder 的自我证明。

🌐

立意一:GEO 不该是「骗 AI」

GEO 的误区:把品牌包装成 AI 眼中的「万能答案」——对任何用户都说自己好。 但 AI 会识破过度的自我吹嘘,也会忽略没有结构化的真实价值。

正确的姿势:客观地让 AI 看见和了解品牌——它的配方、它的段位、它适合什么样的宝宝—— 然后链接到最适合它的人。

七选就是实验场:把 869 个 SKU 变成结构化、可信、可匹配的「品牌认知体」, 亲手验证供给如何被 AI 检索、评估、链接的完整机制。

产品链路即实验:品牌认知体 → AI 看见 → 匹配 → 链接
🔨

立意二:一个人成为 Product Builder

一份 Vibe Coding 作品:借助 AI 的能力,独立跑完 需求洞察 → 产品设计 → 开发上线 → 评测体系 的完整闭环。

不是「用 AI 生成一个 demo」——而是用工程方法做出一个 有评测背书、经得起真机验收、通过合规审核 的真实产品。

完整闭环:需求 → 设计 → 开发 → 上线 → 评测 → 迭代
PRODUCT PORTS

双端产品形态

面向消费者的微信小程序(审核中,H5 版可即时体验)+ 内部管理后台,共用同一套后端与知识图谱。

📱 C 端:微信小程序「七选」提审 1.0.0

宝爸宝妈的对话式养育助手:聊天匹配奶粉、生长曲线工具、多宝宝档案管理、画像面板。

对话式匹配 生长曲线 多宝宝档案 画像面板 商品详情 + 官方店
打开 C 端体验(H5 版)

🛠 O 端:内部管理后台

产品运营控制台:商品知识图谱可视化、用户画像审计、匹配过程追踪、评测报告实时查看。

商品图谱管理 画像升级审计 匹配追踪 评测报告
打开管理后台
CORE ARCHITECTURE

三层产品结构

上层画像提取、底层供给图谱、中间层匹配与链接。两端各自结构化,中间层完成链接——每层独立可迭代、可评测。

1

用户层 · 画像提取

需求不填表——在对话中,用户无感地完成自我描述
  • 对话式并行提取:用户聊天的同时,LLM 从自然语言中抽取 7 个关键字段(月龄/性别/体质/预算/喂养方式/转奶原因/价值观),并约束"只提取用户说过的信息,不推测"
  • 三层画像:L1 关键字段 → L2 辅助字段 → L3 场景标签;4 类场景路由(新手选奶 / 转奶 / 混合喂养 / 特殊体质)决定对话策略
  • 会话维度归一:一台设备多宝宝档案(X-Device-Id 识别设备 → X-User-Id 跟随当前宝宝),二宝家庭每个宝宝独立画像、独立上下文
设计思考:把"填表"变成"聊天",画像提取是与推荐并行的后台任务——用户无感,画像渐全。
界面示意图 · 聊天页
七选 · 养育助手👶 安安 ▾
我家宝宝 3 个半月,男宝,一直喝母乳,最近奶不太够想加点奶粉
收到~宝宝 3.5 个月混合喂养转奶,我会帮你匹配适合的 1 段奶粉 🍼
✓ 月龄 3.5 月 ✓ 性别 男 ✓ 混合喂养 ✓ 场景:母乳不足转奶
↓用户画像 JSON(结构化的需求)
3

匹配层 · 匹配与链接

中间层只做一件事:把正确的供给,链接到具体的需求
  • 硬规则过滤(确定性):月龄 → 段位映射、预算过滤、过敏体质不推商品转就医建议——绝不翻车的底线
  • 模型打分(理解性):top-8 候选送入 LLM,综合体质匹配度 / 配方适合度 / 口碑 / 价格打分排序 → Top 3 + 可解释理由
  • 可追溯的匹配:每一条推荐都能追溯到"用户画像的哪个字段" × "图谱的哪个属性"
设计思考:推荐是"把热门推给所有人"——流量分发;匹配是"把正确的供给链接到具体的需求"——价值创造。这才是决策 Agent 存在的理由。
界面示意图 · 推荐卡
1A2 · 至初 1段93 分
2惠氏 · 启赋未来89 分
3A2 · 紫白金80 分
💡 为什么选它:A2 蛋白对转奶期消化友好 + OPO 应对吸收效率 + 预算 350 内 ✓
↑候选 SKU 池(结构化的供给)
2

供给层 · 供给图谱

LLM 再强,也推荐不了它没见过的产品
  • 电商数据采集:淘宝开放平台 API 批量采集天猫奶粉——869 个 SKU 入库,品牌归一化(14 品牌 / 45 核心系列)、体质标签提取,收敛为 323 个可推荐 SKU
  • 双层知识图谱:产品维度(品牌 → 系列 → SKU:段位/奶源地/核心配方/价格/官方店链接)+ 成分维度(OPO/乳铁蛋白/DHA/益生元/MCT → 体质需求),Graph RAG 检索
  • 数据可信度分层:字段标注来源与可信度,低可信度数据不参与决策排序——防止脏数据污染推荐
设计思考:图谱的质量决定 Agent 的上限——早产儿 badcase 的真实根因就是候选层把含 MCT 的产品挤出了池子。
界面示意图 · 知识图谱
品牌:A2
▼ 属于
系列:至初
▼ 包含
SKU:至初 1段 900g
段位 1 段 奶源 新西兰 A2 蛋白 ¥298
↔ 成分图谱(体质关联)
A2蛋白 → 消化友好 OPO → 吸收效率 乳铁蛋白 → 免疫力
💡 产品初衷:构建 AI 时代的品牌认知体——在生成式引擎主导消费决策的时代,帮品牌以结构化的方式"让 AI 看到它",并链接到合适的用户。
HORIZONTAL EVAL SYSTEM

横向评测体系:能跑 ≠ 可靠

对 LLM 产品而言,没有评测的迭代是盲飞。七选自建 4 链 + E2E 对话式评测——一次命令自动跑分、自动出报告,让每一次改动都有数据背书,让优化有明确的方向。

🔗 4 链 + E2E 分层评测设计

按产品链路拆解评测,问题定位到具体环节而非"整体不好":

链1 · 会话理解 ×20%
83
链2 · 画像提取 ×15%
96
链3 · 图谱构建 ×25%
100
链4 · 匹配推荐 ×40%
80
E2E · 全链路追问
64

29-30 道评测题模拟真实用户与 Agent 完整对话,LLM-as-Judge 按维度打分。每轮约 16 分钟自动跑完,产出报告 + badcase 清单 + 修复建议。

🖥 评测报告页(O 端)

界面示意图 · 管理后台「评测报告」模块

📊 评测报告 · 2026-09-19 · deepseek-v4-pro
总分 88 · 通过 25/30
88
链1 会话理解
83
链4 匹配推荐
80
badcase Q4-5 早产儿场景:MCT 配方未进入候选 → 推荐普通配方
✅ 修复后复测:Q4-5 得分 3 → 4,两轮验证 91 / 88

🐛 一个 Badcase 的完整修复故事

早产儿选奶 · 链4 得分 3/5

现象:早产宝宝需要高能量配方(含 MCT),推荐却全是普通配方。
根因:不在 LLM——在候选层。top-8 截断按数据可信度排序,把仅有的 3 个含 MCT 产品挤出候选池,LLM 根本没机会看到它们。
修复:早产画像将 MCT 配方保送进 top-8;提示词量化能量需求(80 vs 67-70 kcal/100ml);画像文本携带出生体重。

评测的价值不只是打分——它让"推荐不好"从一句笼统的抱怨,变成可定位、可修复、可复测的具体问题。

📈 五轮评测进化:79 → 90 → 88

同一套评测集自动重跑,每次改动都有分数对照——这就是"自动跑、打分、优化"的完整闭环。

798-19 798-27 909-7 909-12 889-19
USER-SIDE TOOL

生长曲线:用户侧的附加工具

与推荐引擎解耦、但共用画像体系的养育工具。放弃第三方图表库,从零移植 WHO 官方标准与 SVG 坐标算法。

📐 WHO 官方标准

解析 WHO 官方 CDN 数据表,19 个锚点(0-24 月身长表 + 30/36 月身高表)经锚点校验生成标准曲线,不是拍脑袋的"经验值"。

🧮 LMS 评估管线

身高/体重共用 LMS 参数化管线:月龄 + 测量值 → 百分位计算 → 评估快照(正常/偏瘦/超重…)。每次录入自动入库、三元组去重、生成带时间戳的成长记录。

💬 对话流深度集成

聊天中随口说"身高 62cm"即自动检测 → 新值校验(40-120cm 范围)→ 写记录 → 生成曲线卡。趋势解读双通道:规则生成(秒回)+ LLM 润色(降级兜底)。8 个场景验收通过。

界面示意图 · 生长曲线
👶 安安 · 身高曲线 60 70 80 P15 P85 62cm · P50 0月 1月 2月 ✓ 评估:身高正常,处于同龄宝宝中等水平
ENGINEERING STORIES

复杂点与踩坑:独立全栈的真实代价

一个人做完需求到上线,最有价值的不是"做出来了",而是每个坑的「现象 → 根因 → 修复」闭环,以及沉淀下来的方法论。

全站卡死事故:一次 LLM 调用瘫痪整个服务P0 线上事故

现象:所有接口全部挂起,连轻量接口都不响应,进程连 kill 信号都处理不了。
根因:FastAPI 单进程事件循环上直接同步调用 LLM,DeepSeek 服务端挂起时整个事件循环被阻塞——"单点阻塞拖垮全局"的经典并发缺陷。
修复:所有 LLM 调用迁入线程池(to_thread)+ 客户端超时 150 秒兜底。

方法论:AI 依赖是"不可信的网络资源",任何同步调用都必须考虑挂起场景——超时 + 隔离 + 降级,三件套缺一不可。
66-98 秒的回复等待:不是网络慢,是管线设计体验瓶颈

现象:一条消息等一分多钟,微信默认 60 秒超时直接误杀正常请求。
根因:画像提取 → 推荐打分 → 生成回复,3 次串行调用全部使用推理模型(单次 20-40 秒)。
修复路径:客户端超时放宽到 180 秒保命;后续按任务分级用模型——结构化提取走秒级 Flash 模型,深度打分保留推理模型。

方法论:慢问题拆成(调用次数 × 单次时长)——次数看管线结构,时长看模型选型。对症下药,而不是笼统"优化速度"。
DeepSeek 推理模型的"空回复"陷阱模型行为坑

现象:趋势解读润色偶发返回空内容。
根因:推理模型把输出预算消耗在"思考"上,max_tokens 过小时正文产出为空;而重试逻辑只对报错生效,空内容静默通过。
修复:提升输出预算,空内容视为失败走降级通道(规则解读兜底)。

方法论:与 LLM 打交道的工程必须区分"报错"与"无效结果"两种失败——后者更隐蔽,需要显式校验 + 降级兜底。
真机 60 秒超时"无回复":三段代码副本的坑工具链坑

现象:代码修好了,手机上依然超时,构建产物里明明有修复。
根因:微信开发者工具的「编译」只更新模拟器——模拟器、真机、上传包是三个独立副本,真机必须重新扫码才会推送新代码包。
修复:重新扫码推送;沉淀"改代码 → 重建 → 重扫"的真机验收固定流程。

方法论:排查"修了没用"的问题,先确认代码版本链——本地 → 构建产物 → 设备包,每一环都可能断。
合规之路:双备案串行 + 个人主体限制合规坑

现象:域名备案被驳回"网站主办者冲突";web-view 套壳方案真机不渲染。
根因:工信部规则——同一主体不能并发两个审核中的备案,必须串行;个人主体小程序不支持 web-view 组件。
修复:小程序备案先行 → 域名备案随后(10-9 双通过);彻底改走 uni-app 原生迁移路线,功能与 H5 完全打平。

方法论:重大方案选型前先查官方硬性限制(个人主体、组件支持),跨 AI 会话交叉检查——这是 hermes 同事提醒及时止损的。
TECH STACK

技术栈:全栈自研 2.1 万行

一个人用 Vibe Coding 完成的全栈产品——从数据采集到双端 UI 到生产部署。

后端
Python + FastAPISQLitehttpx + BeautifulSoupNginx
前端
Vue 3 + Vant(H5)uni-app(小程序)Canvas 2D / SVG
AI
DeepSeek 推理模型LLM-as-Judge 评测结构化输出容错
运维
腾讯云服务器HTTPS 证书ICP 备案 ×2微信开放平台
MILESTONES

项目历程

从立项到提审的完整过程。

2026-06-26
立项:技术栈定稿,8 周计划启动
2026-07 月
供给侧构建:淘宝 API 采集 869 SKU → 品牌归一化 → 知识图谱
2026-08-19
评测体系上线:首轮自动评测 79 分,28/29 零 badcase 初现
2026-09-07
评测 90 分:画像幻觉修复 + 候选排序优化
2026-09-12
生长曲线上线:WHO 标准 + 双曲线图 + 8 场景验收(特色能力)
2026-09-13
小程序发布链路打穿 80%:注册 / 认证 / 备案提交 / 隐私指引
2026-09-17
uni-app 迁移收官:推荐卡 / 商品详情 / 画像面板,功能与 H5 打平
2026-09-28
P0 事故与修复:LLM 阻塞全站卡死 → 线程池化改造
2026-10-09
双备案通过(京ICP备2026063162号-1X / -2)→ HTTPS 全链路上线
2026-10-11
小程序提审 1.0.0 🚀