企业官网建设流程全解析

• AI 技能
• AI 插件

在 Flutter 状态管理选型上，Bloc、Riverpod、Provider 与 ChangeNotifier 各有拥趸。flutter-ai-rules 把四套官方规范整理成可被 AI 编程助手自动加载的"技能包"，当你动手写相应代码时，规范会自动注入上下文。本文带你快速对比四大技能的核心差异与适用场景，帮你选对状态管理方案。

为什么状态管理选型总让人纠结 🤔

写 Flutter 应用绕不开一个问题：谁负责把数据交给 UI？四个主流答案——

• Bloc：事件驱动，状态变更有完整"事件→状态"轨迹
• Riverpod：响应式 Provider，强调缓存、组合与自动销毁
• Provider：轻量依赖注入 + 状态共享，Flutter 社区"默认款"
• ChangeNotifier：Flutter 框架自带的观察者模型，最轻量的起点

选错了意味着后期大面积重构。而 flutter-ai-rules 的做法是：不做主观裁决，而是把每个方案的官方文档规范做成独立技能（位于 skills/ 目录），由 AI 助手在匹配任务时自动加载——你写 Cubit 时它给 Bloc 规范，你写 Provider 时它给 Provider 规范。

四大技能一览：flutter-ai-rules 提供了什么 📦

每个技能就是一个带SKILL.md的文件夹，AI 助手读取描述后判断任务是否匹配，再拉取对应规范。README.md 中的技能总表列出了全部 36 个技能的触发条件。

Bloc 技能：事件驱动，最适合复杂业务流程 🧱

Bloc 技能 覆盖了从建模到测试的完整约定，几个新手最关心的点：

• Cubit vs Bloc 的选择：技能给出的建议是"默认用 Cubit，需求复杂化后再重构为 Bloc"——简单状态直接 emit，不需要事件层；需要事件追溯、防抖节流等高级事件处理时再上 Bloc
• 命名约定：事件用过去时（如LoginSubmitted），状态用名词（LoginInitial/LoginSuccess/LoginFailure），一眼看懂状态生命周期
• 三层架构：UI 层 → 业务逻辑层（Cubit/Bloc）→ 数据层（Repository → DataProvider），Bloc 不得绕过 Repository 直接访问数据
• 常见坑清单：比如"每次 emit 必须产生新状态对象，重复状态会被忽略"、"回调里用context.read，build里才用context.watch"

配套还有压缩版规则 combined/flutter_with_bloc.md，适合不支持技能机制的工具。

Riverpod 技能：响应式组合与自动销毁 ⚡

Riverpod 技能 的核心是把"状态即缓存的计算结果"这件事讲透：

• ref 四件套：ref.watch响应式监听（仅限 build 阶段）、ref.read一次性读取（回调里用）、ref.listen命令式订阅、ref.onDispose清理资源——技能里明确"绝不在回调里调用ref.watch"
• 参数化 provider（Families）：带参数的 provider 必须启用autoDispose防内存泄漏，且避免传没有==的普通List/Map
• 生命周期规则：代码生成模式下状态默认"无人监听即销毁"，需要常驻时用keepAlive；非代码生成模式则相反，需手动加.autoDispose
• 测试约定：每个测试创建全新的ProviderContainer，用overrides注入假数据，优先 mock 依赖（Repository）而不是 Notifier 本身

Provider 技能：最通用的依赖注入与状态共享 🔌

Provider 技能 偏"工程规范"，帮你把这套用得最广泛的方案用对：

• 五种 Provider 选型表：Provider（不可变值）、ChangeNotifierProvider（可变状态，自动 dispose）、FutureProvider、StreamProvider、ProxyProvider（依赖其他 provider 的对象）
• 消费三剑客：context.watch（监听并重建）、context.read（回调里调用方法）、context.select（只监听部分状态，减少重建）
• 反直觉的坑：绝不要用会变化的变量直接创建 provider 对象——变量变了它不会更新，要用ProxyProvider桥接
• 迁移指南：已废弃的ValueListenableProvider如何用ValueListenableBuilder替代

ChangeNotifier 技能：Flutter 内置的轻量起点 🌱

ChangeNotifier 技能 基于 Flutter 官方文档，适合小项目和刚入门的场景：

• 模型写法：内部状态保持私有，对外暴露不可修改视图，每次变更调用notifyListeners()
• 提供与消费：ChangeNotifierProvider挂在使用它的组件上方（会自动销毁模型），Consumer<T>尽量放在组件树深处以缩小重建范围；Provider.of<T>(context, listen: false)用于"只调用方法、不监听变化"的场景
• 优化规则：不要为了几行文字把整棵子树包进Consumer；按钮回调里触发操作时用listen: false
• 测试建议：给 ChangeNotifier 写单元测试，监听addListener验证通知是否触发

如何选？四大方案对比清单 ✅

新手建议：从 ChangeNotifier/Provider 起步，团队规模或业务复杂度上升后再迁移到 Bloc 或 Riverpod——四种方案的官方规范在 flutter-ai-rules 里都有，随时切换都不算"从零学起"。

安装方式：让 AI 助手自动加载对应规范 🚀

安装只需一条命令（Skills CLI，需 Node 22.20+）：

npx skills add evanca/flutter-ai-rules

支持 Claude Code、Codex、Cursor、Antigravity 等主流 AI 编程环境，也可以只挑一个技能：

npx skills add evanca/flutter-ai-rules --skill bloc

各环境的插件安装命令详见 README.md。如果工具不支持技能机制，仓库还保留了两种兜底方案：

• rules/ — 六大基础规则文件，放入项目后按名引用
• combined/ — 按主题合并的静态规则包（含__under_6K精简版），GitHub Copilot 可配合根目录 AGENTS.md 使用

小结 💡

• 四种状态管理没有绝对赢家，看场景选：复杂流程选 Bloc，响应式组合选 Riverpod，通用 DI 选 Provider，轻量起步选 ChangeNotifier
• flutter-ai-rules 的价值在于：无论你选谁，AI 助手都能自动带上该方案的官方规范（命名、架构、坑点、测试约定），把"最佳实践"变成"默认行为"
• 技能内容定期从上游官方文档同步，且刻意保持中立——不同来源规范冲突时两者并存，由你决策

想深入了解某个技能，直接打开对应的SKILL.md，内容比本文详细得多 😉

• AI 技能
• AI 插件