@umacloud/knowledge 1.0.1

package/development/05-cases/case-security-incident-response.md

@@ -0,0 +1,345 @@
+---
+id: case-security-incident-response
+title: 案例研究：SQL 注入攻击发现、响应、修复与复盘全流程
+domain: development
+category: 05-cases
+difficulty: intermediate
+tags: [agent, case, checklist, development, incident, response, security, 元数据]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 案例研究：SQL 注入攻击发现、响应、修复与复盘全流程
+
+## 元数据
+
+| 字段 | 值 |
+|------|------|
+| 行业 | B2B 企业服务平台 |
+| 系统规模 | 企业客户 12,000+，日均 API 调用 800 万次 |
+| 技术栈 | Node.js + Express + PostgreSQL + Redis |
+| 团队规模 | 后端 15 人，安全 2 人，SRE 4 人 |
+| 事件等级 | P1（数据泄露风险） |
+| 时间线 | 发现到完全修复 72 小时 |
+
+---
+
+## 一、背景
+
+### 1.1 系统概述
+
+某 B2B 企业服务平台提供合同管理、客户管理、项目协作功能。系统采用前后端分离架构：
+
+- 前端：React SPA
+- 后端：Node.js + Express，共 45 个 API 端点
+- 数据库：PostgreSQL 15，包含合同、客户、用户等核心业务数据
+- 认证：JWT + OAuth 2.0
+- 部署：AWS ECS + RDS + ElastiCache
+
+### 1.2 安全现状（事件前）
+
+| 项目 | 状态 |
+|------|------|
+| WAF | AWS WAF 基础规则集 |
+| SQL 注入防护 | 部分接口使用 ORM，部分使用原生 SQL 拼接 |
+| 安全审计 | 每半年一次外部渗透测试 |
+| 日志审计 | CloudWatch 基础日志，无专门安全审计日志 |
+| 应急预案 | 有文档但未演练 |
+| SAST/DAST | 未集成到 CI/CD |
+
+---
+
+## 二、事件时间线
+
+### Day 0（周三）- 发现
+
+```
+14:23  WAF 告警：检测到异常请求模式，10 分钟内来自同一 IP 段
+       的 /api/v1/contracts/search 接口请求量激增 300%
+
+14:35  SRE 值班确认告警，初步判断为爬虫行为，加入观察
+
+14:52  安全工程师介入，分析请求日志发现可疑 payload：
+       GET /api/v1/contracts/search?keyword=test' OR 1=1--&page=1
+
+15:05  确认为 SQL 注入攻击尝试，升级为 P1 安全事件
+       启动安全事件响应流程（Security Incident Response Plan）
+
+15:10  成立事件响应小组：
+       - 指挥官：CTO
+       - 技术负责：安全工程师 + 后端 Tech Lead
+       - 通信负责：产品负责人
+       - 记录员：SRE
+```
+
+### Day 0 - 紧急响应（15:10 - 18:00）
+
+```
+15:10  第一响应动作：
+       1. WAF 临时封禁攻击 IP 段（12 个 IP）
+       2. 对 /api/v1/contracts/search 接口启用限流（50 QPS/IP）
+       3. 拉取最近 7 天该接口的全部访问日志
+
+15:30  日志分析发现：
+       - 攻击始于 3 天前（周日 02:17 UTC）
+       - 攻击者使用了 4 个不同 IP 段
+       - 共发送 2,847 个注入尝试请求
+       - 其中 23 个请求返回了非预期数据（HTTP 200 + 异常大响应体）
+
+15:45  确认漏洞：contracts/search 接口的 keyword 参数直接拼接到 SQL
+       /* 漏洞代码 */
+       const query = `SELECT * FROM contracts
+                      WHERE company_id = ${companyId}
+                      AND (title LIKE '%${keyword}%'
+                           OR contract_no LIKE '%${keyword}%')
+                      ORDER BY created_at DESC
+                      LIMIT ${limit} OFFSET ${offset}`;
+
+16:00  影响范围评估：
+       - 攻击者通过 UNION SELECT 获取了 contracts 表结构
+       - 通过 information_schema 查询确认获取了表名列表
+       - 23 个成功请求中，有 8 个提取了合同标题和金额数据
+       - 涉及 3 家企业客户的 47 份合同摘要信息
+       - 未触及用户密码/Token（存储在独立表，被 companyId 条件限制）
+
+16:30  紧急修复：
+       1. 将漏洞接口改为参数化查询（热修复）
+       2. 代码审查同类接口（发现另外 4 个使用原生 SQL 拼接的端点）
+       3. 同步修复全部 5 个漏洞端点
+
+17:00  热修复部署到生产环境
+       - 通过 ECS 蓝绿部署，0 downtime
+       - 部署后验证 5 个端点均不再可注入
+
+17:30  WAF 规则加固：
+       - 启用 AWS WAF SQL injection 规则集（严格模式）
+       - 添加自定义规则：检测 UNION/SELECT/information_schema 等关键词
+
+18:00  紧急响应阶段结束，进入调查阶段
+```
+
+### Day 1（周四）- 深度调查
+
+```
+09:00  全量日志分析：
+       - 使用 Athena 查询 CloudWatch Logs 近 30 天数据
+       - 确认攻击者未通过 SQL 注入进行写操作（UPDATE/DELETE/INSERT）
+       - 确认攻击者未获取到其他表的数据（companyId 隔离有效）
+       - 确认无横向移动迹象（未发现 RDS 异常连接或提权操作）
+
+10:00  数据泄露范围最终确认：
+       - 受影响企业：3 家
+       - 泄露数据：47 份合同的标题、合同编号、金额字段
+       - 未泄露数据：合同附件、用户个人信息、密码
+
+11:00  全代码库 SQL 注入扫描：
+       - 工具：semgrep + 自定义规则
+       - 扫描范围：45 个 API 端点
+       - 结果：
+         * 已修复：5 个端点（昨日热修复）
+         * 新发现：2 个端点使用 SQL 拼接但有输入校验（中等风险）
+         * 安全：38 个端点使用 ORM 参数化查询
+
+14:00  修复新发现的 2 个中等风险端点
+
+16:00  全量回归测试通过
+```
+
+### Day 1 - 客户通知
+
+```
+14:00  法务确认通知义务：
+       - 根据合同条款和数据保护法规，需通知受影响客户
+       - 虽然泄露的是商业数据非个人数据，仍需主动通知
+
+15:00  向 3 家受影响客户发送安全通知：
+       - 说明事件经过、影响范围、已采取措施
+       - 提供专线联系方式
+       - 承诺 7 日内提供完整事件报告
+```
+
+### Day 2（周五）- 加固与验证
+
+```
+09:00  数据库安全加固：
+       1. RDS 连接改为最小权限原则
+          - 应用账号移除 DROP/ALTER/CREATE 权限
+          - 只读查询使用只读账号连接只读副本
+       2. 启用 RDS 审计日志（pgAudit）
+       3. 设置异常查询告警（单次查询返回 > 1000 行）
+
+11:00  CI/CD 安全管线集成：
+       1. semgrep SAST 扫描加入 PR 检查（阻断级）
+       2. OWASP ZAP DAST 扫描加入 staging 部署后检查
+       3. npm audit 加入构建流程
+
+14:00  应用层加固：
+       1. 全面迁移到 Prisma ORM 参数化查询
+       2. 添加请求参数校验中间件（zod schema validation）
+       3. 添加 SQL 注入检测中间件（关键词黑名单 + 特殊字符过滤）
+       4. 增强审计日志：记录所有数据库查询的参数和执行时间
+
+16:00  渗透测试验证：
+       - 内部安全工程师使用 sqlmap 对全部 45 个端点进行自动化测试
+       - 结果：0 个可注入端点
+```
+
+### Day 3（周六）- 复盘
+
+```
+10:00  全员事件复盘会议（Blameless Post-mortem）
+       参加者：CTO、安全、后端全员、SRE、产品
+       时长：2 小时
+```
+
+---
+
+## 三、根因分析
+
+### 3.1 直接原因
+
+contracts/search 接口使用字符串拼接构造 SQL 查询，未对用户输入进行参数化处理或转义。
+
+### 3.2 深层原因
+
+| 层面 | 根因 | 说明 |
+|------|------|------|
+| 代码 | 开发规范未强制参数化查询 | 团队规范文档仅"建议"使用 ORM，未强制要求 |
+| 审查 | Code Review 未覆盖安全 | Review Checklist 无 SQL 注入检查项 |
+| 测试 | 无安全测试 | 单元测试和集成测试不含安全用例 |
+| 工具 | CI/CD 无 SAST/DAST | 安全扫描未集成到自动化流程 |
+| 流程 | 渗透测试频率低 | 每半年一次外部渗透测试，新代码窗口期过长 |
+| 监控 | WAF 规则过于宽松 | 使用默认规则集，未针对业务定制 |
+| 文化 | 安全意识不足 | 开发团队缺乏安全编码培训 |
+
+### 3.3 时间线复盘
+
+- 漏洞引入时间：4 个月前的一次功能迭代（搜索功能增强）
+- 攻击发生到发现：3 天（周日凌晨攻击 → 周三下午 WAF 告警）
+- 发现到紧急修复：2.5 小时
+- 完全加固：72 小时
+
+---
+
+## 四、改进措施
+
+### 4.1 短期（1 周内完成）
+
+| 序号 | 措施 | 负责人 | 完成状态 |
+|------|------|--------|----------|
+| 1 | 全部 SQL 拼接改为参数化查询 | 后端 Tech Lead | Day 2 完成 |
+| 2 | WAF 规则升级为严格模式 | SRE | Day 0 完成 |
+| 3 | CI/CD 集成 semgrep SAST | 安全工程师 | Day 2 完成 |
+| 4 | RDS 最小权限改造 | SRE | Day 2 完成 |
+| 5 | 启用 pgAudit 审计日志 | SRE | Day 2 完成 |
+
+### 4.2 中期（1 个月内完成）
+
+| 序号 | 措施 | 说明 |
+|------|------|------|
+| 1 | 全员安全编码培训 | OWASP Top 10 + 安全编码实践，覆盖全部开发人员 |
+| 2 | Code Review 安全 Checklist | PR 模板增加安全检查必选项 |
+| 3 | 安全单元测试模板 | 为所有 API 端点增加 SQL 注入/XSS 测试用例 |
+| 4 | 请求参数校验中间件 | 基于 zod 的统一输入校验 |
+| 5 | 安全审计日志平台 | 建立独立的安全事件日志收集和分析平台 |
+
+### 4.3 长期（3 个月内完成）
+
+| 序号 | 措施 | 说明 |
+|------|------|------|
+| 1 | Bug Bounty 计划 | 建立漏洞赏金计划，激励白帽子报告 |
+| 2 | 月度渗透测试 | 从半年一次改为每月自动化渗透 + 季度人工渗透 |
+| 3 | 安全冠军计划 | 每个团队指定一名安全冠军，负责本组代码安全审查 |
+| 4 | 威胁建模 | 对核心业务流程进行 STRIDE 威胁建模 |
+| 5 | 数据分级与加密 | 敏感字段（合同金额、客户信息）存储加密 |
+
+---
+
+## 五、结果数据
+
+### 5.1 安全指标改善
+
+| 指标 | 事件前 | 事件后（3个月） |
+|------|--------|-----------------|
+| SAST 覆盖率 | 0% | 100%（所有 PR 必过） |
+| DAST 覆盖率 | 半年一次 | 每次 staging 部署后 |
+| SQL 注入风险端点 | 7 个 | 0 个 |
+| 安全审计日志覆盖 | 30% | 100% |
+| 漏洞平均修复时间 | 未追踪 | 4.2 小时（Critical） |
+| 安全培训覆盖率 | 0% | 100% |
+| WAF 拦截/日 | ~200 次 | ~1,500 次（严格模式） |
+
+### 5.2 事件响应能力
+
+| 指标 | 本次事件 | 改进后目标 |
+|------|----------|------------|
+| 攻击到发现（MTTD） | 3 天 | < 1 小时 |
+| 发现到遏制（MTTC） | 47 分钟 | < 15 分钟 |
+| 遏制到修复（MTTR） | 2 小时 | < 1 小时 |
+| 完全加固 | 72 小时 | < 24 小时 |
+
+### 5.3 业务影响
+
+- 3 家受影响客户中，2 家接受处理结果并续约
+- 1 家客户要求签署补充安全协议后续约
+- 未产生法律诉讼或监管罚款
+- 团队安全意识和能力显著提升
+
+---
+
+## 六、经验教训
+
+### 6.1 关键认知
+
+1. **安全债务比技术债务更危险**：一个 SQL 拼接漏洞可能导致全量数据泄露，修复成本远超预防成本
+2. **自动化是安全基线**：依赖人工 Code Review 发现安全问题不可靠，必须有自动化工具兜底
+3. **最小权限原则必须落地**：应用数据库账号不需要 DDL 权限，但很少有团队认真执行
+4. **监控覆盖决定发现速度**：本次事件 3 天才发现，根因是安全监控不够细致
+5. **Blameless 复盘更有价值**：不追责的复盘让团队愿意暴露更多问题，改进更彻底
+
+### 6.2 安全编码铁律
+
+- **永远不要拼接 SQL**：100% 使用参数化查询或 ORM
+- **永远不要信任用户输入**：所有输入必须校验和清洗
+- **永远使用最小权限**：数据库账号、API 权限、文件权限
+- **永远记录审计日志**：谁在什么时间对什么数据做了什么操作
+- **永远假设会被攻击**：安全设计基于"何时被攻击"而非"是否被攻击"
+
+### 6.3 响应流程优化
+
+- 事件分级标准必须预定义（P0-P3）
+- 每个级别的响应 SLA、通知范围、决策权限必须明确
+- 响应流程必须定期演练（至少每季度一次 Table-top Exercise）
+- 事件复盘模板标准化，确保改进项有 Owner 和 Deadline
+
+---
+
+## Agent Checklist
+
+在 AI Agent 辅助处理安全事件或进行安全审计时，应逐项确认：
+
+### 预防阶段
+- [ ] **输入校验**：所有 API 端点是否对用户输入进行了类型、长度、格式校验
+- [ ] **参数化查询**：是否 100% 使用参数化查询/ORM，无 SQL 字符串拼接
+- [ ] **XSS 防护**：输出是否进行了适当的编码和转义
+- [ ] **认证授权**：是否实现了完整的认证和细粒度授权
+- [ ] **SAST 集成**：CI/CD 是否集成了静态安全分析工具
+- [ ] **依赖审计**：是否定期检查第三方依赖的已知漏洞
+- [ ] **最小权限**：数据库连接、服务账号是否遵循最小权限原则
+
+### 检测阶段
+- [ ] **WAF 配置**：WAF 规则是否覆盖了 OWASP Top 10 攻击模式
+- [ ] **审计日志**：是否记录了完整的访问日志和操作日志
+- [ ] **异常检测**：是否有基于流量模式/错误率/响应大小的异常告警
+- [ ] **安全扫描**：是否定期执行 DAST/渗透测试
+
+### 响应阶段
+- [ ] **事件分级**：是否有明确的安全事件分级标准
+- [ ] **响应预案**：是否有预定义的事件响应流程和角色分工
+- [ ] **遏制手段**：是否有快速封禁 IP/关闭接口/启用限流的能力
+- [ ] **通知流程**：是否有明确的内部通报和客户通知模板
+- [ ] **取证保全**：是否能快速保全日志和受影响数据的快照
+
+### 复盘阶段
+- [ ] **根因分析**：是否从代码/流程/工具/文化多层面分析根因
+- [ ] **改进跟踪**：改进措施是否有明确的 Owner、Deadline 和验证标准
+- [ ] **知识沉淀**：事件报告是否归档并纳入安全培训材料

package/development/06-glossary/full-stack-glossary.md

@@ -0,0 +1,166 @@
+---
+id: full-stack-glossary
+title: 全栈开发术语表
+domain: development
+category: 06-glossary
+difficulty: intermediate
+tags: [development, devops, full, glossary, stack, 前端术语, 后端术语, 安全术语]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 全栈开发术语表
+
+## 概述
+
+本术语表覆盖全栈开发中常用的技术术语、缩写和概念，按主题分类组织。
+
+---
+
+## 通用术语
+
+| 术语 | 英文 | 定义 |
+|------|------|------|
+| **API** | Application Programming Interface | 应用程序编程接口，定义软件组件之间的交互协议 |
+| **REST** | Representational State Transfer | 一种基于 HTTP 的 API 设计风格，使用资源和动词 |
+| **GraphQL** | - | Facebook 开发的 API 查询语言，客户端可以精确指定需要的数据 |
+| **gRPC** | gRPC Remote Procedure Call | Google 开发的高性能 RPC 框架，使用 Protocol Buffers |
+| **SDK** | Software Development Kit | 软件开发工具包 |
+| **CLI** | Command Line Interface | 命令行界面 |
+| **IDE** | Integrated Development Environment | 集成开发环境 (VS Code, JetBrains) |
+| **CI/CD** | Continuous Integration/Delivery | 持续集成/持续交付 |
+| **MVP** | Minimum Viable Product | 最小可行产品 |
+| **SaaS** | Software as a Service | 软件即服务 |
+| **IaC** | Infrastructure as Code | 基础设施即代码 (Terraform, Pulumi) |
+| **SLA** | Service Level Agreement | 服务级别协议 |
+| **SLO** | Service Level Objective | 服务级别目标 |
+| **SLI** | Service Level Indicator | 服务级别指标 |
+| **MTTR** | Mean Time To Recovery | 平均恢复时间 |
+| **MTTF** | Mean Time To Failure | 平均故障间隔时间 |
+
+## 前端术语
+
+| 术语 | 定义 |
+|------|------|
+| **SPA** | Single Page Application，单页应用 |
+| **SSR** | Server-Side Rendering，服务端渲染 |
+| **SSG** | Static Site Generation，静态站点生成 |
+| **CSR** | Client-Side Rendering，客户端渲染 |
+| **ISR** | Incremental Static Regeneration，增量静态再生 (Next.js) |
+| **Virtual DOM** | 虚拟 DOM，React/Vue 用于高效更新真实 DOM 的技术 |
+| **Hydration** | 水合，SSR 后在客户端激活交互的过程 |
+| **Tree Shaking** | 树摇优化，移除未使用代码以减小打包体积 |
+| **Code Splitting** | 代码分割，按需加载 JavaScript 模块 |
+| **Hot Module Replacement (HMR)** | 热模块替换，开发时无需刷新页面即可更新模块 |
+| **Web Vitals** | Google 定义的网页性能指标 (LCP, FID, CLS) |
+| **LCP** | Largest Contentful Paint，最大内容绘制（< 2.5s） |
+| **FID** | First Input Delay，首次输入延迟（< 100ms） |
+| **CLS** | Cumulative Layout Shift，累积布局偏移（< 0.1） |
+| **CORS** | Cross-Origin Resource Sharing，跨域资源共享 |
+| **CSP** | Content Security Policy，内容安全策略 |
+| **PWA** | Progressive Web App，渐进式 Web 应用 |
+| **A11y** | Accessibility 的缩写，无障碍访问 |
+| **WCAG** | Web Content Accessibility Guidelines，网页内容无障碍指南 |
+
+## 后端术语
+
+| 术语 | 定义 |
+|------|------|
+| **ORM** | Object-Relational Mapping，对象关系映射 (SQLAlchemy, Prisma) |
+| **Middleware** | 中间件，请求/响应处理链中的可插拔组件 |
+| **Rate Limiting** | 速率限制，防止 API 被过度调用 |
+| **Circuit Breaker** | 断路器，防止级联故障的设计模式 |
+| **Load Balancer** | 负载均衡器，将请求分发到多个服务实例 |
+| **Connection Pool** | 连接池，复用数据库/HTTP 连接以提升性能 |
+| **Message Queue** | 消息队列，异步通信组件 (Kafka, RabbitMQ, Redis) |
+| **Worker** | 工作进程，处理后台任务的独立进程 |
+| **Webhook** | 事件通知机制，服务主动推送事件到指定 URL |
+| **Idempotency** | 幂等性，多次执行同一操作结果相同 |
+| **CQRS** | Command Query Responsibility Segregation，命令查询职责分离 |
+| **Event Sourcing** | 事件溯源，使用事件流记录状态变更 |
+| **Saga** | 分布式事务管理模式，通过补偿操作保证一致性 |
+| **DDD** | Domain-Driven Design，领域驱动设计 |
+
+## 数据库术语
+
+| 术语 | 定义 |
+|------|------|
+| **ACID** | Atomicity/Consistency/Isolation/Durability，事务四大特性 |
+| **BASE** | Basically Available/Soft state/Eventually consistent，NoSQL 理论 |
+| **CAP** | Consistency/Availability/Partition tolerance，分布式系统三选二定理 |
+| **MVCC** | Multi-Version Concurrency Control，多版本并发控制 |
+| **WAL** | Write-Ahead Log，预写日志 |
+| **B-tree** | 平衡树索引，数据库最常用的索引结构 |
+| **Sharding** | 分片，将数据分布到多个数据库实例 |
+| **Replication** | 复制，数据从主节点同步到从节点 |
+| **Materialized View** | 物化视图，预计算并缓存的查询结果 |
+| **PITR** | Point-In-Time Recovery，时间点恢复 |
+
+## DevOps 术语
+
+| 术语 | 定义 |
+|------|------|
+| **Container** | 容器，轻量级隔离的运行环境 (Docker) |
+| **Pod** | Kubernetes 中最小的部署单元，包含一个或多个容器 |
+| **Helm** | Kubernetes 包管理器 |
+| **Service Mesh** | 服务网格，管理服务间通信的基础设施层 (Istio, Linkerd) |
+| **GitOps** | 以 Git 为唯一事实来源管理基础设施和部署 |
+| **Blue-Green Deployment** | 蓝绿部署，两个相同环境交替使用 |
+| **Canary Deployment** | 金丝雀部署，将流量逐步切换到新版本 |
+| **Rolling Update** | 滚动更新，逐步替换旧版本实例 |
+| **Observability** | 可观测性，通过指标/日志/追踪理解系统状态 |
+| **SRE** | Site Reliability Engineering，站点可靠性工程 |
+| **Chaos Engineering** | 混沌工程，通过故障注入验证系统韧性 |
+| **Toil** | 工辛 (SRE术语)，重复性、手工、可自动化的运维工作 |
+
+## 安全术语
+
+| 术语 | 定义 |
+|------|------|
+| **OWASP** | Open Web Application Security Project，Web 应用安全标准 |
+| **XSS** | Cross-Site Scripting，跨站脚本攻击 |
+| **CSRF** | Cross-Site Request Forgery，跨站请求伪造 |
+| **SSRF** | Server-Side Request Forgery，服务端请求伪造 |
+| **SQLi** | SQL Injection，SQL 注入 |
+| **JWT** | JSON Web Token，用于身份验证的令牌格式 |
+| **OAuth2** | 授权框架标准 |
+| **OIDC** | OpenID Connect，基于 OAuth2 的身份验证协议 |
+| **RBAC** | Role-Based Access Control，基于角色的访问控制 |
+| **Zero Trust** | 零信任安全模型，"永远不信任，始终验证" |
+| **SAST** | Static Application Security Testing，静态应用安全测试 |
+| **DAST** | Dynamic Application Security Testing，动态应用安全测试 |
+| **SCA** | Software Composition Analysis，软件组件分析 |
+| **CVE** | Common Vulnerabilities and Exposures，通用漏洞和暴露 |
+
+## AI/ML 术语
+
+| 术语 | 定义 |
+|------|------|
+| **LLM** | Large Language Model，大语言模型 |
+| **RAG** | Retrieval-Augmented Generation，检索增强生成 |
+| **Fine-tuning** | 微调，在预训练模型上针对特定任务训练 |
+| **Embedding** | 嵌入向量，将文本/图片转换为数值向量 |
+| **Token** | 令牌，LLM 处理的最小文本单元 |
+| **Context Window** | 上下文窗口，LLM 单次可处理的最大 Token 数 |
+| **Prompt Engineering** | 提示工程，设计输入以获取最佳 LLM 输出 |
+| **Agent** | 智能体，能自主使用工具完成任务的 AI 系统 |
+| **Hallucination** | 幻觉，LLM 生成看似合理但实际错误的内容 |
+| **MLOps** | Machine Learning Operations，机器学习运维 |
+| **Vector Database** | 向量数据库，专门存储和查询向量的数据库 |
+| **Inference** | 推理，使用训练好的模型进行预测 |
+
+---
+
+## Agent Checklist
+
+Agent 在技术文档和代码审查中遇到术语时:
+
+- [ ] 是否使用了团队一致认可的术语？
+- [ ] 缩写首次出现时是否有全称？
+- [ ] 是否避免了同一概念用不同名称？
+- [ ] 中英文术语是否统一？
+
+---
+
+**文档版本**: v1.0
+**最后更新**: 2026-03-28
+**质量评分**: 85/100

package/development/09-maturity/quarterly-audit-template.md

@@ -0,0 +1,35 @@
+---
+id: quarterly-audit-template
+title: quarterly-audit-template
+domain: development
+category: 09-maturity
+difficulty: intermediate
+tags: [audit, development, quarterly, template, 季度审计模板]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+
+## 季度审计模板
+
+### 审计概览
+- 审计周期：
+- 审计范围：
+- 审计负责人：
+
+### 指标结果
+- 首条命中率：
+- 零结果率：
+- 复用率：
+- 过期率：
+- 复审准时率：
+
+### 问题清单
+- 高风险问题：
+- 重复冲突问题：
+- 过期未修复问题：
+
+### 整改计划
+- 本季度修复目标：
+- 责任人：
+- 截止时间：

package/development/11-ui-excellence/ui-aesthetic-system.md

@@ -0,0 +1,41 @@
+---
+id: ui-aesthetic-system
+title: ui-aesthetic-system
+domain: development
+category: 11-ui-excellence
+difficulty: intermediate
+tags: [aesthetic, development, system, ui美学系统总册]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# 开发：Excellent（11964948@qq.com）
+
+## UI美学系统总册
+
+### 目标
+- 让界面同时满足“好看、好用、好做、可持续演进”。
+
+### 美学方向定义
+- 每个产品必须先定义视觉气质：专业稳重、科技未来、亲和活力、精品高端中的一种主方向。
+- 同一业务线不得同时采用冲突方向。
+- 新页面上线前必须通过风格一致性评审。
+
+### 视觉层级规则
+- 一级信息优先使用最大对比与最强权重。
+- 二级信息突出关系，不抢主操作。
+- 三级信息做辅助，不干扰任务路径。
+
+### 色彩系统
+- 使用品牌色、语义色、中性色三层模型。
+- 关键操作色不可超过两种。
+- 警告与错误色必须统一语义映射。
+
+### 排版系统
+- 标题、正文、说明至少三层字号体系。
+- 行高优先保证可读性，不以“紧凑”牺牲识别。
+- 长文本区域必须控制每行字符密度。
+
+### 质感系统
+- 阴影、描边、模糊、透明度按层级配比使用。
+- 禁止随意叠加装饰效果造成噪声。
+- 装饰元素必须服务于信息分组与引导。