@umacloud/knowledge 1.0.1

package/product/03-checklists/feature-launch-checklist.md

@@ -0,0 +1,275 @@
+---
+id: feature-launch-checklist
+title: Feature Launch Checklist
+domain: product
+category: 03-checklists
+difficulty: intermediate
+tags: [agent, alerting, checklist, complete, confirmation, feature, launch, passed]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# Feature Launch Checklist
+
+## 概述
+
+功能上线是产品交付中风险最集中的环节。本检查清单覆盖从需求确认到全量发布的完整链路，分为七个阶段：需求确认、设计评审、开发完成、测试通过、灰度发布、监控告警和文档更新。每条检查项标注责任人角色和优先级（P0 必须 / P1 应该 / P2 建议），确保关键环节不被遗漏。
+
+---
+
+## 一、需求确认（Requirement Confirmation）
+
+### 需求文档
+
+- [ ] **[P0][PM]** PRD 文档已发布并经相关方评审
+- [ ] **[P0][PM]** 用户故事（User Story）有明确的验收标准（Acceptance Criteria）
+- [ ] **[P0][PM]** 核心功能的边界情况已列举（空数据、超长输入、并发操作等）
+- [ ] **[P1][PM]** 功能范围（Scope）明确，有"不做"清单
+- [ ] **[P1][PM]** 依赖项已识别（后端 API、第三方服务、数据迁移等）
+- [ ] **[P2][PM]** 竞品分析已完成，差异化定位清晰
+
+### 优先级与排期
+
+- [ ] **[P0][PM]** 功能优先级确认（P0/P1/P2），与团队达成共识
+- [ ] **[P0][TL]** 技术方案已评审，工作量估算完成
+- [ ] **[P1][PM]** 上线日期确认，倒推里程碑节点
+- [ ] **[P1][PM]** 与运营/市场同步上线计划
+- [ ] **[P2][PM]** 风险评估完成，有应急预案
+
+### 合规与安全
+
+- [ ] **[P0][Security]** 涉及用户数据的功能通过安全评审
+- [ ] **[P0][Legal]** 涉及隐私协议变更的内容法务确认
+- [ ] **[P1][PM]** 合规要求梳理（GDPR / 等保 / 行业规范）
+- [ ] **[P2][PM]** 数据埋点方案确认，不采集无关个人信息
+
+---
+
+## 二、设计评审（Design Review）
+
+### 视觉设计
+
+- [ ] **[P0][Design]** 设计稿覆盖所有页面和关键状态
+- [ ] **[P0][Design]** 组件使用设计系统标准组件，无自造组件
+- [ ] **[P0][Design]** 颜色/字体/间距引用 Design Token
+- [ ] **[P1][Design]** 响应式适配：Mobile + Desktop 两套设计稿
+- [ ] **[P1][Design]** 空状态、错误状态、加载状态设计完成
+- [ ] **[P2][Design]** 动效交互标注（时长/缓动/触发条件）
+
+### 交互设计
+
+- [ ] **[P0][Design]** 核心用户流程已绘制并走查
+- [ ] **[P0][Design]** 所有交互元素标注状态（hover/focus/disabled）
+- [ ] **[P1][Design]** 边界情况交互定义（网络异常、超时、重复操作）
+- [ ] **[P1][Design]** 无障碍设计考量（对比度、触控区域、键盘导航）
+- [ ] **[P2][Design]** 用户引导/Onboarding 方案
+
+### 设计交付
+
+- [ ] **[P0][Design]** 设计稿已标注并分享给开发团队
+- [ ] **[P0][Design]** Design Token 已导出并同步
+- [ ] **[P1][Design]** 组件映射表已建立（Figma 组件 <-> 前端组件）
+- [ ] **[P1][Design]** 设计交付会议已完成
+
+---
+
+## 三、开发完成（Development Complete）
+
+### 代码质量
+
+- [ ] **[P0][Dev]** 代码通过 Lint 检查（ESLint / Ruff / 团队规则）
+- [ ] **[P0][Dev]** 代码通过类型检查（TypeScript / mypy）
+- [ ] **[P0][Dev]** 无硬编码敏感信息（密钥、密码、Token）
+- [ ] **[P0][Dev]** 代码评审（Code Review）已完成且通过
+- [ ] **[P1][Dev]** 函数/方法有合理的注释和文档字符串
+- [ ] **[P1][Dev]** 复杂逻辑有内联注释说明
+- [ ] **[P2][Dev]** 技术债务已记录到 Backlog
+
+### 功能实现
+
+- [ ] **[P0][Dev]** 所有 Acceptance Criteria 实现完毕
+- [ ] **[P0][Dev]** API 契约与前后端约定一致
+- [ ] **[P0][Dev]** 数据库变更（Migration）已准备且可回滚
+- [ ] **[P1][Dev]** 功能开关（Feature Flag）已配置，支持灰度
+- [ ] **[P1][Dev]** 国际化（i18n）文案已提取
+- [ ] **[P2][Dev]** 性能优化已完成（懒加载/缓存/查询优化）
+
+### 前端实现
+
+- [ ] **[P0][FE]** 设计走查第一轮完成（布局/颜色/字体）
+- [ ] **[P0][FE]** 响应式在 Mobile / Desktop 上验证通过
+- [ ] **[P0][FE]** 交互状态完整（loading/empty/error/success）
+- [ ] **[P1][FE]** 浏览器兼容性测试（Chrome/Firefox/Safari/Edge）
+- [ ] **[P1][FE]** 首屏加载时间 < 3 秒（4G 网络）
+- [ ] **[P2][FE]** Lighthouse Performance Score >= 80
+
+### 后端实现
+
+- [ ] **[P0][BE]** API 响应时间满足 SLA（P95 < 500ms）
+- [ ] **[P0][BE]** 接口幂等性处理（防重复提交）
+- [ ] **[P0][BE]** 输入验证和防注入处理
+- [ ] **[P1][BE]** 限流策略配置（Rate Limiting）
+- [ ] **[P1][BE]** 日志格式规范，包含请求追踪 ID
+- [ ] **[P2][BE]** 慢查询优化（SQL Explain Plan 审查）
+
+---
+
+## 四、测试通过（Testing Passed）
+
+### 单元测试
+
+- [ ] **[P0][Dev]** 核心业务逻辑单元测试覆盖率 >= 80%
+- [ ] **[P0][Dev]** 所有单元测试通过
+- [ ] **[P1][Dev]** 边界情况有测试用例
+- [ ] **[P2][Dev]** 新增代码增量覆盖率 >= 90%
+
+### 集成测试
+
+- [ ] **[P0][QA]** 核心用户流程端到端测试通过
+- [ ] **[P0][QA]** API 接口测试通过（Postman / 自动化）
+- [ ] **[P1][QA]** 前后端联调测试通过
+- [ ] **[P1][QA]** 第三方依赖集成测试通过
+
+### 功能测试
+
+- [ ] **[P0][QA]** 所有 Acceptance Criteria 验证通过
+- [ ] **[P0][QA]** 边界情况测试通过（空值/最大值/特殊字符）
+- [ ] **[P0][QA]** 权限控制验证（不同角色访问控制）
+- [ ] **[P1][QA]** 多浏览器/多设备兼容性测试
+- [ ] **[P1][QA]** 数据迁移/升级路径测试
+- [ ] **[P2][QA]** 探索性测试完成
+
+### 非功能测试
+
+- [ ] **[P0][QA]** 安全测试：XSS / CSRF / SQL 注入扫描通过
+- [ ] **[P1][QA]** 性能测试：并发 100 用户响应时间满足 SLA
+- [ ] **[P1][QA]** 压力测试：识别系统瓶颈和崩溃阈值
+- [ ] **[P2][QA]** 无障碍测试：axe / Lighthouse Accessibility >= 90
+
+### 回归测试
+
+- [ ] **[P0][QA]** 自动化回归测试套件全部通过
+- [ ] **[P0][QA]** 关联功能手动回归测试通过
+- [ ] **[P1][QA]** 无新增 P0/P1 Bug
+
+---
+
+## 五、灰度发布（Gradual Rollout）
+
+### 发布准备
+
+- [ ] **[P0][DevOps]** 部署脚本/Pipeline 已测试
+- [ ] **[P0][DevOps]** 回滚方案已准备并验证
+- [ ] **[P0][Dev]** 数据库 Migration 已在 Staging 验证
+- [ ] **[P1][DevOps]** 发布窗口确认（避开高峰期）
+- [ ] **[P1][PM]** 发布通知已发送给相关团队
+
+### 灰度策略
+
+- [ ] **[P0][PM]** 灰度策略确定（按用户比例/按地区/按租户）
+- [ ] **[P0][Dev]** Feature Flag 已配置，支持动态开关
+- [ ] **[P0][PM]** 灰度范围：1% -> 5% -> 20% -> 50% -> 100%
+- [ ] **[P1][PM]** 每个灰度阶段的观察期和通过标准定义
+- [ ] **[P1][QA]** 灰度期间的手动抽查计划
+
+### 灰度验证
+
+- [ ] **[P0][Dev]** 灰度 1% 上线后核心指标正常（错误率/延迟/CPU）
+- [ ] **[P0][QA]** 灰度用户功能验证通过
+- [ ] **[P0][PM]** 无用户投诉或负面反馈
+- [ ] **[P1][Dev]** 日志中无异常报错
+- [ ] **[P1][PM]** 业务指标（转化率/使用率）符合预期
+
+---
+
+## 六、监控告警（Monitoring & Alerting）
+
+### 基础监控
+
+- [ ] **[P0][DevOps]** 服务健康检查（Health Check）正常
+- [ ] **[P0][DevOps]** CPU / 内存 / 磁盘使用率告警已配置
+- [ ] **[P0][DevOps]** 服务可用性监控（Uptime）已启用
+- [ ] **[P1][DevOps]** 容器/Pod 自动恢复策略已配置
+- [ ] **[P1][DevOps]** 日志聚合（ELK / CloudWatch）已接入
+
+### 业务监控
+
+- [ ] **[P0][Dev]** 关键接口错误率告警（阈值：> 1%）
+- [ ] **[P0][Dev]** 接口延迟告警（P95 > 1s）
+- [ ] **[P1][Dev]** 业务指标看板已创建（DAU/转化率/使用率）
+- [ ] **[P1][Dev]** 数据埋点验证通过
+- [ ] **[P2][PM]** 用户行为分析看板配置
+
+### 告警响应
+
+- [ ] **[P0][DevOps]** 告警通知渠道配置（Slack / 钉钉 / PagerDuty）
+- [ ] **[P0][TL]** 值班表和升级路径明确
+- [ ] **[P1][TL]** 故障响应 SOP 文档更新
+- [ ] **[P1][DevOps]** 自动回滚触发条件定义
+
+---
+
+## 七、文档更新（Documentation）
+
+### 用户文档
+
+- [ ] **[P0][PM]** 新功能帮助文档/教程已更新
+- [ ] **[P1][PM]** 更新日志（Changelog）已编写
+- [ ] **[P1][PM]** 应用内引导提示已配置
+- [ ] **[P2][PM]** FAQ 更新
+
+### 技术文档
+
+- [ ] **[P0][Dev]** API 文档（Swagger / OpenAPI）已更新
+- [ ] **[P0][Dev]** 数据库变更文档已记录
+- [ ] **[P1][Dev]** 架构决策记录（ADR）更新（如有架构变更）
+- [ ] **[P1][DevOps]** 运维手册（Runbook）更新
+- [ ] **[P2][Dev]** 系统架构图更新
+
+### 团队沟通
+
+- [ ] **[P0][PM]** 功能上线公告发送（内部 + 外部）
+- [ ] **[P1][PM]** 客服/销售团队功能培训完成
+- [ ] **[P1][PM]** 上线复盘会议安排
+- [ ] **[P2][PM]** 用户反馈收集渠道准备
+
+---
+
+## 上线后跟踪（Post-Launch）
+
+### 第一天（D+1）
+
+- [ ] 核心指标无异常（错误率 < 0.1%，延迟 P95 < 500ms）
+- [ ] 无 P0 用户反馈
+- [ ] 灰度比例按计划推进
+
+### 第一周（D+7）
+
+- [ ] 灰度达到 50% 或全量
+- [ ] 业务指标达到预期基线
+- [ ] 已知问题清单记录并排期
+- [ ] 上线复盘会议完成
+
+### 第一月（D+30）
+
+- [ ] 全量发布完成
+- [ ] 用户反馈收集并分析
+- [ ] 功能使用数据分析（是否达到目标）
+- [ ] 技术债务清理完成
+- [ ] 下一迭代优化方向确定
+
+---
+
+## Agent Checklist
+
+以下为 AI Agent 在辅助功能上线时的检查要点：
+
+- [ ] 确认 PRD 和 Acceptance Criteria 已明确
+- [ ] 确认设计稿覆盖所有状态并通过评审
+- [ ] 确认代码通过 Lint、类型检查和 Code Review
+- [ ] 确认核心逻辑单元测试覆盖率 >= 80%
+- [ ] 确认端到端测试和安全扫描通过
+- [ ] 确认 Feature Flag 已配置，支持灰度和回滚
+- [ ] 确认监控告警已配置（错误率/延迟/资源使用）
+- [ ] 确认回滚方案已准备并验证
+- [ ] 确认用户文档和 API 文档已更新
+- [ ] 确认上线后跟踪计划已安排（D+1/D+7/D+30）

package/product/04-antipatterns/product-antipatterns.md

@@ -0,0 +1,355 @@
+---
+id: product-antipatterns
+title: Product Antipatterns
+domain: product
+category: 04-antipatterns
+difficulty: intermediate
+tags: [antipatterns, blindness, creep, factory, opinion, paid, paralysis, product]
+quality_score: 70
+last_updated: 2026-06-15
+---
+# Product Antipatterns
+
+## 概述
+
+产品反模式是在产品管理过程中反复出现的、表面上解决问题但长远来看会损害产品质量和团队效率的做法。这些反模式在初创公司和成熟企业中都广泛存在，识别并规避它们能帮助产品团队做出更好的决策。本文档覆盖六种核心反模式：功能堆砌、HiPPO 决策、过度设计、忽略数据、无优先级和范围蔓延。
+
+---
+
+## 一、功能堆砌（Feature Factory）
+
+### 表现
+
+- 产品路线图是一个永远增长的功能列表
+- 团队按"交付了多少功能"而非"创造了多少价值"来衡量成功
+- 每个客户请求都变成一个 Feature Request 进入 Backlog
+- 功能只做 V1 就进入下一个，从不迭代优化
+
+### 为什么看似合理
+
+- 功能多 = 产品强大 = 竞争力强
+- 团队看起来很忙很有产出
+- 满足了不同客户的不同需求
+
+### 实际危害
+
+- **产品臃肿**：80% 的功能只有 20% 的用户使用，但 100% 的用户承受复杂性
+- **技术债务**：每个功能都增加维护成本，没有时间做质量改进
+- **用户体验下降**：功能越多导航越复杂，新用户上手成本越高
+- **团队倦怠**：永远在赶工交付，没有成就感
+
+### 修正方案
+
+- **Outcome 导向**：用"用户行为变化"和"业务指标变化"衡量成功
+- **功能审计**：每季度分析功能使用率，低于 5% 使用率的考虑下线
+- **One-in-one-out 规则**：每增加一个功能，必须简化或下线一个
+- **迭代深度**：每个功能至少 3 个迭代周期才算完成
+- **Jobs-to-be-Done**：围绕用户任务而非功能需求来规划
+
+### 检测信号
+
+```
+- 过去 6 个月新增 > 20 个功能但未下线任何功能
+- 功能完成后无数据追踪（不知道有没有人用）
+- 团队讨论的主题永远是"下个功能做什么"而非"上个功能效果如何"
+- Backlog 中有 > 200 个未排期的 Feature Request
+```
+
+---
+
+## 二、HiPPO 决策（Highest Paid Person's Opinion）
+
+### 表现
+
+- 产品方向由最高级别的人拍板，不经数据验证
+- "CEO/VP 说要做这个功能"是最常见的需求来源
+- 与领导意见相左的数据被解释为"数据不准"或被忽略
+- 用户调研结论与领导直觉冲突时，以领导为准
+
+### 为什么看似合理
+
+- 高层有更丰富的行业经验和全局视角
+- 决策速度快，不需要冗长的数据收集过程
+- 责任明确，出了问题有人负责
+
+### 实际危害
+
+- **偏见放大**：个人经验和偏好被当作用户需求
+- **团队去技能化**：PM 和设计师沦为执行者而非决策者
+- **错失市场**：领导不是目标用户，直觉可能与市场脱节
+- **创新窒息**：团队不敢提出不同意见
+- **A/B 测试无意义**：结果不影响决策
+
+### 修正方案
+
+- **假设-实验-学习循环**：任何产品决策先表述为可证伪的假设
+- **数据驱动决策框架**：RICE / ICE / Weighted Scoring
+- **用户证据优先**：用户调研、数据分析、A/B 测试结果优先于个人意见
+- **决策日志**：记录每个重要决策的依据，事后复盘
+- **匿名投票**：避免权威效应，让团队先独立形成意见
+
+### 检测信号
+
+```
+- 需求文档中"领导/CEO/VP 要求"出现频率 > 30%
+- A/B 测试结果被推翻的频率 > 50%
+- 产品经理的主要工作是"理解领导意图"而非"理解用户需求"
+- 用户调研预算和频率逐年下降
+```
+
+---
+
+## 三、过度设计（Over-Engineering）
+
+### 表现
+
+- V1 就要支持百万级并发（实际用户 100 人）
+- 微服务拆分过细，10 个用户配 15 个服务
+- 花 3 周搭建"可扩展架构"，实际功能 1 周就能做完
+- 每个需求都要先做"技术调研"和"架构设计"
+
+### 为什么看似合理
+
+- 提前考虑扩展性，避免将来重构
+- 使用最新最好的技术栈
+- 工程师专业能力的体现
+
+### 实际危害
+
+- **上市时间延迟**：用 3 个月做本可以 3 周完成的功能
+- **复杂度爆炸**：系统复杂度与用户规模严重不匹配
+- **运维负担**：更多的服务 = 更多的监控/部署/调试成本
+- **过早优化**：优化了错误的瓶颈，真正的瓶颈在业务逻辑不在技术
+- **资源浪费**：为 1% 的可能性投入 50% 的资源
+
+### 修正方案
+
+- **YAGNI 原则**：You Aren't Gonna Need It，不要为假设的未来需求编码
+- **三次规则**：同样的需求出现三次才抽象
+- **MVP 思维**：用最简单的技术方案验证业务假设
+- **技术预算**：每个功能有时间上限，超过就砍技术方案复杂度
+- **单体优先**：先单体，有明确理由再拆分微服务
+
+### 检测信号
+
+```
+- 技术架构复杂度远超业务复杂度
+- "搭建基础设施"占迭代时间 > 40%
+- 系统中存在从未被调用的 API 和从未被实例化的类
+- 团队花更多时间讨论"如何做"而非"做什么"
+```
+
+---
+
+## 四、忽略数据（Data Blindness）
+
+### 表现
+
+- 产品决策基于"我觉得"而非数据分析
+- 功能上线后没有数据追踪和效果评估
+- 有数据平台但没人看，或只看虚荣指标
+- 用户反馈只有定性（用户说了什么）没有定量（有多少人这样说）
+
+### 为什么看似合理
+
+- 数据收集和分析需要时间，影响交付速度
+- "数据会骗人"，要相信直觉和经验
+- 初期用户少，数据不具统计意义
+- 数据工具和平台投入成本高
+
+### 实际危害
+
+- **盲目迭代**：不知道功能效果如何，只能猜测
+- **资源错配**：把资源投入到用户不关心的功能上
+- **无法复盘**：成功了不知道为什么成功，失败了不知道为什么失败
+- **缺乏说服力**：向管理层/投资人汇报只能说故事不能说数据
+
+### 修正方案
+
+- **North Star Metric**：确定一个核心指标，所有决策围绕它
+- **埋点即需求**：每个功能的 PRD 必须包含数据埋点方案
+- **上线后评审**：功能上线 14 天后必须有数据评审会
+- **指标层级**：战略指标 -> 产品指标 -> 功能指标 -> 行为指标
+- **最小数据基础设施**：至少有事件追踪 + 漏斗分析 + 留存分析
+
+### 指标框架
+
+```
+战略指标：MRR / ARR / 市场份额
+    ↓
+产品指标：DAU / MAU / 留存率 / NPS
+    ↓
+功能指标：功能使用率 / 任务完成率 / 转化率
+    ↓
+行为指标：点击率 / 停留时间 / 跳出率
+```
+
+### 检测信号
+
+```
+- 上线 > 3 个月的功能没有使用数据
+- 团队无法回答"最受欢迎的功能是哪个"
+- 产品决策会议上数据分析师/数据团队不在场
+- A/B 测试次数 < 每月 1 次
+```
+
+---
+
+## 五、无优先级（Priority Paralysis）
+
+### 表现
+
+- 所有需求都是 P0，没有真正的优先级排序
+- 团队同时推进 5 个以上"最高优先级"项目
+- 每周都有新的"紧急需求"插入，现有计划被打断
+- Backlog 中 > 500 个需求，但没有排序逻辑
+
+### 为什么看似合理
+
+- 所有需求都有合理的理由，很难说谁不重要
+- 多线程并行可以"同时推进多件事"
+- 灵活响应变化，不被计划束缚
+
+### 实际危害
+
+- **什么都做 = 什么都做不好**：资源分散导致每个功能都做不到位
+- **交付延迟**：上下文切换成本高，每个任务实际完成时间是预估的 2-3 倍
+- **团队疲惫**：永远在赶进度，没有完成感
+- **质量下降**：赶工导致技术债务和 Bug 积累
+- **战略模糊**：团队不知道什么最重要，无法做长期投入
+
+### 修正方案
+
+- **RICE 打分**：Reach x Impact x Confidence / Effort
+- **MoSCoW 分类**：Must / Should / Could / Won't
+- **2x2 矩阵**：影响力 x 实施难度，优先做高影响低难度
+- **WIP 限制**：同时进行的项目不超过 3 个
+- **季度聚焦**：每季度只有 1-2 个战略主题
+- **说"不"的勇气**：有明确的拒绝标准和流程
+
+### 优先级决策框架
+
+| 维度 | 权重 | 评分标准 |
+|------|------|---------|
+| 用户影响 | 30% | 影响多少用户 x 影响程度 |
+| 业务价值 | 30% | 对收入/留存/增长的贡献 |
+| 战略契合 | 20% | 与长期愿景的一致性 |
+| 实施成本 | 20% | 开发时间 + 维护成本 |
+
+### 检测信号
+
+```
+- Backlog 中 > 50% 的需求标记为 P0
+- 每个迭代的计划完成率 < 60%
+- 团队成员同时参与 > 3 个项目
+- 每周有 > 2 次"紧急需求"插入
+```
+
+---
+
+## 六、范围蔓延（Scope Creep）
+
+### 表现
+
+- 需求在开发过程中不断扩大，"顺便再加一个小功能"
+- 上线日期一推再推，但范围也一扩再扩
+- "先做完再说"，没有明确的 Done 定义
+- 每次评审都有新想法被加入当前迭代
+
+### 为什么看似合理
+
+- "既然都做了，再加一点也不费多少事"
+- 追求完美，希望一次做到最好
+- 竞品有这个功能，我们也应该有
+- 用户反馈说需要这个
+
+### 实际危害
+
+- **永远无法上线**：范围不断扩大，Done 遥遥无期
+- **预算超支**：实际工作量远超估算
+- **质量下降**：赶工完成膨胀的范围，牺牲测试和优化
+- **团队信任崩塌**：反复延期导致利益相关方不再信任团队
+- **机会成本**：被困在一个项目里，无法启动新项目
+
+### 修正方案
+
+- **明确的 Done 定义**：在开始前就确定交付标准和范围边界
+- **变更控制流程**：新增需求必须走变更评审，评估影响
+- **版本化交付**：V1 先交付核心功能，后续迭代再增强
+- **时间盒**：固定时间，灵活范围（而非固定范围，灵活时间）
+- **增量思维**：每两周交付一个可用的增量
+- **需求冻结点**：开发启动后设置需求冻结日期
+
+### 范围管理矩阵
+
+| 新增需求 | 在当前版本范围内 | 处理方式 |
+|---------|:---:|---------|
+| 核心功能缺失 | 是 | 立即加入，调整排期 |
+| 重要但非核心 | 否 | 记入 V2 Backlog |
+| 锦上添花 | 否 | 记入 Backlog 待排期 |
+| 竞品跟风 | 否 | 需数据验证后决策 |
+
+### 检测信号
+
+```
+- 项目实际工时超过估算 > 50%
+- 上线日期已延期 > 2 次
+- PRD 在开发阶段仍在频繁修改
+- 需求评审会上总是"再加一个小需求"
+```
+
+---
+
+## 反模式关联矩阵
+
+反模式之间常常相互关联和加剧：
+
+```
+功能堆砌 <---> 无优先级
+    ↑               ↑
+    |               |
+HiPPO 决策 <---> 范围蔓延
+    ↑               ↑
+    |               |
+忽略数据 <---> 过度设计
+```
+
+- HiPPO 决策加剧功能堆砌（领导的每个想法都变成需求）
+- 忽略数据导致无优先级（没有数据就无法排序）
+- 无优先级助长范围蔓延（什么都想做就什么都加）
+- 过度设计加剧范围蔓延（技术方案越做越大）
+
+---
+
+## 组织级防御机制
+
+### 流程层面
+
+1. **需求准入标准**：每个需求必须有用户场景、成功指标、优先级评分
+2. **迭代回顾**：每两周回顾交付效果和过程问题
+3. **季度路线图评审**：每季度基于数据重新评估路线图
+4. **技术债务预算**：每个迭代预留 20% 时间处理技术债务
+
+### 文化层面
+
+1. **鼓励说"不"**：PM 拒绝不合理需求不会被惩罚
+2. **数据文化**：决策前先看数据已成为习惯
+3. **用户至上**：团队定期与真实用户交流
+4. **小步快跑**：推崇 MVP 和快速迭代而非大而全
+
+---
+
+## Agent Checklist
+
+以下为 AI Agent 在辅助产品决策时用于检测反模式的要点：
+
+- [ ] 检查需求是否有明确的用户场景和成功指标（防功能堆砌）
+- [ ] 确认决策依据是数据/用户调研而非仅领导意见（防 HiPPO）
+- [ ] 评估技术方案复杂度是否与业务需求匹配（防过度设计）
+- [ ] 确认功能有数据埋点方案和上线后评估计划（防忽略数据）
+- [ ] 验证需求有优先级评分且 WIP <= 3（防无优先级）
+- [ ] 确认范围有明确边界和 Done 定义（防范围蔓延）
+- [ ] 检查反模式关联：是否多个反模式同时出现
+- [ ] 提醒团队遵循 YAGNI 和 MVP 原则
+- [ ] 确认迭代预留 20% 时间处理技术债务
+- [ ] 建议使用 RICE/MoSCoW 框架进行优先级排序