group_search_results_prompts.md 15 KB

搜索结果分组 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 本体不变)。