跳到主内容

开发者体验

学习如何使用规范驱动开发和 Gemini 来规划、编写和迭代高质量的 Flutter 应用程序。

生成式 AI 不仅适用于实现应用程序中的功能,还适用于生成实现这些功能的代码。

不幸的是,提示 AI 编码代理“构建一个解决填字游戏问题的 Flutter 应用程序”也同样容易。我确信这个提示会产生一些结果,但我非常怀疑它是否能提供 Crossword Companion 提供的强大 AI 辅助、用户验证的组合。

然而,通过更好的提示,该示例应用程序使用 Gemini 2.5 Pro 实现了大部分功能,并使用 Gemini 3 Pro 预览版添加了最终润色。从这两个模型获得最佳结果的过程是相同的

  • 规划
  • 编码
  • 验证
  • 迭代

规划

#

规划过程的目标是启动编码过程,提供足够的细节让代理了解你的想法。Crossword Companion 规划过程从以下提示开始

I'd like to create a file called requirements.md in the plans folder at the root of the project. here's a description of the project:

The application will be an open-source sample hosted on GitHub in the flutter/demos directory. It aims to demonstrate the use of Flutter, Firebase AI Logic, and Gemini to produce an agentic workflow that can solve a small crossword puzzle (one with a size under 10x10)....lots more description of the app along with a sample puzzle screenshot...
Ask any questions you may have before you get started.

这个提示,加上一些问答环节、人工编辑以及编码过程中的更新,最终产生了 需求文件

在进入架构设计之前,Gemini CLI 被要求初始化 GEMINI.md 规则文件,然后用一系列架构原则来更新它

DRY (Don't Repeat Yourself) – eliminate duplicated logic by extracting shared utilities and modules.

Separation of Concerns – each module should handle one distinct responsibility.

Single Responsibility Principle (SRP) – every class/module/function/file should have exactly one reason to change.

Clear Abstractions & Contracts – expose intent through small, stable interfaces and hide implementation details.

Low Coupling, High Cohesion – keep modules self-contained, minimize cross-dependencies.

Scalability & Statelessness – design components to scale horizontally and prefer stateless services when possible.

Observability & Testability – build in logging, metrics, tracing, and ensure components can be unit/integration tested.

KISS (Keep It Simple, Sir) - keep solutions as simple as possible.

YAGNI (You're Not Gonna Need It) – avoid speculative complexity or over-engineering.

GEMINI.md 文件会被加载到你使用 Gemini 创建的每个新提示中;它提供了你希望它记住的规则集,用于任何活动。Gemini 在一个空的 Flutter 应用程序项目中运行,因此 /init 命令记录了如何构建、测试和运行它,这在编码期间很有用。

如果你构建的东西不仅仅是一个示例,我还建议添加一些关于测试驱动开发的内容

markdown
- **TDD (Test-Driven Development)** - write the tests first; the implementation
  code isn't done until the tests pass.

这有助于建立护栏,以确保编码代理随着时间的推移编写出可靠的代码。

有了需求和规则,接下来就是提示设计.md 文件

great. i'd like to work on the design with you to be created in a design.md file to be stored in the plans folder. please use the @GEMINI.md and @requirements.md files as input. ask any questions you may have before you get started.

在检查和编辑生成的应用程序设计之后,Gemini 被提示将其分解为 任务

please read the files in the @specs folder and create a corresponding tasks.md file in the same folder that lays out a set of tasks and subtasks representing the functionality of this app. lay out the top-level tasks as minimal new functionality that the user can see in the running app, step-by-step as each top-level task is completed. each top-level task should include sub-tasks for creating and running tests and updating the @README.md with a description of the current functionality of the app. ask any questions you may have before you get started.

所有这些都发生在任何代码编写之前。你不必将事情分成单独的文件,但通过仔细考虑需求、设计和任务分解,你正在帮助代理提供满足你期望的结果。这被称为“规范驱动开发”,目前是我们已知的将你的流程从“感觉编码”升级到“AI 辅助软件开发”的最佳方式。

此外,句子“在开始之前提出你可能有的任何问题”是让代理澄清它不理解的任何内容的好方法,而不是仅仅在不知道答案的情况下编造答案。它也有助于你决定你可能没有考虑到的细节。

编码

#

有了需求、规则、设计和任务,启动编码部分就很容易了

Read the @tasks.md file and implement the first milestone.

你可以观看编码代理的工作,在它工作时进行纠正,或者只是让它运行。无论哪种方式,完成之后,就该检查它的工作了。

验证

#

此时,你有一些代码,并且(在示例之外的世界中)有一些测试。为了验证,问自己一些问题

  • 分析器显示它没有错误吗?没有警告吗?
  • 应用程序可以运行吗?
  • 它具有你要求的功能吗?它们有效吗?
  • 测试通过吗?
  • 代码通过你的审查吗?

这些问题的答案是下一阶段的输入。

迭代

#

收集需要解决的问题,并将需要修复的问题交还给编码代理,在它编码和你的验证之间进行迭代,直到你从功能角度达到一个好的状态。

现在再次从架构原则的角度进行验证,启动一个新的代理来检查代码。通过清除代理的上下文,你可以消除原始代理在第一次选择要编写的代码时产生的偏差。为了将其仅限于代理刚刚所做的代码更改,请使用如下提示

Use git diff to find the new code and check it against the architectural principles listed here: @GEMINI.md. Make recommendations for important improvements.

这样做几次可以使代码保持良好的状态,供 AI 代理和人类使用。