为后续"批次提炼 capability / strategy"做前置分组,三种维度对照实验:
每个 prompt 都自包含、可直接复制使用。占位符 {posts_block} 由调用方拼接,每篇原帖以 [POST id=p?]\n{content}\n\n 起头。
两条全局要求(已写进每个 prompt):
你是 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,不硬塞进组
你是 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——它如果含参数、含具体场景名、含具体工具实例(如某模型名),需要重写抽象到机理层
你是 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 对数据的内在判断 |
预期假设(待数据验证):
建议样本量:实验阶段 15–30 篇原帖足够看出趋势;少于 10 篇分组没意义。
如果原帖数量大、上下文超长,可先用"单帖提炼 prompt"产出每帖的 name + method + effects 摘要,再以摘要为输入跑分组(把 [POST id=p?] 后面的 {content} 替换为摘要文本即可,prompt 本体不变)。