隨著前端業(yè)務(wù)邏輯的日益復(fù)雜化，團(tuán)隊(duì)在協(xié)作開發(fā)中往往面臨著代碼可維護(hù)性下降、復(fù)用困難等諸多痛點(diǎn)。近年來，“領(lǐng)域驅(qū)動(dòng)設(shè)計(jì)”（DDD）逐漸從后端深入前端，衍生出了以業(yè)務(wù)領(lǐng)域?yàn)楹诵牡?Feature Mode 分層架構(gòu)。與此同時(shí)，AI 編程助手的爆發(fā)式普及，又對(duì)前端工程化提出了新的挑戰(zhàn)與機(jī)遇。

一、傳統(tǒng)架構(gòu)的泥潭，與 Feature Mode (DDD) 的破局

在傳統(tǒng)前端項(xiàng)目中，大家普遍習(xí)慣按照“文件類型”來組織代碼，比如將所有的頁面寫在 src/pages，將所有的組件堆放在 src/components，將所有的接口方法塞入 src/api。

這種分層在項(xiàng)目初期看似清晰，但隨著業(yè)務(wù)膨脹，很快會(huì)帶來不可維護(hù)的災(zāi)難：

1. 代碼散落與牽一發(fā)而動(dòng)全身：要修改一個(gè)“訂單管理”的需求，你不得不在 pages、components、api 甚至 utils 目錄下來回穿梭，修改散落在七八個(gè)地方的文件。一旦發(fā)生變更，極容易引發(fā)意想不到的 Bug。
2. 全局污染與復(fù)用困境：很多開發(fā)者把某個(gè)特定頁面的業(yè)務(wù)組件（如 OrderTable）和業(yè)務(wù)工具庫放到了全局的 components 和 utils 中。結(jié)果全局庫日漸臃腫，當(dāng)另一個(gè)完全無關(guān)的模塊試圖復(fù)用時(shí)，往往帶著冗余的邏輯，最后干脆“復(fù)制粘貼”一份新代碼。

Feature Mode 帶來了什么？

為了應(yīng)對(duì)這些問題，前端引入了參考 DDD 思想的 Feature Mode（特征分層模式）。它的核心邏輯是：按“業(yè)務(wù)領(lǐng)域 (Domain)”劃分模塊，而不是按“技術(shù)元素”劃分。

在 Feature Mode 下，目錄結(jié)構(gòu)通常如下（如項(xiàng)目中現(xiàn)有的 user、order、student，以及共享的 shared 模塊）：

src/features/
    ├── student/       # 具體業(yè)務(wù)域
    │   ├── components/# 領(lǐng)域?qū)俳M件
    │   ├── hooks/     # 領(lǐng)域?qū)贁?shù)據(jù)流
    │   ├── services/  # 領(lǐng)域接口
    │   └── types.ts   # 領(lǐng)域數(shù)據(jù)模型
    └── shared/        # 跨領(lǐng)域共享域
        ├── components/# 跨領(lǐng)域復(fù)用組件
        ├── hooks/     # 跨領(lǐng)域復(fù)用業(yè)務(wù)邏輯
        ├── constants/ # 跨領(lǐng)域業(yè)務(wù)常量
        └── utils/     # 跨領(lǐng)域業(yè)務(wù)工具

這種設(shè)計(jì)完美的解決了一系列工程化問題：

• 跨領(lǐng)域能力下沉至 Shared 模塊：如果在開發(fā)過程中發(fā)現(xiàn)某個(gè)業(yè)務(wù)組件或數(shù)據(jù)流在多個(gè)領(lǐng)域場景下（例如在新的 Page 中或另一條業(yè)務(wù)線）需要跨頁面復(fù)用，正確的做法是：將這些原本屬于某個(gè)獨(dú)立 Domain 的可復(fù)用邏輯，提取下沉到 features/shared 目錄下。新的頁面或模塊只需統(tǒng)一從 shared 模塊中引入即可。這避免了各個(gè)領(lǐng)域模塊間的相互依賴和深度耦合（例如避免 order 模塊去引入 student 模塊的內(nèi)部實(shí)現(xiàn)）。
• 業(yè)務(wù)組件與工具的領(lǐng)域級(jí)收口：原本充斥在全局的業(yè)務(wù)組件，現(xiàn)在被收攏在 features/{domain}/components 或 features/shared/components 中。全局的 src/components 和 src/utils 徹底擺脫具體的業(yè)務(wù)邏輯限制，只留下純粹的技術(shù)基礎(chǔ)設(shè)施。
• Page 與 Feature 的優(yōu)雅協(xié)作：在這套架構(gòu)中，Page 層被徹底“抽空”為一層極薄的容器殼。Page（位于 src/pages）不直接處理復(fù)雜的業(yè)務(wù)邏輯，只負(fù)責(zé)頁面的入口路由、頂層狀態(tài)實(shí)例化（如基于 Antd 的 Form.useForm() 制定的“Form 外置模式”）和基礎(chǔ)的骨架排版。而所有的核心業(yè)務(wù)組件（如 DomainTable、DomainSearchForm）和數(shù)據(jù)獲取流（如 useDomainList）都內(nèi)聚在對(duì)應(yīng)的 Feature 模塊中。Page 就像是一個(gè)司令部，僅通過調(diào)用 Feature 暴露出來的清晰 API（Hooks）與預(yù)制 UI（組件），像搭積木一樣將業(yè)務(wù)組裝串聯(lián)起來。這種嚴(yán)格的職責(zé)分離極大提升了代碼的可讀性和測試性，徹底杜絕了業(yè)務(wù)邏輯與視圖狀態(tài)揉捏在同一個(gè)文件里導(dǎo)致的“千行屎山”現(xiàn)象。

二、AI 的崛起，與 AI Skills 的誕生背景

Cursor、Claude Code、GitHub Copilot 等 AI 代碼助手的普及，給開發(fā)者帶來了開發(fā)效率的極大提升，但同時(shí)也暴露出了嚴(yán)重的問題：AI 是個(gè)“無狀態(tài)”的超級(jí)程序員。

AI 編程痛點(diǎn)所在

1. 喜歡堆砌代碼（寫千行大文件）：當(dāng)你讓 AI 幫忙寫一個(gè)“帶有列表和編輯的頁面”時(shí)，如果沒有明確的約束，它通常會(huì)把請(qǐng)求邏輯、組件渲染、各種 useEffect 全部寫在一個(gè) index.tsx 里。它直接破壞了你苦心孤詣設(shè)計(jì)的 Feature Mode 架構(gòu)。
2. 缺乏系統(tǒng)上下文：AI 不知道你的團(tuán)隊(duì)使用 onPageChange 還是 handlePageChange 命名；不知道你們用 !!value 進(jìn)行簡寫判斷；不知道你們需要“外置 Form”，于是寫出了五花八門的代碼，代碼審查（CR）時(shí)的糾集與修改成本非常高。

AI Skills 的核心價(jià)值

正是在這種背景下，AI Skills（結(jié)合 OpenSpec 的工程規(guī)范） 應(yīng)運(yùn)而生。它的核心思想是：用系統(tǒng)約定的 Prompt 和技能規(guī)范，構(gòu)建 AI 編程的護(hù)欄（Guardrails）。

通過在項(xiàng)目中建立 AGENTS.md、project.md 以及細(xì)分的 skills/ 文檔：

1. 統(tǒng)一代碼規(guī)范（統(tǒng)一風(fēng)格）：明確告訴 AI 項(xiàng)目的分層結(jié)構(gòu)，嚴(yán)禁在 Page 級(jí)直接編寫業(yè)務(wù)與請(qǐng)求。
2. 提供確定與穩(wěn)定的上下文：限制 AI 胡亂發(fā)揮的沖動(dòng)。讓它遵循如“返回格式必須包含 list, total, pageNo, pageSize”、“Form 必須通過 props 透傳”的嚴(yán)格標(biāo)準(zhǔn)。
3. 減少 Token 試錯(cuò)（提效提質(zhì)）：讓 AI 精準(zhǔn)對(duì)焦在某一個(gè)小巧的 Feature 目錄下工作，而不是去通讀整個(gè)存量代碼庫從而產(chǎn)生幻覺。

三、珠聯(lián)璧合：當(dāng) DDD 架構(gòu)遇上 AI Skills

Feature Mode（DDD架構(gòu)）與 AI Skills 的相遇，并非偶然，而是相互成就的終極組合。我們可以看作是高質(zhì)量的架構(gòu)為 AI 提供了發(fā)揮的沙盒，清晰的 AI Skills 確保了沙盒游戲規(guī)則不可逾越。

1. AI 是 DDD 落地的最佳實(shí)踐者
   由于特征模式強(qiáng)調(diào)“內(nèi)聚的、拆分的物理小文件”，這對(duì)人類其實(shí)是一種心智負(fù)擔(dān)——我們要手動(dòng)創(chuàng)建三四個(gè)目錄、導(dǎo)出各種文件。而現(xiàn)在？開發(fā)者只需要寫好一份業(yè)務(wù)的 spec.md 需求文檔交給 AI，AI 能瞬間遵循 AI Skills 的約定，生成出極為漂亮的領(lǐng)域拆分代碼。開發(fā)者變成了架構(gòu)師與審查員，AI 變成了碼農(nóng)。

2. Feature Mode 是最適合 AI 分析的范式
   對(duì)于 LLM 的上下文窗口而言，理解一個(gè)高達(dá)百兆的全盤項(xiàng)目很容易使其丟失焦點(diǎn)。而在 Feature Mode 架構(gòu)下，AI 在處理任何一個(gè)業(yè)務(wù)需求時(shí)，都可以被精準(zhǔn)地限制在一個(gè)按特定領(lǐng)域劃分的代碼目錄樹之下。這種高度內(nèi)聚且“局部自閉環(huán)”的設(shè)計(jì)天然契合 AI 的工作方式：每一個(gè) Feature 模塊都獨(dú)立封裝了該領(lǐng)域?qū)俚慕M件（components）、狀態(tài)（hooks）、接口（services）和類型（types），形成了一個(gè)微小且完備的上下文沙盒。當(dāng) AI 在這個(gè)局部自閉環(huán)沙盒中進(jìn)行代碼推演、生成或重構(gòu)時(shí)，無需跨越遙遠(yuǎn)的文件樹去尋找復(fù)雜的外部依賴，其推理的思維鏈（Reasoning）連貫性會(huì)得到極大增強(qiáng)。這不僅大幅降低了產(chǎn)生幻覺和代碼 Bug 的概率，更讓 AI 模型卓越的局部代碼工程能力得到了最極致的發(fā)揮。

四、總結(jié)與未來展望

總結(jié)
現(xiàn)代前端工程的難點(diǎn)不在于如何實(shí)現(xiàn)一個(gè)按鈕，而在于如何在一個(gè)數(shù)百名工程師參與、生命周期長達(dá)數(shù)年的中后臺(tái)系統(tǒng)里，保證代碼的腐化速度慢于重構(gòu)的速度。

通過 Feature 驅(qū)動(dòng)的組件與邏輯分層（DDD），我們把代碼治理得井井有條，實(shí)現(xiàn)了高內(nèi)聚低耦合的業(yè)務(wù)與跨頁面復(fù)用；通過引入 AI Skills / OpenSpec 規(guī)范化約定，為 AI 工具掛載了系統(tǒng)記憶和“項(xiàng)目戒律”，消除了 AI 隨意破壞架構(gòu)的隱患。兩者結(jié)合，在效率和質(zhì)量之間找到了完美的平衡點(diǎn)。

這里需要強(qiáng)調(diào)一個(gè)個(gè)人觀點(diǎn)：對(duì)于龐大的存量項(xiàng)目，我們切忌盲目追求用 AI 去強(qiáng)行生成新功能。真正的“磨刀不誤砍柴工”，是首先借助 AI 強(qiáng)大的代碼理解與重構(gòu)能力，完成老舊架構(gòu)的升級(jí)（向 Feature Mode 遷移），統(tǒng)一團(tuán)隊(duì)底層的代碼規(guī)范，夯實(shí)項(xiàng)目的“地基”。只有在堅(jiān)實(shí)穩(wěn)固的地基和明確的邊界約束（AI Skills）之上，我們再去探索“如何借助 AI 更好地完成業(yè)務(wù)開發(fā)”，才能避免系統(tǒng)走向積重難返的技術(shù)債深淵，真正做到在享受 AI 帶來開發(fā)提效紅利的同時(shí)，依然能保證項(xiàng)目隨時(shí)可以被低成本地人工接手與維護(hù)。

未來展望
在不遠(yuǎn)的未來，隨著大模型的推理能力進(jìn)一步進(jìn)化，前端開發(fā)的工作流將發(fā)生實(shí)質(zhì)性轉(zhuǎn)變：

• 從 "Code-First" 到 "Spec-First"：開發(fā)者不再將精力陷入敲擊 React Hooks 和 CSS 的瑣碎工作中，重心將轉(zhuǎn)移到梳理業(yè)務(wù)邏輯的“邊界”、寫好定義清晰的 Specification 文檔，即真正的規(guī)范驅(qū)動(dòng)開發(fā)（SDD）。
• 架構(gòu)治理的自動(dòng)化：工程師將化身為 Prompt 工程師與業(yè)務(wù)架構(gòu)師的結(jié)合體。你只需關(guān)注如何精準(zhǔn)定義領(lǐng)域模型、如何調(diào)優(yōu) AGENTS.md 里 AI Skills 條款、以及確保業(yè)務(wù)需求的正確傳遞。執(zhí)行層的拼裝復(fù)用、增刪改查全權(quán)委托給被深刻約束在這個(gè)架構(gòu)里的 AI Agents。

這是代碼編寫走向“工業(yè)化”組裝的重要一步，DDD 的理念與 AI 的智能交織，正在重塑屬于開發(fā)者的下一個(gè)黃金時(shí)代。

附錄：以本項(xiàng)目的落成為例 —— AI 多模型協(xié)同落地的實(shí)戰(zhàn)工作流

上面探討了方法論，回落到實(shí)踐，本項(xiàng)目（包括你現(xiàn)在看到的這篇文章結(jié)構(gòu)和底層的代碼腳手架）本身就是“人機(jī)協(xié)同”、“多模型合作”的最佳產(chǎn)物。筆者在整個(gè)項(xiàng)目中的代碼貢獻(xiàn)量小于3%，更多的是通過不斷的與AI對(duì)話，來指導(dǎo)AI完成代碼的生成與調(diào)優(yōu)。以下展示了如何將多個(gè)頂尖大模型各司其職，從零到一構(gòu)建并提煉出一個(gè)完整的 Feature Mode 架構(gòu)與 AI Skills 規(guī)范工程體系：

核心工作流程圖

詳細(xì)實(shí)操五步曲

1. 項(xiàng)目骨架設(shè)計(jì) (Architecture Design)
   結(jié)合中后臺(tái)業(yè)務(wù)的實(shí)際情況與痛點(diǎn)，首先與 ChatGPT 和 Gemini 展開對(duì)話，梳理出符合 DDD 思想的 Feature Mode 的理論支持，并由它們生成一份包含 src/features 和 src/pages 職責(zé)徹底分離的初始項(xiàng)目目錄結(jié)構(gòu)方案。

2. 代碼 Demo 生成 (Code Generation)
   將確定的目錄結(jié)構(gòu)拋給 智譜大模型 (GLM-4)，讓它快速充當(dāng)“打字機(jī)”角色。根據(jù)目錄樹結(jié)構(gòu)，它能迅速生成具有依賴注入特征和 Form 外置模式的初始項(xiàng)目 Demo（包含基礎(chǔ)路由、useDomainList 的狀態(tài)封裝和 Ant-Design 表單渲染）。

3. 代碼深度調(diào)優(yōu) (Code Refactoring)
   初版的 AI 代碼往往伴隨有細(xì)微的類型安全、廢棄屬性等問題。在此階段，我們引入擅長上下文感知的 Cursor（或其他頂尖代碼模型，如多輪智譜交互）作為 IDE 伴侶。通過人工 CR 以及 AI 自動(dòng)修復(fù)（例如把冗余的狀態(tài)邏輯通過 !!value 化簡，或者把 destroyOnClose 替換為 destroyOnHidden），確保項(xiàng)目符合極其嚴(yán)苛的工業(yè)級(jí)代碼要求。

4. 規(guī)范反向提取與 AI Skills 的生成 (Skill Extraction)
   有了完善運(yùn)行的成熟代碼系統(tǒng)作為“存量參考”，我們利用長文本能力極其出色的 Kimi（K 2.5） 模型，將項(xiàng)目的核心目錄源碼，結(jié)合社區(qū)頂級(jí)的代碼規(guī)范（如 vercel-react-best-practices 模板）丟給它。讓 Kimi 從代碼實(shí)現(xiàn)中反向提煉出一整套適用于當(dāng)前項(xiàng)目的體系化 skill.md 與工程約束文檔，形成自己的 AI Skills。

5. 總結(jié)與文章生成 (Documentation output)
   最后一步，為了記錄這個(gè)完整的架構(gòu)躍遷，我們將整個(gè)項(xiàng)目結(jié)構(gòu)以及提煉出的 Skills 文檔，輸入給強(qiáng)無敵的 Google Antigravity 內(nèi)置模型 (Gemini 3.1 Pro)。告訴它以高級(jí)架構(gòu)師的視角幫忙生成一篇文章。并在生成后，通過多輪自然的對(duì)話（即本對(duì)話框的交互流），不斷潤色、修補(bǔ)錯(cuò)漏細(xì)節(jié)、加入針對(duì)存量項(xiàng)目的個(gè)人重構(gòu)觀點(diǎn)，最終得到了這份兼顧深廣與實(shí)踐經(jīng)驗(yàn)的“最佳實(shí)踐”結(jié)晶。

文末寄語

“多少事，從來急；天地轉(zhuǎn)，光陰迫。一萬年太久，只爭朝夕?！?/strong>