2026年初春，当 AI 编程助手已经成为和 Git、IDE 一样基础的工具时，我突然意识到一个问题：如果现在的新人开发者从一开始就习惯了用自然语言生成代码，那么作为“手写时代”过来的我们，所谓的“经验”和“手感”到底还有什么价值？我们会不会像当年那些守着汇编语言鄙视 C 语言的老师傅一样，最终被时代的列车甩下？
在过去的一年里，我高强度地使用了各类 AI 编程工具，从简单的代码补全到复杂的项目脚手架生成。经过大量的实践和反思，我逐渐摸索出一套新的生存法则：前端开发的竞争点，已经从“谁能更快写出正确的代码”，转变为“谁能更精确地描述世界，并审核 AI 生成的逻辑”。
本文将分享我在实际项目中总结的三个核心思维转变，希望能给同样在迷雾中探索的同行们一点启发。
一、 从“面向语法编程”转向“面向意图编程”
在以前，我们学习前端的很大一部分精力是消耗在语法细节和API 记忆上的。比如 Array.prototype.splice 和 slice 的区别、CSS Flex 布局中 justify-content 和 align-items 的各种组合效果、Webpack 繁杂的配置项……这些“八股文”知识曾经构成了面试的壁垒。
但现在，AI 几乎能瞬间生成 100% 正确的样板代码和工具函数。面对这种冲击，我的应对策略是抽象层级的上移。
反面案例（无效努力）：
试图比 AI 更快地手写出一个复杂的正则表达式，或者在不查阅文档的情况下精准写出 React.memo 的所有比较逻辑。这就像在现代战争中比拼谁的剑术更高超一样，虽有观赏性，但效率极低。
正面实践（意图驱动）：
在上周的 Tabs 组件重构中，我没有先打开 IDE 写 export default function Tabs()，而是打开了记事本，写下了这样一段“意图描述”：
我需要一个受控的 Tabs 组件。
当 Tab 数量超过 6 个时，头部必须支持横向滚动，且当前激活的 Tab 要自动滚动到可视区域内。
切换 Tab 时，内容区域不要立即销毁 DOM，要保留我之前填写表单的状态（keep-alive 逻辑）。
这涉及跨端，既要支持 Web，也要适配小程序的环境差异。
我把这段描述交给 AI 后，它生成了第一版代码。我的工作不再是写代码，而是审代码：
-
检查
scrollIntoView在 iOS Safari 上的兼容性表现（AI 可能会忽略 WebKit 的特定 Bug）。 -
检查
keep-alive逻辑在小程序端的实现是否符合 ARIES 框架的渲染机制（这是我独有的项目上下文知识）。 -
重构 AI 生成的大段
useEffect，将其封装为语义化的自定义 HookuseTabScroll。
结论： 我们的价值不再是“活字典”，而是架构师和QA。能够清晰地定义输入、输出和边界条件，并能敏锐地发现 AI 代码中的逻辑漏洞（尤其是跨端适配和性能陷阱），这就是新的护城河。
二、 拥抱“临时基建”：从“复用”到“速写”的思维解放
过去我们讲究封装、讲究复用、讲究设计模式，因为我们修改代码的成本很高。但在 AI 的辅助下，修改代码的边际成本正在趋近于零。
我在处理一个复杂的后台表单需求时深有体会。原本这个表单包含十几个联动项，按照传统思路，我可能会花 30 分钟设计一个通用的 FormContext 来管理状态，再用 1 小时处理校验逻辑的抽象。
但这次我换了一种思路：
-
我让 AI 直接生成了一段完全不考虑复用的“面条代码”，把所有联动逻辑通过
if/else和switch粗暴地硬编码在组件内。 -
我花 10 分钟阅读了这段 200 行的代码，确认逻辑正确。
-
我又对 AI 下达了新的指令：
“把刚才那段代码里关于城市选择的逻辑抽离成一个单独的 Hook，命名为 useCitySelector，并添加 TypeScript 类型约束。”
-
几秒钟后，重构完成。
反思： 这种“先污染，后治理”的开发模式，在过去是噩梦，但在今天却极其高效。AI 允许我们先快速验证功能的正确性，甚至快速搭建一个可交互的 MVP（最小可行性产品）去给产品经理确认。确认无误后，再通过自然语言指令瞬间完成重构。
掘友可能担心的点： 这样会不会导致项目里全是难以维护的垃圾代码？
回答： 不会。因为我们是人在做决策。我们的职责是设定重构的“时机”和“标准”。功能确认前，随意堆砌；功能确认后，一句话重构。这种动态平衡的能力，才是人类开发者区别于 AI 的核心智能。
三、 语境才是稀缺资源：成为“项目布道师”
目前所有 AI 工具最大的短板，不是算力不够，而是上下文长度和理解深度受限。AI 看不懂你整个项目庞大的 10 万行代码之间的隐式约定，它不知道你的后端同事有个坏习惯（比如返回的 userId 有时候是 String 有时候是 Number），它更不知道你们团队为了赶工期在 utils 里留了多少“坑”。
这些隐性的、肮脏的、业务特有的上下文信息，就是我们作为人类开发者的绝对优势。
我的具体做法是建立团队的 .ai/context.md 文件：
# 项目隐式约定 (AI 须知) 1. **API 返回格式**：尽管 Swagger 定义是标准的，但实际 `/api/v2/users` 接口在出错时，HTTP Status 仍是 200，需要检查 body.code 字段。 2. **时间处理**：项目中混用了 dayjs 和 moment，**新代码请务必使用 dayjs**，且在传给后端组件时需使用 `dayjs.tz` 转换为 'Asia/Shanghai'。 3. **样式规范**：严禁使用 `!important`，因为全局有 Tailwind 基础层，会被覆盖。
通过维护这份“AI 说明书”，我极大地提高了 AI 生成代码的可用性，减少了我手动修改隐式 Bug 的时间。我甚至发现，当团队新成员加入时，这份文档比 Wiki 更能帮助他们理解系统的真实运作方式。
最后的话
2026 年了，我们不必再为“前端已死”的论调焦虑。前端没有死，只是敲门砖变了。
以前，我们靠记 API 和刷 LeetCode 进入这个行业；
现在，我们靠对业务的理解、对工程体系的把控、以及对 AI 指令的精确调校能力站稳脚跟。
当代码的书写不再是瓶颈，关于“为什么要这么写”和“写出来会有什么后果”的思考，就成了最闪耀的价值。愿我们都能成为那个告诉 AI 该去哪里的领航员，而不是被 AI 替代的划桨手。
