mcpField
C
cargo-gtm

cargo-gtm

github.com/getcargohq营销与增长2110.2k 次安装2 天前更新
代码仓库

关于 cargo-gtm

cargo-gtm 是用于 B2B 销售与营销流程的 Cargo 技能，面向潜在客户发现、研究和触达准备。它提供分阶段的操作指南，并以合规检查、费用审批和不代发消息为约束。

主要功能

  1. 01指导公司与联系人搜寻
  2. 02支持资料补全与信号研究
  3. 03提供评分和个性化流程
  4. 04按任务路由至操作指南
  5. 05内置合规与费用门槛

适用场景

  1. 01按理想客户画像建立潜客名单
  2. 02补全并验证联系人资料
  3. 03监测职位变动或融资信号
  4. 04准备个性化文案并交接发送

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/getcargohq/cargo-skills --skill cargo-gtm

安装后在 Claude Code 中输入/cargo-gtm确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

agents/
execution-plan-creator.md
list-builder.md
guides/
enriching-and-researching.md
finding-companies-and-contacts.md
writing-outreach.md
provider-playbooks/
aiArk.md
anthropic.md
apolloio.md
bounceban.md
bouncer.md
brightData.md
builtwith.md
cargoSignals.md
cleon1.md
companyEnrich.md
contactOut.md
datagma.md
dropcontact.md
enrichCrm.md
enrichley.md
enrowio.md
exa.md
explorium.md
findyMail.md
firecrawl.md
forager.md
FullEnrich.md
g2.md
gemini.md
hunter.md

详细介绍

Cargo GTM — Meta 技能

使用此技能进行客户开发、账户研究、联系人信息补充与验证、潜在客户评分、个性化、信号监控和营销活动启动。

可接受的使用方式 — 在进行任何涉及个人的操作之前，必须遵守

完整规范：references/acceptable-use.md。以下简要说明适用于本文中的所有操作方案，且具有约束力：

  • 仅限 B2B 专业身份，且必须来自 provider-playbooks/ 中获得许可的提供商——不得以消费者为目标、不得使用购买的名单，也不得使用违反平台条款取得的数据。
  • 执行任何外联步骤前必须通过三项检查——依据（客户、已同意接收信息的联系人、活动参与者，或有记录的合法利益案例）、抑制名单（在补充信息或发送之前，筛除已退订／DNC／硬退信的记录）、相关性（针对每位收件人，说明为何这条消息适合对方）。任何一项检查未通过，都必须停止并询问，而不是仅作警告。
  • 拒绝并说明原因：不加区分地批量发送（“给 <industry> 里的所有人发邮件”）、联系已在抑制名单中的记录、规避筛选或伪装发件人身份、自动拨号和批量发送短信、批量执行 LinkedIn 互动操作、通过用户的 X 账户 (xAccount) 批量或自动发布／回复／点赞／发送私信。只提供一次合规替代方案——说明即可，不要说教。
  • **此技能绝不发送消息。**外联操作方案只会准备好可直接用于发送的变量，并将后续工作交给用户自己的序列工具，且必须遵守该工具的限制、域名和身份要求。它起草的文案必须使用真实的发件人和主题，提供有效的退订方式，并在适用司法管辖区要求时附上邮寄地址。

初始化

如果已登录（cargo-ai whoami 返回工作区），请跳到下一节。

npm install -g @cargo-ai/cli            # no global install? prefix every command with `npx @cargo-ai/cli`
cargo-ai login --email [email protected]  # emailed code, no browser; creates the account on first use
                                        # alternatives: --oauth (browser) · --token <api-token> (CI)
cargo-ai whoami                         # confirm the active workspace before any write

每条命令都会向标准输出打印 JSON；失败时以非零状态码退出，并返回 {"errorMessage": "..."}。任何会创建运行任务或批次的操作都是异步的——请传入 --wait-until-finished，或轮询匹配的 get 命令。安装完整技能包后，../cargo/references/prerequisites.md 会补充 CLI 版本固定、令牌作用域和仅限管理员使用的功能。

1) 此技能的适用范围

  • 在执行之前，为 GTM 决策、安全关卡和提供商／质量默认设置提供指引。
  • 将较长的命令链和工具使用细节放在子文档中；将提供商特定的实现细节放在 provider-playbooks/*.md 中。
  • 以基于积分的操作（高价值操作调用）为操作方案提供依据。免费 CRUD（createLead、getLead、deleteRecords）无需此技能——Agent 可以按需自行组合。
流程／目标

用户通常希望从“我有一个 ICP”推进到“这是一份包含已验证邮箱和个性化信号的潜在客户名单”。他们可能处于流程中的任何阶段——请引导他们逐步推进。

**发现顺序：先公司，后人员。**当任务要求寻找符合特定条件（投资组合、ICP、招聘信号）的公司中的联系人时，先确定公司集合，再在每家公司中寻找人员。不要从宽泛的人员搜索查询开始。

文档层级

2）读取行为 — 执行前必须完成

停止。打开与你的任务对应的子文档之前，不得调用任何提供商、运行任何 cargo-ai orchestration action execute 命令，也不得编写任何搜索查询。

这些文档说明了哪些做法有效、哪些会失败以及原因。文档中包含经过验证的参数架构、成本最低的提供商映射、并行执行模式、示例载荷和已知陷阱。花 10 秒阅读正确的文档，可以避免 10 次失败的操作调用、浪费额度和产出无用结果。

路由规则 — 根据任务查找对应文档并阅读
任务涉及……你必须先阅读此文档文档内容
查找公司、查找人员、建立潜在客户名单、客户开发、投资组合/VC 寻源、查找已知公司的联系人guides/finding-companies-and-contacts.md提供商筛选条件架构、最低成本来源决策树、并行模式、基于角色的搜索规则、投资组合/VC 快捷方式、联系人查找模式。
丰富公司或联系人信息、查找电子邮件/电话/LinkedIn、瀑布式丰富、查询信号（职位变动、融资、技术栈）、合并数据guides/enriching-and-researching.md带备用链的瀑布式模式、何时使用 aiArk、waterfall、FullEnrich 或 peopleDataLabs、电子邮件/电话/LinkedIn 备用顺序、信号细分，以及通过 run download-outputs 获取输出。
撰写首次联系的外联内容、个性化消息、潜在客户评分、资格评估、序列设计、营销活动文案guides/writing-outreach.md + references/acceptable-use.md（§3 检查、阻止条件）LLM 提供商路由（openAi/anthropic/perplexity/gemini）、提示词模板、评分标准、电子邮件长度/语气规则、个性化模式 — 需满足法律依据、抑制名单和收件人相关性要求。
实际从 Cargo 管理的邮箱发送已撰写的文案（而非交给用户自己的序列工具）../cargo-mailbox-management/SKILL.md + references/acceptable-use.md（§3 检查、阻止条件）邮箱配置与预热、限制发送量的 5→40 封/天发送递增方案、sendEmail 操作（每次发送消耗 0.1 个额度）、工作区抑制名单，以及将回复/打开/点击记录为事件。
构建或修改周期性工作流（cron / webhook / 定时工具 / play）、设计步骤序列、触发器、部署/验证周期../cargo-orchestration/SKILL.md（功能）+ 本技能配方中的应用模式 + provider playbook（每个付费节点都要阅读）（§11，尤其是其中的 Recurring use 部分）工具/play 工作流架构、节点图语法、轮询策略、输出获取方式；以及各提供商默认调用频率和重新计费门槛。
配方：分步操作手册（执行前先查看）

浏览此列表并阅读与你的任务匹配的配方。如果有匹配的配方，请按步骤将其作为执行计划。

配方适用场景…
recipes/source-planning.md如果数据源不明确，请先阅读。 将问题转化为一个字段，在 5–10 行数据上试探 2–3 个候选数据源，并展示每次命中的成本 — 在任何扇出之前
recipes/prospecting.md端到端执行查找 → 补充信息 → 验证 → 同步（P1/P2/P3 变体）
recipes/build-tam.md大规模构建总可寻址市场（Total Addressable Market）名单（100–10,000 家公司）
recipes/linkedin-url-lookup.md根据姓名和公司查找某人的 LinkedIn 个人资料 URL，并严格验证身份
recipes/portfolio-prospecting.md投资者 / 加速器 → 投资组合公司 → 联系人
recipes/job-change-monitoring.md对联系人细分群体运行 waterfall.detectJobChange（cargo-unique）
recipes/funding-watch.md跟踪近期获得融资的公司
recipes/tech-intent.md根据技术栈或招聘意向信号查找公司
recipes/icp-discovery.md对比 Closed-Won 与 Closed-Lost 细分群体，挖掘 ICP 信号
recipes/custom-datapoints.md为卖家的 ICP 设计要收集的自定义属性和实时信号 — 先根据目录评估可行性，再将其接入列、评分、细分群体和刷新频率
recipes/outreach-activation.md将信号细分群体转化为可直接发送的外联内容（补充信息 → 验证 → 个性化 → 移交序列工具）
recipes/ads-audience-activation.md将细分群体推送到付费媒体 — Google Ads Customer Match 或 LinkedIn Matched Audiences — 并查看匹配率
recipes/review-and-iterate.md需要人工审核的判断结果 — 交接表格、分组更正、永久修复，并作为评估集保留
recipes/re-engagement.md仅在触发新信号（职位变动、融资、技术意向）时唤醒过期联系人
recipes/lost-deal-revival.md根据 lost_reason（关键支持者离职、预算、时机）分支处理 CRM 中 Closed-Lost 的交易，推动其重启
recipes/account-expansion.md对现有客户账户进行多线程拓展 — 寻找全新买家，并与工作区的 Contacts 模型进行去重
recipes/save-as-play.md将成功的临时运行转化为可持久执行的定时 play 或 cron 工具 — 对任何可重复的拉取操作都应提供此选项
recipes/import-gtm-data.md将现有 GTM 数据（来自任何工具的 CSV/CRM 导出文件）导入模型，对其进行 QA 审核，并有选择地将重复逻辑重建为 play，同时进行一致性检查
recipes/clay-to-cargo.md专用于 Clay：导出列配置（而非 CSV）、列类别 → 操作映射、四种无法一一对应的 Clay 概念（水位线、运行条件、自动更新、部分运行），以及与 Clay 自身输出的一致性检查

如果都不适用，请扫描上方的阶段文档，寻找最接近的模式并加以调整 — 或调用 agents/execution-plan-creator.md，使用提供商 / 操作 slug 和成本估算来组合自定义链路。对于会扇出的广泛数据源扫描（按行业、按地区），请将获批的切片委派给 agents/list-builder.md — 它会对每个切片严格执行一项预先批准的操作，并将行数据返回到文件中，使主上下文不包含行数据。（在带有该插件的 Claude Code 上，两者都作为原生子 Agent 安装：cargo-execution-planner 和 cargo-list-builder。）

3) 成本控制 — 强制关卡

完整规范：references/cost-discipline.md。每项任务都必须遵守的精简版：

  1. 先抽样 → 再审批 → 最后完整运行，顺序不可颠倒。 先对确切输入运行一个切片——1–3 行，用于验证某项操作的配置；任何批处理前先处理 10–20 条记录（单行无法体现命中率）。然后展示 4 部分审批消息（假设 · 原样呈现样本结果 · 积分/范围/上限——始终说明完整运行会纳入多少条记录以及费用是多少，并与实际余额核对 · 3 个具体选项）；在用户作出选择前，始终保持 AWAIT_APPROVAL 状态。未经审批或费用未知的操作，绝不能大规模展开；也绝不能将用户对样本的审批视为对完整数据范围的审批。
  2. 每次付费操作后都提供收据：已花费积分 + 剩余余额 + 命中率（“找到 34 个邮箱，共 40 条记录”）+ 预估与实际的对比，以及存在差异时的原因。优先使用 billing usage get-metrics，而不是自行计算。
  3. 按 1.4×N 超量配置，然后筛选——覆盖率取决于公司本身；应舍弃不完整的行，而不是再用更多服务商追查。
  4. 先计数，再付费——搜索按返回的行数计费；严格设置 limit，并在完整提取前用 1 行探测来确定数据池大小。
  5. 手机号是受控的手段——仅在用户明确要求时，对符合条件的潜在客户使用。即使是低价方案也一样：aiArk.findMobilePhone（0.5，仅限手机号）是第一步，未命中时费用为 0；但后续升级会花费 3–7 个积分（约为邮箱的 10 倍），因此对完整名单进行手机号扫描也必须像其他任何付费批量操作一样获得审批。

4) 每次运行后 — 先提供收据，再给出有据可依的下一步

每次运行完成后，都以收据（见上文）收尾，然后提出最多 2–3 个下一步选项，且必须根据刚生成的数据制定——绝不能给出泛泛的菜单。必须符合以下格式：

  1. 保持连贯——基于本次会话产出的内容（“这 70 家公司中有 67 家设有 RevOps 团队——要查找相关潜在客户吗？”），而不是重新提出泛泛的想法。
  2. 考虑预算——结合剩余余额说明（“你还剩约 9 个积分，可查找约 5 个已验证的邮箱”）。
  3. 说明单项成本——“邮箱瀑布流程每个约需 1.4 个积分。”
  4. 给出默认筛选启发式，让用户只需回答一个词（“我默认推荐：有融资数据 + 至少 2 个 RevOps 人员 + 近期发布内容”）。
  5. 提供其他选择——结尾始终写上“或者其他任何想法”。

如果某次运行产出了可长期重复使用的结果，建议中应包含将其系统化——参见 recipes/save-as-play.md。

如果运行或批处理出现异常——报错、缺少下游值、费用意外——请交由 cargo-diagnostics 技能处理（../cargo-diagnostics/SKILL.md）：在再次进行任何付费运行前，先全面排查批处理的根本原因。计划审批、具体选项和结果呈现的交互默认规则见 ../cargo/references/interaction.md。

5) 优先服务商栈（配方优先使用以下 7 个）

这 7 个基于积分的服务商以目录中最低的积分成本，覆盖从潜在客户挖掘 → 信息补全 → 验证 → 信号的完整流程。本技能 recipes/ 中的每个配方都优先使用此服务商栈：

提供商角色关键操作（积分成本）
salesNavigator寻源searchLeads（0.2）、searchAccounts（0.2）、findCompanyInsights/Metrics/EmployeesCount/Distribution（各 0.25）
aiArk基于 LinkedIn 的丰富数据 + 最低成本搜索enrichCompany（0.01 — 目录中成本最低的公司概况数据），searchCompanies（0.01/条记录，相似对象种子），searchPeople / reverseLookup / analyzePersonality（0.05），enrichPerson（0.1 — 个人资料 + 已验证的电子邮件），findMobilePhone（0.5）
waterfall多来源丰富数据 + 信号enrichContact（2）、enrichCompany（1）、verifyEmail（0.1）、detectJobChange（3）、searchProspects（3）、findPhone（7）
FullEnrich高级联系人查找 + 免费寻源searchPeople / searchCompanies / lookupPerson / lookupCompany（0），fetchPeople / fetchCompanies 提取器（0），findEmail（1）、findPhone（6）、findPhoneAndEmail（7）、reverseEmailLookup（1）
apolloio小众领域覆盖型丰富数据enrichPerson（1，使用 revealPhoneNumber 时为 9），enrichOrganization（1）；searchPeople（0，或使用 shouldEnrich 时为 1/人）和 searchOrganizations（0.01/条记录）也使用积分；其余七项需要你自己的 Apollo API 密钥
theirStack技术栈 + 招聘意向searchTechnologies（0.5）、searchJobs（0.5）、searchCompanies（0.5）
peopleDataLabs大规模补充数据enrichPerson（3）、enrichCompany（3）、searchPeople（3）、searchCompanies（3）、queryPeople/Companies（3）

aiArk 和 apolloio 分处丰富数据层的两端，选择依据是你手头已有的数据，而非个人偏好：只要手头有 LinkedIn URL，就优先选 aiArk（个人资料 + 已验证的电子邮件，0.1；手机号码为 0.5；未找到时两者均不计费）；apolloio 则是 1 积分的小众领域覆盖阶梯，当试点显示 Apollo 能命中 aiArk（0.1）和 waterfall（2）都未命中的目标时，按批次启用它——尤其适用于获得投资者支持的企业和投资组合领域。对于纯粹的大规模寻源，两者都无法取代 salesNavigator（0.2/条潜在客户）。

有三类信号位于这套工具链之外，应根据任务从 references/stage-action-map.md 中选择：要获得超出 aiArk.enrichCompany 的公司概况深度 → companyEnrich.enrichByDomain（0.25）；融资 / 收购 → enrichCrm.getFunding（1，是目录中唯一基于积分的融资操作）；已知域名时查询技术栈 → 先用 builtwith.getDomainSummary（免费），再用 builtwith.enrichDomain（1）。

请参阅 provider-playbooks/ 了解各提供商的深入介绍——其中包括每个提供商的 Recurring use 部分，说明任务是监控、执行活动还是定期拉取，而非一次性操作时应如何使用。请参阅 references/stage-action-map.md，查看涵盖完整 136 个集成目录的各阶段最低成本操作表。

已经持有标识符（而非进行寻源）？ 上述工具链介绍的是寻源优先的主流程。若你已经有 LinkedIn URL，成本最低的丰富数据操作是 aiArk.enrichPerson（0.1 — 完整个人资料 以及 已验证的电子邮件；未找到电子邮件时不计费）；如果不需要电子邮件，可改用 linkedin.enrichProfile / enrichCompany（0.25），此时不要用 waterfall.enrichContact（它也接受 linkedin URL，但费用为 2 积分，是前者的 20 倍）。需要电话号码？先选 aiArk.findMobilePhone（0.5），而非 3–7 积分的档位。持有 LinkedIn 活动 URL？linkedin.extractEventAttendees 可直接获取参会者列表。持有电子邮件？先用 aiArk.reverseLookup（0.05），再考虑 leadMagic / contactOut。完整的输入类型 → 最低成本操作对照表，请参阅 references/stage-action-map.md。

6) 配方主链（默认链路）

1. SOURCE   → salesNavigator.searchLeads / searchAccounts            (0.2/record)
              lookalike seeds, or filters SN can't express (skills,
              education, tenure)? aiArk.searchCompanies / searchPeople (0.01–0.05/record)
              free first pass on plain title/industry/size/geo filters?
              FullEnrich.searchPeople / searchCompanies                (0/record)
2. DEDUPE   → match against the workspace's own Companies / Contacts models
              on domain / linkedin_url (storage SQL or a segment filter)  (free)
3. ENRICH   → LinkedIn URL in hand? aiArk.enrichPerson (0.1) FIRST — profile + verified
              email in one call; linkedin.enrichProfile/enrichCompany (0.25) if no email needed
              aiArk.enrichCompany (0.01) for firmographics; companyEnrich.enrichByDomain
              (0.25) on the rows that come back thin
              + waterfall.enrichContact / enrichCompany              (1–2/record)
              + apolloio.enrichPerson / enrichOrganization on the niche residue (1/record)
4. SIGNAL   → enrichCrm.getFunding                                   (1/record)
              + theirStack.searchJobs / builtwith.getDomainSummary   (0–0.5/record)
              + waterfall.detectJobChange                            (3/record)
5. CONTACT  → FullEnrich.findEmail — only on rows step 3 left without
              an email (fallback peopleDataLabs)                     (1–3/record)
6. VERIFY   → waterfall.verifyEmail                                  (0.1/record)
7. BACKFILL → peopleDataLabs.enrichPerson (only if step 5 missed)    (3/record)
8. QA       → scripts/contact-accuracy-audit.ts                      (free, local)

关于 8-provider 堆栈的两条主链说明：步骤 3 的 aiArk.enrichPerson 已经会返回经过验证的邮箱，因此步骤 5 只针对剩余记录运行——对于已有邮箱的记录，不要再付费调用 FullEnrich.findEmail（1）。如果目标是获取电话号码，则先使用 aiArk.findMobilePhone（0.5，仅限手机号码，未找到时费用为 0），再用 prospeo（3）/ FullEnrich（6）/ waterfall（7）——§3 中的受控杠杆规则仍适用于这四项。

按阶段调整：删去与用户目标无关的步骤。纯粹寻找潜在客户时，只运行步骤 1。对于“丰富我已有的列表”，运行步骤 2–7。

7) 获取输出 — 使用 run download-outputs，而不是 run download

当 Agent 需要获取某项操作生成的实际数据（丰富后的字段、找到的邮箱、搜索结果）时，请使用：

cargo-ai orchestration run download-outputs \
  --workflow-uuid <uuid> \
  --output-node-slug <slug> \
  --format json

返回 {"url": "..."}——这是一个签名 URL，指向只包含输出节点数据的 CSV/JSON。它比 run download 更快、更省钱（后者会拉取完整的运行记录）。参见 references/output-retrieval.md 和 ../cargo-analytics/SKILL.md。

直接执行 action execute-batch 时没有可供指向的工作流，而 --wait-until-finished 会打印批次对象，而不是数据行。使用 cargo-ai orchestration batch download --uuid <batch-uuid> 获取其数据行：它会返回 {"url": "<signed CSV URL>"}，CSV 会将每个顶层输出键添加为 cargo_<key> 列（搜索的结果数组会落在一个 cargo 列中）。

8) 联系人准确性 — 运行 QA 脚本，不要凭目测判断

scripts/ 中的四个确定性 TypeScript 脚本（Node ≥ 22.18、无依赖、在 CI 中通过 fixture 测试）可取代在上下文中逐行检查。**运行脚本——切勿通过逐行推理重新推导其逻辑。**完整规范、流水线顺序以及 SEND/VERIFY/REVIEW/REMOVE 判定语义：references/contact-accuracy.md。

  • scripts/validate-emails.ts — 在付费调用 verifyEmail 之前，免费清除语法错误、高风险和重复项。
  • scripts/select-current-role.ts — 从 experiences 数组中选出真实的当前职位（可发现更换工作的人员）。
  • scripts/validate-linkedin-names.ts — 检查姓名与个人资料是否匹配（可发现同名干扰项）；配合 recipes/linkedin-url-lookup.md 使用。
  • scripts/contact-accuracy-audit.ts — 在合并后的输出中，为每行添加最终的 audit_action 标记；在回执中引用其汇总计数。可直接读取文件或已完成的运行（--workflow-uuid，通过 @cargo-ai/api）。

9）操作形状规则（适用于每个操作指南）

此技能中的每个操作 JSON 都遵循 ../cargo-orchestration/references/examples/actions.md 中的规则：

  • kind: "connector" 操作的形状：{"kind":"connector","integrationSlug":"<slug>","actionSlug":"<slug>"}。config 中不包含 connectorUuid——平台会根据 integrationSlug 自动解析工作区经过身份验证的连接器。
  • 顶层操作没有 config——请省略它。 输入应放在 --data / --records 中，此处的每个操作指南都不会在操作中包含此键。action execute、execute-batch 和 get-output-schema 都适用此规则——action list 返回的对象可直接粘贴到这三种命令中。误放入 config 的输入会被剥离，且不会提示 config 出错——调用会因缺少第一个必填字段而被拒绝；如果没有必填字段，则会在空操作上运行。因此，若调用返回空结果或在没有明显原因的情况下失败，请先检查这一点。拼错的输入键会在运行前被拒绝（Unknown field: <key>），但这只适用于顶层操作：在工作流节点中，此类输入仍会被静默丢弃。
  • 不要手写不确定的 slug，也不要翻遍目录查找。 cargo-ai orchestration action list <keywords> [--integration-slug <slug>] 可免费使用，会搜索所有集成以及原生操作、工具和 Agent，并返回可直接粘贴的操作对象，附带该操作的点数成本——在付费调用前，可用它以低成本检查 slug 和价格是否正确。要查询某个场景有哪些付费操作，请使用 cargo-ai connection action search <keywords> --credits-only，它会按是否消耗点数筛选。两者都不能替代下面的提供商指南：输入方面的特殊要求、命中率以及周期性使用时的陷阱，都写在指南中。
  • 对于多步骤节点图：connectorUuid 位于节点顶层，而不在 config 中。跨节点插值使用 {{nodes.<slug>.<field>}}。Agent 节点的输出会包装在 .answer 下（读取方式为 {{nodes.<slug>.answer.<field>}}）。

10）遇到困难时——提交工作区报告

如果某个操作指南反复失败且原因不明，请通过 cargo-ai workspaceManagement report create 提交问题。请参阅 ../cargo-workspace-management/SKILL.md（Reports 部分）。

11）提供商操作指南——调用前请阅读（无论是单次还是周期性调用）

STOP——在打开下面提供商的操作手册之前，请勿对其执行任何付费操作，也不要将其接入会重复运行的 play/tool 节点图。 每份操作手册都列出了准确的操作 slug、配置结构、输入注意事项和成本陷阱；花五秒阅读，比一次失败的付费调用划算得多，而一次失败的批处理意味着 100 次失败的付费调用。当提供商被接入重复运行的工作流时，风险只会更高，不会更低：错误配置会在每次计划运行时重复执行，错误的频率设置会导致同一批行不断重复计费——每份操作手册末尾都有一个重复使用部分（计划适配性、默认频率、重复计费门槛、提取器），专门说明这些问题。每个带有可调用操作、按额度计费的提供商现在都有操作手册，但有两个明确的例外：openRouter 提供的是模型列表器，而不是按额度计费的操作，因此无需编写文档；xAccount 的操作会以用户自己的 X 账号发布帖子、回复、点赞和发送私信——由于它没有可供记录的潜在客户开发用途，因此它在 references/acceptable-use.md §2 中被拒绝，而不是编写操作手册。使用自有密钥的集成请参阅 references/alternatives.md 和 references/stage-action-map.md。brightData 和 proxycurl 现在也有了操作手册，不再是未列出的提供商——未记录的提供商仍会出现在成本表中，而让可接受使用的界定含糊不清是更差的做法：provider-playbooks/brightData.md 开篇就声明拒绝面向消费者的定向操作。

优先级列表（配方优先介绍以下内容）：

大模型提供商（全部：一个 instruct 操作，按每 1,000 个 token 的套餐计费，按模型分档——提示词来自 references/prompt-library/index.md）：

类型化判断（不是 instruct——输入问题，输出概率）：

  • provider-playbooks/typesafe.md — 是／否、选项和评分答案，按每 1,000 个输入 token 收费 0.01；原生 classify 操作使用相同输入。

12) 参考资料

  • references/cost-discipline.md — 强制支出规则：试点 → 审批关卡、每次运行的收据、按 1.4×N 超额预留、先统计再估算资源，以及服务提供商计费规则。
  • references/contact-accuracy.md — 确定性 QA 脚本（邮箱筛选、当前职位、姓名匹配、最终审计）和 SEND/VERIFY/REVIEW/REMOVE 判定。
  • references/prompt-library/index.md — 约 40 个命名且参数化的大模型提示词（个性化、评分、研究、资质审核、信号分析、提取）。从头编写任何数据丰富或评分提示词之前，先 grep 此索引——复用胜过重新发明，且每个条目都附带经过测试的输出规范。只加载所需的分片，绝不要全部加载。
  • references/stage-action-map.md — 覆盖完整 136 项集成目录的各阶段最低成本积分操作。
  • references/credits-cost-table.md — 所有 180 项积分操作的自动生成成本表。
  • references/waterfall-strategy.md — 按数据丰富目标划分的规范瀑布链（每个方案中的“fallback”都遵循这些链）。
  • references/alternatives.md — 当优先级栈无法满足需求时，可从长尾中替换使用的服务提供商。
  • references/output-retrieval.md — 用于获取操作数据的 run download-outputs 模式。

评论

支持 Markdown