@umacloud/knowledge 1.0.16 → 1.0.18

package/high-quality-engineering-playbook.md

@@ -1,15 +1,13 @@
 ---
 id: high-quality-engineering-playbook
-title: high-quality-engineering-playbook
-domain: high-quality-engineering-playbook.md
+title: 高质量工程知识库（Web 全栈版）
+domain: development
 difficulty: intermediate
-tags: [engineering, high, high-quality-engineering-playbook.md, playbook, quality, 全栈版]
+tags: [高质量工程, engineering, web全栈, 工程规范, 全栈, development, 商业级]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# high-quality-engineering-playbook
-
-## 高质量工程知识库（Web 全栈版）
+# 高质量工程知识库（Web 全栈版）
 
 ### 1. 目标与范围
 - 本知识库面向商业级 Web 应用，覆盖需求澄清、架构设计、交互体验、工程质量、上线运维与复盘。

package/incident/02-playbooks/chaos-engineering-playbook.md

@@ -11,10 +11,6 @@ quality_score: 70
 ---
 
 # 混沌工程作战手册
-# 功能：混沌工程全流程作战手册
-# 作用：指导团队安全地实施混沌实验以验证系统韧性
-# 创建时间：2026-03-28
-# 最后修改：2026-03-28
 
 ## 目标
 

package/incident/postmortem-and-response-deep-dive.md

@@ -1,16 +1,14 @@
 ---
 id: postmortem-and-response-deep-dive
-title: postmortem-and-response-deep-dive
+title: 事故响应与复盘深度知识库
 domain: incident
-category: postmortem-and-response-deep-dive.md
+category: 01-standards
 difficulty: intermediate
-tags: [and, deep, dive, incident, postmortem, response, 事故响应与复盘深度知识库]
+tags: [事故响应, postmortem, 复盘, incident-response, 根因分析, incident]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# postmortem-and-response-deep-dive
-
-## 事故响应与复盘深度知识库
+# 事故响应与复盘深度知识库
 
 ### 目标
 - 把每次故障转化为可复用的组织能力，持续降低重复事故概率。

package/mobile/01-standards/flutter-complete.md

@@ -2,17 +2,15 @@
 title: Flutter 完整开发标准
 category: mobile/standards
 version: 1.0.0
-last_updated: 2026-03-20
-maintainer: Excellent（）
+last_updated: 2026-06-29
 knowledge_score: 9.3/10
 domain: mobile
 difficulty: intermediate
-quality_score: 70
+quality_score: 83
 ---
 
 # Flutter 完整开发标准
 
-## Flutter 完整开发标准
 
 ### 1. 架构与分层
 - 遵循 Clean Architecture 或 MVVM 模式。
@@ -79,7 +77,6 @@ quality_score: 70
 
 ### Widget 组件示例
 ```dart
-// 开发：Excellent（）
 // 功能：用户头像组件
 // 作用：展示用户头像，支持默认头像和加载状态
 // 创建时间：2026-03-20
@@ -150,7 +147,6 @@ class UserAvatar extends StatelessWidget {
 
 ### 网络请求封装示例
 ```dart
-// 开发：Excellent（）
 // 功能：API 客户端封装
 // 作用：统一管理网络请求，包含认证和错误处理
 // 创建时间：2026-03-20
@@ -230,7 +226,6 @@ final apiClient = ApiClient();
 
 ### 状态管理示例（Provider）
 ```dart
-// 开发：Excellent（）
 // 功能：用户状态管理
 // 作用：管理用户登录状态和用户信息
 // 创建时间：2026-03-20

package/mobile/01-standards/react-native-complete.md

@@ -2,17 +2,15 @@
 title: React Native 完整开发标准
 category: mobile/standards
 version: 1.0.0
-last_updated: 2026-03-20
-maintainer: Excellent（）
+last_updated: 2026-06-29
 knowledge_score: 9.2/10
 domain: mobile
 difficulty: intermediate
-quality_score: 70
+quality_score: 83
 ---
 
 # React Native 完整开发标准
 
-## React Native 完整开发标准
 
 ### 1. 架构与分层
 - 业务层、展示层、数据层严格分离。
@@ -79,7 +77,6 @@ quality_score: 70
 ### TypeScript 组件示例
 ```typescript
 /**
- * 开发：Excellent（）
  * 功能：用户头像组件
  * 作用：展示用户头像，支持默认头像和加载状态
  * 创建时间：2026-03-20
@@ -138,7 +135,6 @@ const styles = StyleSheet.create({
 ### 网络请求封装示例
 ```typescript
 /**
- * 开发：Excellent（）
  * 功能：API 客户端封装
  * 作用：统一管理网络请求，包含认证和错误处理
  * 创建时间：2026-03-20
@@ -201,7 +197,6 @@ export const apiClient = new ApiClient();
 ### FlatList 优化示例
 ```typescript
 /**
- * 开发：Excellent（）
  * 功能：用户列表组件
  * 作用：高性能渲染用户列表，支持下拉刷新和加载更多
  * 创建时间：2026-03-20

package/mobile/02-playbooks/mobile-performance.md

@@ -2,17 +2,15 @@
 title: 移动应用性能优化手册
 category: mobile/playbooks
 version: 1.0.0
-last_updated: 2026-03-20
-maintainer: Excellent（）
+last_updated: 2026-06-29
 knowledge_score: 9.0/10
 domain: mobile
 difficulty: intermediate
-quality_score: 70
+quality_score: 83
 ---
 
 # 移动应用性能优化手册
 
-## 移动应用性能优化手册
 
 ### 执行步骤
 
@@ -88,7 +86,6 @@ quality_score: 70
 #### React Native 优化
 ```typescript
 /**
- * 开发：Excellent（）
  * 功能：优化 FlatList 性能
  * 作用：通过配置优化参数提升长列表渲染性能
  * 创建时间：2026-03-20
@@ -165,7 +162,6 @@ export default OptimizedList;
 
 #### Flutter 优化
 ```dart
-// 开发：Excellent（）
 // 功能：优化 ListView 性能
 // 作用：通过 const 和 builder 提升长列表渲染性能
 // 创建时间：2026-03-20
@@ -231,7 +227,6 @@ class _ItemTile extends StatelessWidget {
 #### React Native 性能监控
 ```typescript
 /**
- * 开发：Excellent（）
  * 功能：性能监控工具
  * 作用：记录和上报关键性能指标
  * 创建时间：2026-03-20
@@ -326,7 +321,6 @@ export const performanceMonitor = PerformanceMonitor.getInstance();
 
 #### Flutter 性能监控
 ```dart
-// 开发：Excellent（）
 // 功能：性能监控工具
 // 作用：记录和上报关键性能指标
 // 创建时间：2026-03-20

package/mobile/03-checklists/mobile-release-checklist.md

@@ -2,17 +2,15 @@
 title: 移动应用发布检查清单
 category: mobile/checklists
 version: 1.0.0
-last_updated: 2026-03-20
-maintainer: Excellent（）
+last_updated: 2026-06-29
 knowledge_score: 9.1/10
 domain: mobile
 difficulty: intermediate
-quality_score: 70
+quality_score: 85
 ---
 
 # 移动应用发布检查清单
 
-## 移动应用发布检查清单
 
 ### 一、功能完整性检查
 

package/mobile/04-antipatterns/mobile-antipatterns.md

@@ -2,17 +2,15 @@
 title: 移动开发反模式库
 category: mobile/antipatterns
 version: 1.0.0
-last_updated: 2026-03-20
-maintainer: Excellent（）
+last_updated: 2026-06-29
 knowledge_score: 9.0/10
 domain: mobile
 difficulty: intermediate
-quality_score: 70
+quality_score: 88
 ---
 
 # 移动开发反模式库
 
-## 移动开发反模式库
 
 ### 1. 性能反模式
 

package/operations/01-standards/prometheus-monitoring-complete.md

@@ -5,8 +5,8 @@ domain: operations
 category: 01-standards
 difficulty: intermediate
 tags: [complete, grafana仪表盘, kubernetes监控, monitoring, operations, prometheus, prometheus核心概念, promql查询语言]
-quality_score: 70
-last_updated: 2026-06-15
+quality_score: 90
+last_updated: 2026-06-29
 ---
 # Prometheus监控完整指南
 

package/operations/aiops-anomaly-detection.md

@@ -1,18 +1,14 @@
 ---
 id: aiops-anomaly-detection
-title: aiops-anomaly-detection
+title: AIOps 异常检测体系
 domain: operations
-category: aiops-anomaly-detection.md
+category: 01-standards
 difficulty: intermediate
-tags: [aiops, anomaly, detection, operations, 告警降噪, 实施架构, 常见失败模式, 异常检测算法]
+tags: [aiops, 异常检测, anomaly-detection, 告警降噪, 时序, 根因, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# aiops-anomaly-detection
-# 功能：AIOps 异常检测实践指南
-# 作用：利用机器学习和 AI 技术自动化检测和诊断系统异常
-# 创建时间：2026-03-20
-# 最后修改：2026-03-20
+# AIOps 异常检测体系
 
 ## 目标
 建立 AIOps 异常检测体系,通过机器学习算法自动识别系统异常、减少告警噪音、加速根因定位、实现智能运维。

package/operations/capacity-planning.md

@@ -1,18 +1,14 @@
 ---
 id: capacity-planning
-title: capacity-planning
+title: 容量规划体系
 domain: operations
-category: capacity-planning.md
+category: 01-standards
 difficulty: intermediate
-tags: [capacity, operations, planning, 容量规划报告, 容量规划流程, 当前状态, 执行摘要, 核心概念]
+tags: [容量规划, capacity-planning, 资源预测, 扩容, 成本, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# capacity-planning
-# 功能：容量规划实践指南
-# 作用：提供系统容量预测、规划和优化的完整方法论
-# 创建时间：2026-03-20
-# 最后修改：2026-03-20
+# 容量规划体系
 
 ## 目标
 建立科学的容量规划体系,预测业务增长带来的资源需求,提前规划扩容,避免性能瓶颈和资源浪费,实现成本与性能的最优平衡。

package/operations/chaos-engineering.md

@@ -1,18 +1,14 @@
 ---
 id: chaos-engineering
-title: chaos-engineering
+title: 混沌工程实践
 domain: operations
-category: chaos-engineering.md
+category: 01-standards
 difficulty: intermediate
-tags: [chaos, engineering, operations, 分钟, 实施流程, 实验信息, 实验概况, 核心原则]
+tags: [混沌工程, chaos-engineering, 故障注入, 韧性, 演练, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# chaos-engineering
-# 功能：混沌工程实践指南
-# 作用：通过主动注入故障验证系统韧性,提前发现和修复潜在问题
-# 创建时间：2026-03-20
-# 最后修改：2026-03-20
+# 混沌工程实践
 
 ## 目标
 建立混沌工程实践体系,通过受控的故障注入实验,验证系统在生产环境真实负载下的韧性,提前发现和修复潜在问题,提升服务可靠性。

package/operations/incident-command-system.md

@@ -1,16 +1,14 @@
 ---
 id: incident-command-system
-title: incident-command-system
+title: 事故指挥体系（ICS）手册
 domain: operations
-category: incident-command-system.md
+category: 02-playbooks
 difficulty: intermediate
-tags: [command, incident, operations, system]
+tags: [事故指挥, incident-command, ics, 应急响应, 值班, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# incident-command-system
-
-## 事故指挥体系（ICS）手册
+# 事故指挥体系（ICS）手册
 
 ### 目标
 - 在生产事故中实现统一指挥、快速止损、清晰协同。

package/operations/observability-complete.md

@@ -1,18 +1,14 @@
 ---
 id: observability-complete
-title: observability-complete
+title: 可观测性完整知识库
 domain: operations
-category: observability-complete.md
+category: 01-standards
 difficulty: intermediate
-tags: [complete, dashboard, observability, operations, 告警设计, 实施清单, 常见失败模式, 技术选型]
+tags: [可观测性, observability, 监控, 追踪, 日志, 告警, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# observability-complete
-# 功能：可观测性完整体系
-# 作用：提供日志、指标、追踪三大支柱的完整实施指南
-# 创建时间：2026-03-20
-# 最后修改：2026-03-20
+# 可观测性完整知识库
 
 ## 目标
 建立生产环境全链路可观测能力,实现故障快速定位、性能瓶颈精准识别、用户体验量化评估。

package/operations/slo-sli-playbook.md

@@ -1,18 +1,14 @@
 ---
 id: slo-sli-playbook
-title: slo-sli-playbook
+title: SLO/SLI 实践手册
 domain: operations
-category: slo-sli-playbook.md
+category: 02-playbooks
 difficulty: intermediate
-tags: [budget, operations, playbook, sli, slo, 实施流程, 核心概念, 目标]
+tags: [slo, sli, 可靠性, 错误预算, error-budget, 服务质量, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# slo-sli-playbook
-# 功能：SLO/SLI 实战手册
-# 作用：提供服务水平目标（SLO）和服务水平指标（SLI）的完整实施指南
-# 创建时间：2026-03-20
-# 最后修改：2026-03-20
+# SLO/SLI 实践手册
 
 ## 目标
 建立以 SLO 为中心的可靠性工程体系,量化服务质量,平衡功能交付与稳定性,实现数据驱动的故障响应和容量规划。

package/operations/sre-operations-deep-dive.md

@@ -1,16 +1,14 @@
 ---
 id: sre-operations-deep-dive
-title: sre-operations-deep-dive
+title: 运维环节深度知识库
 domain: operations
-category: sre-operations-deep-dive.md
+category: 01-standards
 difficulty: intermediate
-tags: [deep, dive, operations, sre, 运维环节深度知识库]
+tags: [sre, 运维, 可观测, 应急, 容量, operations]
 quality_score: 70
 last_updated: 2026-06-15
 ---
-# sre-operations-deep-dive
-
-## 运维环节深度知识库
+# 运维环节深度知识库
 
 ### 目标
 - 构建可观测、可响应、可恢复的生产运行体系。

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@umacloud/knowledge",
-  "version": "1.0.16",
+  "version": "1.0.18",
   "description": "UmaDev curated engineering knowledge corpus (standards, methodologies, expert playbooks, design systems, miniprogram/uniapp guides). Platform-independent data shipped once so npm users get the full KB offline.",
   "license": "MIT",
   "repository": { "type": "git", "url": "https://github.com/umacloud/umadev.git" },

package/product/feature-prioritization-framework.md

@@ -1,40 +1,102 @@
 ---
 id: feature-prioritization-framework
-title: feature-prioritization-framework
+title: 功能优先级决策框架（商业级必读）
 domain: product
-category: feature-prioritization-framework.md
+category: 02-playbooks
 difficulty: intermediate
-tags: [feature, framework, prioritization, product]
-quality_score: 70
-last_updated: 2026-06-15
+tags: [优先级, prioritization, 排期, roadmap, rice, kano, 价值成本矩阵, 决策门, 取舍, 需求评审, 产品, 商业级]
+quality_score: 95
+last_updated: 2026-06-29
 ---
-# feature-prioritization-framework
-
-## 功能优先级决策框架（深度版）
-
-### 目标
-- 统一需求排期口径，避免“拍脑袋优先级”导致资源浪费。
-
-### 四维评分模型
-- 业务价值：是否直接推动收入、留存、效率提升。
-- 用户价值：是否解决高频痛点或关键任务阻塞。
-- 实现成本：研发、测试、运维、培训与迁移成本。
-- 风险敞口：合规、安全、稳定性、依赖不确定性。
-
-### 评分规则
-- 每维 1-5 分，最终分数 = (业务价值+用户价值)×权重 - (实现成本+风险敞口)×权重。
-- 默认权重：业务价值0.35、用户价值0.25、实现成本0.2、风险0.2。
-- 分数相近时，以“减少关键链路风险”优先。
-
-### 决策门禁
-- 涉及账号、支付、权限、数据导出功能时，风险评分必须由安全与运维双签。
-- 涉及跨系统变更时，必须有回滚方案与兼容策略。
-- 未给出可量化验收标准的需求不得进入开发。
-
-### 输出模板
-- 需求名称
-- 预期业务影响
-- 用户受益群体
-- 估算工作量
-- 依赖项与风险
-- 发布策略与回滚方案
+
+# 功能优先级决策框架（商业级必读）
+
+> 优先级决定一个团队把有限的研发产能投到哪里——它比"做得好不好"更早、更致命地决定产品成败。最常见的失败不是把某个功能做砸，而是把整季产能投在低价值需求上。"拍脑袋排期""谁声音大做谁的""老板说的先做"都不是优先级方法，只是把决策责任藏起来。本框架把优先级从主观争论升级为**可复算、可追责、带门禁的决策**：每个需求都要有量化打分、验收标准、回滚策略，且高风险项必须双签。
+
+## 1. 先分类，再打分（不要对所有需求用同一把尺）
+
+打分前先用一个粗筛把需求分桶，避免把"救火"和"探索"放进同一个排序里：
+
+| 类型 | 判定 | 处置 |
+|---|---|---|
+| **合规/安全/止血** | 不做会违法、泄露、资损或线上事故 | 不进打分队列，直接最高优先级排期 |
+| **核心价值线** | 直接驱动北极星指标（激活/留存/收入/成本） | 进加权打分，主战场 |
+| **体验/效率优化** | 改善现有任务流的成功率与耗时 | 进打分，与价值线竞争产能 |
+| **探索/赌注** | 高不确定性、可能高回报 | 单独留固定产能比例（如 10–20%），不与确定性需求直接比分 |
+| **债务/可维护性** | 不做会持续拖慢未来交付 | 量化"拖慢成本"后进打分，禁止长期归零 |
+
+## 2. 四维加权评分模型
+
+每个进入打分队列的需求按四维各 1–5 分，给出可复算的综合分。
+
+| 维度 | 含义 | 1 分 | 5 分 | 默认权重 |
+|---|---|---|---|---|
+| 业务价值 | 对收入/留存/成本/战略的直接推动 | 几乎无关 | 直接撬动北极星指标 | 0.35 |
+| 用户价值 | 解决痛点的频率 × 强度 | 边缘场景 | 高频关键任务阻塞 | 0.25 |
+| 实现成本 | 研发+测试+运维+迁移+培训（反向计入） | 一周内 | 跨团队多季度 | 0.20 |
+| 风险敞口 | 合规/安全/稳定性/依赖不确定性（反向计入） | 隔离可控 | 触及账号/支付/数据 | 0.20 |
+
+`综合分 = (业务价值×0.35 + 用户价值×0.25) − (实现成本×0.20 + 风险敞口×0.20)`
+
+- 权重不是固定的：早期产品调高用户价值，规模化阶段调高业务价值与风险；权重一旦定了，**整季不随单个需求改**，否则打分失去公信力。
+- 分数相近（差值在 0.3 内）时，**以"减少关键链路风险/降低不确定性"优先**——先做能解锁后续决策的需求。
+- 打分是输入不是判决：评审用分数聚焦讨论分歧最大的维度，而不是机械按分排期。
+
+## 3. 价值/成本四象限（快速版，用于粗排与对齐）
+
+当需求多、时间紧时，用二维矩阵先对齐方向，再对争议项做四维细打分。
+
+| | 低成本 | 高成本 |
+|---|---|---|
+| **高价值** | 立即做（quick win） | 重点投入，需拆分里程碑 |
+| **低价值** | 顺手做/批量清 | 不做或砍掉（最危险象限：高成本低价值） |
+
+- 警惕"高成本低价值"象限——它最容易因为"已经投入了"而被沉没成本绑架。
+- "高价值高成本"必须拆成可独立交付、可独立验证的里程碑，避免一次性大爆炸。
+
+## 4. 满意度模型：区分"必备"与"惊喜"
+
+同样高分的需求，对用户满意度的作用并不线性，排期时要区分：
+
+- **必备型**：缺了就投诉、做到顶也只是"不扣分"（如登录稳定、支付不丢单）→ 必须满足基线，但不要过度打磨。
+- **期望型**：投入与满意度线性相关 → 主战场，按四维分排。
+- **惊喜型**：用户没预期，做到了显著加分 → 适合作为差异化赌注，但不能挤占必备型产能。
+
+## 5. 决策门禁（硬约束，不可绕过）
+
+- 涉及**账号、支付、权限、数据导出/删除**的功能，风险评分必须由**安全 + 运维双签**方可进开发。
+- 涉及**跨系统/跨团队**变更，必须附**回滚方案 + 向后兼容策略**，否则不予排期。
+- **没有可量化验收标准**的需求不进开发队列（"做个更好的搜索"不是需求，"搜索 P95 < 300ms 且 0 结果率 < 5%"才是）。
+- 每个排期需求必须绑定**至少 1 个业务指标 + 1 个质量指标**，并预设上线后的验证窗口与下线条件。
+
+## 6. 输出模板（每个排期需求必须填全）
+
+- 需求名称与一句话价值主张
+- 预期业务影响（绑定哪个指标、预期幅度、衡量口径）
+- 受益用户群体与触发场景频率
+- 四维打分 + 综合分（含权重快照）
+- 估算工作量与关键依赖
+- 风险敞口与缓解措施（高风险需双签记录）
+- 验收标准（可判定）+ 上线后验证窗口 + 回滚/下线条件
+- 发布策略（灰度比例、放量节奏）
+
+## 反模式
+
+- **拍脑袋优先级**：用职级、嗓门、最近一次会议决定排期，没有可复算的打分，事后无法追责。
+- **权重随需求漂移**：为了让某个需求排上去临时改权重，打分体系沦为表演。
+- **只算价值不算风险**：把账号/支付/权限类高风险需求当普通功能排，绕过双签，埋下资损与合规雷。
+- **沉没成本绑架**：因为"已经做了一半"就继续投入高成本低价值项，而不是及时止损。
+- **无验收标准入队**：需求描述模糊、没有可量化的成功定义，导致做完无法判断成败，也无法回滚。
+- **探索与确定性混排**：把高不确定性赌注和确定性需求放进同一个排序，要么赌注永远排不上、要么挤垮基本盘。
+- **必备型过度打磨**：在"做到顶也只是不扣分"的必备功能上投入惊喜型的产能。
+
+## 最低交付 checklist
+
+- [ ] 所有候选需求已分桶（合规止血 / 核心价值 / 体验优化 / 探索 / 债务），止血类不进打分直接排期。
+- [ ] 进队列需求均有四维打分 + 综合分，权重在本季度内固定且公开。
+- [ ] 高成本需求已拆为可独立交付、可独立验证的里程碑。
+- [ ] 账号/支付/权限/数据类需求已完成安全+运维双签并留痕。
+- [ ] 跨系统变更均附回滚方案与向后兼容策略。
+- [ ] 每个排期需求绑定 ≥1 业务指标 + ≥1 质量指标，并有可判定的验收标准。
+- [ ] 探索类需求有独立产能配额，未挤占确定性基本盘。
+- [ ] 排期结论与未采纳需求的理由均有记录，可向相关方解释。