Back to Details

fetching-salesforce-docs

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

fetching-salesforce-docs

fetching-salesforce-docs

Use this skill to retrieve and ground answers in official Salesforce documentation on the public web.
This skill provides a reliable online retrieval playbook for Salesforce docs that are hard to fetch, especially 
help.salesforce.com
, JS-heavy 
developer.salesforce.com
, Lightning Design System docs on 
lightningdesignsystem.com
, and other official Salesforce-owned doc pages such as 
architect.salesforce.com
and 
admin.salesforce.com
.
Optional extraction scripts are available in 
scripts/
— see the Reference File Index below.
使用此技能可检索并基于公开网络上的官方Salesforce文档给出答案。
本技能为难以抓取的Salesforce文档提供了一套可靠的在线检索方案，尤其是
help.salesforce.com
、包含大量JS的
developer.salesforce.com
、
lightningdesignsystem.com
上的Lightning Design System文档，以及其他Salesforce自有官方文档页面，如
architect.salesforce.com
和
admin.salesforce.com
。
scripts/
目录下提供了可选的提取脚本——请参阅下方的参考文件索引。

Scope

适用范围

In scopeOfficial Salesforce doc retrieval: Apex, API, LWC, metadata, Agentforce, setup articles, SLDS, architect/admin guidance
Out of scopeThird-party blogs, PDF fallback, local corpus indexing, benchmark workflows, generating code or metadata
适用场景官方Salesforce文档检索：Apex、API、LWC、元数据、Agentforce、设置文章、SLDS、架构师/管理员指南
不适用场景第三方博客、PDF备用方案、本地语料库索引、基准测试流程、生成代码或元数据

Required Inputs

必要输入

Before fetching, identify:
  • The exact concept, identifier, class, method, or feature name being requested
  • The likely doc family (developer docs, help articles, design system, architect/admin)
No additional setup is required to use the retrieval playbook in this skill. The optional extraction scripts require 
playwright
— see 
requirements.txt
.
在抓取前，请确定：
  • 被请求的具体概念、标识符、类、方法或功能名称
  • 文档所属的可能类别（开发者文档、帮助文章、设计系统、架构师/管理员文档）
使用本技能中的检索方案无需额外配置。可选的提取脚本需要
playwright
——请查看
requirements.txt
。

Official Sources Only

仅使用官方来源

Prefer Salesforce-owned documentation sources:
  • developer.salesforce.com
  • help.salesforce.com
  • architect.salesforce.com
  • admin.salesforce.com
  • lightningdesignsystem.com
  • other official Salesforce documentation pages when Salesforce uses them as the source of truth
Avoid third-party blogs, videos, or summary articles unless the user explicitly asks for them.
Do not fall back to PDFs.
优先选择Salesforce自有文档来源：
  • developer.salesforce.com
  • help.salesforce.com
  • architect.salesforce.com
  • admin.salesforce.com
  • lightningdesignsystem.com
  • 其他Salesforce用作事实来源的官方文档页面
除非用户明确要求，否则避免使用第三方博客、视频或摘要文章。
请勿退而求其次使用PDF。

Retrieval Workflow

检索流程

1. Classify the request first

1. 先对请求进行分类

Before fetching anything, identify the likely doc family.
FamilyTypical SourceUse For
Developer docs
developer.salesforce.com/docs/...
Apex, APIs, LWC, metadata, Agentforce developer docs
Help docs
help.salesforce.com/...
setup, admin, product configuration
Architect/Admin docs
architect.salesforce.com/...
, 
admin.salesforce.com/...
best practices, patterns, well-architected guidance, admin enablement
Design system docs
lightningdesignsystem.com/...
SLDS, Cosmos, design tokens, component and styling guidance
Legacy atlas docs
developer.salesforce.com/docs/atlas.en-us.*
older official guide and reference docs
在抓取任何内容之前，确定文档所属的可能类别。
类别典型来源适用场景
开发者文档
developer.salesforce.com/docs/...
Apex、API、LWC、元数据、Agentforce开发者文档
帮助文档
help.salesforce.com/...
设置、管理员操作、产品配置
架构师/管理员文档
architect.salesforce.com/...
、
admin.salesforce.com/...
最佳实践、模式、架构设计指南、管理员赋能
设计系统文档
lightningdesignsystem.com/...
SLDS、Cosmos、设计令牌、组件和样式指南
旧版atlas文档
developer.salesforce.com/docs/atlas.en-us.*
较旧的官方指南和参考文档

2. Identify the exact concept

2. 确定具体概念

Extract the real target before you search:
  • exact API/class/method name
  • exact feature name
  • exact product phrase
  • exact setup concept
Examples:
  • Lightning Message Service
  • Wire Service
  • System.StubProvider
  • Agentforce Actions
  • Messaging for In-App and Web allowed domains
在搜索前提取真正的目标：
  • 准确的API/类/方法名称
  • 准确的功能名称
  • 准确的产品术语
  • 准确的设置概念
示例：
  • Lightning Message Service
  • Wire Service
  • System.StubProvider
  • Agentforce Actions
  • Messaging for In-App and Web allowed domains

3. Prefer targeted official retrieval

3. 优先使用针对性的官方检索

Do not broad-crawl Salesforce docs.
Instead:
  1. identify the most likely official guide root or article
  2. if search is needed, restrict it to official Salesforce domains only
  3. fetch that official page
  4. check whether the exact concept actually appears on the page
  5. if not, inspect and follow the most relevant 1–3 official child links
  6. stop once you have grounded evidence
请勿对Salesforce文档进行广泛爬取。
正确做法：
  1. 确定最可能的官方指南根页面或文章
  2. 如果需要搜索，仅限制在Salesforce官方域名内
  3. 抓取该官方页面
  4. 检查具体概念是否确实出现在页面上
  5. 如果未找到，检查并跟随最相关的1-3个官方子链接
  6. 一旦获取到可靠依据即停止

4. Do not stop at broad landing pages

4. 不要停留在宽泛的着陆页

A guide landing page is not enough unless it clearly contains the exact requested concept.
This is especially important for:
  • LWC docs
  • Agentforce docs
  • broad platform guide homepages
  • help landing pages that link to the real article
指南着陆页不足以作为回答依据，除非它明确包含所请求的具体概念。
这一点在以下场景中尤为重要：
  • LWC文档
  • Agentforce文档
  • 宽泛的平台指南首页
  • 链接到真实文章的帮助着陆页

5. For 
developer.salesforce.com

5. 针对
developer.salesforce.com
的处理

Use this playbook:
  • start with the most likely official guide root
  • if the page is JS-heavy, prefer browser-rendered extraction
  • check whether the exact concept appears on the page
  • if the concept is missing, inspect official child links and follow the best matching 1–3 links
  • prefer exact concept pages over broad guide roots
  • legacy atlas pages are valid if they are the real official reference for the concept
使用以下方案：
  • 从最可能的官方指南根页面开始
  • 如果页面包含大量JS，优先使用浏览器渲染提取
  • 检查具体概念是否出现在页面上
  • 如果未找到概念，检查官方子链接并跟随最匹配的1-3个链接
  • 优先选择具体概念页面而非宽泛的指南根页面
  • 如果旧版atlas页面是该概念的真正官方参考，则可使用

6. For 
help.salesforce.com

6. 针对
help.salesforce.com
的处理

Help pages often fail with naive fetching.
Use this playbook:
  • prefer exact 
    articleView?id=...
    URLs when available
  • use browser-rendered extraction when plain fetch returns shell content
  • treat outputs like 
    Loading
    , 
    Sorry to interrupt
    , 
    CSS Error
    , or mostly chrome/navigation text as failed extraction, not evidence
  • look for the real article body, not just header, nav, or footer text
  • reject shell pages and soft-404 pages such as:
    • "We looked high and low but couldn't find that page"
    • generic empty help shells
  • if starting from a nearby guide or hub page, follow linked Help articles until you reach the real article body
  • if extraction still fails after targeted retries, return the best official Help URLs you found and explicitly say that article-body extraction was unsuccessful
帮助页面通常难以通过普通抓取方式获取内容。
使用以下方案：
  • 如果有可用的准确
    articleView?id=...
    URL，优先使用
  • 当普通抓取返回shell内容时，使用浏览器渲染提取
  • 将
    Loading
    、
    Sorry to interrupt
    、
    CSS Error
    等输出，或主要为导航/框架文本的内容视为提取失败，而非有效依据
  • 寻找真实的文章主体，而非仅标题、导航或页脚文本
  • 拒绝shell页面和软404页面，例如：
    • "我们四处查找但未找到该页面"
    • 通用的空帮助shell页面
  • 如果从附近的指南或中心页面开始，跟随链接的帮助文章直到找到真实的文章主体
  • 如果经过针对性重试后提取仍失败，返回找到的最佳官方帮助URL，并明确说明文章主体提取未成功

Acceptance Rules

验收规则

A page is good enough to answer from only when at least one of these is true:
  • the exact identifier appears on the page
  • the exact concept phrase appears on the page
  • multiple query-specific phrases appear in the correct official context
A page is not good enough when:
  • it is only a broad landing page
  • it is a shell page with little real article text
  • it is from the wrong product area
  • it does not contain the requested identifier or concept
  • it is a third-party explanation when an official page should exist
只有满足以下至少一个条件时，页面才足以作为回答依据：
  • 页面上出现准确的标识符
  • 页面上出现准确的概念术语
  • 多个与查询相关的术语出现在正确的官方语境中
以下情况页面不足以作为回答依据：
  • 仅为宽泛的着陆页
  • 是几乎没有真实文章文本的shell页面
  • 来自错误的产品领域
  • 不包含请求的标识符或概念
  • 在官方页面存在的情况下使用第三方解释

Rejection Rules

拒绝规则

Reject these as final evidence:
  • broad guide homepages without the exact concept
  • release notes when a concept/reference page is expected
  • admin blog posts when developer docs are requested
  • third-party blogs when official docs are available
  • shell-rendered pages with no real article body
  • pages whose titles sound right but whose body does not contain the requested concept
拒绝将以下内容作为最终依据：
  • 不包含具体概念的宽泛指南首页
  • 在需要概念/参考页面时使用发布说明
  • 在需要开发者文档时使用管理员博客文章
  • 在官方文档可用时使用第三方博客
  • 没有真实文章主体的shell渲染页面
  • 标题看似正确但主体不包含请求概念的页面

Grounding Requirements

依据要求

When answering, include:
  1. guide/article title
  2. exact official URL
  3. source type:
    • developer doc page
    • atlas reference page
    • help article page
  4. any caveat if extraction was partial or browser-rendered
If evidence is weak, say so plainly.
回答时需包含：
  1. 指南或文章标题
  2. 准确的官方URL
  3. 来源类型：
    • 开发者文档页面
    • atlas参考页面
    • 帮助文章页面
  4. 若提取内容不完整或使用了浏览器渲染，需说明相关注意事项
如果依据不足，请直接说明。

Examples

示例

Example: Lightning Message Service

示例：Lightning Message Service

Do not stop at the general LWC guide root. Find the exact LWC page for Lightning Message Service or follow the most relevant child links from the LWC docs until the exact concept appears.
请勿停留在通用LWC指南根页面。 找到Lightning Message Service的准确LWC页面，或从LWC文档中跟随最相关的子链接，直到出现具体概念。

Example: Wire Service

示例：Wire Service

Do not answer from the LWC homepage unless 
Wire Service
is actually present there. Follow the relevant child doc page for wire service or wire adapters.
除非
Wire Service
确实出现在LWC首页上，否则请勿基于该页面回答。 跟随wire service或wire适配器的相关子文档页面。

Example: Agentforce Actions

示例：Agentforce Actions

Do not answer from a broad Agentforce landing page or a blog post. Find the official Agentforce developer page for actions, or follow the best matching child pages from the official Agentforce docs.
请勿基于宽泛的Agentforce着陆页或博客文章回答。 找到Agentforce操作的官方开发者页面，或从官方Agentforce文档中跟随最匹配的子页面。

Example: Messaging for In-App and Web allowed domains

示例：Messaging for In-App and Web allowed domains

Prefer official Help articles and browser-rendered extraction. Reject generic help shells. Follow linked Help articles from nearby official messaging docs if needed.
优先使用官方帮助文章和浏览器渲染提取。 拒绝通用的帮助shell页面。必要时从附近的官方消息文档中跟随链接的帮助文章。

Example: System.StubProvider

示例：System.StubProvider

Prefer the official Salesforce reference/developer page where the exact identifier appears. Do not substitute a broader Apex landing page if the identifier is absent.
优先选择出现准确标识符的官方Salesforce参考/开发者页面。 如果标识符不存在，请勿使用更宽泛的Apex着陆页替代。

Non-Goals

非目标

This skill should not:
  • maintain a local documentation corpus
  • rely on a local index
  • use PDF fallback
  • run benchmark workflows
  • depend on repo-specific scripts to be useful
本技能不应：
  • 维护本地文档语料库
  • 依赖本地索引
  • 使用PDF备用方案
  • 运行基准测试流程
  • 依赖特定仓库的脚本才能发挥作用

Output Expectations

输出预期

For each retrieval, include:
  1. Guide or article title
  2. Exact official URL
  3. Source type (developer doc page / atlas reference page / help article page)
  4. Any caveat if extraction was partial or browser-rendered
If evidence is weak, say so plainly rather than forcing an answer.
每次检索需包含：
  1. 指南或文章标题
  2. 准确的官方URL
  3. 来源类型（开发者文档页面 / atlas参考页面 / 帮助文章页面）
  4. 若提取内容不完整或使用了浏览器渲染，需说明相关注意事项
如果依据不足，请直接说明，而非强行给出答案。

Reference File Index

参考文件索引

FileWhen to read
scripts/extract_salesforce_doc.py
Use to fetch any official Salesforce doc URL; automatically routes 
help.salesforce.com
into the dedicated Help extractor and supports browser-rendered extraction for all Salesforce-owned doc hosts
scripts/extract_help_salesforce.py
Use directly when targeting 
help.salesforce.com
articleView
URLs; use when the wrapper is not appropriate
scripts/runtime_bootstrap.py
Imported by the extraction scripts to resolve the isolated fetching-salesforce-docs Python runtime and Playwright browser path; not called directly
requirements.txt
Lists Python dependencies (
playwright
, 
playwright-stealth
) needed to run the extraction scripts
文件阅读时机
scripts/extract_salesforce_doc.py
用于抓取任何官方Salesforce文档URL；自动将
help.salesforce.com
路由到专用的帮助提取器，并支持所有Salesforce自有文档主机的浏览器渲染提取
scripts/extract_help_salesforce.py
直接用于定位
help.salesforce.com
的
articleView
URL；当包装器不合适时使用
scripts/runtime_bootstrap.py
由提取脚本导入，用于解析独立的fetching-salesforce-docs Python运行时和Playwright浏览器路径；不直接调用
requirements.txt
列出运行提取脚本所需的Python依赖（
playwright
、
playwright-stealth
）