always-on-rule.md 6.6 KB


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(除非涉及逻辑修改)