Flutter AI Harness 如何让 Agent 参与软件开发全流程

至于项目地址。

说到痛点一览，为什么现有工具无法满足长期维护需求？不过，

• 项目架构和约束散落在文档、代码和个人记忆中。Agent 每次都要重新猜测上下文。
• 需求通常直接进入实现阶段，任务边界、依赖关系和验收标准没有被固定下来。
• 一个通用 Reviewer 既审查业务代码。又审查 Harness 自身，很容易出现职责重叠或遗漏。
• 测试、建立和安全审查常常变成实现完成后的补充动作，而不是任务的一部分。怎么说呢，
• Agent 给出了“看起来合理”的结论。但没有留下足够的机器结果和失败原因供后续复核。

先说我想解决的不是“AI 会不会写代码”

最近几年。AI 编程工具的使用方式越来越自然：打开 Claude Code、Codex 或其他编码 Agent，进入项目目录，接下来用一句话描述需求。这对一次性修改非常有效，从但出现来看，

从提示词编程到程序化 Agent 协作

这里的变化不只是“增加了几个 Agent”。从真正的变化是来看，AI 的工作对象从一段代码。变成了一个有规则、有状态、有验收条件的工程任务。

使用者痛点提炼：

• "我只想把需求交给 AI，却不知道它会不会误解我的业务目标。" → 通过明确需求拆解与任务卡解决。按理说，
• "测试总是在最终才跑。我担心后期发现错误成本太高。" → 建立完整回归与聚焦验证两种模式。话说回来，
• "Review 看似自动。却没有区分业务逻辑和框架规则。" → 明确 Review Profile 与 Security Review 分工。
• "证据不足，我无法信任 AI 产生的功能是否真的符合规范。" → Evidence 机制记录所有机器验证摘要。

AIG 的基与层级结构

AIG
├── 项目契约
├── 工作流
├── 任务程序
├── Agent 程序
├── 质量门禁
├── 工具适配
└── 技术栈适配

这些层之间不是平行配置文件，而是一个有先后关系的执行链：项目契约决定边界 → 任务卡决定范围 → Agent 根据类型执行 → Review 路由检查 → 质量门禁判断是否可以归档。

至于第一层。项目契约是 Agent 的共同事实源

If 项目规则只存在于聊天历史中，Agent 就无法稳定地复用这些规则。Harness 把关键约束放回代码仓库。在当前项目中，CLAUDE.md 是权威项目契约。里面定义了：

• *Workspace* 和 *Package* 的依赖方向；
• *Domain Entity*、*Transport*、*Fixture* 和数据库 Row 的边界；
• *Flutter / Android / iOS* 的技术栈约定；老实说，
• *Native Module*。 *Bridge Adapter*,*Flutter Client* 的关系；
• *Agent*。*Command*,*Skill*,*Memory* 的组织方式；
• *Task card*,*Review*。*Security Review*,*Evidence*,*Archive* 生命周期。

Codex 的 AGENTS.md 只是入口适配，并不能覆盖 CLAUDE.md;所有工具必须读取同一套工程约束。

从第二层来看，任务卡把需求变成可执行工作

The natural language request is usually too broad;it cannot directly serve as a long‑term engineering boundary.

A simplified task card example:

# Task Card Example
executor: task-executor
platforms:
workKinds:
blockedBy:
# # 增加客服服务媒体发送入口
## 范围
- 在客服服务页面接入拍摄和相册入口。怎么说呢，- 复用已有媒体资源模型，不在页面层解析网站传输对象。## 验收条件
- 拍摄完成后可以进入结果预览页面。- 使用者确认后可以发送媒体消息。其实，- 失败时页面保留可理解的错误状态。## 验证
- 运行相关 Dart / Flutter 测试。- 对真实设备能力保留人工验证项。

The task card is not meant to stifle creativity;it answers “What exactly needs to be done?” When a requirement spans Flutter,Android,iOS or Bridge,it is typically split into multiple dependent tasks rar than letting one agent roam freely across layers.

从第三层来看，Agent 按职责参与，而不是共享一个模糊角色

The name of an agent should reflect a concrete role with clear responsibilities and output contracts.

 ​
​
​
​
​
​
​
​
​

一次完整执行的大致流程示例:

• .先分析，不急着写代码：…
• .生成任务卡并明确依赖：…
• .Agent 根据任务边界执行：…
• .独立 Review 和必要的 Security Review：…
• .记录 Evidence，最终才归档：…

为什么不应该每次都全量重跑？

Harness 的目标不是把所有检查都做一遍，而是让检查与变更影响面保持一致。
**主要原则**：

一样原则适用于历史报告：归档后的审核记录不可变，新修改应创建新任务而非 历史。

Flutter 并非主要，只是第一个治理对象

虽然仓库名含 Flutter。但模型本身不依赖任何特定技术栈，可迁移至 Web/Node.js/Go/Python 等环境，只需调整技术栈适配层即可。

如何把 Harness 接入另一个项目？

1. 已有项目

   • 审计现有技术栈、架构边界、CI/CD 等
   • 输出方案并等待批准

2. 空目录

   • 讨论产品目标、网站部署、团队能力、安全等
   • 确认技术栈后再制定初始化方案

接入后仅引入真实使用者需要的能力，并复用原有测试/建立工具。怎么说呢，

我们要明确哪些不是？

从实践得到的关键结论

1. AI 编码瓶颈将从速度转向上下文管理与结果验证。
2. Agent 数量并非关键，清晰职责与输出规范。
3. Task 卡决定需求是否具备清晰范围与完成定义。
4. Review/Evidence/Security Review 必须区分，以避免责任模糊。
5. Harness 本身也需持续审查，否则可能演化为繁琐流程程序。

最终思考

我们并未声称 Flutter AI Harness 已解决所有问题。它更像是一套工程组织方式，把原本仅存在于个人经验中的规则逐步转化为可读可执行且可审查的仓库资产。

至于最终目标是，“当 Agent 在需求分析→拆解→实现→测试→审核→归档各环节均通过明确制度支持时整个过程能否更稳定、透明且可复用？按理说，” 如果答案为肯定。那么 Flutter 将仅是起点——一样的方法能带到更多语言、网站及团队之中。

Project 地址：