用途
该技能面向将 Intercom 集成部署到生产环境的场景，提供一份完整的上线前检查清单和回滚程序。它适合在发布前逐项核对集成质量，并在上线时作为准入门槛使用。
主要能力
检查清单按故障类别分为六组，每组对应一类典型问题，需要按顺序逐项完成，不能因为“应该没问题”而跳过任何一组：
- 认证与密钥：生产访问令牌存入密钥管理器而非环境文件；令牌仅具备所需的最小 OAuth 范围；记录并测试令牌轮换流程；开发、预发、生产工作区使用不同令牌；通过
grep -r "dG9r" .确认源码中无硬编码令牌。 - API 集成质量：所有 API 调用包裹错误处理（try/catch 配合 IntercomError）；实现 429 速率限制的指数退避重试；实现 5xx 服务端错误重试；配置请求超时（建议 30 秒）；分页正确支持游标迭代；联系人搜索高效使用复合查询。
- Webhook 端点：Webhook URL 使用 HTTPS（Intercom 要求）；实现 X-Hub-Signature 验证（HMAC-SHA1）；处理程序在 5 秒内响应（Intercom 超时限制）；幂等处理重复 Webhook；处理失败重试（Intercom 在 1 分钟后重试一次）。
- 数据处理：日志中脱敏 PII（邮箱、姓名、电话号码）；联系人数据缓存设置合理 TTL；实现联系人数据的 GDPR 删除处理；发送到 API 前校验自定义属性。
- 监控与告警：健康检查端点包含 Intercom 连通性测试；配置错误率告警（阈值：5 分钟内 5%）；跟踪速率限制使用量（达到限额 80% 时告警）；延迟监控（P95 超过 2 秒告警）；监控 Intercom 状态页（https://status.intercom.com）。
- 健康检查与上线：生产健康端点在 Intercom 不健康时返回 503；使用生产令牌运行上线前验证脚本；演练回滚流程。
使用方式
技能包含预检脚本作为上线准入门槛，运行时输出认证结果（PASS 才通过）、当前速率限制余量、Intercom 状态指示（none 表示正常）以及 Webhook 端点 HTTP 状态码；认证返回非 200 时脚本以非零退出并阻止上线。健康检查端点在 Intercom 健康时返回 200，降级或不健康时返回 503，并在 JSON 正文中给出分类原因。资料中提供了一个最小健康检查骨架：
async function checkIntercomHealth(client: IntercomClient) {
const start = Date.now();
try {
await client.admins.list();
return { status: "healthy", latencyMs: Date.now() - start };
} catch (err) {
// 429 → degraded, 401 → unhealthy + unauthenticated, else unhealthy
return { status: "unhealthy", latencyMs: Date.now() - start };
}
}
完整实现位于 references/implementation.md，包含 TypeScript 模块和 Express /health 端点。预检与回滚脚本位于 references/examples.md。
前置条件包括：拥有生产 Intercom 工作区并在开发者中心签发访问令牌；在运行检查的环境中导出 $INTERCOM_ACCESS_TOKEN；具备 curl 和 jq 用于预检与状态探测；集成部署在功能开关之后，以便无需重新部署即可禁用；接收 Webhook 时可选设置 $WEBHOOK_URL。
适用场景
适用于 Intercom 集成准备上线、发布前核查、以及生产环境故障时的回滚处置。
限制
资料未说明该技能支持的具体平台、是否需要特定运行时版本或依赖包；也未提供价格或收费信息。回滚步骤包括关闭功能开关、回滚部署、验证 /health、在开发者中心禁用 Webhook，但完整脚本需参考对应文件。对于版本升级场景，资料建议参考同包中的 intercom-upgrade-migration 技能。