旅游路线规划 Agent · 项目经历

个人项目 · 独立完成设计 / 实现 / 评测 / 上线 | 2026.10 | GLM-4-Flash 驱动 · 线上真机运行
已上线 · 可对话8 规则时间账求解器双城市案例验证评测 20/20工具循环

一、项目介绍

🎯 背景

AI 旅行规划产品普遍存在"生成得漂亮、执行不了"的问题:大模型排的行程里藏着闭馆日、赶不上的末班车、天黑后的户外景点、落地当晚不可能的到店时间。这些错误用户照着走才会发现——信任一旦崩塌,产品就废了。

💡 目的

验证一个产品命题:把"模型算不准的部分"从 LLM 推理中剥离,交给确定性程序校验,让每份行程"可执行、可验证、可解释"。同时验证这套方法论能跨城市迁移,而不是一次性运气。

📋 需求(我给自己定的产品需求)

需求澄清(开场三问)→ 方案生成(逐日时间表+交通+票价口径)→ 程序化校验(8 规则求解器)→ 拦截/修正(❌ 必须过)→ 可视化交付(静态单文件)

硬性验收线:时间账校验 100% 通过才允许交付;每个票价数字带信源与检索日期;用户偏好(如怕吵)压倒"最优解"。

🏁 成果

线上运行真接 GLM · 可对话
20/20求解器自动化评测
28/28京都五日时间账校验
6→6bad case → 防复发机制

成果一 · 土耳其伊斯坦布尔 1.0(方法论的源头)

第一次真实跨国规划,一天内 8 轮结构迭代(V1 含卡帕 → V2.6 砍卡帕枢纽版)。项目最大的收获恰恰是踩出来的 6 个真实 bad case:LLM 心算"20:30 到店"被落地推演推翻、训练记忆里的水宫旧价 800 里拉(实际 1950/3000)、沿用备忘录的日落 17:30(公式算出 18:15–18:22)……每一个坑都变成了一条确定性规则——这是后续所有能力的地基。

查看案例复盘 →

成果二 · 日本京都 2.0(方法论迁移验证)

用土耳其长出的规则体系在新城市从零排程:闭馆日矩阵避开周一博物馆、龙安寺冬季"受付止 16:00"压线风险被求解器拦截、银阁寺 2026.4 涨价(500→1000 円)被时效核查抓出。五日行程 28/28 全部通过校验,证明方法论不是单城经验,是可迁移机制。

查看京都行程成品 →

成果三 · 线上真机 Agent(最终形态)

不是演示页:访客打开即可对话,每条回复由 GLM-4-Flash 实时生成;Agent 需要校验行程时,云端后端真实执行 8 规则求解器并把结果回喂模型——工具调用轨迹在页面上全程可见。

🚀 打开真机 Agent 工作流拆解演示版
⚠️ 诚实边界:全程单人验证,无多用户线上数据;20 条评测集按求解器规则构造,证明"求解器正确"而非"Agent 输出质量好";门票/政策类数字存在时效性,成品中均标注检索日期并提示出发前复核。

二、工作流:逻辑与技术构造

总架构:四层分离

L1 模型 · GLM-4-Flash→ L2 编排 · 工具循环 + 知识库注入→ L3 应用 · 协议与 SOP→ L4 交互 · 聊天页/对比卡

核心设计决策:模型只做模型擅长的事(理解需求、生成方案、解释结果),确定性的事交给程序(时间账、闭馆日、日落、通勤)。这不是技术炫技,是产品判断——知道 AI 能力边界在哪,才知道产品该把可靠性放在哪一层。

构造 ① · 知识库(travel-agent-kb,16 文档)

九步规划 SOP、12 个决策模式库(P1–P12)、数据口径规则(数字必带信源+检索日期)、意图澄清协议、方案对比卡协议、评测框架。作为 System Prompt 注入 LLM——知识库决定 Agent 的行为边界,实测开场三问被逐字执行。

构造 ② · 8 规则时间账求解器(工具层核心)

规则校验什么真实拦截案例
R3 闭馆日活动撞上每周闭馆日托普卡帕宫周二闭馆(土耳其)
R6 日落户外活动结束晚于日落日落时间 17:30→18:15 修正后窗口+50min
R7 落地推演落地+入境+交通 vs 首个活动"20:30 到店"被推翻(1.0 bad case 之首)
R4 通勤相邻活动间隙 ≥ 通勤时间京都 D3 两处 0min 余量卡点被显式标出
R1/R2/R5/R8重叠 / 时长 / 末班 / 睡眠评测集 20 条全覆盖

同一引擎三处同构:Python 版(tools/time_solver.py,20/20 评测)、云函数版(线上真实工具)、前端版(工作流演示页)。

构造 ③ · 工具循环(Agent 的"手")

用户需求→ GLM 生成方案→ 输出 <<TOOL:time_check>> JSON→ 后端真跑求解器→ 结果回喂 GLM→ 基于真实结果解释/修正

关键工程决策:工具协议用文本标记而非 function calling(零 SDK、可调试、模型 1-shot 学会);工具异常回喂后模型可优雅降级。

构造 ④ · 评测体系(分层的)

工具层:20 条自动化用例,20/20 可复现,禁止"感觉对了"。 输出层:6 个真实 bad case 分层归因——4 个在编排层、2 个在数据层、0 个在模型层。这个归因结论本身就是产品判断力的证据:同代际模型下,产品差异在编排层。

三、解析:这些在产品经理岗位描述里代表什么

本项目的技术构造它证明的产品能力JD 中的对应表述
线上能跑、能对话的 Agent不是 PPT 产品经理——想法→设计→实现→部署→验证全程闭环"有从 0 到 1 落地 AI 产品的经验"
8 规则求解器(模型算不准的剥离为确定性校验)知道模型哪里不可靠,会用规则兜底;对 AI 可靠性有产品级解法"体验指标与评估机制""效果评测"
开场三问协议(≤2 轮×≤3 问、带选项)会设计对话式交互、渐进式澄清,并量化收敛轮次"对话式交互、渐进式提问"
方案对比卡协议做多方案生成与结构化比较,拒绝"神谕式"单一答案"方案生成与对比"
数据口径规则(数字必带信源+检索日期)懂幻觉治理,知道 AI 产物的用户信任从哪来"事实性/可信度""反幻觉"
bad case 分层归因(4 编排/2 数据/0 模型)问题定位到层,不把锅甩给模型——直接决定修哪里"AI 能力边界判断、问题定位"
L1–L4 四层架构与算法/研发协作的共同语言,方案讨论不鸡同鸭讲"技术方案设计、跨团队协作"
双城市验证(土耳其踩坑→京都 28/28)方法论可迁移、可复制——不是撞运气的一次成功"可复制 / 规模化"
诚实边界主动声明对数据口径的严谨,恰是 AI PM 最稀缺的品质"数据敏感度、结果导向"
💡 一句话总结:这个项目里没有一行"我懂大模型"的空话——开场三问是对话设计、求解器是评测机制、归因是问题定位、双城市是可复制性。每个技术构造都能落回一条 JD 能力,这就是"用作品说话"。