当AI成为开发伙伴，我们的代码架构该向何处去？

当AI成为开发伙伴，我们的代码架构该向何处去？

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

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

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

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

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

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

这篇文章，我想聊聊在这个AI与人类混合编程的时代，我对代码架构的一些重新思考。

先回顾一下：我们曾经追求过什么

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

第一阶段：能跑就行

最朴素的诉求是：

• 别让我从零配置webpack/vite
• 路由、状态管理、HTTP请求最好有人帮我搭好架子
• 登录、权限、布局这些通用模块不要重复造轮子

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

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

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

第二阶段：组件海洋

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

• 几十种图表组件
• 十几种编辑器集成
• 拖拽看板、可视化配置、地图集成
• 主题切换、多语言示例

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

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

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

第三阶段：工程化觉醒

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

• 页面保活不只是简单的开关，而是需要精细化策略
• 权限系统需要支持路由、菜单、按钮的多层控制
• 多标签页应该能管理状态，而不是简单缓存
• 组件库不应该和框架锁死，否则换肤都困难

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

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

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

但现在，我遇到了新的困境

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

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

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

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

问题一：过度抽象反而让AI难以理解

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

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

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

问题二：隐式约定成了黑盒

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

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

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

问题三：业务逻辑散落各处

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

• 表单定义在一个文件
• 校验规则在另一个文件
• 提交逻辑在store的action里
• 错误处理在工具函数中
• 成功后的跳转逻辑又在组件里

人要拼凑出完整画面已经很吃力，AI更难。它可能只看到了局部，就给出了看似合理但实际错误的建议。

我开始尝试的新方向

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

方向一：垂直切片，而不是水平分层

传统分层架构（UI → 逻辑 → 数据 → API）是按技术职责切的。我现在更倾向于按业务特性切：

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

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

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

方向二：显式优于隐式

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

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

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

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

方向三：为AI准备项目地图

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

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

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

• 代码生成规范（文件命名、导出方式、错误处理模式）
• 常见任务的实现模式（新增页面、新增API、新增表单）
• 需要注意的边界情况
• 不应该触碰的区域

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

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

方向四：接受一定程度的“冗余但清晰”

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

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

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

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

方向五：把高频任务变成“技能包”

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

• 新增列表页：一个脚本生成标准结构的文件，包含搜索、表格、分页、CRUD操作
• 新增表单：基于schema生成表单页面，自动处理校验和提交
• 新增弹窗流程：一套标准的多步骤弹窗模板

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

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

一个具体的例子：列表页开发

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

1. 创建组件文件
2. 定义表格列
3. 写搜索表单
4. 接分页逻辑
5. 写增删改查API
6. 处理加载和错误状态
7. 处理权限控制

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

现在我的做法是：

单个文件包含该页面的所有核心逻辑（200-300行以内）。搜索、表格、分页、API调用都在同一个文件里，只是用<script setup>的组织结构来区分区块。

<!-- UserListPage.vue --> <script setup lang="ts"> // === 类型定义 === interface User { id: number name: string email: string } // === API 调用 === async function fetchUsers(params: any) { return api.get('/users', { params }) } async function deleteUser(id: number) { await api.delete(`/users/${id}`) refreshList() } // === 搜索状态 === const searchForm = reactive({ name: '', status: '' }) const handleSearch = () => { currentPage.value = 1; refreshList() } // === 表格状态 === const tableData = ref<User[]>([]) const loading = ref(false) const currentPage = ref(1) const pageSize = ref(20) // === 刷新逻辑 === async function refreshList() { loading.value = true try { const res = await fetchUsers({ page: currentPage.value, ...searchForm }) tableData.value = res.data } finally { loading.value = false } } // === 生命周期 === onMounted(refreshList) </script> <template> <!-- 搜索区 --> <!-- 表格区 --> <!-- 分页区 --> </template> 

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

• 定位快：所有相关逻辑在一个文件里
• 修改稳：改分页逻辑不会影响其他页面
• AI友好：AI能看到完整上下文，不需要跨文件推断
• 重构容易：当真正需要抽象时，模式已经很明显

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

关于AI时代的几个判断

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

判断一：代码的“可理解性”比“优雅”更重要

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

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

判断二：“适度重复”将成为新的默认选择

过去DRY（Don’t Repeat Yourself）是金科玉律。但DRY的代价是增加间接层和耦合度。

现在我会更倾向于WET（Write Everything Twice），第三次再考虑抽象。因为：

• 两次重复的成本很低
• 模式在第三次时才真正清晰
• AI可以快速帮忙重构，抽象变得廉价

判断三：文档不再是“写完就过时”的负担

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

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

判断四：框架的竞争力将从“功能多”转向“可理解”

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

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

• 清晰的目录结构和命名约定
• 显式的配置而非隐式魔法
• 为AI准备的项目描述文件
• 高频任务的标准化模板

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

最后：我的架构原则（2026版）

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

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

1. 垂直优先：按业务特性组织代码，而不是按技术角色
2. 显式优于隐式：宁可多写几行，也不制造魔法
3. 局部完整优于全局抽象：一个文件能说清楚的事，不要拆成五个
4. 重复三次再抽象：让模式自然浮现，而不是提前设计
5. 为AI准备地图：项目元信息、决策记录、生成规范
6. 高频任务模板化：把常见流程沉淀成可执行的资产
7. 接受不完美但可理解：优雅是追求，但不是枷锁

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

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

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

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