智能助手 · 北极星与终局蓝图
上一次更新: 2026-08-17 决策：ADR-039 · ADR-040 本文回答：这个 AI 应用的「最终章」长什么样、护城河在哪、怎么一站一站迭代过去。 和施工图分工：本文讲终局与主线（为什么 / 去哪）；具体排期仍留在主仓，不收录到博客。
主线拍板（2026-08-16）：
- 产品主线 = C 端「搭子 / 活动匹配」（先合 C 端闭环 M1，再做匹配 M2），走社交差异化。
- 模型基线 = DeepSeek（经
ILlmPort隔离，随时可换，换模型≈跑评测回归 + 调 Prompt）。- 蓝图里程碑制 = M0–M7，可停在任一里程碑。
0. 北极星（一句话）
让用户「用一句话，找到对的活动、对的搭子、并顺手组好局」；让运营「用一句话，复盘一场活动并生成可落库的报告」。 模型只负责「理解 + 表达」，所有真相（活动、人、订单、指标）都来自现有业务系统。
判断任何一个待做功能是否属于主线，只问一句：它是否让「说话 → 系统真实实体 → 可点击动作」这条链更顺、更准、更可信？ 是则做，否则不做。
1. 我们不是 OTA：护城河在哪
竞品现状（截至 2026-08，来自公开信息）：
| 竞品 | 形态 | 核心能力 |
|---|---|---|
| 携程 问道 / TripGenie / Trip.Planner | 垂直大模型 + AI 行程助手 | 行程规划（食住行游娱购）、地图拖拽编辑、实时数据验证、机酒比价、预订闭环、商旅 7-Agent「程星途」 |
| 飞猪 问一问 → 飞猪帮帮（2026-08） | Multi-Agent | 「帮我想 / 帮我订 / 帮我办」三入口，攻略→预订→退改→报销全链路，拍照讲解，履约层 |
| 马蜂窝 AI 小蚂 / AI 路书 | DeepSeek + UGC | 实时问答、个性化路书、目的地「专属管家」 |
共性：它们都在拼同一件事——个人行程规划 + 机酒门票预订闭环（OTA 基因）。
结论：TourMate 不是 OTA，是「活动 + 搭子」社交匹配平台。终局不去卷「新疆七日游行程规划」（数据打不过携程），而打竞品结构性不做的空白区：
🟢 对话式「找活动 / 找搭子 / 组局报名」 —— 这是护城河，是你区别于携程飞猪的地盘。
对齐策略：
| 竞品共性能力 | 我们的策略 |
|---|---|
| 多日行程规划 | ⚠️ 非主线（OTA 强项）；后期最多做「多活动串周末路书」轻量版 |
| 真实库存 + 预订闭环 | ✅ 必须对齐：卡片来自真实活动 + 深链进详情报名（M1） |
| 个性化推荐（问偏好） | ✅ 对齐且是强项：复用推荐/画像做「搭子匹配」（M2） |
| RAG 知识问答 | ✅ 对齐：平台规则 / 玩法 / 目的地知识助手（M4a） |
| Multi-Agent / 履约 | 🔵 终局再做（M7），不过早拆 |
| 拍照讲解 / 多模态 | 🔵 选做，非主线 |
| 对话式找搭子 / 组局 | 🟢 差异化主攻：竞品空白 |
2. 三条产品线终局
| 产品线 | 终局能力 | 类比 | 能力层 |
|---|---|---|---|
| C 端 · 出行搭子 Agent（主线） | 说话 → 匹配真实活动/搭子 → 对话内预览报名 → 跳转支付；群内 @助手协调 | 挂号推荐医生 + 点餐组单 | L1→L3 |
| B 端 · 运营数字员工 | 说话 → 固定工作流查订单/退款/转化 → Java 算指标 → 模型写报告 → 人工确认落库 | 运营数字员工 | L4 |
| 对外 · 能力开放 | 把 search_activities / get_refund_policy 等封装成 MCP，给 Cursor/Claude 复用 | OpenAPI 的 AI 版 | L5 |
3. 企业 AI 应用「能力六层」→ 本项目对应
（源自仓外底稿 99-原文档/TourMate-Agent-能力分层学习底稿.md，此处是本项目的落点映射）
| 层 | 通用能力 | TourMate 落点 |
|---|---|---|
| 1 模型调用 | 稳定调 API、超时、降级 | ILlmPort + OpenAiCompatibleLlmAdapter（默认 mock） |
| 2 结构化输出 + Prompt + 评测 | JSON Schema、System Prompt、Evals | ActivitySearchIntent + 评测记分卡 |
| 3 RAG | 切块/元数据/混合检索/引用/拒答 | 知识助手（M4a，先关键词后向量） |
| 4 Tool Use / MCP | 工具定义、路由、治理分级、MCP | 真 Function-Calling（M3）+ MCP（M7） |
| 5 Workflow / Agent / Memory | 状态机、HITL、分层记忆 | B 端工作流（M4b）+ 记忆（M5） |
| 6 生产级治理 | 权限、审计、可观测、防注入、限流 | 审计 + 日限额 + traceId（已骨架，持续加厚） |
4. 「算不算 AI 应用」标尺（L0–L5）
别凭感觉，用这把尺随时定位：
| 级别 | 定义 | 判据 | 谁在这级 |
|---|---|---|---|
| L0 | 接了个模型能聊天 | 能调通 API | 玩具 Demo |
| L1 | 结构化输出 + 单工具 + 真实数据 | 虚构=0，列表来自业务查询，可点击 | C 端 MVP 及格线 |
| L2 | 评测 + 治理 + 多轮 | 评测集过线、审计限流、缺槽追问 | 能内测上线 |
| L3 | 真 Function-Calling + 多工具 + 工具治理分级 | 模型自主选工具，高风险要确认 | 像样的产品 |
| L4 | RAG（带引用/拒答）+ 长流程编排 + HITL | 知识问答有出处、B 端工作流可人工确认落库 | 竞品主力在此 |
| L5 | 记忆/个性化 + 多 Agent + MCP + 多模型路由 | 跨会话记偏好、对外可复用、成本可控 | 飞猪帮帮 Multi-Agent |
当前坐标：M1 评测已过线（真模型 DeepSeek·意图 100%·43 条）→ 跨过 L1、站上 L2；M3a-① 天气意图已落地（QUERY_WEATHER 复用 IWeatherPort 预报 + grounding，2026-08-18）；M3a-② 行程规划已落地（MAKE_TRAVEL_PLAN 首个 chat 生成型意图·独立生成 Port·grounding·成本闸门默认关，ADR-041，2026-08-18）；M3b 真 Function-Calling 已落地（手写 OpenAI 兼容 tool-calling·Agent 循环 + 工具注册表·与意图派发双通道并存·成本护栏默认关，ADR-042，2026-08-18）→ 正式站上 L3（模型编排版，把选工具权交模型）；工具治理分级 / HITL 尚缺。L4 部件（RAG 骨架/治理/多轮）已提前造。 动作：M3a/M3b 收口 → 顺 M2（检索升匹配，产品灵魂）/ M3b 工具治理分级 + HITL / M4a（RAG 向量化） 走，不再半空加骨架。
5. 四个高频困惑的定论
| 困惑 | 定论 |
|---|---|
| 「只是接了个模型」和 AI 应用差在哪？ | 差在模型外面的结构化输出 / Tool / Prompt / 评测 / 治理 / RAG·记忆·编排六层约束。裸模型=聊天 API；AI 应用=把模型锁进业务。 |
| 怎么让模型调系统内活动、做匹配？ | Function Calling：用 JSON 描述把「查活动」方法告诉模型，模型决定调不调、传什么参；执行的仍是你的 Java。模型拿不到库=不虚构的物理保证。注意：现在是「检索(filter)」，产品灵魂是「匹配(人×活动×偏好)」——M2 升级。 |
| 怎么做 Prompt 增强？ | System Prompt 8 段（角色/任务/意图枚举/Schema/规则/边界拒答/few-shot/失败处理）+ 用评测集驱动迭代。Prompt+评测集是核心资产。 |
| DeepSeek 换 v4 要重做吗？ | 不用。ILlmPort 隔离，换模型只改配置；然后用评测集回归 + 调 Prompt（不是微调模型）。这正是「AI 应用工程」相对「调模型」的价值分水岭。 |
6. 从终点倒推的里程碑 M0–M7
每个里程碑 = 一个能对外交付/演示的能力，可停在任一站，每站产出一篇 devlog：
| 里程碑 | 交付物（能对外说的话） | 能力层 | 现状 |
|---|---|---|---|
| M0 地基 | Port 隔离 + 评测/治理/多轮/RAG 骨架 | — | ✅ 已完成 |
| M1 · C 端闭环封顶 ⭐ | 真模型(DeepSeek)+真活动，App「说话→点进详情」，评测 30~50 条过线（虚构0/越权0/P95<8s） | L1→L2 | ✅ 评测过线（意图 100%·时延 935ms·虚构/越权 0，见 devlog 13）；App 对话页+深链已接，真实活动详情待造数点验 |
| M2 · 检索升级为「匹配」 | 从条件筛 → 融合画像/搭子偏好排序 + 「为什么推给你」解释 | L2+ | 🟡 最小闭环（A0/A1：活动双轨标签 + 人口硬过滤 + 画像重排 + 匹配评测轨，ADR-043，2026-08-19）；Phase B（评分质量分/地理时间权/「为什么推给你」/Agent 路）待做 |
| M3a · 多意图·多工具·固定工作流 ⭐ | 扩 QUERY_WEATHER✅ / MAKE_TRAVEL_PLAN✅ 等意图，Java 编排；工具 4/5 已在库（详见 §6.1） | L2→L3 | ①天气✅ ②行程✅（2026-08-18，ADR-041） |
| M3b · 真 Function-Calling + 工具治理 | 模型自主选工具（活动/推荐/天气…）+ 工具分风险等级 + HITL | L3 | ✅ 循环 + 3 工具（search/weather/detail）·手写 tool-calling 双通道·默认关（2026-08-18，ADR-042）；工具分级/HITL 待做 |
| M4a · RAG 知识助手 | 「退款规则/玩法/目的地」问答，带出处引用 + 无资料拒答 | L4 | 🟡 关键词骨架在，缺向量/引用/拒答 |
| M4b · B 端运营数字员工 | 「分析五一活动转化」→工作流→Java 算指标→模型写报告→人工确认落库 | L4 | 待做 |
| M5 · 记忆与个性化 | 跨会话记住偏好（常去地/预算档），可编辑可删除 | L4+ | 待做 |
| M6 · 组局 / 意向单 | 对话内组装报名意图→跳支付；群内 @助手 | L3+ | 待做（差异化终局） |
| M7 · MCP / 多 Agent / 多模型路由 | 工具对外开放 + 成本/自托管治理 | L5 | 触发式，最后做 |
及格线（能对外说「做过 AI 应用」）= M1。优秀线 = M4。差异化线 = M2 + M6。
6.1 M3 拆解：先做「Tool-augmented Assistant」，再谈真 Function-Calling
定性（2026-08-17 讨论确认）：TourMate 现在要追的不是 DeepSeek Harness 那种大而全的底座，而是把「单一意图助手」升级成 多意图 + 多工具 + 固定工作流的垂直旅游助手（Tool-augmented AI Assistant）。等每个意图的固定流程都跑稳、评测过线，再把「选工具的决定权」交给模型（M3b 真 Function-Calling）。
一句话定心：你做的不是「低配 ChatGPT」，是「会查真实活动、能跳转下单、懂业务边界」的垂直助手。 ChatGPT 是通用工具箱，它看似全能只因背后接好了很多工具；TourMate 的护城河恰恰在真实库存 + 深链下单 + 业务边界。
M3a：多意图 · 多工具 · 固定工作流（Java 编排，先做）
意图枚举（在现有 SEARCH_ACTIVITIES / RECOMMEND / OUT_OF_SCOPE 上扩）：
| Intent | 含义 | 固定流程（谁做什么） |
|---|---|---|
SEARCH_ACTIVITIES | 查活动 | LLM 抽槽 → Java 查库 → 卡片（✅ 已做） |
QUERY_WEATHER | 查天气 | LLM 抽地点 → Java 调 IWeatherPort.getDailyForecast（复用 ICommonApplicationService 缓存）→ 模板回复（✅ 已做 2026-08-18） |
MAKE_TRAVEL_PLAN | 做攻略 / 行程 | LLM 抽「目的地/天数/预算」→ 查活动 + 天气(+资料) → LLM 生成每日行程(grounding) → 卡片 + 文案（✅ 已做 2026-08-18：独立 IItineraryGenerationPort，卡片只出 Java 真相、查不到活动不生成，tourmate.assistant.plan.* 默认关，ADR-041） |
RECOMMEND_DESTINATION | 推荐去哪 | 新意图（区别于现有 RECOMMEND=推荐热门活动）；先接知识库/常识，后升 RAG |
OUT_OF_SCOPE | 拒答 / 引导 | Java 写死话术（✅ 已做） |
工具清单与库里现状（摸底 2026-08-17：5 个里 4 个已存在，只 build_itinerary 需新造）：
| Tool | 现状 | 位置 / 落点 |
|---|---|---|
search_activities | ✅ 已接助手 | searchActivitiesAdvanced |
get_activity_detail | ✅ 存在，未接助手 | getActivityDetailWithMembers(activityId) |
get_weather | ✅ 已接助手（2026-08-18，加 7 天预报） | IWeatherPort.getDailyForecast + QWeatherAdapter(7d)/OpenMeteoAdapter(daily)/MockWeatherAdapter；助手复用 ICommonApplicationService.getWeatherForecast(缓存) |
get_destination_info | 🟡 已有关键词版 RAG | KeywordKnowledgeRetrievalAdapter + destinations.json |
build_itinerary | ❌ 唯一要新造 | 检索后 LLM 生成（ADR-040 grounding 思路） |
三条关键认知
- 「接工具」80% 是把已有 Port 挂到意图路由上，不是造新能力（复用纪律，见 AGENTS.md「新增基础设施前的强制摸底」）。天气就是活例：接
QUERY_WEATHER≈ 复用IWeatherPort，和当初复用searchActivitiesAdvanced一模一样。 MAKE_TRAVEL_PLAN是第一个真正用到模型「生成/组织成人话」能力的意图。前面查活动/查天气，模型只干「抽 JSON」；做攻略必须多一步「把查到的真实活动 + 天气喂回模型 → 生成每日行程」。因此它更贵、更需防幻觉——必须约束「只能用查出来的真实活动，不许自己编景点」（幻觉=0 是产品可信度底线）。- 落地顺序（性价比/风险排序）：
- ①
QUERY_WEATHER：工具现成、单轮、token 极低、演示立竿见影 → 验证「多意图路由」最便宜的一步（✅ 已做 2026-08-18：IWeatherPort加 7 天预报 + grounding 拼真实预报 + 缺地点追问）。 - ②
MAKE_TRAVEL_PLAN（靠谱版）：最大差异化，但要配成本闸门 + grounding 约束，别裸放（✅ 已做 2026-08-18：独立生成 Port +tourmate.assistant.plan.*默认关 + 卡片只出真实活动，边界见 ADR-041）。 - ③
RECOMMEND_DESTINATION/get_destination_info升向量 RAG：想清产品价值再做，别为技术而技术。
- ①
M3b：真 Function-Calling（模型自主选工具）✅ 已落地（2026-08-18，ADR-042）
- 用 JSON 描述把工具告诉模型，模型自己决定调哪个、传什么参、要不要多轮循环。
- 实现：手写 OpenAI 兼容 tool-calling（不引 Spring AI）——
ILlmPort.chat(messages, tools)低阶往返（OpenAiCompatibleLlmAdapter发tools/收tool_calls、MockLlmAdapter出确定性 tool_call）+ domainAssistantApplicationService的 Agent 循环 + 工具注册表 dispatcher；首批工具search_activities/get_weather/get_activity_detail。 - 双通道并存：
agent.enabled=true走模型编排；关（默认）走 M3a 稳定意图派发（评测锚点，零回退），可灰度切换。 - 成本/安全护栏：
tourmate.assistant.agent.*（默认关 +max-iterations循环上限，每次 tool call 结构化日志）；grounding：卡片只来自工具真实返回、模型碰不到活动 id、工具空结果如实告知不编造。 - 尚缺：工具风险分级 + 高风险工具（组局/支付/落库）人工确认（HITL）——下一步。
- 攻略三档参考：轻量版（LLM 常识，可能不准）→ 靠谱版（查活动+天气+资料再让 LLM 组合）→ 产品版（偏好+活动+天气+预算+天数，每个活动可点进真实详情）。产品版 = M3a 的
MAKE_TRAVEL_PLAN逐步长成。
7. 主线说明：为什么先 C 端闭环再做匹配
- M1 先行：架构方向已对，缺的是「接真模型 + 真实数据 + 可点击验证 + 评测过线」这一次封顶。做完即从「学了」变「做出了」。
- M2 紧随：把「检索」升级为「匹配」（融合已有推荐/画像），这才是 TourMate 区别于 OTA 的灵魂；也顺势对齐竞品的「个性化」标准，却打在社交差异化上。
- 不一气呵成：M3a 起一站一站来（先固定工作流、后 Agent 化），每站可停、可交付、可写进能力叙事。
8. 模型基线与可替换性
- 基线：DeepSeek（性价比高、中文强；经中转 Key 走
provider=openai-compatible）。 - 隔离：业务只认
ILlmPort；换模型（v4 / Qwen / GPT-4o）= 改配置provider/model一行。 - 换模型流程：跑评测集回归 → 掉分处调 Prompt/加 few-shot → 对比 token/延迟/成本。业务代码零改。
9. 与其它文档的关系
| 文档 | 角色 |
|---|---|
| 本文《北极星与终局蓝图》 | 终局与主线（为什么 / 去哪 / 护城河） |
| 出行助手全场景流程图 | 一句话走进哪条代码链路 |
| 线上接入不影响 DDD | 现网怎么加助手、又不拆六边形 |
| ADR-039 | 主仓架构决策：包级接入 / 开关隔离 / 可剥离 |