会议时间：2025年6月24日 参与人员：说话人A（主导，负责需求与架构方向）、小关（前端开发）、朱晨（API/后端开发）

一、核心议题

1. 产品推荐入口与流程重构

• 背景：原产品推荐入口废弃，统一从”重点推荐 → 新增推荐”进入。
• 新流程三步：选品 → 排版 → 生成。
• 选品：接入 AI 能力，类似当前选品逻辑：用户提需求，下面给出产品推荐。

2. UI 与会话整合方式

• 决策：选品页面只放一个简单的聊天窗口（不复用整套 chat 页面）。
• 原因：完整迁移 chat 维护成本太高，且需引入大量系统功能依赖，复杂度高。
• 该聊天窗口对应一个独立的 LangGraph workflow agent（类似宜品找客的方式），单独新建。

3. 选品阶段交互设计

• 页面初始消息不由 AI 发出，直接由前端渲染。
• 用户可点击标签 → 标签展示在下方对话框中 → 用户在输入框补充需求 → 发送。
• 真正发出去的消息是用户输入的需求那条；标签作为消息的附加属性传递。
• 简化方案：标签先不实现，直接将所选标签作为纯文本拼接在输入框中发送。

4. 推荐结果展示方式

• 之前在消息内渲染推荐卡片；新方案：直接展示到左侧推荐区。
• 例如六个产品系列，全部渲染到左侧六个系列卡片，样式以左侧为主。
• 工具调用消息仍然产生（保留聊天历史可恢复），但前端不渲染，最终在右侧只展示一句简单文本（如”已成功创建推荐”）。

5. 反馈调整与版本管理

• 用户可通过对话进一步反馈（如”删掉第一个”），再次创建新的推荐版本。
• 左侧时刻拉取右侧消息中”最后一个推荐”工具结果，渲染最新版本。
• 选用历史记录方式而非维护全局状态，便于恢复历史版本。

6. 排版需求与边界控制

• 老板需求：可替换产品图、拖拽排序、删除产品、自定义介绍页等，但需求过于复杂、原型与 UI 稿不清晰。
• 本周决策：仅实现简单版——分类顺序拖拽、系列内图片位置拖拽。
• 暂不实现：替换图片、回收站、自定义模块、像 WordPress 那样的拖拽建站、AI 排版对话等。

7. 成本与搜索优化（宜品找客）

• 当前主要成本来自 GPT-4o search（很贵），并非 O3 模型本身。
• 计划：自建搜索方案 + 通过亚马逊与 Shopify 渠道补充候选客户，降低成本并提升质量。
• 未来可试 Grok DeepSearch、Gemini 搜索 API 来降低成本。

二、技术决策与方案细节

推荐 Agent 设计

• 使用 LangGraph workflow 单独新建一个 agent，专注于推荐场景。
• 第一条消息不参与会话，只是页面渲染。
• 真正与 AI 的会话从用户的需求消息开始。
• 标签可作为 LangGraph message 的额外参数（additional_kwargs），后端在 agent 中拼接进 prompt；现阶段先用纯文本简化。

推荐展示更新策略

• 两种实现方式：
  1. 每次让 AI 修改时，结合历史聊天记录生成新版本（采用此方案，便于版本回溯）。
  2. 在对象中维护当前推荐状态，全程修改同一对象。
• 选用方案 1，左侧从消息内容中筛出最后一个”创建推荐”工具结果作为主体。

搜索与定位客户优化

• 当前问题：中文分析时，AI 倾向把中文检索到国内同行（永强、凌雅等），实际也有参考性（同行做自有品牌+外贸+独立站）。
• 英文分析则正常返回目标海外客户。
• 改进思路：
  • 调大 GPT-4o search 数量；
  • 分别从网页搜索（20）+ 亚马逊（20）+ Shopify（20）三渠道获取共 60 个候选客户。
  • 亚马逊：用前置产品搜索 → 获取卖家名称 → 对该卖家做深度分析；卖家可能没有官网。
  • Shopify：直接搜出客户后提炼域名。
• 备选方案：跑 Xai Grok DeepSearch（成本极低，约 1 毛/客户），但报告质量不如 O3；后续再批量验证。
• 必要时启用 SPA 渲染（启动浏览器渲染整页），可借助 BrightData 提供的解决方案。

任务状态管理

• 当前任务状态显示不准确，缺少 pending/running/success 等状态对应。
• 每次打开通过 thread ID 调 getState，获取后通知 API Server 更新任务状态。
• 最佳方案应是 LangGraph 端通过 webhook 通知 API Server，但当前先由前端打开时拉取后再通知 API Server。
• API 需要朱晨提供：让前端可改任务状态（原来仅后台运行时改）。

产品图优化

• 当前定位客户的产品图来源是搜索图像，结果不一定限定为目标品类。
• 优化：直接用 Google 搜图，搜索词带上具体商品词，提升相关性（暂不能用 OR 语法）。

联系方式

• 当前联系方式来自搜索阶段；后续打通”特意”系统与领英，从中拿到客户联系方式。

三、UI/交互细节

选品页面

• 顶部：固定的引导欢迎语（前端渲染）。
• 标签区：用户点击选择标签，下方对话框中以标签形式展示已选项。
• 输入框：用户在此补充自由文本需求并发送。

推荐展示

• 左侧：六个系列卡片，时刻同步右侧最新推荐版本。
• 右侧：执行过程消息提示，如”已搜索 120 个产品”应改为”已成功创建推荐”。
• 工具调用过程中产生的消息不渲染出来，仅保留在历史记录中。

排版页面（简版）

• 系列上下拖拽排序。
• 系列内单个产品左右拖拽排序。
• 不实现：替换产品图、拼接图、视图模式切换、设置属性、自定义模块、回收站、对话排版等。

报告与生成

• 生成阶段产出 PDF/网页预览。
• 任务状态标签复用现有 3 状态（待处理 / 进行中 / 已完成），完成后默认显示在”生成”标签下。
• 任务卡片下展示 PDF 或网页预览入口，与任务模块一致。

四、后续行动与分工

角色	任务
说话人A	从原推荐 agent 复制一份并做调整，作为本次新 agent 基础；写得不完整，由小关后续补完
小关	把消息渲染相关代码从老 chat 项目剥出，放入新页面
小关	调整任务状态显示逻辑，让 running 阶段也能看到分析商品阶段的数据
小关	实现简易排版（系列拖拽、系列内图片拖拽）
朱晨	提供修改任务状态的 API（前端可调）
朱晨	推荐表结构后续可清理（推荐数据全删，重构结构）；当前暂不动数据库结构，因为信息都在 message 中
朱晨	修改 API 项目的 third ID 配置（仿照之前 agent 的方式）
团队	后续删除冗余推荐相关代码与表结构，避免臃肿

五、其他要点

• 现阶段选品的标签实现可推迟，先用纯文本拼接。
• 引导提问可作为单独 agent，或作为推荐工具的额外属性内置；本周不做。
• 老板对排版有大量复杂构思（自定义模块、回收站、可视化建站、SKU 拼接图算法等），但 UI 稿不清晰且需求不成熟，本周一律不做。
• 自定义模块若真要做，更倾向”AI 直接生成 HTML 片段”的轻量方案，而非搭建可视化编辑器。
• 排版页面预览生成可能信息过多无法容纳，需后续与老板再沟通。
• O3 模型并不贵，真正贵的是 4o-search；4o-mini 和 4o 价差很大，但生成质量也下降。
• 后端 agent 拷贝时，说话人A 只写一个粗版，由小关迭代补完。
• 之后会清理推荐相关旧代码与冗余字段，“该删的就删，避免臃肿”。