ssssd
This commit is contained in:
149
.cursor/rules/5sguize.mdc
Normal file
149
.cursor/rules/5sguize.mdc
Normal file
@@ -0,0 +1,149 @@
|
||||
---
|
||||
description:
|
||||
globs:以下是为软件开发人员设计的**5S个人工作规范体系**，结合5S管理原则（整理、整顿、清扫、清洁、素养）与技术实践需求，采用模块化分层结构，包含可执行条款与评估标准：
|
||||
|
||||
---
|
||||
|
||||
### **软件开发人员5S个人工作规范体系**
|
||||
**版本：** 1.0
|
||||
**生效日期：** 2025年8月16日
|
||||
|
||||
---
|
||||
|
||||
#### **1. 文档管理规范（Seiri - 整理）**
|
||||
**目标：** 消除冗余文档，确保必要信息结构化存储。
|
||||
**1.1 文档创建触发条件**
|
||||
- ✅ 必须创建文档的场景：
|
||||
- 项目启动（输出《项目计划书》）
|
||||
- 需求变更（更新《需求规格说明书》）
|
||||
- 技术方案评审（输出《技术设计文档》）
|
||||
- 事故复盘（输出《故障分析报告》）
|
||||
**1.2 文档核心要素**
|
||||
- 所有文档必须包含：
|
||||
```markdown
|
||||
- 目标 | 版本号 | 责任人 | 最后更新日期
|
||||
- 变更记录（含修改人、修改内容）
|
||||
- 关联资源链接（代码库/JIRA编号）
|
||||
```
|
||||
**1.3 版本控制机制**
|
||||
- 使用Git管理文档（Markdown格式），禁止本地存档
|
||||
- 文档更新必须：
|
||||
- 更新版本号（语义化版本 `v<主>.<次>.<补丁>`）
|
||||
- 提交变更日志（>50字说明）
|
||||
**✅ 检查点：**
|
||||
- 月度文档审计（抽查20%文档，检查要素完整性与版本合规性）
|
||||
- **评估标准：** 文档缺失率 ≤ 5%，版本记录完整率100%
|
||||
|
||||
---
|
||||
|
||||
#### **2. 开发流程规范（Seiton - 整顿）**
|
||||
**目标：** 标准化流程，减少上下文切换成本。
|
||||
**2.1 标准开发步骤**
|
||||
```mermaid
|
||||
graph LR
|
||||
A[需求分析] --> B[技术设计]
|
||||
B --> C[编码]
|
||||
C --> D[单元测试]
|
||||
D --> E[Code Review]
|
||||
E --> F[集成测试]
|
||||
```
|
||||
**2.2 代码提交规范**
|
||||
- 单次提交代码量 ≤ 300行
|
||||
- 提交信息格式：
|
||||
```git
|
||||
feat|fix|docs|refactor(<模块>): <描述> [JIRA-ID]
|
||||
# 示例：fix(auth):修复登录token过期逻辑 [PROJ-123]
|
||||
```
|
||||
**2.3 质量控制标准**
|
||||
- 单元测试覆盖率 ≥ 80%（语言无关）
|
||||
- Code Review必须：
|
||||
- 2人以上参与
|
||||
- 使用工具（GitLab MR/SonarQube）
|
||||
- 24小时内完成
|
||||
**✅ 检查点：**
|
||||
- CI流水线拦截未达标代码（测试覆盖率/静态扫描）
|
||||
- **评估标准：** MR平均周转时间 ≤ 4小时，缺陷泄漏率 ≤ 2%
|
||||
|
||||
---
|
||||
|
||||
#### **3. 问题解决规范（Seiso - 清扫）**
|
||||
**目标：** 快速定位并根治问题。
|
||||
**3.1 问题分级标准**
|
||||
| 级别 | 响应时限 | 影响范围示例 |
|
||||
|-------|-----------|----------------|
|
||||
| P0 | ≤15分钟 | 线上核心功能瘫痪 |
|
||||
| P1 | ≤2小时 | 主要功能降级 |
|
||||
| P2 | ≤8小时 | 次要功能异常 |
|
||||
| P3 | ≤24小时 | 优化建议 |
|
||||
**3.2 问题处理流程**
|
||||
1. **记录**：JIRA创建Issue（附日志/截图/复现步骤）
|
||||
2. **分析**：根因定位（使用5Why法）
|
||||
3. **解决**：提交Hotfix（遵循2.2规范）
|
||||
4. **验证**：回归测试 + 文档更新
|
||||
**3.3 追踪要求**
|
||||
- 所有问题关联知识库条目（Confluence）
|
||||
- P0级问题必须输出《故障报告》
|
||||
**✅ 检查点：**
|
||||
- 问题平均解决时长（MTTR）统计
|
||||
- **评估标准：** P0解决时效达标率100%，知识库覆盖率 ≥ 90%
|
||||
|
||||
---
|
||||
|
||||
#### **4. 执行约束规范（Seiketsu - 清洁）**
|
||||
**目标：** 建立可持续的高效工作节奏。
|
||||
**4.1 工作纪律**
|
||||
- 每日站会 ≤ 15分钟（聚焦阻塞点）
|
||||
- 专注时段（10:00-12:00/14:00-16:00）禁用IM通知
|
||||
**4.2 时间管理**
|
||||
- 任务拆解为 ≤2h 的原子任务
|
||||
- 使用番茄工作法（25分钟专注+5分钟休息）
|
||||
**4.3 沟通协作**
|
||||
- 紧急问题：Slack @责任人 + 电话
|
||||
- 技术讨论：提前预约会议（需提供议题文档）
|
||||
**✅ 检查点：**
|
||||
- 周计划完成率（实际完成/计划任务数）
|
||||
- **评估标准：** 计划完成率 ≥ 85%，会议超时率 ≤ 10%
|
||||
|
||||
---
|
||||
|
||||
#### **5. 环境和输出规范（Shitsuke - 素养）**
|
||||
**目标：** 保障交付物质量与知识传承。
|
||||
**5.1 工作环境标准**
|
||||
- 本地开发环境：
|
||||
- 使用Docker容器化（版本锁定）
|
||||
- IDE插件统一（Prettier/ESLint）
|
||||
- 项目目录结构：
|
||||
```bash
|
||||
/src # 源代码
|
||||
/tests # 测试用例
|
||||
/docs # 项目文档
|
||||
README.md # 项目入口
|
||||
```
|
||||
**5.2 交付物质量标准**
|
||||
| 交付物 | 质量要求 |
|
||||
|--------------|------------------------------|
|
||||
| 代码 | 通过SonarQube质量门禁 |
|
||||
| 部署包 | 包含版本签名（GPG） |
|
||||
| 用户文档 | 提供搜索功能 + 截图示例 |
|
||||
**5.3 知识沉淀要求**
|
||||
- 技术方案评审后48小时内归档
|
||||
- 每月输出1篇技术总结（含踩坑记录）
|
||||
**✅ 检查点：**
|
||||
- 交付物验收通过率（QA测试报告）
|
||||
- **评估标准：** 一次交付合格率 ≥ 95%，知识文档产出量 ≥ 1篇/人/月
|
||||
|
||||
---
|
||||
|
||||
### **执行保障机制**
|
||||
1. **个人看板**：使用Trello管理每日任务（To Do/Doing/Done）
|
||||
2. **月度自评**：依据检查点填写《5S执行评分表》（满分100分，≥80分达标）
|
||||
3. **持续改进**：季度复盘会（优化低分项规范）
|
||||
|
||||
> **附件模板：**
|
||||
> - [5S执行评分表.xlsx](链接)
|
||||
> - [文档变更记录模板.md](链接)
|
||||
> - [JIRA问题分类标签表.csv](链接)
|
||||
|
||||
本规范通过**工具强制（CI/CD门禁）** + **文化引导（知识共享）** 双轨落地，确保开发者从"被动遵守"到"主动优化"的进阶。
|
||||
alwaysApply: false
|
||||
---
|
||||
70
.cursor/rules/python-flask-rules.mdc
Normal file
70
.cursor/rules/python-flask-rules.mdc
Normal file
@@ -0,0 +1,70 @@
|
||||
---
|
||||
description:Cursor Rules中的6A工作流规则是一套针对AI辅助编程的项目管理方法论，其核心是通过结构化流程提升开发效率和代码质量。以下是该规则的具体解析：
|
||||
一、6A阶段划分
|
||||
|
||||
Align（对齐）
|
||||
|
||||
需求澄清阶段，禁止模糊表述，需明确功能边界和技术约束
|
||||
典型产出：需求文档、接口定义和技术选型报告
|
||||
|
||||
Architect（架构）
|
||||
|
||||
先设计后编码，要求输出系统架构图和模块拆分方案
|
||||
避免"边写边改"的开发模式，强调设计先行原则
|
||||
|
||||
Atomize（原子化）
|
||||
|
||||
将大任务拆解为可独立完成的小单元，每个子任务需明确：
|
||||
• 输入输出规范
|
||||
• 验收标准
|
||||
• 预估工时
|
||||
|
||||
Approve（审批）
|
||||
|
||||
人工审核AI生成的代码，重点关注：
|
||||
• 与设计文档的一致性
|
||||
• 潜在安全风险
|
||||
• 性能瓶颈
|
||||
采用代码审查清单机制确保检查全面性
|
||||
|
||||
Automate（执行）
|
||||
|
||||
严格按文档实施，禁止擅自修改需求范围
|
||||
要求：
|
||||
• 版本控制规范提交
|
||||
• 自动化测试覆盖
|
||||
• 持续集成流水线
|
||||
|
||||
Assess（评估）
|
||||
|
||||
质量验收阶段，包含：
|
||||
• 功能测试报告
|
||||
• 性能基准测试
|
||||
• 代码健康度分析
|
||||
不合格需返回对应阶段重构
|
||||
|
||||
二、实施要点
|
||||
|
||||
文档驱动开发
|
||||
|
||||
每个阶段必须生成标准文档（Markdown/图表）才能进入下一阶段
|
||||
推荐使用版本化的设计文档仓库
|
||||
|
||||
递归任务分解
|
||||
|
||||
复杂功能需进行多级拆解，直到每个子任务可被AI可靠执行为止
|
||||
典型拆解层级：模块→组件→函数→逻辑块
|
||||
边界控制
|
||||
通过.cursorignore文件限制AI修改范围
|
||||
使用@file/@folder指令聚焦当前开发模块
|
||||
|
||||
三、适用场景
|
||||
|
||||
中大型项目开发（推荐）
|
||||
需要长期维护的代码库
|
||||
多人协作的AI辅助编程项目
|
||||
|
||||
该工作流通过强制分阶段审核和文档化，有效解决了AI编码常见的需求漂移、代码质量不稳定等问题。实际应用中建议结合Git版本控制规范（如语义化版本）形成完整管理体系。
|
||||
globs:
|
||||
alwaysApply: true
|
||||
---
|
||||
Reference in New Issue
Block a user