在人工智能（AI）輔助編程日益普及的今天，我們編碼的方式正在經歷一場前所未有的變革。

AI 工具如 QWenCoder，TreaCN等，能夠幫助我們快速生成代碼，極大地提升了開發效率。

然而，這也帶來了一個新的挑戰：

如何確保 AI 生成的代碼能夠遵循我們精心設計的軟件架構，特別是在中小型軟件項目中？

如何讓AI成為我們的得力伙伴，而不是混亂的制造者？

接下來，咱們一起來看看在AI輔助編程的時候，怎么才能把軟件分層設計做得又快又好。

不管是對AI編程充滿好奇的新手朋友，還是想提升團隊協作效率的老手，希望都能對你有些幫助。

1. 什么時候需要分層設計

如果你只是寫個臨時用的小工具或者腳本，用完即扔，那么，完全不需要考慮分層設計。

在下面的情況下，我們才需要先考慮分層設計，再去實現代碼：

• 追求模塊化和可維護性：當你希望系統的不同部分可以獨立開發、測試和維護時，分層架構是你的不二之選。
• 需要良好的可擴展性：隨著業務的發展，系統需要不斷迭代和擴展。分層架構的松耦合特性使得在不重構整個系統的情況下，添加新功能或替換某一層級的技術實現變得更加容易。
• 中小型項目或快速迭代：對于規模不大，追求開發效率的項目，分層架構因其簡單明了，易于理解和上手，同樣是一個不錯的選擇。

比如，以我比較熟悉的python語言為例，如果要做一個命令行工具（不需要連接數據庫），大致結構如下：

your_tool_name/               # 項目根目錄 (Project Root)
├── docs/                     # 項目文檔
├── src/                      # 源代碼目錄 (推薦) 或 your_tool_name/
│   └── your_tool_name/       # 主包目錄 (Main Package)
│       ├── __init__.py       # 標識這是一個包，并可定義`__version__`
│       ├── cli.py            # 命令行接口入口點，組織命令組
│       ├── commands/         # 子命令模塊（可選，復雜工具適用）
│       │   ├── __init__.py
│       │   ├── command_a.py
│       │   └── command_b.py
│       ├── core/             # 核心業務邏輯
│       │   ├── __init__.py
│       │   └── logic.py
│       └── utils/            # 公共輔助函數
│           ├── __init__.py
│           ├── file_io.py
│           └── helpers.py
├── tests/                    # 單元測試目錄
│   ├── __init__.py
│   ├── test_core.py
│   └── test_commands.py
├── scripts/                  # 輔助腳本（如部署腳本）
├── .gitignore                # Git忽略文件規則
├── LICENSE                   # 開源許可證
├── README.md                 # 項目說明文檔
├── requirements.txt          # 項目依賴列表
├── requirements-dev.txt      # 開發環境額外依賴（可選）
├── pyproject.toml           # 現代項目配置和依賴管理（推薦）
└── setup.py                 # 傳統打包配置（如果使用pyproject.toml可省略）

如果我想做一個略微復雜一些的Web項目（基于Python的FastAPI框架），大致結構可以如下：

your_fastapi_project/                 # 項目根目錄
├── app/                             # 應用主目錄 (核心包)
│   ├── __init__.py                 # 標識為Python包
│   ├── main.py                     # FastAPI應用創建和啟動入口（ASGI服務器入口）
│   ├── core/                       # 核心配置與基礎設施
│   │   ├── __init__.py
│   │   ├── config.py               # 應用配置（使用Pydantic讀取環境變量）
│   │   ├── dependencies.py         # 全局依賴注入（如數據庫會話）
│   │   ├── exceptions.py           # 全局異常處理器
│   │   ├── middlewares.py          # 全局中間件（如CORS、日志）
│   │   └── security.py             # 安全相關（如密碼哈希、JWT令牌創建驗證）
│   ├── api/                        # API層（路由層/表現層）
│   │   ├── __init__.py
│   │   └── v1/                     # API版本v1（支持多版本共存）
│   │       ├── __init__.py
│   │       ├── endpoints/          # 端點模塊（按業務模塊拆分路由文件）
│   │       │   ├── __init__.py
│   │       │   ├── users.py        # 用戶相關路由（如 /users/）
│   │       │   ├── items.py        # 物品相關路由（如 /items/）
│   │       │   └── ...             # 其他業務模塊路由
│   │       └── router.py           # v1版本路由匯總（聚合所有endpoints中的路由）
│   ├── models/                     # 數據模型（ORM模型，如使用SQLAlchemy）
│   │   ├── __init__.py
│   │   ├── base.py                 # 模型基類（如包含id, create_time的基類）
│   │   ├── user.py                 # 用戶數據模型
│   │   ├── item.py                 # 物品數據模型
│   │   └── ...
│   ├── schemas/                    # Pydantic模式（數據驗證與序列化）
│   │   ├── __init__.py
│   │   ├── base.py                 # 基礎Schema（如分頁響應基類）
│   │   ├── user.py                 # 用戶相關的請求/響應模式（如UserCreate, UserResponse）
│   │   ├── item.py                 # 物品相關的請求/響應模式
│   │   └── ...
│   ├── crud/                       # 數據操作層（基礎的增刪改查操作）
│   │   ├── __init__.py
│   │   ├── base.py                 # 基礎CRUD類（通用操作）
│   │   ├── crud_user.py            # 用戶數據操作
│   │   ├── crud_item.py            # 物品數據操作
│   │   └── ...
│   ├── services/                   # 業務邏輯層（封裝復雜業務規則，可跨CRUD操作）
│   │   ├── __init__.py
│   │   ├── user_service.py         # 用戶相關業務邏輯（如注冊、登錄流程）
│   │   ├── item_service.py         # 物品相關業務邏輯
│   │   └── ...
│   ├── db/                         # 數據庫相關
│   │   ├── __init__.py
│   │   ├── session.py              # 數據庫會話管理（如創建engine、SessionLocal）
│   │   └── base.py                 # 數據庫基礎（如Declarative Base）
│   └── utils/                      # 通用工具函數
│       ├── __init__.py
│       ├── helpers.py              # 通用輔助函數
│       └── ...
├── tests/                          # 測試目錄
│   ├── __init__.py
│   ├── conftest.py                 # pytest配置，定義測試夾具（fixtures）
│   ├── test_api/                   # API接口測試
│   │   ├── test_users.py
│   │   ├── test_items.py
│   │   └── ...
│   └── test_services/              # 業務邏輯測試
│       ├── test_user_service.py
│       └── ...
├── migrations/                     # 數據庫遷移腳本（如使用Alembic）
│   ├── versions/                   # 存放遷移版本文件
│   ├── alembic.ini                 # Alembic配置文件
│   └── env.py                      # Alembic環境腳本
├── static/                         # 靜態文件（CSS, JS, Images等）
├── templates/                      # 模板文件（如使用Jinja2）
├── requirements.txt                # 項目Python依賴列表
├── .env                            # 環境變量文件（本地開發，不應提交至Git）
├── .env.example                    # 環境變量示例文件（列出所需變量名和格式說明）
├── Dockerfile                      # Docker鏡像構建文件
├── docker-compose.yml              # Docker編排配置（可選）
└── README.md                       # 項目說明文檔

2. 如何讓 AI 生成的代碼乖乖“分層”？

“AI 并不知道你的架構”，這是一個在 AI 編程時代需要牢記的箴言。

AI 工具生成的代碼可能在功能上是正確的，但往往會忽略更廣泛的架構模式和設計原則。為了讓 AI 成為我們架構的“好幫手”而非“破壞者”，我們需要掌握一些技巧。

2.1. 始于意圖，而非代碼

在要求 AI 生成代碼之前，先明確意圖。

不要直接說“給我寫一個用戶注冊功能”，而是要提供更具體的上下文和邊界。

比如，我們可以這樣描述：

“我正在構建一個采用三層架構的電商應用。請為我生成用戶注冊功能的業務邏輯層代碼。這一層需要接收來自表現層的用戶數據（用戶名、密碼、郵箱），進行數據驗證，然后調用數據訪問層的方法將用戶信息存入數據庫。注意，不要在業務邏輯層直接編寫數據庫操作的代碼。”

通過清晰地定義代碼應該做什么、它所處的上下文以及必須遵守的邊界，可以極大地提高 AI 生成代碼的準確性和合規性。

2.2. 為 AI 提供充足的“上下文”

AI 的記憶力是有限的，它不會像人類一樣記住項目的整個架構。

因此，在每次交互中提供必要的上下文至關重要。

就好比將AI當成一位新來的同事，你需要不斷地向他同步項目的背景信息。

我們可以通過以下方式來提供上下文：

• 描述你的技術棧、文件夾結構和命名規范。
• 引用包含共享決策的文檔，例如 Markdown 文件。
• 在多個提示中復用上下文信息塊。

這些內容可以整理成文檔，方便代碼生成中反復使用。

2.3. 像開發者一樣思考，增量構建

不要指望 AI 一次性為你生成完美的、符合所有架構要求的復雜功能。

更好的方式是像一個經驗豐富的開發者那樣，將大任務分解成小的、可管理的部分，然后逐步構建和驗證。

例如，在開發一個功能時，我們可以：

1. 先讓 AI 生成數據訪問層的接口和實現
2. 然后是業務邏輯層的服務
3. 最后是表現層的控制器或視圖

每一步都進行審查和必要的調整，確保其符合分層原則。

3. 如何讓AI“學習”并理解我們的分層結構？

讓 AI 理解我們的軟件架構，是確保其生成合規代碼的關鍵。

雖然目前的 AI 還不能完全像人類架構師那樣進行高層次的思考和決策，但我們可以通過一些方法，讓它成為一個更懂架構的“隊友”。

1. 架構決策記錄：這是記錄重要架構決策背后原因的文檔。將這些文檔提供給 AI，可以讓它理解你為什么做出某些設計選擇，從而生成更符合意圖的代碼。
2. “活”的文檔和代碼示例：將文檔與代碼放在一起，并保持同步更新。同時，提供清晰的代碼示例，展示實現特定任務的“正確方式”。比如，我們甚至可以為AI提供一個遵循分層設計原則的完整功能的代碼范例。
3. 架構定義語言（**Architecture Definition Language, ADL**）：對于更復雜的系統，可以考慮使用輕量級的 ADL 來描述你的架構。這種方式可以用偽代碼的形式定義系統的結構和約束，然后將 ADL 作為提示提供給 AI，讓它生成符合架構定義的代碼。

4. 總結

總之，在 AI 輔助編程的新時代，軟件架構師和開發者的角色正在發生轉變。

我們不再是代碼的唯一創作者，而是與 AI 協作，共同構建高質量軟件的“指揮家”。

通過清晰地定義分層架構的邊界、為 AI 提供充足的上下文、并利用 AI 工具進行實時的架構審查和監督，我們完全有能力駕馭 AI 的強大力量，同時確保我們軟件的結構完整性和長期可維護性。

記住，AI 是一個強大的工具，但最終的架構決策和質量把控，仍然掌握在我們自己的手中。