flutter

flutter skill 概览

这个 flutter skill 是做什么的

flutter skill 是一套专门面向 Flutter/Dart 代码库的工作流指南，尤其适用于使用 Riverpod、Freezed、go_router 和 mocktail 的项目。它主要帮助你在现有应用里做改动，而不是从零学习 Flutter。如果你希望 AI 理解 Flutter 项目的结构，并产出贴合代码库的修改方案，那么这个 flutter skill 就是合适的起点。

最适合前端应用开发

当任务属于应用 UI 和客户端逻辑时，使用 flutter skill 最合适：页面、widgets、路由、状态、数据模型和测试。它非常适合 Flutter for Frontend Development，因为它强调的正是通常会拖慢实现速度的那些层级和模式：代码该放哪里、状态如何流动、路由和测试该怎么组织。

它在实际工作中的价值

它的核心价值在于“帮你做判断”。它不会让你猜功能该放在哪儿、provider 该怎么接，而是会把你引导到仓库既定的结构：lib/core、lib/data、lib/domain 和 lib/presentation。这样可以减少对本地约定的偏离，也更容易让第一次实现就通过编译和测试。

如何使用 flutter skill

先安装并打开正确的文件

使用下面的命令安装 flutter skill：
npx skills add alinaqi/claude-bootstrap --skill flutter

然后先读 SKILL.md，再看 pubspec.yaml、lib/main.dart、lib/app.dart，以及 lib/presentation/features/ 下最近的功能文件。如果任务涉及路由，请查看 lib/core/router/app_router.dart。如果任务涉及模型或 API 数据结构，请在写代码前先查看 lib/data/models/。

给这个 skill 一个真实的 Flutter 任务

flutter install 的效果最好时，是你给它一个具体目标，而不是“优化一下 app”这种模糊需求。要说明功能是什么、目标页面是哪一页、数据来自哪里、用户期望的行为是什么，以及有哪些限制。更强的提示可以这样写：“使用 Riverpod 状态、Freezed 模型更新和 go_router 导航，添加一个个人资料编辑页；保持现有主题，并用 mocktail 做测试。” 这样才能让 skill 拿到足够上下文，选出合适的文件和模式。

按实用流程推进

先扫描仓库，再要方案，再要实现，最后要验证。这样可以避免把设计决策和代码生成混在一起。对于 Flutter 使用场景，信息密度最高的顺序是：先识别功能边界，再定位 provider/model/router 文件，接着实现最小改动，最后在 test/unit 或 test/widget 中补充或更新测试。

这个 skill 最能节省时间的场景

当架构本身已经有一定约束时，这份 flutter 指南最有用。它在 Riverpod provider 选择、Freezed 模型边界，以及需要在多个页面之间保持一致的路由更新方面特别有帮助。如果你需要的是更宏观的应用策略、产品设计，或者彻底重构架构，它就没那么合适。

flutter skill 常见问题

这个 flutter skill 只适用于 Flutter 应用吗？

是的。它面向 Flutter/Dart 仓库，在代码库已经使用 skill 描述中提到的那些工具链时，价值最大。如果你的项目不是 Flutter 应用，flutter skill 基本帮不上忙。

还需要手动阅读仓库吗？

需要，但工作量会少很多。这个 skill 的作用，是快速理解预期的文件布局和实现模式；它不能替代对 pubspec.yaml、当前功能目录，以及你的改动依赖的路由和测试文件的检查。

flutter 对初学者有用吗？

有，但前提是你已经知道自己要完成什么任务。flutter skill 更适合“帮我把这个功能正确加进去”，而不是“教我 Flutter”。初学者最受益的情况，是他们能明确指向一个具体页面、状态变化或需要的测试。

什么时候不该用 flutter？

不要把它用在纯后端工作、一次性的概念问题，或者不采用分层 Flutter 结构的项目上。如果你的仓库在状态管理或路由方案上和 Riverpod、go_router 相差很大，它也会比较不合适。

如何改进 flutter skill

补齐应用上下文

最能提升效果的，是把功能的形状交代清楚：页面名、当前路由、数据源、加载/错误行为，以及 UI 应该如何响应。比如，“先展示缓存数据，再刷新”就比“把列表做得更好”有用得多。只有你说明了“完成”的定义，flutter skill 才能真正对齐你的应用。

明确要保留的文件和模式

如果仓库里已经有 provider 约定、widget 命名规则或测试辅助工具，请直接说明。明确指出哪些文件是权威来源，比如 app_router.dart、某个功能的 providers/ 文件夹，或者已有的 mocktail 配置。这样可以减少重复逻辑、代码放错位置，以及测试风格与项目不一致的问题。

先要小步的第一版

flutter 的最佳结果通常来自渐进式提问：先要实现方案，再要 provider/model 改动，再要 UI，最后要测试。如果第一版已经接近但还不对，就直接指出具体不匹配的地方：层级不对、路由结构不对、缺少空值处理，或者测试设置和你现有的 mocks 不一致。

注意常见失败模式

最常见的错误是 widget 过度泛化、provider 逻辑放错层，以及测试断言的是实现细节而不是行为。如果输出看起来很泛，再次提问时就要加入仓库专属锚点：功能目录路径、路由名、模型文件，以及精确的用户流程。通常这比单纯要求“写得更好”更能提升 flutter 使用效果。