我定制的通义灵码 Project Rules，用 AI 写出“更懂我”的代码

作者：不起名字可以不

我是一名全栈开发，平时会大量使用通义灵码做代码生成、接口注释、测试代码补全等工作，效率提升是真的肉眼可见。最近通义灵码推出的 Project Rules 功能，我立刻体验了一下，现在已经用上了！

为什么我需要定制规则？

在我们项目组里，不同人写出来的代码格式和命名习惯不一样，尤其是通过 AI 辅助生成的代码，有时会“跑偏”，比如：

• 用了不符合我们项目约定的注释风格
• 命名不贴合业务语义
• 忽略了我们常用的工具类

以前每次 review 都要花时间来调整格式或重命名，现在我直接通过 Project Rules 把这些偏好告诉 AI，生成出来的代码更“懂我”了。

我的 Project Rules 示例配置

规则限制

每个规则文件最大限制为 10000 字符，超过部分将自动截断。

规则文件请使用自然语言描述，不支持图片或链接的解析。

我的项目语言是 Vue（使用 Vue 3 + Composition API） ，以下是我对代码风格、注释方式和生成代码的偏好：

### 1. 语法和框架规范：
- 使用 Vue 3 的 **Composition API**，不使用 Options API；
- 脚本部分必须使用 `<script setup>` 语法；
- 模板中尽量使用简洁语法，如 `v-if / v-for / v-model`，避免多余嵌套；
- 尽量避免使用 `any` 类型，优先使用 TypeScript 明确类型；
- 如果使用了异步请求，默认封装为 `useXXX()` 的组合式函数，统一放在 `composables/` 文件夹中；
- 所有页面组件统一放在 `views/` 文件夹中，通用组件放在 `components/` 中。
### 2. 命名规范：
- 文件命名统一为 **小写中划线格式**（如：`user-list.vue`）；
- 变量、函数名使用 **camelCase**；
- 组件名使用 **PascalCase**；
- 钩子函数命名使用 `use` 前缀，如 `useUserList`；
- SCSS 变量使用 `$` 开头，命名清晰，避免缩写。
### 3. 注释风格：
- 所有方法必须添加注释，注释风格清晰简洁，使用自然语言说明该方法的作用；
- 对于复杂逻辑、watchEffect、computed 计算过程请写明业务含义；
- 文件顶部应注明作者、创建时间和功能简述；
- 注释语气中性，不带个人语气，不重复代码内容。
### 4. 样式和布局：
- 使用 SCSS 或 Less 预处理器，**禁止在 style 中使用 scoped**；
- 样式统一使用 BEM 命名规范；
- 组件布局使用 CSS Grid 或 Flex，禁止使用 table；
- 移动端优先使用 rem 单位，桌面端可适当使用 px。
### 5. 代码结构和项目约定：
- 每个组件文件中顺序为：模板（template）> 脚本（script）> 样式（style）；
- API 请求统一封装到 `api/` 文件夹中，禁止在组件内直接写 `axios` 请求；
- 所有 API 响应结果请使用统一的响应封装器处理（如 `useRequest()`）；
- 表单组件封装时需支持 `v-model` 双向绑定。
### 6. 响应和异常处理：
- 所有请求必须添加异常捕获处理，如 `try/catch` 或 `onError` 钩子；
- 异常提示语应通用，避免硬编码字符串；
- 页面加载时使用骨架屏或 loading 动画，避免页面空白。
### 7. 通义灵码回复和生成内容要求：
- 灵码回答请使用中文；
- 回答内容结构清晰，重点内容可使用列表展示；
- 不推荐使用未经引入的三方包，如 lodash、dayjs，除非已有安装；
- 如生成表单、表格代码，请基于 Element Plus UI 框架；
- 建议代码块加上简要解释，便于理解。

通义灵码提效使用经验

🔧 提高注释生成质量

平时让我头疼的就是写注释，现在用了 Javadoc 规范 + neutral 评论语气，通义灵码生成的注释几乎可以直接使用，甚至文档都不太用手动整理了。

🚫 避免不必要的“AI 幻觉”

之前我让它帮我生成一个工具方法，它老是引入我们项目中没有的三方库，现在通过 "use_stream_api": false 和 "exception_handling": "customExceptionClass"，它会更贴近我项目的写法。

👥 团队协作保持一致性

我们组里是多人协作，我直接把 project-rules.json 加进 git 项目中，大家用同一套规则，不仅生成代码风格统一，连灵码生成的提示回复也更一致，review 也更省事了。

使用建议 & 期待

• 希望之后能支持团队规则库共享和一键应用；
• 如果能内置几套“通用行业规则模版”（比如 Spring Boot 项目推荐规则）就更友好了；
• 灵码提示区支持高亮哪些是根据 Rules 特别优化过的部分，会更直观。

总结一下

通义灵码的 Project Rules 功能真的解决了我使用 AI 编码过程中最实际的一些“误差”问题。现在我的 AI 编码助手不再“天马行空”，而是真的按照我的要求来“定制产出”。

如果你也经常用灵码写业务逻辑、处理项目细节，强烈推荐你定制一份属于自己的编码规则，效果真的不一样！

下载通义灵码：https://lingma.aliyun.com/download