zxy的个人博客

让 LLM 稳定输出可被前端消费的 JSON，是 AI 应用从 Demo 走向上线的关键一关。本文结合智能旅行规划助手项目，用解析层、Pydantic 校验+自动重试、真实数据兜底三层防线，把 JSON 解析失败彻底挡在前端之外，并附上我踩过的坑。

写在前面做 MedMind 这个项目之前，我对 RAG 的理解停留在“把文档切块、向量化、检索、生成”这套流程。 这套流程在菜谱问答那个项目里跑得挺顺，但切到医疗场景之后，我发现一个问题一直解决不好：用户问的是感冒，但他真正需要的答案里还涉及发热处理和布洛芬用法，而这两块知识在知识库里是三个独立的条目。 单纯靠相似度检索，召回的永远是最像“感冒”的那几条，关联知识捞不出来。 这篇文章记录我为什么引

写在前面前几篇记录了智能旅行规划助手的后端接口、工具调用、多 Agent 协作和结构化输出。最后一步是前端可视化和线上部署。 一个 AI 项目如果只能在本地跑通，还不能算真正完成。只有部署到公网，让别人能访问、能填写表单、能生成结果，才更接近真实项目。 前端页面设计前端使用 Vue3，主要分成两个页面： 表单页：收集用户旅行需求 结果页：展示结构化旅行计划 表单页重点是让用户输入尽量结构化：

写在前面做 AI 应用时，模型能不能回答不是唯一问题，更重要的是：模型输出能不能被系统稳定消费。 在智能旅行规划助手里，前端需要展示每日行程、景点、餐饮、住宿、交通、预算等结构化内容。如果模型输出一段自然语言，前端就无法稳定渲染。 所以这一篇记录结构化输出解析和兜底机制。 为什么必须做结构化输出旅行计划的展示不是普通文本，而是多个模块： 行程概览 景点卡片 餐饮安排 酒店信息 交通方式 天气建议

写在前面智能旅行规划助手的核心不是简单调用一次模型，而是把复杂旅行规划任务拆成多个相对清晰的子任务。 如果让一个 Prompt 同时完成景点筛选、天气分析、酒店推荐、行程编排、预算估算和 JSON 输出，模型很容易顾此失彼。所以我把它拆成多 Agent 协作流程。 多 Agent 拆分思路项目里主要拆成四类 Agent： 1234景点搜索 Agent -> 天气分析 Agent ->

写在前面在旅行规划场景里，模型最容易出现的问题就是“编”。它可以生成很流畅的行程，但景点、地址、酒店、天气这些信息如果没有真实数据支撑，就很难让用户信任。 所以这个项目的第三步是接入高德地图 API，把外部工具返回的真实数据作为 LLM 的上下文输入。 为什么要接地图 API如果只依赖大模型，可能会出现这些情况： 景点名称不准确 地址不真实 景点之间距离不合理 酒店推荐没有依据 天气建议泛泛而谈

写在前面上一篇记录了智能旅行规划助手的需求拆解和整体架构。这一篇主要记录后端接口设计，重点是 FastAPI 和 Pydantic 在这个项目里的作用。 做 AI 应用时，很多人容易把注意力全部放在 Prompt 上，但实际开发中，接口和数据结构同样重要。因为前端、后端、工具 API、LLM 输出最终都要围绕一套稳定的数据格式协作。 为什么先设计 Schema如果后端只返回一段文本，前端展示会非常

写在前面最近完成了一个智能旅行规划助手项目。这个项目不是简单地调用一次大模型 API，然后把结果展示出来，而是尝试把一个真实的 AI 应用从需求拆解、外部工具接入、Agent 协作、结构化输出、前端展示到服务部署完整跑通。 这篇文章先记录第一阶段：我如何理解这个项目的需求，以及为什么最后选择了“FastAPI 后端 + LLM Agent + 高德地图工具 + Vue3 前端”的整体架构。 为什么

高山仰止，景行行止，虽不能至，心向往之

写在前面虽然我的主方向是 Java 后端，但做 AI 项目和博客后台时，经常需要写一点前端逻辑。JavaScript 的异步编程是绕不开的基础。 这篇文章记录 Promise 和 async/await 的基本理解。 PromisePromise 用来表示一个未来才会完成的操作。 1234567function fetchUser() { return new Promise