Dify实战指南:从零构建企业级AI应用的完整教程
在AI应用开发领域,你是否也曾面临这样的困境:想法很多,但受限于复杂的模型部署、繁琐的API对接和前后端开发,一个简单的AI应用从构思到上线却要耗费数周时间?传统的开发流程将大量精力消耗在环境搭建和工程化上,而非核心的业务逻辑与AI能力本身。
Dify的出现,正是为了解决这一痛点。它作为一个开源的LLM应用开发平台,将大模型能力封装成可视化的“乐高积木”,让开发者、产品经理甚至业务人员都能通过拖拽和配置,快速构建、部署和运营基于大语言模型的AI应用。无论是智能客服、内容创作助手、数据分析工具还是复杂的多步骤工作流,Dify都提供了从原型到生产的完整解决方案。
本文将以2026年的技术视角,为你带来一套超浓缩的Dify实战指南。我们不谈空洞的理论,直接切入30+个企业级项目的核心场景,手把手带你从零搭建,覆盖安装部署、工作流设计、高级功能集成到生产运维的全链路。无论你是想快速验证AI创意的创业者,还是需要将AI能力集成到现有系统的开发者,都能在这里找到可复用的“配方”,用一周时间,系统掌握Dify的实战精髓,避开前人踩过的99%的坑。
1. Dify核心概念与架构解析
在动手之前,深入理解Dify的设计哲学和核心组件,是高效使用它的关键。这能帮助你在后续面对复杂需求时,做出正确的技术选型和架构设计。
1.1 Dify是什么?解决什么问题?
Dify并非另一个大模型,而是一个“AI应用操作系统”。它的核心价值在于降低AI应用开发门槛和提升开发运维效率。
传统AI应用开发流程:
- 选择模型(如GPT-4、Claude、本地模型)。
- 编写代码调用模型API,处理鉴权、流式输出、错误重试。
- 设计提示词(Prompt),反复调试以获得稳定输出。
- 构建前后端界面,处理会话状态、文件上传、知识库检索。
- 部署服务,配置监控、日志、扩展性。 这个过程涉及全栈技能,迭代缓慢。
基于Dify的开发流程:
- 在Dify界面选择或接入模型。
- 使用可视化编排器设计应用逻辑(对话或工作流)。
- 配置提示词、知识库、工具(函数调用)等能力。
- 一键发布,获得可立即使用的Web应用或API。 Dify将上述2-5步标准化、可视化,让开发者聚焦于业务逻辑和提示词工程。
1.2 核心架构与组件
Dify的架构清晰区分了控制面与数据面,理解其组件有助于后续的部署和问题排查。
- 前端 (Frontend):基于React的管理控制台和AI应用播放器。提供可视化编排、应用管理、日志查看等功能。
- 后端 (Backend):基于Python (FastAPI) 的核心API服务。负责处理所有业务逻辑,包括工作流执行、知识库处理、模型调用代理等。
- 工作流引擎 (Workflow Engine):Dify的灵魂。一个基于DAG(有向无环图)的可视化编排系统,每个节点代表一个处理步骤(如LLM调用、代码执行、条件判断)。
- 模型推理网关 (Model Inference Gateway):统一对接各类大模型API(OpenAI、Anthropic、国内厂商、本地模型如Ollama),提供负载均衡、限流、缓存等能力。
- 向量数据库 (Vector Database):默认集成Milvus、PGVector等,用于存储和检索知识库文档的嵌入向量,实现基于语义的精准问答。
- 任务队列 (Celery):处理异步任务,如知识库文档的索引生成、长时间运行的工作流。
- 关系型数据库 (PostgreSQL):存储应用配置、用户数据、会话记录等元数据。
- 对象存储 (S3/MinIO):存储上传的文件、生成的图片等。
一个典型的请求流程是:用户从前端发起请求 → 后端API接收 → 工作流引擎按DAG执行节点 → 通过模型网关调用LLM或工具 → 结合知识库检索结果 → 返回响应给前端。
2. 环境准备与多种部署方案实战
“工欲善其事,必先利其器”。Dify支持从最简单的本地体验,到高可用的生产级部署。我们将详细介绍三种主流方案。
2.1 方案一:本地快速启动(适合开发测试)
这是最快体验Dify的方式,使用Docker Compose一键拉起所有服务。
环境要求:
- 操作系统:Windows 10/11 (WSL2), macOS, 或 Linux(推荐Ubuntu 20.04+)
- Docker&Docker Compose:确保已安装并启动。
- 硬件:至少4核CPU,8GB内存,20GB磁盘空间。如需运行本地大模型,需要更高配置。
部署步骤:
获取部署文件: 在终端中,克隆部署仓库并进入目录。
git clone https://github.com/langgenius/dify.git cd dify/docker配置环境变量: 复制环境变量模板文件并编辑。
cp .env.example .env使用文本编辑器(如VSCode、nano)打开
.env文件,关键配置如下:# 设置一个安全的密钥,用于加密 SECRET_KEY=your-strong-secret-key-here-change-this # 指定外部访问的地址,本地开发设为 localhost CONSOLE_API_URL=http://localhost:5001 CONSOLE_WEB_URL=http://localhost:3000 APP_API_URL=http://localhost:5001 # 数据库配置(使用默认即可) DB_USERNAME=postgres DB_PASSWORD=difyai123456 DB_HOST=db DB_PORT=5432 DB_DATABASE=dify # 邮件服务(可选,用于用户邀请) # MAIL_TYPE=smtp # MAIL_HOST=smtp.gmail.com # MAIL_PORT=587 # MAIL_USERNAME=your-email@gmail.com # MAIL_PASSWORD=your-app-password启动服务: 在
docker目录下,执行以下命令:docker-compose up -d此命令将后台启动PostgreSQL、Redis、Milvus、MinIO、Nginx以及Dify的所有核心服务。首次启动会拉取镜像,需要几分钟时间。
验证与访问:
- 使用
docker-compose ps查看所有容器状态,确保均为Up。 - 打开浏览器,访问
http://localhost:3000。 - 首次访问需要初始化,设置管理员账号和密码。
- 登录后,即可进入Dify控制台。
- 使用
2.2 方案二:云服务器部署(适合生产预览)
在云服务器(如阿里云ECS、腾讯云CVM)上部署,流程与本地类似,但需注意网络安全和持久化存储。
关键步骤与差异:
- 安全组/防火墙:在云控制台,为实例的安全组开放端口
3000(Web),5001(API),22(SSH)。生产环境强烈建议将3000和5001端口设置为仅允许特定IP访问,或通过VPN接入。 - 持久化数据:Docker Compose默认使用匿名卷,服务器重启可能导致数据丢失。修改
docker-compose.yml,将关键服务的卷映射到主机目录:# 在PostgreSQL服务部分添加 services: db: volumes: - ./data/pg_data:/var/lib/postgresql/data redis: volumes: - ./data/redis_data:/data milvus: volumes: - ./data/milvus_data:/var/lib/milvus minio: volumes: - ./data/minio_data:/data - 域名与HTTPS:生产环境必须使用HTTPS。你可以:
- 使用Nginx反向代理:在服务器上安装Nginx,配置SSL证书(可从Let‘s Encrypt免费获取),将
https://your-domain.com代理到本地的http://localhost:3000和http://localhost:5001。 - 修改Dify配置:在
.env中,将CONSOLE_API_URL、CONSOLE_WEB_URL、APP_API_URL的localhost替换为你的域名,并加上https://前缀。
- 使用Nginx反向代理:在服务器上安装Nginx,配置SSL证书(可从Let‘s Encrypt免费获取),将
2.3 方案三:Kubernetes部署(企业级高可用)
对于需要弹性伸缩、高可用和CI/CD集成的企业,Kubernetes是最佳选择。Dify官方提供了Helm Chart。
前置条件:
- 一个运行的Kubernetes集群(如AWS EKS, GCP GKE, 或自建K8s)。
kubectl和helm命令行工具。
部署命令:
# 添加Dify Helm仓库 helm repo add dify https://langgenius.github.io/dify-helm/ helm repo update # 创建命名空间 kubectl create namespace dify # 安装Dify(使用自定义values文件覆盖配置) helm install dify dify/dify -n dify -f values.yaml你需要准备一个values.yaml文件来配置数据库连接、存储类、资源限制、域名等。这需要一定的K8s运维知识。
3. 核心功能实战:从零构建你的第一个AI应用
部署完成后,我们进入最激动人心的部分:构建应用。Dify主要支持两种应用类型:对话型应用和工作流应用。我们先从最简单的对话应用开始。
3.1 实战项目一:智能客服助手
目标:创建一个能回答特定领域(如“公司产品FAQ”)问题的客服机器人。
步骤:
创建应用:
- 登录Dify控制台,点击“创建新应用”。
- 选择“对话型应用”,输入名称“产品客服助手”,点击创建。
配置模型与提示词:
- 进入应用构建界面,在“提示词编排”页签。
- 选择模型:在右侧“模型”区,选择“OpenAI”,并选择
gpt-4o-mini(性价比高)。你需要提前在“模型供应商”设置中填入你的OpenAI API Key。 - 编写系统提示词:这是机器人的“人格”和规则。例如:
你是一个专业、友好且高效的公司产品客服助手。 你的知识范围仅限于以下提供的公司产品信息。如果用户的问题超出这个范围,你应该礼貌地表示无法回答,并引导用户提出与产品相关的问题。 请用清晰、简洁的中文回答,如果问题复杂,请分点说明。 - 编写上下文:在“上下文”区域,你可以上传或粘贴产品FAQ文档。Dify会自动将其作为上下文注入对话,增强机器人回答的准确性。
配置对话参数:
- 温度(Temperature):设为
0.7,平衡创造性和一致性。 - 最大令牌数:设为
2000,控制单次回答长度。 - 开启会话记忆:勾选,让机器人能记住同一会话中的历史对话。
- 温度(Temperature):设为
预览与测试:
- 点击右上角“预览”按钮,在右侧聊天窗口直接提问,例如:“你们的主打产品有什么特点?”。观察机器人的回答是否基于你提供的产品信息。
发布与分享:
- 测试满意后,点击“发布”。发布后,你可以:
- 获取API:在“访问方式”中获取API端点(Endpoint)和密钥(App Key),集成到你的网站或第三方系统。
- 分享Web链接:生成一个独立的H5页面链接,任何人点开即可使用。
- 嵌入网站:获取嵌入代码,以iframe或聊天窗口形式嵌入你的官网。
- 测试满意后,点击“发布”。发布后,你可以:
3.2 实战项目二:多步骤内容创作工作流
目标:创建一个自动化工作流,输入一个主题,自动生成一篇包含标题、大纲、正文和社交媒体文案的完整内容。
步骤:
创建工作流应用:
- 点击“创建新应用”,这次选择“工作流”。
- 命名为“全栈内容生成器”。
设计工作流DAG: 工作流画布是一个可视化编辑器,我们从左侧拖拽节点进行连接。
- 开始节点:拖入一个“开始”节点。将其配置为有一个字符串输入变量,命名为
topic, 代表文章主题。 - LLM节点(生成大纲):拖入一个“LLM”节点,连接到开始节点。配置其提示词为:
输出变量命名为根据用户提供的主题,生成一份详细的文章大纲。 主题:{{topic}} 要求大纲包含引言、3-5个核心论点及子论点、结论。 以Markdown列表格式输出。outline。 - LLM节点(生成正文):再拖入一个“LLM”节点,连接到上一个LLM节点。提示词为:
输出变量命名为根据以下主题和详细大纲,撰写一篇完整的文章正文。 主题:{{topic}} 大纲:{{outline}} 要求文章流畅、有深度,字数在800字左右。article_body。 - LLM节点(生成标题和文案):再拖入一个“LLM”节点,可以并行连接到“生成大纲”节点之后。提示词为:
输出变量命名为基于以下主题,生成一个吸引人的文章标题,以及一段适合Twitter和微博的推广文案(140字以内)。 主题:{{topic}} 请以JSON格式输出:{"title": "...", "social_media_copy": "..."}meta_info。 - 代码节点(格式化输出):拖入一个“Python”代码节点,连接到“生成正文”和“生成标题文案”节点。编写代码,将前面的输出整合成一个结构化的字典或字符串。
# 输入:article_body, meta_info # 输出:final_output import json meta = json.loads(meta_info) final_output = f""" # {meta['title']} ## 大纲 {outline} ## 正文 {article_body} ## 社交媒体文案 {meta['social_media_copy']} """ - 结束节点:将“代码节点”连接到“结束”节点。结束节点会输出
final_output作为工作流的最终结果。
- 开始节点:拖入一个“开始”节点。将其配置为有一个字符串输入变量,命名为
运行与调试:
- 点击右上角“运行”。在弹出窗口中为
topic输入值,如“人工智能在医疗诊断中的应用”。 - 点击“运行”,你可以实时看到执行过程在每个节点间的流转,以及每个节点的输入输出,非常利于调试复杂的逻辑。
- 点击右上角“运行”。在弹出窗口中为
发布为API:
- 工作流调试通过后,同样可以发布。发布后获得的API,当你传入
{"topic": "你的主题"}时,它会自动执行整个工作流,并返回生成的所有内容。
- 工作流调试通过后,同样可以发布。发布后获得的API,当你传入
4. 高级功能与集成实战
掌握了基础构建后,Dify的高级功能将释放其真正的生产力。
4.1 知识库:打造专属领域专家
知识库是Dify的杀手级功能,能让AI基于你提供的文档(PDF、Word、TXT、网页)进行精准问答。
创建与使用流程:
- 创建知识库:在控制台“知识库”菜单点击新建,命名如“公司内部技术文档”。
- 上传与处理:
- 上传文档。Dify支持多种格式,并会自动进行文本提取、分割、向量化。
- 关键配置:
- 分词与清洗规则:可配置如何处理特殊字符、是否保留表格等。
- 索引方式:选择“高精度”或“高召回”,平衡准确性与速度。
- 在应用/工作流中调用:
- 在对话应用或工作流中,拖入“知识库检索”节点。
- 选择你创建的知识库。
- 配置检索参数:
Top K(返回最相关的几条片段)、Score Threshold(相关性分数阈值,过滤低质量结果)。 - 检索到的片段会自动作为上下文插入到后续LLM节点的提示词中,从而实现“基于文档的问答”。
最佳实践:
- 文档预处理:上传前尽量保证文档格式清晰,去除无关页眉页脚。
- 分段策略:对于长文档,合理的分段能提升检索质量。Dify的自动分段通常效果不错,但对于结构特殊的文档,可考虑手动预处理。
- 多知识库混合检索:一个应用可以连接多个知识库,实现更全面的知识覆盖。
4.2 工具(函数调用):连接外部世界
LLM本身无法获取实时信息或操作外部系统。“工具”功能让LLM可以调用你编写的函数,实现如查询天气、操作数据库、调用第三方API等能力。
实战:创建一个查询股票价格的工具
编写工具函数(在“工具”菜单中创建):
# 函数名称:get_stock_price # 描述:根据股票代码查询实时股价 # 参数定义: # - stock_code: string, 股票代码,例如 ‘AAPL’, ‘00700.HK’ import requests import json def get_stock_price(stock_code: str) -> str: """ 模拟一个查询股票价格的函数。 实际应用中,这里应替换为真实的金融数据API调用。 """ # 示例:使用一个模拟API # 真实情况请使用 Yahoo Finance, Alpha Vantage, 或国内股票API mock_data = { ‘AAPL‘: ‘$172.31‘, ‘00700.HK‘: ‘HK$380.00‘, ‘TSLA‘: ‘$175.79‘ } price = mock_data.get(stock_code.upper(), ‘未找到该股票代码‘) return f“股票 {stock_code} 的当前价格是 {price}。“在应用/工作流中启用工具:
- 在对话应用的“提示词编排”页,或工作流的LLM节点配置中,找到“工具”选项。
- 勾选你创建的
get_stock_price工具。 - 在系统提示词中补充说明,例如:“如果用户询问股票价格,你可以使用 get_stock_price 工具来查询。”
测试:
- 发布应用后,询问:“苹果公司(AAPL)的股价现在是多少?”
- LLM会理解你的意图,自动调用
get_stock_price(‘AAPL‘)函数,并将函数返回的结果整合到它的自然语言回复中。
4.3 多模型路由与负载均衡
在企业环境中,你可能需要同时使用多个模型供应商(如OpenAI、Azure、 Anthropic、本地模型)以实现成本优化、冗余备份或特定能力调用。
配置模型供应商:
- 在“模型供应商”设置中,添加多个供应商的API密钥和端点。
- 为每个模型设置别名和优先级。
在应用中使用路由:
- 创建应用时,在模型选择处,可以选择“自动”(由Dify根据配置的规则和负载情况自动选择),也可以指定一个具体的模型。
- 在工作流中,不同的LLM节点可以选择不同的模型,实现灵活的编排。例如,创意生成用Claude,代码生成用GPT-4,简单问答用便宜的GPT-3.5-Turbo。
5. 企业级项目实战案例集锦
下面我们列举几个典型的企业级场景,描述其核心构建思路,你可以将其作为模板进行扩展。
项目1:智能合同审查助手
- 场景:法务团队需要快速审查合同中的风险条款。
- 构建:创建一个工作流。
开始→文件上传节点(接收PDF合同)→文本提取节点→知识库检索节点(连接“法律法规及风险条款知识库”)→LLM节点(提示词:“请对比提取的合同文本与知识库中的风险条款,列出潜在风险点并给出修改建议。”)→结束。 - 输出:一份结构化的风险审查报告。
项目2:自动化客户支持工单分类与路由
- 场景:客服系统收到大量工单,需要自动分类并分配给对应部门。
- 构建:创建一个工作流。
开始(接收工单文本)→LLM分类节点(提示词:“将以下客户问题分类为:[技术问题]、[账单问题]、[产品咨询]、[投诉]。只输出分类结果。”)→条件判断节点(根据分类结果,路由到不同的分支)→各分支处理节点(如调用不同的内部API或生成标准回复模板)→结束。 - 输出:工单分类结果及初步处理内容。
项目3:个性化营销内容生成平台
- 场景:为不同渠道(邮件、社交媒体、广告)和不同客户画像生成个性化营销文案。
- 构建:创建一个对话应用,但深度使用“变量”和“上下文”。
- 在应用开场,通过表单收集变量:
客户行业、产品名称、核心卖点、渠道。 - 系统提示词中引用这些变量:
请为{行业}行业的客户,针对{产品名称},撰写一篇用于{渠道}的营销文案,突出{核心卖点}。 - 结合“产品知识库”进行检索,确保文案准确性。
- 在应用开场,通过表单收集变量:
- 输出:高度定制化的营销文案。
6. 运维、监控与性能调优
将应用投入生产,稳定性与性能至关重要。
6.1 日志与监控
- 访问日志:Dify的Nginx和API服务会记录访问日志。在Docker部署中,日志默认输出到容器标准输出,可以使用
docker-compose logs -f service_name查看。 - 应用日志:在Dify控制台的“日志与标注”中,可以查看每个应用对话的详细日志,包括用户输入、模型响应、工具调用、消耗的Token数等。这是排查问题的主要依据。
- 系统监控:对于服务器,建议部署Prometheus + Grafana来监控CPU、内存、磁盘、网络以及Docker容器的状态。
6.2 性能调优建议
- 知识库检索优化:
- 调整
chunk_size(文本分段大小)和chunk_overlap(分段重叠)。较小的chunk_size检索更精准,但可能丢失上下文;适当的overlap可以保持语义连贯。 - 为知识库建立多层索引,结合关键词索引(BM25)和向量索引,提升召回率。
- 调整
- 工作流异步化:
- 对于耗时较长的工作流(如处理大量文档),在发布时启用“异步”模式。这样API调用会立即返回一个任务ID,客户端可以通过轮询另一个接口来获取结果,避免HTTP超时。
- 模型缓存:
- 对于内容相对固定的提示词(如固定模板的邮件生成),可以利用LLM节点的“缓存”功能,对相同输入直接返回历史输出,大幅降低Token消耗和延迟。
- 数据库与向量库优化:
- PostgreSQL:确保为频繁查询的字段(如
app_id,conversation_id)建立索引。定期清理过期的会话记录。 - Milvus:根据数据量调整索引类型(如IVF_FLAT, HNSW)。生产环境务必为Milvus配置持久化卷和备份。
- PostgreSQL:确保为频繁查询的字段(如
6.3 备份与恢复
- 数据库备份:定期对PostgreSQL进行逻辑备份:
docker exec -t dify-db-1 pg_dump -U postgres dify > backup_$(date +%Y%m%d).sql。 - 文件备份:备份
docker/data目录下的所有子目录(PG, Milvus, MinIO数据)。 - 恢复:通过
psql命令恢复数据库,并将备份的数据目录覆盖回原位置,重启服务。
7. 常见问题与故障排查清单
在实际操作中,你可能会遇到以下问题。这里提供一个快速排查指南。
| 问题现象 | 可能原因 | 排查步骤与解决方案 |
|---|---|---|
访问localhost:3000无法连接 | 1. 容器未成功启动。 2. 端口被占用。 3. 防火墙/安全组限制。 | 1.docker-compose ps检查所有容器状态。2. docker-compose logs查看错误日志。3. netstat -tlnp | grep :3000检查端口占用。4. 确保防火墙开放了3000和5001端口。 |
| 上传文件到知识库失败或处理慢 | 1. MinIO对象存储服务异常。 2. 文件格式不支持或损坏。 3. 网络问题导致上传中断。 | 1. 检查MinIO容器日志。 2. 确认文件格式在支持列表内(txt, pdf, docx, pptx, xlsx, md, html)。 3. 尝试较小的文件测试。检查服务器磁盘空间。 |
| 知识库问答效果差,答非所问 | 1. 文档分割不合理。 2. 检索Top K值或分数阈值设置不当。 3. 提示词未正确引导模型使用上下文。 4. 原始文档质量差。 | 1. 调整知识库的“分段处理”规则,尝试不同的chunk_size。2. 增加 Top K值,或降低Score Threshold。3. 在系统提示词中强调“请严格根据以下上下文回答”。 4. 优化源文档,去除无关内容。 |
| 调用API返回超时错误 | 1. 工作流执行时间超过API网关超时限制(通常30s)。 2. 模型API响应慢。 3. 服务器资源不足。 | 1. 将复杂工作流改为“异步”调用模式。 2. 检查模型供应商的状态和网络延迟。 3. 监控服务器CPU/内存使用率,考虑升级配置。 |
| 工作流中LLM节点报错“模型不可用” | 1. 模型供应商API密钥错误或过期。 2. 模型配额已用尽。 3. 在Dify中未正确配置该模型。 | 1. 在“模型供应商”设置中检查API密钥和端点。 2. 登录对应模型平台检查余额和用量。 3. 确保在当前应用或节点中选择了已配置且可用的模型。 |
| Docker容器频繁重启 | 1. 内存不足(OOM)。 2. 健康检查失败。 3. 依赖服务(如DB)连接失败。 | 1.docker stats查看容器资源使用情况,在docker-compose.yml中为服务增加mem_limit。2. docker-compose logs查看重启前的错误信息。3. 检查PostgreSQL、Redis等依赖服务是否正常运行。 |
8. 安全与生产环境最佳实践
将Dify应用于生产,安全是重中之重。
网络隔离:
- 绝不将Dify的控制台(3000端口)和API(5001端口)直接暴露在公网。应通过VPN、堡垒机或零信任网络访问管理后台。
- 对外提供服务的AI应用,应通过API网关(如Nginx)反向代理,并配置严格的限流、鉴权和WAF规则。
认证与授权:
- 启用SSO:在
.env中配置EXTERNAL_LOGIN_*相关变量,集成企业已有的OAuth2.0或SAML身份提供商(如Okta, Azure AD)。 - 精细化权限:利用Dify的企业版功能,为不同团队成员分配“所有者”、“开发者”、“运营者”等角色,控制其可访问的应用和操作。
- 启用SSO:在
数据安全:
- 加密传输:确保所有组件间通信(浏览器-Dify, Dify-模型API)都使用HTTPS。
- 敏感信息处理:不要在提示词或知识库中硬编码API密钥、数据库密码等敏感信息。使用环境变量或密钥管理服务。
- 审计日志:定期审查Dify的操作日志和API调用日志,监控异常行为。
模型API安全:
- 使用代理:考虑通过一个自建代理来转发所有对第三方模型API的请求,以便在代理层实施统一的审计、鉴权和限速。
- 监控费用:密切关注各模型API的Token消耗情况,设置预算告警,防止意外费用产生。
持续更新与备份:
- 定期升级:关注Dify GitHub仓库的Release,定期更新到稳定版本,以获取新功能和安全补丁。
- 灾备方案:制定完整的备份恢复方案,并定期进行演练。
通过以上八个章节的系统性学习与实践,你不仅能够完成从零到一的Dify应用搭建,更能掌握其核心原理、高级功能以及企业级部署运维的全套技能。Dify的强大之处在于它将复杂的AI工程化能力平民化,让你能专注于业务创新本身。现在,就从第一个实战项目开始,亲手搭建你的AI应用,体验快速迭代和交付的乐趣吧。如果在实践中遇到任何具体问题,欢迎在社区交流探讨,共同构建更完善的AI应用生态。
