双十一将至，用Rules玩转电商场景提效

双十一将至，结合电商场景，来聊聊如何 "让AI写代码更省心" ------使用Rules帮助解决 "AI写代码总跑偏" 的问题。

01 什么是Rules&如何使用Rules

Rules是什么呢------ 是⼀组规则/指令，⽤来教AI在特定项⽬或框架中应该遵守的模式、最佳实践和约束，做好这个规则⽂件，可以显著提升AI⽣成代码的质量、⼀致性，减少之后⼈⼯修正的⼯作。

可以把Rules想象成 "行为说明书"或者"工作守则"：

对人来说，Rules就像"公司员工手册"👉 让新同事知道要遵守什么流程、不能乱改配置；
对AI来说，Rules就是"编程导航图" 👉 让 AI 明白项目结构在哪、该用什么命令启动、要注意哪些细节。

实际开发中，Rules可以理解为一套项目级的"开发约束与规范" ，帮助统一AI的编码行为，让生成的代码更符合团队习惯、项目架构和业务场景。来看看电商团队在实际工作中是如何应用Rules的：

1、在Rules中定义环境依赖、启动命令、目录结构等，避免AI "自由发挥"；

2、针对电商业务，设置业务规则，比如所有的价格展示统一使用一个组件、涉及到的订单状态统一维护一个组件等；

3、加入团队代码规范和安全要求，例如在代码中不能随意引用npm包、写法风格生成一致等；

4、定义错误处理机制，比如所有可能出错的地方，都使用统一的机制处理（例如统一弹出错误信息、异常捕获等）。

Rules就像是团队的"AI导师"：

1）对新人友好： 即使是不熟悉项目的新同学，也能通过 Rules 快速了解项目规范和最佳实践。

2）对AI可控： 让AI生成的代码"开箱即用"，减少人工review和修改成本。

3）架构一致： 确保代码风格、目录结构、技术栈统一，维护性更强。

02 电商场景下，未配置Rules的问题

相信大家平时都有网购经验，肯定要关注所购买商品的状态，以订单详情页为例：根据设计稿，通过Figma to Code模式生成一个订单详情页。

说明：Figma to Code是Zulu针对前端场景开发的功能，在传统开发中，设计师出图、前端再手写页面的流程被大大简化了。如"订单详情页"设计稿，通过Figma to Code模式，只需要将设计稿导入系统，就能自动生成可运行的页面原型。

生成视频👉mp.weixin.qq.com/s/QaZL34zk0...

以上的生成过程，在没有Rules的情况下有什么问题？

当前，数据是按一个一个渲染的，而不是数组形式渲染；存在CSS文件的style没有用到lang="less",生成的文件默认用了"原始px"的写法；图标用的是符号，而不是组件icon。Comate生成的代码没有合理使用团队所引用的组件库、也没有拆成特别细的组件，CSS的写法也不是研发所要求的。此外，还会有一些通用性问题，例如样式没有按要求的规范去写、组件的颗粒度不够等。

未配置Rules，订单详情页生成的结果

那么，如何解决这些问题呢？切换到当前的代码生成界面，输入对话并引导改善。在没有Rules的场景下，模型并不知道具体的业务规则、代码规范或者样式要求。想要修改一些问题（比如代码格式不对、CSS写法不规范、布局跑偏等），只能依靠和模型的对话交互（Prompt）来一步步引导它调整，每次改动都需要重新输入Prompt，明确告诉模型要改哪里、怎么改。

一次次"人工指导"------虽然灵活，但成本也比较高。随着上下文越来越多，Prompt的长度也会增加，token消耗变高，模型响应速度也会变慢。如果问题过多，使用自然语言交互就会比较困难。

有没有一种更好的方式，能让模型"记住"这些通用规范？是不是可以通过配置Rules的方式，让这些交互自动化？ 从而实现一次配置，长期生效。

03 电商场景下，配置Rules的效果

在没有配置Rules的情况下，修改问题得靠一轮轮和模型对话。如果配置了Rules，会发生什么样的质变呢？ 可以把Rules想象成是给大模型配的一本「行为规范手册」，它的效果主要分几个层面：

1.命名约定 ------ 代码界的"起名大会"

命名约定模板就像在代码界开了一场"起名大会"。变量不能随便叫"张三"，函数也别整成"李四"。有了命名规则之后，模型就能统一风格、保证可读性。不再出现一堆奇怪的名字。从此团队协作更顺畅，调试也不再像拆盲盒。

2.代码结构 ------ 给模型戴上"紧箍咒"

代码结构约束就像是给模型戴了个"紧箍咒"。不允许模型写"俄罗斯套娃"式的嵌套结构，也不允许函数变成一团"意大利面条式"的灾难代码。有了结构约束后，代码层次清晰、逻辑明了，就像写作文有大纲，模型不会乱飙自由发挥。

3.业务逻辑层 ------ 模型的"逻辑交警"

业务逻辑层是大模型的"脑回路"，而Rules在这里扮演的角色，就像一个"逻辑交警"。它负责指挥------"这个流程该往哪跑"、"那个判断在哪停"。防止模型乱开车、逻辑撞车，让业务流转更顺畅、更可控。

有了Rules，模型就像从"自由创作"变成了"规范生产" ，既能理解设计意图，又能按照标准稳定输出。

目前有两种配置Rules的方式，一种是采用编译器，根据某个标准页面生成：

第二种是手动更新项目Rules，找到入口，然后进行更新：

Rule具体内容如下：

markdown 复制代码

---
description:
globs:
alwaysApply: true
---
## 项目概述
自动解析项目框架版本，这是一个移动端的项目，所有的样式需要参考移动端来实现。
## 开发指南
1. **class 类名处理**
    - 所有 class 名应可读、可猜测功能 统一采用 - 拼接法，如：content-title
    - 去除多余复杂的 class 类名
    - 保持 class 层级扁平，尽量最多嵌套三层
2. **css 写法**
    - 尺寸单位优先把 PX 改成 * @rex414 的写法; （例如 1px 变成 1* @rex414），这一点一定要执行，不要使用 @rpx414。
    - 组件样式必须加 lang="less"
    - 每个新写的 style 文件 必须引入 @import 'src/lib/style/common.less';，这个只需要在<style></style>标签里面引入就行
3. **组件开发**
    - 事件命名采用 handleXxx 格式。
    - 组件请帮我写在 src/routes/components 下，不要生成组件使用示例，直接生成组件。
4. **页面开发**
    - 根据设计稿，并且根据页面的模块，请务必合理拆分组件！帮我把页面写在 src/routes/ 下。
    - 页面的组件写在 src/routes/components 下。
5. **图片资源管理**
    - 所有的图片都采取占位符的方式实现。
    - 图片的所有资源都要放在 assets 下，例如 list-demo 的图片都放在 src/routes/list-demo/assets 下。
    - 例如，组件在 src/routes/list-demo/components 路径下 组件使用图片引入方式都需要按照 /assets/list-demo/image_1.png 这样实现。

配置完Rules，下一步会打开设计稿，根据约束的方式自动生成代码。

有了Rules的约束后，会有什么样的效果呢? 以上文提到的订单详情页为例，可以明显看出配置后项目代码层级的优化（如CSS格式等）。

配置Rules后，订单详情页代码展示

电商场景下，配置Rules的效果视频 👉mp.weixin.qq.com/s/QaZL34zk0...

04 Q&A

Q1: 在实际场景中，如何配置符合项目的Rules？

A：不要把AI看作一个能独立完成工作的程序员，而应视为一个知识渊博但缺决策能力 的程序员。Rules，就是给这位"队友"的工作指引和边界说明。首先要明确几点：

明确不引入外部依赖确保生成代码安全可控；
明确告知AI项目的架构与模式，确保数据的正确引入与使用；
告知AI项目使用的技术栈语法，保证生成代码在项目中可用。

最好的方式，就是让AI先生成一段代码，发现不足后，总结成一个通用规范。如果项目有已存在文件，按照已有文件的代码风格，自定义Rules的规则并逐步改善，最终使生成代码与原有代码风格保持一致。

Q2：没有Rules时，AI输出的代码会出现哪些问题？

A：比如格式不统一、命名不规范、CSS或接口写法不符合项目标准等，AI会"凭自己理解"生成，容易出现跑偏或低质量代码。

Q3：没有Rules时，有没有快速让AI输出符合规范的方法？

A：在没有配置Rules的情况下，可以通过一些方式尽量让AI输出符合规范 ，不过每种方法都有优劣。最直接的就是多轮对话逐步引导， 每次都要手动下指令，对写提示词的能力要求比较高、效率低，且容易出错。除了多轮对话，还有一些辅助办法：

1）Few-shot 示例： 给AI看几个标准示例，让它模仿好例子输出；

2）RAG（检索增强生成） ：把公司的规范文档或者参考代码库检索进来，让模型在生成时参考，这样可以减少偏离规范的情况。

但说到底，这些都是权宜之计 ，效率和稳定性都不如一次性建立Rules 。一旦把规则配置好，模型就像有了"行动指南"，以后生成的代码基本能自动符合规范，这才是真正一劳永逸的办法。

Q4：Rules是不是只针对前端项目有效？

A：Rules可以用在任何编程场景。 本质上，它就是给模型定规范、定边界，告诉它"该怎么做"、"不能乱做"。前端用它可以规范命名、组件风格、CSS写法；后端可以约束函数命名、接口设计、数据库操作、日志格式；文档、报告、甚至Markdown，也能规定模板、格式和用词。甚至在多模型协作或者Agent场景，Rules也可以帮助明确输入输出、调用顺序、任务边界。只要你的任务有规范可遵循，Rules就能发挥作用，绝对不局限于前端。针对不同的场景，可以写不同的Rules去规范模型的输出。