重构前端工程：DDD、Feature Mode 与 AI Skills 的深度融合

随着前端业务逻辑的日益复杂化，团队在协作开发中往往面临着代码可维护性下降、复用困难等诸多痛点。近年来，“领域驱动设计”（DDD）逐渐从后端深入前端，衍生出了以业务领域为核心的 Feature Mode 分层架构。与此同时，AI 编程助手的爆发式普及，又对前端工程化提出了新的挑战与机遇。

一、传统架构的泥潭，与 Feature Mode (DDD) 的破局

在传统前端项目中，大家普遍习惯按照“文件类型”来组织代码，比如将所有的页面写在 src/pages，将所有的组件堆放在 src/components，将所有的接口方法塞入 src/api。

这种分层在项目初期看似清晰，但随着业务膨胀，很快会带来不可维护的灾难：

代码散落与牵一发而动全身：要修改一个“订单管理”的需求，你不得不在 pages、components、api 甚至 utils 目录下来回穿梭，修改散落在七八个地方的文件。一旦发生变更，极容易引发意想不到的 Bug。
全局污染与复用困境：很多开发者把某个特定页面的业务组件（如 OrderTable）和业务工具库放到了全局的 components 和 utils 中。结果全局库日渐臃肿，当另一个完全无关的模块试图复用时，往往带着冗余的逻辑，最后干脆“复制粘贴”一份新代码。

Feature Mode 带来了什么？

为了应对这些问题，前端引入了参考 DDD 思想的 Feature Mode（特征分层模式）。它的核心逻辑是：按“业务领域 (Domain)”划分模块，而不是按“技术元素”划分。

在 Feature Mode 下，目录结构通常如下（如项目中现有的 user、order、student，以及共享的 shared 模块）：

src/features/
    ├── student/       # 具体业务域
    │   ├── components/# 领域专属组件
    │   ├── hooks/     # 领域专属数据流
    │   ├── services/  # 领域接口
    │   └── types.ts   # 领域数据模型
    └── shared/        # 跨领域共享域
        ├── components/# 跨领域复用组件
        ├── hooks/     # 跨领域复用业务逻辑
        ├── constants/ # 跨领域业务常量
        └── utils/     # 跨领域业务工具

这种设计完美的解决了一系列工程化问题：

跨领域能力下沉至 Shared 模块：如果在开发过程中发现某个业务组件或数据流在多个领域场景下（例如在新的 Page 中或另一条业务线）需要跨页面复用，正确的做法是：将这些原本属于某个独立 Domain 的可复用逻辑，提取下沉到 features/shared 目录下。新的页面或模块只需统一从 shared 模块中引入即可。这避免了各个领域模块间的相互依赖和深度耦合（例如避免 order 模块去引入 student 模块的内部实现）。
业务组件与工具的领域级收口：原本充斥在全局的业务组件，现在被收拢在 features/{domain}/components 或 features/shared/components 中。全局的 src/components 和 src/utils 彻底摆脱具体的业务逻辑限制，只留下纯粹的技术基础设施。
Page 与 Feature 的优雅协作：在这套架构中，Page 层被彻底“抽空”为一层极薄的容器壳。Page（位于 src/pages）不直接处理复杂的业务逻辑，只负责页面的入口路由、顶层状态实例化（如基于 Antd 的 Form.useForm() 制定的“Form 外置模式”）和基础的骨架排版。而所有的核心业务组件（如 DomainTable、DomainSearchForm）和数据获取流（如 useDomainList）都内聚在对应的 Feature 模块中。Page 就像是一个司令部，仅通过调用 Feature 暴露出来的清晰 API（Hooks）与预制 UI（组件），像搭积木一样将业务组装串联起来。这种严格的职责分离极大提升了代码的可读性和测试性，彻底杜绝了业务逻辑与视图状态揉捏在同一个文件里导致的“千行屎山”现象。

二、AI 的崛起，与 AI Skills 的诞生背景

Cursor、Claude Code、GitHub Copilot 等 AI 代码助手的普及，给开发者带来了开发效率的极大提升，但同时也暴露出了严重的问题：AI 是个“无状态”的超级程序员。

AI 编程痛点所在

喜欢堆砌代码（写千行大文件）：当你让 AI 帮忙写一个“带有列表和编辑的页面”时，如果没有明确的约束，它通常会把请求逻辑、组件渲染、各种 useEffect 全部写在一个 index.tsx 里。它直接破坏了你苦心孤诣设计的 Feature Mode 架构。
缺乏系统上下文：AI 不知道你的团队使用 onPageChange 还是 handlePageChange 命名；不知道你们用 !!value 进行简写判断；不知道你们需要“外置 Form”，于是写出了五花八门的代码，代码审查（CR）时的纠集与修改成本非常高。

AI Skills 的核心价值

正是在这种背景下，AI Skills（结合 OpenSpec 的工程规范） 应运而生。它的核心思想是：用系统约定的 Prompt 和技能规范，构建 AI 编程的护栏（Guardrails）。

通过在项目中建立 AGENTS.md、project.md 以及细分的 skills/ 文档：

统一代码规范（统一风格）：明确告诉 AI 项目的分层结构，严禁在 Page 级直接编写业务与请求。
提供确定与稳定的上下文：限制 AI 胡乱发挥的冲动。让它遵循如“返回格式必须包含 list, total, pageNo, pageSize”、“Form 必须通过 props 透传”的严格标准。
减少 Token 试错（提效提质）：让 AI 精准对焦在某一个小巧的 Feature 目录下工作，而不是去通读整个存量代码库从而产生幻觉。

三、珠联璧合：当 DDD 架构遇上 AI Skills

Feature Mode（DDD架构）与 AI Skills 的相遇，并非偶然，而是相互成就的终极组合。我们可以看作是高质量的架构为 AI 提供了发挥的沙盒，清晰的 AI Skills 确保了沙盒游戏规则不可逾越。

AI 是 DDD 落地的最佳实践者
由于特征模式强调“内聚的、拆分的物理小文件”，这对人类其实是一种心智负担——我们要手动创建三四个目录、导出各种文件。而现在？开发者只需要写好一份业务的 spec.md 需求文档交给 AI，AI 能瞬间遵循 AI Skills 的约定，生成出极为漂亮的领域拆分代码。开发者变成了架构师与审查员，AI 变成了码农。
Feature Mode 是最适合 AI 分析的范式
对于 LLM 的上下文窗口而言，理解一个高达百兆的全盘项目很容易使其丢失焦点。而在 Feature Mode 架构下，AI 在处理任何一个业务需求时，都可以被精准地限制在一个按特定领域划分的代码目录树之下。这种高度内聚且“局部自闭环”的设计天然契合 AI 的工作方式：每一个 Feature 模块都独立封装了该领域专属的组件（components）、状态（hooks）、接口（services）和类型（types），形成了一个微小且完备的上下文沙盒。当 AI 在这个局部自闭环沙盒中进行代码推演、生成或重构时，无需跨越遥远的文件树去寻找复杂的外部依赖，其推理的思维链（Reasoning）连贯性会得到极大增强。这不仅大幅降低了产生幻觉和代码 Bug 的概率，更让 AI 模型卓越的局部代码工程能力得到了最极致的发挥。

四、总结与未来展望

总结
现代前端工程的难点不在于如何实现一个按钮，而在于如何在一个数百名工程师参与、生命周期长达数年的中后台系统里，保证代码的腐化速度慢于重构的速度。

通过 Feature 驱动的组件与逻辑分层（DDD），我们把代码治理得井井有条，实现了高内聚低耦合的业务与跨页面复用；通过引入 AI Skills / OpenSpec 规范化约定，为 AI 工具挂载了系统记忆和“项目戒律”，消除了 AI 随意破坏架构的隐患。两者结合，在效率和质量之间找到了完美的平衡点。

这里需要强调一个个人观点：对于庞大的存量项目，我们切忌盲目追求用 AI 去强行生成新功能。真正的“磨刀不误砍柴工”，是首先借助 AI 强大的代码理解与重构能力，完成老旧架构的升级（向 Feature Mode 迁移），统一团队底层的代码规范，夯实项目的“地基”。只有在坚实稳固的地基和明确的边界约束（AI Skills）之上，我们再去探索“如何借助 AI 更好地完成业务开发”，才能避免系统走向积重难返的技术债深渊，真正做到在享受 AI 带来开发提效红利的同时，依然能保证项目随时可以被低成本地人工接手与维护。

未来展望
在不远的未来，随着大模型的推理能力进一步进化，前端开发的工作流将发生实质性转变：

从 "Code-First" 到 "Spec-First"：开发者不再将精力陷入敲击 React Hooks 和 CSS 的琐碎工作中，重心将转移到梳理业务逻辑的“边界”、写好定义清晰的 Specification 文档，即真正的规范驱动开发（SDD）。
架构治理的自动化：工程师将化身为 Prompt 工程师与业务架构师的结合体。你只需关注如何精准定义领域模型、如何调优 AGENTS.md 里 AI Skills 条款、以及确保业务需求的正确传递。执行层的拼装复用、增删改查全权委托给被深刻约束在这个架构里的 AI Agents。

这是代码编写走向“工业化”组装的重要一步，DDD 的理念与 AI 的智能交织，正在重塑属于开发者的下一个黄金时代。

附录：以本项目的落成为例 —— AI 多模型协同落地的实战工作流

上面探讨了方法论，回落到实践，本项目（包括你现在看到的这篇文章结构和底层的代码脚手架）本身就是“人机协同”、“多模型合作”的最佳产物。笔者在整个项目中的代码贡献量小于3%，更多的是通过不断的与AI对话，来指导AI完成代码的生成与调优。以下展示了如何将多个顶尖大模型各司其职，从零到一构建并提炼出一个完整的 Feature Mode 架构与 AI Skills 规范工程体系：

核心工作流程图

详细实操五步曲

项目骨架设计 (Architecture Design)
结合中后台业务的实际情况与痛点，首先与 ChatGPT 和 Gemini 展开对话，梳理出符合 DDD 思想的 Feature Mode 的理论支持，并由它们生成一份包含 src/features 和 src/pages 职责彻底分离的初始项目目录结构方案。
代码 Demo 生成 (Code Generation)
将确定的目录结构抛给 智谱大模型 (GLM-4)，让它快速充当“打字机”角色。根据目录树结构，它能迅速生成具有依赖注入特征和 Form 外置模式的初始项目 Demo（包含基础路由、useDomainList 的状态封装和 Ant-Design 表单渲染）。
代码深度调优 (Code Refactoring)
初版的 AI 代码往往伴随有细微的类型安全、废弃属性等问题。在此阶段，我们引入擅长上下文感知的 Cursor（或其他顶尖代码模型，如多轮智谱交互）作为 IDE 伴侣。通过人工 CR 以及 AI 自动修复（例如把冗余的状态逻辑通过 !!value 化简，或者把 destroyOnClose 替换为 destroyOnHidden），确保项目符合极其严苛的工业级代码要求。
规范反向提取与 AI Skills 的生成 (Skill Extraction)
有了完善运行的成熟代码系统作为“存量参考”，我们利用长文本能力极其出色的 Kimi（K 2.5） 模型，将项目的核心目录源码，结合社区顶级的代码规范（如 vercel-react-best-practices 模板）丢给它。让 Kimi 从代码实现中反向提炼出一整套适用于当前项目的体系化 skill.md 与工程约束文档，形成自己的 AI Skills。
总结与文章生成 (Documentation output)
最后一步，为了记录这个完整的架构跃迁，我们将整个项目结构以及提炼出的 Skills 文档，输入给强无敌的 Google Antigravity 内置模型 (Gemini 3.1 Pro)。告诉它以高级架构师的视角帮忙生成一篇文章。并在生成后，通过多轮自然的对话（即本对话框的交互流），不断润色、修补错漏细节、加入针对存量项目的个人重构观点，最终得到了这份兼顾深广与实践经验的“最佳实践”结晶。

文末寄语

“多少事，从来急；天地转，光阴迫。一万年太久，只争朝夕。”

在 AI 技术日新月异、生产力范式发生根本性变革的当下，面对时代的巨轮，我们不应观望徘徊。借此诗词与诸君共勉：让我们以时不我待的精神积极拥抱 AI，在技术博弈的方寸之间，只争朝夕，不负时代。

参考资料

项目代码：https://github.com/forever-project/feature-mode-temp
AI Skills 规范：参见项目 ai-skills/ 目录
DDD 参考：《领域驱动设计》Eric Evans

重构前端工程：DDD、Feature Mode 与 AI Skills 的深度融合