过去三年，我一直在维护一套内部的后台管理系统。从Zui初几个人快速搭建的MVP，到现在支撑着公司六个业务线的核心运营，这个系统经历了一次彻底的重构。

重构的原因hen简单：代码变得“不可爱”了。

不是不Neng跑，而是每次加新功Nengdou像在雷区里跳舞。改一行代码，影响三个不相关页面；想引入一个新思路，发现老架构处处掣肘；团队成员越来越多，但代码的可理解性却在直线下降。

这让我开始思考一个geng本质的问题：

当我们的0代码不再只被人阅读，AI也将成为日常协作者时架构应该为什么而设计？

这不是一个遥远的技术幻想。Cursor、Copilot、WindsurfYi经深度嵌入到我的日常开发中。它们读代码的速度比我快百倍，但它们“理解”代码的方式和人截然不同。

这篇文章，我想聊聊我对代码架构的一些重新思考。

在谈未来之前，有必要理清我们走过的路。这里以我熟悉的React/Vue生态下的中后台项目为例。

从“Neng跑就行”到“Nengkan懂才好”

Zui朴素的诉求是：

这个阶段的代表是各种starter kit和脚手架工具。它们解决的是“生存问题”——让项目Neng快速启动。

我记得hen清楚，2018年我第一次用某后台模板时Zui大的惊喜是：原来菜单Ke以自动根据路由生成。这件事在今天kan来理所当然但在当时它意味着我不再需要手动维护两份会逐渐失步的数据。

这一步的关键贡献证明了框架Ke以通过约定来消除重复劳动。

“应有尽有”的陷阱

随着UI框架成熟，这个阶段的特点是“应有尽有”：

坦白说我早期也迷恋过这种“强大”。但后来我发现一个尴尬的事实：一个项目里真正用到的组件，通常不超过框架示例的20%。而那些真正高频的需求——列表页的表单搜索、表格列配置、弹窗管理——框架反而帮不上太多忙。

这个阶段Zui大的问题是：用“广度”掩盖了“深度”。

kan起来什么douNengZuo，但Zuo什么dou需要自己再写一遍胶水代码。框架成了一个漂亮的样品间，而不是趁手的工具箱。

从“NengZuohen多事”到“Neng把核心事Zuo好”

大约从2021年开始，大家开始关注geng实在的问题：

我开始理解一个道理：真正影响长期体验的，往往是那些kan不见的设计决策。

比如页面保活。Ru果只是提供一个keepAlive: true，确实Neng满足80%的场景。但真实业务中，从列表进详情希望列表保活，从列表跳到外部模块希望列表释放，用户手动关闭标签页时缓存该何去何从——这些细节决定了产品经理会不会经常来找你“提个小小的需求”。

这个阶段的进步是：框架开始从“NengZuohen多事”转向“Neng把核心事Zuo好”。

AI来了代码还Neng不Neng好好说话？

上面这些演进douhen有价值，但它们有一个共同的隐含假设：

代码 是给人读的，然后顺便给机器执行。

这个假设在过去基本成立。但今天AIYi经在大量阅读和生成代码。我的团队里大约40%的代码是由AI辅助完成的。Cursor的Composer一次Neng处理多个文件，ClaudeNeng理解整个项目的上下文。

这时候，我发现了三个新问题：

1. 抽象太多，AIkan不懂

为了提高复用，我们习惯Zuohen深的抽象：基础组件、业务组件、逻辑组合、状态管理、工具函数……一个简单的按钮点击，可Neng跨越五六个文件。

人Ke以通过IDE的跳转功Neng勉强跟上，但AI在处理这种碎片化代码时上下文经常断裂。它会漏kan某个mixin里的逻辑，或者忽略某个高阶组件传递的props。

geng讽刺的是抽象本来是为了减少重复、提升可维护性，但过度抽象反而增加了认知负担——无论对人还是对AI。

2. 魔法太多，AI猜不到

hen多框架有自己的“魔法”：通过文件路径自动注册路由、通过命名规范自动注入依赖、通过装饰器自动处理权限。

这些约定用熟了hen爽，但对AI来说这些dou是隐式知识。除非这些约定被明确写进项目文档，否则AI生成的代码大概率不符合规范。

我遇到过太多次：AI生成的页面跑不起来因为忘记在某个配置文件里注册路由，或者缺少某个特定的export。

3. 分层太深，AI拼不全

经典的“关注点分离”告诉我们：UI、状态、逻辑、数据访问应该分开。但在实践中，一个完整的业务特性经常被拆得七零八落：

人要拼凑出完整画面Yi经hen吃力，AIgeng难。它可Neng只kan到了局部，就给出了kan似合理但实际错误的建议。

我现在的Zuo法

基于这些观察，过去一年我逐步调整了架构思路。不一定全对，但确实让团队和AI的协作顺畅了hen多。

按业务特性组织代码

传统分层架构是按技术职责切的。我现在geng倾向于按业务特性切：

features/
├── user-profile/
│   ├── UserProfilePage.vue    # 页面组件
│   ├── useUserProfile.ts      # 该特性专用逻辑
│   ├── userProfileApi.ts      # 该特性的API调用
│   ├── userProfileTypes.ts    # 类型定义
│   └── userProfileStore.ts    # 状态
├── order-list/
│   └── ...
└── shared/                    # 真正的共享内容
    ├── components/
    └── utils/

这样Zuo的效果是：一个完整的业务Neng力集中在同一个目录下。当AI需要修改“用户资料”功Neng时它Nengkan到所有相关文件，而不是在整个项目里散落。

代价是会有一些重复代码。但我越来越觉得，重复比错误抽象geng便宜。重复Ke以被AI快速识别和重构，而错误的抽象会让整个项目越来越僵硬。

少点魔法，多点显式

我开始减少“魔法”，增加显式声明。

比如路由注册，以前可Neng是自动扫描文件夹，现在我会在router/index.ts里显式导入和注册。虽然多写几行代码，但AINeng清楚kan到路由结构，不会凭空猜测。

比如权限控制，以前可Neng藏在指令或全局混入里现在我geng倾向在组件里显式调用canAccess。代码变啰嗦了但可读性和可推断性大大提升。

一个原则Ru果AI需要通过“猜测”才Neng理解某段逻辑，那对人来说也迟早会成为负担。

文档先行，AI才kan得懂

我们给项目增加了几个重要文件：

PROJECT.md给人kan的高层概览，技术栈、目录结构、核心概念。

AI_CONTEXT.md专门给AIkan的详细说明，包括：

ARCHITECTURE_DECISIONS.md记录关键架构决策和当时的考量，避免AI不理解为什么要这么写。

这些文档放在仓库根目录，并在.cursorrules里明确告诉AI优先阅读。效果hen明显：AI生成的代码风格geng统一，第一次跑通的概率从60%提升到了85%以上。

重复没关系，别搞错就行

过去我会极力避免重复代码。现在我设了一个阈值：重复不超过3次Ke以接受；超过3次再考虑抽象。

geng重要的是：抽象应该是“收集共识”的结果，而不是“提前设计”的产物。

先让代码自然地重复出现，当你真的kan到了模式，再Zuo抽象。这时候的抽象往往geng准确，也geng容易被理解。

这对AI同样友好：AIkan到几个相似的实现，Neng自己出模式；但Ru果kan到一个高深莫测的抽象层，它可Neng完全迷失。

模板即规范

我们团队整理了一份“常见任务清单”，不是文档，而是一组可执行的模板和脚本：

这些东西和框架解耦，geng像是一套“团队规范”的具象化。新人来了Ke以直接用，AI也Ke以参考这些模板来生成代码。

本质上，这是把隐性知识变成了显性资产。

单文件大法好

以前开发一个标准列表页，我需要：

分散在4-5个文件里每个文件还有自己的抽象层次。

现在我的Zuo法是：

单个文件包含该页面的所有核心逻辑。搜索、表格、分页、API调用dou在同一个文件里只是用

这不是Zui“优雅”的写法，但它的好处是：

Ru果这个文件超过500行，那时候再考虑拆分。但实际上，一个标准列表页hen少超过300行。

我的几个判断

基于这一年的实践，我有几个不一定对的判断：

1. 代码不是写给机器kan的

优雅往往是简洁+抽象，但简洁不等于易懂，抽象不等于正确。

代码不仅要让人Nengkan懂，还要让AINeng“kan懂”。而AI理解代码的方式是扫描上下文、寻找模式、建立关联。显式的、局部的、完整的代码，比分散的、抽象的、依赖约定的代码，geng容易被AI正确处理。

2. DRY不是万Neng的

过去DRY是金科玉律。但DRY的代价是增加间接层和耦合度。

现在我会geng倾向于WET，第三次再考虑抽象。因为：

3. 文档是代码的伴侣

以前文档总是落后于代码，因为geng新成本高。但现在我Ke以用AI维护文档——每次PR合并时让AI检查是否需要geng新AI_CONTEXT.md。

文档变成了代码的伴侣，而不是事后补充。这对人和AIdou有价值。

4. 框架应该成为人与AI之间的共同语言

一个框架再强大，Ru果AI无法正确使用它，它的价值会打折扣。

未来框架应该提供的不只是组件和工具，还应该包括：

框架应该成为人与AI之间的共同语言，而不仅仅是一套技术实现。

Zui后

回到Zui初的问题：当AI成为开发伙伴，我们的代码架构该向何处去？

我给自己的答案是七个原则：

这些原则不一定适用于所有项目。大库、超大规模团队、性Neng极致场景，可Neng需要不同的取舍。

但对绝大多数中后台业务系统来说我越来越相信：

Zui好的架构，不是ZuiNeng炫技的，而是Zui容易被人和AI一起理解和改进的。

因为Zui终，代码的生命力不在于它写得有多聪明，而在于它是否经得起持续的修改——无论是人的手，还是AI的算法。

---