ethan-skill 1.6.0 → 1.7.0

package/rules/claude-code/CLAUDE.md

@@ -1,11 +1,11 @@
 # Ethan v1.6.0
 
-> Auto-generated from src/skills/ | 2026-03-26T15:25:56.504Z
+> Auto-generated from src/skills/ | 2026-03-31T07:56:06.363Z
 > Do not edit manually. Source: src/skills/
 
 ## Ethan
 
-本文件配置了 10 个标准化工作流节点（Skill）。当用户输入触发词时，严格按对应 Skill 的步骤执行，输出遵循各 Skill 的格式模板。
+本文件配置了 14 个标准化工作流节点（Skill）。当用户输入触发词时，严格按对应 Skill 的步骤执行，输出遵循各 Skill 的格式模板。
 
 ## 执行原则
 
@@ -813,4 +813,642 @@ Why 5: 为什么没有自动化？→ CI/CD 流程中没有这个步骤
 
 ---
 
+### 11. 接口设计 (`api-design`)
+
+**描述**: 基于业务需求设计清晰、可演进的 RESTful / GraphQL 接口规范，输出接口文档
+
+**触发词**: `接口设计`, `API 设计`, `api design`, `设计接口`, `接口规范`, `RESTful 设计`, `GraphQL 设计`, `设计 REST API`, `设计 API`, `@ethan api`, `@ethan 接口`, `/接口设计`
+
+**执行步骤**:
+
+#### 1. 明确业务边界与资源模型
+
+- 梳理本次需要暴露的**核心业务实体**（资源）
+- 确定资源间的关联关系：一对一 / 一对多 / 多对多
+- 识别操作类型：CRUD、操作型动作（如 /activate、/cancel）
+- 确认调用方（Web / App / 第三方 / 内部服务）
+- 确认认证方式：JWT / OAuth2 / API Key / Session
+
+#### 2. 设计 URL 路径与 HTTP 方法
+
+遵循 REST 语义设计路径：
+
+**命名规范**
+- 使用复数名词表示集合：`/users`、`/orders`
+- 资源嵌套不超过 2 层：`/users/{id}/orders`
+- 动作使用子资源表达：`POST /orders/{id}/cancel`
+- 使用小写 kebab-case：`/user-profiles`
+
+**HTTP 方法映射**
+| 方法 | 场景 | 幂等性 |
+|------|------|--------|
+| GET | 查询（单个/列表） | ✅ |
+| POST | 创建 / 触发动作 | ❌ |
+| PUT | 全量更新 | ✅ |
+| PATCH | 局部更新 | ✅ |
+| DELETE | 删除 | ✅ |
+
+**版本控制**
+- URL 版本：`/api/v1/users`（推荐，可见性高）
+- Header 版本：`Accept: application/vnd.api+json;version=1`
+
+#### 3. 设计请求与响应体
+
+**请求体规范**
+- Content-Type 统一 `application/json`
+- 字段使用 camelCase（Web 侧）或 snake_case（按团队规范统一）
+- 必填字段明确标注，给出示例值
+- 枚举值给出完整列表和含义
+
+**统一响应体格式**
+```json
+{
+  "code": 0,           // 0=成功，非0=错误码
+  "message": "ok",     // 描述信息
+  "data": { ... },     // 业务数据（成功时）
+  "requestId": "uuid"  // 链路追踪 ID
+}
+```
+
+**分页响应**
+```json
+{
+  "code": 0,
+  "data": {
+    "list": [...],
+    "total": 100,
+    "page": 1,
+    "pageSize": 20
+  }
+}
+```
+
+**HTTP 状态码使用**
+- 200 OK / 201 Created / 204 No Content
+- 400 Bad Request（参数错误）/ 401 Unauthorized / 403 Forbidden
+- 404 Not Found / 409 Conflict / 422 Unprocessable Entity
+- 500 Internal Server Error（不暴露内部细节）
+
+#### 4. 设计错误码体系
+
+建立业务错误码规范，避免所有错误都返回 500：
+
+**错误码设计**
+```
+模块前缀 + 序号：
+1001xx — 用户模块
+1002xx — 订单模块
+1003xx — 支付模块
+```
+
+**示例**
+```json
+{
+  "code": 100101,
+  "message": "用户不存在",
+  "data": null,
+  "requestId": "abc-123"
+}
+```
+
+- 错误信息面向**开发者**（不直接展示给终端用户）
+- 敏感错误（如数据库异常）统一返回 `"系统繁忙，请稍后重试"`
+- 提供错误码文档（维护在 API 文档中）
+
+#### 5. 安全与性能设计
+
+**安全**
+- 所有修改类操作（POST/PUT/PATCH/DELETE）必须鉴权
+- 列表接口加入数据权限隔离（用户只能看自己的数据）
+- 文件上传接口限制文件类型和大小
+- 敏感字段（手机号、身份证）在响应中脱敏：`138****8888`
+- 接口加入速率限制（Rate Limiting）
+
+**性能**
+- 列表接口支持分页（禁止无限制全量返回）
+- 大数据量接口提供游标分页（cursor-based）
+- 支持字段过滤：`?fields=id,name,email`
+- 耗时操作改为异步：POST 立即返回 `taskId`，GET 轮询状态
+
+#### 6. 输出接口规范文档
+
+按以下格式输出每个接口的文档：
+
+```markdown
+## POST /api/v1/users — 创建用户
+
+**描述**：注册新用户账号
+
+**认证**：不需要
+
+**请求体**
+| 字段 | 类型 | 必填 | 描述 |
+|------|------|------|------|
+| username | string | ✅ | 用户名，3-20字符，字母数字下划线 |
+| email | string | ✅ | 邮箱地址 |
+| password | string | ✅ | 密码，最少8位 |
+
+**响应示例（201 Created）**
+```json
+{
+  "code": 0,
+  "message": "ok",
+  "data": {
+    "id": "usr_abc123",
+    "username": "john_doe",
+    "email": "john@example.com",
+    "createdAt": "2024-01-01T00:00:00Z"
+  }
+}
+```
+
+**错误码**
+| code | message | 场景 |
+|------|---------|------|
+| 100101 | 邮箱已被注册 | 邮箱重复 |
+| 100102 | 用户名不合法 | 格式校验失败 |
+```
+
+**输出格式**: Markdown 接口规范文档，含路径设计、请求/响应体、错误码表、安全说明，风格参考 OpenAPI 3.0
+
+**注意事项**:
+- URL 路径不使用动词，操作语义由 HTTP 方法表达
+- GraphQL 场景用 Schema First 原则，先定义类型再实现 resolver
+- 接口变更优先保持向后兼容，破坏性变更必须升版本号
+- 内部服务间调用（RPC/gRPC）可不遵循 REST 规范
+
+---
+
+### 12. 安全审查 (`security-review`)
+
+**描述**: 基于 OWASP Top 10 对代码和依赖进行安全扫描，识别漏洞并给出修复建议
+
+**触发词**: `安全审查`, `安全扫描`, `安全检查`, `漏洞扫描`, `security review`, `security audit`, `OWASP`, `安全风险`, `代码安全`, `@ethan 安全`, `@ethan security`, `/安全审查`
+
+**执行步骤**:
+
+#### 1. 确定审查范围
+
+- 明确审查对象：代码变更 / 整个模块 / 依赖包 / 部署配置
+- 确认技术栈（Node.js / Java / Python / 前端框架等）
+- 了解数据敏感程度：是否涉及 PII（用户个人信息）、金融数据
+- 确认暴露面：公网 API / 内部服务 / 用户上传入口
+- 收集现有安全策略（如 CSP、CORS 配置）
+
+#### 2. OWASP Top 10 逐项检查
+
+按 OWASP 2021 Top 10 逐项扫描：
+
+**A01 失效的访问控制**
+- 垂直越权：普通用户能否访问管理员接口？
+- 水平越权：用户A能否读取用户B的数据？
+- IDOR（不安全的直接对象引用）：接口参数是否直接暴露内部 ID？
+- 前端隐藏菜单 ≠ 权限控制，后端必须强制校验
+
+**A02 加密失效**
+- 密码是否使用 bcrypt/argon2（禁止 MD5/SHA1）
+- 传输层是否强制 HTTPS
+- 敏感字段（身份证、银行卡）是否静态加密存储
+- Cookie 是否设置 Secure + HttpOnly + SameSite
+
+**A03 注入**
+- SQL 注入：是否使用 ORM 参数化查询（禁止字符串拼接）
+- XSS：用户输入是否经过 HTML 转义后再输出
+- Command 注入：是否调用 shell 命令且参数含用户输入
+- LDAP/XML/NOSQL 注入场景检查
+
+**A04 不安全设计**
+- 是否存在无限重试（暴力破解风险）
+- 重要操作缺少二次确认（如删除账号、大额转账）
+- 密码重置流程是否可被枚举
+
+**A05 安全配置错误**
+- 生产环境是否关闭 Debug 模式、详细错误堆栈
+- 是否暴露 `.env`、`.git`、`node_modules` 等目录
+- 默认账号/密码是否修改
+- CORS 是否配置为 `*`（应按域名白名单）
+
+**A06 自带缺陷和过时的组件**
+- 运行 `npm audit` / `pip-audit` / `mvn dependency-check`
+- 检查高危 CVE（CVSS ≥ 7.0）
+- 框架和运行时是否在安全维护期内
+
+**A07 身份识别和认证失败**
+- JWT 是否验证签名和过期时间
+- Session 是否在登出时服务端失效
+- 多因素认证（MFA）是否支持
+
+**A08 软件和数据完整性失败**
+- 第三方 CDN 资源是否加 SRI（Subresource Integrity）
+- CI/CD 管道是否允许未授权修改部署配置
+- 序列化数据是否来自可信来源
+
+**A09 安全日志和监控失败**
+- 登录成功/失败是否记录 IP 和时间戳
+- 高危操作（删除、权限变更）是否有审计日志
+- 日志中是否意外记录了密码或 Token
+
+**A10 服务端请求伪造（SSRF）**
+- 接受 URL 参数的接口是否限制可访问的域名/IP
+- 是否阻断对内网地址（10.x/172.x/192.168.x/127.x）的请求
+
+#### 3. 密钥与凭据扫描
+
+- 扫描代码中是否硬编码了：API Key、数据库密码、JWT Secret、云账号 AK/SK
+- 检查 `.env` 文件是否被提交到 Git（查 `.gitignore`）
+- 历史 commit 是否包含敏感信息（可用 `git log -S "password"` 搜索）
+- 推荐工具：
+  - `gitleaks` — 扫描 git 历史中的密钥
+  - `trufflehog` — 高熵字符串检测
+  - GitHub Secret Scanning（如在 GitHub 托管）
+
+#### 4. 依赖漏洞扫描
+
+根据技术栈运行对应命令：
+
+```bash
+# Node.js
+npm audit --audit-level=high
+npx audit-ci --high
+
+# Python
+pip install pip-audit && pip-audit
+
+# Java/Maven
+mvn dependency-check:check
+
+# Docker 镜像
+trivy image your-image:tag
+```
+
+重点关注：
+- CVSS Score ≥ 7.0 的高危/严重漏洞
+- 直接依赖优先修复（间接依赖通过升级父包解决）
+- 有修复版本的立即升级，无修复的评估缓解措施
+
+#### 5. 按风险级别输出报告
+
+```markdown
+## 安全审查报告
+
+**审查范围**：[模块/文件/PR]
+**审查日期**：[日期]
+**整体风险等级**：🔴 Critical / 🟠 High / 🟡 Medium / 🟢 Low
+
+---
+
+### 🔴 Critical（立即修复，阻止上线）
+
+- [ ] `auth.ts:45` SQL 注入漏洞：用户 ID 直接拼接查询字符串
+  **修复**：使用 ORM 参数化查询 `db.query('SELECT * FROM users WHERE id = ?', [id])`
+  **CVE**：— **CVSS**：9.8
+
+### 🟠 High（本次迭代修复）
+
+- [ ] `upload.ts:23` 文件上传未限制类型，可上传 .php 执行文件
+  **修复**：白名单校验扩展名，并检查 MIME type
+
+### 🟡 Medium（计划修复）
+
+- [ ] 缺少登录频率限制（Rate Limiting），存在暴力破解风险
+  **修复**：引入 express-rate-limit，5次失败后锁定15分钟
+
+### 🟢 Low（建议改进）
+
+- [ ] Session Cookie 缺少 SameSite=Strict 属性
+
+### ✅ 已做好的安全措施
+- [值得肯定的安全实践]
+
+### 统计
+Critical: X | High: Y | Medium: Z | Low: W
+```
+
+**输出格式**: Markdown 安全审查报告，含 OWASP 维度检查结果、风险级别（Critical/High/Medium/Low）、修复建议和优先级
+
+**注意事项**:
+- Critical 问题必须在上线前修复，不接受任何例外
+- 前端安全校验只是 UX 辅助，所有安全逻辑必须在后端实现
+- 依赖漏洞扫描建议加入 CI 流程自动运行（每次 PR 触发）
+- 安全审查不能替代专业渗透测试，重大系统上线前建议委托专业团队
+
+---
+
+### 13. 部署上线 (`deployment`)
+
+**描述**: 系统化执行部署上线流程，覆盖预检、发布、验证和回滚，保障变更安全落地
+
+**触发词**: `部署上线`, `上线`, `发布`, `deploy`, `发版`, `部署`, `上线流程`, `发布流程`, `怎么上线`, `准备上线`, `@ethan 上线`, `@ethan deploy`, `/部署上线`
+
+**执行步骤**:
+
+#### 1. 上线前预检（Pre-flight）
+
+在发布代码前完成以下检查，任何一项 ❌ 不得上线：
+
+**代码质量**
+- [ ] 所有 CI 检查通过（单测、集成测试、Lint）
+- [ ] Code Review 已完成，无 Blocker 问题
+- [ ] 安全扫描无 Critical/High 级别漏洞（`npm audit`）
+- [ ] 变更已在 Staging/预生产环境验证通过
+
+**配置核查**
+- [ ] 生产环境配置（数据库、Redis、MQ 地址）已更新
+- [ ] 环境变量已在目标环境注入（不含硬编码的密钥）
+- [ ] Feature Flag 配置正确（灰度开关状态）
+
+**数据库变更**
+- [ ] 数据库迁移脚本已备份原表结构
+- [ ] 迁移脚本已在 Staging 执行并验证
+- [ ] 大表 DDL 变更（加字段/加索引）在低峰期执行，评估锁表时间
+
+**依赖与基础设施**
+- [ ] 第三方服务（支付/短信/CDN）已确认可用
+- [ ] 新增的 Redis Key / MQ Topic 已提前创建
+- [ ] 容器镜像已构建并推送到镜像仓库
+
+**通知**
+- [ ] 上线时间已知会相关团队（QA / 前端 / 产品 / 运维）
+- [ ] 回滚预案已准备（上个版本的镜像 Tag 或 SQL 回滚脚本）
+
+#### 2. 选择发布策略
+
+根据变更风险等级选择合适的发布策略：
+
+**🟢 滚动发布（Rolling Update）**
+- 场景：低风险常规迭代
+- 方式：逐个 Pod/实例替换，始终保持一定数量可用
+- Kubernetes：`kubectl set image deployment/app app=image:v2`
+- 优点：无停机；缺点：同时存在新旧版本（需兼容）
+
+**🟡 蓝绿部署（Blue/Green）**
+- 场景：中风险版本，需要快速回滚能力
+- 方式：并行运行两套环境，切换负载均衡流量
+- 优点：回滚只需切流量（秒级）；缺点：资源成本翻倍
+
+**🟠 灰度发布（Canary Release）**
+- 场景：高风险变更，需验证真实流量
+- 方式：先放 5%-10% 流量到新版本，观察监控后逐步扩量
+- 关键指标：错误率、P99 延迟、业务转化率
+- Nginx 示例：`split_clients "${remote_addr}" $upstream { 10% backend_v2; * backend_v1; }`
+
+**🔴 停机发布（Maintenance Window）**
+- 场景：强破坏性变更（如数据库大规模迁移）
+- 提前在状态页通知用户，维护窗口选在凌晨低峰期
+
+#### 3. 执行发布
+
+**自动化流水线（推荐）**
+```bash
+# GitOps 方式：更新镜像 Tag 触发 CD
+git tag v1.2.3 && git push origin v1.2.3
+
+# 手动触发 GitHub Actions
+gh workflow run deploy.yml --field environment=production --field version=v1.2.3
+```
+
+**发布过程监控要点**
+- 实时观察 Pod 滚动状态：`kubectl rollout status deployment/app`
+- 监控健康检查端点（Liveness/Readiness Probe）
+- 观察 APM 工具（Datadog/SkyWalking）中错误率和延迟变化
+- 若部署过程中出现 CrashLoopBackOff，立即暂停并触发回滚
+
+**数据库迁移执行顺序**
+1. 先执行 向后兼容的迁移（如加字段，设默认值）
+2. 发布新代码
+3. 确认新代码运行稳定后，再执行清理旧逻辑的迁移
+（Expand-Contract 模式，避免新旧代码不兼容）
+
+#### 4. 上线后验证
+
+发布完成后，在 **15 分钟内**完成以下验证：
+
+**基础健康检查**
+- [ ] 所有实例健康检查端点 `/health` 返回 200
+- [ ] Pod/实例数量与预期一致（未发生缩减）
+- [ ] 无 OOMKilled 或高 CPU 异常
+
+**监控告警**
+- [ ] 错误率（5xx）在基线水平（< 0.1%）
+- [ ] P99 响应时间未劣化（对比上线前）
+- [ ] 关键业务指标（下单量、登录量）趋势正常
+
+**核心链路冒烟测试**
+- [ ] 用最高风险的 1-3 个核心功能人工验证
+  - 示例：登录 → 查看商品 → 加购 → 提交订单
+- [ ] 检查日志无新增 ERROR 级别错误
+
+**灰度扩量（Canary 场景）**
+```
+5% → 稳定 10min → 20% → 稳定 10min → 50% → 100%
+```
+
+#### 5. 回滚方案
+
+**触发回滚的条件（满足任一立即回滚）**
+- 错误率超过基线 3 倍以上
+- P99 延迟超过告警阈值 2 倍
+- 核心业务指标断崖式下跌
+- 出现 Critical 级别报错
+
+**回滚操作**
+```bash
+# Kubernetes 快速回滚
+kubectl rollout undo deployment/app
+kubectl rollout undo deployment/app --to-revision=3  # 回滚到指定版本
+
+# Docker Compose 回滚
+docker-compose up -d --no-deps --scale app=2  # 拉起旧版本
+```
+
+**数据库回滚**
+- 向后兼容的迁移（加字段）通常不需要回滚
+- 破坏性迁移回滚需执行预先准备的 SQL 脚本
+- 数据删除操作必须在回滚脚本中用 INSERT 恢复（从备份）
+
+**上线后记录**
+- 记录上线时间、版本号、发布人
+- 若出现问题，触发故障排查（`ethan debug`）和事后复盘（`ethan oncall`）
+
+**输出格式**: Markdown 上线 Checklist + 执行记录，含预检清单、发布策略建议、验证结果和回滚记录
+
+**注意事项**:
+- 生产环境首次部署必须有专人在线值守，完成后才能离开
+- 数据库变更是最高风险项，大表 DDL 操作务必在低峰期执行
+- 回滚方案必须提前验证可用，不能到了出问题才发现回滚脚本有 bug
+- 蓝绿和灰度部署需要基础设施支持，提前确认 K8s/Nginx 配置
+
+---
+
+### 14. PRD 编写 (`prd`)
+
+**描述**: 从用户故事和业务目标出发，结构化生成产品需求文档（PRD），支撑研发高效落地
+
+**触发词**: `PRD`, `产品需求`, `写 PRD`, `需求文档`, `prd 编写`, `产品文档`, `写需求`, `功能需求`, `生成 PRD`, `@ethan PRD`, `@ethan 需求文档`, `/prd`, `/PRD`
+
+**执行步骤**:
+
+#### 1. 背景与目标
+
+明确以下关键信息（询问或推导）：
+
+**业务背景**
+- 这个功能/产品要解决什么业务问题？
+- 当前用户的痛点是什么？（现有方案的不足）
+- 有哪些量化的数据支撑这个问题的存在？
+
+**目标用户**
+- 主要用户角色：[角色名称 + 典型特征描述]
+- 次要用户角色：[如有]
+- 用户当前的操作路径是什么（Before）？
+
+**成功指标（OKR/KPI）**
+- 核心业务指标：如 "注册转化率提升 15%"、"客服工单减少 30%"
+- 次要指标：NPS、页面停留时长等
+- 不追求的指标（避免过度设计）：明确 out-of-scope
+
+**优先级与时间**
+- P0（必须有，MVP 核心）/ P1（重要但非必须）/ P2（锦上添花）
+- 目标上线日期：[日期]
+- 里程碑节点：[设计完成 / 研发完成 / 灰度 / 全量]
+
+#### 2. 用户故事与功能范围
+
+用标准用户故事格式描述每个功能点：
+
+**用户故事格式**
+> 作为 [用户角色]，
+> 我需要 [完成某事]，
+> 以便 [获得某种价值]。
+
+**示例**
+> 作为新注册用户，我需要通过邮箱验证激活账号，以便确保账号安全并接收通知邮件。
+
+**功能列表模板**
+
+| # | 功能模块 | 用户故事 | 优先级 | 研发工作量估算 |
+|---|---------|---------|--------|----------------|
+| 1 | 注册激活 | 新用户通过邮件激活账号 | P0 | M（3-5天）|
+| 2 | 邮件模板 | 支持品牌化邮件样式 | P1 | S（1-2天）|
+| 3 | 批量导入 | 管理员批量导入用户 | P2 | L（5-8天）|
+
+**明确 Out-of-Scope（本期不做的）**
+- [功能 A]：原因 / 延后到 v2
+- [功能 B]：超出本期范围
+
+#### 3. 详细功能描述与验收标准
+
+为每个 P0/P1 功能编写详细说明和可测试的验收标准：
+
+**功能详细描述模板**
+
+---
+
+#### 功能：[功能名称]
+
+**触发场景**：[用户在什么情况下使用此功能]
+
+**操作流程**（主流程 Happy Path）
+1. 用户进入 [入口页面]
+2. 操作 [步骤]
+3. 系统 [处理逻辑]
+4. 用户看到 [结果/反馈]
+
+**异常流程**
+- [条件] → 系统提示 "[错误信息]"
+- 网络超时 → 提示重试，不重复提交
+
+**验收标准（AC）**
+> Given [前置条件]
+> When [用户操作]
+> Then [系统行为 + 可量化结果]
+
+示例：
+- AC1: Given 用户输入正确邮箱和密码，When 点击登录，Then 3秒内跳转到首页
+- AC2: Given 用户连续5次密码错误，When 第6次尝试，Then 账号锁定15分钟并发送通知邮件
+
+---
+
+#### 4. 非功能性需求
+
+明确产品的质量属性约束：
+
+**性能**
+- 核心页面首屏加载时间：< 2秒（P75）
+- 核心接口响应时间：< 500ms（P99）
+- 并发支持：峰值 QPS XXX
+
+**可用性与可靠性**
+- SLA：99.9%（每月不超过 44 分钟停机）
+- 容灾：支持单机房故障切换
+- 数据备份：每日全量 + 实时增量
+
+**安全**
+- 涉及 PII 数据字段列表：[手机号、身份证号]
+- 合规要求：[GDPR / 等保二级 / 金融监管要求]
+- 脱敏规则：手机号显示 138****8888
+
+**兼容性**
+- 浏览器：Chrome 90+, Safari 14+, Firefox 88+（不支持 IE）
+- 移动端：iOS 13+, Android 8+
+- 屏幕适配：最小支持 375px 宽度
+
+**国际化**
+- 语言：简体中文（v1）/ 英文（v2规划）
+- 时区：UTC+8（如有跨时区需求需说明）
+
+#### 5. UI/UX 与交互说明
+
+**设计资源**
+- Figma/Sketch 链接：[填写]
+- 设计规范：遵循 [设计系统名称] 组件库
+- 标注版本：[v1.2 / 待定]
+
+**关键交互说明**
+列出容易被研发忽略的交互细节：
+
+- 空状态设计：列表无数据时展示 [空态图 + 引导文案]
+- Loading 状态：核心操作需要骨架屏（Skeleton），不用转圈
+- 错误状态：区分网络错误（可重试）和业务错误（不可重试）
+- 表单校验：实时校验（onBlur）还是提交时校验（onSubmit）
+- 动效要求：页面切换 fade-in 200ms，按钮点击 100ms 响应反馈
+
+**无障碍要求（A11y）**
+- 图片必须有 alt 属性
+- 颜色对比度不低于 4.5:1（WCAG AA 标准）
+- 核心操作支持键盘导航
+
+#### 6. 数据埋点与监控
+
+**埋点方案**
+
+| 事件名 | 触发时机 | 属性 | 说明 |
+|--------|---------|------|------|
+| page_view | 进入页面 | page_name, user_id | 必填 |
+| btn_click | 点击按钮 | btn_name, page | 所有 CTA 按钮 |
+| form_submit | 表单提交 | form_name, is_success | 含失败原因 |
+| feature_use | 使用核心功能 | feature_name, duration | 用于功能价值评估 |
+
+**业务监控告警**
+
+| 指标 | 告警阈值 | 负责人 |
+|------|---------|--------|
+| 注册成功率 | < 85% 触发告警 | PM + 后端 |
+| 支付成功率 | < 95% 立即告警 | PM + 后端 + 运维 |
+| 页面崩溃率 | > 0.1% 告警 | 前端 |
+
+**数据分析需求**
+- 上线后第 3/7/30 天分析用户路径漏斗
+- 功能使用率（功能激活用户 / 总用户）
+
+**输出格式**: Markdown PRD 文档，含背景目标、用户故事、功能详情（含验收标准 AC）、非功能性需求、UI/UX 说明和埋点方案
+
+**注意事项**:
+- PRD 应明确 Out-of-Scope，避免研发范围蔓延
+- 验收标准必须可测试，"用户体验好" 不是有效的 AC
+- 非功能性需求经常被遗漏，但对系统架构选型影响很大
+- 埋点方案尽早与数据团队对齐，避免上线后补埋导致历史数据断层
+
+---
+
 *Ethan - Your AI Workflow Assistant | 让每一步都有据可依*