easy-vibe 实战智能旅游规划 Agent 平台全栈开发指南——从 PRD 拆解到可演示 AI 产品落地【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe本指南以 easy-vibe 课程 Stage 2 综合实战项目「智能旅游规划 Agent 平台」为核心围绕仓库中的真实 PRDdocs/zh-cn/stage-2/assignments/travel-planning-agent-platform/PRD.md完整讲解从需求分析、数据建模、前后端开发、Agent 编排到部署演示的全流程。读完本文你将掌握如何把一个 AI 想法拆解为「结构化输入 → Agent 编排 → 结构化输出 → 保存复用」的可运行产品并了解每步的提示词写法、接口设计与验收标准。项目定位与核心挑战本项目要求围绕一份真实的 PRD从零构建一个智能旅游规划 Agent 平台接收用户的结构化输入出发地、目的地、日期、预算、偏好生成每日行程并支持保存与重新生成。它不是聊天机器人而是一个具备任务管理能力的 AI 产品——这是 Stage 2 的综合实战环节。项目的核心挑战在于如何让 AI 生成结构化、可用的行程规划而不是一大段不可操作的文字。PRD 对此给出了明确要求第 9 节「关键业务规则」第一版只支持单目的地行程天数限制在 3 到 7 天预算必须同时返回总预算与每日预算失败任务必须可重试生成结果必须是结构化 JSON不能只返回自由文本。一句话定义 PRD 中的产品做一个可以生成、保存、调整与导出旅行计划的 Agent 编排平台。前置知识路径与技术选型动手前应先掌握 easy-vibe Stage 2 的前置课程它们分别对应本项目的六大技术切片前置知识对应课程仓库内路径在本项目中的作用前端页面设计与组件库UI 设计、现代组件库规划页、详情页等页面视觉与组件实现后端接口设计大模型辅助编写接口代码Agent 编排层与 RESTful API 的编写数据库与 BaaS从数据库到 Supabase建表、Supabase Auth、RLS 安全策略Git 工作流与部署Git 和 GitHub、部署 Web 应用版本管理与线上发布PRD 第 1.0 节给出了建议的技术选型前端框架Next.js App Router用户鉴权Supabase Auth数据库Supabase Postgres模型层统一后端服务调用大模型避免前端直接暴露 API Key可参考 ai-interface-code 中「Edge Functions 作为安全中间层」的思路可选缓存Redis站点入口约定为三套子域名官网前台www.xxx.com、用户工作台app.xxx.com、后台管理台admin.xxx.com。前后端推荐技术栈还包括 TypeScript Tailwind CSS前端以及 Node.js NestJS/Express后端。第一步需求分析——从 PRD 提取开发任务清单在写任何代码之前先通读 PRD 并回答四个关键问题第一版是否只做单目的地答案是肯定的详见「关键业务规则」行程输出是否必须结构化结构是什么必须trip_plans / itinerary_days / itinerary_items三层结构导出能力做多深MVP 先做文本/PDF 占位能力后台统计和任务日志的范围是什么热门目的地、任务成功率、失败任务数、用户反馈原作业指南给出明确警告如果以上问题没有明确答案不要开始写代码需求理解不清楚是导致返工的最常见原因。这一环节正是阅读 PRD 并从中提取开发任务清单的学习目标。MVP 范围界定PRD 第 3 节明确划分了第一版的边界第一版必须包含规划表单页、行程详情页、历史计划页、计划保存与重生成、预算拆分、导出文本/PDF 占位能力、后台查看任务与失败日志。第一版不做真正的机票/酒店预订、多城市复杂路线联排、实时票价与库存同步、多人协同编辑、多语言输出。角色与权限角色权限普通用户创建计划、查看历史、导出、反馈管理员查看热门目的地、失败任务、用户反馈确认系统架构数据模型设计五张核心表PRD 第 6 节给出了完整的建表 SQL这是全项目的数据地基务必在 Supabase 的 SQL Editor 中完整执行建表方式可参考 database-supabase 中「让 LLM 生成 init.sql 并在 SQL Editor 执行」的 SOPtrip_plans ( id uuid primary key, user_id uuid, origin text, destination text, start_date date, end_date date, budget numeric, preferences jsonb, pace text, status text, created_at timestamptz ) itinerary_days ( id uuid primary key, trip_plan_id uuid, day_index int, title text, summary text, day_budget numeric ) itinerary_items ( id uuid primary key, itinerary_day_id uuid, start_time text, end_time text, place_name text, category text, notes text, estimated_cost numeric ) planner_runs ( id uuid primary key, trip_plan_id uuid, provider text, latency_ms int, status text, error_message text, created_at timestamptz ) trip_feedback ( id uuid primary key, trip_plan_id uuid, user_id uuid, score int, comment text, created_at timestamptz )从表结构可以看出设计意图trip_plans是行程主表preferences使用jsonb存储不定长的偏好数组如[美食, 历史文化]pace记录节奏如standard这正对应 database-supabase 中JSON 适合结构复杂、层级明显、字段不固定的数据的讲解itinerary_days按天与itinerary_items按时间段/地点通过外键形成trip_plans → itinerary_days → itinerary_items的三层嵌套确保行程按天展示的界面结构有稳定的数据来源planner_runs记录每次生成任务的 provider、耗时、状态与错误信息是后台失败任务可追溯与监控指标平均生成耗时、任务成功率的数据基础trip_feedback支撑反馈评分分布与未处理 → 已查看 → 已关闭的反馈状态流。上线前务必为这些表配置Row Level SecurityRLS策略例如仅当trip_plans.user_id与当前登录用户auth.uid()匹配时才可查询这是 Supabase 课程中强调的用户只能看到自己的数据的核心安全机制service_role密钥只允许放在服务端。第二步搭建前端骨架页面架构总览3 套入口、8 个大页面PRD 第 5.1 节将页面定义为「3 套入口8 个大页面」A. 官网前台www.xxx.com官网首页www:/产品介绍、典型使用场景、Demo 行程展示、CTA。B. 用户工作台app.xxx.com登录页app:/login登录 注册入口用 Supabase Auth 的signUp/signInWithPassword实现见 database-supabase 项目 2规划页app:/planner输入旅行需求、选择偏好与预算、发起规划任务行程详情页app:/trips/:id查看每日行程、查看预算拆分、再次生成和导出历史计划页app:/history查看历史计划、重新打开、重新生成反馈与导出页app:/exports导出计划、提交反馈。C. 后台管理台admin.xxx.com后台首页admin:/热门目的地、任务成功率、失败任务数任务与反馈页admin:/runs查看失败任务、查看用户反馈、排查异常计划。关键用户链路与状态流三条关键状态流必须在全栈中贯通规划任务待生成 → 生成中 → 成功 / 失败行程草稿 → 已保存 → 已导出反馈未处理 → 已查看 → 已关闭用 AI 生成前端骨架的提示词原作业指南提供了可直接复用的提示词参考注意它刻意限定只生成页面结构和假数据不接真实接口以便先跑通视觉与交互骨架请基于当前 PRD帮我生成一个智能旅游规划 Agent 平台的前端骨架。 要求 1. 页面包括首页、规划页、行程详情页、历史记录页、管理页 2. 规划页左侧是表单右侧是结果预览 3. 先只生成页面结构和假数据不接真实接口 4. 风格要像现代 AI 产品PRD 推荐的前端关键组件包括旅行需求表单、任务进度状态条、Day by Day 行程卡片、预算拆分卡片、历史记录列表、错误重试与反馈组件。验证页面结构自检清单生成骨架后逐项验证规划页的表单字段是否与 PRD 一致出发地、目的地、日期、预算、偏好、节奏结果预览区域能展示结构化的行程数据而非一段文字历史记录页可以展示多条计划管理后台页可以展示统计数据第三步迭代开发——Agent 编排层与业务闭环按模块推进的七个步骤原作业指南建议严格按以下模块顺序迭代每个模块完成后自检再进入下一个鉴权注册、登录规划表单结构化输入出发地、目的地、日期、预算、偏好Agent 编排接收输入 → 调用模型 → 解析结构化输出结果展示行程按天展示、预算拆分、建议历史管理保存计划、再次生成、导出管理后台热门目的地、失败任务、用户反馈任务状态生成中 / 成功 / 失败的状态管理和错误记录。其中Agent 编排层是项目的技术核心它接收前端提交的表单统一由后端调用 LLM避免密钥暴露解析模型返回的 JSON 为trip_plans / itinerary_days / itinerary_items三层结构并落库。PRD 强调规划结果要有稳定的结构化 JSON因此在提示词中应要求模型严格输出符合字段约束的 JSON可用 function calling / 结构化输出特性约束 Schema并在服务端做解析校验解析失败则记录到planner_runs.error_message。接口草案8 个 APIPRD 第 8 节给出了完整的接口清单可直接作为后端开发的任务清单方法路径说明POST/api/trips/plan创建新的规划任务GET/api/trips/:id获取计划详情POST/api/trips/:id/regenerate按原条件重新生成PATCH/api/trips/:id/preferences更新偏好后重算GET/api/history获取历史计划列表POST/api/trips/:id/export导出行程POST/api/trips/:id/feedback提交用户反馈GET/api/admin/planner-runs获取生成日志POST /api/trips/plan的请求示例与规划表单字段一一对应{ origin: 上海, destination: 成都, startDate: 2026-05-01, endDate: 2026-05-04, budget: 3500, preferences: [美食, 历史文化], pace: standard }编写这些接口时可参考 ai-interface-code 中的最佳实践RESTful 命名URL 表示资源、动作交给 HTTP 方法、标准状态码201 创建成功 / 400 参数错误 / 401-403 未认证或越权 / 404 资源不存在 / 500 服务端错误、绝不信任前端输入后端必须重新校验参数如日期区间、预算数值、天数限制并让 LLM 自动生成 OpenAPI/Swagger 文档与 Postman 测试集合。模块自检检查项验证方法输入完整性表单字段是否与 PRD 一致输出结构化行程结果是不是结构化数据而非一大段文字数据一致性trip、itinerary、logs 数据是否对得上闭环验证是否能演示输入 → 生成 → 保存 → 再次生成后台指标与监控PRD 第 6.1 节要求后台至少展示六项指标日规划任务数、规划成功率、平均生成耗时、热门目的地排行、用户反馈评分分布、导出次数。基础监控建议覆盖模型调用成功率、外部信息源失败率天气/地图/POI 等外部源失败时要优雅降级这是 PRD 第 10 节的非功能要求之一、任务重试次数、数据库存取耗时。这些监控项大多可直接从planner_runs表聚合得到这也是该表存在的价值。第四步端到端联调与上线至少验证三个端到端场景输入行程参数 → 生成每日行程 → 查看预算拆分 → 保存到历史从历史记录中再次生成行程复用POST /api/trips/:id/regenerate管理员查看任务统计和失败日志GET /api/admin/planner-runs。联调通过后使用 zeabur-deployment 中讲解的 PaaS 一键部署方式连接 GitHub 仓库、自动识别 Next.js/Node.js 应用、获得公网地址或参考该课程中对 Vercel / CloudBase 等平台的对比选择适合的方案发布上线Git 协作与版本管理则遵循 git-workflow。PRD 给出的开发顺序建议为规划页表单与 mock 结果 → 创建计划与详情接口 → 历史记录与重生成 → 导出与反馈 → 管理后台日志页。交付物清单完成项目后需要提交可访问的线上演示链接源码仓库链接含 READMEPRD 文档核心页面截图规划页、行程详情页、历史记录页、管理后台60 秒演示视频评分标准维度基本要求进阶要求PRD 对齐页面、功能、数据结构基本符合 PRD能清晰说明设计决策产品闭环规划 → 保存 → 历史 → 重生成可跑通支持导出和分享输出质量行程结果结构化且可读预算拆分合理、建议有针对性后台能力任务统计和失败日志可查看有热门目的地分析工程完整度前端、后端、数据库、模型调用链路已接通任务状态管理完善错误可追溯参考资料UI 设计使用现代组件库更新你的界面从数据库到 Supabase大模型辅助编写接口代码与接口文档Git 和 GitHub 工作流如何部署 Web 应用项目完整 PRD【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 easy-vibe 实战：智能旅游规划 Agent 平台全栈开发指南——从 PRD 拆解到可演示 AI 产品落地
easy-vibe 实战智能旅游规划 Agent 平台全栈开发指南——从 PRD 拆解到可演示 AI 产品落地【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe本指南以 easy-vibe 课程 Stage 2 综合实战项目「智能旅游规划 Agent 平台」为核心围绕仓库中的真实 PRDdocs/zh-cn/stage-2/assignments/travel-planning-agent-platform/PRD.md完整讲解从需求分析、数据建模、前后端开发、Agent 编排到部署演示的全流程。读完本文你将掌握如何把一个 AI 想法拆解为「结构化输入 → Agent 编排 → 结构化输出 → 保存复用」的可运行产品并了解每步的提示词写法、接口设计与验收标准。项目定位与核心挑战本项目要求围绕一份真实的 PRD从零构建一个智能旅游规划 Agent 平台接收用户的结构化输入出发地、目的地、日期、预算、偏好生成每日行程并支持保存与重新生成。它不是聊天机器人而是一个具备任务管理能力的 AI 产品——这是 Stage 2 的综合实战环节。项目的核心挑战在于如何让 AI 生成结构化、可用的行程规划而不是一大段不可操作的文字。PRD 对此给出了明确要求第 9 节「关键业务规则」第一版只支持单目的地行程天数限制在 3 到 7 天预算必须同时返回总预算与每日预算失败任务必须可重试生成结果必须是结构化 JSON不能只返回自由文本。一句话定义 PRD 中的产品做一个可以生成、保存、调整与导出旅行计划的 Agent 编排平台。前置知识路径与技术选型动手前应先掌握 easy-vibe Stage 2 的前置课程它们分别对应本项目的六大技术切片前置知识对应课程仓库内路径在本项目中的作用前端页面设计与组件库UI 设计、现代组件库规划页、详情页等页面视觉与组件实现后端接口设计大模型辅助编写接口代码Agent 编排层与 RESTful API 的编写数据库与 BaaS从数据库到 Supabase建表、Supabase Auth、RLS 安全策略Git 工作流与部署Git 和 GitHub、部署 Web 应用版本管理与线上发布PRD 第 1.0 节给出了建议的技术选型前端框架Next.js App Router用户鉴权Supabase Auth数据库Supabase Postgres模型层统一后端服务调用大模型避免前端直接暴露 API Key可参考 ai-interface-code 中「Edge Functions 作为安全中间层」的思路可选缓存Redis站点入口约定为三套子域名官网前台www.xxx.com、用户工作台app.xxx.com、后台管理台admin.xxx.com。前后端推荐技术栈还包括 TypeScript Tailwind CSS前端以及 Node.js NestJS/Express后端。第一步需求分析——从 PRD 提取开发任务清单在写任何代码之前先通读 PRD 并回答四个关键问题第一版是否只做单目的地答案是肯定的详见「关键业务规则」行程输出是否必须结构化结构是什么必须trip_plans / itinerary_days / itinerary_items三层结构导出能力做多深MVP 先做文本/PDF 占位能力后台统计和任务日志的范围是什么热门目的地、任务成功率、失败任务数、用户反馈原作业指南给出明确警告如果以上问题没有明确答案不要开始写代码需求理解不清楚是导致返工的最常见原因。这一环节正是阅读 PRD 并从中提取开发任务清单的学习目标。MVP 范围界定PRD 第 3 节明确划分了第一版的边界第一版必须包含规划表单页、行程详情页、历史计划页、计划保存与重生成、预算拆分、导出文本/PDF 占位能力、后台查看任务与失败日志。第一版不做真正的机票/酒店预订、多城市复杂路线联排、实时票价与库存同步、多人协同编辑、多语言输出。角色与权限角色权限普通用户创建计划、查看历史、导出、反馈管理员查看热门目的地、失败任务、用户反馈确认系统架构数据模型设计五张核心表PRD 第 6 节给出了完整的建表 SQL这是全项目的数据地基务必在 Supabase 的 SQL Editor 中完整执行建表方式可参考 database-supabase 中「让 LLM 生成 init.sql 并在 SQL Editor 执行」的 SOPtrip_plans ( id uuid primary key, user_id uuid, origin text, destination text, start_date date, end_date date, budget numeric, preferences jsonb, pace text, status text, created_at timestamptz ) itinerary_days ( id uuid primary key, trip_plan_id uuid, day_index int, title text, summary text, day_budget numeric ) itinerary_items ( id uuid primary key, itinerary_day_id uuid, start_time text, end_time text, place_name text, category text, notes text, estimated_cost numeric ) planner_runs ( id uuid primary key, trip_plan_id uuid, provider text, latency_ms int, status text, error_message text, created_at timestamptz ) trip_feedback ( id uuid primary key, trip_plan_id uuid, user_id uuid, score int, comment text, created_at timestamptz )从表结构可以看出设计意图trip_plans是行程主表preferences使用jsonb存储不定长的偏好数组如[美食, 历史文化]pace记录节奏如standard这正对应 database-supabase 中JSON 适合结构复杂、层级明显、字段不固定的数据的讲解itinerary_days按天与itinerary_items按时间段/地点通过外键形成trip_plans → itinerary_days → itinerary_items的三层嵌套确保行程按天展示的界面结构有稳定的数据来源planner_runs记录每次生成任务的 provider、耗时、状态与错误信息是后台失败任务可追溯与监控指标平均生成耗时、任务成功率的数据基础trip_feedback支撑反馈评分分布与未处理 → 已查看 → 已关闭的反馈状态流。上线前务必为这些表配置Row Level SecurityRLS策略例如仅当trip_plans.user_id与当前登录用户auth.uid()匹配时才可查询这是 Supabase 课程中强调的用户只能看到自己的数据的核心安全机制service_role密钥只允许放在服务端。第二步搭建前端骨架页面架构总览3 套入口、8 个大页面PRD 第 5.1 节将页面定义为「3 套入口8 个大页面」A. 官网前台www.xxx.com官网首页www:/产品介绍、典型使用场景、Demo 行程展示、CTA。B. 用户工作台app.xxx.com登录页app:/login登录 注册入口用 Supabase Auth 的signUp/signInWithPassword实现见 database-supabase 项目 2规划页app:/planner输入旅行需求、选择偏好与预算、发起规划任务行程详情页app:/trips/:id查看每日行程、查看预算拆分、再次生成和导出历史计划页app:/history查看历史计划、重新打开、重新生成反馈与导出页app:/exports导出计划、提交反馈。C. 后台管理台admin.xxx.com后台首页admin:/热门目的地、任务成功率、失败任务数任务与反馈页admin:/runs查看失败任务、查看用户反馈、排查异常计划。关键用户链路与状态流三条关键状态流必须在全栈中贯通规划任务待生成 → 生成中 → 成功 / 失败行程草稿 → 已保存 → 已导出反馈未处理 → 已查看 → 已关闭用 AI 生成前端骨架的提示词原作业指南提供了可直接复用的提示词参考注意它刻意限定只生成页面结构和假数据不接真实接口以便先跑通视觉与交互骨架请基于当前 PRD帮我生成一个智能旅游规划 Agent 平台的前端骨架。 要求 1. 页面包括首页、规划页、行程详情页、历史记录页、管理页 2. 规划页左侧是表单右侧是结果预览 3. 先只生成页面结构和假数据不接真实接口 4. 风格要像现代 AI 产品PRD 推荐的前端关键组件包括旅行需求表单、任务进度状态条、Day by Day 行程卡片、预算拆分卡片、历史记录列表、错误重试与反馈组件。验证页面结构自检清单生成骨架后逐项验证规划页的表单字段是否与 PRD 一致出发地、目的地、日期、预算、偏好、节奏结果预览区域能展示结构化的行程数据而非一段文字历史记录页可以展示多条计划管理后台页可以展示统计数据第三步迭代开发——Agent 编排层与业务闭环按模块推进的七个步骤原作业指南建议严格按以下模块顺序迭代每个模块完成后自检再进入下一个鉴权注册、登录规划表单结构化输入出发地、目的地、日期、预算、偏好Agent 编排接收输入 → 调用模型 → 解析结构化输出结果展示行程按天展示、预算拆分、建议历史管理保存计划、再次生成、导出管理后台热门目的地、失败任务、用户反馈任务状态生成中 / 成功 / 失败的状态管理和错误记录。其中Agent 编排层是项目的技术核心它接收前端提交的表单统一由后端调用 LLM避免密钥暴露解析模型返回的 JSON 为trip_plans / itinerary_days / itinerary_items三层结构并落库。PRD 强调规划结果要有稳定的结构化 JSON因此在提示词中应要求模型严格输出符合字段约束的 JSON可用 function calling / 结构化输出特性约束 Schema并在服务端做解析校验解析失败则记录到planner_runs.error_message。接口草案8 个 APIPRD 第 8 节给出了完整的接口清单可直接作为后端开发的任务清单方法路径说明POST/api/trips/plan创建新的规划任务GET/api/trips/:id获取计划详情POST/api/trips/:id/regenerate按原条件重新生成PATCH/api/trips/:id/preferences更新偏好后重算GET/api/history获取历史计划列表POST/api/trips/:id/export导出行程POST/api/trips/:id/feedback提交用户反馈GET/api/admin/planner-runs获取生成日志POST /api/trips/plan的请求示例与规划表单字段一一对应{ origin: 上海, destination: 成都, startDate: 2026-05-01, endDate: 2026-05-04, budget: 3500, preferences: [美食, 历史文化], pace: standard }编写这些接口时可参考 ai-interface-code 中的最佳实践RESTful 命名URL 表示资源、动作交给 HTTP 方法、标准状态码201 创建成功 / 400 参数错误 / 401-403 未认证或越权 / 404 资源不存在 / 500 服务端错误、绝不信任前端输入后端必须重新校验参数如日期区间、预算数值、天数限制并让 LLM 自动生成 OpenAPI/Swagger 文档与 Postman 测试集合。模块自检检查项验证方法输入完整性表单字段是否与 PRD 一致输出结构化行程结果是不是结构化数据而非一大段文字数据一致性trip、itinerary、logs 数据是否对得上闭环验证是否能演示输入 → 生成 → 保存 → 再次生成后台指标与监控PRD 第 6.1 节要求后台至少展示六项指标日规划任务数、规划成功率、平均生成耗时、热门目的地排行、用户反馈评分分布、导出次数。基础监控建议覆盖模型调用成功率、外部信息源失败率天气/地图/POI 等外部源失败时要优雅降级这是 PRD 第 10 节的非功能要求之一、任务重试次数、数据库存取耗时。这些监控项大多可直接从planner_runs表聚合得到这也是该表存在的价值。第四步端到端联调与上线至少验证三个端到端场景输入行程参数 → 生成每日行程 → 查看预算拆分 → 保存到历史从历史记录中再次生成行程复用POST /api/trips/:id/regenerate管理员查看任务统计和失败日志GET /api/admin/planner-runs。联调通过后使用 zeabur-deployment 中讲解的 PaaS 一键部署方式连接 GitHub 仓库、自动识别 Next.js/Node.js 应用、获得公网地址或参考该课程中对 Vercel / CloudBase 等平台的对比选择适合的方案发布上线Git 协作与版本管理则遵循 git-workflow。PRD 给出的开发顺序建议为规划页表单与 mock 结果 → 创建计划与详情接口 → 历史记录与重生成 → 导出与反馈 → 管理后台日志页。交付物清单完成项目后需要提交可访问的线上演示链接源码仓库链接含 READMEPRD 文档核心页面截图规划页、行程详情页、历史记录页、管理后台60 秒演示视频评分标准维度基本要求进阶要求PRD 对齐页面、功能、数据结构基本符合 PRD能清晰说明设计决策产品闭环规划 → 保存 → 历史 → 重生成可跑通支持导出和分享输出质量行程结果结构化且可读预算拆分合理、建议有针对性后台能力任务统计和失败日志可查看有热门目的地分析工程完整度前端、后端、数据库、模型调用链路已接通任务状态管理完善错误可追溯参考资料UI 设计使用现代组件库更新你的界面从数据库到 Supabase大模型辅助编写接口代码与接口文档Git 和 GitHub 工作流如何部署 Web 应用项目完整 PRD【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考