scrape-plan

此文件共 544 行，请全部阅读。

以下 SKILL_DIR 表示包含此文件的目录的绝对路径。SKILLS_DIR 表示存放所有技能目录的目录，其中一个目录就是 SKILL_DIR。

你正计划抓取网页。先下载 1 个详情页，发现字段，在终端中确认架构，然后通过下载更多页面、比较 HTML 变体并提取值来验证规范，最后提交最终计划以供批准。

用户可以直接调用此技能（为某个网站规划抓取器/爬虫），也可以由 /scrape 编排器将其作为规划和验证阶段调用。

请阅读 SKILLS_DIR/scrape/references/python-environments.md 和 SKILLS_DIR/scrape/references/extraction-spec.md。

你需要输出两部分内容：

1. .scrape/{site_name}/ 下的持久化规范文件——架构、页面、值和导航数据类型，供构建爬虫使用。
2. 纯文本最终消息，包含已确定的计划参数（最终确认阶段）——/scrape 编排器会解析此内容，以驱动后续阶段。

以下有几个步骤需要在子 Agent 中运行技能，以免页面 HTML 进入当前上下文。请使用任何能在独立 Agent 中运行提示词的工具进行委派，例如 Agent、task 或 spawn_agent：将引号中的文本作为提示词，并将 Agent 类型、模型和推理力度保留为默认值。如果没有此类工具，则依次在当前上下文中运行技能，并仅根据其保存的输出文件继续操作。

以下有几个步骤会请用户在选项中进行选择。无法提问时，请改用问题中所述的备用方案，并在最终答复中说明。请使用任何能向用户提供多选题的工具提问，例如 AskUserQuestion 或 request_user_input；如果没有此类工具，请以纯文本提问，按编号列出选项，然后等待用户答复。

硬性约束——绝不可违反：

• 你不得自行获取、读取、搜索或解析任何 HTML 文件。页面下载由 download.py 处理；字段发现由 /scrape-analyze-page 子 Agent 处理。主 Agent 只能负责协调并使用其输出。
• 这包括 raw.html、rendered.html、*.cleaned.html 以及任何其他已保存的页面 HTML。你可以检查文件是否存在，但不得打开、打印、搜索、解析这些文件，也不得从主 Agent 运行提取脚本处理这些文件。
• 构建任何架构之前，必须先将 /scrape-analyze-page 作为子 Agent 调用。未先运行该子 Agent 就根据原始 HTML 构建架构，属于严重错误。
• 等待 /scrape-analyze-page 期间，不得读取 HTML 文件、运行 clean_html.py 或 extract_metadata.py，也不得运行任何内联解析代码，即使 Agent 的回复建议继续处理无关工作也不行。请等待子 Agent 完成，然后只读取其保存的 JSON 输出。

工作规则

以下是贯穿各阶段的规则；下文各部分会按名称引用这些规则。

• 网站受阻规则：如果下载或探索报告网站受阻，请建议使用 Zyte API。只有用户同意后，才调用 /zyte 进行凭据设置——传入凭据设置请求（例如 /zyte set up Zyte credentials），以确保技能进入凭据设置流程，而不是其他流程。完成后，重新运行失败的下载/探索，只有成功后才能继续。
• HTML 文件选择规则：优先使用 rendered.html；如果该文件不存在，则使用 raw.html。分析两种变体时，跳过不存在的文件。只能通过检查文件是否存在来判断（参见硬性约束）。
• 事实来源规则：.scrape/{site_name}/{data_type}/spec.json 是架构的唯一事实来源。所有架构变更（删除、重命名、描述编辑、来源变更）都必须应用于此文件；如果 .scrape/{site_name}/{data_type}-list/spec.json 存在，也必须同步架构变更。

解析意图

这是用户提示词：$ARGUMENTS。你需要从中提取以下信息：

• target_url：起始 URL
• data_type：要提取的内容类型，始终使用单数，无论用户是否明确指出，还是由你根据 URL／页面推断——“books” → “book”，“products” → “product”
• field_hints：用户提到的任何特定字段（可为空）
• existing_approved_schema：调用方提供的任何明确现有架构，例如 Existing approved schema: ProductItem(title: string, price: string, rating: string)。这些字段已由项目上下文批准，并非仅供参考。
• site_name：简短标识符（例如 “books-toscrape”、“realestate-listings”）——根据网站和数据类型推导

如果提示词中指定了以下计划参数，也要一并提取。它们会预先填入初始计划中的对应行，让用户看到这些参数已应用，而无需在细化时重新说明：

参数	默认值	备注
project_name	根据网站推导（例如 books_toscrape_com）
project_dir	./{project_name}
html_variant	auto	raw 或 rendered 会固定变体；auto 会比较两者
browser_review	ask	always / never
spider_create	yes	no 会跳过 spider 阶段
Zyte API	除非已配置，否则关闭

工作分为五个阶段——发现、架构门控、验证、审查、最终定稿——依次进行，每个阶段都决定是否进入下一阶段。每个阶段内的各个部分按执行顺序排列：后续部分会使用前面部分的输出。

发现

选择一个唯一的网站名称

BASE="books-toscrape"  # your derived site_name
NAME="$BASE"
N=2
while [ -d ".scrape/$NAME" ]; do NAME="${BASE}-${N}"; N=$((N+1)); done
echo "$NAME"

规范文件放在 .scrape/{site_name}/ 下，工作文件放在 .scrape/.work/{site_name}/ 下。由写入这些目录的工具按需创建目录——无需预先创建。

获取详情页

决定如何获取详情页：

• 如果 target_url 本身就是详情页（用户指向某个具体商品／文章，或 URL 明确指向某个具体项目），直接下载。
• 否则，询问用户——你必须询问；不得替用户做决定。问题：“我该如何获取详情页进行分析？如果你已经有详情页 URL，请将其粘贴为‘其他’答案。”标题：“详情页”。选项：提供 URL（描述：“你也可以直接将 URL 粘贴到自由填写的答案中。”）／探索网站。如果答案是 URL，直接下载；如果用户选择了 提供 URL 但未提供 URL，告诉用户“请粘贴详情页 URL。”，等待用户提供 URL，然后直接下载。备用选项：探索网站。

使用 download.py 直接下载：

uv run --python 3.14 SKILL_DIR/scripts/download.py <<'EOF'
[{"url": "DETAIL_URL", "output_dir": ".scrape/.work/{site_name}/explore/pages/detail-1", "page_type": "detail"}]
EOF

探索时，请自行按步骤进行探索，并在此处执行——这项最简探索工作不足以使用子 Agent。阅读 SKILL_DIR/references/explore-site.md，并按以下参数执行： url={target_url}, project_path=.scrape/.work/{site_name}/explore, DETAIL_COUNT=1, LIST_COUNT=0。

这会将首页和 1 个详情页下载到 .scrape/.work/{site_name}/explore/pages/。

如果探索报告网站受阻：应用受阻网站规则。

分析详情页并探索网站

根据 HTML 文件选择规则选择用于分析的 HTML 文件（优先选择已渲染的文件，只检查文件是否存在）。

在一条消息中启动两个子 Agent：一个分析详情页，另一个完整探索网站，供 Validation 阶段使用。现在启动探索任务，可让它在后台运行并通过架构门禁，而不是在之后的 Validation 阶段阻塞。探索任务会复用已下载的页面，只下载达到数量要求所需的缺失页面；根据子 Agent 路径规则，在提示词中传入 SKILL_DIR。分析提示词必须以 /scrape-analyze-page 开头，且子 Agent 必须调用该技能——由主 Agent 替代执行将违反硬性约束。

每行一个子 Agent，先写描述，再写提示词：

analyze detail-1 rendered — 运行 /scrape-analyze-page，从 .scrape/.work/{site_name}/explore/pages/detail-1/rendered.html 提取数据，并将结果保存到 .scrape/.work/{site_name}/analyze-page/detail-1.rendered.json explore site — 阅读 SKILL_DIR/references/explore-site.md 并遵循其中的说明，使用以下参数：url={target_url}, project_path=.scrape/.work/{site_name}/explore, DETAIL_COUNT=2, LIST_COUNT=2。返回摘要。

等待分析子 Agent 完成——探索任务会在后台继续运行；Validation 阶段会收集其结果。然后从 .scrape/.work/{site_name}/analyze-page/detail-1.rendered.json 读取分析结果——根据硬性约束，此 JSON 是主 Agent 唯一可用于发现字段的输入。如果预期文件不存在，请重试 /scrape-analyze-page 子 Agent，或报告阻塞问题。

构建架构

根据分析结果构建 JSON Schema：

• 收集所有字段名称及其类型（analyze-page 会报告 JSON Schema 类型名称）
• 为每个字段添加 description（根据上下文推断）
• 将与 field_hints 匹配的字段标记为 "source": "requested"，其他字段标记为 "source": "discovered"
• 从提取的值中记录 examples（若超过 200 个字符，则截断并加上 ...）

如果存在 existing_approved_schema，它将覆盖开放式字段发现：

• 仅根据已批准的字段名称和表面类型构建架构。
• 分析结果中的值只能用作这些字段的示例和提取依据。
• 将所有已批准的字段标记为 "source": "requested"。
• 不要添加无关的已发现字段，即使 /scrape-analyze-page 找到了它们。
• 如果分析结果中缺少某个已批准字段，或其类型看起来不兼容，请报告冲突，不要悄悄将其丢弃或更改。

架构门禁

快速检查架构

如果存在 existing_approved_schema，则跳过未更改字段的审批流程。简要说明将沿用现有项目架构，然后继续保存规范。不要再次要求用户选择、重新定义或审批这些字段。

否则，在终端中显示包含值的架构，并按请求/发现的字段分组：

Found {N} fields on {detail_page_url}:

Requested:
  title (string): "A Light in the Attic"
  price (string): "£51.77"

Discovered:
  rating (integer): 3
  category (string): "Poetry"
  description (string): "It's hard to imagine a world without..." (2340 chars)
  upc (string): "a897fe39b1053632"

这些字段是从一个页面中抽取的；验证阶段会在更多页面上检查这些字段，因此列表仍可能发生变化。告知用户现在可以添加、删除或重命名字段，也可以将详细修改留到之后的浏览器审核中。

等待用户回复。用户可以：

• 批准（"looks good"、"ok"、"approve"）→ 继续保存规范
• 删除字段（"drop description, image_url"）→ 从架构中移除，并显示更新后的列表
• 保留发现的字段（"keep rating"）→ 将其 "source" 改为 "requested"
• 重命名（"rename upc to product_code"）→ 在架构中重命名
• 编辑描述（"price should be without the currency symbol"）→ 更新描述和值
• 使用其他详情页 URL → 直接下载该页面（"Get a detail page"），重新运行分析子 Agent 和 "Build schema"，然后再次展示。不要重新启动探索——正在运行的探索仍然有效，它以 target_url 为键。
• 其他指示 → 执行并显示更新后的架构

持续循环，直到用户批准；每次变更后都重新显示架构。

如果用户已预先授权继续（例如 "just save it, don't check back"），则跳过等待，直接保存规范。

保存规范（架构检查之后）

按照 extraction-spec.md 中的数据类型规范格式（url、data_type、html_variant、schema），写入 .scrape/{site_name}/{data_type}/spec.json。schema MUST 是使用文档所述子集的有效 JSON Schema（draft/2020-12）——不要自行编造自定义格式（例如普通的字段对象数组）。每个字段都需要包含 type、description 和 examples——用户批准的值（包括任何更正）；如果超过 200 个字符，则截断并加上 "..."。将 html_variant 设为探索阶段分析的变体（如果 "Choose HTML variant" 的比较结果选择了不同变体，则更新该值）。

验证

收集探索结果

现在要使用更多页面验证架构。如果探索阶段启动的 "explore site" 子 Agent 仍在运行，现在等待其完成——它通常会在架构审核期间完成。如果它失败或从未启动，则使用相同提示启动它并等待。

返回后，探索结果会包含起始页、2 个详情页、2 个列表页、分类后的链接和导航值，全部位于 .scrape/.work/{site_name}/explore/ 下。将其摘要中的链接提取变体存储为 nav_html_variant——"Extract values" 会将其写入导航规范。

如果站点被拦截，请应用受阻站点规则。

然后将页面分发到正确的数据类型子文件夹（site_path 为 .scrape/{site_name}）。只复制下游会读取的内容——HTML 变体和 meta.json；links.json 和 groups.txt 保留在工作目录中：

copy_page() {
  dest="$2/$(basename "$1")"; mkdir -p "$dest"
  for f in "$1"/*.html "$1"/meta.json; do [ -f "$f" ] && cp "$f" "$dest"; done
}

# Detail pages → data type
for d in .scrape/.work/{site_name}/explore/pages/detail-*; do
  [ -d "$d" ] && copy_page "$d" {site_path}/{data_type}/pages
done

# Start + list pages → navigation
for d in .scrape/.work/{site_name}/explore/pages/start-* .scrape/.work/{site_name}/explore/pages/list-*; do
  [ -d "$d" ] && copy_page "$d" {site_path}/navigation/pages
done

# Navigation values (generated by the exploration)
mkdir -p {site_path}/navigation/values
cp .scrape/.work/{site_name}/explore/values/*.json {site_path}/navigation/values/ 2>/dev/null || true

并行分析详细页样本和列表页

通过分析有限的详细页样本（两种 HTML 变体，测试哪种可以提取已批准的架构字段）以及每个列表页，验证架构。

复用 Discovery 分析结果。 Detail-1 的 Discovery JSON 已位于 .scrape/.work/{site_name}/analyze-page/，且架构就是基于它构建的， 因此无需重新分析该页面和变体。例外：如果架构审核除了批准、删除或保留字段之外，还进行了其他修改（重命名、编辑描述或值格式、添加字段），JSON 就不再与架构匹配——将该变体重新加入启动列表。

构建启动列表：

1. 详细页样本。 选择样本页面：

   • 如果 {site_path}/navigation/pages/ 中有列表页：选一个页面——第一个同时具有 raw.html 和 rendered.html 的详细页；如果没有，则回退到 detail-1。
   • 否则：选择 detail-1 和 detail-2。

   每个样本页面的每种 HTML 变体启动一个子代理——跳过文件不存在的变体（HTML 文件选择规则）、可复用 Discovery JSON 已覆盖的变体，以及在 html_variant 已固定时的另一种变体。详细页子代理最多 4 个。

2. 列表页。 对 {site_path}/navigation/pages/ 中的每个页面，使用 raw 变体启动一个 --list-mode 子代理，将值直接写入 {site_path}/{data_type}-list/values/。只要存在列表页，就必须执行——用户指定数据类型 ID 不是跳过它们的理由：该 ID 正是 {data_type}-list 的派生依据，且下面的列表数据类型决策依据字段覆盖情况，而非意图猜测。绝不要为了给详细页腾出位置而舍弃列表页子代理。

在一条消息中启动所有子代理，中间不要调用工具——不要等待任何结果后再启动其余子代理——并且启动数量不得超过 5 个。如果运行环境无法并行运行，则依次运行。详细页部分为空是正常的（唯一存在的变体已在 Discovery 中分析）；如果整个启动列表为空，则仅使用 Discovery JSON 继续。

每行一个子代理，先写描述，再写提示词：

analyze detail-1 raw — 运行 /scrape-analyze-page，使用 {site_path}/{data_type}/spec.json 中的架构，从 {site_path}/{data_type}/pages/detail-1/raw.html 提取数据，并将其保存到 .scrape/.work/{site_name}/analyze-page/detail-1.raw.json analyze list-1 — /scrape-analyze-page --list-mode，使用 {site_path}/{data_type}/spec.json 中的架构，从 {site_path}/navigation/pages/list-1/raw.html 提取所有 {data_type} 项目，并将其保存到 {site_path}/{data_type}-list/values/list-1.json analyze list-2 — /scrape-analyze-page --list-mode，使用 {site_path}/{data_type}/spec.json 中的架构，从 {site_path}/navigation/pages/list-2/raw.html 提取所有 {data_type} 项目，并将其保存到 {site_path}/{data_type}-list/values/list-2.json ...（在同一条消息中，为剩余的每个列表页各启动一个子代理）

架构路径为 analyze-page 提供已批准的字段名称、描述和示例，使其能够使用正确的名称和值格式进行提取。 此处启动的子代理是 Validation 阶段中唯一的分析子代理——这是硬性限制，而非建议：本阶段其余工作只依据有限样本的输出，即使探索阶段下载的详细页多于样本分析的页面，也不例外。

如果已完成的分析对某个值的格式存在分歧（例如，某个列表页使用的价格币种与其他所有输出不同），不要重新分析。如果其他输出已经确定正确格式，则用一个小脚本直接修补受影响的值文件，并在呈现计划时说明修正；如果确实无法确定，则保留提取出的值，并在计划中注明差异。

决定是否创建列表页数据类型

此决定仅适用于在上述并行分析中发现并分析了列表页的情况。

此决定仅依据下方的字段覆盖规则作出——不要因为用户请求的数据类型而跳过或覆盖此规则：列表页提取能精确提供所请求的字段，只是成本更低（条目直接来自列表页，无需逐项请求详情）。

读取 {site_path}/{data_type}-list/values/list-*.json 文件。对于每个文件，检查架构中的每个 source: "requested" 字段是否都作为键出现在 values 数组至少一个条目中。

如果每个列表页 values 文件中都找到了所有请求字段：

设置 list_spec_created = true。

1. 写入 {site_path}/{data_type}-list/spec.json：

   {
     "url": "{url}",
     "data_type": "{data_type}-list",
     "html_variant": "raw",
     "schema": {<same schema object as in {site_path}/{data_type}/spec.json>}
   }
   

2. 将列表页复制到新的数据类型中：

   mkdir -p {site_path}/{data_type}-list/pages
   for d in {site_path}/navigation/pages/list-*; do
     [ -d "$d" ] && cp -r "$d" {site_path}/{data_type}-list/pages/
   done
   

否则： 设置 list_spec_created = false。按常规继续提取详情页——{data_type}-list/values/ 目录可以保留，但会被忽略。

选择 HTML 变体

如果计划中已固定 html_variant，则跳过此比较并使用固定的变体。

比较 .scrape/.work/{site_name}/analyze-page/ 中限定样本的原始结果与渲染结果。

对于每个页面，比较 {page_id}.raw.json 和 {page_id}.rendered.json：

• 哪种变体找到的架构字段更多？
• 哪些字段只出现在一种变体中？
• 同一字段在不同变体中的值是否不同？

使用一个小型 Python 脚本进行比较。脚本应加载 {site_path}/{data_type}/spec.json，枚举 .scrape/.work/{site_name}/analyze-page/*.json，仅比较架构字段的覆盖情况和值，打印简洁摘要，并建议使用 raw，除非 rendered 能稳定找到 raw 遗漏的请求架构字段。

默认优先使用 Raw——它速度更快、成本更低，也更可靠。只有当它能找到 raw 稳定遗漏的架构字段，或者原始 HTML 基本为空（SPA 网站）时，才使用 rendered。

在终端中展示比较结果：

HTML variant comparison:
  Both variants found: name, price, brand, description, image_url
  Only in rendered: reviews_count (3/3 pages), sale_price (2/3 pages)
  Only in raw: (none)
  Value differences:
    price: raw="$29.99", rendered="$24.99" (detail-1) — rendered may show sale price

  Recommendation: raw (all schema fields found)
  Note: rendered also has reviews_count, sale_price — say "use rendered" if you need these.

如果能明确该使用哪种变体，就使用它。如果无法确定——例如 raw 视图包含大多数字段，但并非全部——询问用户要使用哪种变体（问题为“提取时应使用哪种 HTML 变体？”，标题为“HTML 变体”，选项为“使用 raw”和“使用 rendered”，并将推荐选项标记为推荐），然后使用用户选择的变体。回退方案：使用推荐的变体。

如果两种变体在限定样本中都找到了所有已批准的架构字段，立即选择 raw。 如果所选变体与规范中的不同，则使用新的 html_variant 更新 {site_path}/{data_type}/spec.json。 选定变体后，直接继续提取值；不要启动更多分析子代理。

提取值

如果 list_spec_created 为 true，则跳过下方的详情页值提取——并行分析已将值写入 {data_type}-list/values/。 下方的 Navigation 部分仍然适用。

否则，使用 extract_values.py 从分析文件构建值，并按架构进行筛选：

uv run --python 3.14 SKILL_DIR/scripts/extract_values.py \
  .scrape/.work/{site_name}/analyze-page/ \
  {site_path}/{data_type}/spec.json \
  --variant {html_variant} \
  -O {site_path}/{data_type}/values/

此操作会从已分析的详情页样本中写入新的提取结果。

Navigation

使用网站 URL、nav_html_variant（由探索过程报告）、爬取的起始 URL，以及描述其必须覆盖范围的纯英文 scope，将固定导航架构写入 {site_path}/navigation/spec.json。覆盖范围应为用户要求的部分；如果用户未要求限制，则覆盖整个网站。

Navigation 值已从探索输出中复制。

Review

浏览器审查

遵循规划期间确定的 browser_review 策略：

• never → 跳转至最终整理阶段。
• always → 无需询问，直接打开审查（见下文）。
• ask → 先告知用户提取统计信息（“已从 {N} 个详情页和 {M} 个导航页提取值。”），然后询问是否要进行浏览器审查（问题“是否打开浏览器审查提取的值？”，标题“浏览器审查”，选项 Skip browser review — “不打开浏览器，直接继续。”和 Open browser review — “在浏览器中审查这些值。”）。后备方案：跳过浏览器审查。如果用户选择 Skip browser review，或无法提问，则进入最终整理阶段。

打开审查：

1. 确保 {site_path}/{data_type}/spec.json 保存的是当前架构 — 审查页面会从该文件读取架构。
2. 运行审查并等待命令完成 — 它会在浏览器中打开审查页面，等待用户提交反馈，打印反馈，然后自动退出：

   uv run --python 3.14 SKILL_DIR/scripts/run_review.py {site_path}/{data_type} .scrape/.work/{site_name} --variant {html_variant}
   

   修改后重新审查时，添加 --changes '["Re-analyzed price across all pages","Dropped field isbn"]'，以便页面显示已完成的操作。

应用反馈

如果用户进行了审查并提供了反馈：

根据事实来源规则应用所有架构变更（删除、重命名、编辑描述、保留字段 → 将来源更改为 "requested"）— 包括在 list_spec_created 为 true 时同步到 {site_path}/{data_type}-list/spec.json。同步后，重新运行列表模式分析子 Agent，使列表值与更新后的架构一致。

如果反馈以 APPROVED 开头：应用其中的架构变更，然后跳转至最终整理阶段。用户已确认。

如果反馈不以 APPROVED 开头（用户点击了“Request changes”）：

• 应用架构变更
• 对于值的更正：使用选定的变体，针对所有详情页重新分析已更正的字段。如果执行环境允许，则为每个页面启动一个子 Agent，并行运行。

重新分析后，重新提取值（“提取值”），并再次提供审查，同时通过 --changes 传入变更摘要。

重复审查阶段，直到用户批准或跳过审查。

最终整理

提交最终计划供用户批准

现在，架构已通过验证 — 覆盖所有详情页，采用选定的 HTML 变体，并包含实际提取的值。按照以下模板向用户提交最终计划和具体 后续步骤。应用“解析意图”中的任何覆盖项，使其预先设置；如果用户要求跳过 此步骤（spider_create = no），则省略“生成爬虫”步骤。

## Scrape plan: {host} → {data_type}

**Target**
- URL: {target_url}
- Data type: {data_type}
- Extraction: {from list pages (all requested fields found there) | from detail pages}
- Site name: `{site_name}`
- Use Zyte API: {yes | no — note if already configured}

**Schema** ({N} fields, validated across {P} pages, variant `{html_variant}`)

Requested:
- `title` (string) — "A Light in the Attic"
- `price` (string) — "£51.77"

Discovered:
- `rating` (integer) — 3
- `category` (string) — "Poetry"
- `description` (string) — "It's hard to imagine a world without…" (2340 chars)
- `upc` (string) — "a897fe39b1053632"

**Next steps**

1. Create the Scrapy project
   - Directory: `{project_dir}`
   - Project: `{project_name}`
2. Generate the extraction code
3. Generate the spider, run it and fix possible issues
4. (Optional) Deploy the spider to Scrapy Cloud and run it there

**Outputs**
- Spec: `.scrape/{site_name}/`
- Project: `{project_dir}/`

如果用户已在浏览器审查中（审查阶段）批准架构，则不要 重新打开字段 — 计划已反映该批准，因此此环节应聚焦于 后续步骤。

询问用户是否批准此计划，或想更改其中的任何内容。

用户批准后，继续生成报告。收到任何调整要求时，应用调整并重新提交：

• 架构变更（删除/保留/重命名/编辑）→ 更新 {site_path}/{data_type}/spec.json
• 范围变更（更换板块、添加筛选条件、更改起始 URL）→ 更新 {site_path}/navigation/spec.json 中的 scope/start_urls
• 跳过爬虫 → 删除“生成爬虫”步骤，并将 spider_create 设为 no
• 设置（项目目录/名称、Zyte、变体）→ 更新对应行

重复此流程，直到用户批准。如果用户预先授权继续（例如“直接保存，不用再确认”），则仅跳过等待：仍需先提交上述计划，然后在同一条消息中直接继续生成报告。

报告

结束此技能时，输出纯文本最终消息，报告规格说明的保存位置以及以下事实。所有值必须反映用户完善后选择的最终方案，而非初始默认值。无论计划以何种方式获批，最终消息都必须先包含最终方案，再附上此报告——计划用于让用户了解后续步骤——而不是对同一组事实进行自由发挥式的总结。

Plan approved. Spec validated and saved to .scrape/{site_name}/.

Details:
- Data types: {comma-separated list, e.g. "product-list, navigation" when list_spec_created, else "product, navigation"}
- Project dir: {project_dir}
- Project name: {project_name}
- Create the spider: {yes | no}
- Start URLs: {comma-separated list}
- Scope: {scope}
- Using Zyte API: {yes | no}

单独调用时（并非从 /scrape 调用），还要告知用户如何继续：针对 Data types 中的每个条目，使用 /scrapy-extra {site_path}/{data_type_entry} {project_dir}，或者使用 /scrape 执行完整工作流。