2025 年快结束的时候，我回头看了一眼这一年的代码量，突然意识到一件事：
我写的代码可能变少了，但解决的问题变复杂了。
这是我第一次明确感觉到——
前端工程师的成长，真的进入了下一个阶段。
一、这一年，我写得最多的不是页面
如果用几个关键词概括我 2025 年的工作内容：
- Vue3 / React 仍然在写
- 表单、列表、弹窗一个不少
- 但真正消耗精力的，不再是 UI
而是这些：
- 复杂数据结构怎么设计
- 状态该不该存在
- 计算逻辑放前端还是后端
- 改一个需求会不会影响隐蔽分支
前端越来越不像“切图”，而像“建模”。
二、一个真实变化：我开始先画“逻辑”，再写代码
这一年我明显养成了一个新习惯：
需求一来，先不写代码。
以前我会直接开文件、起组件；
现在我会先把这三件事想清楚：
- 数据结构长什么样
- 哪些是不可变约束
- 哪些是 UI 层可以随便改的
比如在一个复杂的评分 / 概率 / 封顶计算需求里，我会先明确：
// 哪些是规则
const MAX_INPUT = 15000
const PROB_A = 0.9
// 哪些是变量
asset
profit
然后才去写代码。
这个转变，让我后面几乎不需要推翻重写。
三、AI 真正介入我工作的方式，不是“帮我写”
2025 年我用 AI 最多的场景，其实不是生成代码，而是这几类问题：
- “这个设计有没有隐含 bug？”
- “这个状态是不是根本不该存在？”
- “这个逻辑在极端情况下会不会炸？”
比如在 Element Plus 的动态表单里，我遇到过这种问题：
<el-form-item :prop="`goalList.${index}.value`">
删除中间项后校验异常、DOM 报错。
我把问题描述给 AI 后，它第一反应不是改代码，而是提醒我：
“prop 是字符串路径，index 变化会导致引用失效。”
这让我意识到：
AI 更适合站在“代码审查者”的位置。
一、真实场景：一个“看起来很普通”的表单
这是一个我在真实项目里遇到的需求：
- Vue3 + Element Plus
- 动态数组表单（可新增 / 删除）
- 每一项都有校验
- 校验字段路径是动态的
- 删除后不能影响其他项的校验
一开始的代码，大概是这样的 👇
<el-form :model="form" ref="formRef">
<div v-for="(item, index) in form.goalList" :key="item.id">
<el-form-item
:label="`目标${index + 1}`"
:prop="`goalList.${index}.goalContent`"
>
<el-input v-model="item.goalContent" />
</el-form-item>
<el-button @click="remove(index)">删除</el-button>
</div>
</el-form>
问题很快就来了：
- 删除中间一项后
- 校验报错指向错误的 index
- 有时直接报：
DOMException: String contains an invalid character
二、以前的我：开始“盲修”
老实说，这种问题以前我的处理方式是：
- 打 log
- 猜原因
- 搜关键词
- 一点点试
但这一次，我换了种方式。
三、我第一次把问题“交给 AI 先推演”
我没有让 AI 改代码，而是直接把问题描述给它：
“这是一个动态数组表单，
使用 Element Plus，prop 是动态字符串，
删除中间项后校验会异常，
你先别改代码，帮我分析可能的根因。”
它给我的第一条结论就是：
“prop 路径是字符串，会被当成 DOM selector 的一部分，
特殊字符或 index 变化都可能导致异常。”
然后它提醒我两个点：
key是否稳定prop是否和v-model完全一致
四、真实修复：稳定 key + 显式数据路径
我最后采用的是这一版方案 👇
1️⃣ 保证 key 永远稳定
function addGoal() {
form.goalList.push({
id: Date.now(), // 永远不变
goalContent: ''
})
}
<div v-for="(item, index) in form.goalList" :key="item.id">
2️⃣ 明确 prop 只指向数据模型
<el-form-item
:prop="`goalList.${index}.goalContent`"
>
<el-input v-model="form.goalList[index].goalContent" />
</el-form-item>
而不是直接用 item.xxx。
3️⃣ 删除时，手动清理校验状态
这是我以前经常忽略的一步：
function remove(index: number) {
form.goalList.splice(index, 1)
nextTick(() => {
formRef.value?.clearValidate()
})
}
👉 这一步是 AI 特别提醒我的。
五、技术成长最大的变化：从“写法”到“选择”
如果说前几年我的成长重点是：
“我会不会这个技术？”
那 2025 年，问题变成了：
“我该不该这样做？”
比如：
- 一个状态，是不是本来就不该进前端？
- 一个复杂计算，是否应该先抽象成纯函数？
- 一个组件，是不是已经过度封装？
这些问题，没有标准答案，但会直接决定项目质量。
而 AI 的价值在于：
它可以陪我把所有选项都推一遍。
六、Vibe Coding 对我来说，不是快，是“稳”
很多人理解 Vibe Coding 是“写得飞快”，
但我自己的感受恰恰相反。
我 2025 年写代码的状态更像是：
- 节奏稳定
- 很少被卡住
- 很少“越改越乱”
因为在真正敲代码之前，
80% 的坑已经被提前发现了。
这是一种很微妙的变化：
不是技术突然跃迁，而是心态开始变从容。
七、这一年我对“前端工程师”的重新认识
2025 年让我彻底确认了一件事：
前端工程师的核心竞争力，
不是写组件的速度，而是对复杂度的判断力。
AI 能写组件、补逻辑、找语法错误；
但它替代不了你去判断：
- 什么是必要复杂度
- 什么是可以删掉的复杂度
而这，恰恰是成长的分水岭。
结语：这是我前端生涯的一个分水年
2025 年不是我学到最多 API 的一年，
但很可能是我：
- 写代码最顺的一年
- 犯低级错误最少的一年
- 对“技术”理解最清晰的一年
前端没有消失，
只是开始变得更接近“工程”。
而 AI，让我第一次觉得：
我不是在追着技术跑，而是在和它并肩走。
这，就是我 2025 年的
前端 · Vibe Coding · 年度总结。
