Strategy 抽象化合并方法论

适用场景：已有 N 条 req-specific 的具体 strategy（每条是"为 req X 设计的解法"），想把它们合并成 M 条抽象 pattern（每条是"跨 req 可迁移的方法套路 / skill"）， N 通常 100-300，M 目标 20-40。

记录时间：2026-04-22（193 → 27 实操时）

一、核心立场

strategy 作为"skill"的价值在于迁移复用。合并的目的是识别"同一种做事方法" 跨 req 重现的规律，不是机械压缩数量。

因此：

合不合的唯一标准是方法论本身是否相同，不是 cap 集合是否重叠
宁可过细不过粗——过细还能查询，过粗会让后续工作失真
不信任自动化聚类结果，但可作为起点
不用 embedding（LLM 生成的 strategy 文本有大量命名漂移，embedding 对"方法差异"敏感度低）

二、五步执行流程

Step 1 · 准备特征数据

对每条 strategy 提取以下信号：

信号	用途
cap_signature（set of canonical cap ids）	机械粗筛基础
name（strategy 名）	理解命名者的本意
phase 列表（phase 名 + 简述）	理解执行步骤
reasoning（选择理由）	理解作者强调的差异点
body.source / workflow_outline 里的 implements	关键技术锚点（工具/模型/参数）

⚠️ 不要只取名字——名字往往是被 LLM 即兴起的，方法论藏在 phases 和 reasoning 里。

Step 2 · 机械粗筛（不是最终结果）

算法选择：中心贪心 + Jaccard 相似度

# 按 cap_count 降序排列（cap 多的做中心候选）
indices.sort(key=lambda i: -cap_count[i])

for center_idx in indices:
    if assigned: continue
    members = [center_idx]
    for other in indices:
        if other not in assigned and Jaccard(cap[center], cap[other]) >= threshold:
            members.append(other); assigned.add(other)
    clusters.append(members)

关键选择：

❌ 不用传递闭包：A-B=0.6, B-C=0.6 不代表 A-C 相似，容易滚成假大簇
✅ 中心-成员结构：每个簇所有成员都和中心相似，不跨中心扩散
阈值 0.5 是起点（0.4 太松、0.7 太紧；193 条时 0.5 产出 67 簇适合审）
0-cap strategy 单独处理（没有 signature 可比）

粗筛产出：候选簇 + 单例。把每个簇的成员（带 name/phases/reasoning）输出到 md，供下一步人工判断。

Step 3 · 人工判断（核心环节）

不要信任粗筛结果。逐簇读内容，问三个问题：

判断三问（按优先级）

Q1：方法论主轴是否相同？（决定能否合并）

方法论主轴即"怎么做"的根本路径。典型主轴：

主轴	判别特征
提示词直出	核心是单条 prompt，无多节点
工作流编排	Coze/ComfyUI/Lovart 串节点，LLM + 批量生图 + 后处理
参考图驱动	上传图做 anchor（风格/主体/构图）
局部重绘	Inpaint 蒙版，主体保持其余换
分层合成	分别生成底/人/光/字再合
双图融合	主体 + 目标两张图合一
模板填充	预设模板 + 数据源灌入
图生视频	静态图作首帧/尾帧驱动视频

主轴不同 → 不合并（即使 cap 完全一样）。

Q2：技术锚点是否相同？（决定同主轴下要不要再拆）

技术锚点 = 工具生态 / 模型 / 关键参数：

Coze vs ComfyUI（都"工作流"，但技能栈完全不同）
Midjourney --sref vs IP-Adapter vs ControlNet（都"参考图驱动"，但技术路径不同）
Nano Banana 多模态 vs GPT-Image 2 文字渲染（都"AI 直出"，但模型特定能力不同）

技术锚点不同 → 同主轴也拆开（他们是不同的 skill）。

Q3：产出形态是否与合并相容？（次要维度）

一条出九宫格一条出长图，方法（Coze 批量拼合）完全一致 → 合并
方法相同但产出不同 → 产出是参数层的事，不影响合并
产出相同但方法不同 → 不合并（产出不是方法论）

决策树

两条 strategy 应该合并吗？
├─ 方法论主轴相同吗？
│   ├─ No → 不合并
│   └─ Yes ↓
├─ 技术锚点相同吗？（工具/模型/关键技术）
│   ├─ No → 不合并（同主轴但不同 skill）
│   └─ Yes ↓
└─ 合并（产出形态差异可接受）

Step 4 · 命名抽象 strategy

每个 pattern 起名的规则：

必须体现方法论，不是产出：❌ "九宫格生成" ✅ "Coze 工作流编排全自动套路"
用"套路"/"skill"后缀（和"路线"/"流派"这种 req-specific 叫法区分开）
结构：[工具/生态] + [核心动作] + 套路 例如：
- "Nano Banana 多模态单模型直出套路"
- "双图融合虚拟试穿套路"
- "QA 闭环自动优化套路"
- "Character Sheet 多视角参考表套路"

避免：

过于通用的后缀如"套路"前不带任何区分词（"AI 生成套路" 无信息量）
req-specific 词汇（"表情包套路"太窄，改为"多情绪矩阵批量生成套路"）
英文术语堆砌（"Prompt-driven Single-Step Generation Pattern"）

Step 5 · 质量检查

合并完成后验证：

检查	期望
每个 pattern 的成员能用一句话描述共通做法	✓
pattern 数量在 20-40（针对 100-300 条 strategy）	✓（过少过合，过多过散）
单例 pattern 不超过总量 20%	允许 1:1 的"独特方法"，但不能全是单例
最大簇不超过总量 15%	超过说明粒度太粗
每条具体 strategy 被分配到一个（且仅一个）pattern	✓

三、反模式清单

以下做法即使诱人也要避免：

反模式 1 · 按 cap 重合度机械合并

典型：Jaccard >= 0.7 传递闭包 → 45 条归一大类
问题：基础 cap（CAP-001 文生图、CAP-008 批量、CAP-014 文字）人人都用，重合度高不代表方法同
对策：cap 只做粗筛，判断要看 phases + reasoning

反模式 2 · 按 name 文本相似度合并

典型：用 2-gram Jaccard 比 strategy name
问题：LLM 生成的 name 命名漂移严重（"3D夸张风格路线"和"多镜头拟人化故事视频流派"都用"多维"和"拟人化"词汇，但方法完全不同）
对策：名字只是参考，以 phases 为准

反模式 3 · 用 embedding 做相似度

典型：把每条 strategy 文本化后 embed，cosine > 0.85 合并
问题：embedding 对"讨论话题"敏感，对"方法差异"不敏感（两条都讨论"生成猫咪表情包"得分很高，但一条是 prompt 直出，一条是 ComfyUI 换装，不该合并）
对策：看不见的信号不用

反模式 4 · 用传递闭包

典型：A-B=0.6、B-C=0.6，推出 A-B-C 一簇
问题：A-C 可能 0.2，真实不相似，但被强行归到一起
对策：中心-成员结构（每个成员必须和簇中心相似，不跨中心传递）

反模式 5 · 按产出形态分类

典型：把所有"九宫格"归一类、所有"视频"归一类
问题：产出相同但方法可以天差地别；同方法应用到不同产出反而被拆开，失去迁移复用价值
对策：方法优先，产出次要

反模式 6 · 过度细分到失去抽象

典型：每条 strategy 都有自己独特之处 → 27 条变 50+ pattern
问题：没达到抽象目的，相当于 1:1 映射
对策：强制合并"大同小异"，抓主轴忽略细节差异

反模式 7 · 过度合并到失去信息

典型：所有 AI 生成归为"AI 生成套路"
问题：抽象层级太高，查询时无区分度
对策：至少区分"方法论 × 技术锚点"两维

四、边界情况处理

情况 1 · Strategy 跨多个 pattern

示例：REQ_045 的"AI脚本驱动·批量生图·文字嵌入·宫格自动排版一体化流派" 同时涉及：

Coze 工作流编排（P04）
网格直出（P15）
AI 文字渲染（P26）

处理：归到主要方法那个 pattern（通常是方法论主轴最重的那个）。这里归 P04，因为 Coze 编排是灵魂，网格和文字只是其中一个环节。

情况 2 · 单例 strategy

示例：只有 1 条成员的候选 pattern。

处理：

若确实是独特方法（无其他 strategy 可合并），保留为单例 pattern
若是因数据稀少导致的漏判（比如 alt strategy 没生成），归到最近的 pattern
判断标准：这条 strategy 的方法论是否将来可能被其他 req 采用？是则独立，否则合并

情况 3 · 0-cap 或 body 缺失的 strategy

处理：优先用 salvage 脚本补全 body（参考 salvage_placeholder_strategies.py），再参与合并。无法补全的标 data_degraded，不参与聚类。

情况 4 · Selected 和 Alt 归到同一 pattern

这是正常的。一个 req 的 selected 和 alt 如果用同一方法（只是参数不同）就应归同一 pattern。不同 req 各自的 alt 归到同一 pattern 也正常——说明那个方法在多 req 下都被考虑过但未被选中。

情况 5 · 方法论混合型 strategy

示例：一条 strategy 前半用 Coze 工作流后半用 ComfyUI 精修。

处理：归到阶段数占比最大的那个 pattern。若真 50-50，归到门槛更低的那个（工作流 > ComfyUI）。

五、实操产出形式

完成后给用户审核的 md 应包含：

## P01 · 套路名
> 一句话方法论描述

**成员（N）**：
- REQ_XXX selected/alt name
- REQ_YYY selected/alt name
...

以及汇总表：

| # | 套路 | 成员数 |
|---|---|---|
| P01 | ... | 17 |

用户审核时主要看：

套路命名是否一眼看懂方法论
成员是否符合命名（粗翻，找明显不搭的）
边界是否合理（有没有想拆/想合的冲动）

用户通常只会"看一眼没问题就行"，所以方案要一读即懂，命名和分类要经得起 5 秒直觉判断。

六、后续入库建议

合并方案确认后：

保留全部原具体 strategy 作为 knowledge（带 version 标记，如 howard_strategy_instance）
新建抽象 strategy（约 N/6 条，N=具体 strategy 数量）
requirement_strategy 改 M:N：每 req 关联其具体 strategy 对应的抽象 pattern
strategy_capability 重建为抽象 strategy ↔ cap signature（取簇内 cap 联合集或频次 ≥50% 的核心集）
strategy_resource 为抽象 strategy ↔ 簇内所有成员 resource 联合集

七、本次（2026-04-22）实操验证

指标	值
输入具体 strategy 数量	193
机械粗筛候选簇数（Jaccard>=0.5 中心贪心）	67（31 多簇 + 36 单例）
人工判断后最终 pattern 数	27
pattern 分布	最大 17 成员 / 平均 7 / 最小 1
耗时（纯判断环节）	~30 分钟

关键观察：

粗筛的 31 多簇最终拆成了 20+ 个 pattern（方法论主轴不同被拆）
但也有跨候选簇的 strategy 被合并（机械聚类因 cap 不完全重合未识别，但方法论相同）
说明机械聚类召回和精度都不够，人工判断不可省

参考脚本

knowhub/scripts/salvage_placeholder_strategies.py - 占位 strategy 修复（Step 0 前置）
knowhub/scripts/ingest_all_strategies.py - 全量入库含 alt（本方法论的输入数据准备）
Phase 3 聚类脚本（center-greedy clustering） - 本方法论 Step 2 的实现

strategy_abstraction_methodology.md 11 KB Постоянная ссылка История Исходник