教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载导读本文围绕 easy-vibe 课程 Stage 2 的综合实战项目——「Custom Dify Agent Platform」展开。你将基于一份真实的产品需求文档PRD从需求分析、项目脚手架、模块化迭代开发到部署交付完整走通「创建智能体 → 配置 Prompt → 发起对话 → 查看调用日志 → 可选接入知识库」这条 AI 平台主链路。读完本文你将掌握如何借助 AI 辅助编码搭建一个包含用户控制台、后台管理台与平台后端的多角色 AI 产品并具备端到端联调与演示交付的能力。一、项目定位复刻 Dify 核心体验的最小可用智能体平台本项目是 easy-vibe Stage 2 的综合性实战环节。与之前单页面、单功能的小项目不同它要求你构建一个「平台型」AI 产品——涉及多角色、多模块、数据持久化和模型调用管线。项目的官方 PRD 定义如下仓库内文档位于 docs/zh-cn/stage-2/assignments/custom-dify-agent-platform/PRD.md做一个类 Dify 的最小可用智能体编排平台。关键点在于「最小可用」重点不是复刻 Dify 的全部能力而是跑通下面这条主链路创建智能体配置 Prompt 与模型参数发起对话查看调用日志可选接入知识库平台拆分为两个子系统子系统职责用户控制台User Console创建智能体、配置 Prompt、发起对话、查看日志、管理知识库后台管理台Admin Dashboard查看用户数据、平台资源使用情况、API 调用统计后端需要支撑智能体管理、会话管理、消息存储、模型调用、调用日志记录、知识库接入。二、前置知识要求开始本项目前你应该已经熟悉以下内容均在 easy-vibe Stage 2 课程中覆盖前端页面设计与组件库UI Design、Modern Component Libraries后端 API 设计与开发API Code with LLM Assistance数据库基础与 SupabaseDatabase to SupabaseGit 工作流与部署Git GitHub Workflow、Web App Deployment此外PRD 还建议参考 Dify 基础与知识库接入 一课来理解 RAG 与知识库集成的完整概念。三、学习目标完成本项目后你将能够阅读并理解一份真实 PRD从中提取开发任务清单为智能体平台设计页面架构与数据模型实现「智能体创建 → 对话 → 日志记录」的完整管线借助 AI 辅助构建平台型产品完成端到端集成交付一个可演示的 AI 平台原型。四、需求分析先读懂 PRD再动手写代码4.1 阅读 PRD 并回答关键问题打开 PRD 文档先回答这些问题再开工agents、sessions、logs、knowledge base 中哪些应进入 MVP页面与路由清单是否已经定稿模型调用与日志记录的边界在哪里多租户和复杂工作流是否应推迟⚠️ 警告如果上述问题没有清晰答案不要开始编码。需求不明确是返工最常见的根源。4.2 MVP 范围界定来自 PRDPRD 明确划定了第一版边界第一版必须包含注册/登录智能体 CRUD对话页会话历史调用日志页可选知识库仅支持文本文件上传与基础检索第一版不做复杂工作流节点编排 UI多租户企业权限体系工具调用沙箱支付与计费多模型路由策略4.3 角色与权限模型角色权限普通用户管理自己的智能体、发起对话、查看自己的日志管理员查看全平台用户和调用概览4.4 确认系统架构基于 PRD 梳理整体架构PRD 给出了更完整的系统总览官网前台www.xxx.com、用户控制台app.xxx.com、后台管理台admin.xxx.com三套入口都汇入统一的「应用 API / 管理 API」API 层再对接 Supabase Auth、Supabase Postgres、LLM Provider 与知识库/文档处理。4.5 技术选型建议PRD 推荐的技术栈前端框架Next.js App Router TypeScript Tailwind CSS shadcn/ui用户鉴权Supabase Auth数据库Supabase Postgres文件存储Supabase Storage模型层统一后端适配层对接第三方 LLMOpenAI 兼容接口后端可用 Node.js NestJS 或 Express这里与 Stage 2 的 Database to Supabase 课程一脉相承Supabase 提供开箱即用的注册登录、权限验证、文件上传存储能力能显著缩短从原型到可用产品的距离。五、项目脚手架用 AI 生成前端页面骨架5.1 生成前端页面的提示词参考Based on the current PRD, help me generate a frontend scaffold for a Dify-like agent platform. Requirements: 1. User side: login, agent list, agent configuration, conversation page, logs page, knowledge base page 2. Admin side: dashboard homepage, user overview, resource usage overview 3. Only generate page structure with mock data first, no real API integration 4. Style should look like a modern AI platform5.2 页面结构核验清单逐项检查脚手架产出用户控制台与后台管理台入口分离智能体列表、配置、对话、日志、知识库页面齐全后台管理台首页与用户概览页可访问Mock 数据展示出基本 UI 状态5.3 PRD 的三套入口与十个大页面PRD 将页面结构定义为「3 套入口10 个大页面」这是脚手架阶段的重要核对基准A. 官网前台www.xxx.com1 个页面www:/官网首页产品介绍、能力说明、使用场景、注册/登录 CTAB. 用户控制台app.xxx.com7 个页面app:/login登录页登录、注册入口、第三方登录app:/agents智能体列表页查看所有智能体、新建、编辑入口、状态筛选app:/agents/:id智能体配置页配置名称和描述、Prompt、模型、参数、启停和发布状态app:/chat对话页选择智能体、新建会话、聊天消息展示、问答发送与结果展示app:/chat/:id会话详情页查看完整消息历史、重命名会话、继续提问app:/knowledge知识库页上传文档、查看处理状态、关联到智能体app:/logs日志页查看调用日志、按状态/模型筛选、查看错误详情C. 后台管理台admin.xxx.com2 个页面admin:/后台首页用户数、调用次数、失败率、平台资源概览admin:/usage用户与调用概览页查看用户使用情况、模型调用消耗、异常用户和高成本调用核心前端组件建议智能体卡片列表、Agent 配置表单、对话消息列表、Prompt 调试面板、日志筛选表格、文件上传组件。六、迭代开发按模块渐进式实现在脚手架基础上按以下顺序逐模块添加功能认证Authentication注册、登录、角色区分智能体管理Agent Management创建、编辑、删除、Prompt 配置对话Conversation会话创建、消息交换、模型调用日志Logging延迟、token 用量、错误记录知识库Knowledge Base加分项文档上传、检索、结果注入后台管理台Admin Dashboard用户数据、资源使用、调用统计每个模块完成后使用以下自检表核对检查项验证方法页面一致性页面数量和功能是否符合 PRDAPI 完备性agents、chat、logs、knowledge API 是否齐全认证隔离用户是否只能管理自己的智能体会话数据一致性消息、日志、文档数据是否对齐演示就绪能否端到端演示「创建智能体 → 对话 → 查看日志」6.1 后端模块与接口草案PRD 建议后端拆分为auth、agents、chat、knowledge、logs、admin六大模块并给出了完整的接口草案方法路径说明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: 帮我总结一下这个功能的定位 }关于「用 LLM 编写 API 代码与文档」的完整方法论可参考 Using LLMs to Write API Code and API Documentation 一课它强调在让模型写 API 之前先提供数据库 Schema 与业务约束并要求模型分离 routes / controllers / services / middlewares 职责再借助模型自动生成 OpenAPI 文档与 Jest 测试、Postman 集合。6.2 数据模型设计六张核心表PRD 给出了可直接在 Supabase SQL Editor 中执行的建表建议字段设计是数据模型的关键产出物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 )设计要点agents.temperature使用numeric存储模型采样参数配置页需要支持编辑chat_messages.token_usage与run_logs.prompt_tokens / completion_tokens为日志统计token 用量、延迟提供数据基础run_logs.status建议枚举成功 / 错误 / 超时error_message必须记录失败原因knowledge_documents.chunk_count用于知识库文档分块处理结果的状态反馈。结合 Database to Supabase 课程的知识这里必须启用Row Level SecurityRLS核心业务规则是「用户只能访问自己的智能体、文档和会话」可以通过auth.uid()编写策略让agents.user_id、chat_sessions.user_id、run_logs.user_id与当前登录用户 ID 精确匹配在数据库层拦截越权访问。6.3 关键业务规则来自 PRD用户只能访问自己的智能体和会话删除智能体前需要检查是否有活跃会话日志中必须记录失败原因知识库文档处理失败要可见6.4 知识库集成加分项如果想加入知识库能力为每个智能体添加一个「知识库开关」开启时先检索知识片段再将片段与用户问题一起发给模型关闭时以普通对话模式回复。第一版不要追求复杂的 RAG只需保证「检索结果可见、调用链路可解释」。关于 RAG 的底层原理可参考 Dify Basics and Knowledge Base Integration 一课RAG 的核心思路是当用户提问时先从企业知识中检索语义最相关的文本块再将这些文本块注入模型上下文使答案基于真实来源材料生成。知识库设置中需要关注分块策略最大分块长度、分块重叠、Embedding 模型选择、Rerank 模型与 Top K / Score Threshold 等检索参数——这些参数直接决定检索质量。七、集成与上线7.1 端到端测试至少验证以下场景注册 → 创建智能体 → 配置 Prompt → 发起对话 → 查看日志管理员登录 → 查看用户数据 → 查看调用统计上线前检查清单所有核心 API 都需要登录验证智能体所有权权限校验通过对话和日志记录持久化到数据库模型 API Key 使用环境变量不硬编码错误信息在前端可见而不只在控制台关于「API Key 使用环境变量」这一点ai-interface-code 课程同样强调敏感凭据API keys、DB URLs应放在.env文件并通过process.env读取这也是模型调用适配层对接 LLM Provider的底线安全要求。7.2 部署将项目部署到公网环境。部署说明参见Git GitHub Workflow、Web App Deployment。参考 zeabur-deployment 课程PaaS 平台如 Zeabur、Vercel、Netlify能自动完成服务器购买、运行时配置、代码拉取、服务启动与可用性监控——对于本项目这类「前端 后端 数据库」组合直接连接 GitHub 仓库即可持续部署。PRD 中的站点入口约定官网前台 / 用户控制台 / 后台管理台可以映射为同一部署下的不同路由或子域名。八、交付物完成项目后提交以下内容可访问的线上演示链接源码仓库链接含 READMEPRD 文档核心页面截图智能体管理、对话、日志、后台管理台60 秒演示视频覆盖 创建智能体 → 对话 → 查看日志README 至少应包含项目概述、架构描述、技术栈、本地启动步骤、环境变量列表、API 文档。九、评分标准维度基础要求进阶要求平台完备性agents / chat / logs 页面可用有清晰导航和统一设计语言业务闭环能创建智能体并进行真实对话支持多智能体切换和会话历史数据与追踪消息和调用日志可查询有 token / 延迟统计仪表盘认证与安全只有登录用户可访问核心 API资源所有权校验健壮工程交付可部署、可演示、README 清晰接入知识库且检索可解释PRD 对后台指标与监控也有明确建议后台至少查看智能体总数、活跃用户数、日调用次数、平均响应耗时、模型调用失败率、知识库文档处理成功率、高消耗用户与高成本智能体监控项包括/api/chat平均耗时与错误率、模型供应商调用成功率、知识库文档处理队列状态、数据库连接和日志写入健康状态。十、提交前最终检查登录后智能体管理、对话、日志页面可访问至少 1 个智能体可创建并成功对话每一轮问答都能在数据库中找到记录调用失败时前端显示错误信息并被记录到日志项目已部署README 和演示视频完整十一、关键状态流与开发顺序备忘状态流设计PRD 定义智能体草稿 → 已配置 → 可用 / 停用会话新建 → 进行中 → 归档文档上传中 → 处理中 → 可检索 / 失败调用成功 / 错误 / 超时推荐开发顺序登录与基础鉴权智能体 CRUD对话页和会话存储日志记录文档上传与基础检索管理后台概览待确认项PRD 遗留问题可在方案评审时敲定第一版是否必须带知识库、模型供应商先只接 1 家还是预留多家、平台是否需要 Workspace 概念、日志是否保留完整 prompt 快照。参考链接UI DesignModern Component LibrariesDatabase to SupabaseAPI Code with LLM AssistanceGit GitHub WorkflowWeb App DeploymentDify Basics and Knowledge Base Integration项目 PRD赞分享教程文档【免费下载链接】easy-vibe从 0 到 1 学会 vibe coding项目制学习项目地址https://gitcode.com/datawhalechina/easy-vibe点击查看免费下载相关推荐类 Dify 智能体编排平台实战从 PRD 到可交付的 AI Agent 平台easy-vibe 第 2 阶段综合项目类 Dify 智能体编排平台实战从 PRD 到可交付的 AI Agent 平台easy vibe 第 2 阶段综合项目 本篇技术指南以 easy vibe教程文档人工智能Vibe Coding类 Dify 智能体平台开发实战基于 easy-vibe Stage 2 综合项目从 PRD 到可演示的 AI 平台原型类 Dify 智能体平台开发实战基于 easy vibe Stage 2 综合项目从 PRD 到可演示的 AI 平台原型 本文围绕 easy vibe 课程体教程文档人工智能Vibe Codingeasy-vibe 实战项目从 PRD 到上线用 AI 辅助构建类 Dify 智能体编排平台easy vibe 实战项目从 PRD 到上线用 AI 辅助构建类 Dify 智能体编排平台 本文是 Datawhale easy vibe 课程 Stag教程文档创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
