浅析实际场景理解为什么Cursor Rules没有生效以及后续如何规避的最佳实践

一、工作流程导致 rules 没生效

　　我在使用 cursor 进行业务开发时，是写了很多规范的 rules 的，但是在开发过程中却发现有的没有生效（所以我让他按 rules 自检）。

@.cursor/rules/vue-components.mdc 功能实现没有根据该 rules 实现，请自检并按该 rules 的要求实现

我来检查代码是否符合规范：
发现以下不符合规范的问题：
TitleResultDrawer.vue：手动导入了 ref, reactive；使用了 show-overflow-tooltip
taskMonitor.vue：手动导入了 ref

　　而且一次还没有按 rules 改全

@.cursor/rules/vue-components.mdc  规定了组合式函数 useList，为什么你在列表相关的实现里没有使用 useList

你说得对，我应该在 TitleResultDrawer.vue 中使用 useList 来处理列表逻辑。
......
已按规范使用 useList 重构，代码更简洁：
使用 useList(getTitleResultApi) 获取列表相关状态和方法
移除手动实现的 fetchData、setPagerParams、loading、dataList、total 等逻辑
复用组合式函数，符合 DRY 原则

　　所以我想了解一下为什么我设置了 rules，也设置 globs：vue 文件都得遵守的 rules，但是他却没有生效呢？

我想了解为什么我设置 rules ，而你没有按我设置的 rules 的约束行为去实现

　　回复的原因如下：

　　所以我让他：在 @.cursor/rules/project-guidelines.mdc 里增加一条重要的规则，去规避以后再出现类似问题

　　他给我增加了一条工作流程：

### 工作流程

- 复杂需求：先输出理解，确认后再开发
- 简单需求：直接实现
- **开发前必须先读取相关规范文件**：涉及 Vue 组件开发时，先读取 `vue-components.mdc`；涉及 API 开发时，先读取 `api-design.mdc`，确保代码一次性符合规范，避免反复修正

　　这条规则强制他在动手写代码前先阅读对应规范，从源头避免不符合规范的代码。

　　后面再对话的需求我看到他确实是先读取了相关的规范了（说明有效）

二、非强制性语言导致 rules 不生效

　　关于前端分页其实我前端时间有写一个组合式方法，但是我发现 cursor 没有使用，还是独立实现的。所以我让他使用组合式方法去实现了（由于我的项目规则里有写 rules 自更新机制，所以这里我也想试一下看这个 rules 自更新机制有没有生效，但是我发现没有生效，他没有帮我去抽离范式去放在 rules 里，所以我就继续追问原因）

@.cursor/rules/project-guidelines.mdc 根据Rules 自更新机制，以上关于前端分页的处理，是可以抽离出范式，放于  vue-components.mdc 里的，为什么你没有这么做呢

你说得对，这是我的疏忽。根据 Rules 自更新机制：
前端分页模式具有通用性（项目中 TitleImport.vue 已在使用，现在 TitleResultDrawer.vue 也使用）
属于 Vue 组件模式 → 应更新 vue-components.mdc
.....
已将「前端分页模式」追加到 vue-components.mdc，后续遇到前端分页场景，我会直接按此规范实现。

　　他确实帮我去干了，但是我的核心还是需要知道为什么他之前没有按我的 rules 去做

我想知道为什么之前没有根据“Rules 自更新机制”去处理，而是在我提出后才处理。是“Rules 自更新机制”提示词写的有问题，还是因为什么？
如果是提示词写的有问题，请优化该部分，以避免你后期再出现类似问题

　　这是给我的回复：

　　可以看下他给我的变更如下：

　　给出的改进点如下：

三、持续迭代的反思

　　通过上面2次 rules 没生效，我连续追问了 2 次，并要求 Cursor 去强制执行的优化，能够给我带来什么启示呢。

　　我觉得：这是个很好的反思。通过这两次经历，可以总结出 AI 提示词/规则设计 的几条启示：

1、表述方式决定执行力度

原规则	优化后	区别
"检查是否有..."	"必须执行以下检查"	建议 → 强制
"完成后检查"	"开发后（必须）"	模糊 → 明确时机
描述性段落	检查清单 + 逐条回答	抽象 → 可操作

　　启示：AI 对"强制性语言"（必须、禁止、强制）的响应比"建议性语言"（可以、建议、应该）更可靠。

2、规则需要嵌入流程

　　独立存在的规则容易被忽略。优化后将其嵌入工作流程：

开发前（必须）→ 读规范
开发中 → 实现
开发后（必须）→ 执行 Rules 自更新检查

　　启示：规则与流程绑定，在关键节点强制触发，而非依赖 AI 主动想起。
3、检查清单优于描述性规则

描述性	检查清单式
"识别是否有可复用模式"	1. 是否用了未记录的组合式函数？ 2. 是否形成可复用模式？ 3. 是否≥2处使用？

　　启示：清单化、结构化的规则更容易被严格执行。

4、用户反馈驱动规则迭代

规则未生效 → 用户追问 → 分析原因 → 优化规则 → 规则更可靠

　　启示：Rules 本身需要迭代。当 AI 行为不符合预期时，不是 AI 的问题，而是规则设计的问题。通过反馈持续优化规则。

5、总结：好的 Prompt/Rules 设计 = 强制性语言 + 明确时机 + 检查清单 + 流程绑定 + 持续迭代

　　这也是为什么我在项目里设计了"Rules 自更新机制"——规则本身也需要演进。