我不是想让 AI 替我写前端，而是不想再重复教它怎么写

最近一边忙着做业务前端，一边在搭建一套让AI更稳定地参与前端开发的协作体系。

每当聊起AI写代码，很多人第一反应都是：它能让速度飞起来。

但实践越多，越会觉得，真正浪费时间的，从来不是敲代码，而是那些不断重复、却没人沉淀下来的约定。

每接一个需求，AI都要重新理解一遍：

如果这些没有明确规则，不只是AI，每个开发都会写出一套自己的理解。

最后代码能跑，但项目越来越不像一个项目。

所以，想解决的问题从来不是：

而是：

前端，其实是最适合做AI协作的岗位之一

很多人觉得前端变化快。

但真正做业务的人都知道，大部分需求其实都长得很像。

这一周可能是：

• 新增一个列表
• 多几个筛选项
• 加一个弹窗
• 多几个状态Tag
• 调整权限控制
• 补几个表单字段
• 对接一个新接口

下一周换个业务，又来一次。

真正变化的，往往只有数据。

而页面结构、组件规范、交互习惯、请求方式，甚至代码组织方式，基本都可以复用。

真正消耗开发精力的，不是JSX，也不是Vue或React。

而是这些没人记录，却每天都在重复沟通的问题：

• 这一周到底有哪些需求？
• 每个需求会影响哪些页面？
• 用哪套公共组件？
• 有没有设计稿？
• 有没有原型？
• 是否需要国际化？
• 有没有权限？
• 有没有接口依赖？
• 做完以后应该跟谁确认？
• 什么情况下可以合并？

这些，才是真正吃掉团队带宽的地方。

所以，这些经验就被一点点拆了出来

现在做的事情，不是训练一个万能Agent。

而是把以前只存在脑子里的经验，一点点变成可以调用的能力。

整个体系目前只有两层。

业务仓负责回答：

编排仓负责回答：

两边职责拆开以后，整个流程就清晰很多。

业务仓持续沉淀：

• 列表怎么搭
• 表单怎么组织
• Table怎么封装
• 请求如何统一
• 哪些内容不能硬编码
• 什么情况下必须走公共组件
• 哪些规则不能违反

而编排仓负责把这些能力串起来。

例如：

 需求 Intake
        ↓
整理 Brief
        ↓
判断改动范围
        ↓
标记待确认事项
        ↓
创建周分支
        ↓
Agent 实现页面
        ↓
按 Rules + Skill 审查
        ↓
人工确认
        ↓
保留 / 回滚
        ↓
生成执行报告 & 周报

整个过程更像是一条可重复执行的流水线，而不是每次都从零开始。

给AI定了几条不能碰的规则

随着项目越来越真实，会发现，与其不断优化Prompt，不如先把边界定清楚。

核心原则是：

• 约定永远优先于模型发挥。
• 有设计稿就先对设计稿，再写代码。
• 有原型就按原型，不允许自由发挥。
• 不确定的需求宁可挂起，也不要猜。
• 失败就是失败，不允许把未完成伪装成完成。
• 所有代码都必须经过人工确认，才能真正进入项目。

AI可以施工。

但不能决定产品。

真正想释放的，其实不是编码能力

很多人会问：

答案恰恰相反。

真正应该被释放的，从来不是写代码本身。

而是那些没有技术含量、却不断重复发生的工作。

比如：

• 一遍遍告诉别人这个项目怎么写
• 一遍遍解释公共组件怎么用
• 一遍遍整理每周需求
• 一遍遍核对哪些页面需要修改
• 一遍遍检查是不是漏了国际化、权限、接口依赖

这些事情，本来就应该交给系统。

开发应该把更多时间放在真正需要判断的地方：

• 用户体验是否合理
• 页面结构是否清晰
• 接口设计有没有问题
• 有没有隐藏风险
• 功能到底该做到什么程度

这些，才是真正有价值的部分。

越来越相信一件事

AI不会替代优秀的前端。

但会不断淘汰那些只能重复写业务代码的开发。

真正的竞争力，已经不是谁会写一个列表、一个表单、一个弹窗。

而是谁能把团队积累下来的经验、规范和流程，沉淀成一套任何人、任何Agent都能稳定复用的能力。

Skill、Rules、公共组件，本质上是在沉淀知识。

而编排，则是在沉淀流程。

两者结合起来，释放的不是写代码的速度，而是整个团队的交付能力。

目前这套体系还在真实项目里持续打磨，不是Demo，也不是为了展示概念，而是每天跟着业务一起迭代。

最终希望做到的不是「AI会写前端」。

而是AI能稳定地按照团队的标准写前端，而开发者可以把精力放回真正需要思考和决策的地方。

如果你也在尝试让AI参与团队开发，很好奇：你现在最大的瓶颈，是Prompt、规范，还是整个协作流程？