网站建设山东公司,erp软件培训,购买网站域名多少钱,做网站很赚钱如何让开源项目能够持续获得资金支持#xff0c;2025 - 2026 的答案肯定是紧跟 AI 。 2025 年 Dart/Flutter MCP 和 Flutter GenUI 的出现#xff0c;无疑让 Flutter 在 AI 上刷新了存在感#xff0c;特别是谷歌核心项目 NotebookLM 在 Flutter 上的成功#xff0c;也让 Fl…如何让开源项目能够持续获得资金支持2025 - 2026 的答案肯定是紧跟 AI 。2025 年 Dart/Flutter MCP 和 Flutter GenUI 的出现无疑让 Flutter 在 AI 上刷新了存在感特别是谷歌核心项目 NotebookLM 在 Flutter 上的成功也让 Flutter 在 AI 应用场景证明了可行性这从第三方 appfigures 提供的数据也可以有明显体现数据是 appfigures 分析数百万个 iOS 和 Android 应用和游戏并根据 SDK 当前安装的应用数量对其进行排名 https://appfigures.com/top-sdks/development/apps而这次新的 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(提示词) resources:-name:slivers_tutorial# 默认为文件名title:Slivers Tutorialdescription:Become a slivers expert with this doc!path:resources/slivers/really_awesome_doc_on_slivers.mdprompts:-name:split_into_subwidgets# 默认为文件名title:Split into subwidgetsdescription:Splits a widget up into multiple widgetspath:prompts/widgets/split_up_into_subwidgets.mdresources列表里每个对象包含name可选默认文件 basenametitledescriptionpath指向资源文件prompts同理name可选titledescriptionpath指向 prompt 文件这里的title/description支持 Agent UI 里展示这样可以更直观。在使用过程中AI 代理可以通过resource语法引用资源系统会将路径转换为 URI 格式package-root://package-name/path/from/package/root例如state自动引入状态管理文档同样 Prompts 也是prompts 通常以 slash commands 形式出现/prompt-nameMCP 服务器在暴露提示词时会有/package-name/prompt-name的区分例如/widget自动补全所有 widget 相关的命令 。当然提案里也说了一些限制MCP prompts 支持参数但参数都是字符串且不支持 repeated argumentsMCP 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 可以更好的理解和实现鸿蒙平台的支持。那么你觉得这个提案对你来说是否有帮助呢参考链接https://docs.google.com/document/d/1k_X-Sp4GQyZP6k9lvZ1Itj0GvzQZuWl3iKzi5AIa69Q/