decomposition-reconstruction

分解与重构

工作流

复制此清单并跟踪进度：

Decomposition & Reconstruction Progress:
- [ ] Step 1: Define the system and goal
- [ ] Step 2: Decompose into components and relationships
- [ ] Step 3: Analyze component properties and interactions
- [ ] Step 4: Reconstruct for insight or optimization
- [ ] Step 5: Validate and deliver recommendations

步骤 1：定义系统和目标

请用户描述系统（我们正在分析什么）、当前问题或目标（需要改进、理解或重新设计什么）、边界（范围内和范围外的内容），以及成功标准（怎样才算“更好”）。明确边界可避免无休止的分解。请参阅范围界定问题，获取澄清提示。

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

将系统拆分为无法再进行有意义细分的原子部分。确定各部分之间的关系（依赖关系、数据流、控制流、时间顺序）。根据系统类型选择分解策略。结构化流程请参阅分解策略和resources/template.md。

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

针对每个组件，确定关键属性（成本、时间、复杂度、可靠性等）。梳理交互关系（哪些组件依赖哪些组件）。确定关键路径、瓶颈或脆弱点。如需进行复杂分析 → 请参阅 resources/methodology.md，了解依赖关系映射和关键路径技巧。

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

根据目标，选择以下做法之一：(a) 找出关键组件（瓶颈、单点故障、成本最高的驱动因素）；(b) 重新设计配置（调整顺序、并行化、移除或合并组件）；或 (c) 简化系统（移除不必要的组件）。常见方法请参阅重构模式。

步骤 5：验证并交付建议

使用 resources/evaluators/rubric_decomposition_reconstruction.json 进行自我评估（最低分数 ≥ 3.5）。提交 decomposition-reconstruction.md，清晰列出组件拆分结果、分析发现（瓶颈、依赖关系），以及附有预期影响的可执行建议。

范围界定问题

定义系统：

• 我们正在分析什么系统？（请具体说明：“结账流程”，而不是“网站”）
• 系统从哪里开始，到哪里结束？（边界）
• 哪些内容在范围内，哪些不在范围内？（避免无休止的分解）

明确目标：

• 我们要解决什么问题？（性能缓慢、成本高、复杂度高、不可靠）
• 怎样才算成功？（具体目标：“将延迟降低至 <500ms”、“削减 30% 的成本”）
• 我们要进行优化、理解还是重新设计？

了解约束：

• 有哪些内容不能更改？（遗留系统、预算限制、监管要求）
• 时间范围是什么？（快速见效还是长期重新设计）
• 利益相关者有哪些？（工程、业务、客户）

分解策略

根据系统类型进行选择：

功能分解

适用场景： 业务流程、软件功能、工作流 方法： 按功能或任务拆分 示例： 电商结账 → 浏览商品 | 加入购物车 | 输入配送信息 | 付款 | 确认

结构分解

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

数据流分解

适用场景： 管道、ETL 流程、信息系统 方法： 按数据转换拆分 示例： 分析管道 → 摄取原始事件 | 清理并验证 | 汇总指标 | 存储到数据仓库 | 在仪表板中可视化

时间分解

适用场景： 包含顺序阶段、时间线、用户旅程的流程 方法： 按时间或顺序拆分 示例： 客户引导 → 第 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：识别瓶颈

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

模式 2：简化

目标： 移除不必要的部分，降低复杂度 方法： 逐一审视各个组件是否必要，移除冗余或价值较低的部分 示例： 工作流有 5 个审批步骤，其中 3 个是冗余的 → 移除这 3 个步骤

模式 3：重新排序

目标： 通过调整顺序提高效率 方法： 识别依赖关系，将独立任务提前或并行执行 示例： 测试与构建并行运行，而非依次运行 → 缩短 CI 时间

模式 4：并行化

目标： 通过并发处理提高吞吐量 方法： 找出独立组件，同时执行 示例： 并行获取用户数据和产品数据，而非依次获取 → 延迟减半

模式 5：替换

目标： 用更好的替代方案取代较弱的组件 方法： 找出表现不佳的组件，寻找替代方案 示例： 将同步 API 调用替换为异步消息队列 → 提高可靠性

模式 6：整合

目标： 通过合并相似组件降低开销 方法： 找出冗余或重叠的组件并将其合并 示例： 将 3 个执行相似工作的微服务整合为 1 个 → 降低运维开销

模式 7：模块化

目标： 通过分离关注点提高可维护性 方法： 找出紧密耦合的组件，通过明确的接口将其分离 示例： 将身份验证逻辑从单体应用中提取为独立服务 → 支持独立扩缩

不适合使用此技能的场景

以下情况应跳过分解与重建：

• 系统已经很简单（有 3-5 个显而易见的组件，且没有复杂交互）
• 问题与系统结构无关（纯粹是执行问题，而非设计问题）
• 需要创意或构思（而非分析）——改用头脑风暴
• 对系统了解不足（需要先探索或研究，而非分解）
• 无法进行变更（如果无法根据分析结果采取行动，分析就没有意义）

可改用：

• 简单系统 → 直接分析或观察
• 执行问题 → 项目管理、流程改进
• 需要创意 → 头脑风暴、设计思维
• 未知系统 → 探索性访谈、研究
• 无法变更 → 规划变通方案、约束优化

各领域的常见模式

软件架构：

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

业务流程：

• 分解：步骤、决策点、交接、审批
• 重构用于：缩短周期时间、发现自动化机会、消除浪费

问题解决：

• 分解：子问题、依赖项、未知因素、约束
• 重构用于：安排任务顺序、识别阻碍因素、找出可并行处理的工作

成本优化：

• 分解：成本中心、细目、资源使用情况
• 重构用于：找出最大的成本驱动因素、发现快速见效的改进机会

用户体验：

• 分解：用户旅程阶段、交互、痛点
• 重构用于：简化流程、消除阻力、提高转化率

系统可靠性：

• 分解：组件、故障模式、依赖项
• 重构用于：识别单点故障、增强韧性

快速参考

流程：

1. 定义系统和目标 → 设定边界
2. 分解 → 拆分为组件及其关系
3. 分析 → 衡量属性、梳理交互
4. 重构 → 优化、简化或重新设计
5. 验证 → 根据评估标准检查，提供建议

分解策略：

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

重构模式：

• 识别瓶颈、简化、重新排序、并行化、替换、整合、模块化

资源：

• resources/template.md - 包含模板的结构化分解流程
• resources/methodology.md - 高级技术（依赖关系图、关键路径分析、分层分解）
• resources/evaluators/rubric_decomposition_reconstruction.json - 质量检查清单

交付物： decomposition-reconstruction.md，包含组件拆解、分析和建议