什么是 FlyEnv？原生本地技术栈、AI 编程 CLI 与 MCP 工作区
现在的本地开发，早就不只是 PHP 加 MySQL。一个真实项目通常还需要多种运行时、本地服务、HTTPS 站点，以及必须看见真实本地环境的 AI 编程客户端。
FlyEnv 就是把这些能力收进同一个原生桌面工作区的工具。它负责管理本地运行时和服务，按项目切换版本，启动 AI 编程 CLI，并通过内置的 FlyEnv MCP Server 把受管理的本地上下文暴露给 AI 客户端。
FlyEnv 实际上能做什么
FlyEnv 让你只安装当前工作流需要的软件，并在一个原生桌面工作区中统一管理：
| 模块分类 | 支持的软件 |
|---|---|
| AI 编程与 MCP | FlyEnv MCP Server、Claude Code、Codex、OpenCode、Kimi、Antigravity CLI、GitHub Copilot CLI |
| AI 集成与自动化 | Hermes Agent、OpenClaw、n8n、Ollama、CliProxyAPI |
| 容器 | Podman |
| 网络隧道 | Cloudflared、Cloudflare Tunnel |
| Web 服务器 | FrankenPHP、Apache、Nginx、Caddy、Tomcat |
| 数据库 | MySQL、MariaDB、PostgreSQL、MongoDB、Qdrant、ClickHouse |
| 邮件服务器 | Mailpit |
| 编程语言与运行时 | .NET、Flutter、PHP、Composer、PHP-CLI、PHP-FPM、RoadRunner、Swoole CLI、Go、Node.js、Python、Java、Maven、Gradle、SDKMAN、Erlang、Ruby、Rust、Rustup、Bun、Deno、Zig |
| 缓存与消息队列 | Redis、Memcached、RabbitMQ |
| 服务治理 | Consul、Etcd、R-Nacos、Temporal、Temporal CLI |
| 搜索引擎 | Elasticsearch、Meilisearch、Typesense、ZincSearch |
| 对象存储 | RustFS、Minio |
| 自动化与调度 | Cron Jobs |
| 实用工具 | Git、MkCert、DNS Server、FTP Server、Static HTTP Server |
| 自定义模块 | 自定义模块可以作为服务或常用命令添加，并像内置模块一样工作。 |
所有模块均支持多版本共存，因此不同项目可以使用各自需要的运行时和服务版本，无需为每种软件分别维护版本管理工具。
除这些模块外，FlyEnv 还统一管理本地站点的自定义域名、HTTPS/SSL、反向代理、日志和站点级运行时设置；也把 AI 编程客户端和 FlyEnv MCP Server 放进同一工作区，让 AI 客户端能够结构化访问受管理的服务、站点、配置、日志和部分操作能力。
你不需要再把 Docker、版本管理器、shell 别名、hosts 修改和 AI 客户端配置拼成一套散乱流程，而是直接在一个本地桌面工作区里完成。
13 分钟了解 FlyEnv 核心功能
本视频采用英文旁白和英文字幕，集中演示 FlyEnv 的核心本地开发流程：按需选择模块、安装和切换版本、管理服务、创建可复用启动组、配置本地站点，以及使用内置开发工具。
关于 AI 编程 CLI 和 MCP 功能，请继续阅读 FlyEnv AI 工作区与 MCP 指南。
开发者为什么会用它
| 常见本地开发问题 | 常见应对方式 | FlyEnv 的变化 |
|---|---|---|
| 多项目之间版本冲突 | nvm、pyenv、手动切 PHP、各种 shell 胶水 | 在同一个工作区里做项目级运行时切换 |
| 本地工具太多太散 | 运行时一个工具，数据库一个工具，站点又一个工具 | 运行时、服务、站点和工具统一管理 |
| 本地 HTTPS 与自定义域名配置麻烦 | 手动配代理、证书和 hosts | 直接管理本地站点、域名、SSL 和日志 |
| AI 客户端能看代码，却看不到真实本地上下文 | 自己写配置、脚本，或直接给过大的 shell 权限 | 受管理的 AI CLI 与 MCP 本地上下文接入 |
| 容器优先的本地工作流对日常开发偏重 | 什么都先上 Docker | 不以容器为前提的原生本地工作流 |
真正的强项：当所有能力协同工作时
FlyEnv 的任何一项能力单独拿出来都很有用。版本切换、服务面板、本地域名和 SSL、隧道、AI 编程 CLI 管理、通过 MCP 暴露本地环境。
这些功能在别的工具里你也许都能分别找到。但更难找到的是：把它们全部放在一处，共享同一批项目、站点和工作流。这正是 FlyEnv 从“一个方便的小工具”变成“你真正工作的地方”的关键。
设想你平常的一天：
- 安装或管理项目需要的运行时与服务。
- 让 FlyEnv 自动把正确版本对准当前项目。
- 在同一个工作区里运行本地站点、域名、SSL、反向代理、日志和依赖服务。
- 直接用 Claude Code、Codex 或其他支持的 AI 编程 CLI 打开同一个项目上下文。
- 通过 FlyEnv MCP Server 把受管理的本地技术栈暴露给 AI，让它读取服务、配置、日志和部分操作能力。
过去这些通常意味着多个工具、多个配置文件和一堆 shell 胶水。现在它们可以变成一条连续的本地流程：
安装 -> 配置 -> 运行 -> 代理 -> 隧道 -> 调试 -> 接入 AI -> 交付
这才是 FlyEnv 真正的强项。节省下来的时间，不是因为某一个功能特别快，而是因为你不需要不断离开当前工作区。
FlyEnv 与 Docker、XAMPP 类工具的区别
| 方案 | 更擅长什么 | 相比 FlyEnv 的取舍 |
|---|---|---|
| Docker Desktop | 容器一致性与多服务容器编排 | 日常本地应用开发需要更多配置，也有额外容器开销 |
| XAMPP / MAMP 这类集成包 | 简单固定的 PHP/MySQL 沙盒 | 多版本、多运行时与 AI 工作流支持更弱 |
| FlyEnv | 原生多运行时本地开发，加上 AI 与 MCP 工作流 | 不以完整容器拓扑复现为第一目标 |
如果你的本地工作重点，是围绕真实运行时和本地服务来开发、调试和接入 AI，那么 FlyEnv 优先就是为这条路径设计的。
为什么 AI 让“本地环境”的定义变了
AI 编程客户端需要的，不只是仓库代码。它们还需要：
- 当前激活的 PHP、Node.js 或 Python 版本
- 正在运行的本地数据库、缓存和 Web 服务
- 站点 URL、日志和受管理配置文件
- 一种可控的、本地环境访问方式
FlyEnv 把运行时层和 AI 接入层放在同一个地方：
- 项目级运行时切换
- 同一工作区里的 AI 编程 CLI 模块
- 带 token 鉴权、工具开关、审批模式和审计日志的内置 MCP
如果你想看完整 AI 接入流程，可以继续读 FlyEnv AI 工作区与 MCP 指南。
由社区共建，并由社区驱动
FlyEnv 的增长并不只来自内部路线图。很多模块、修复、翻译和文档改进，都来自社区需求和直接提交的 Pull Request。
这件事的现实意义很直接：你今天缺少的那个功能，可能已经有人在提，甚至已经在实现。FlyEnv 基于模块化架构构建，这让新增运行时、服务、AI 工具和相关集成时，不需要推翻整个应用。
所以，如果 FlyEnv 还没有覆盖你需要的本地工具或工作流，下一步通常很明确：
- 去 GitHub 提一个需求
- 直接提交一个 Pull Request
产品是公开演进的，而这正是它能覆盖这么多本地开发场景的重要原因之一。
FlyEnv 适合谁
- 需要在多个本地项目与版本之间频繁切换的开发者
- 想减少 shell 胶水代码和零散工具的团队
- 希望让 Claude Code、Codex 等 AI 客户端接入真实本地服务的开发者
- 想要比容器优先方案更轻的日常本地工作流的人
平台支持
FlyEnv 原生支持：
- macOS
- Windows
- Linux
常见问题
Q：FlyEnv 只是给 PHP 用的吗？
A：不是。FlyEnv 面向的是多运行时本地开发，覆盖 PHP、Node.js、Python、数据库、本地站点以及相关工具。
Q：FlyEnv 能替代 Docker 吗？
A：对很多日常本地开发流程来说可以。如果你的重点是完整容器拓扑或生产级容器编排，Docker 仍然有它的价值。
Q：AI 编程客户端能接入 FlyEnv 吗？
A：可以。FlyEnv 既能直接管理支持的 AI 编程 CLI，也能通过 FlyEnv MCP Server 暴露本地上下文。
下一步
- 下载 FlyEnv
- 按照 快速入门指南 开始使用
- 继续阅读 FlyEnv vs Docker & XAMPP
- 查看完整的 FlyEnv AI 工作区与 MCP 指南