关于 trigger-cost-savings
用于通过源码检查和实时运行分析寻找 Trigger.dev 任务降本机会的技能。它结合与 SDK 版本匹配的指南及 Trigger.dev MCP 服务的运行数据，帮助开发者排列优化优先级。
主要功能
- 01检查任务源码中的成本风险
- 02分析运行记录与失败模式
- 03审查机器规格和利用率
- 04检查重试、等待与防抖
- 05生成按优先级排列的建议
适用场景
- 01发现任务代码中规格过高的机器
- 02定位成本高的失败运行与重试
- 03找出可改用检查点等待的轮询
- 04检查高频触发是否需要防抖
MCP 相关
使用 Trigger.dev MCP 服务的 `list_runs`、`get_run_details` 和 `get_current_worker` 工具检查实时运行和任务配置。工具不可用时仍可进行静态源码分析。
安装
复制下面的命令，在终端中运行。
$
npx skills add https:/安装后在 Claude Code 中输入/trigger-cost-savings确认已加载。
详细介绍
Trigger.dev 成本节省分析
分析任务运行和配置，找出降低成本的机会。此技能将静态源码分析与通过 Trigger.dev MCP 服务进行的实时运行分析结合起来。
开始之前：阅读权威指南
权威且固定版本的成本指南与此技能一同提供。请先阅读，确保建议与已安装的 SDK 版本一致：
@trigger.dev/sdk/docs/how-to-reduce-your-spend.mdx— 权威的“降低支出”指南（机器规格、幂等去重、并行处理、重试、maxDuration、检查点等待、防抖）。- 配套参考资料：
@trigger.dev/sdk/docs/machines.mdx、runs/max-duration.mdx、queue-concurrency.mdx、idempotency.mdx、triggering.mdx（防抖 + 批处理）、errors-retrying.mdx（AbortTaskRunError）。
前置条件：MCP 工具
实时运行分析需要 Trigger.dev MCP 服务。请确认以下工具可用：
list_runs— 按筛选条件列出运行（状态、任务、时间段、机器规格）get_run_details— 获取运行日志、时长和状态get_current_worker— 获取已注册任务及其配置
如果这些工具不可用，请告知用户安装 MCP 服务：
npx trigger.dev@latest install-mcp
没有 MCP 工具时，仍可进行下方的静态源码分析；不要编造运行数据。
分析工作流
步骤 1：静态分析（源代码）
扫描任务文件，检查以下问题：
- 机器规格过高 — 使用
large-1x/large-2x，但没有明确的需求。 - 缺少
maxDuration— 未限制执行时长（存在运行失控导致成本过高的风险）。 - 重试次数过多 —
maxAttempts> 5，且已知的永久性故障没有使用AbortTaskRunError。 - 缺少防抖 — 高频触发未进行防抖。
- 缺少幂等性 — 支付/关键任务没有幂等键。
- 使用轮询而不是等待 — 使用
setTimeout/setInterval/睡眠循环，而不是wait.for()。 - 等待时间过短 —
wait.for()少于 5 秒（不会设置检查点，会浪费计算资源）。 - 使用顺序执行而不是批处理 — 多个
triggerAndWait()调用本可改用batchTriggerAndWait()。 - 计划任务过于频繁 — 计划触发频率高于实际需要。
步骤 2：运行分析（需要 MCP 工具）
- 2a. 高成本任务 — 使用
list_runs查询period: "30d"/"7d"；找出总计算量（时长 × 次数）较高、失败率较高，以及运行时长较短却使用大型机器的任务（规格过高）。 - 2b. 失败模式 — 使用
list_runs查询status: "FAILED"/"CRASHED"；区分瞬时故障（可重试）和永久性故障；对后者建议使用AbortTaskRunError；估算重试浪费的计算资源。 - 2c. 机器利用率 — 对样本运行使用
get_run_details；如果large-2x任务始终在一秒内完成，或属于 I/O 密集型任务（API/数据库），则说明机器规格过高。 - 2d. 计划频率 — 使用
get_current_worker列出 cron 模式；标记对于其用途而言过于频繁的计划。
步骤 3：生成建议
按优先级提供报告，并估算影响：
## Cost Optimization Report
### High impact
1. **Right-size `process-images`** — currently `large-2x`, average run 2s. `small-2x` could cut this task's cost by ~16x.
`machine: { preset: "small-2x" }` // was "large-2x"
### Medium impact
2. **Debounce `sync-user-data`** — 847 runs/day, often bursty.
`debounce: { key: \`user-${userId}\`, delay: "5s" }`
### Low impact / best practice
3. **Add `maxDuration` to `generate-report`** — no timeout configured.
`maxDuration: 300` // 5 minutes
机器预设成本（相对值）
机器规格越大，每秒计算成本按比例越高：
| 预设 | vCPU | RAM | 相对成本 |
|---|---|---|---|
| micro | 0.25 | 0.25 GB | 0.25x |
| small-1x | 0.5 | 0.5 GB | 1x（基准） |
| small-2x | 1 | 1 GB | 2x |
| medium-1x | 1 | 2 GB | 2x |
| medium-2x | 2 | 4 GB | 4x |
| large-1x | 4 | 8 GB | 8x |
| large-2x | 8 | 16 GB | 16x |
核心原则
- 超过 5 秒的等待不收费 — 会设置检查点，不产生计算费用。
- 从小规格开始，再逐步扩容 — 默认的
small-1x适用于大多数任务。 - I/O 密集型任务不需要大型机器 — API 调用和数据库查询都在等待网络响应。
- 防抖能为高频任务节省最多成本 — 将触发突发合并为单次运行。
- 幂等性可避免重复计费的工作 — 尤其适用于成本高昂的操作。
AbortTaskRunError可停止浪费资源的重试 — 永久性故障不应付费重试。
版本
此技能随 @trigger.dev/sdk 一同打包，并直接从 node_modules 读取，因此始终与已安装的 SDK 版本一致（请参阅旁边的 package.json）。完整的成本文档也随包附带，位于 @trigger.dev/sdk/docs/ 下。
评论
支持 Markdown