首先进入C盘下的用户目录，点击用户名文件夹，打开".codex"隐藏文件夹，再打开AGENTS.md,如果没有需要自行建立一个。【md文件可以通过Typora或者其他工具打开，可以使用windows记事本强制打开】

进入md文件后输入以下全局指令

必须使用 UTF-8 编码，否则会乱码。
Your code must use UTF-8 encoding; otherwise, garbled text will occur.

所有源代码文件、配置文件、资源文件必须以 UTF-8 无 BOM 格式保存。
All source code files, configuration files, and resource files must be saved in UTF-8 without BOM format.

每次修改只允许修改用户提问内容范围之内的相关文件。
Each modification is strictly limited to files directly related to the user's query scope.

禁止修改用户未提及的任何非相关文件，包括依赖配置、构建脚本或无关模块。
Do not modify any unrelated files not mentioned by the user, including dependency configs, build scripts, or unrelated modules.

前端项目必须遵循模块化、组件化开发规范，使用 TypeScript 优先。
Frontend projects must follow modular and component-based development practices, with TypeScript preferred.

后端项目必须采用 Spring Boot 标准分层架构，确保编码一致性与可维护性。
Backend projects must adopt the standard Spring Boot layered architecture to ensure encoding consistency and maintainability.

所有 HTTP 响应头必须显式声明 charset=UTF-8，避免中文乱码。
All HTTP response headers must explicitly declare charset=UTF-8 to prevent Chinese character corruption.

数据库连接字符串、中间件配置、日志输出均需强制使用 UTF-8 编码。
Database connection strings, middleware configurations, and log outputs must all enforce UTF-8 encoding.

------

### **前端项目目录架构（Node.js / Next.js / Vue / TS / CSS）**

Frontend Project Directory Structure (Node.js / Next.js / Vue / TS / CSS)

```Text
frontend/
├── src/
│   ├── app/                    # Next.js App Router (React Server Components)
│   │   └── layout.tsx
│   │   └── page.tsx
│   ├── components/             # Reusable UI components
│   ├── views/                  # Page-level components (Vue convention)
│   ├── api/                    # API service layer (Axios/fetch wrappers)
│   ├── assets/                 # Static assets (images, fonts, icons)
│   ├── styles/
│   │   ├── globals.css         # @charset "UTF-8"; required at top
│   │   └── variables.scss
│   ├── utils/                  # Utility functions & helpers
│   ├── types/                  # TypeScript interfaces & types
│   ├── router/                 # Vue Router config (Vue projects only)
│   └── store/                  # State management (Pinia/Vuex)
├── public/                     # Static files served as-is
├── next.config.js              # Next.js config (ensure webpack handles UTF-8)
├── tsconfig.json               # TS config: "module": "ESNext", "target": "ES2020"
├── package.json                # Scripts & deps; include "type": "module" if needed
├── .eslintrc.cjs               # ESLint rules (UTF-8 compatible)
└── .gitignore
```

### **后端项目目录架构（Spring Boot / Spring Cloud / Alibaba）**

### 强制后端目录与分层规范（Spring Boot）

所有后端代码必须严格遵循以下目录结构与分层规则。除非用户明确要求，否则禁止擅自突破、简化、合并或绕过这些规范。

#### 1. service / impl 强制规则

- `service` 包下只允许存放接口，禁止存放任何实现代码。
- `service/impl` 包下只允许存放接口对应的实现类。
- 所有 Service 必须严格采用以下命名配对：
  - 接口名：`XxxService`
  - 实现名：`XxxServiceImpl`
- 禁止以下行为：
  - 在 `service` 根目录直接编写实现逻辑
  - 将实现类放在 `service` 以外的任意目录
  - 在 `service` 下继续创建业务多级子目录
  - Controller 直接依赖 `XxxServiceImpl`
- 所有 Controller 只能依赖 `service` 包中的接口，不能依赖 `impl`。

#### 2. controller 强制分类规则

- `controller` 必须按业务域拆分子目录，禁止所有 Controller 平铺在同一层。
- 新增 Controller 时，必须优先归入已有业务目录；没有对应目录时，才允许新增新的业务子目录。
- 推荐业务目录包括但不限于：
  - `controller/auth`
  - `controller/approval`
  - `controller/business`
  - `controller/training`
  - `controller/task`
  - `controller/knowledge`
  - `controller/quality`
  - `controller/standards`
  - `controller/permission`
  - `controller/database`
  - `controller/system`
  - `controller/dashboard`
  - `controller/support`
- 禁止创建无明确业务边界的聚合控制器，例如：
  - `ApiController`
  - `CommonController`
  - `SystemApiController`
  - 任何混合多个无关业务域的大控制器
- 一个 Controller 只能承载同一业务域内的接口，禁止跨域混放。

#### 3. dto 强制分类规则

- 所有 DTO 必须放在 `api/dto` 下，并按业务域划分子目录。
- 禁止将不同业务的 DTO 长期堆放在 `api/dto` 根目录。
- DTO 必须表达明确语义，优先采用以下命名：
  - `XxxCreateRequest`
  - `XxxUpdateRequest`
  - `XxxUpsertRequest`
  - `XxxQueryRequest`
  - `XxxResponse`
- 若某业务已经存在对应 dto 子目录，则新增 DTO 必须进入该目录，禁止新旧风格混用。

#### 4. entity 强制分类规则

- 所有实体类必须统一放在 `entity` 下，并按业务域分类。
- 禁止把多个业务域的实体长期混放在 `entity` 根目录。
- 若某业务已建立子目录，例如 `entity/training`，则该业务所有新增 Entity 必须继续放入该目录。

#### 5. 命名与职责强制规则

- 所有类命名必须体现明确业务职责，禁止使用模糊、泛化、兜底式命名。
- 禁止新增以下类型命名，除非用户明确指定：
  - `CommonService`
  - `BaseBusinessService`
  - `GeneralController`
  - `ApiController`
  - `TempService`
  - `HelperController`
- Service 的职责必须清晰、单一，不能把多个无关业务硬塞进一个 Service。
- Controller 负责接口编排与参数接收。
- Service 接口负责业务能力抽象。
- ServiceImpl 负责业务实现。
- Entity 负责领域数据建模。
- DTO 负责接口输入输出传输。
- 禁止让 DTO、Entity、Controller、Service 相互越层承担职责。

#### 6. 通用能力类约束

- 若存在通用数据库操作、公共转换逻辑或复用工具方法，只能作为“实现层内部支撑类”存在。
- 通用支撑类不能替代正式业务 Service。
- 禁止使用一个“大而全”的通用 Service 承接多个业务域的长期业务逻辑。
- 如发现已有“大服务类”“大控制器”，新增功能时不得继续往其中堆积，必须按业务域拆分。

#### 7. 新增代码强制执行规则

- 新增后端功能时，必须先判断其所属业务域，再放入对应目录。
- 若已有对应的 `controller`、`service`、`service/impl`、`dto`、`entity` 业务目录，必须复用，不得另起一套平行结构。
- 若不存在对应业务目录，可新增目录，但必须保持：
  - `controller` 按业务域分类
  - `service` 仅接口
  - `service/impl` 仅实现
  - `dto` 按业务域分类
  - `entity` 按业务域分类

#### 8. 修改现有代码时的纠偏规则

- 修改现有后端代码时，如果发现以下问题，应优先在当前任务范围内纠偏：
  - Controller 混放
  - Service 与实现类混放
  - DTO 混放
  - Entity 混放
  - 大控制器承载多个业务域
  - 大服务类承载多个业务域
- 但纠偏只能发生在当前用户请求相关范围内，禁止超范围重构无关模块。

#### 9. 兼容性规则

- 目录重组、包重组、类重组时，默认不得改变已有接口 URL，除非用户明确要求修改接口路径。
- 默认不得改变已有对外接口的请求结构、响应结构与业务语义，除非用户明确要求。
- 结构整理优先影响代码组织，不得默认引入接口行为变更。

#### 10. 编码与文件规则

- 所有 `.java`、`.yml`、`.properties` 文件必须使用 UTF-8 无 BOM 编码。
- 修改后端文件时，必须保持 UTF-8，无乱码风险。
- 仅允许修改当前任务直接相关的文件，禁止借整理结构之名修改无关模块。

#### 11. 默认执行策略

- 当用户要求“整理后端结构”“按现有风格补齐代码”“统一 service 与 impl 格式”“拆分 controller”时，默认必须遵循本规范执行。
- 如果用户未明确说明目录风格，则默认采用本规范，而不是自由发挥。
- 如现有项目已经部分遵循本规范，后续新增与修改必须继续向本规范收敛，禁止倒退。