ylsw-bw/.cursor/rules/always-on-rule.md

---

trigger: always_on

---

description: AI 行为、安全底线与任务路由规则(始终生效,融合 always-on-rule + skill-routing-required)

alwaysApply: true

AI 行为与安全底线规则

本文件由系统自动注入,每次对话始终生效。等效约束力最高,无需 AI 主动读取。

---

一、任务执行前置流程(SKILL 路由强制)🔥 最高优先级

在执行任何任务前,必须先完成 SKILL 路由判断,不能直接写代码或执行命令。

1. 读取当前项目配置文件：先读仓库根目录下 current_project_config.md（非 .cursor/ 内模板）；必须解析其中单独一行的 「项目标签（路由）：…」（格式见 SKILL.md §1.0），据此加载 language/ 与 rules/；禁止仅用 L2 通用技术栈表猜测框架。若该文件声明的技术事实（数据库、UI 库、UniApp 路径等）与 L2 不一致，以本文件为准。
2. 读取 SKILL.md：先读取技能入口文件 ../skills/tofly-memory-system/SKILL.md,获取路由规则与「严格执行清单」
3. 判断任务类型：根据 SKILL.md 路由表归类(项目初始化/目录对齐、代码编写、技术选型、Git 操作、调试排错、构建部署、测试、纯问答)
4. 按需加载配置：只加载当前任务需要的配置片段,禁止全量加载
5. 路由不明确时：先向用户确认再继续,禁止猜测
6. 注释规则：编写的代码逻辑复杂和重要的地方需要写注释
7. 页面生成规则:用户在使用dsl文件或者.json文件或者使用https://mastergo.com的mcp生成页面的时候必须使用tofly-memory-system中相应的模版,具体使用的模版你可以在`current_project_config.md`,获取项目标签中获取到

执行约束：

• ❌ 禁止跳过路由流程直接开始实现
• 若存在项目级覆盖配置(current_project_config.md),先读 SKILL.md,再按优先级应用项目配置；其中 项目标签（路由） 与 §二 技术事实 对 AI 路由的约束力 高于 warehouse_shared_config.md 中与项目冲突的通用表述
• 改动范围尽量小,并严格遵循已路由到的 skill 约束

二、行为规范

• 第一原则必须使用户提供的代码模版去做创建代码和文件,方法等。
• 禁止主动创建 *.md / README 文档,除非用户明确要求
• 例外（与 SKILL §2.0 对齐）：当任务属于 SKILL.md §2.0 目录对齐时，允许在当轮回复内使用 Markdown 表格说明目录；仅在用户显式要求在仓库中创建/更新某一说明文件且给出单一路径时，方可在该路径写入 Markdown。禁止在 src/、java/、views/ 等业务目录批量新建 README 作为目录说明的替代。
• 优先编辑已有文件,不随意新建文件
• 不假设库的存在,使用前确认依赖文件(package.json / pom.xml / go.mod)
• 多步骤任务必须用 TodoWrite 跟踪进度
• 用户习惯记录：用户说"记住这个""以后都这样"时,必须更新 L3 §五(local_private_config.md 用户习惯记录部分)

三、浏览器规则

• 禁止使用 IDE 内置浏览器打开页面
• 必须使用外部浏览器预览
• 可通过 MCP 工具获取浏览器控制台报错和网络请求信息

四、沟通风格

• 默认中文回复,代码注释语言与用户一致
• 结论先行：先给方案再解释原因
• 回答简洁聚焦,完成工作后简要总结
• 遇到歧义主动用 AskUserQuestion 询问,不猜测
• 破坏性操作(删除/覆盖)前必须确认

五、安全红线(绝对不可违反)

完整版详见 L1 §一(company_unified_config.md 安全红线部分),此处为强制摘要。

• ❌ 绝对禁止硬编码密钥、密码、Token、API Key
• ❌ 绝对禁止将敏感信息提交到版本控制
• ❌ 禁止 SQL 拼接、命令注入、XSS 未转义
• ❌ 禁止使用已停止维护超过 2 年的生产依赖
• 敏感配置必须通过环境变量或密钥管理服务注入

六、AI 行为准则

• 不编造不存在的 API 或库用法,不确定时明确说明
• 发现安全风险或性能问题时必须主动提醒
• 用户显式约束条件始终遵循
• 先用 SearchCodebase / Grep 了解代码结构,不凭空假设
• 最小改动原则：满足需求的前提下改动范围尽可能小
• 跟随项目惯例：即使个人偏好不同,以项目现有风格为准
• 渐进式实现：复杂功能先跑通主流程,再逐步完善细节

七、配置权重覆盖规则

L3 本地私有配置 (权重:100) ← 最高优先级,覆盖 L1/L2
    ↓ 覆盖
L2 仓库共享配置 (权重:75)  ← 项目级技术事实 + 架构约定
    ↓ 覆盖
L1 公司统一配置 (权重:25)  ← 安全红线(只读不可覆盖)+ 技术规范 + 语言约束

• 安全红线部分(L1 §一)为只读规则,L2/L3 不可覆盖
• 其余 L1 规则可被 L2/L3 合理覆盖
• 冲突时高权重层级优先,无法确定时主动询问用户

八、编码质量底线(跨语言通用摘要)

完整版详见 L1 §三(company_unified_config.md 编码质量底线部分),此处为每次写代码都应遵守的强制摘要。

命名与可读性

• 命名自解释：变量、函数、类、模块名必须能表达其用途,禁止无意义命名(如 a/tmp/data/foo/x)
• 遵循语言惯例：使用该语言社区公认的命名风格(camelCase / snake_case / PascalCase)
• 避免缩写谜题：除非是行业通用缩写(如 URL、ID、HTTP),否则不使用难以理解的缩写

错误处理

• 禁止静默吞错：不允许空 catch / 忽略错误返回值,必须有明确的错误处理逻辑或向上传播
• 错误信息有意义：错误消息应包含足够的上下文帮助定位问题,禁止抛出空错误或通用错误字符串
• 资源必须释放：打开的资源必须确保释放,使用语言提供的 RAII / try-finally / defer / using 等机制

代码组织

• DRY 原则：相同逻辑出现 3 次以上必须抽取为公共函数/模块/组件
• 单一职责：单个函数/方法只做一件事,逻辑复杂时拆分
• 模块边界清晰：模块/包之间依赖方向应单向,避免循环依赖

全局禁用(跨语言)

• ❌ 禁止使用已被官方标记为 deprecated / removed 的语法/API
• ❌ 禁止使用已终止维护且无社区接管的依赖/框架
• ❌ 禁止在支持异步的语言中强制使用同步阻塞 I/O 模式

九、变更后自动验证

• 前端改动 → 自动运行 lint + typecheck
• 后端改动 → 自动运行 mvn compile
• 不需要每次都跑完整 test suite(除非涉及逻辑修改)