从 PRD 到上线：基于 easy-vibe 课程体系从零构建类 Dify 智能体编排平台

从 PRD 到上线基于 easy-vibe 课程体系从零构建类 Dify 智能体编排平台【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe导读本篇实战指南以 easy-vibe 课程 Stage 2 的综合项目「Plataforma de Agentes Inteligentes tipo Dify」为蓝本完整讲解如何围绕一份真实的 PRD从零构建一个复刻 Dify 核心体验的智能体平台包含用户控制台、管理后台与平台后端覆盖智能体管理、对话、调用日志、知识库接入等核心能力。读完本文你将掌握从需求分析、数据建模、前后端骨架生成、逐模块迭代到端到端联调上线的完整工程方法并学会借助 AI 辅助完成一个有平台感的多角色 AI 产品。1. 项目定位跑通一条可演示的主链路本项目来自 easy-vibe 课程 Stage 2 的扩展实战项目完整作业说明位于 custom-dify-agent-platform 作业文档其需求规格见仓库中的 PRD 原文状态Draft v0.1。与 Stage 2 之前的单页面或单功能项目不同本项目的核心目标是构建一个有平台感的 AI 产品重点不是复刻 Dify 的全部能力而是跑通下面这条主链路创建智能体Agent配置 Prompt 与模型参数发起对话查看调用日志可选接入知识库一句话定义做一个类 Dify 的最小可用智能体编排平台MVP。整个项目包含两个子系统子系统职责用户控制台app.xxx.com创建智能体、配置 Prompt、发起对话、查看日志、管理知识库管理后台admin.xxx.com查看用户数据、平台资源使用情况、调用统计后端需要支撑的核心能力包括智能体管理、会话管理、消息存储、模型调用、调用日志记录、知识库接入。2. 前置知识开工前需要掌握的能力栈PRD 和作业文档都明确要求在开始本实战前你应当已经掌握以下 Stage 2 前置章节的内容前端页面设计与组件库使用UI 设计、现代组件库后端接口设计与开发AI 辅助编写接口代码数据库基础与 Supabase从数据库到 SupabaseGit 工作流与部署Git 和 GitHub、部署 Web 应用2.1 为什么用 Supabase 做后端底座PRD 明确推荐技术选型为Next.js App Router Supabase Auth Supabase Postgres Supabase Storage模型层由统一后端适配层对接第三方 LLM。这套选型与前置章节 从数据库到 Supabase 完全衔接Supabase 是基于 PostgreSQL 的新一代 BaaS将数据库、认证Auth、对象存储Storage、实时同步Realtime和 Edge Functions 打包成开箱即用的服务让团队把有限资源集中在业务主链路上。其中两个关键机制会直接影响本项目的实现Row Level SecurityRLS通过auth.uid()编写行级安全策略实现用户只能访问自己的智能体和会话这一核心业务规则从数据库底层拦截越权访问。Auth 会话用户登录后Supabase 自动为后续所有请求附带认证信息配合 RLS 完成多用户数据隔离。2.2 用 LLM 写后端接口的正确姿势前置章节 AI 辅助编写接口代码 强调LLM 不怕复杂需求怕的是模糊需求。高质量 Prompt 必须包含数据库字段定义Schema与具体约束。例如为agents表编写创建接口时应像下面这样提供完整上下文帮我写一个创建智能体的 API。智能体有名称、描述、system_prompt、模型、温度参数和发布状态名称和模型必填温度取值范围 0~2用户输入不合法时要返回明确的错误信息。同时要遵循 RESTful 命名GET /api/agents、POST /api/agents而不是POST /api/getAgents、标准化 HTTP 状态码200/201/400/401/403/404/500并且永远不要信任前端输入关键参数校验必须在后端重新执行。3. 学习目标与四阶段推进路线完成本实战后你将能够阅读并理解一份真实的 PRD从中提取开发任务清单设计智能体平台的页面架构和数据模型实现智能体创建、对话、日志记录的完整链路使用 AI 辅助完成平台型产品开发完成端到端联调交付一个可演示的 AI 平台原型。整个项目按四个阶段推进每个阶段对应一个明确的产出4. 第一阶段需求分析 —— 先想清楚再动手作业文档给出了一条硬性警告如果对 PRD 的关键问题没有明确答案不要开始写代码——需求理解不清楚是导致返工的最常见原因。4.1 阅读 PRD 时要回答的问题打开 PRD 文档重点回答智能体、会话、日志、知识库哪些必须进入 MVP页面和路由清单是否已经拍板模型调用和日志记录的边界是什么多租户和复杂工作流是否第一版先不做仓库中的 PRD 对这些问题的答案是清晰的这也是本项目区别于边写边想式开发的关键MVP 必做注册/登录、智能体 CRUD、对话页、会话历史、调用日志页知识库仅支持文本文件上传与基础检索。第一版明确不做复杂工作流节点编排 UI、多租户企业权限体系、工具调用沙箱、支付与计费、多模型路由策略。4.2 确认系统架构根据 PRD 梳理出的系统总体架构如下4.3 角色与权限模型PRD 定义了两种角色权限边界非常清晰角色权限普通用户管理自己的智能体、发起对话、查看自己的日志管理员查看全平台用户和调用概览对应到数据层面profiles表中需要role字段来区分身份而只能管理自己的资源这条规则由 RLS 策略在数据库层兜底。4.4 页面与路由清单3 套入口、10 个大页面PRD 将前端定义为3 套入口、10 个大页面这是后续生成骨架时的直接依据A. 官网前台www.xxx.com页面路径核心功能官网首页/产品介绍、能力说明、使用场景、注册/登录 CTAB. 用户控制台app.xxx.com页面路径核心功能登录页/login登录、注册入口、第三方登录智能体列表页/agents查看所有智能体、新建、编辑入口、状态筛选智能体配置页/agents/:id配置名称与描述、Prompt、模型、参数、启停和发布状态对话页/chat选择智能体、新建会话、聊天消息展示、问答发送与结果展示会话详情页/chat/:id查看完整消息历史、重命名会话、继续提问知识库页/knowledge上传文档、查看处理状态、关联到智能体日志页/logs查看调用日志、按状态/模型筛选、查看错误详情C. 管理后台admin.xxx.com页面路径核心功能后台首页/用户数、调用次数、失败率、平台资源概览用户与调用概览页/usage用户使用情况、模型调用消耗、异常用户和高成本调用4.5 关键状态流在设计数据模型前先把业务状态机定清楚智能体草稿 → 已配置 → 可用 / 停用会话新建 → 进行中 → 归档文档上传中 → 处理中 → 可检索 / 失败调用成功 / 错误 / 超时5. 第二阶段搭建项目骨架 —— 用 AI 生成前后端结构5.1 生成前端页面的参考提示词作业文档给出了可以直接复用的提示词模板请基于当前 PRD帮我生成一个类 Dify 智能体平台的前端骨架。 要求 1. 用户侧包括登录、智能体列表、智能体配置、对话页、日志页、知识库页 2. 后台侧包括后台首页、用户概览、资源使用概览 3. 先只生成页面结构和假数据不接真实接口 4. 风格要像现代 AI 平台PRD 补充了推荐技术栈Next.js App Router TypeScript Tailwind CSS shadcn/ui并列出前端核心组件智能体卡片列表、Agent 配置表单、对话消息列表、Prompt 调试面板、日志筛选表格、文件上传组件。5.2 页面结构逐项验证骨架生成后不要急着写业务代码先按清单逐项检查用户控制台和管理后台入口是否分开智能体列表、配置、对话、日志、知识库页面是否完整管理后台首页、用户概览页面是否可访问假数据是否展示了基本的 UI 状态5.3 设计数据模型六张核心表PRD 直接给出了建议的 SQL 表结构这是整个后端的根基必须完整保留并理解每个字段的含义profiles ( id uuid primary key, email text, role text, created_at timestamptz ) agents ( id uuid primary key, user_id uuid, name text, description text, system_prompt text, model text, temperature numeric, status text, created_at timestamptz ) chat_sessions ( id uuid primary key, user_id uuid, agent_id uuid, title text, created_at timestamptz ) chat_messages ( id uuid primary key, session_id uuid, role text, content text, token_usage int, created_at timestamptz ) knowledge_documents ( id uuid primary key, user_id uuid, agent_id uuid, filename text, status text, chunk_count int, created_at timestamptz ) run_logs ( id uuid primary key, user_id uuid, agent_id uuid, session_id uuid, model text, latency_ms int, prompt_tokens int, completion_tokens int, status text, error_message text, created_at timestamptz )对照前置章节 从数据库到 Supabase 中的实践方法可以在 Supabase 的 SQL Editor 中执行这段 DDL然后在 Table Editor 中确认表结构每张业务表都应配套 RLS 策略例如agents.user_id auth.uid()并注意profiles表通过外键关联auth.users而authschema 下的表不建议手动修改。5.4 接口草案前后端联调的契约PRD 给出了完整的 REST 接口草案前后端应严格按此契约开发方法路径说明POST/api/auth/register注册POST/api/auth/login登录GET/api/agents获取当前用户的智能体列表POST/api/agents创建智能体PATCH/api/agents/:id更新智能体配置DELETE/api/agents/:id删除智能体POST/api/chat/sessions创建新会话POST/api/chat/sessions/:id/messages向某个会话发送消息GET/api/chat/sessions/:id/messages获取会话消息POST/api/knowledge/documents上传知识库文档GET/api/logs获取调用日志GET/api/admin/overview平台总览其中POST /api/chat/sessions/:id/messages的请求示例为{ agentId: agent_123, message: 帮我总结一下这个功能的定位 }6. 第三阶段迭代开发 —— 逐模块推进业务闭环在骨架基础上按以下顺序逐模块补充功能每完成一个模块就用自检表验证一次鉴权注册、登录、角色区分智能体管理创建、编辑、删除、Prompt 配置对话功能会话创建、消息收发、模型调用日志记录耗时、token 用量、错误记录知识库接入加分项文档上传、检索、结果注入管理后台用户数据、资源使用、调用统计6.1 模块自检表检查项验证方法页面一致性页面数量、功能是否符合 PRD接口闭环agents、chat、logs、knowledge 接口是否完整权限隔离用户是否只能管理自己的 agent 和会话数据一致性messages、logs、documents 数据是否对得上可演示性是否能演示创建 agent → 对话 → 查看日志完整链路6.2 对话链路的实现要点对话功能是整条主链路的枢纽前端将消息写入chat_messages后端调用模型供应商将耗时、token 用量、状态写入run_logs再返回流式或完整回答。实现时建议把模型调用适配层做成独立模块PRD 的技术选型即统一后端适配层对接第三方 LLM这样未来接入多家模型供应商时只需替换适配层而不用改动会话与日志逻辑。模型 Key 必须通过环境变量注入禁止硬编码。6.3 知识库接入加分项知识库开关模式作业文档给出了一个务实的 MVP 方案——为每个智能体增加一个知识库开关开启时先检索知识片段再将检索结果与用户问题一起发送给模型关闭时按普通对话模式响应。第一版不必追求复杂 RAG只要做到检索结果可见、调用链路可解释即可。knowledge_documents表中的chunk_count、status字段用于跟踪文档切分与处理进度若想深入了解检索增强的原理与落地形态可参考本仓库的 Dify 知识库章节 Dify 与知识库接入其中讲解了 Embedding、Rerank、Top-K 与 Score Threshold 等检索参数的作用。6.4 关键业务规则PRD 第 9 节明确了四条必须遵守的业务规则它们是验收的核心依据用户只能访问自己的智能体和会话RLS 后端双重校验删除智能体前需要检查是否有活跃会话日志中必须记录失败原因run_logs.error_message不可为空知识库文档处理失败要可见前端展示处理状态。7. 第四阶段联调与上线7.1 端到端测试场景至少验证以下两条主链路注册 → 创建智能体 → 配置 Prompt → 发起对话 → 查看日志管理员登录 → 查看用户数据 → 查看调用统计7.2 部署前检查清单所有核心接口都做了登录校验智能体归属权限检查通过会话记录、日志记录真实落库模型 Key 使用环境变量不硬编码错误提示可在前端看到不只打在控制台7.3 部署将项目部署到公网环境部署流程参考仓库中的 Git 和 GitHub 工作流 与 如何部署 Web 应用Zeabur。部署完成后需要验证线上环境的三件事登录后可访问核心页面、创建智能体能成功对话、每轮问答都能在数据库查到记录。8. 交付物与 README 要求完成项目后需要提交可访问的线上演示链接源码仓库链接含 READMEPRD 文档核心页面截图智能体管理页、对话页、日志页、后台首页60 秒演示视频覆盖创建智能体 → 对话 → 查看日志README 至少包含项目简介、架构说明、技术栈、本地启动步骤、环境变量清单、接口说明。9. 评分标准从能用到有平台感维度基本要求进阶要求平台完整度agents / chat / logs 三页可用有清晰导航与统一设计语言业务闭环可创建智能体并真实对话支持多智能体切换与历史会话数据与追踪消息与调用日志可查询有 token / 耗时统计看板权限安全仅登录用户可访问核心接口资源归属校验完善工程交付可部署、可演示、README 清晰接入知识库并可解释检索结果9.1 提交前最终检查登录后可访问智能体管理、对话、日志页面至少可以创建 1 个智能体并成功对话每轮问答都能在数据库查到记录调用失败时前端可见错误信息且日志已记录项目已部署README 和演示视频齐全10. 结语这个项目练的是什么这个类 Dify 平台项目与单页面项目最大的区别在于平台感多角色用户/管理员、多模块agents/chat/logs/knowledge/admin、数据持久化、模型调用链路四者交织成一个完整的全栈闭环。它把 easy-vibe 课程 Stage 2 的前置知识点——组件库、Supabase、接口开发、Git 工作流、云部署——全部串联起来。建议严格按照需求分析 → 骨架 → 迭代 → 联调四个阶段推进每个模块用自检表验证后再进入下一个最后以评分标准作为验收尺度交付一个可演示、可部署、可讲清楚的 AI 平台原型。参考资料custom-dify-agent-platform 作业文档类 Dify 智能体编排平台 PRDUI 设计现代组件库从数据库到 SupabaseAI 辅助编写接口代码Git 和 GitHub 工作流部署 Web 应用ZeaburDify 与知识库接入【免费下载链接】easy-vibe vibe coding 101The first course for AI-native product builders.项目地址: https://gitcode.com/GitHub_Trending/ea/easy-vibe创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考