定位与双端边界

1. 为什么要拆成 C / B

「智能助手」四个字容易糊成一个产品。实际上：

维度	C 端出行助手	B 端运营助手
用户	App 登录用户	运营 / 管理员 / 你自己
入口	App 对话页、发现页入口、未来可挂 IM	Web Admin 对话页或任务中心
典型问法	「新疆赛里木湖附近、7 天内、2000 以内的活动」	「分析五一活动转化，重点看退款异常」
成功长什么样	卡片 + 深链 +（可选）下单	指标表 + 结论 + 报告落库
写操作	低风险可引导到原生页面完成（报名/支付）	高风险必须 Human-in-the-loop
数据依赖	活动检索、详情链接即可起步	订单/退款/埋点/画像有量才「像回事」
习惯变化	从筛选项 → 自然语言表达意图	从多页报表 → 对话委派复盘

原则：共享底座，分端产品，分端评测。

2. 你观察过的好形态（对标）

这些都不是「闲聊 GPT」，而是 约束意图 → 系统实体 → 可点击动作：

医院挂号：说症状 → 推荐科室/医生 → 点进挂号页
营养餐点餐：说「7 天营养餐」→ 列出系统内真实餐品 → 合计金额 → 支付 → 后续按日程履约

TourMate C 端应对齐这条链路：

自然语言意图
  → 结构化筛选条件（目的地/时间/预算/人数…）
  → 调用现有活动查询能力（不是模型编活动）
  → 返回卡片（标题、价格、时间、封面）+ deep link
  → 用户点进原生活动详情（报名/支付仍走原流程）

B 端则对齐 WorkBuddy / 运营数字员工：

对话任务
  → 固定工作流 + Tool
  → Java 算指标
  → 模型解释与写报告
  → 确认后保存

3. 价值与负担（双端共用认知）

提高了什么

降低「找得到」的门槛（C）与「复盘成本」（B）
把业务能力产品化成 Tool（描述、权限、审计）——对主系统也是好事
个人能力：Java 业务工程 → AI 应用工程（结构化输出 / RAG / Tool / 治理）

新增负担

负担	说明
Token / 调用成本	要配额、缓存、闲聊限流
不确定性	需要评测集，不能只靠手感
信任	禁止虚构活动/医生/餐品；无结果要诚实说
知识与口径运维	RAG 与指标口径会过期
预期管理	用户当万能助理时会失望——边界要写进产品文案

习惯会不会变

C 端：只有「对话检索 + 深链」足够稳、足够快时，才会从筛选器迁一部分流量过来；复杂报名/支付仍应留在原生页。
B 端：适合长任务（周报、异常分析）；单次查一个订单，表格往往更快。

4. 「功能做完很空虚」和 AI 的关系

AI 能很好解决：能力跃迁叙事、学习热情、后台提效
AI 不一定立刻解决：冷启动、内容供给、真实用户反馈闭环

推荐系统 / 画像 / IM 仍是内容平台主线；助手是放大器，不是替代品。
用户量没起来时：C 端 MVP 可做「可演示的闭环」；B 端更偏作品集与自用。

5. 明确不做（第一年默认）

不做「一个入口通吃客服 + 推荐 + 行程 + 财务 + 运营」的万能 Agent
不让模型直接生成 SQL 打生产库
不让 Agent 以超级管理员身份调接口
不为 Multi-Agent 而 Multi-Agent
微调不进主线（Prompt / RAG / Tool / Workflow 解决不了再评估）