尧图网站建设 
Dify 开源贡献指南本地环境搭建与 PR 全链路【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/difyDify 是面向团队的 LLM 应用开发平台。本文覆盖 Dify 开源贡献的完整闭环领 good first issue、按 uv 与 pnpm 工作区搭建本地开发环境、遵守 Bug 报告规范直到提交 PR 并等合并并整理关键的测试与调试命令。开工前三张准入票请先阅读 LICENSE 中的许可证与 Contributor Agreement并确认遵守社区 Code of Conduct。另外贡献文档本身是活文档描述落后于项目现状时反馈修正即是一次有效贡献。任务入口你的 Issue 在哪领浏览带good first issue标签的开放 Issue挑选一个入门任务新增模型运行时或新工具提交到独立插件仓库dify-plugins不进主仓库更新已有插件或修复插件 Bug提交到官方插件仓库dify-official-plugins。PR 描述必须关联一个已存在的 Issue或先开 Issue 讨论再开 PR。从源码结构可以印证这条分工主仓库 api/core/plugin/ 负责插件运行时与插件服务端的通信模型运行时与工具的具体实现都在插件仓库里。上游沟通报告与请求的最小完备集Bug 报告必含字段清晰且具描述性的标题详细的 Bug 描述包含完整错误信息可复现的步骤steps to reproduce期望行为expected behavior后端问题必须附日志通过docker-compose logs获取如适用附截图或视频缺陷优先级分级缺陷类型优先级核心功能故障云服务、无法登录、应用不可用、安全漏洞严重Critical非关键缺陷、性能改进中Medium小修正错别字、易混淆但功能正常的 UI低Low功能请求必含字段清晰且具描述性的标题功能的详细描述该功能的应用场景use case其他上下文或截图功能优先级分级功能类型优先级被团队成员标记为高优先级高社区反馈看板中受欢迎的请求中非核心功能和小幅增强低有价值但不紧急未来功能Future-Feature交付流水线Fork → Merge 七步Fork 仓库起草 PR 之前先创建 Issue 讨论你要做的改动为新改动创建独立分支当改动影响可观测行为或存在实质回归风险时添加或更新测试确保代码通过既有测试在 PR 描述中用fixes #issue_number关联 Issue等待合并。第 4 步对应仓库明确的测试理念测试保护的是可观测契约即用户交互与 UI 状态、导航与持久化、可达的加载/成功/错误/空状态、可访问性语义以及可通过公开边界复现的回归 Bug。不要仅因文件存在覆盖率缺口或TypeScript 已保证类型而补测试。本地开发栈前后端一键拉起后端Python uv自 v1.3.0 起后端包管理器从 poetry 切换到 uv官方推荐使用 dev/ 下的脚本脚本相对自身位置解析路径任意目录可执行。./dev/setup # 拷贝 env 文件并安装依赖 # 检查 api/.env、web/.env.local、docker/middleware.env 取值 ./dev/start-docker-compose # 启动 PostgreSQL/Redis/Weaviate ./dev/start-api # 启动后端先执行数据库迁移 ./dev/start-web # 启动前端 # 访问 http://localhost:3000 完成应用初始化 ./dev/start-worker # 启动 worker异步与定时任务 ./dev/start-beat # 可选启动 Celery Beat关键环境变量SECRET_KEY必须在.env中生成随机值Linux 下执行sed -i /^SECRET_KEY/c\\SECRET_KEY$(openssl rand -base64 42) .envCOOKIE_DOMAIN前后端运行在不同子域时设为站点顶级域名如example.com两端须处于同一顶级域下才能共享认证 CookiemacOS 的sed语法不同需先取值再写入secret_key$(openssl rand -base64 42) sed -i /^SECRET_KEY/c\\ SECRET_KEY${secret_key} .env前端Next.js 根目录 pnpm workspaceNode.js 与 pnpm 版本由根 package.json 的devEngines.runtime与packageManager字段锁定JavaScript 依赖由根工作区文件统一管理请从仓库根目录执行安装。pnpm install # 根目录安装依赖 cp web/.env.example web/.env.local # 创建本地环境变量 pnpm dev # 启动 vinext 与本地 API 代理两个易错点前端与后端不同子域部署时设置NEXT_PUBLIC_COOKIE_DOMAIN将NEXT_PUBLIC_API_PREFIX与NEXT_PUBLIC_PUBLIC_API_PREFIX指向正确的后端 API 地址仅当明确需要裸 Next.js 开发服务器不走 vinext时才用pnpm -C web dev路由归属定义在 web/dev-proxy.config.tsUI 组件开发可用pnpm -C web storybook启动 Storybook访问 6006 端口。api/README.md 与 web/README.md 是排障的第一手资料涵盖前置条件与依赖、安装步骤、配置细节与常见排障提示。质量门禁测试、Lint 与架构红线后端测试与格式化cd api uv sync --group dev # 安装测试环境依赖 uv run pytest # 全部测试 uv run pytest tests/unit_tests/ # 仅单元测试 uv run pytest tests/integration_tests/ # 集成测试 ./dev/reformat # 全部格式化器与 linter uv run ruff check --fix ./ # 修复 lint 问题 uv run ruff format ./ # 格式化代码 uv run pyrefly check # 类型检查dev/reformat 实际串联lint-imports架构分层检查→ruff check --fix→ruff format→dotenv-linter校验api/.env.example与web/.env.example的注释一致性→ 本地 pyrefly 类型检查。api/tests/ 下分unit_tests/、integration_tests/、test_containers_integration_tests/三层测试所用的模拟系统环境变量配置在pyproject.toml的tool.pytest_env段。前端测试cd web vp test run --project unit项目采用 Vitevitest命令不可用必须走vp命令。标准单元测试运行在happy-dom环境Browser Mode 仅保留给依赖真实浏览器行为的测试CSS 布局、原生焦点行为、真实指针输入等。别用裸vp test它会运行所有已注册项目包括 Browser Mode。架构分层自查按 api/AGENTS.md 的分层约定自查controller 管传输解析与序列化service 管编排逻辑core/或领域归属模块管领域策略。配置统一经configs.dify_config读取出站 HTTP 走现有的 SSRF 安全出口core.helper.ssrf_proxy请求与响应模型使用 Pydantic v2异步工作复用现有 Celery 任务归属者可重试任务必须保持副作用幂等。修改 controller schema 或SystemFeatureModel之前请先读 api/controllers/API_SCHEMA_GUIDE.md。卡住了两个求助口最直接的求助口是对应的 Issue 区维护者会关注活跃讨论直接在 Issue 中提问。更快的交流入口是 Dify 官方 Discord入口见根 README.md 的 Community 部分。收束以 Issue 为先导以插件仓库承接模型与工具扩展以dev/脚本驱动 uv 与 pnpm 工作区的本地开发栈以 ruff、pyrefly、vp test两套工具链守住质量门禁。四件事串起来就是一次从领 Issue 到等合并的完整 Dify 开源贡献闭环。【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/dify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Dify 开源贡献指南：本地环境搭建与 PR 全链路
Dify 开源贡献指南本地环境搭建与 PR 全链路【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/difyDify 是面向团队的 LLM 应用开发平台。本文覆盖 Dify 开源贡献的完整闭环领 good first issue、按 uv 与 pnpm 工作区搭建本地开发环境、遵守 Bug 报告规范直到提交 PR 并等合并并整理关键的测试与调试命令。开工前三张准入票请先阅读 LICENSE 中的许可证与 Contributor Agreement并确认遵守社区 Code of Conduct。另外贡献文档本身是活文档描述落后于项目现状时反馈修正即是一次有效贡献。任务入口你的 Issue 在哪领浏览带good first issue标签的开放 Issue挑选一个入门任务新增模型运行时或新工具提交到独立插件仓库dify-plugins不进主仓库更新已有插件或修复插件 Bug提交到官方插件仓库dify-official-plugins。PR 描述必须关联一个已存在的 Issue或先开 Issue 讨论再开 PR。从源码结构可以印证这条分工主仓库 api/core/plugin/ 负责插件运行时与插件服务端的通信模型运行时与工具的具体实现都在插件仓库里。上游沟通报告与请求的最小完备集Bug 报告必含字段清晰且具描述性的标题详细的 Bug 描述包含完整错误信息可复现的步骤steps to reproduce期望行为expected behavior后端问题必须附日志通过docker-compose logs获取如适用附截图或视频缺陷优先级分级缺陷类型优先级核心功能故障云服务、无法登录、应用不可用、安全漏洞严重Critical非关键缺陷、性能改进中Medium小修正错别字、易混淆但功能正常的 UI低Low功能请求必含字段清晰且具描述性的标题功能的详细描述该功能的应用场景use case其他上下文或截图功能优先级分级功能类型优先级被团队成员标记为高优先级高社区反馈看板中受欢迎的请求中非核心功能和小幅增强低有价值但不紧急未来功能Future-Feature交付流水线Fork → Merge 七步Fork 仓库起草 PR 之前先创建 Issue 讨论你要做的改动为新改动创建独立分支当改动影响可观测行为或存在实质回归风险时添加或更新测试确保代码通过既有测试在 PR 描述中用fixes #issue_number关联 Issue等待合并。第 4 步对应仓库明确的测试理念测试保护的是可观测契约即用户交互与 UI 状态、导航与持久化、可达的加载/成功/错误/空状态、可访问性语义以及可通过公开边界复现的回归 Bug。不要仅因文件存在覆盖率缺口或TypeScript 已保证类型而补测试。本地开发栈前后端一键拉起后端Python uv自 v1.3.0 起后端包管理器从 poetry 切换到 uv官方推荐使用 dev/ 下的脚本脚本相对自身位置解析路径任意目录可执行。./dev/setup # 拷贝 env 文件并安装依赖 # 检查 api/.env、web/.env.local、docker/middleware.env 取值 ./dev/start-docker-compose # 启动 PostgreSQL/Redis/Weaviate ./dev/start-api # 启动后端先执行数据库迁移 ./dev/start-web # 启动前端 # 访问 http://localhost:3000 完成应用初始化 ./dev/start-worker # 启动 worker异步与定时任务 ./dev/start-beat # 可选启动 Celery Beat关键环境变量SECRET_KEY必须在.env中生成随机值Linux 下执行sed -i /^SECRET_KEY/c\\SECRET_KEY$(openssl rand -base64 42) .envCOOKIE_DOMAIN前后端运行在不同子域时设为站点顶级域名如example.com两端须处于同一顶级域下才能共享认证 CookiemacOS 的sed语法不同需先取值再写入secret_key$(openssl rand -base64 42) sed -i /^SECRET_KEY/c\\ SECRET_KEY${secret_key} .env前端Next.js 根目录 pnpm workspaceNode.js 与 pnpm 版本由根 package.json 的devEngines.runtime与packageManager字段锁定JavaScript 依赖由根工作区文件统一管理请从仓库根目录执行安装。pnpm install # 根目录安装依赖 cp web/.env.example web/.env.local # 创建本地环境变量 pnpm dev # 启动 vinext 与本地 API 代理两个易错点前端与后端不同子域部署时设置NEXT_PUBLIC_COOKIE_DOMAIN将NEXT_PUBLIC_API_PREFIX与NEXT_PUBLIC_PUBLIC_API_PREFIX指向正确的后端 API 地址仅当明确需要裸 Next.js 开发服务器不走 vinext时才用pnpm -C web dev路由归属定义在 web/dev-proxy.config.tsUI 组件开发可用pnpm -C web storybook启动 Storybook访问 6006 端口。api/README.md 与 web/README.md 是排障的第一手资料涵盖前置条件与依赖、安装步骤、配置细节与常见排障提示。质量门禁测试、Lint 与架构红线后端测试与格式化cd api uv sync --group dev # 安装测试环境依赖 uv run pytest # 全部测试 uv run pytest tests/unit_tests/ # 仅单元测试 uv run pytest tests/integration_tests/ # 集成测试 ./dev/reformat # 全部格式化器与 linter uv run ruff check --fix ./ # 修复 lint 问题 uv run ruff format ./ # 格式化代码 uv run pyrefly check # 类型检查dev/reformat 实际串联lint-imports架构分层检查→ruff check --fix→ruff format→dotenv-linter校验api/.env.example与web/.env.example的注释一致性→ 本地 pyrefly 类型检查。api/tests/ 下分unit_tests/、integration_tests/、test_containers_integration_tests/三层测试所用的模拟系统环境变量配置在pyproject.toml的tool.pytest_env段。前端测试cd web vp test run --project unit项目采用 Vitevitest命令不可用必须走vp命令。标准单元测试运行在happy-dom环境Browser Mode 仅保留给依赖真实浏览器行为的测试CSS 布局、原生焦点行为、真实指针输入等。别用裸vp test它会运行所有已注册项目包括 Browser Mode。架构分层自查按 api/AGENTS.md 的分层约定自查controller 管传输解析与序列化service 管编排逻辑core/或领域归属模块管领域策略。配置统一经configs.dify_config读取出站 HTTP 走现有的 SSRF 安全出口core.helper.ssrf_proxy请求与响应模型使用 Pydantic v2异步工作复用现有 Celery 任务归属者可重试任务必须保持副作用幂等。修改 controller schema 或SystemFeatureModel之前请先读 api/controllers/API_SCHEMA_GUIDE.md。卡住了两个求助口最直接的求助口是对应的 Issue 区维护者会关注活跃讨论直接在 Issue 中提问。更快的交流入口是 Dify 官方 Discord入口见根 README.md 的 Community 部分。收束以 Issue 为先导以插件仓库承接模型与工具扩展以dev/脚本驱动 uv 与 pnpm 工作区的本地开发栈以 ruff、pyrefly、vp test两套工具链守住质量门禁。四件事串起来就是一次从领 Issue 到等合并的完整 Dify 开源贡献闭环。【免费下载链接】difyBuild Agentic workflows, RAG pipelines, with rich AI model and tool support on one collaborative workspace. Deploy on cloud, VPC, or self-hosted, so teams move from prototype to production without rebuilding the stack.项目地址: https://gitcode.com/GitHub_Trending/di/dify创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考