有了AI Coding，前端规范还重要吗？设计稿可以直接扔了吗？
先说结论
我就是来抛砖引玉的，不是来定标准的。我自己的观点很简单——我觉得不用再搞独立的 Axure 原型图了，设计稿直接等于 Vue 组件代码。规范还是要的，但规范得是 AI 能直接遵守的那种规范，而不是写完还得人工改的约束。
下面聊为什么。
那你告诉我：你是图省事，还是图规范？
以前开发流程是这样的：产品画 Axure → 设计师出 MasterGo → 前端照着还原 → 后端骂前端还原得慢 → 产品骂还原度不够。
现在有了 AI Coding，你可以直接把需求写成 prompt，它给你生成一个完整组件。有跑偏的地方，再补一句就纠正了。
于是问题就来了——如果你还在严格遵守组件规范、设计系统、命名约定，那你可能陷入了一个尴尬的处境：AI 写的 80% 是对的，但你为了满足规范，还得手动改剩下 20%。
这就很蠢。AI 帮你省了时间，规范又给你加了回来。
设计稿的终点应该是代码，不是原型文件
我的第一个论断：独立的 Axure / MasterGo 原型，在 AI Coding 时代已经失去了存在的必要性。
为什么？因为原型的作用是"沟通设计意图"。以前你没法直接描述一个交互，所以得画出来让别人看。现在 AI 能通过自然语言理解你想要的交互，甚至比你画得还准。
比如你说："做个商品选择器，左边分类树，右边是卡片列表，点击卡片弹窗展示细节。" AI 直接就能生成 Vue 组件给你，结构、样式、交互一步到位。
而如果你已经画好设计稿，现在 AI 也能直接解析设计稿生成代码（Figma to Code / MasterGo to Code）。所以独立原型的意义被大幅压缩——设计稿就是个中间产物，AI 帮你在脑子里完成了"设计→代码"的映射，不需要转一手。
那规范怎么办？彻底不要了？
也不是。我觉得这里的关键是：规范得从"人遵守的规则"变成"AI 遵守的条件"。
以前的前端规范（BEM 命名、目录结构统一、组件粒度拆分、Props 类型收敛）是为多人协作设计的。你怕同事写的代码你看不懂，怕不同人写的组件风格不一致。
现在 AI 写了大多数代码，你是唯一的"人"。这时候规范的目标变了：
- 不需要的是：命名风格一致性（反正都是 AI 命名，你管它驼峰还是下划线？只要不报错就行了）
- 需要的是：AI 能理解的统一约定——比如统一的组件库入口、统一的 API 调用写法、统一的状态管理模式
人眼审查的时候，一眼能看出"哦这是弹窗"就行了。至于这个弹窗的 Props 叫 visible 还是 show——说实话，有 AI 帮你重构成统一风格，一键的事。
我的做法
维护一份 CONVENTIONS.md，给 AI 做 system prompt。里面写：用 Ant Design Vue，所有弹窗用 v-model:visible，API 请求走统一的 fetcher，文件按 feature 组织。
这样 AI 第一次生成的代码就大体符合要求，不用回头改。
AI Native那通用组件呢？还有必要维护吗？
有，但粒度要变粗。
以前我们拆组件的原因是"为了让代码复用"，现在 AI 可以随时生成一个一模一样的组件，复用的成本几乎为零了。那为什么还要抽象？
答案是：为了修改。
如果你的 100 个页面都有同一个"确认弹窗"，但它们的代码都是 AI 独立生成的，没有抽离。有一天你要改这个弹窗的样式——你就要改 100 个文件。AI 可以帮你批量改，但效率远不如改一个组件。
所以通用组件还是要的，但不需要做得太细。粗粒度的业务组件就够了，细粒度的工具函数让 AI 自己去生成。
更好的路径：AI-First 设计流程
如果按照上面的思路，一个 AI Coding 时代的理想流程长这样：
需求描述（语言） → AI 生成代码（初版）
↓
人工审查（看效果，不看代码）
↓
文字修正（改这里，加那里）
↓
AI 生成最终版
↓
可选：AI 生成文档/原型图（给测试看）
注意最后一步：原型图反而成了"生产的副产品"，而不是前提。你需要给不懂技术的同事看的话，可以让 AI 把代码渲染成截图或者自动生成 Figma 文件。但在开发端，原型图已经不存在了。
那我到底在说什么？
三个核心观点，简单粗暴：
直接写代码
但AI能直接遵守
但粒度要粗
当然，这只是我目前用 AI Coding 做了几个项目之后的真实感受。你要是觉得我的做法太激进、太野路子，那你大概率是对的——毕竟我是一个连表单校验都让 AI 写的人。
就这样，评论区见。
浙公网安备 33010602011771号