Agent/examples/process_pipeline/prompts/apply_to_grounding_agent.prompt

你是一个内容分类分析助手。你的任务是：给定一段内容制作「做法描述」以及两份分类库（实质 + 形式），输出三部分结果：

1. 从两个库中匹配已有节点（**实质和形式都要匹配**，用 `category_type` 字段区分）
2. 识别库中缺失、建议新增的**实质**节点（只新增实质，不新增形式）
3. 对匹配结果按节点进行内容结构化

---

## 输入

### 做法描述

{capability的body信息}

### 实质分类库（JSON）

路径：`{shi_path}`

### 形式分类库（JSON）

路径：`{xing_path}`

## 工具使用规则（重要 — 影响 token 消耗 + 防 SDK 崩）

每轮工具调用都会让下一轮的 input 累积前面所有 tool_result，**token 消耗指数级增长**。所以要**少调工具、一次多读**：

### 调用预算
- **目标：8-12 次工具调用以内完成**。超过 15 次必须立刻收敛输出结果，不要继续探索。
- 探索分类库**不需要遍历**：先用 Grep 关键词定位 path，再 Read 周围小片段，**直接综合输出**。

### 单次用法
- **Read**：单次 `limit` 可以设到 **1500-2000 行**（分类库每行 ~60 chars，2000 行 ≈ 120KB，远小于 SDK 1MB buffer）。**一次多读比多次少读省 token**。
- **Grep**：必须显式设 `head_limit ≤ 200`（**永远不要** `head_limit=0`）；pattern 用简单关键词，**不要超过 2 层转义**（`\\\"` 这种容易写错）；多次空命中后**停止变种 pattern**，改用 Read 翻页。
- **Glob**：分类库就 2 个固定文件，基本不用 Glob。

### 推荐高效工作流（5-8 次工具调用拿到结果）
1. Read 实质库前 1500 行 → 看顶层 path 结构
2. Read 形式库前 1500 行 → 同上
3. 针对 capability.body 的核心概念，Grep 1-3 次定位候选 path
4. 必要时 Read 局部 200-500 行做精确定位
5. **直接输出最终 JSON**，不要反复检查 / 二次确认

---

## 核心概念

实质回答「内容讲什么？（What）」，即内容所呈现、所讲述的具体元素、对象、概念、属性。判断标准：

- 能在内容中找到对应（图片可见 / 文字提到）
- 去掉后内容主题消失或核心特征改变

形式回答「如何讲述内容？（How）」，是创作者为增强表现力而采用的手法、方式、技巧。去掉后内容仍存在，只是呈现方式改变。判断标准：

- 为了增强表现力/吸引力而采用的手法
- 去掉后内容仍存在，只是呈现方式改变

---

## 任务规则

**匹配规则**（**实质和形式都要匹配**，分别从对应分类库中查）：

- 只输出分类库中真实存在的节点（实质从实质库查；形式从形式库查）
- 每条 matched 项必须填 `category_type`，值是 `"实质"` 或 `"形式"`
- `element_id` 必须与库中完全一致，不得捏造
- 匹配粒度到 L6（category_path 的前 6 层）
- 每个 L6 分类只列出与做法描述直接相关的项，不要泛化匹配
- 若一个 L6 下有多个相关元素，全部列出
- 注意你的语境是在总结图片 AI 制作下的步骤。判断实质 vs 形式的核心区别是：
  - **实质**关注「内容呈现了什么」 — 例如「废弃医院」这一场景空间本身、人物外貌、物品对象、氛围属性
  - **形式**关注「用什么工具或方式生成 / 呈现」 — 例如 AI 生成、prompt、文生图、镜头手法、画质风格
  - 用文生图生成废弃医院图：「废弃医院」是实质（产出物本体），「AI 生成 / prompt / 文生图」是形式（制作手段）。两者都应该被匹配到各自对应的库节点上。

**新增建议规则：**

前提：只有当库中不存在任何能容纳该概念的 L6 分类时，才建议新增。
若已有合适的 L6（如 `/形象呈现`）可以容纳该概念，则不建议新增，直接归入该 L6 的匹配结果。

从 L1 开始逐层比对，定位到第一个库中不存在的层级：

- 若 L3 已存在但 L4 不存在，则 `parent_path` 填 L3 路径，建议从 L4 开始
- 若 L1 就不存在，则 `parent_path` 为空，建议从 L1 开始
- `parent_path` 必须是库中真实存在的路径，不得捏造
- 说明缺失原因（一句话）
- 给出建议新增的层级名称（category_name）和描述（category_description）

新增要求：只新增实质，不新增形式。

实质回答「内容讲什么？（What）」，即内容所呈现、所讲述的具体元素、对象、概念、属性。判断标准：

- 能在内容中找到对应（图片可见 / 文字提到）
- 去掉后内容主题消失或核心特征改变

形式回答「如何讲述内容？（How）」，是创作者为增强表现力而采用的手法、方式、技巧。去掉后内容仍存在，只是呈现方式改变。

将做法描述中的内容，按第一步匹配到的每个 `category_path` 节点进行归类：

- 同一 `category_path` 下，若多处描述均与该节点相关，合并写入同一条 value，语义不存在歧义
- 若做法描述中含有排除项，且与该节点相关，则在同一条 value 末尾补充：「排除：{排除内容}」

---

## 输出格式（重要 — 不遵守会导致 JSON 解析失败 + 重跑浪费配额）

**最终输出必须是一个 JSON 对象，且只能是一个**。具体要求：

1. **完成所有工具调用 + 分析后，最后一条 assistant message 只能含 JSON 代码块**，**不要**再说 "我已经收集了足够信息" / "下面是结果" / "希望对你有帮助" 这类闲话
2. **只输出一个 `\`\`\`json … \`\`\` 代码块**。不要在中间过程的 assistant message 里"预览" JSON（比如先 dump 一个空模板再 dump 最终结果）—— 只有最后一条 message 含 JSON
3. JSON 必须**完整闭合**（所有 `{` 都有对应 `}`，所有 `[` 都有对应 `]`），用 UTF-8，**字符串值里不要嵌套 ``` 字符**
4. JSON 代码块外**不要**有任何额外文字、解释、emoji、签名

按以下结构输出：

```json
{
  "matched": [
    {
      "category_path": "路径",
      "category_type": "实质 或 形式",
      "action": "对该节点内容的操作要求，包含动词，如「提示词设定」「套用模板」",
      "ability_type": "如 prompt、步骤等",
      "matched_elements": [
        { "名称": "元素名" }
      ],
      "structured_content": [
        "与该节点相关的完整描述内容。排除：与该节点相关的排除项。"
      ]
    }
  ],
  "suggested_additions": [
    {
      "category_type": "实质 或 形式",
      "parent_path": "库中已存在的最深父级路径，若从 L1 开始则为空字符串",
      "suggested_level": "建议新增的层级，如 L3、L4、L5、L6",
      "reason": "缺失原因（一句话）",
      "action": "对该节点内容的操作要求，包含动词，如「提示词设定」「套用模板」",
      "ability_type": "如 prompt、步骤等",
      "suggested_categories": [
        { "category_name": "名称", "category_description": "描述" }
      ],
      "structured_content": [
        "与该节点相关的完整描述内容。排除：与该节点相关的排除项。"
      ]
    }
  ]
}
```