ethan-skill 1.15.2 → 1.15.4

package/rules/cline/.clinerules

@@ -1,5 +1,5 @@
-# Ethan v1.15.0
-# Generated: 2026-04-11T16:46:27.639Z
+# Ethan v1.15.3
+# Generated: 2026-04-14T03:45:03.061Z
 # Source: https://github.com/aokiz-ek/smart-flow-skill
 
 Ethan。当用户输入以下触发词时，按对应 Skill 的步骤执行。
@@ -97,6 +97,13 @@ Ethan。当用户输入以下触发词时，按对应 Skill 的步骤执行。
 - **移动端专项审查**: 移动端审查 | mobile review | ios review | android review
 - **数据管道设计**: 数据管道 | data pipeline | etl | elt
 - **ML 实验管理**: ml experiment | mlops | model training | 模型训练
+- **自动修复**: 自动修复 | auto fix | auto-fix | CI 失败
+- **Agent 记忆**: agent 记忆 | agent memory | 持久化记忆 | persistent memory
+- **竞品分析**: 竞品分析 | 竞品对比 | competitive analysis | 竞争对手
+- **售前方案**: 售前方案 | 方案建议书 | solution proposal | 方案制作
+- **测试计划**: 测试计划 | 测试策略 | test plan | 测试方案
+- **缺陷管理**: 缺陷管理 | 缺陷报告 | bug report | 提 bug
+- **运维手册**: 运维手册 | runbook | 操作手册 | 变更管理
 
 ---
 
@@ -6527,5 +6534,1323 @@ if drift_detected:
 
 输出格式：实验设计文档 + MLflow/W&B 追踪配置 + DVC 数据管道 + Model Card + 部署 A/B 测试方案 + 漂移监控配置
 
+## 自动修复
+
+触发：自动修复 | auto fix | auto-fix | CI 失败
+说明：读取 CI/测试/Lint 失败信息，自动分析根因、生成修复方案并迭代验证，直到通过（最多 3 轮）
+
+1. 收集失败信息
+收集所有可用的失败上下文：
+
+**信息来源（优先级从高到低）**
+- CI 流水线日志（完整 stderr/stdout，不截断）
+- 测试框架输出（Jest / Vitest / PyTest / Go test）
+- Lint 报告（ESLint / Prettier / tsc / pylint）
+- 构建错误（webpack / vite / tsc）
+- 运行时异常（stack trace + 上下文代码）
+
+**必须提取的字段**
+```
+失败类型:    [ 测试失败 | Lint | 类型错误 | 构建失败 | 运行时错误 ]
+失败文件:    [文件路径:行号]
+错误信息:    [原始错误文本，保留完整 stack trace]
+触发条件:    [哪个命令/步骤触发]
+上次绿灯:   [最近一次通过的 commit / 时间（如可获取）]
+```
+
+> 如果日志超长，提取前 100 行 + 最后 50 行，优先保留 "FAILED"、"ERROR"、"at " 行。
+
+2. 根因分析
+对每个失败逐一诊断根因，区分「直接原因」和「根本原因」：
+
+**失败类型与常见根因速查**
+
+| 失败类型 | 直接原因 | 根本原因示例 |
+|---------|---------|------------|
+| 测试断言失败 | 返回值与预期不符 | 业务逻辑变更未同步更新测试 |
+| 测试超时 | 异步未正确 resolve | 缺少 await 或 mock 配置不当 |
+| 类型错误 | interface 不匹配 | API 变更未更新消费方类型 |
+| Lint 报错 | 代码风格违规 | 缺少 import、未使用变量、规则变更 |
+| 构建失败 | 模块未找到 | 路径别名配置、缺少依赖 |
+| 运行时错误 | 空指针/未定义 | 边界条件未处理 |
+
+**输出根因诊断表**
+```
+失败 #1
+  文件:       src/auth/login.test.ts:42
+  错误:       Expected "invalid" but received "error"
+  直接原因:   返回值从 "error" 改为 "invalid"
+  根本原因:   auth.ts 第 89 行修改了错误码但未同步测试
+  修复难度:   🟢 简单（更新测试断言）
+  可自动修复: ✅
+
+失败 #2
+  文件:       src/utils/parser.ts:15
+  错误:       Type 'string | null' is not assignable to 'string'
+  直接原因:   getUser() 返回值新增了 null 类型
+  根本原因:   API 层变更未向下传播 null 处理
+  修复难度:   🟡 中等（需添加 null guard）
+  可自动修复: ✅
+```
+
+3. 生成修复方案（Round 1）
+针对每个可自动修复的失败，生成最小化修复方案：
+
+**修复原则**
+- 最小改动原则：只修改必须改的代码
+- 不引入新问题：修复后不能导致其他测试失败
+- 保持语义一致：修复逻辑应符合原始意图
+- 优先修代码而非修测试（除非测试本身写错了）
+
+**分优先级处理**
+1. 🔴 **先修 Blocker**：类型错误、构建失败（影响所有后续步骤）
+2. 🟡 **再修测试**：断言失败、Mock 配置（影响覆盖率报告）
+3. 🟢 **最后修 Lint**：风格问题（不影响功能，可批量修复）
+
+**Lint 批量自动修复命令**
+```bash
+npx eslint src --fix
+npx prettier src --write
+```
+
+**输出修复 Diff（每个失败一个代码块）**
+```diff
+// 修复 #1：更新测试断言
+- expect(result).toBe('error');
++ expect(result).toBe('invalid');
+
+// 修复 #2：添加 null guard
+- const name = getUser().name;
++ const user = getUser();
++ const name = user?.name ?? '';
+```
+
+4. 应用修复并验证
+应用修复方案后立即验证：
+
+**验证步骤（按失败类型）**
+```bash
+# 测试失败
+npx vitest run [changed-test-file]   # 先跑单文件，快速反馈
+npx vitest run                        # 再跑全量，确认无新增失败
+
+# 类型错误
+npx tsc --noEmit                     # 全量类型检查
+
+# Lint 错误
+npx eslint src --max-warnings 0      # 不允许遗留 warning
+
+# 构建失败
+npm run build                        # 完整构建验证
+```
+
+**验证结果记录**
+```
+Round 1 结果：
+  修复前：❌ 3 失败（2 测试 + 1 类型错误）
+  修复后：
+    ✅ 测试失败 #1 — 已修复（断言更新）
+    ✅ 类型错误 #2 — 已修复（null guard）
+    ❌ 测试失败 #3 — 仍失败（需进入 Round 2）
+```
+
+5. 迭代修复（Round 2-3）
+如果 Round 1 仍有失败，进入迭代模式：
+
+**迭代策略**
+- **Round 2**：针对剩余失败，进行更深入的根因分析（可能是 Round 1 修复引入了副作用）
+- **Round 3**：最终尝试，优先保证 CI 通过（允许临时 skip 不稳定测试，但必须标注 @todo）
+
+**副作用检测**（重要）
+```
+检查 Round 1 修复后的新增失败：
+- 是否有原本通过的测试现在失败了？
+- 如果有，优先回退引入副作用的修改，重新设计方案
+```
+
+**Round 3 后仍失败的处理**
+```markdown
+## ⚠️ 需要人工介入
+
+以下失败无法通过自动修复解决：
+
+### 失败 #X
+- **错误**：[原始错误]
+- **已尝试**：[已尝试的修复方案]
+- **失败原因**：[为什么自动修复不可行]
+- **建议人工处理**：[具体建议步骤]
+- **最低可行方案**：暂时 skip 此测试，添加 TODO 注释：
+  `// TODO(@owner): fix in #issue-number — [简短原因]`
+```
+
+**迭代上限约束**
+- 最多 3 轮迭代，防止无限循环
+- 每轮必须有至少 1 个失败被修复，否则停止并输出人工介入指引
+
+6. 输出修复报告
+所有轮次完成后，输出结构化修复报告：
+
+```markdown
+## Auto-Fix 修复报告
+
+### 修复概览
+- **总失败数**：X
+- **自动修复**：Y（Y/X）
+- **需人工处理**：Z
+- **迭代轮次**：N 轮
+
+### 修复详情
+
+| # | 文件 | 错误类型 | 修复方式 | 状态 |
+|---|------|---------|---------|------|
+| 1 | src/auth.ts:42 | 断言失败 | 更新期望值 | ✅ Round 1 |
+| 2 | src/utils.ts:15 | 类型错误 | 添加 null guard | ✅ Round 1 |
+| 3 | src/api.ts:88 | 集成测试 | 更新 Mock 配置 | ✅ Round 2 |
+
+### 代码变更摘要
+[修改的文件列表 + 每处修改的简短说明]
+
+### 需要人工介入
+[如有，列出无法自动修复的项目 + 建议]
+
+### 预防建议
+- [导致此次失败的系统性问题]
+- [建议的规范或流程改进]
+```
+
+输出格式：Markdown 修复报告：根因诊断表 + 分 Round 修复 Diff + 验证结果 + 人工介入指引（如有）
+
+## Agent 记忆
+
+触发：agent 记忆 | agent memory | 持久化记忆 | persistent memory
+说明：提取并持久化项目关键决策、架构约束与已解决问题，跨会话注入 Agent 上下文，消除重复探索
+
+1. 识别值得记忆的信息
+并非所有信息都值得持久化，聚焦以下四类高价值记忆：
+
+**四类核心记忆**
+
+| 类型 | 描述 | 示例 |
+|------|------|------|
+| 🏗️ **架构决策** | 重要的技术选型和设计取舍 | "使用 Zustand 而非 Redux，因为项目规模小、不需要 devtools" |
+| ⚠️ **已知陷阱** | 踩过的坑、避坑经验 | "直接调用 /api/v1/user 会 401，必须先刷新 token" |
+| 📐 **项目约定** | 命名规范、目录结构、代码约束 | "所有异步操作用 useQuery，禁止裸 fetch" |
+| ✅ **已解决问题** | 解决了的复杂 bug 和方案 | "iOS Safari 下 flex gap 不生效，用 margin 替代" |
+
+**识别触发条件**
+- 对话中出现「为什么要这样」「这个项目的约定是」「上次解决这个问题的方法是」
+- 重要的 ADR（架构决策记录）产出
+- 排查超过 30 分钟的 bug 及其解决方案
+- 用户明确说「记住这个」
+
+**不值得记忆的信息**
+- 一次性任务的临时上下文
+- 可以从代码本身读出的信息
+- 过于宽泛的"最佳实践"（已在 CLAUDE.md 中）
+
+2. 结构化记忆条目
+将识别到的信息格式化为标准记忆条目：
+
+**记忆条目格式（YAML）**
+```yaml
+# .ethan/agent-memory/architecture.yaml
+entries:
+  - id: mem_001
+    type: architecture_decision    # architecture_decision | gotcha | convention | resolved_bug
+    title: 状态管理选型：Zustand over Redux
+    content: |
+      本项目使用 Zustand 进行全局状态管理。
+      原因：组件树层级浅（≤3层），不需要时间旅行调试，Redux 模板代码过多。
+      影响：所有跨组件状态通过 useXxxStore() hook 访问，不使用 Context API。
+    tags: [state-management, zustand, frontend]
+    created_at: 2024-01-15
+    confidence: high               # high | medium | low
+    scope: global                  # global | module:<name> | file:<path>
+```
+
+**文件组织结构**
+```
+.ethan/agent-memory/
+├── architecture.yaml    # 架构决策
+├── gotchas.yaml         # 已知陷阱
+├── conventions.yaml     # 项目约定
+├── resolved-bugs.yaml   # 已解决问题
+└── index.yaml           # 记忆索引（供快速检索）
+```
+
+**记忆条目质量标准**
+- title：一句话，包含关键词（方便检索）
+- content：5-10 行，包含决策背景 + 结论 + 影响范围
+- tags：3-5 个，技术栈 + 模块 + 问题类型
+- confidence：high=已验证可重用，medium=上下文相关，low=存疑待确认
+
+3. 写入持久化存储
+将格式化的记忆条目追加写入对应文件：
+
+**写入操作**
+```bash
+# 目录不存在时自动创建
+mkdir -p .ethan/agent-memory
+
+# 在 index.yaml 更新记忆摘要（用于快速检索）
+# index.yaml 格式：
+# entries:
+#   - id: mem_001
+#     title: "状态管理选型：Zustand over Redux"
+#     type: architecture_decision
+#     tags: [state-management, zustand]
+#     file: architecture.yaml
+```
+
+**记忆维护规则**
+- 同一主题新记忆覆盖旧记忆（更新 content + updated_at）
+- 标记为 low confidence 的记忆，3 个月未访问则删除
+- 每次成功使用后，将 confidence 升级（low → medium → high）
+- 发现记忆内容已过时时，立即更新或标记 deprecated
+
+**与 .ethan/team-knowledge/ 的区别**
+| | agent-memory | team-knowledge |
+|--|---|---|
+| 写入者 | AI（自动提取） | 人工（ethan knowledge add）|
+| 格式 | 结构化 YAML | 自由文本 Markdown |
+| 粒度 | 单条决策/问题 | 完整知识文档 |
+| 检索 | 按 tags + type 自动匹配 | 按关键词全文搜索 |
+
+4. 记忆检索与上下文注入
+在新会话开始或 Agent 执行前，检索相关记忆注入上下文：
+
+**检索策略（多维度匹配）**
+```
+1. 任务关键词 ↔ 记忆 tags（精确匹配）
+2. 当前工作文件路径 ↔ 记忆 scope（前缀匹配）
+3. 失败信息中的技术词 ↔ 记忆 title（模糊匹配）
+4. 最近 7 天被访问的记忆（时间权重提升）
+```
+
+**注入格式（添加到系统提示词开头）**
+```markdown
+## 📚 项目记忆上下文（来自 .ethan/agent-memory/）
+
+### 架构决策
+- **状态管理**：使用 Zustand，不用 Redux。所有跨组件状态通过 useXxxStore() 访问。
+- **API 层**：统一使用 React Query，禁止裸 fetch 调用。
+
+### 已知陷阱
+- ⚠️ iOS Safari 下 flex gap 不生效，用 margin-right/bottom 替代
+- ⚠️ /api/v1/user 接口在 token 过期时返回 200 + {error: "token_expired"}，非标准 401
+
+### 项目约定
+- 组件文件统一 PascalCase，工具函数 camelCase
+- 单元测试覆盖率要求 ≥ 80%（核心业务）
+
+> ⓘ 以上记忆来自 .ethan/agent-memory/（共 N 条）。如有不准确，请更新记忆文件。
+```
+
+**记忆命中反馈**
+每次使用记忆后，记录命中情况：
+```yaml
+# .ethan/agent-memory/index.yaml
+  - id: mem_003
+    last_hit: 2024-03-20
+    hit_count: 7
+    confidence: high    # 命中多次后自动升级
+```
+
+5. 记忆审计与清理
+定期维护记忆库，确保记忆的准确性和有效性：
+
+**审计清单**
+```bash
+# 查看所有记忆
+ethan memory list
+
+# 统计记忆健康度
+ethan memory stats
+# 输出：
+#   总记忆条数：48
+#   高置信度：32 | 中：12 | 低：4
+#   30天未命中：8条（建议清理）
+#   重复/矛盾：2组（需合并）
+```
+
+**记忆衰减策略**
+- 90 天未命中：自动降级 confidence（high → medium → low）
+- 180 天未命中的 low confidence 记忆：标记为 deprecated，下次审计删除
+- 代码库重大重构后：批量检查相关记忆是否仍有效
+
+**记忆冲突处理**
+```
+如发现两条矛盾的记忆：
+1. 保留更新的（created_at 更晚）
+2. 将旧的标记为 deprecated
+3. 在新记忆的 content 中注明「取代了 mem_xxx」
+```
+
+**团队共享记忆**
+```bash
+# 将记忆同步到 git（团队共享）
+ethan sync push --include agent-memory
+
+# 拉取团队记忆
+ethan sync pull
+
+# 记忆文件建议加入 .gitignore 的例外
+# .gitignore:
+# !.ethan/agent-memory/*.yaml
+```
+
+输出格式：YAML 记忆条目文件（写入 .ethan/agent-memory/）+ Markdown 注入格式的上下文摘要
+
+## 竞品分析
+
+触发：竞品分析 | 竞品对比 | competitive analysis | 竞争对手
+说明：系统收集竞品信息，构建多维对比矩阵，识别差异化机会，输出可执行的竞品洞察报告
+
+1. 界定分析范围
+明确竞品分析的边界和目标：
+
+**确认以下信息**
+- **分析目的**：售前支撑 / 产品规划 / 定价策略 / 功能取舍
+- **目标客户群**：哪类客户在同时考察我方和竞品？
+- **核心场景**：客户最关心哪 3-5 个使用场景？
+- **分析时效**：一次性深度分析 vs 持续监测
+
+**竞品分层**
+```
+直接竞品（核心战场）：
+  - 相同目标客户、相似产品形态、直接争抢同一笔预算
+  - 通常 3-5 个，重点深入分析
+
+间接竞品（边缘防御）：
+  - 不同产品形态但解决同一问题
+  - 通常 2-3 个，了解即可
+
+替代方案（需求层竞争）：
+  - 客户可能选择的完全不同的路径（如自研、外包）
+  - 列出但不做深度分析
+```
+
+2. 信息收集
+系统化收集竞品多维度信息：
+
+**官方渠道**
+- 官网产品页、定价页、案例页（截图留存，注明日期）
+- 产品文档/帮助中心（了解功能边界）
+- 官方博客/发布说明（了解产品方向）
+- LinkedIn / 招聘信息（判断团队规模和技术方向）
+
+**用户反馈渠道**
+- G2 / Capterra / 产品猎人（Product Hunt）评分与评论
+- App Store / 各应用市场用户评价
+- 知乎、Reddit、Twitter 用户讨论
+- 重点提取：**高频好评**（核心优势）和**高频差评**（核心痛点）
+
+**公开数据**
+- SimilarWeb / Alexa 流量数据
+- GitHub Stars / 开源活跃度（技术产品）
+- 融资信息（Crunchbase）— 判断竞品资源投入
+
+**第一手情报**（如可获取）
+- 试用竞品产品（免费版 / Demo）
+- 竞品销售人员对话记录
+- 客户提供的竞品方案 / RFP 评估
+
+> ⚠️ 所有信息注明来源和收集时间，竞品信息时效性强，超过 3 个月需重新验证
+
+3. 构建对比矩阵
+将收集信息结构化为多维对比矩阵：
+
+**功能对比矩阵**
+
+| 功能/场景 | 权重 | 我方 | 竞品A | 竞品B | 竞品C |
+|---------|------|------|-------|-------|-------|
+| 核心功能1 | 高 | ✅全支持 | ✅全支持 | ⚠️部分 | ❌不支持 |
+| 核心功能2 | 高 | ⚠️部分 | ✅全支持 | ✅全支持 | ⚠️部分 |
+| 差异功能X | 中 | ✅独有 | ❌ | ❌ | ❌ |
+
+评分说明：✅全支持(5) ⚠️部分支持(3) 🔧需定制(2) ❌不支持(0)
+
+**定价对比**
+
+| 维度 | 我方 | 竞品A | 竞品B |
+|------|------|-------|-------|
+| 起步价 | XXX | XXX | XXX |
+| 计费模式 | 按座席 | 按用量 | 按功能包 |
+| 企业版价格 | 询价 | 公开 | 询价 |
+| 免费版 | 有 | 有 | 无 |
+
+**非功能对比**
+
+| 维度 | 我方 | 竞品A | 竞品B |
+|------|------|-------|-------|
+| 部署方式 | SaaS+私有化 | 仅SaaS | 私有化 |
+| 数据合规 | 等保三级 | SOC2 | ISO27001 |
+| 技术栈/集成 | 开放API | 封闭 | 部分开放 |
+
+4. 优劣势分析（SWOT）
+基于对比矩阵提炼我方竞争态势：
+
+**竞争优势（Where We Win）**
+- 哪些功能维度我们明显领先？
+- 什么场景下客户更倾向选择我们？
+- 我们独有哪些能力（竞品无法快速复制）？
+
+**竞争劣势（Where We Lose）**
+- 哪些功能维度我们明显落后？
+- 客户最常拿哪些点质疑我们？
+- 竞品有哪些"杀手锏"功能我们缺失？
+
+**竞争机会（Gaps to Exploit）**
+- 竞品用户高频差评的问题，我们能更好解决吗？
+- 有哪些细分市场/场景竞品没有覆盖？
+
+**竞争威胁（What to Watch）**
+- 竞品近期有哪些重大产品发布/融资？
+- 哪些竞品正在往我方核心场景延伸？
+
+**竞争定位声明**（用于售前演讲）
+> "相比 [竞品]，我们在 [场景] 下通过 [差异化能力] 为客户实现 [业务价值]。
+> 对于看重 [竞品优势点] 的客户，我们的应对是 [我方策略]。"
+
+5. 输出竞品洞察报告
+输出结构化的竞品分析报告：
+
+```markdown
+# 竞品分析报告 — [产品/场景名称]
+
+**分析日期**：YYYY-MM-DD
+**分析目的**：[售前支撑 / 产品规划 / 定价策略]
+**主要竞品**：[竞品A、竞品B、竞品C]
+
+## 核心结论（TL;DR）
+- 🥇 我们的核心优势：[2-3句话]
+- ⚠️ 需正视的差距：[1-2句话]
+- 🎯 最佳竞争场景：[哪类客户/哪种场景最利于我们赢单]
+
+## 功能对比矩阵
+[表格]
+
+## 定价对比
+[表格]
+
+## 赢单话术（Battle Card）
+### 遇到"竞品A"时
+- **他们的优势**：[客观承认]
+- **我们的应对**：[差异化切入]
+- **杀手问题**（引导客户质疑竞品）：[具体问题]
+
+### 遇到"竞品B"时
+...
+
+## 产品团队建议
+- 短期（本季度）：[紧急补强点]
+- 中期（半年）：[规划差异化功能]
+- 长期监测：[持续关注的竞品动向]
+```
+
+输出格式：Markdown 竞品分析报告：功能矩阵 + 定价对比 + SWOT 分析 + Battle Card（赢单话术）+ 产品建议
+
+## 售前方案
+
+触发：售前方案 | 方案建议书 | solution proposal | 方案制作
+说明：根据客户需求制定针对性技术/商业解决方案文档，涵盖需求映射、方案架构、ROI 测算与实施路径
+
+1. 需求痛点梳理
+在写方案之前，彻底理解客户的真实诉求：
+
+**需求层次分析（冰山模型）**
+```
+表层需求（客户说的）：  "我们需要一个工单系统"
+深层需求（客户想的）：  "我们希望客诉处理更规范、更快"
+根本需求（客户要的）：  "我们希望客户满意度提升，减少流失"
+```
+
+**痛点信息收集清单**
+- [ ] 客户现有方案是什么？核心不满是什么？
+- [ ] 本次采购的直接触发事件是什么？（合同到期 / 业务扩张 / 监管要求）
+- [ ] 决策链：谁主导 / 谁审批 / 谁使用（不同角色关注点不同）
+- [ ] 预算范围和采购时间窗口
+- [ ] 已知的技术约束（现有系统、数据合规、部署要求）
+- [ ] 评估标准：客户最看重什么（功能 / 价格 / 服务 / 品牌）
+
+**关键痛点排序**（方案要优先回应前3个）
+```
+P0（不解决就不买）：
+P1（解决了加分很多）：
+P2（有更好，没有也行）：
+```
+
+2. 方案架构设计
+将客户需求映射到解决方案：
+
+**需求-能力映射表**
+
+| 客户痛点 | 我方解决方案 | 核心功能/模块 | 差异化亮点 |
+|---------|------------|-------------|----------|
+| [痛点1] | [解决思路] | [具体功能] | [为什么选我] |
+| [痛点2] | [解决思路] | [具体功能] | [为什么选我] |
+
+**解决方案架构图**
+
+用 Mermaid 或 ASCII 图描述方案整体架构：
+```mermaid
+graph TB
+  subgraph 客户侧
+    A[业务系统] --> B[集成层/API]
+  end
+  subgraph 我方平台
+    B --> C[核心功能模块]
+    C --> D[数据层]
+    C --> E[分析层]
+  end
+  E --> F[报表/大屏]
+```
+
+**分阶段交付建议**
+
+| 阶段 | 交付内容 | 时间 | 价值 |
+|------|---------|------|------|
+| 阶段一（MVP） | [核心功能，快速见效] | X周 | [快速见到ROI] |
+| 阶段二（深化） | [更多功能，深度集成] | X周 | [扩大收益] |
+| 阶段三（扩展） | [进阶能力] | X周 | [长期价值] |
+
+3. ROI 测算与价值量化
+用数字说话，让客户看到投资回报：
+
+**价值量化框架（优先选有数据支撑的）**
+
+| 价值维度 | 计算逻辑 | 估算数据 | 年化收益 |
+|---------|---------|---------|---------|
+| 效率提升 | 节省人工 X 小时/天 × 人力成本 | X人 × 2h/天 | ¥XXX/年 |
+| 错误减少 | 降低 X% 故障率 × 故障损失 | 年均X次故障 | ¥XXX/年 |
+| 合规价值 | 避免合规罚款/审计成本 | 潜在罚款 XXX | ¥XXX/年 |
+| 收入增长 | 支撑新业务 X% 增长 | 业务收入 XXX | ¥XXX/年 |
+
+**ROI 汇总**
+```
+总投资（TCO）：¥XXX（含实施+年费）
+年化收益：¥XXX
+投资回收期：X 个月
+3年ROI：X%
+```
+
+> 注：ROI 数据应基于客户自身业务规模估算，并注明假设前提。
+> 过于激进的ROI数字会损害可信度，保守估算更有说服力。
+
+**成功案例支撑**
+列举 1-2 个类似规模/行业客户的真实数据：
+> "[类似客户] 上线 X 个月后，[具体指标] 提升了 X%"
+
+4. 实施路径与保障
+让客户相信"我们能做到"：
+
+**实施方法论**
+```
+标准实施流程（X周）：
+  Week 1-2：需求确认 & 环境准备
+  Week 3-4：核心功能部署 & 数据迁移
+  Week 5-6：集成联调 & 用户培训
+  Week 7：UAT 验收 & 上线切换
+  Week 8+：运营支持 & 持续优化
+```
+
+**风险与应对**
+
+| 风险 | 概率 | 影响 | 应对措施 |
+|------|------|------|---------|
+| 数据迁移复杂 | 中 | 高 | 提前数据质量评估 + 并行迁移方案 |
+| 现有系统集成 | 高 | 中 | 提供标准 API + 专属集成支持 |
+| 用户接受度 | 中 | 中 | 分批上线 + 专项培训计划 |
+
+**服务保障承诺**
+- SLA 承诺：系统可用性 XX%，响应时间 < X小时
+- 实施团队：X 名工程师 + X 名项目经理
+- 售后支持：7×24 紧急响应 / 5×8 日常支持
+- 培训方案：在线培训 + 现场培训 + 操作手册
+
+5. 输出方案文档
+按受众定制方案版本：
+
+**完整技术方案（给技术决策者）**
+```markdown
+# [客户名称] [场景名称] 解决方案建议书
+
+## 执行摘要（1页，给C-level看）
+[核心问题 + 解决方案 + 预期价值 = 3句话]
+
+## 需求理解
+[对客户痛点的理解——体现我们"懂客户"]
+
+## 解决方案
+[方案架构图 + 功能说明 + 与竞品差异化]
+
+## 分阶段实施路径
+[阶段划分 + 时间线 + 里程碑]
+
+## 投资回报分析
+[ROI 测算表]
+
+## 实施保障
+[团队 + 方法论 + 服务承诺]
+
+## 关于我们
+[公司/产品核心优势 + 典型案例]
+```
+
+**精简演示版（PPT提纲，给汇报用）**
+1. 我们理解你的挑战（痛点共鸣）
+2. 我们的解决思路（架构图）
+3. 你将获得的价值（ROI）
+4. 我们的实施计划（时间线）
+5. 为什么是我们（差异化 + 案例）
+6. 下一步（明确行动项）
+
+输出格式：Markdown 方案建议书：需求映射 + 方案架构图 + ROI 测算表 + 实施路径 + 演示提纲
+
+## 测试计划
+
+触发：测试计划 | 测试策略 | test plan | 测试方案
+说明：制定全面的测试策略与计划，覆盖测试范围、用例设计、环境准备和质量门禁，确保产品质量可量化
+
+1. 测试范围与目标
+明确本次迭代的测试边界：
+
+**测试目标**
+- 本版本要验证的核心功能/场景
+- 回归范围：哪些已有功能可能受影响？
+- 明确不测的内容（Out of Scope）及原因
+
+**风险评估与测试重点**
+```
+高风险（必须全面测试）：
+  - 新增功能 / 核心主流程变更
+  - 与外部系统集成点
+  - 数据迁移或 Schema 变更
+
+中风险（重点测试）：
+  - 依赖被修改模块的功能
+  - 性能敏感路径
+
+低风险（冒烟测试即可）：
+  - UI 样式微调
+  - 文案修改
+  - 配置项变更
+```
+
+**测试类型矩阵**
+
+| 测试类型 | 是否需要 | 负责人 | 工具 |
+|---------|---------|--------|------|
+| 单元测试 | ✅ | 开发 | Vitest/Jest |
+| 接口测试 | ✅ | QA/开发 | Postman/Newman |
+| 集成测试 | ✅ | QA | Playwright/Cypress |
+| 性能测试 | 视需求 | QA | k6/JMeter |
+| 安全测试 | 视需求 | 安全/QA | OWASP ZAP |
+| 兼容性测试 | ✅ | QA | BrowserStack |
+
+2. 测试用例设计
+系统化设计测试用例，覆盖正常流、异常流和边界条件：
+
+**测试用例设计方法**
+
+**等价类划分**
+```
+有效等价类（正常输入）：
+  - 例：年龄字段 → 有效范围 [1, 150]
+
+无效等价类（异常输入）：
+  - 例：年龄字段 → 负数、0、>150、非数字、空值
+```
+
+**边界值分析**
+```
+对于范围 [min, max]，测试：min-1, min, min+1, max-1, max, max+1
+```
+
+**测试用例模板**
+
+| TC编号 | 模块 | 用例标题 | 前置条件 | 测试步骤 | 预期结果 | 优先级 |
+|--------|------|---------|---------|---------|---------|--------|
+| TC-001 | 登录 | 正确账密登录成功 | 账号已注册 | 1.输入账密 2.点击登录 | 跳转首页 | P0 |
+| TC-002 | 登录 | 错误密码提示友好 | 账号已注册 | 1.输入错误密码 2.点击登录 | 显示"密码错误" | P1 |
+
+**测试优先级定义**
+- **P0**：核心主流程，必须在版本发布前全部通过
+- **P1**：重要功能，应在发布前通过
+- **P2**：次要功能，可在下次迭代修复
+- **P3**：体验优化，记录但不阻塞发布
+
+**探索性测试 Charter**
+除结构化用例外，为高风险模块安排探索测试：
+```
+探索目标：[模块名称]
+时间盒：X 小时
+关注点：[并发操作、网络异常、异常数据输入等]
+记录方式：截图 + 操作日志
+```
+
+3. 测试环境与数据准备
+确保测试环境稳定、测试数据充分：
+
+**环境规划**
+
+| 环境 | 用途 | 部署方式 | 数据说明 |
+|------|------|---------|---------|
+| Dev | 开发自测 | 本地 | 模拟数据 |
+| Staging | QA 测试 | 自动部署 | 脱敏生产数据 |
+| PreProd | UAT验收 | 手动触发 | 接近真实数据 |
+| Production | 生产监控 | 审批发布 | 真实数据 |
+
+**测试数据策略**
+```
+数据分类：
+  - 正常数据：覆盖典型使用场景
+  - 边界数据：最大值、最小值、空值
+  - 异常数据：非法格式、SQL注入、XSS尝试
+  - 历史存量数据：模拟真实用户场景
+
+数据准备方法：
+  - 自动生成：Faker.js / 工厂函数
+  - 快照恢复：测试开始前恢复数据库快照
+  - 独立隔离：每个测试用例使用独立数据集，避免互相污染
+```
+
+**环境就绪检查**
+- [ ] 所有依赖服务（数据库、消息队列、第三方API）可用
+- [ ] 测试账号已创建（覆盖不同角色权限）
+- [ ] 监控和日志收集已开启
+- [ ] 被测版本已正确部署并通过冒烟测试
+
+4. 自动化测试策略
+规划自动化覆盖，实现质量门禁：
+
+**自动化优先级选择**
+```
+优先自动化的场景：
+  ✅ 回归测试（高频执行）
+  ✅ 核心主流程（P0 用例）
+  ✅ 接口测试（快速、稳定）
+  ✅ 数据驱动场景（大量参数组合）
+
+暂不自动化的场景：
+  ❌ 探索性测试（需人工判断）
+  ❌ 一次性场景（成本高于收益）
+  ❌ UI 频繁变更的页面（维护成本高）
+```
+
+**自动化框架选型**
+
+| 类型 | 框架 | 适用场景 |
+|------|------|---------|
+| 单元测试 | Vitest / Jest | 函数/组件逻辑 |
+| API 测试 | Supertest / Postman | 接口验证 |
+| E2E 测试 | Playwright | 全链路主流程 |
+| 性能测试 | k6 | 压力/负载测试 |
+
+**CI 集成配置**
+```yaml
+# 每次 PR 必须通过：
+- 单元测试（覆盖率 ≥ 80%）
+- API 接口测试（P0 用例全通过）
+
+# 每日定时（凌晨 2:00）：
+- 全量回归（含 P1 用例）
+- 性能基准测试（响应时间对比）
+```
+
+**质量门禁（Quality Gate）**
+
+| 指标 | 通过标准 | 失败处理 |
+|------|---------|---------|
+| 单测覆盖率 | ≥ 80% | 阻塞合并 |
+| P0 用例通过率 | 100% | 阻塞发布 |
+| P1 用例通过率 | ≥ 95% | 需评审 |
+| Critical/High Bug | 0 | 阻塞发布 |
+| 性能劣化 | P99 < 基线 120% | 需评审 |
+
+5. 缺陷管理与发布标准
+建立清晰的缺陷处理流程和发布质量标准：
+
+**缺陷严重级别定义**
+```
+P0 - Critical（阻塞级）：
+  系统崩溃、核心功能不可用、数据丢失/安全漏洞
+  → 立即修复，不发布
+
+P1 - High（严重）：
+  核心功能受损，有临时绕过方法
+  → 本版本修复
+
+P2 - Medium（一般）：
+  功能部分异常，不影响主流程
+  → 可延期至下版本
+
+P3 - Low（轻微）：
+  体验问题、文案错误、UI 细节
+  → 排期修复，不阻塞发布
+```
+
+**缺陷生命周期**
+```
+New → 开发确认 → In Progress → Fixed → 测试验证
+  ↓（无法复现/不修复）→ Closed / Won't Fix
+```
+
+**发布质量标准（Release Criteria）**
+- ✅ 所有 P0 Bug 已修复并验证
+- ✅ P1 Bug 修复率 ≥ 95%，剩余已评估风险
+- ✅ P0/P1 测试用例通过率 100%
+- ✅ 性能指标未出现显著劣化（对比基线）
+- ✅ 安全扫描无 Critical/High 漏洞
+- ✅ 主要浏览器/设备兼容性验证通过
+
+**测试报告模板**
+```markdown
+## 测试总结报告
+
+### 执行概况
+- 测试周期：[开始] ~ [结束]
+- 执行用例数：N（P0: x, P1: y, P2: z）
+- 通过率：X%
+- 发现缺陷：N（P0:x, P1:y, P2:z, P3:w）
+- 已修复：N / 待修复：N
+
+### 风险说明
+[遗留问题及上线风险评估]
+
+### 质量结论
+✅ 建议发布 / ⚠️ 有条件发布 / ❌ 不建议发布
+```
+
+输出格式：Markdown 测试计划文档：测试范围 + 用例设计矩阵 + 环境准备清单 + 自动化策略 + 发布质量标准
+
+## 缺陷管理
+
+触发：缺陷管理 | 缺陷报告 | bug report | 提 bug
+说明：规范缺陷报告撰写、优先级评估、根因追踪和统计分析，建立团队缺陷管理闭环
+
+1. 高质量缺陷报告撰写
+一份好的 Bug Report 让开发无需追问就能复现和修复：
+
+**缺陷报告必填字段**
+
+```markdown
+## Bug Report: [简洁描述，动词+对象+现象]
+
+**严重级别**: P0/P1/P2/P3
+**优先级**: 高/中/低
+**发现版本**: v1.x.x
+**环境**: [浏览器/OS/设备型号]
+**发现日期**: YYYY-MM-DD
+**报告人**: @名字
+
+### 问题描述
+[一句话描述：在[场景]下，执行[操作]，出现[异常现象]]
+
+### 复现步骤
+1. 前置条件：[账号状态、数据准备、环境配置]
+2. 操作步骤（精确、可重复）：
+   - Step 1: 进入 [页面/模块]
+   - Step 2: 执行 [具体操作]
+   - Step 3: 观察 [现象]
+3. 实际结果：[发生了什么]
+4. 预期结果：[应该发生什么，依据：需求文档/设计稿]
+
+### 复现率
+□ 必现（100%）  □ 偶现（约 X%）  □ 难以复现
+
+### 证据
+- 截图/录屏：[附件]
+- 错误日志：[关键堆栈信息]
+- 网络请求：[接口返回的异常数据]
+```
+
+**好 vs 坏 Bug Report 对比**
+
+| 差的写法 | 好的写法 |
+|---------|---------|
+| "登录有问题" | "输入正确密码后点击登录，接口返回 500 但页面无错误提示（必现）" |
+| "页面显示错误" | "商品列表第2页价格显示 0.00，实际应为正确价格（Safari 15 + macOS）" |
+
+2. 缺陷优先级与严重级别评估
+优先级评估直接影响研发排期，必须准确：
+
+**严重级别（Severity）— 描述影响范围**
+
+| 级别 | 定义 | 典型案例 |
+|------|------|---------|
+| **P0 Critical** | 系统崩溃 / 数据丢失 / 安全漏洞 / 核心功能完全不可用 | 支付失败但订单已创建、SQL注入 |
+| **P1 High** | 核心功能受损，无临时解决方案 | 购物车无法添加商品 |
+| **P2 Medium** | 功能部分异常，有绕过方法 | 导出 Excel 某列乱码，可手动复制 |
+| **P3 Low** | 体验问题、UI 细节、文案 | 按钮颜色不符合设计稿 |
+
+**优先级（Priority）— 决定修复时间**
+
+| 优先级 | 修复时间 | 说明 |
+|--------|---------|------|
+| 高 | 当天/1个工作日 | 影响版本发布或大量用户 |
+| 中 | 本迭代内 | 影响功能但不阻塞发布 |
+| 低 | 下个迭代 | 体验优化，排入 Backlog |
+
+**严重级别 ≠ 优先级**（重要）
+```
+案例：登录页 Logo 错位（P3 Severity）
+  → 但明天是品牌发布会 → Priority = 高
+
+案例：隐藏页面数据精度问题（P2 Severity）
+  → 用户无感知，下个迭代处理 → Priority = 低
+```
+
+3. 缺陷生命周期管理
+规范缺陷流转，确保每个 Bug 都有人负责、有结果：
+
+**缺陷状态流转**
+```
+[New] → 分配给开发确认
+  ↓           ↓
+[Confirmed]   [Rejected/Won't Fix]（说明原因）
+  ↓
+[In Progress] → 开发修复中
+  ↓
+[Fixed/待验证] → QA 回归验证
+  ↓           ↓
+[Closed]     [Reopen]（验证不通过）
+```
+
+**关闭条件明确化**
+```
+✅ 正常关闭（Closed）：
+  - 修复已验证通过
+  - 标注修复版本号
+
+⚠️ Won't Fix（不修复）：
+  - 说明原因：设计如此/无法复现/成本>收益
+  - 需 PM 或技术负责人确认
+
+🔄 延期（Deferred）：
+  - 说明延期原因和目标版本
+  - 不能无限期延期
+```
+
+**回归测试要点**
+```
+验证修复时，除验证原场景外还需检查：
+1. 相关功能是否引入新问题（Side Effect）
+2. 历史类似 Bug 是否也已修复（举一反三）
+3. 修复方案是否符合原始需求（不能"曲线救国"）
+```
+
+4. 缺陷根因分析
+从每个 Bug 中学习，驱动质量改进：
+
+**根因分类体系（参考 Orthogonal Defect Classification）**
+
+| 根因类别 | 说明 | 预防措施 |
+|---------|------|---------|
+| 需求理解偏差 | 开发理解与产品意图不一致 | 需求评审 + AC 验收标准 |
+| 逻辑缺陷 | 算法/条件判断错误 | 单元测试覆盖分支 |
+| 边界未处理 | Null/空/越界/特殊字符 | 测试用例覆盖边界值 |
+| 接口契约不一致 | 前后端字段/格式约定不一致 | API 文档 + 接口自动化测试 |
+| 并发/竞态 | 多用户操作时出现数据异常 | 并发测试 + 事务设计 |
+| 环境/配置差异 | 测试环境通过，生产环境报错 | 配置即代码 + 环境等价性 |
+| 数据问题 | 存量数据格式与新逻辑不兼容 | 数据迁移脚本 + 兼容性设计 |
+
+**5 Why 根因追溯（针对 P0/P1 Bug）**
+```
+Bug：用户余额扣减后订单状态仍为"待支付"
+
+Why 1: 为什么订单状态没更新？→ 更新订单状态的事务回滚了
+Why 2: 为什么回滚了？→ 库存扣减接口超时导致事务失败
+Why 3: 为什么超时？→ 库存服务在高并发时响应慢
+Why 4: 为什么没有降级处理？→ 缺少超时熔断配置
+Why 5: 为什么缺少？→ 技术方案设计时未考虑外部依赖超时场景
+
+根因：技术方案评审缺少分布式事务和超时处理checklist
+```
+
+5. 缺陷统计与质量分析
+用数据驱动质量持续改进：
+
+**核心缺陷指标**
+
+| 指标 | 计算方式 | 参考目标 |
+|------|---------|---------|
+| 缺陷发现率 | 发现缺陷数 / 测试用例数 | 低于 5% 说明系统质量良好 |
+| 缺陷修复率 | 已修复 / 总发现 × 100% | 发布前 P0/P1 ≥ 100% |
+| 缺陷逃逸率 | 生产 Bug / (测试Bug + 生产Bug) | 目标 < 5% |
+| 平均修复时间 | 修复耗时均值（按P级统计） | P0 < 4h, P1 < 24h |
+| 缺陷重开率 | Reopen 次数 / Close 次数 | 目标 < 10%（说明修复质量） |
+
+**缺陷分布分析**
+```
+维度1：按模块分布 → 识别质量热点，重点加强测试
+维度2：按根因分布 → 识别系统性问题，改进研发流程
+维度3：按发现阶段 → 越早发现成本越低，推动向左移测试
+  开发自测 < 代码审查 < 测试阶段 < 上线后
+```
+
+**周期性质量报告模板**
+```markdown
+## 缺陷分析报告 — v[版本] [时间范围]
+
+### 本期概况
+- 总发现: N 个（P0:x, P1:y, P2:z, P3:w）
+- 已关闭: N 个 | 遗留: N 个
+- 逃逸到生产: N 个（逃逸率: X%）
+
+### 质量热点
+高频缺陷模块 TOP3：
+1. [模块] — N 个缺陷 — 根因：[分类]
+2. ...
+
+### 改进行动
+- [针对高频根因的具体改进措施]
+- 负责人 & 完成时间
+```
+
+输出格式：Markdown 缺陷报告 + 优先级评估 + 根因分析（5 Why）+ 质量数据报告
+
+## 运维手册
+
+触发：运维手册 | runbook | 操作手册 | 变更管理
+说明：制定标准化运维手册（Runbook），涵盖日常操作、变更管理、故障响应和值班流程，实现运维操作可重复、可审计
+
+1. 服务概览与运维范围
+建立服务的运维基础信息档案：
+
+**服务基本信息**
+```markdown
+## 服务概览
+
+| 字段 | 内容 |
+|------|------|
+| 服务名称 | [service-name] |
+| 负责团队 | [团队名] |
+| 主要联系人 | [姓名 + 联系方式] |
+| 备用联系人 | [姓名 + 联系方式] |
+| 代码仓库 | [Git URL] |
+| 部署环境 | Staging: [URL] / Production: [URL] |
+| 监控大盘 | [Grafana/Datadog Dashboard URL] |
+| 日志链接 | [Kibana/Loki URL] |
+| 告警配置 | [AlertManager/PagerDuty URL] |
+| SLA 目标 | 可用性 99.9%，P99 < 500ms |
+```
+
+**依赖关系图**
+```
+[本服务] → 依赖 → [上游服务列表]
+           ← 被依赖 ← [下游服务列表]
+关键外部依赖：[数据库/缓存/消息队列/第三方API]
+```
+
+**运维范围界定**
+- 纳入本 Runbook 的操作：[列出]
+- 需要升级处理的情况：[列出，及升级联系人]
+- 禁止直接操作的内容：[如生产数据库写操作需 DBA 审批]
+
+2. 日常运维操作手册
+标准化高频运维操作，减少执行失误：
+
+**操作手册模板格式**
+```markdown
+### 操作名称：[动词 + 对象]
+
+**触发时机**：[什么情况下执行此操作]
+**执行频率**：[每日/每周/按需]
+**预计耗时**：[X 分钟]
+**风险等级**：🟢 低 / 🟡 中 / 🔴 高
+**前置条件**：[权限/环境/备份]
+**影响范围**：[会影响哪些服务/用户]
+
+#### 执行步骤
+1. [步骤1，精确到命令行]
+   ```bash
+   # 说明：[此命令的作用]
+   kubectl get pods -n production | grep service-name
+   ```
+2. [步骤2]
+3. [验证步骤：确认操作成功]
+
+#### 预期结果
+[执行成功后系统状态描述]
+
+#### 异常处理
+- 如果遇到 [错误A]：[处理方式]
+- 如果遇到 [错误B]：[停止操作，升级处理]
+```
+
+**日常巡检项（每日）**
+```
+□ 检查所有服务健康状态（Pod Running状态）
+□ 检查错误日志（过去24小时ERROR级别）
+□ 检查磁盘使用率（阈值 < 80%）
+□ 检查数据库连接池使用率
+□ 确认定时任务执行情况
+□ 检查证书过期时间（提前30天预警）
+```
+
+**常用操作索引**
+
+| 操作类别 | 操作名称 | 风险 | 章节 |
+|---------|---------|------|------|
+| 服务管理 | 重启服务 | 🟡 | §3.1 |
+| 扩缩容 | 手动扩容 Pod | 🟡 | §3.2 |
+| 数据库 | 只读查询 | 🟢 | §4.1 |
+| 发布 | 回滚到上个版本 | 🔴 | §5.3 |
+
+3. 变更管理流程
+规范变更操作，降低生产事故风险：
+
+**变更分类与审批矩阵**
+
+| 变更类型 | 风险 | 审批人 | 执行窗口 | 回滚时间 |
+|---------|------|--------|---------|---------|
+| 配置微调（无功能影响） | 🟢 低 | 自批 | 任意时间 | < 5min |
+| 服务版本升级 | 🟡 中 | Team Lead | 工作日9-18点 | < 15min |
+| 基础设施变更 | 🔴 高 | Tech Lead + Ops | 低峰期（凌晨2-4点） | 需人工干预 |
+| 数据库 DDL | 🔴 高 | DBA + Tech Lead | 维护窗口 | 需回滚脚本 |
+
+**变更执行 SOP**
+```
+变更前（Pre-Change）：
+  □ 变更申请已审批
+  □ 测试环境验证通过
+  □ 回滚方案已准备并测试
+  □ 相关团队已知会
+  □ 监控告警已关注
+
+执行中（During Change）：
+  □ 按步骤执行，不跳步
+  □ 每步执行后验证符合预期
+  □ 有专人实时监控关键指标
+  □ 记录每步操作和时间戳
+
+变更后（Post-Change）：
+  □ 核心功能冒烟测试通过
+  □ 监控指标正常（错误率/延迟）
+  □ 日志无异常
+  □ 更新变更记录文档
+```
+
+**变更回滚决策树**
+```
+出现异常 → 是否影响用户？
+          ↓ 是
+      能否快速定位并修复（< 15min）？
+          ↓ 不确定或 No
+      立即回滚 → 通知相关方 → 事后复盘
+```
+
+4. 故障响应与值班流程
+建立标准化的故障处置流程，缩短 MTTR：
+
+**告警分级与响应时间**
+
+| 告警级别 | 定义 | 响应时间 | 通知方式 |
+|---------|------|---------|---------|
+| P0 Critical | 服务不可用，影响全量用户 | 立即（5min内确认） | 电话 + IM + PagerDuty |
+| P1 High | 核心功能受损，影响部分用户 | 15 分钟内 | IM + PagerDuty |
+| P2 Medium | 功能降级，有替代方案 | 1 小时内 | IM |
+| P3 Low | 非关键指标异常 | 工作时间内 | 邮件/工单 |
+
+**故障响应 SOP（P0/P1）**
+```
+T+0   告警触发 → 值班工程师确认
+T+5   快速评估影响范围，上报故障
+T+10  决策：临时缓解 or 继续排查？
+       → 能快速缓解（重启/回滚/降级）：立即执行
+       → 需深入排查：拉相关同学进故障群
+T+30  每30分钟更新一次进展（状态页 + 钉/Slack）
+T+??  故障缓解 → 告知相关方 → 持续监控
+T+24h 输出故障复盘报告（ethan postmortem）
+```
+
+**值班手册**
+```markdown
+### 值班职责
+- 响应 P0/P1 告警（7×24）
+- 每日执行巡检清单
+- 处理常规运维请求（工作时间）
+
+### 值班工具
+- 告警: [PagerDuty/钉钉]
+- 监控: [Grafana Dashboard URL]
+- 日志: [Kibana URL]
+- 通讯: [故障频道]
+
+### 交接要点
+□ 未解决的告警和问题
+□ 进行中的变更
+□ 下周计划的变更
+□ 需要持续关注的风险点
+```
+
+**常用诊断命令**
+```bash
+# 查看服务状态
+kubectl get pods -n [namespace] -o wide
+
+# 查看最近日志
+kubectl logs -n [namespace] [pod-name] --tail=100 -f
+
+# 查看资源使用
+kubectl top pods -n [namespace]
+
+# 强制重启服务（仅在紧急情况）
+kubectl rollout restart deployment/[deployment-name] -n [namespace]
+```
+
+5. 容量规划与持续改进
+运维不只是救火，还要防患于未然：
+
+**容量规划指标**
+
+| 资源 | 当前使用 | 阈值（告警） | 扩容触发线 | 当前余量 |
+|------|---------|-----------|----------|---------|
+| CPU | [X%] | 80% | 70%（持续10min） | [X%] |
+| 内存 | [X GB] | 85% | 75% | [X GB] |
+| 磁盘 | [X TB] | 80% | 70% | [X TB] |
+| 数据库连接数 | [X/max] | 80% | 70% | [X] |
+| QPS | [X/s] | 80%容量 | 70%容量 | [X/s] |
+
+**扩容 SOP**
+```
+水平扩容（无状态服务）：
+  kubectl scale deployment/[name] --replicas=[n] -n [ns]
+  → 验证：kubectl get pods -n [ns] | grep [name]
+
+垂直扩容（数据库/有状态服务）：
+  → 需 DBA/架构师评审
+  → 在维护窗口执行
+  → 提前做好备份
+```
+
+**Runbook 维护机制**
+```
+更新触发条件：
+  ✅ 每次执行操作后发现步骤有误/过期 → 立即更新
+  ✅ 架构变更后 → 同步更新受影响章节
+  ✅ 故障复盘中发现操作缺失 → 补充
+
+维护责任人：[运维负责人]
+Review 周期：每季度一次全面 Review
+
+文档版本控制：
+  - 所有 Runbook 纳入 Git 版本管理
+  - 重大变更通过 PR 审批后合并
+  - 变更记录在文档头部的 Changelog
+```
+
+**运维成熟度自评**
+```
+L1 - 被动响应：靠人工经验处理，高度依赖老员工
+L2 - 规范化：有 Runbook，操作可重复
+L3 - 自动化：常见故障自愈，变更自动化执行
+L4 - 智能化：AIOps，预测性运维，主动预防
+     目标：尽快从 L[当前] 升级到 L[目标]
+```
+
+输出格式：Markdown 运维手册：服务档案 + 操作 SOP + 变更流程 + 故障响应流程 + 值班手册
+
 ---
 规则：严格按步骤执行，不跳步，输出遵循各 Skill 的格式模板。