我不是想让 AI 替我写前端,而是不想再重复教它怎么写
最近一边忙着做业务前端,一边在搭建一套让AI更稳定地参与前端开发的协作体系。

每当聊起AI写代码,很多人第一反应都是:它能让速度飞起来。
但实践越多,越会觉得,真正浪费时间的,从来不是敲代码,而是那些不断重复、却没人沉淀下来的约定。
每接一个需求,AI都要重新理解一遍:
如果这些没有明确规则,不只是AI,每个开发都会写出一套自己的理解。
最后代码能跑,但项目越来越不像一个项目。
所以,想解决的问题从来不是:
而是:
前端,其实是最适合做AI协作的岗位之一
很多人觉得前端变化快。
但真正做业务的人都知道,大部分需求其实都长得很像。
这一周可能是:
- 新增一个列表
- 多几个筛选项
- 加一个弹窗
- 多几个状态Tag
- 调整权限控制
- 补几个表单字段
- 对接一个新接口
下一周换个业务,又来一次。
真正变化的,往往只有数据。
而页面结构、组件规范、交互习惯、请求方式,甚至代码组织方式,基本都可以复用。
真正消耗开发精力的,不是JSX,也不是Vue或React。
而是这些没人记录,却每天都在重复沟通的问题:
- 这一周到底有哪些需求?
- 每个需求会影响哪些页面?
- 用哪套公共组件?
- 有没有设计稿?
- 有没有原型?
- 是否需要国际化?
- 有没有权限?
- 有没有接口依赖?
- 做完以后应该跟谁确认?
- 什么情况下可以合并?
这些,才是真正吃掉团队带宽的地方。
所以,这些经验就被一点点拆了出来
现在做的事情,不是训练一个万能Agent。
而是把以前只存在脑子里的经验,一点点变成可以调用的能力。
整个体系目前只有两层。
| 层 | 职责 |
|---|---|
| 业务前端仓 | 真正交付代码,把组件规范、Skill、Rules、项目约定全部沉淀下来 |
| 编排仓 | 接需求、分类、派发Agent、审查结果、生成报告,不直接修改业务代码 |
业务仓负责回答:
编排仓负责回答:
两边职责拆开以后,整个流程就清晰很多。
业务仓持续沉淀:
- 列表怎么搭
- 表单怎么组织
- Table怎么封装
- 请求如何统一
- 哪些内容不能硬编码
- 什么情况下必须走公共组件
- 哪些规则不能违反
而编排仓负责把这些能力串起来。
例如:
需求 Intake
↓
整理 Brief
↓
判断改动范围
↓
标记待确认事项
↓
创建周分支
↓
Agent 实现页面
↓
按 Rules + Skill 审查
↓
人工确认
↓
保留 / 回滚
↓
生成执行报告 & 周报
整个过程更像是一条可重复执行的流水线,而不是每次都从零开始。
给AI定了几条不能碰的规则
随着项目越来越真实,会发现,与其不断优化Prompt,不如先把边界定清楚。
核心原则是:
- 约定永远优先于模型发挥。
- 有设计稿就先对设计稿,再写代码。
- 有原型就按原型,不允许自由发挥。
- 不确定的需求宁可挂起,也不要猜。
- 失败就是失败,不允许把未完成伪装成完成。
- 所有代码都必须经过人工确认,才能真正进入项目。
AI可以施工。
但不能决定产品。
真正想释放的,其实不是编码能力
很多人会问:
答案恰恰相反。
真正应该被释放的,从来不是写代码本身。
而是那些没有技术含量、却不断重复发生的工作。
比如:
- 一遍遍告诉别人这个项目怎么写
- 一遍遍解释公共组件怎么用
- 一遍遍整理每周需求
- 一遍遍核对哪些页面需要修改
- 一遍遍检查是不是漏了国际化、权限、接口依赖
这些事情,本来就应该交给系统。
开发应该把更多时间放在真正需要判断的地方:
- 用户体验是否合理
- 页面结构是否清晰
- 接口设计有没有问题
- 有没有隐藏风险
- 功能到底该做到什么程度
这些,才是真正有价值的部分。
越来越相信一件事
AI不会替代优秀的前端。
但会不断淘汰那些只能重复写业务代码的开发。
真正的竞争力,已经不是谁会写一个列表、一个表单、一个弹窗。
而是谁能把团队积累下来的经验、规范和流程,沉淀成一套任何人、任何Agent都能稳定复用的能力。
Skill、Rules、公共组件,本质上是在沉淀知识。
而编排,则是在沉淀流程。
两者结合起来,释放的不是写代码的速度,而是整个团队的交付能力。
目前这套体系还在真实项目里持续打磨,不是Demo,也不是为了展示概念,而是每天跟着业务一起迭代。
最终希望做到的不是「AI会写前端」。
而是AI能稳定地按照团队的标准写前端,而开发者可以把精力放回真正需要思考和决策的地方。
如果你也在尝试让AI参与团队开发,很好奇:你现在最大的瓶颈,是Prompt、规范,还是整个协作流程?
-
- 关于宇宙的好的网名有哪些
- 角色扮演 | 1
- 网名