文档版本：v0.2
状态：产品基线草案
最后更新：2026-07-29
适用阶段：产品验证至 MVP
本文档定义 FunPlay（趣玩）第一阶段的产品定位、目标用户、核心场景、功能范围、验收标准和度量方式。它用于统一产品、设计、研发、运营和测试的理解，不替代交互稿、接口文档和测试用例。
一人公司执行阶段的范围裁剪、四周节奏和原型策略见 OPC MVP 与原型执行指南。
- 产品英文名称为 FunPlay，中文名称为 趣玩。
- 产品方向是面向本地休闲与短途出行场景的“去哪玩 Agent”。
- 产品首先解决“感觉无聊、想出去，但不知道去哪、懒得做攻略”的决策问题。
- 产品体验参考“对话式理解需求 + 自动调用工具 + 生成可执行方案”，而不是传统关键词搜索。
- 第一阶段客户端以微信小程序为主，同时保留网页、分享页和运营后台能力。
- 后端可以采用 Python，事务、并发控制和异步任务由数据库及基础设施保证。
以下内容尚未经过真实用户和商业验证，暂作为 MVP 假设：
- 首批用户以中国大陆城市中的年轻人、情侣、朋友、亲子家庭和独处用户为主。
- 首版优先解决“现在或周末去哪玩、和谁玩、怎么玩、是否值得出发”，暂不直接承接支付、出票和酒店库存交易。
- 核心场景以半天、一天和周末短途活动为主，多日旅行规划作为后续扩展能力。
- 首版覆盖少量重点城市，以数据质量和方案可用性优先于城市数量。
- 地图、天气、路线、POI、展览演出与活动等能力通过合规的第三方数据源接入。
任何会显著改变 MVP 范围的假设，应先完成用户访谈或小规模验证，再修改本文档。
FunPlay（趣玩）是一个替用户决定“去哪玩”，并把决定直接变成可执行方案的 AI Agent。
现代人的休闲选择看似很多，实际经常陷入“无聊但不想研究”的状态。用户不一定有明确目的地，甚至不知道自己想玩什么，却需要在内容平台、地图、票务和点评应用之间反复切换，并自行完成以下工作：
- 从“想出去但没想法”中确定一个方向；
- 在大量相似内容中筛掉太远、太贵、已去过或不合适的选项；
- 兼顾当前时间、位置、天气、预算、同行人、精力和心情；
- 判断一个选择是否值得为它换衣服、出门和花费时间；
- 把地点、路线、吃饭和预约信息组成可以立即执行的安排；
- 在意见不一致、下雨、闭店或临时犯懒时快速换一个方案。
传统搜索和内容平台继续把选择留给用户。FunPlay 的价值是主动收敛选项，在用户授权的决策强度内替用户做选择，并给出经过约束检查、可解释、可修改的行动方案。
FunPlay 不是另一个 POI 搜索框，也不是只会生成长篇攻略的聊天机器人。它的核心产物不是“更多推荐”，而是：
- 一个最值得执行的主方案；
- 最多两个有明显差异的备选方案；
- 清楚说明“为什么适合你、现在能不能去、下一步做什么”；
- 用户接受后可直接导航、预约、分享或加入日程。
- 降低决策门槛：用户无需先想好目的地，只需表达当下状态。
- 少而明确：默认给一个主选择，而不是把几十个地点重新丢给用户。
- 现在可执行：综合时间、位置、天气、营业状态、预算和同行关系。
- 替我决定但不越界：用户可以选择“直接帮我定”“给我三个选择”或“只给灵感”。
- 越用越新鲜：在用户授权下理解偏好，同时避免反复推荐同一种玩法。
- 随时能反悔：一句“不想走太远”即可局部换方案，不必重新做攻略。
- 先帮用户做决定：信息用于收敛选择，不用长篇内容增加认知负担。
- 先可执行，再好看：不推荐来不及、已闭店、明显超预算或通勤不合理的方案。
- 默认一个主方案：除非用户要求比较，否则不提供同质化的长列表。
- 追问越少越好：能从位置、时间、历史偏好和常识推断的内容不反复询问；关键假设必须可见、可改。
- 事实与建议分开：营业时间、天气等事实说明来源和更新时间；主观推荐说明判断依据。
- 关键决策由用户确认：付费、预约、删除方案、共享隐私信息等操作不得静默执行。
- 不确定就说明：无法确认的信息不得由模型补全成事实。
- 修改成本要低：用户说“太远了”或“今天不想逛展”时，只替换受影响部分。
- 避免兴趣茧房：在偏好匹配和适度探索之间保持平衡，并允许用户调节“熟悉/新鲜”程度。
- 工具失败可恢复：第三方服务失败时给出降级结果和重试入口。
| 用户类型 | 典型特征 | 核心任务 |
|---|---|---|
| 无聊但没想法的用户 | 想出门，缺少目标，不愿浏览大量攻略 | 用最低输入成本得到一个值得出发的选择 |
| 周末临时决策用户 | 只有半天或一天，受时间、天气和距离影响 | 快速获得今天或周末可执行的活动组合 |
| 约会/朋友组织者 | 怕踩雷，需要兼顾多人喜好和预算 | 直接得到适合关系场景、方便分享的方案 |
| 亲子家庭 | 时间碎片化，对年龄、交通和设施有硬限制 | 找到省心、安全、节奏合适的活动 |
| 城市探索用户 | 熟悉本地常规地点，希望发现新鲜体验 | 避开去过和同质化地点，探索城市新玩法 |
| 短途出游用户 | 想离开本城但不想做完整攻略 | 得到周末可往返的目的地和轻量行程 |
- 当我觉得无聊但没有具体想法时，根据我现在的状态直接替我选一个去处。
- 当我说“周六和对象出去玩”时，用少量必要问题给出一套约会方案，而不是一长串榜单。
- 当我不想思考时，允许我开启“直接帮我决定”，并在可接受范围内自动采用合理默认值。
- 当我觉得主方案太远、太贵或太累时，只替换不合适的部分。
- 当天气、营业状态或活动余票发生变化时，提醒我并给出等价替代。
- 当同伴意见不一致时，汇总偏好并提供一个兼顾方案或快速投票。
- 当我要出发时，让我能从方案直接进入导航、预约或分享，而不是继续查攻略。
| 优先级 | 场景 | 首发策略 |
|---|---|---|
| P0 | 现在去哪 | 产品主入口，聚焦未来 2–8 小时、同城可到达、可立即执行 |
| P0 | 周末去哪 | 聚焦半天或一天，为留存和提前规划服务 |
| P1 | 约会/朋友去哪 | 复用 P0 能力，增加关系场景模板、分享和轻量反馈 |
| P1 | 一个人去哪 | 强调低社交压力、安全、独处友好和新鲜探索 |
| P1 | 亲子去哪 | 数据要求更高，补齐年龄、设施和安全字段后开放 |
| 后续 | 周末短途/多日旅行 | 在同城决策闭环验证后扩展，不作为首版主战场 |
MVP 应以“同城、当天或本周末、无需复杂预订”为首发边界，避免重新扩张成泛旅行攻略产品。
MVP 必须形成以下闭环：
表达当下状态 → 自动补全场景 → 收敛候选 → 给出主方案 → 接受或一句话调整 → 出发/分享 → 反馈
MVP 包含：
- 微信登录或其他低摩擦登录方式；
- 低负担的新用户偏好采集，并允许直接跳过；
- “现在去哪”“周末去哪”“约会去哪”“亲子去哪”“一个人去哪”等场景入口；
- 基于当前位置、可用时间、同行人、预算、出行半径、心情和精力的需求理解；
- 三档决策模式：直接帮我定、给我少量选择、只给灵感；
- 多轮对话与流式回复；
- POI、展览、演出、市集、公园、商圈和短途目的地的搜索、过滤和推荐；
- 默认一个主方案、最多两个差异化备选；
- 半天、一天和周末轻量方案生成；
- 基于地图的路线与地点展示；
- 自然语言局部调整；
- 接受方案、保存、复制、分享和进入导航；
- 推荐理由、数据来源和更新时间展示；
- 去过、不喜欢、太远、太贵、没兴趣等快速反馈；
- 新鲜度控制，减少重复推荐用户去过或明确不喜欢的玩法；
- 点赞、点踩、原因反馈和问题上报；
- 基础运营后台：城市、POI/活动、内容源、主题玩法、提示词版本和反馈查看。
- 机票、酒店、门票的真实库存锁定、下单、支付和退款；
- 全量内容社区、达人笔记和短视频信息流；
- 单纯追求 POI 数量的榜单或搜索产品；
- 覆盖复杂多日长途旅行的完整 OTA 能力；
- 面向商家的复杂营销投放系统；
- 用户自由安装第三方插件；
- 完全自治、长时间无人值守的任务执行；
- 同时覆盖大量城市和全部旅行品类；
- 为了“智能体”概念而引入复杂多 Agent 协作；
- 用 AI 生成无法验证的点评、价格、营业时间或预订状态。
- 基于空闲时间、天气和用户习惯主动发起“今天要不要出去”的建议；
- 实时天气、交通、闭店或余票变化触发的主动换方案建议；
- 多人协作投票与偏好合并；
- 酒店、门票、餐厅的比价、深链跳转和联盟转化；
- 经用户明确确认后的预订和支付；
- 图片识别、语音输入、聊天记录和内容链接解析；
- “惊喜模式”：在安全范围内暂不揭晓完整目的地；
- 出行中模式：位置感知、下一站导航、附近临时推荐；
- 多日旅行规划和异地目的地决策；
- 原生 App 或 React Native 客户端。
| 模块 | 说明 |
|---|---|
| 首页 | “帮我决定”主入口、场景快捷入口、当前位置与最近采用方案 |
| AI 决策 | 轻量澄清、决策模式、执行进度、主方案和备选 |
| 去玩方案 | 时间线、地图、预算、推荐理由、导航和修改入口 |
| 灵感/收藏 | 收藏的地点、方案和主题；不作为默认决策主流程 |
| 我的 | 偏好、去过记录、新鲜度、历史决策、授权、隐私和账户设置 |
| 模块 | 说明 |
|---|---|
| 数据运营 | 城市、POI、活动、标签、内容来源、数据质量 |
| Agent 运营 | 提示词、工具开关、模型配置、灰度版本 |
| 用户反馈 | 点踩原因、问题上报、对话追踪和处理状态 |
| 质量评测 | 测试集、版本对比、决策采纳率、约束满足率和失败案例 |
| 系统管理 | 用户、角色、权限、配置和审计日志 |
- 用户从首页点击“帮我决定”，输入：“好无聊，想出去但不知道去哪。”
- FunPlay 在授权范围内读取当前位置、当前时间、天气和稳定偏好。
- 系统只追问一个会显著改变选择的问题，例如“一个人还是和别人一起？”；其余条件采用可见、可修改的默认值。
- FunPlay 搜索并校验候选，默认给出一个主方案：“去河畔骑行看日落，再到附近吃晚饭。”
- 方案展示出发时间、总时长、预计花费、路程、天气适配、推荐理由和第一步行动。
- 用户点击“就这个”，系统保存本次决定并提供导航、预约或分享入口。
- 用户也可以说“有点远”，FunPlay 保留场景和其他约束，只替换为更近的等价方案。
- 用户输入：“周六和对象出去，不想逛商场，人均 300。”
- FunPlay 识别关系场景、时间、预算和避雷项，必要时询问出行半径。
- 系统综合活动新鲜度、天气、交通、营业状态和两人偏好，生成一个半日或一日主方案。
- 为降低选择压力，默认只展示主方案；用户展开后可查看两个具有明显差异的备选。
- 用户接受后生成可分享的行动卡；对方可确认、反馈不喜欢或发起快速投票。
- 用户选择“直接帮我定”和“想尝试新东西”。
- FunPlay 在预算、距离、安全、时间和明确禁忌范围内提高探索权重。
- 系统仍展示需要提前知道的穿着、交通、预约和风险信息，但可按用户设置暂不揭晓完整目的地。
- 用户随时可以退出惊喜模式并查看或更换完整方案。
- 地图或路线服务失败：保留候选地点，明确路线尚未校验，不生成虚假通勤时间。
- 天气数据不可用：使用“天气未确认”标识，不声称适合户外。
- 实时活动或余票不可确认：标记为“需自行确认”，不以稀缺性诱导用户。
- 可用候选不足：说明哪些条件造成冲突，请用户只放宽一个影响最大的条件。
- 模型超时：保留本次用户输入和任务状态，允许重试或稍后查看。
- 部分工具失败：返回可用部分，并标出缺失依据。
优先级含义：
- P0：没有该能力就无法形成 MVP 闭环；
- P1：显著提升留存或质量，可在首个公开版本后补齐；
- P2：验证商业模式或规模化后再考虑。
| 编号 | 优先级 | 需求 | 验收标准 |
|---|---|---|---|
| ACC-01 | P0 | 用户登录 | 用户可完成微信登录；失败有明确提示；登录态可安全续期和退出 |
| ACC-02 | P0 | 基础偏好 | 用户可设置常用位置、预算、活动半径、节奏、兴趣、同行关系和避雷项 |
| ACC-03 | P0 | 偏好可控 | 用户可查看、修改、关闭个性化记忆并删除已保存偏好 |
| ACC-04 | P1 | 多场景画像 | 用户可为独处、情侣、朋友、亲子等场景保存不同偏好模板 |
| ACC-05 | P1 | 去过与厌倦管理 | 用户可查看或删除去过记录，并标记“暂时不想再看此类玩法” |
| 编号 | 优先级 | 需求 | 验收标准 |
|---|---|---|---|
| AGT-01 | P0 | 多轮对话 | 同一会话内能引用已确认的日期、预算和同行人等上下文 |
| AGT-02 | P0 | 状态与约束提取 | 结构化展示系统识别到的位置、可用时间、同行人、预算、心情、精力和限制，用户可以更正 |
| AGT-03 | P0 | 最少必要追问 | 只在缺失信息会显著改变结果或涉及高风险操作时追问 |
| AGT-04 | P0 | 流式进度 | 用户能看到生成状态、工具执行状态和可取消入口 |
| AGT-05 | P0 | 工具调用 | POI/活动、地图/路线、天气等调用结果有超时、重试和失败降级 |
| AGT-06 | P0 | 可解释结果 | 每个核心推荐包含简短理由；实时事实包含来源和更新时间 |
| AGT-07 | P0 | 主动收敛 | 在“直接帮我定”模式下默认给出一个主方案，备选不超过两个且差异明确 |
| AGT-08 | P0 | 局部修改 | 用户说“太远、太贵、太累、不想去室内”等反馈时，保留未受影响条件 |
| AGT-09 | P0 | 结果恢复 | 断网或刷新后可恢复已完成内容；重复提交不会重复创建方案 |
| AGT-10 | P0 | 决策模式 | 用户可随时切换“直接帮我定、少量选择、只给灵感”，切换后结果符合对应信息量 |
| AGT-11 | P1 | 长期记忆 | 经用户授权后，将稳定偏好、去过记录和明确负反馈用于后续推荐，并允许撤销 |
| AGT-12 | P1 | 探索控制 | 用户可调节熟悉与新鲜程度；探索结果仍必须满足安全和硬约束 |
| 编号 | 优先级 | 需求 | 验收标准 |
|---|---|---|---|
| PLN-01 | P0 | 创建决策请求 | 用户无需先给出目的地，可从模糊表达创建一次“去哪玩”决策 |
| PLN-02 | P0 | 主方案结构 | 方案展示主题、地点、时间线、通勤、预计花费、适合原因和下一步行动 |
| PLN-03 | P0 | 候选收敛 | 系统先过滤硬限制，再综合偏好、新鲜度、质量和可执行性选出主方案 |
| PLN-04 | P0 | 约束校验 | 系统能识别来不及、重复地点、闭店风险、天气不适配和过长通勤 |
| PLN-05 | P0 | 地图展示 | 地点和顺序可在地图中查看；无坐标数据不得伪造位置 |
| PLN-06 | P0 | 费用估算 | 费用明确标记为估算，展示币种、范围和数据时间 |
| PLN-07 | P0 | 接受与行动 | 用户点击“就这个”后可保存，并获得导航、预约、分享等下一步入口 |
| PLN-08 | P0 | 保存与分享 | 用户可保存、重命名、复制和删除方案；分享内容默认不含私密信息 |
| PLN-09 | P1 | 快速换方案 | 用户拒绝主方案时可选择原因，系统生成等价但避开该原因的新方案 |
| PLN-10 | P1 | 备选与投票 | 主方案可带最多两个差异化备选，并支持同行人轻量反馈或投票 |
| 编号 | 优先级 | 需求 | 验收标准 |
|---|---|---|---|
| POI-01 | P0 | 地点与活动检索 | 支持按城市、时间、主题、距离、类型和场景检索地点及活动 |
| POI-02 | P0 | 去重与归一 | 同一地点来自多个数据源时形成统一实体并保留来源映射 |
| POI-03 | P0 | 数据新鲜度 | 营业时间、活动日期、价格和余票等易变字段记录来源和最近更新时间 |
| POI-04 | P0 | 推荐过滤 | 时间、距离、预算、营业/活动状态等硬限制先过滤，再进行个性化排序 |
| POI-05 | P0 | 新鲜度排序 | 已去过、近期重复曝光和明确不喜欢的内容默认降权或过滤 |
| POI-06 | P1 | 用户纠错 | 用户可上报地点关闭、活动结束、位置错误或信息过期 |
| 编号 | 优先级 | 需求 | 验收标准 |
|---|---|---|---|
| OPS-01 | P0 | 推荐反馈 | 用户可点赞、点踩并选择结构化原因 |
| OPS-02 | P0 | 问题追踪 | 管理员可根据请求 ID 查看脱敏后的调用链和失败阶段 |
| OPS-03 | P0 | 提示词版本 | 提示词和工具配置可版本化、灰度发布和快速回滚 |
| OPS-04 | P0 | 质量评测 | 每次发布前可运行固定测试集并对比核心指标 |
| OPS-05 | P1 | 内容运营 | 管理员可配置重点城市、场景主题、季节玩法和人工精选地点/活动 |
- 根据用户选择的决策模式，搜索、过滤、排序和收敛地点/活动候选；
- 查询天气、路线和公开信息；
- 在约束范围内采用可见的默认值；
- 生成、校验和调整去玩方案；
- 在用户自己的数据及授权范围内读取偏好、去过记录和历史方案；
- 保存用户明确接受或要求保存的草稿。
- 任何支付、下单、预约、退款或取消；
- 向外部联系人发送消息；
- 公开分享包含用户个人信息的内容；
- 删除不可恢复的数据；
- 使用精确位置、通讯录等敏感权限；
- 将一次性表达沉淀为长期记忆。
- 默认先输出明确结论和行动卡，再按需展开攻略详情；
- “直接帮我定”模式只给一个主方案；“少量选择”模式最多给三个差异化方案；
- 说明系统采用的关键默认值，例如出行半径、预算范围和最晚结束时间；
- 明确区分“已确认事实”“估算”“建议”和“未知”；
- 重要事实尽量附来源与更新时间；
- 不展示内部思维过程，但可展示简洁的推荐依据和工具状态；
- 遇到冲突约束时指出冲突，并给出可选择的取舍；
- 不以“已经预订”“一定开放”等措辞描述尚未执行或无法验证的状态。
| 对象 | 说明 |
|---|---|
| User | 用户身份和账户状态 |
| PreferenceProfile | 用户授权保存的长期偏好 |
| Conversation | 一段对话及其上下文 |
| Message | 用户、Agent、工具或系统产生的消息 |
| AgentRun | 一次 Agent 执行、状态、版本和成本记录 |
| DecisionRequest | 一次“去哪玩”请求、当下状态、硬约束和决策模式 |
| Candidate | 经召回和过滤的候选地点、活动或组合及其评分依据 |
| PlayPlan | 用户可接受和执行的半日、单日或周末方案 |
| PlanItem | 方案中的地点、活动、交通、用餐或休息节点 |
| POI | 统一地点实体 |
| Event | 有明确起止时间的展览、演出、市集或其他活动 |
| POISource | POI 与外部数据源的映射及更新时间 |
| Exposure | 推荐曝光、接受、拒绝、去过和反馈记录 |
| Feedback | 用户对回答、地点、活动或方案的反馈 |
以下为 MVP 服务目标，正式 SLA 需根据部署方案和成本重新确认：
| 维度 | 目标 |
|---|---|
| 首次反馈 | 用户提交后 1 秒内显示已接收或正在处理状态 |
| 首段内容 | 正常情况下 P95 不超过 3 秒 |
| 主方案生成 | 常规请求 P95 不超过 20 秒；复杂周末方案 P95 不超过 45 秒 |
| 可用性 | 用户核心链路月可用性目标 99.5%，第三方故障需可降级 |
| 一致性 | 方案、额度、反馈等写操作支持幂等；不得因重试重复扣减或重复创建 |
| 隐私 | 最小化采集、明确授权、可撤回、可导出和可删除 |
| 安全 | 管理端强认证和权限隔离；敏感信息不写入普通日志 |
| 可访问性 | 核心文字具备足够对比度，图片信息提供文本替代 |
- 明确每个外部数据源的授权范围、缓存期限、展示要求和商业使用限制。
- 用户位置只在提供功能所需范围内使用；精确位置必须单独授权。
- 对话、偏好、去过记录和方案属于用户数据，应支持删除和过期策略。
- 模型供应商、日志平台和分析平台不得默认接收不必要的个人信息。
- 用于模型评测或训练的数据必须脱敏并获得相应授权。
- 产品上线前应根据实际经营区域完成隐私政策、用户协议、生成式 AI 标识及相关合规评估。
每周有效出发次数：用户接受 FunPlay 的主方案后，发生导航、预约、同行确认、到访反馈或计划开始后的再次打开等至少一种行动信号。
在无法可靠获得到访信号的 MVP 阶段，使用“每周被接受的去玩方案数”作为代理指标。该指标关注 FunPlay 是否真正帮用户结束犹豫，而不是生成了多少内容。
- 感到无聊/进入首页 → 发起“帮我决定”；
- 发起请求 → 系统获得足够上下文；
- 获得上下文 → 成功给出主方案；
- 主方案曝光 → 点击“就这个”；
- 接受方案 → 导航、预约、分享或同行确认；
- 首次有效决策 → 次周再次发起决策。
- 关键约束满足率；
- 主方案采纳率和首次推荐采纳率；
- 从发起请求到做出决定的中位时长；
- 平均每次决策追问数；
- 地点/活动真实性和可用性准确率；
- 明显时间冲突率；
- 路程、预算和总时长合理度；
- 重复与同质化推荐率；
- 拒绝原因后的换方案成功率；
- 点踩率及原因分布；
- 第三方工具失败率；
- Agent 单次任务成本和耗时。
- 虚假事实率；
- 已结束、闭店或来不及到达的内容进入主方案的次数；
- 因过度个性化造成的重复推荐率；
- 未授权敏感数据访问次数；
- 重复创建或重复扣减次数；
- 高风险操作未经确认执行次数；
- 用户投诉和内容安全事件数。
公开测试前至少满足：
- 重点城市 POI 抽检质量达标，关键字段有来源和更新时间；
- 首批重点活动源的有效期、状态和去重逻辑通过抽检；
- 固定评测集中的硬约束满足率达到团队约定阈值；
- 主方案模式不会退化为未经排序的长列表；
- 不出现未经确认的付费或外部操作；
- 核心链路具备幂等、超时、重试、取消和降级能力；
- 已完成隐私政策、用户协议、数据源授权和安全检查；
- 管理员可定位失败请求并回滚提示词或模型配置；
- 已建立成本上限、频率限制和异常流量告警。
- 访谈 10–20 名目标用户；
- 收集 100 条真实“无聊、不知道去哪、懒得做攻略”的表达；
- 验证用户是否愿意把决定交给 Agent，以及可接受的追问数量；
- 选择 1–2 个重点城市；
- 验证 POI、活动、地图、天气数据源的覆盖、价格和授权；
- 建立首版离线评测集。
- 完成登录、场景入口、决策模式、工具调用、主方案、地图、接受和反馈闭环；
- 支持少量重点城市；
- 建立后台追踪、提示词版本和基础评测；
- 团队内部及邀请用户测试。
- 提升快速换方案、弱网恢复、活动数据新鲜度和推荐新鲜感；
- 增加分享页、运营配置和成本治理；
- 根据真实反馈优化推荐排序和城市覆盖。
- 验证深链跳转、联盟转化或会员权益；
- 只有在交易价值和组织能力得到验证后，再建设订单、支付和售后域。
| 风险 | 影响 | MVP 应对 |
|---|---|---|
| POI/活动数据过期或无授权 | 推荐不可用、产生合规风险 | 优先确认数据合同；记录字段级来源、有效期和更新时间 |
| Agent 仍给出大量选择 | 没有真正降低决策成本 | 默认一个主方案；限制备选数量；跟踪决策耗时和采纳率 |
| 自动选择与用户期待不符 | 用户感觉“自作主张”并失去信任 | 提供三档决策模式；公开关键默认值；一句话换方案 |
| 推荐过度依赖历史偏好 | 内容重复、缺少惊喜感 | 建立曝光与去过记录；设置探索比例；允许调节新鲜度 |
| 内容看起来不错但不足以促使出门 | 方案被收藏却不执行 | 强化距离、时间、天气和第一步行动；优化“就这个”后的转化 |
| 模型生成看似合理但不可执行 | 用户失去信任 | 使用结构化工具结果和确定性校验器，不只靠提示词 |
| 调用链长、速度慢、成本高 | 转化与毛利受损 | 工具并行、缓存、预算上限、小模型分流和结果复用 |
| 需求范围失控 | 无法按期形成闭环 | 严格维持 MVP 不做清单，以重点城市验证 |
| 过早建设交易系统 | 增加事务和合规复杂度 | 首版仅提供建议和跳转，交易域后续独立评估 |
| 用户误以为 Agent 已替其操作 | 造成损失和投诉 | 明确状态；所有外部重要操作二次确认并提供回执 |
- 首批重点城市和种子用户从哪里获取？
- 首版只做微信小程序，还是同时发布公开 Web 端？
- 首发优先验证“现在去哪”“周末去哪”“约会去哪”中的哪一个场景？
- 地图、POI、展演活动、天气和内容数据源分别选择哪家，授权成本如何？
- 默认决策模式是“直接帮我定”还是“给我三个选择”？
- 用户可接受的首次输入项和追问上限分别是多少？
- 是否需要在首版接入门票、餐厅或活动报名的联盟深链？
- 用户长期偏好、去过记录和精确位置分别采用怎样的默认授权策略？
- 如何以导航、到访反馈或位置授权校准“有效出发”指标？
- 产品首发区域、主体资质和模型供应商有哪些合规限制？