工具箱包含 12 个 Skill 说明书 + 14 个脚本 + 3 个数据文件模板。三种落地路径：从零建站按 00→64 顺序执行；已有站点改造先跑审计（45–50）定位问题再补；只用工具箱的话核心是 registry.json + 五个审计脚本。

全系列 AI Skills 工具箱汇总：Prompt 合集与使用指南

这是全系列的收口。前面 64 篇讲了方法论、架构、执行和运营，这一篇把所有可复用的资产整理成索引。

一、五层方法论回顾

┌──────────────────────────────────────────────────────┐
│  底座：中央关键词注册表（registry.json）              │
│  唯一事实来源 · 意图隔离 · AI 协作接口                │
└─────────────────────┬────────────────────────────────┘
                      ↓ 驱动架构
┌──────────────────────────────────────────────────────┐
│  骨架：Topic → Pillar → Cluster 拓扑                  │
│  权重自下而上汇聚 · 意图自上而下分流                   │
└──────┬───────┬───────────┬───────────┬───────────────┘
       ↓       ↓           ↓           ↓
   ┌───────┐┌────────┐┌─────────┐┌─────────┐
   │ pSEO  ││Digital ││  EEAT   ││  GEO    │
   │ 肉体  ││PR 磁铁 ││  灵魂   ││  接口   │
   └───────┘└────────┘└─────────┘└─────────┘
       ↓       ↓           ↓           ↓
┌──────────────────────────────────────────────────────┐
│  运营：12 个 AI Skill（审计 6 + 辅助 6）              │
└──────────────────────────────────────────────────────┘

核心公式：注册表（底座）+ Pillar-Cluster（骨架）+ pSEO（肉体）+ Digital PR & EEAT（灵魂）+ GEO（接口）= 高权重 B2B 数字资产

二、脚本清单（14 个）

全部脚本放在项目的 scripts/ 目录下。

审计类（6 个）

生产类（6 个）

Schema 与增长类（2 个）

package.json 快捷命令

{
  "scripts": {
    "seo:lint": "node scripts/registry-lint.mjs",
    "seo:coverage": "node scripts/coverage-audit.mjs",
    "seo:links": "npm run build && node scripts/link-flow-audit.mjs",
    "seo:geo": "npm run build && node scripts/geo-audit.mjs",
    "seo:schema": "node scripts/schema-generate.mjs && node scripts/schema-validate.mjs",
    "seo:health": "npm run build && node scripts/health-report.mjs",
    "seo:discover": "node scripts/discover-new-keywords.mjs",
    "seo:calendar": "node scripts/content-calendar.mjs",
    "seo:all": "npm run seo:lint && npm run seo:schema && npm run seo:links && npm run seo:geo"
  }
}

三、数据文件模板（3 个）

这三个文件是整套体系的事实来源，必须提交到 Git。

registry.json（第 01 篇）

[
  {
    "keyword": "centrifugal pump manufacturer",
    "intent_type": "commercial",
    "page_slug": "/products/centrifugal-pumps/",
    "page_type": "pillar",
    "pkw": "centrifugal pump manufacturer",
    "skw": ["centrifugal pump supplier", "industrial centrifugal pump OEM"],
    "nkw": ["what is", "how does", "repair", "free", "DIY", "CP-100"],
    "priority": 5,
    "target_locale": ["en-US", "en-GB"],
    "monthly_volume": 880,
    "difficulty": 42,
    "current_rank": null,
    "status": "active",
    "category": "centrifugal",
    "last_audited": "2026-08-04",
    "notes": ""
  }
]

src/data/entities.yaml（第 55 篇）

Organization + Persons 的完整实体信息，同时充当第 39 篇要求的 NAP 标准。

src/data/applications.yaml（第 28 篇）

pSEO 的场景数据源。每个场景至少 3 条 challenges、3 条 keySelectionCriteria、2 个 industryStandards——这是第 54 篇数据层预检的门槛。

四、十二个 Skill 索引

审计体系（第 45–50 篇）

辅助体系（第 51–56 篇）

贯穿全部 Skill 的设计原则：

确定性的事交给脚本，需要判断的事交给模型，中间用一份写死了判定规则和输出格式的说明书连接。

这个原则来自站内已有的 SEO Skills 系列，在这 12 个 Skill 里保持一致。

五、三种落地路径

路径 A：从零建站（按顺序执行）

阶段 1｜规划（第 00–10 篇，约 1 周）
  □ 读方法论总览（00）
  □ 设计注册表字段（01）
  □ 用 AI 建初始注册表，MVP 20–30 行（02）
  □ 填 NKW（03）
  □ 设计 Pillar-Cluster 拓扑（05–10）
  产出：registry.json + 页面架构图

阶段 2｜基建（第 11–14 篇，约 2 天）
  □ 域名 + Cloudflare DNS（11）
  □ 企业邮箱（12）+ SPF/DKIM/DMARC（13）
  □ 确认技术选型（14）

阶段 3｜开发（第 15–21 篇，约 2 周）
  □ 品牌视觉（15）
  □ Astro 项目 + 设计系统（16）
  □ Pillar 和 SKU 页模板（17）
  □ 英文内容（18）
  □ 询盘表单（19）+ WhatsApp（20）
  □ 性能优化（21）

阶段 4｜上线（第 22–26 篇，约 2 天）
  □ CF Pages 部署（22）
  □ 安全响应头（23）+ 隐私政策（24）
  □ GA4 + GSC + Bing（25）
  □ 监控告警（26）
  ⚠️ 此时应能收到测试询盘

阶段 5｜四大引擎（第 27–44 篇，持续 2–3 个月）
  □ pSEO 批量场景页（27–31）
  □ Digital PR 第一个资产（32–35）
  □ EEAT 实体绑定（36–39）
  □ GEO 结构优化（40–44）

阶段 6｜运营体系（第 45–64 篇，持续）
  □ 部署 12 个 Skill 的脚本
  □ 配置第 63 篇的三层自动化
  □ 进入第 62 篇的季度循环

关键时间点：阶段 4 结束时网站已经可用并能收询盘。阶段 5 之后才是增长——不要在阶段 5 完成前一直不上线。

路径 B：已有站点改造（先诊断后动手）

如果你已经有一个外贸站，不要从第 00 篇开始重建。先诊断。

第 1 步｜建注册表（反向工程，约半天）
  用第 46 篇的覆盖度审计思路，但反向做：
  □ 导出站点所有页面 URL（从 sitemap）
  □ 对每个页面，判断它当前实际在争什么词（看 GSC 数据）
  □ 反向填入 registry.json（这是"现状注册表"）
  □ 跑 npm run seo:lint → 大概率会发现一批 error

第 2 步｜跑全套审计（第 45–50 篇，约半天）
  □ npm run seo:all
  □ 导出 GSC 数据，跑 Cannibalization 诊断（47）
  □ 生成健康度报告（50）
  产出：四个指标的当前值 + 问题清单

第 3 步｜按 ROI 修复（1–2 周）
  优先级顺序：
  1. GEO 致命项（robots 屏蔽 / 客户端渲染）
  2. 注册表 error（唯一性冲突）
  3. 已确认的 Cannibalization
  4. 内链断流的 Cluster
  5. 未纳管页面

第 4 步｜补齐缺失的层（按诊断结果）
  □ 如果没有 Pillar-Cluster 结构 → 读 05–10，重构架构
  □ 如果 GEO 就绪度低 → 读 40–44，改 FAQ 和参数表
  □ 如果外链少 → 读 32–35，做第一个 Digital PR 资产
  □ 如果 EEAT 弱 → 读 36–39，补实体信息和 Schema

第 5 步｜进入常规运营
  同路径 A 的阶段 6

改造的关键判断：如果现有站是 WordPress 且内容量大，不一定要迁移到 Astro。第 14 篇的选型逻辑是给新站的；已有站点先解决 SEO 结构问题，技术栈迁移是另一个话题。

路径 C：只用 Skills 工具箱

如果你不需要整套方法论，只想用这些审计工具管理现有站点：

最小可用集：
  1. registry.json（哪怕只有 20 行核心页面）
  2. scripts/registry-lint.mjs
  3. scripts/coverage-audit.mjs
  4. scripts/link-flow-audit.mjs
  5. scripts/geo-audit.mjs

执行：
  npm run seo:all

这四个脚本能回答：
  - 我的关键词规划有冲突吗？
  - 哪些词还没有页面？哪些页面没纳管？
  - 我的内链在传递权重吗？
  - AI 搜索能看到我的内容吗？

不需要读完 65 篇——读第 01 篇（注册表设计）和第 45–49 篇（四个审计 Skill）就够用。

六、执行频率总表

每季度的固定投入约 5–7 小时（集中在季度首周），其余时间用于执行内容产出。

七、常见的落地失败原因

按发生频率排列，都是可以提前避免的。

1. 注册表建了但不执行

最常见。建完 registry.json 之后，新建页面时凭感觉写 H1，不查注册表。

对策：把 npm run seo:lint 加进 CI（第 63 篇第 1 层），让它成为强制门槛。

2. pSEO 批量生成了低质量页面

数据层没差异化就开始批量生成，50 个页面高度相似，被判低价值。

对策：第 54 篇的数据层预检和 shingle 检测不能跳过。宁可先花两小时补数据。

3. 内链缺失导致权重空转

Digital PR 拿到了外链，但 Cluster 页没有指向 Pillar 的精准锚文本内链，权重停在 Cluster 层。

对策：第 48 篇的内链流审计加进周检查。

4. GEO 做了但被 robots.txt 屏蔽

FAQ 和参数表都按规范改了，但 robots.txt 屏蔽了 AI 爬虫，全部努力归零。

对策：第 49 篇的致命项检查放在最前，且在 CI 里阻断。

5. 上线前想做完所有优化

想把四大引擎全部做完才上线，结果半年没上线。

对策：按路径 A 的阶段 4 结束就上线。四大引擎是上线后持续做的。

6. 每周都在重新规划

每周花时间想“这周写什么”，实际产出很少。

对策：第 62 篇的季度循环——规划集中在季度首周做完，剩下 11 周只执行。

八、全系列 65 篇索引

九、最后一句

这套方法论的价值不在于任何单一技巧，而在于它把外贸站建设从“凭经验做”变成了“有约束、可审计、可持续”的工程。

注册表约束了关键词归属，Pillar-Cluster 约束了页面结构，四大引擎提供了增长手段，12 个 Skill 保证了这些约束不会随时间腐化。

门槛不高，但需要执行。哪怕只做到底座 + 骨架 + 审计三件事——20 行注册表、清晰的 Pillar-Cluster 结构、每次建页前跑一次 lint——你的站点结构就已经比大多数外贸站更健康。