CASE STUDY · TripMind
Travel Agent
把一句出行想法，
变成核验过、能继续改的行程
面向第一次自由行、已选好国内城市的用户：用自然语言说出天数、节奏和在意的事，得到一份 2–5 天的行程。地点、路线和天气来自真实地图工具，没核验过的结果不会被当成当前行程。
- 我的职责
- 用户与范围定义 · 评测设计 · 关键取舍与验收（借助 Codex 实现）
- 交付形态
- Web（手机／桌面）
- 当前阶段
- 原型验证（0A），未公开发布
200 次真实规划交付 157 次
真实模型与真实高德地图，四条固定需求各 50 次。
记录「无胜者」
唯一候选配置稳定性不达标，不为结论改门槛。
行程质量护栏上线
超长步行改公交、餐厅按餐段营业过滤，均经真实请求确认。
01 / 问题与范围
只服务一类人，只做一件事
目标用户
第一次自由行、已经选好城市
不缺攻略，缺的是把景点、吃饭、路上时间排成一份能走得通的计划。
产品承诺
一份合理的 2–5 天行程
对话说需求，行程是结果；之后继续对话修改，由用户明确定稿。
明确不做
不订票，不做内容社区
住宿只是可选候选、不代表有房；没有信息流、关注、热门榜单。
自然语言是主入口，不把规划流程做成伪装的表单；一句话里同时提出多个要求时，走同一个理解入口，再决定要调用哪些工具。
02 / 方案
模型负责理解和取舍，事实由工具核验
自然语言输入
目的地、天数、同行人、节奏、必去，用平常的话说。
意图与需求理解
区分新建、修改、只读提问，并逐句保留原文，防止需求被漏掉。
调用必要工具
高德地点搜索、路线、天气；只在需要时调用。
预览与核验分开
结构校验后先显示「未保存」预览；路线核验通过才写入当前行程。
持续修改，用户定稿
点名某一天的修改只动那一天；失败时恢复旧方案，不悄悄覆盖。
03 / 关键取舍
用证据决定留下什么，也决定撤回什么
取舍 1
可核验的文字交给服务端
模型只负责需求理解、选点和日程取舍；行程里的营业、路线、天气说明由服务端从工具结果生成，减少编造事实的空间。
取舍 2
没有合格配置，就写「无胜者」
唯一候选在 6 个会话中 5 个自动通过，但同条件路线重复 1 成 1 败。没有提高 45 秒截止、也没有加 fallback 来制造成功。
取舍 3
无收益的方向关掉，但保留开关
候选片区、远郊限额、一天一片区等 6 个方向经真实对照没有收益后关闭；开关保留，旧证据仍可复现。
一次中途转向：从「提速」回到完整旅程
早期工作集中在压缩单次规划的耗时。2026-09-04 我把目标改为完整闭环：自然语言理解、必要工具、可编辑草稿、持续调整、用户定稿。模型、Agent 架构和 45 秒等待目标都改为可被证据推翻的假设，而用户隔离、事实边界、未校验结果不得写入当前行程这些底线不随试验放松。
行程质量护栏是怎么来的
先离线检查 344 份已交付行程（不花请求），找出最常见的问题，再逐项修复并用小批量真实请求确认：超过 2 公里的步行改查公交（慢节奏或行动受限时 1.2 公里），餐厅按餐段营业和菜系过滤，景点时段与营业时间冲突时给出提示。确认轮中超限步行 29 段全部改成公交，餐厅营业冲突 0／55。
04 / 验证与现状
交付率 78.5%，0A 仍未通过
诚实边界：完整规划仍会超过 45 秒截止，用户自由输入的验收还没开始，所以 0A 没有通过。这是一份原型验证记录，不是已上线的旅行产品。
一次更正：第一轮 200 次评测里「餐厅按菜系过滤」一项，事后发现判定有缺陷，至少 19 餐选了川菜馆；我在报告里更正为不成立，修复后再单独确认。
两轮评测之间不比较提升幅度：各自没有对照组，模型提供方在不同时段的状态差异很大。
Demo 部署后会在这里开放体验。