wehub-resource-sync
44 lines
3.4 KiB
Markdown
44 lines
3.4 KiB
Markdown
# 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 并行实现 + 持续验收的长程模式完成。
|
||
|
||
## 完成标准
|
||
- 必须有测例或明确构造的测例。
|
||
- 必须说明每个核心组件采用调用/重写/舍弃的理由。
|
||
- 必须能在同一考卷上与目标对比。
|
||
- “更好”不能只靠主观判断，至少落在一个可测维度：通过率、性能、成本、稳定性、易用性、可维护性、覆盖范围。
|