如何让开源项目能够持续获得资金支持，2025 - 2026 的答案肯定是紧跟 AI 。
2025 年 Dart/Flutter MCP 和 Flutter GenUI 的出现，无疑让 Flutter 在 AI 上刷新了存在感，特别是谷歌核心项目 NotebookLM 在 Flutter 上的成功，也让 Flutter 在 AI 应用场景证明了可行性，这从第三方 appfigures 提供的数据也可以有明显体现：
数据是 appfigures 分析数百万个 iOS 和 Android 应用和游戏，并根据 SDK 当前安装的应用数量对其进行排名 appfigures.com/top-sdks/de…
而这次新的 AI 提案，主要是为了： 让 Dart/Flutter 的 Package 可以把「给 AI Agent 用的资源（文档/指南）和 prompts」直接随包发布，并由 Dart/Flutter MCP Server 从「当前工程的依赖」中自动发现并暴露给 Agent 使用，从而避免额外安装 MCP server / node/npx / 单独 prompts 仓库等分裂的分发方式。
说人话就是：让 AI 可以通过 Dart/Flutter MCP 更好地理解和使用 Flutter 的 Package ，而不是需要花费额外 token 去理解并让 AI 发挥想象力去接入。
也就是把“AI 辅助能力”当作 Package 的一等公民 ，并且发现/更新还能自动化完成，让 Flutter 的 AI 生态更加完善。
实际上这确实当前趋势下比较迫切的需求之一，AI coding 越来越常用，而如果让 Agent 能更好理解 Flutter Package 自然就成新的刚需，例如：
最佳实践、典型坑位、推荐用法、命令化工作流等，甚至让包能够更优先出现在 AI 的选择里。
所以这个这不是「让 agent 读 README」的低级需求，而是「包作者提供 curated 的、面向 agent 的知识与操作入口」。
而 Flutter 这次提议的 Packaged AI Assets ，其实就是希望可以：只装一个 Dart/Flutter MCP server，然后在你加依赖/更依赖版本时，相关 agent features 会随之更新。
怎么简单怎么来。
提案的核心，是通过在包中添加一个特定格式的配置文件来描述该 Package 提供的 AI 资源，例如：
- 提供一个
extensions/mcp/config.yaml的全新路径文件，让它成为 Packaged AI Assets 的入口 - 格式遵循
package:extension_discovery格式，借用extension_discovery的既有机制 - 工作原理则是，Dart/Flutter MCP 会读取直接依赖项中的这些配置文件，并将定义的资源和提示词直接通过 MCP 协议暴露给 AI 代理
这里暂时使用的是 MCP 而不是 Skills ，核心也是希望直接依赖于已有的 Dart/Flutter MCP server ，这样也不需要额外配置；另外未来页可能会考虑，目前可以通过在
bin/目录下添加 Dart 脚本，用户可以通过提示词执行dart run <package>:<script>来运行。
所以，在 Packaged AI Assets 的详细设计里，配置文件主要包含两个部分：resources (资源) 和 prompts (提示词) ：
1resources: 2 - name: slivers_tutorial # 默认为文件名 3 title: "Slivers Tutorial" 4 description: "Become a slivers expert with this doc!" 5 path: resources/slivers/really_awesome_doc_on_slivers.md 6 7prompts: 8 - name: split_into_subwidgets # 默认为文件名 9 title: "Split into subwidgets" 10 description: "Splits a widget up into multiple widgets" 11 path: prompts/widgets/split_up_into_subwidgets.md 12
resources 列表里每个对象包含：
- name（可选，默认文件 basename）
- title
- description
- path（指向资源文件）
prompts 同理：
- name（可选）
- title
- description
- path（指向 prompt 文件）
这里的
title/description支持 Agent UI 里展示，这样可以更直观。
在使用过程中：
- AI 代理可以通过
@<resource>语法引用资源，系统会将路径转换为 URI 格式package-root://<package-name>/<path/from/package/root>，例如@state自动引入状态管理文档 - 同样 Prompts 也是，prompts 通常以 slash commands 形式出现（
/<prompt-name>），MCP 服务器在暴露提示词时会有/package-name/prompt-name的区分，例如/widget自动补全所有 widget 相关的命令 。
当然，提案里也说了一些限制：
- MCP prompts 支持参数，但参数都是字符串，且不支持 repeated arguments（MCP spec 限制）
- 如果 prompt 声明了 arguments，那么 prompt 文件会被当作 mustache 模板，用
package:mustache_template注入参数
所以按照目前的规则，可以理解为：
- 必须定义「arguments 在 config.yaml 的写法」
- mustache 模板替换要有转义规则，否则 prompt 注入/模板注入风险更高
- 参数都是 string 而复杂结构需要 JSON string，这可能会影响复杂场景的通用性
另外，一些边缘情况处理也需要考虑，例如：
- 多包配置场景: 如果用户同时打开了多个包，且这些包依赖同一个包的不同版本，系统会使用在任何打开的包中找到的最新版本的资源和提示词，这样可以减少重复和保持 URI 简短
- 当依赖项发生变化（如添加新包）时，目前需要重启 MCP 服务器才能加载新的 AI 辅助功能，虽然未来可能会支持动态监听和更新，但由于许多 AI 代理本身不支持动态变更通知，应该暂时不会支持
AI 辅助最怕“自信但错”，如果 agent 引用的是不匹配版本的文档，会直接误导代码修改，浪费更多 token。
同时安全性也是一个着重考虑的点，可能会面临提示词注入的风险，所以需要考虑：
- 由 MCP 客户端负责防范
- 所有 MCP 服务器应被视为不可信来源
- 计划在推进前研究缓解措施，例如在上传到
pub.dev时进行安全扫描
最后，目前提案还存在一些需要解决的问题，例如：
- 文件干扰 : Agnet 可能会同时看到原始文件和 MCP 资源，可能导致混淆，需要通过向 Agnet 隐藏
extensions/目录来解决 - 是否需要将
geminicli 扩展中的 Flutter 特性迁移到packages/flutter/extensions/ai - 是否允许发布仅包含 AI 辅助功能而不含 Dart 代码的包？
- 是否应暴露传递依赖（间接依赖）的资源？目前 V1 版本不计划支持，但未来可考虑添加传递可见性选项。
- 是否可以不依赖手动编写，而是自动包含示例等资源？
总的来说，我还是很期待这个提案的落地，对我来说目前 AI 在使用和选择 Package 里，确实经常遇到使用了错误的 API ，或者更新了 Package 之后，它还保留上个版本的写法，当然这个提案就算落地，最终也需要作者愿意提供对应的 Packaged AI Assets ，我觉得这对于社区版本的 Flutter 也是很好的帮助，例如鸿蒙版本的 Flutter 在后续跟进鸿蒙平台 Package 时，AI 可以更好的理解和实现鸿蒙平台的支持。
那么，你觉得这个提案对你来说是否有帮助呢？
参考链接
《Flutter 正在计划提供 Packaged AI Assets 的支持，让你的包/插件可以更好被 AI 理解和选择》 是转载文章，点击查看原文。
