# 搜索结果分组 Prompt（实验三档）

为后续"批次提炼 capability / strategy"做前置分组，三种维度对照实验：
1. **Prompt A** — 按 effects（解决的需求/效果）分组
2. **Prompt B** — 按 method（核心技术机理）分组 ← 当前重点
3. **Prompt C** — LLM 自主选维度分组

每个 prompt 都自包含、可直接复制使用。占位符 `{posts_block}` 由调用方拼接，每篇原帖以 `[POST id=p?]\n{content}\n\n` 起头。

**两条全局要求**（已写进每个 prompt）：
- **跨组帖子重复是预期**：一篇帖子如果用了多种 method / 涵盖多种 effects，应同时进入多个组；不是漏写、不是问题
- **粒度合理**：每个组既不能过大（无法横向归纳出可复用 capability），也不能过小（绑定单一参数/场景/工具，无法迁移）

---

## Prompt A：按 effects 分组

```
你是 AI 内容制作研究员，正在帮一个内容制作能力知识库做调研结果的预处理分组。

# 项目背景

我们在沉淀一个 AI 内容制作能力知识库，目标是从大量"如何用 AI 做出 X 内容"的原帖中提炼可复用的「能力（capability）」和「工序（strategy）」入库，未来供 agent 自主调用工具完成内容制作任务。

- **能力（capability）**：能独立交付产出 + 能在多个工序中复用的最小动作单元。例：人像角色一致性生成、三段式排版、图像超分。
- **工序（strategy）**：端到端制作流程，由能力组合而成。例：小红书穿搭分享首图制作流程。

# 当前任务

你做的是"分组"步骤——分组结果会送给下游"批次提炼 prompt"，每组独立提炼出多个 capability / strategy。**分组维度直接影响下游产出质量**：组内能横向归纳的共性越多，提炼出的 capability 越稳定、复用性越强。

**本次按 effects（解决的需求 / 实现的效果）维度分组**：同组内的帖子要解决的内容制作需求相近，**即使做法、工具完全不同**也归一组。

# 粒度判据

每组的"合理粒度"标准——组送入下游批次提炼时应能产出 1–3 个稳定可复用的 capability。

- ❌ **过大**：例如"做小红书内容"——需求太泛，组内 capability 无法收敛
- ❌ **过小**：例如"为某博主做 4 月某条首图"——绑定单一具体场景，无法迁移
- ✅ **合理**：例如"维持角色一致性"、"做穿搭分享首图"、"商品白底图制作"——明确的需求类型，跨账号 / 跨平台可套用

# 跨组帖子重复（重要）

一篇帖子如果同时涵盖多种 effects（例如教程同时讲"角色一致性"和"光影氛围渲染"），应同时进入多个组。member_post_ids 在不同组里重复出现是**预期、不是问题**。不要为了"每帖只属一组"硬切。

# effects_label 写法

每组的 `effects_label` 写一句"实现 XX 效果"形式的需求描述，不写工具名、不写做法（那是 method 维度的事）。

# 判据细则

- ✅ 同组：核心要解决的需求/效果相近
  例：以下三篇都属于"维持角色一致性"组——
  - 用 LoRA 训练实现角色面部一致
  - 用 IP-Adapter + reference image 锁定特征
  - 用 ControlNet + 多角度参考图保面孔
- ❌ 不要按工具或做法分组（那是 method 维度，不是当前任务）

# 输入

每篇原帖以 `[POST id=p?]` 开头标识，content 跟随其后：

---
{posts_block}
---

# 输出（严格 JSON，无任何额外文字）

{{
  "groups": [
    {{
      "group_id": "g1",
      "effects_label": "实现 XX 效果（一句话需求描述）",
      "member_post_ids": ["p1", "p3"]
    }}
  ],
  "ungrouped": [
    {{"post_id": "p?", "reason": "为什么不属任何组"}}
  ]
}}

# 通用规则

- 一篇可属多组（multi-effect 帖）→ member_post_ids 在多组中重复出现，预期行为
- 单成员组允许（孤儿效果，不强行合并）
- 组数参考：N 篇期望 ⌈N/8⌉ ~ ⌈N/3⌉ 组，过密过稀都需 reconsider
- 边界 case 进 ungrouped + 写 reason，不硬塞进组
```

---

## Prompt B：按 method 分组 ← 重点

```
你是 AI 内容制作研究员，正在帮一个内容制作能力知识库做调研结果的预处理分组。

# 项目背景

我们在沉淀一个 AI 内容制作能力知识库，目标是从大量"如何用 AI 做出 X 内容"的原帖中提炼可复用的「能力（capability）」和「工序（strategy）」入库，未来供 agent 自主调用工具完成内容制作任务。

- **能力（capability）**：能独立交付产出 + 能在多个工序中复用的最小动作单元。例：人像角色一致性生成、三段式排版、图像超分。
- **工序（strategy）**：端到端制作流程，由能力组合而成。例：小红书穿搭分享首图制作流程。

# 当前任务

你做的是"分组"步骤——分组结果会送给下游"批次提炼 prompt"，每组独立提炼出多个 capability / strategy。**分组维度直接影响下游产出质量**：组内能横向归纳的共性越多，提炼出的 capability 越稳定、复用性越强。

**本次按 method（核心技术机理）维度分组**——method 分组是这次工作的重点。同组内的帖子用了相似的核心技术路径或机理，**即使解决的需求、应用领域、具体工具实例完全不同**也归一组。

# 粒度判据（核心要求，请严格遵守）

method 分组的"合理粒度"——分组结果送入下游"批次提炼 prompt"时，**每组应能产出 1–3 个稳定可复用的 capability**。粒度过大或过小都直接破坏下游提炼。

## 过大（请避免）

- ❌ "用 SD 生图"——SD 生态下做法多样（LoRA / IP-Adapter / ControlNet / textual inversion 等），混在一组无法收敛出统一机理
- ❌ "用 LLM 做内容"——太宽泛，CoT / Agent / RAG 等不同机理混在一起
- ❌ "图像生成"——按工具类别分，不是按机理分

**过大特征**：组下含多种本质不同的机理路径，无法横向归纳出 1 个或几个共同的 capability。

## 过小（请避免）

- ❌ "用 LoRA rank=16 alpha=32 训练角色一致性"——参数化粒度
- ❌ "针对小红书首图的 LoRA + IP-Adapter 复合"——绑定单一应用场景
- ❌ "用 wanxiang 模型 + 某 prompt 模板生成人像"——绑定单一工具实例和具体 prompt

**过小特征**：绑定单一参数 / 单一场景 / 单一工具实例，删去这些约束后机理就和别组重合，无法独立成组也无法跨场景迁移。

## 合理（目标）

- ✅ "LoRA + reference image 复合维持一致性"——明确机理 + 跨场景适用（角色一致 / 画风一致 / 构图控制）
- ✅ "ControlNet + 参考图控制构图"——明确机理 + 跨内容形态适用
- ✅ "多 prompt 链 + 评分 reranker 选优"——明确机理 + 跨任务适用
- ✅ "图像分割 + 局部重绘"——明确机理 + 跨场景适用

**合理特征**：
1. method_label 描述"可独立调用的核心机理"——去参数化（不写 rank/alpha）、去场景化（不绑定小红书/抖音）、去工具实例化（不绑定某具体模型）
2. 删去组内任意一篇帖子，剩下的帖子仍能归纳出同一 method（鲁棒性）
3. 包含明确的"做法骨架"——不是"用 AI"这种空泛，也不是"某具体 prompt"这种死绑

# 跨组帖子重复（重要）

一篇帖子通常会用到多种 method（例如一个完整教程同时用了 LoRA、IP-Adapter、ControlNet、后期色调统调），**应同时进入多个 method 组**。member_post_ids 在不同组里重复出现是**预期、不是问题**。

为提炼充分覆盖该帖的全部机理信号，请尽量把帖子分配到所有它能贡献的组——分组宁愿冗余覆盖，不要漏。

# method_label 写法

每组的 `method_label` 写一句去参数化的机理概述：
- ✅ "用 LoRA + IP-Adapter 复合维持一致性"
- ❌ "用 LoRA rank=16 alpha=32 训练"（含参数）
- ❌ "用 SD"（太大，未到机理层）
- ❌ "用 LoRA 维持小红书博主角色一致"（绑定场景）

# 判据细则

- ✅ 同组：核心做法机理相似（不看具体参数、不看应用场景、不看具体工具实例）
  例：以下三篇都属于"LoRA 训练 + reference image 复合"组——
  - LoRA 训练 + reference image 维持角色一致性（人像场景）
  - LoRA 训练 + reference image 维持画风一致性（插画场景）
  - LoRA 训练 + reference image 控制构图（电商场景）
- ✅ 同组判定看机理层：rank/alpha/weight 不同 = 同一种 method，参数差异不影响分组
- ❌ 不要按需求/效果分组（那是 effects 维度，不是当前任务）

# 输入

每篇原帖以 `[POST id=p?]` 开头标识，content 跟随其后：

---
{posts_block}
---

# 输出（严格 JSON，无任何额外文字）

{{
  "groups": [
    {{
      "group_id": "g1",
      "method_label": "一句话去参数化机理概述",
      "member_post_ids": ["p1", "p3"]
    }}
  ],
  "ungrouped": [
    {{"post_id": "p?", "reason": "为什么不属任何组"}}
  ]
}}

# 通用规则

- 一篇可属多组（绝大多数有信息密度的帖子会涉及多种 method）→ member_post_ids 在多组中重复出现，预期行为
- 单成员组允许（孤儿机理，不强行合并）
- 组数参考：N 篇期望 ⌈N/8⌉ ~ ⌈N/3⌉ 组，过密过稀都需 reconsider；如果数据集机理多样，可以多于此范围
- 边界 case 进 ungrouped + 写 reason，不硬塞进组
- 自检：写完每组后回头看 method_label——它如果含参数、含具体场景名、含具体工具实例（如某模型名），需要重写抽象到机理层
```

---

## Prompt C：LLM 自主选维度分组

```
你是 AI 内容制作研究员，正在帮一个内容制作能力知识库做调研结果的预处理分组。

# 项目背景

我们在沉淀一个 AI 内容制作能力知识库，目标是从大量"如何用 AI 做出 X 内容"的原帖中提炼可复用的「能力（capability）」和「工序（strategy）」入库，未来供 agent 自主调用工具完成内容制作任务。

- **能力（capability）**：能独立交付产出 + 能在多个工序中复用的最小动作单元。例：人像角色一致性生成、三段式排版、图像超分。
- **工序（strategy）**：端到端制作流程，由能力组合而成。例：小红书穿搭分享首图制作流程。

# 当前任务

你做的是"分组"步骤——分组结果会送给下游"批次提炼 prompt"，每组独立提炼出多个 capability / strategy。**分组维度直接影响下游产出质量**：组内能横向归纳的共性越多，提炼出的 capability 越稳定、复用性越强。

**本次不指定分组维度**——你自主选择最有助于下游"批次提炼 capability / strategy"的分组方式，并在输出里说明选择理由。

# 候选维度（可选其一、可组合、可自创）

- effects（解决的需求 / 效果）
- method（核心技术机理）
- 应用领域（人像 / 风景 / 视频 / 文案 ...）
- 平台场景（小红书 / 抖音 / 知乎 ...）
- 工具栈（SD 系 / Flux 系 / 视频生成系 ...）
- 内容形态（图文 / 短视频 / 长文 ...）
- 复合维度（如 "effects + 应用领域"）
- 其他你认为更合适的

# 决策原则

1. 选能让"组内帖子可以横向归纳出共同 capability / strategy"的维度
2. 跟随数据本身的内在结构——不要硬塞维度
3. 复合维度可以但要明确写出（"effects + 平台"，标清楚每个维度的取值）
4. 优先选能让组内 capability 数量集中、组间 capability 重叠少的维度

# 粒度判据

每组的"合理粒度"——组送入下游批次提炼时应能产出 1–3 个稳定可复用的 capability。

- ❌ **过大**：组内涵盖多种本质不同的内容/做法，无法收敛出共同 capability。例："用 AI 生图"、"做小红书内容"
- ❌ **过小**：绑定单一参数 / 单一场景 / 单一工具实例，无法跨场景迁移。例："用 wanxiang 模型某 prompt 模板"、"为某博主做某条首图"
- ✅ **合理**：明确的中层抽象——可独立成 capability 单元、跨场景可迁移、有具体做法骨架

# 跨组帖子重复（重要）

一篇帖子如果在你选的维度上能贡献到多个组（例如同时涉及多种 method、多种 effects），**应同时进入多个组**。member_post_ids 重复出现是**预期、不是问题**。

# 输入

每篇原帖以 `[POST id=p?]` 开头标识，content 跟随其后：

---
{posts_block}
---

# 输出（严格 JSON，无任何额外文字）

{{
  "chosen_dimension": "你选择的分组维度 + 1-2 句理由（为何这个维度对当前数据集最合适）",
  "groups": [
    {{
      "group_id": "g1",
      "label": "一句话概括这组共性",
      "member_post_ids": ["p1", "p3"]
    }}
  ],
  "ungrouped": [
    {{"post_id": "p?", "reason": "为什么不属任何组"}}
  ]
}}

# 通用规则

- 一篇可属多组 → member_post_ids 重复出现，预期行为
- 单成员组允许
- 组数参考：N 篇期望 ⌈N/8⌉ ~ ⌈N/3⌉ 组，过密过稀都需 reconsider
- 边界 case 进 ungrouped + 写 reason
- 如果数据集天然不适合分组（例如全部独立、各讲各的），可以输出近乎"每篇一组"，并在 chosen_dimension 里说明此判断
```

---

## 实验对比建议

跑完三种分组后，把每组分别送给"批次提炼 prompt"，按下表收集对比指标：

| 指标 | 含义 | 怎么读 |
|---|---|---|
| 总 capability 数 | 三种分组下产出的 capability 总数 | 数量越少 + 复用越高 = 抽象越彻底 |
| 平均 source_post_ids 长度 | 每条 capability 平均合并了几个帖子 | 越大 = 跨帖归纳越成功 |
| 组内 capability 一致性 | 同组内 capability 的命名 / method 相似度 | 高 = 分组维度收敛性好 |
| 组间 capability 重叠率 | 不同组产出 capability 之间的语义相似比例 | 高 = 分组维度漏抽共性，需后置 dedup |
| 帖子跨组分配率 | 平均每帖出现在多少个组 | 1.0 偏低（可能漏分），1.5–3.0 健康 |
| 组规模分布 | 每组 member_post_ids 长度的分布 | 单峰均匀 = 粒度统一；长尾 = 有些组过大 |
| LLM 自主版选维度 | Prompt C 选了什么 | 看 LLM 对数据的内在判断 |

**预期假设**（待数据验证）：
- effects 分组：组内 method 多样 → 抽出的 capability "机理通用"，但数量可能偏多
- method 分组：组内做法收敛 → capability "做法稳定"，但需重点防止粒度过大/过小（已在 prompt 中加严判据）
- LLM 自主：可能选择复合维度（如 effects + 平台），适合作 baseline 反推合理维度

**建议样本量**：实验阶段 15–30 篇原帖足够看出趋势；少于 10 篇分组没意义。

---

## 摘要降级（可选）

如果原帖数量大、上下文超长，可先用"单帖提炼 prompt"产出每帖的 `name + method + effects` 摘要，再以摘要为输入跑分组（把 `[POST id=p?]` 后面的 `{content}` 替换为摘要文本即可，prompt 本体不变）。