名称: 分解与重构描述: 用于处理需要简化的复杂系统，识别瓶颈或关键故障点，重新设计架构或流程以提高性能，分解感觉压倒性的问题，分析依赖关系以理解连锁效应，用户提到“这太复杂了”、“瓶颈在哪里”、“我们如何重新设计这个”、“关键组件是什么”，或者当优化需要理解部件如何交互时。

分解与重构

什么是它？

分解-重构是一种两阶段分析技术：首先，将复杂系统分解为原子组件并理解它们的关系；其次，要么以更好的配置重新组合组件，要么识别驱动系统行为的关键元素。

快速示例：

系统： 慢的Web应用（3秒页面加载）

分解：

前端：1.2秒（JS包：0.8秒，CSS：0.2秒，HTML渲染：0.2秒）
网络：0.5秒（API调用：3个请求 × 150毫秒每个，并行）
后端：1.3秒（数据库查询：1.0秒，业务逻辑：0.2秒，序列化：0.1秒）

重构（瓶颈识别）： 关键路径：数据库查询（1.0秒）+ JS包（0.8秒）= 总3.0秒中的1.8秒优化目标：优化DB查询索引和代码分割JS包 → 预期1.5秒页面加载

工作流

复制此清单并跟踪您的进度：

分解与重构进度：
- [ ] 步骤1：定义系统和目标
- [ ] 步骤2：分解为组件和关系
- [ ] 步骤3：分析组件属性和交互
- [ ] 步骤4：重构以获取洞察或优化
- [ ] 步骤5：验证并交付推荐

步骤1：定义系统和目标

请用户描述系统（我们正在分析什么），当前问题或目标（需要改进、理解或重新设计什么），边界（范围内 vs 范围外），和成功标准（“更好”看起来像什么）。清晰的边界防止无休止的分解。见范围问题以澄清提示。

步骤2：分解为组件和关系

将系统分解为不能有意义地进一步细分的原子部分。识别关系（依赖关系、数据流、控制流、时间顺序）。根据系统类型选择分解策略。见分解策略和resources/template.md以获取结构化过程。

步骤3：分析组件属性和交互

对于每个组件，识别关键属性（成本、时间、复杂性、可靠性等）。映射交互（哪些组件依赖于哪些）。识别关键路径、瓶颈或脆弱点。对于复杂分析 → 见resources/methodology.md以获取依赖映射和关键路径技术。

步骤4：重构以获取洞察或优化

基于目标，要么：(a) 识别关键组件（瓶颈、单点故障、最高成本驱动），(b) 重新设计配置（重新排序、并行化、消除、组合组件），或 © 简化（移除不必要组件）。见重构模式以获取常见方法。

步骤5：验证并交付推荐

使用resources/evaluators/rubric_decomposition_reconstruction.json自评估（最低分数 ≥ 3.5）。提交decomposition-reconstruction.md，包含清晰的组件分解、分析发现（瓶颈、依赖关系）和可操作的推荐与预期影响。

范围问题

定义系统：

我们正在分析的系统是什么？（具体：“结账流程”而不是“网站”）
它从哪里开始和结束？（边界）
范围内 vs 范围外是什么？（防止无休止分解）

澄清目标：

我们正在解决什么问题？（性能慢、成本高、复杂性、不可靠性）
成功看起来像什么？（具体目标：“减少延迟到<500毫秒”，“削减成本30%”）
我们是优化、理解还是重新设计？

理解约束：

我们不能改变什么？（遗留系统、预算限制、监管要求）
时间范围是什么？（快速获胜 vs 长期重新设计）
利益相关者是谁？（工程、业务、客户）

分解策略

根据系统类型选择：

功能分解

当：业务流程、软件功能、工作流 方法： 按功能或任务分解 示例： 电子商务结账 → 浏览产品 | 加入购物车 | 输入运输 | 支付 | 确认

结构分解

当：架构、组织、物理系统 方法： 按组件或模块分解 示例： Web应用 → 前端（React） | API（Node.js） | 数据库（PostgreSQL） | 缓存（Redis）

数据流分解

当：管道、ETL过程、信息系统 方法： 按数据转换分解 示例： 分析管道 → 摄取原始事件 | 清理和验证 | 聚合指标 | 存储在仓库 | 可视化在仪表板

时间分解

当：具有顺序阶段、时间线、用户旅程的过程 方法： 按时间或序列分解 示例： 客户 onboarding → 第1天：注册 | 第2-7天：教程 | 第8-30天：第一次价值时刻 | 第31天+：保留

成本/资源分解

当：预算分析、资源分配、优化 方法： 按成本中心或资源类型分解 示例： AWS账单 → 计算（$5K） | 存储（$2K） | 数据传输（$1K） | 其他（$500）

深度指南： 当进一步分解不揭示有用洞察或可操作机会时停止。

组件关系类型

分解后，映射关系：

1. 依赖关系（A需要B）：

API服务依赖于数据库
前端依赖于API
关键用于：识别级联故障、理解变化影响

2. 数据流（A发送数据到B）：

用户输入 → 验证 → 数据库 → API响应
关键用于：追踪信息、找到转换瓶颈

3. 控制流（A触发B）：

按钮点击触发表单提交
支付成功触发订单履行
关键用于：理解执行路径、识别竞争条件

4. 时间顺序（A在B之前时间）：

认证在授权之前
编译在部署之前
关键用于：排序、找到并行化机会

5. 资源共享（A和B竞争C）：

多个服务共享数据库连接池
团队共享预算
关键用于：识别争用、资源约束

重构模式

模式1：瓶颈识别

目标： 找到限制系统吞吐量或速度的东西 方法： 测量组件属性（时间、成本、容量），识别关键路径或最高值 示例： DB查询占请求时间的80% → 首先优化DB查询

模式2：简化

目标： 通过移除不必要部分减少复杂性 方法： 质疑每个组件的必要性，消除冗余或低值部分 示例： 工作流有5个批准步骤，3个是冗余的 → 移除3个步骤

模式3：重新排序

目标： 通过改变序列提高效率 方法： 识别依赖关系，移动独立任务更早或并行 示例： 运行测试并行于构建而不是顺序 → 减少CI时间

模式4：并行化

目标： 通过同时做工作增加吞吐量 方法： 找到独立组件，同时执行 示例： 获取用户数据和产品数据并行而不是串行 → 减少延迟一半

模式5：替换

目标： 用更好的替代品替换弱组件 方法： 识别表现不佳组件，找到替换 示例： 替换同步API调用为异步消息队列 → 提高可靠性

模式6：合并

目标： 通过组合相似组件减少开销 方法： 找到冗余或重叠组件，合并它们 示例： 合并3个做类似工作的微服务为1 → 减少操作开销

模式7：模块化

目标： 通过分离关注点提高可维护性 方法： 识别紧密耦合组件，用清晰接口分离 示例： 提取认证逻辑从单体到单独服务 → 启用独立扩展

何时不使用此技能

跳过分解-重构如果：

系统已经简单（3-5个明显组件，无复杂交互）
问题不是关于系统结构（纯粹执行问题，不是设计问题）
你需要创造力/构思（不是分析） - 使用头脑风暴代替
系统理解不佳（需要发现/研究首先，不是分解）
变化不可能（如果无法对发现采取行动，分析无意义）

使用代替：

简单系统 → 直接分析或观察
执行问题 → 项目管理、过程改进
需要想法 → 头脑风暴、设计思维
未知系统 → 发现访谈、研究
不可改变 → 变通规划、约束优化

按领域常见模式

软件架构：

分解：模块、服务、层、数据存储
重构用于：微服务迁移、性能优化、减少耦合

业务流程：

分解：步骤、决策点、交接、批准
重构用于：周期时间减少、自动化机会、移除浪费

问题解决：

分解：子问题、依赖关系、未知数、约束
重构用于：任务排序、识别阻塞器、找到可并行工作

成本优化：

分解：成本中心、行项目、资源使用
重构用于：识别最大成本驱动、找到快速获胜

用户体验：

分解：用户旅程阶段、交互、痛点
重构用于：简化流、移除摩擦、提高转换

系统可靠性：

分解：组件、故障模式、依赖关系
重构用于：识别单点故障、提高韧性

快速参考

过程：

定义系统和目标 → 设置边界
分解 → 分解为组件和关系
分析 → 测量属性、映射交互
重构 → 优化、简化或重新设计
验证 → 对照标准检查、交付推荐

分解策略：

功能（按任务）、结构（按组件）、数据流、时间、成本/资源

重构模式：

瓶颈ID、简化、重新排序、并行化、替换、合并、模块化

资源：

resources/template.md - 结构化分解过程与模板
resources/methodology.md - 高级技术（依赖图、关键路径分析、层次分解）
resources/evaluators/rubric_decomposition_reconstruction.json - 质量检查单

可交付物： decomposition-reconstruction.md 包含组件分解、分析和推荐