当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也可以参考这些模板来生成代码。
本质上，这是把隐性知识变成了显性资产。
一个具体的例子：列表页开发
以前开发一个标准列表页，我需要：
- 创建组件文件
- 定义表格列
- 写搜索表单
- 接分页逻辑
- 写增删改查API
- 处理加载和错误状态
- 处理权限控制
分散在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成为开发伙伴，我们的代码架构该向何处去？
我给自己的答案是七个原则：
- 垂直优先：按业务特性组织代码，而不是按技术角色
- 显式优于隐式：宁可多写几行，也不制造魔法
- 局部完整优于全局抽象：一个文件能说清楚的事，不要拆成五个
- 重复三次再抽象：让模式自然浮现，而不是提前设计
- 为AI准备地图：项目元信息、决策记录、生成规范
- 高频任务模板化：把常见流程沉淀成可执行的资产
- 接受不完美但可理解：优雅是追求，但不是枷锁
这些原则不一定适用于所有项目。大库、超大规模团队、性能极致场景，可能需要不同的取舍。
但对绝大多数中后台业务系统来说，我越来越相信：
最好的架构，不是最能炫技的，而是最容易被人和AI一起理解和改进的。
因为最终，代码的生命力不在于它写得有多聪明，而在于它是否经得起持续的修改——无论是人的手，还是AI的算法。
