AI-Driven Architecture Development System
核心目标：
你负责：
架构设计 / 业务判断 / 技术取舍 / 质量标准 / 最终验收
AI负责：
代码实现 / 模板生成 / 单元测试 / 文档补全 / 重构建议 / 风险扫描一、整体开发思想
以前开发是：
需求 → 人写代码 → 人调试 → 人维护AI 时代应该变成：
需求
→ 人做架构设计
→ AI生成候选方案
→ 人做技术决策
→ AI实现代码
→ AI自检
→ 人验收
→ AI补测试/文档
→ 持续迭代你不是少干活了。
你是从：
代码工人升级成：
系统设计者 + AI 指挥官二、AIChats + Flutter 双架构总览
你现在有两条线：
1. AIChats / SwiftUI 体系
适合：
iOS 原生
SwiftUI
@Observable
Environment 注入
Interactor
Router / Builder
Firebase / OpenAI
日志 / 埋点 / 权限 / 付费墙推荐架构：
View
↓
Presenter / ViewModel
↓
Interactor
↓
Service Protocol
↓
Concrete Service
↓
SDK / API / Firebase / OpenAI2. Flutter 体系
适合：
跨平台
Riverpod
Dio
Repository
Service
NetworkClient
Mock
Cache
统一错误处理推荐架构：
Widget
↓
Controller / Notifier / ViewModel
↓
UseCase / Interactor
↓
Repository
↓
Service Protocol
↓
NetworkClient / Cache / Local DB三、统一后的 AI 时代架构模型
无论 SwiftUI 还是 Flutter，都统一成这个思想：
UI Layer
只负责展示和用户交互
Presentation Layer
负责状态、加载、错误、页面行为
Domain Layer
负责业务规则、用例、权限判断
Data Layer
负责网络、本地缓存、数据库、SDK
Infrastructure Layer
负责日志、埋点、配置、环境、工具也就是：
页面不碰网络
页面不碰 Firebase
页面不碰 Dio
页面不碰 OpenAI
页面不判断复杂业务
页面只展示状态四、你的角色重新定义
你以后不是这样问 AI：
帮我写一个登录页面而是应该这样：
我要实现 UserAuth 模块。
请按照我定义的架构：
View 只负责展示；
Presenter 负责状态；
Interactor 负责业务；
Service 使用协议；
MockService 用于 Preview 和测试；
所有错误通过 AppError 统一处理；
所有关键行为打点；
请先给我模块拆分方案，不要直接写代码。这就是质变。
五、AI 参与开发的五种模式
你需要把 AI 分成五种工作模式。
1. Exploration Mode：探索模式
用于：
不知道怎么设计
需要比较方案
需要发现盲区你问 AI：
我现在要做一个聊天消息流模块。
要求：
1. Firestore 实时流
2. 支持弱网
3. 支持消息发送中状态
4. 支持 AI 回复生成
5. 支持失败重试
6. 支持日志埋点
7. UI 不直接依赖 Firebase
请不要写代码。
先分析这个模块可能有哪些架构方案。
每个方案说明优点、缺点、风险、适用场景。
最后推荐一个方案。这个阶段 AI 不能写代码。
只能帮你开脑洞。
2. Decision Mode：决策模式
用于：
从多个方案中选一个
确定最终架构你问 AI：
基于上面的方案，我决定使用：
View + Presenter + Interactor + Service Protocol + FirebaseChatService。
请帮我输出最终技术决策文档：
1. 为什么选择这个方案
2. 为什么不选择其他方案
3. 模块边界
4. 数据流
5. 错误处理
6. 日志埋点点位
7. 后续扩展方向
不要写代码。这个文档非常重要。
它相当于你的架构记录。
3. Task Mode：执行模式
用于：
让 AI 真正写代码你给 AI 的指令应该像任务单：
请实现 Chat 模块第一步。
目标：
创建 ChatServiceProtocol、FirebaseChatService、MockChatService。
要求：
1. ChatServiceProtocol 必须抽象消息流、发送消息、删除消息
2. FirebaseChatService 使用 Firebase 实现
3. MockChatService 用于 Preview 和测试
4. 不要写 UI
5. 不要写 Presenter
6. 错误统一转换为 AppError
7. 所有 public 类型添加必要注释
8. 代码按文件拆分输出
完成后请自检：
- 是否有强耦合
- 是否违反单一职责
- 是否方便测试重点是：
一次只让 AI 做一个明确任务
不要一口气让它做整个 App4. Review Mode：审查模式
用于：
AI 写完代码后，让另一个 AI 视角审查你问：
请作为高级 iOS 架构师审查下面代码。
重点检查：
1. 是否违反分层
2. 是否存在并发问题
3. 是否存在内存泄漏
4. 是否存在强耦合
5. 是否不利于单元测试
6. 是否有命名不清晰
7. 是否有未来扩展风险
请不要重写代码。
只输出问题、原因、修改建议。这个非常关键。
因为 AI 写代码很快，但也会写出“表面很漂亮，后期很毒”的代码。
5. Refactor Mode：重构模式
用于：
代码已经能跑，但结构不好指令：
请在不改变外部调用方式的前提下，重构下面代码。
目标：
1. 降低耦合
2. 提高可测试性
3. 拆分过大的方法
4. 保持 API 兼容
5. 不改变业务行为
请先列出重构步骤，再给代码。六、你的项目应该有一套 AI 开发文件
建议你在项目根目录加一个：
AI/
├── PROJECT_RULES.md
├── ARCHITECTURE.md
├── TASK_TEMPLATE.md
├── REVIEW_TEMPLATE.md
├── PROMPTS/
│ ├── exploration.md
│ ├── decision.md
│ ├── task.md
│ ├── review.md
│ └── refactor.md
└── MODULES/
├── Chat.md
├── Auth.md
├── User.md
├── Network.md
└── Payment.md这不是摆设。
这是你给 AI 的“项目宪法”。
七、PROJECT_RULES.md 示例
# Project Rules
## General
- Do not let UI directly call network, Firebase, OpenAI, or database SDK.
- All external dependencies must be wrapped behind protocols.
- All modules must support Mock implementations.
- All user-facing errors must be mapped into AppError.
- All important user actions must be trackable.
- Business logic should live in Interactor / UseCase, not View.
- View should only render state and send user actions.
## SwiftUI Rules
- Use SwiftUI as the UI layer.
- Use @Observable for Presenter / ViewModel where appropriate.
- Inject dependencies through Environment or module factory.
- Router is responsible for navigation.
- Builder is responsible for constructing screens.
- Presenter should not directly create concrete services.
- Firebase SDK should only appear inside service implementations.
## Flutter Rules
- Use Riverpod for dependency injection and state management.
- Dio must not be used directly in widgets.
- Use NetworkClient abstraction.
- Repository handles data coordination.
- Service handles API calls.
- State classes should be immutable.
- Use AsyncValue or explicit UiState for loading/error/success.
## AI Coding Rules
- AI must not introduce new architecture without explanation.
- AI must not directly modify unrelated modules.
- AI must output file paths.
- AI must explain assumptions.
- AI must self-review generated code.八、ARCHITECTURE.md 示例
# Architecture
## Core Principle
This project follows layered architecture.
UI does not know concrete data source.
Business logic does not depend on UI.
External SDKs are hidden behind protocols.
## Layers
### UI Layer
Responsible for:
- Rendering state
- Receiving user input
- Calling Presenter actions
Not responsible for:
- Network request
- Firebase operation
- OpenAI operation
- Cache logic
- Business rules
### Presentation Layer
Responsible for:
- UI state
- Loading/error/success state
- Calling Interactor
- Mapping domain result into UI state
### Domain Layer
Responsible for:
- Business use cases
- Permission checks
- Free limit checks
- Message sending rules
- Payment gate rules
### Data Layer
Responsible for:
- Repository
- Service implementation
- DTO mapping
- Cache strategy
### Infrastructure Layer
Responsible for:
- Logging
- Analytics
- Network client
- Config
- Environment switching九、SwiftUI / AIChats 标准模块结构
以后每个模块都这样：
Modules/
└── Chat/
├── Entity/
│ ├── Chat.swift
│ ├── ChatMessage.swift
│ └── ChatMock.swift
│
├── View/
│ ├── ChatView.swift
│ ├── ChatMessageRow.swift
│ └── ChatInputBar.swift
│
├── Presenter/
│ └── ChatPresenter.swift
│
├── Interactor/
│ ├── ChatInteractor.swift
│ └── MockChatInteractor.swift
│
├── Service/
│ ├── ChatServiceProtocol.swift
│ ├── FirebaseChatService.swift
│ └── MockChatService.swift
│
├── Router/
│ └── ChatRouter.swift
│
├── Builder/
│ └── ChatBuilder.swift
│
└── Tests/
├── ChatPresenterTests.swift
└── ChatInteractorTests.swift十、Flutter 标准模块结构
Flutter 也对应一套：
lib/
└── features/
└── home/
├── domain/
│ ├── entities/
│ │ └── home_banner.dart
│ ├── repositories/
│ │ └── home_repository.dart
│ └── usecases/
│ └── get_home_banners.dart
│
├── data/
│ ├── models/
│ │ └── home_banner_model.dart
│ ├── repositories/
│ │ └── home_repository_impl.dart
│ └── services/
│ ├── home_api_service.dart
│ └── mock_home_api_service.dart
│
├── presentation/
│ ├── providers/
│ │ └── home_providers.dart
│ ├── controllers/
│ │ └── home_controller.dart
│ └── views/
│ └── home_page.dart
│
└── widgets/
├── home_banner_view.dart
└── home_article_item.dart十一、统一的模块开发流程
每个模块固定 7 步。
Step 1：定义业务目标
这个模块解决什么问题？
用户是谁？
核心流程是什么？
失败场景有哪些？Step 2：定义数据模型
Entity 是什么？
DTO 是什么？
Model 是否需要 mock？
是否需要 computed properties？
是否需要 validation？Step 3：定义协议
Service Protocol
Repository Protocol
Interactor Protocol
Router ProtocolStep 4：实现 Mock
先写 Mock，不是先写真服务。
原因：
Mock 可以验证架构是否解耦
Mock 可以让 UI 先跑起来
Mock 可以让 Preview / 测试提前工作Step 5：实现真实服务
比如：
FirebaseChatService
OpenAITextService
DioNetworkClient
AlamofireNetworkClientStep 6：接入 UI
UI 最后接入。
不是一上来就写页面。
Step 7：测试 + 审查
每个模块至少有：
正常场景
失败场景
空数据场景
弱网场景
权限不足场景十二、AI 在每一层的参与边界
UI Layer
AI 可以做：
布局
组件拆分
样式优化
Preview / mock UI你必须做：
交互体验判断
是否符合产品感觉
复杂滚动体验
动画体验
性能判断Presentation Layer
AI 可以做：
状态枚举
loading/error/success
调用 interactor
基础事件处理你必须做：
状态边界设计
页面行为设计
用户操作顺序
异常恢复策略Domain Layer
AI 可以辅助，但不能主导。
这里最危险。
比如：
免费次数限制
付费墙触发
消息发送前置条件
分销规则
商品价格规则
SKU 选择规则这些必须你定规则。
AI 只能帮你实现。
Data Layer
AI 很适合做：
API 封装
DTO 解析
缓存策略
错误映射
分页加载
重试策略但你要定义：
什么时候用缓存
缓存多久
失败时是否降级
本地数据是否可信Infrastructure Layer
AI 很适合做：
Logger
Analytics
Config
Feature Flag
Environment
MockProvider
NetworkClient这些你可以大量交给 AI。
十三、你以后和 AI 协作的标准格式
你每次给 AI 发任务，最好固定格式：
# Task
实现 XXX 模块的第 X 步。
## Context
当前项目使用：
- SwiftUI / Flutter
- 架构：
- 依赖：
- 已存在文件：
## Goal
本次只完成：
## Requirements
1.
2.
3.
## Constraints
- 不要修改无关文件
- 不要引入新架构
- 不要直接访问 SDK
- 必须使用协议
- 必须支持 Mock
## Output
请按文件路径输出代码。
## Self Review
完成后检查：
1. 是否违反分层
2. 是否可测试
3. 是否有强耦合
4. 是否有并发/状态问题十四、你的 AI 开发流程应该变成这样
你：
我要做 Chat 模块
AI：
给出 3 个方案
你：
选择方案 B，原因是 xxx
AI：
输出架构决策文档
你：
执行 Step 1：Entity + Protocol
AI：
写代码
你：
Review
AI：
指出问题
你：
执行 Step 2：Mock
AI：
写 Mock
你：
接 UI
AI：
生成 View
你：
体验测试
AI：
补测试和文档十五、最重要的原则：AI 不能直接碰核心业务规则
比如这些，不要让 AI 自己决定：
用户什么时候能发消息
免费次数怎么算
缓存什么时候失效
弱网时是否显示旧数据
支付失败后怎么处理
SKU 价格怎么组合
分销规则怎么限制
风控策略怎么处理正确方式是：
你写规则
AI 写实现十六、AIChats 推荐升级方向
你的 AIChats 项目可以升级成这样：
Core/
├── AppState/
├── Environment/
├── Router/
├── Builder/
├── Logger/
├── Analytics/
├── Error/
├── Config/
├── TaskStore/
├── Network/
├── AI/
├── Firebase/
└── Purchase/
Modules/
├── Auth/
├── User/
├── Avatar/
├── Chat/
├── Explore/
├── Settings/
├── Paywall/
└── Report/Core 层职责
不属于某个业务模块，但全 App 都需要的能力。比如：
Router
Builder
Logger
Analytics
AppError
NetworkClient
AIService
FirebaseService
PurchaseManager
FeatureFlag
EnvironmentConfigModules 层职责
具体业务模块。比如：
Chat
Auth
User
Avatar
Explore
Paywall模块内部可以使用 Core，但 Core 不应该反向依赖模块。
十七、Flutter 项目推荐升级方向
lib/
├── app/
│ ├── app.dart
│ ├── app_router.dart
│ ├── app_bootstrap.dart
│ └── app_providers.dart
│
├── core/
│ ├── config/
│ ├── error/
│ ├── network/
│ ├── cache/
│ ├── logger/
│ ├── analytics/
│ ├── constants/
│ └── utils/
│
├── shared/
│ ├── widgets/
│ ├── models/
│ └── extensions/
│
└── features/
├── auth/
├── home/
├── chat/
├── profile/
└── settings/十八、AI 最适合帮你沉淀的“企业级基础设施”
这些你以后可以让 AI 一步步补齐。
SwiftUI 侧
AppError
AppLogger
AnalyticsEvent
TrackableView
TaskStore
EnvironmentBundle
ModuleFactory
RouterProtocol
BuilderProtocol
ServiceProtocol
MockProvider
FeatureFlag
RemoteConfig
CacheStore
SecureStoreFlutter 侧
AppError
Result<T>
NetworkClient
DioNetworkClient
RequestOptionsBuilder
ResponseMapper
ErrorMapper
CacheManager
MockProvider
Logger
AnalyticsService
AppConfig
Environment
FeatureFlag
BaseController
UiState<T>
PaginationController十九、你最应该做的事情
你以后应该把精力放在这些地方：
1. 定义架构规则
哪些层可以依赖哪些层
哪些东西必须走协议
哪些东西不能直接调用2. 定义业务规则
什么情况下允许
什么情况下禁止
什么情况下降级
什么情况下弹窗3. 定义质量标准
是否可测试
是否可 Mock
是否可替换
是否可扩展
是否可维护4. 定义 AI 任务边界
这次只做 Entity
这次只做 Service
这次只做 Mock
这次只做 View二十、最终结论
AI 时代，你不能再把自己定位成：
我会不会写代码而应该定位成：
我能不能设计一个长期不烂的系统你真正的价值变成：
架构判断力
业务抽象能力
复杂度控制能力
AI 指挥能力
代码审查能力
系统演进能力一句话总结：
以后代码让 AI 写，但系统必须由你设计。
你现在最该做的，就是给自己的项目建立一套：
AI 开发规则 + 架构文档 + 任务模板 + 审查模板这套东西一旦建立起来，AI 就不是“帮你写几段代码”的工具，而是可以被你稳定指挥的工程团队。