1
## 一、目录与文件约束
2

3
1. 禁止擅自新建目录、拆分文件、重命名已有模块。所有新增必须基于现有目录结构放置。
4
2. 修改前先读取相关现有文件，风格、命名、组织方式必须与现有代码保持一致。
5
3. 同一功能的代码必须集中在约定位置，禁止为单一功能分散创建多个新文件。
6

7
## 二、组件约束
8

9
1. 禁止重复创建通用 UI 组件（Button、Input、Modal、Table、Form 等）。必须从项目已有组件库或设计系统中选取。
10
2. 业务组件必须遵循项目现有封装范式：props 定义、事件命名、状态管理、样式引用方式统一。
11
3. 禁止把简单组件过度拆分为多个无复用价值的小文件。
12
4. 组件新增必须说明复用场景；仅在确定会被多处使用时才允许抽离为独立组件。
13

14
## 三、代码风格约束
15

16
1. 命名规范：
17
   - 组件文件使用 PascalCase；
18
   - 工具函数、hook、常量使用 camelCase；
19
   - 类型/接口使用 PascalCase；
20
   - CSS 类名遵循项目现有命名约定（BEM / Tailwind / CSS Modules 等）。
21
2. 禁止使用魔法数字、硬编码颜色、硬编码断点，必须使用项目已定义的设计令牌或常量。
22
3. 禁止在组件中写死样式块；样式必须按项目约定集中管理或使用已有工具类。
23
4. 代码必须保持简洁直接，禁止为了炫技引入不必要的抽象或设计模式。
24

25
## 四、依赖与技术约束
26

27
1. 禁止引入未在项目 package.json 中声明的依赖，或未经评审的新库。
28
2. 禁止同时使用多种实现同类功能的库。
29
3. 禁止使用已被项目明确弃用的 API、语法或写法。
30
4. 必须使用项目已选定的框架能力解决问题，不自行封装与框架等价的底层能力。
31

32
## 五、修改范围约束
33

34
1. 只改动完成任务所必需的最小范围，禁止顺手重构无关代码。
35
2. 禁止删除或修改与当前需求无关的现有代码、注释、测试。
36
3. 如果现有实现已能满足需求，优先复用而非重写。
37
4. 每处修改必须说明理由，不能回答“这样更好”之类的模糊理由。
38

39
## 六、输出要求
40

41
1. 先简要列出你计划修改的文件和改动点，经确认后再输出具体代码。
42
2. 输出代码时只输出改动部分或完整文件，禁止输出大段解释性废话。
43
3. 如果某项约束无法满足，必须明确说明原因，并给出替代方案。