从古法编程到 vibecoding：一个前端程序员的范式转变

我从移动端转到前端后，做了多年业务前端开发。前几年的工作流大致稳定：查文档、写代码、调 lint、修 type。从今年我开始用 Claude Code，工作流被打散重组，到现在我花在写 CLAUDE.md 上的时间比写 Vue 组件还多。这篇文章记录我最近的转变，不是教程，不是结论。

古法编程是什么样子

写一个 Vue 组件，传统流程是这样：

在 VS Code 里敲，Volar 实时标红——props 类型不对、模板里变量拼错、ref 忘了 .value。hover 一下看报错，改。跑 pnpm dev，浏览器控制台一堆 warn，v-for 没给 key、watch 依赖不对，再改。提交前 pnpm lint 又红一片，逐条修。改完跑 tsc --noEmit，再红一片。提交时 pre-commit hook 拦一次，CI 再拦一次。

这套流程的本质是：人写代码，工具兜底。lint、typecheck、test 是三条独立防线，每条都假设上游会出错。你跟工具博弈，它告诉你哪里不对，你改。

成熟、可教、可复制。问题是慢——一个组件从想法到合并，光在工具博弈上就能耗掉半小时。

vibecoding 是什么样子

现在我写一个 Vue 组件，流程变成这样：

在 CLAUDE.md 里写清楚项目用 Vue 3 + TS、<script setup> 优先、不写 Options API、import.meta.env 不许散布。在栈级 SKILL.md 顶部写一段《代码风格》：缩进 2 空格、单引号、分号必带、const 优先。在 eslint 配置里写好兜底规则。然后对 Claude 说：”写一个用户列表组件，分页，搜索框防抖 300ms。”

它写。我 review。它自己跑 lint、跑 typecheck、跑测试。hook 在它写完文件后自动 format，在它 git commit 前自动 lint。

本质变了：LLM 写代码，工具兜底，人写规则。我不再跟工具博弈，变成了给 LLM 写规则、给工具配兜底的人。CLAUDE.md 是给 LLM 的项目宪法，SKILL.md 是栈级风格指南，工具配置是兜底的硬墙。

转变落在三个地方

不是工具换代，是工种换位。

写什么：从代码到规则

组件代码由 LLM 生成，我写的是 CLAUDE.md、SKILL.md、工具配置。产出物从”代码”变成”约束代码的规则”。这听起来像退后一步，实际是上升一层——同一个 Vue 列表组件会在十个项目里被写十遍，但”v-for 的 key 必须稳定、禁止 index”这条规则只写一次。代码是消耗品，规则是资产。代价也真实：写规则要把模糊的”我觉得这样不对”显式成可执行的约束，比写代码难。

调什么：从工具链到 LLM 行为

古法调 lint 规则、调 tsconfig、调 vite。现在调 hook 触发时机、调 sub-agent 上下文边界、调 SKILL 触发词、调 MCP 组合。前者成熟——ESLint 怎么配、tsconfig 哪个字段干嘛、vite 怎么优化，社区有十年答案，senior 能讲半小时。后者没成熟——hook 什么时机触发不误伤、上下文边界画在哪、触发词怎么写不漏不误，没有标准答案，社区还在试。调工具链是工程，调 LLM 行为是驯兽。工程有规范，驯兽靠观察。

怕什么：从报错到静默

古法怕运行时 bug、怕 type 不对、怕 lint 红一片。这些错误有一个共同点：会响。控制台报红、CI 挂、测试失败——显式的，看得见就能修。vibecoding 最怕的是 LLM 静默写错。比如你写了一条风格规则，表面上看 LLM 每次都”遵守”了，你以为生效了。实际上那条规则字段名写错了，工具根本不认，LLM 写对是因为训练数据里见过类似风格——是默认值的功劳，不是你规则的功劳。规则形同虚设，但你不会查，因为”看起来在工作”。显式的报错逼你修，静默的错误让你以为自己不用修。古法的错误大声告诉你，vibecoding 的错误是温水煮青蛙。

找不到最佳实践

转变后第一反应是找参考：GitHub 上肯定有人做过 vibecoding 最佳实践仓库吧？搜一遍，高星的要么是机制说明，要么是演示性质的例子，没有一套敢说”我在生产项目跑了半年，团队 5 个人用，这些规则真触发了，那些没触发”。高星不等于经过验证。

这不是大模型问题，也不是 agent 问题，是领域本身还没成熟。vibecoding 现在的状态，像极了 Vue 3 Composition API 刚出来的那阵——<script setup> 还没落地，ref 还是 reactive 吵成一团，composables 怎么拆没人有定论。社区摸索了一两年才有共识。vibecoding 现在就在那个摸索期，只是还没人知道要摸多久。

重起炉灶的陷阱

我开始这套配置时反复陷入一个循环：做一版，不满意，重起炉灶做第二版，又不满意，再做第三版。LLM 让”重起炉灶”变得极便宜——一句话，半小时新仓库就起来了。

直到有一天我意识到：每一版的问题都不是”基础选错了”，而是还没在真实项目里踩过坑。配置里那个字段名写错、那条规则没触发、那个 hook 漏匹配——都不是设计问题，是没用过真实项目的副作用。重起炉灶会让我再次绕开这一步，换个目录名，问题原样复制过去，再加一层”这次肯定对了”的幻觉。

这是 vibecoding 时代最常见的陷阱：用再找一个更好的方案，来推迟开始真用的不适感。便宜的动作容易上瘾，上瘾的结果是永远停在原型阶段。古法时代重起炉灶成本高——重构一个 vite 配置能调三天，所以你会先把现有配置改透。现在这个摩擦消失了，副作用是失去”逼你深入”的外力。

现状的尴尬

承认一下：工具链不成熟（ESLint flat config 还在迁移期，eslint-plugin-vue 的某些规则也跟着调）；最佳实践不存在（不是”我没找到”，是”行业还没有”）；护栏覆盖不全（Claude Code 的 hook 只在它调 Bash 时触发，同事用 VS Code 提交按钮或终端直接 git commit，完全绕过）。这些不是 bug，是阶段。

古法教会我的事

古法 7 年，我以为学到的是 Vue、TypeScript、vite。转变后我才看清，古法真正教我的是三件事：

敬畏报错。 lint 红了、type 错了、测试挂了——这些显式的报错是朋友不是敌人。vibecoding 时代最大的风险是它不响了，所以我把工具链配得比以前更严，宁可噪音多一点，也不能让错误静默。

规则要显式。 古法时代很多团队默契是隐式的——“我们这里不这么写”。vibecoding 时代隐式默契失效，LLM 不读空气。必须把所有”我觉得这样不对”显式成可执行的规则，这逼着把团队的隐性知识沉淀成显性资产。

慢动作有价值。 古法查文档、看 type、调 lint 这些”慢”的动作，其实是加深理解的过程。vibecoding 时代 LLM 帮你跳过这些，效率上去了，理解没跟上。我现在刻意保留一些慢动作——比如重要决策先手写一遍思路再让 LLM 实现——就是为了不让自己变成只会审 AI 代码的人。

下一步

不是再找一个更好的方案。是开始用。

接到一个非关键项目里——不是主力 SaaS，是内部工具或 side project。跑一周。看哪些规则真触发了，哪些没触发。看同事用 VS Code 提交时护栏失效是不是真问题。看 strict 模式在真实老代码上是不是噪音过载。

撞墙。改。再撞。

vibecoding 最佳实践今天还不存在到能被”找到”的程度。它正在被几千个开发者各自摸索，我也是其中一个。这篇文章是我摸索的中途笔记，不是终点。