AI 写完 Flutter，还要你盯日志、手动重启？我把这些操作交给了它
AI 改完代码后，你是不是还要切回开发工具，点热重载、翻控制台，再把报错复制给它？涉及原生代码时，还得停止项目、重新运行。
我想把这段流程也交给 AI：确认项目和设备，执行合适的运行命令，再读取真实控制台。为此，我做了 Flutter Manager，把 Flutter 环境、多项目开发和本机 MCP 接到一起。
在让 AI 接手操作之前，先要把开发环境和项目状态管清楚。维护多个项目时，我们经常需要确认：
“这个老项目用哪个 Flutter 版本？”
“刚才切换的是全局 SDK，还是当前项目的 SDK？”
“设备连上了吗？这一段报错属于哪个任务？”
“AI 改完页面，能不能直接热重载，再看看真实控制台？”
为了解决这些问题，我做了 Flutter Manager：一个基于 Flutter Desktop 的桌面工作台，把 FVM / Flutter 环境管理、项目管理与本机 MCP 接入放在一起，再补齐构建、产物、签名和安装流程。
现在更新到了 v1.3.0。这篇不单独聊 UI 改了什么，而是从日常开发流程出发，介绍它能帮我们省下哪些重复操作。
本文使用新版界面截图。业务 App Logo、项目路径和分发凭据已遮挡；截图中的 SDK 版本与历史安装包用于展示界面。
一、先把 FVM 和 Flutter 环境管清楚
多版本不是例外，而是日常
维护多个项目时，很难让所有项目同时升级 Flutter。旧项目有依赖兼容成本，新项目可能又需要更新的 SDK。
Flutter Manager 没有再造一套版本管理器，底层仍然使用 FVM。它做的是把版本和状态可视化：下载 SDK、查看已安装版本、设置全局版本，以及为不同项目选择各自的版本。
我比较在意的一点是：全局 Flutter 和项目 Flutter，必须分开表达。
全局版本是默认环境；项目自己的版本配置则是另一层约束。不能因为给新项目切了 SDK，就让旧项目悄悄跟着变。
打开工作台，先知道本机是什么状态
概览页集中展示 FVM 版本、当前全局 Flutter、已安装 SDK，并提供更新 FVM、查看目录和管理缓存的入口。
这件事看起来简单，但能省掉在几个终端里来回执行版本查询、猜测 PATH 指向的过程。
下载源与环境诊断也要放在一起
SDK 下载慢，不一定只是“换个镜像”就能解决。网络、代理、下载源和环境变量都可能影响结果。
工具提供镜像选择和测速入口，并通过环境诊断集中检查 FVM、Flutter SDK、Flutter Doctor、设备、平台工具以及相关配置，先把异常定位到具体环节。
这里不承诺换源后必然提速。它的价值是让当前使用的环境更清楚，而不是用一个按钮隐藏所有问题。
二、项目管理：把“打开项目”扩展成一次完整开发流程
项目列表不只是目录收藏夹
把本地 Flutter 项目添加进来后，可以集中查看项目，按标签和关键字筛选，并切换对应的 Flutter 版本。列表会尝试读取项目 Logo，没有时使用 Flutter 标识；收起列表后，也能直接通过图标切换项目。
项目被移动了，可以重新定位；不再使用的项目，可以只删除管理记录，不删除源码。
设备、模式、运行命令放到同一个上下文
选中项目后，可以选择运行设备与 Debug / Release 模式，默认 Debug，再执行 Flutter Run。
运行、热重载、热重启、重新运行、Pub Get、Clean 和 DevTools 都有明确入口。需要修改源码时，也可以从项目页使用配置的开发工具打开 Flutter 或原生项目。
这些按钮并不是同一种“刷新”：
| 改动场景 | 通常从什么操作开始 |
|---|---|
| 普通 Flutter UI、样式、布局改动 | Debug 下先尝试热重载 |
| 需要重新执行 Dart 初始化、重建运行状态 | 热重启 |
| 修改原生代码或涉及原生侧插件配置 | 停止后重新运行，必要时重新构建 |
| Release 模式运行 | 不依赖热重载，修改后重新构建运行 |
实际仍要看改动影响，不能机械地把所有变更都交给热重载。
控制台要能回答：“这是哪个项目、哪一次任务的输出？”
Flutter Manager 使用多任务标签隔离输出。主窗口只显示选中标签的内容，需要时也可以打开独立控制台。
搜索支持命中计数和回车逐项定位；重新运行、热重启以及开始构建时会清理对应旧输出，降低把上一轮报错当成当前问题的概率。
关闭仍在执行的任务标签会停止对应命令，而不是只让日志窗口消失、进程继续在后台跑。
三、MCP 服务：AI 改完代码，可以继续运行、热重载和读日志
这是我最想介绍的部分。
如果 AI 只能生成命令，开发者仍然要负责复制、执行、等待，再把报错贴回去。Flutter Manager 的 MCP 接入希望缩短这段反馈循环：让支持 MCP 的本机 AI 客户端，通过明确的工具接口操作项目、设备、任务和控制台。
它不是一个对公网开放的远程服务
连接链路是：
本机 AI 客户端
↓ MCP / stdio
Flutter Manager MCP Server
↓ HTTP + Token，127.0.0.1
Flutter Manager App
↓
项目、设备、Flutter 命令、运行状态与控制台
App 的 HTTP 控制接口只监听 127.0.0.1。它不能直接供外部网络或另一台电脑连接，也不是把 Flutter 项目暴露成一个公网控制台。
MCP Server 和 Skill 也不是同一个东西：MCP 提供调用能力，Skill 与命令指南帮助 AI 理解如何正确使用这些能力。
接入后可以做什么？
当前工具包括列出和选择项目、查询设备、运行、重新运行、热重载、热重启、停止任务、读取控制台、查询运行状态，以及 Pub Get、Clean、Build 和 DevTools 等操作。
例如可以向已正确接入的 AI 客户端提出：
先确认当前选中项目和可用设备，再运行 Debug；修改 Flutter 布局后尝试热重载，读取控制台确认是否有异常。涉及原生代码时不要只做热重载。
这不是让 AI 不加判断地执行命令。恰恰相反，项目、设备、运行模式与命令边界都应该明确。
一键复制接入说明，也把“什么时候用什么命令”交给 AI
MCP 页提供“一键复制接入说明”，准备 MCP、Skill 和命令选择指南。将内容粘贴给本机 AI 工具后，按说明完成配置。
它不是“复制一次就适配所有客户端”：仍需要本机环境、Node.js 18+，以及支持相应 MCP 配置的客户端；部分客户端修改配置后还需要重启。
对我来说，这一模块的重点不是又多了几个按钮，而是让 AI 的反馈能够接上真实的项目状态。
四、构建产物中心：打包结束后，还能继续把事情做完
构建支持平台、模式和 Android 渠道等选项，项目需要特殊流程时也可以使用自定义命令工作流。
构建完成后，产物中心统一扫描、筛选和查看项目安装包，展示文件名、类型、大小、时间与路径。配置相应平台凭据后，可以使用蒲公英、fir.im 的上传入口；具体支持的格式仍以分发平台规则为准。
v1.3.0 把 APK 选择和签名也串了起来：
- 从项目里展示已构建的 APK 列表，不再只猜某个固定目录中的最新文件。
- 从列表选择一个具体的 APK，或在产物详情中将它送入签名。
- 签名并校验成功后，选择保留源文件，或用签名包覆盖源文件。
- 可以记住处理方式，也能在设置中重新开启询问；覆盖前会保留
.bak备份。
macOS 上还新增了本地打包完成通知：同一批构建步骤成功结束后通知一次，点击通知可用访达打开产物目录。需要允许系统通知权限，失败和手动停止不会被当作成功完成。
五、环境配置与其他配套工具
环境配置页集中处理 Dart Pub / Flutter 下载源、FVM 和 PATH 等配置，并提供相关说明。配置会用于工具启动的命令；外部终端或其他应用是否读到新环境，还取决于它们的启动时机，需要时应重新打开。
除此之外，还有几项方便日常联调的功能：
- APK 安装：选择 APK、选择已连接的 Android 设备、点击安装，需要 ADB 和设备 USB 调试授权。
- 应用签名信息：读取 APK 或 JKS / Keystore 的证书信息，查看 SHA1、SHA256、MD5 等。
- 项目依赖管理：集中查看和调整项目依赖，减少重复打开配置文件的操作。
- Bugly 符号表上传：为配置了相关信息的项目提供构建后的配套操作。
这些功能不是为了把桌面工具做成一个“小型 IDE”。它依然依赖 FVM、Flutter、ADB、Android SDK 和各平台构建工具。比如在 macOS 上使用 Windows 项目管理入口，不等于能在本机直接构建 Windows 安装包。
六、v1.3.0 的 UI 调整，是为了把上下文做清楚
这次重新整理了整体配色和页面层级，保留浅色、深色与跟随系统：导航、内容、配置和结果不再挤在同一层。
项目页突出当前项目和运行操作；签名页把凭据与输出设置分组；MCP 页把本机服务和 AI 接入区分开。颜色只是辅助，状态仍有文字和图标说明。
它们最终想解决的是同一件事：当项目、设备、SDK 和任务变多时，开发者不应该靠记忆猜“这个按钮现在会作用于哪里”。
下载与反馈
- 源码：haoyuanwu/flutter_manager
- 本文版本：v1.3.0 下载页
- 反馈邮箱：qw761754627@163.com
v1.3.0 已提供 Apple Silicon 和 Intel 两种 macOS DMG。安装包使用临时签名，未完成 Apple Developer ID 签名和公证；Windows 安装包是否可用，请以对应 Release 的实际附件为准。
如果你正在用 AI 写 Flutter，可以先让它完成一个具体任务：确认项目和设备，运行 Debug，修改页面后执行热重载，再读取控制台。把这条流程跑通之后，许多原来需要来回切换窗口的操作，就能交给它继续完成。
欢迎试用，也欢迎反馈具体场景、操作步骤和实际结果。接下来，我会继续围绕环境管理、项目开发和 AI 操作这条流程打磨工具。
