我是一名全栈开发，平时会大量使用通义灵码做代码生成、接口注释、测试代码补全等工作，效率提升是真的肉眼可见。最近通义灵码推出的 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 编码助手不再“天马行空”，而是真的按照我的要求来“定制产出”。
如果你也经常用灵码写业务逻辑、处理项目细节，强烈推荐你定制一份属于自己的编码规则，效果真的不一样！
