# morphling_sop

## 定义
Morphling 是一种项目级能力吸收/替代模式：给定任意目标项目，先抽取其目标与测例，再按组件选择调用、重写或少量复刻禁区规避，最终让自身或新产物在同一测例上达到或超过目标。

## 核心三元组
1. **目标（Target）**：它解决什么问题、面向谁、核心价值是什么；目标可以是完整项目，也可以是巨型项目中的可交付子系统。
2. **测例（Tests）**：它声称能通过的 benchmark、demo、CI、榜单、评测站、用户任务清单、性能/质量指标；没有测例先构造最小客观测例。
3. **行为（Actions）**：对每个组件分别决定：调用、重写、舍弃；避免“复刻/抄袭”作为默认行为。

## 输出形态
- **调用型 morphling**：把目标能力纳入自身工具链，产物是“更强的我”。
- **重写型 morphling**：理解核心后从零实现更好版本，产物是可独立替代原项目的新 repo/工具/产品。
- **混合型 morphling**：同一项目可分组件处理：底层复杂依赖调用，差异化核心重写，冗余模块舍弃。

## 流程
1. **锁定目标**：记录 URL/repo/产品名；不要先评价值不值得，先看它实际解决的问题。
2. **目标拆解**：识别类型：skill/教程、库、CLI、桌面/网页产品、基础设施、巨型生态、纯概念项目。
3. **测例提取**：优先找官方 tests、CI、benchmark、论文/README 指标、demo 脚本、评测网站、issue 中的真实失败案例。
4. **测例补全**：若目标没有公开测例，构造最小可验证任务集：核心 happy path、边界条件、目标宣称的杀手特性、用户最痛点。
5. **组件分解**：列出核心模块、可替换依赖、生态/数据/模型/硬件等不可轻易重写部分。
6. **行为选择**：
   - 能稳定调用且非差异化核心 → 调用/封装。
   - 质量差、耦合重、可用更简洁方式实现、或需独立发布 → 重写。
   - 巨型/长期生态部分 → 缩小到子系统或调用成熟依赖。
   - 复刻/照抄只作为理解阶段，不作为交付策略。
7. **实现闭环**：先做能跑通测例的最小版本，再补强超过目标的维度。
8. **对照验证**：在同一测例上跑目标与 morphling 产物，记录通过率、速度、稳定性、成本、易用性。
9. **固化成果**：调用型写入工具链/SOP；重写型形成 repo、README、测试与交付说明。

## 边界判断
- Office 这类巨型生态不做整体替代，拆成具体子系统或能力点。
- Stable-diffusion-webui 这类“大但核心可抽离”的项目可以重写核心体验，因为历史包袱可能大于真实复杂度。
- UI-TARS-Desktop 这类路线差异项目：调用可吸收其纯视觉能力；重写则意味着做一个独立多模态桌面 Agent，并跑同类 GUI benchmark。

## 执行方式
- Morphling 任务应通过 Goal Hive 执行（参见 goal_hive_sop），利用 Master 调度 + Worker 并行实现 + 持续验收的长程模式完成。

## 完成标准
- 必须有测例或明确构造的测例。
- 必须说明每个核心组件采用调用/重写/舍弃的理由。
- 必须能在同一考卷上与目标对比。
- “更好”不能只靠主观判断，至少落在一个可测维度：通过率、性能、成本、稳定性、易用性、可维护性、覆盖范围。
