销售邮件撰写

按产品信息、目标客户画像和沟通目的，产出可直接发送的个性化销售邮件。邮件正文由接入方部署的后端付费服务生成，本 Skill 负责输入归集、目标市场语言匹配、质量双自检与交付，付费调用在对话内确认后执行。

适用范围

适用：

• 首次接触潜在客户的开发信
• 向已有联系人或线索推广产品或服务的推广信
• 在已有沟通之后发送的跟进信

不适用：

• 内部通知、客服回复、法务文书、合同与报价单正文
• 批量生成、收件人采集、邮件列表整理
• 代发邮件。本 Skill 只产出草稿，发送由用户自行完成

调用范围与计费

超出调用范围的请求（批量、群发、收件人采集、合同类文书）直接拒绝，不调用付费接口。

付费链路

本 Skill 按四步编排付费链路，步骤名为 probe → pay → complete → ack。支付与验付一律复用支付宝官方支付能力，本 Skill 不自研支付代码、不接触任何密钥。

补充约定：

• 买方侧履约回执由官方支付技能执行（alipay-bot 402-buyer-fulfillment-ack -t <tradeNo>），本 Skill 不自行构造该命令。
• 单次用户请求对应的 out_trade_no 在整条链路上固定不变，付款重试复用同一编号，不产生第二笔订单。
• 应用私钥、serviceId 等只存在于服务端；本 Skill 与配置文件都不保存密钥，也不要求用户在对话里粘贴凭据。
• 不向用户展示 Payment-Proof、Payment-Validation 的原始值，也不展示支付链接原文之外的中间过程。

订单与幂等

订单持久化与幂等由服务端承担，本 Skill 侧固定订单号、记录台账、不在订单完成后重复发起付款。

本 Skill 侧的幂等动作限于三件：固定订单号、按订单号读台账、不重复发起同一笔付款。资源是否重复发放由服务端保证。

结果回流

• 接口返回的正文与备选标题原样进入本 Skill 的双自检与交付格式，不改写、不摘要。
• 订单号、交易号（32 位纯数字）、支付状态、计费金额写入「本次状态」，供平台侧对账与回溯。
• 履约确认完成、订单状态回到 FULFILLED 后才向用户交付正文；确认未完成时按未交付处理。
• 本 Skill 不改写订单号与交易号、不重复发起同一笔付款、不在订单完成后重新查询。

输入变量

开始撰写前确认四项。任何一项缺失时标注「待确认」，不猜测、不补造、不套用默认值。

环境检查与就绪路由

本 Skill 依赖两项：接入方的后端付费服务（必需）、402 付款用的 alipay-bot 命令行（付款阶段必需）。邮件正文只能由后端付费服务产出，本 Skill 不提供离线生成通道。进入流程前先做一次只读环境检查。

1. 运行 python scripts/check_environment.py。
2. 涉及 402 付款时，先由宿主执行最小只读探测（alipay-bot check-wallet），把脱敏结果写入 probe-results.json，再运行 python scripts/check_environment.py --probe-results probe-results.json。探测证据字段格式见 references/setup-guide.md。
3. 按返回状态路由：

4. 后端付费服务不可用时不产出邮件，不提供替代生成方式。
5. 已经通过的检查项不重复引导。环境检查只读取状态，不安装、不登录、不授权、不修改配置。

生成流程

Step 1 归集输入

整理四项变量，逐项标记来源：用户提供、推断、待确认。产品参数只使用用户给出的内容。核对请求是否落在调用范围内，超出即停止。

Step 2 确定类型与结构

按邮件类型确定结构，各结构的段落职责、字数控制与填好的示例见 references/email-structures.md。

Step 3 匹配语言

按目标市场确定语言，映射表与本地化注意事项见 references/language-mapping.md。目标市场不在表内时使用英语，并标注「目标市场未覆盖，语言待确认」。

Step 4 走付费链路取回正文

这是产出正文的唯一通道。请求体、订单号生成、调用命令、四步链路与结果回流规则见 references/paid-endpoint.md。

1. 按前 3 步整理请求体，由脚本生成固定订单号并写入请求体的 out_trade_no，调用 python scripts/call_paid_endpoint.py --payload <请求体文件> --json。
2. 返回 probe 命中（HTTP 402 + Payment-Needed）：先向用户列明服务内容、金额、收款方与影响并取得明确确认，再把账单交给官方支付宝支付能力完成 pay。
3. pay 完成后重新调用同一请求，由服务端携带 Payment-Proof 完成 complete：验证支付凭据、匹配本地订单、校验金额与资源归属，返回正文。
4. 返回 200 且有 Payment-Validation：确认 ack 履约确认已完成，进入 Step 5。
5. 返回鉴权失败、额度受限、网络故障、验付失败或履约确认失败：按 references/paid-endpoint.md 的分支处理，接口未恢复前不产出正文。

Step 5 双自检

对返回的正文和每个备选标题执行两道检查，规则见 references/self-check-rules.md。

1. 把正文写入临时文件，运行 python scripts/check_email_quality.py --file <正文文件> --json，取得违规清单。
2. 逐条修复；脚本无法判定的主观项按 references/self-check-rules.md 人工复核。

存在 P1 级违规（垃圾邮件特征、夸大承诺、编造数据）时禁止输出，修复后重跑直到无 P1。修复只在措辞层进行，不改动接口返回的事实性内容。

Step 6 输出

按下方输出格式交付。邮件正文使用与目标市场一致的语言，标题与状态说明使用中文。

输出格式

【邮件类型】开发信
【目标市场】德国（语言：德语）
【生成方式】后端付费服务
【订单号】<out_trade_no>

【邮件正文】
主题：<主题行>

<正文段落>

【备选标题】
1. <标题一>
2. <标题二>
3. <标题三>

【本次状态】
- 计费：¥<单价> × 1 次
- 交易号：<32 位交易号>
- 收款方：<接口返回的收款方>
- 支付环节：probe 402 → pay 完成 → complete 验付通过 → ack 履约确认完成
- 已执行：反营销腔自检、反垃圾邮件自检
- 自检结果：无 P1 违规；<其余发现>
- 降级项：<无／具体说明>
- 缺失输入：<逐项列出，无则写「无」>
- 未覆盖：未发送邮件，收件人与发送时机由你确认

质量自查清单

• [ ] 请求落在调用范围内，未越界调用付费接口
• [ ] 四项输入都有来源标记，缺失项已列进「缺失输入」
• [ ] 邮件类型与结构对应，未混用两种结构
• [ ] 语言与目标市场一致，未覆盖市场已标注
• [ ] probe 收到的账单金额与收款方已向用户明示并取得确认
• [ ] complete 返回含有效 Payment-Validation，未以「支付成功」文字替代证据
• [ ] ack 履约确认已完成，未确认前未向用户交付正文
• [ ] out_trade_no 全链路一致，未对同一订单重复发起付款
• [ ] 输出未包含 Payment-Proof、Payment-Validation 原文与任何密钥
• [ ] check_email_quality.py 已运行，无 P1 违规
• [ ] 反营销腔检查已执行，已删除空泛形容词与自夸断言
• [ ] 3 个备选标题互不重复，均不超过 60 字符
• [ ] 无编造的产品参数、价格、客户名称、案例数据、合作方名称
• [ ] 订单号、交易号、金额、收款方已原样填入「本次状态」
• [ ] 未代替用户发送邮件

功能降级

停止条件

• 后端付费服务未配置或不可用：停止，本 Skill 没有离线生成通道。
• 接口返回 402 且用户拒绝付款：停止，不交付该资源。
• 验付未通过或履约确认未完成：停止，不交付正文，也不要求用户重复付款。
• 出现同一订单重复扣费迹象：停止并输出订单号，交由接入方核对订单状态。
• 用户要求批量生成、整理收件人或做群发准备：停止，本 Skill 只产出单封草稿。
• 产品参数、价格、客户信息无法确认，而用户要求「先编一个」：停止并说明不编造任何未提供的数据。
• 请求超出调用范围（合同、报价单、法务文书、代发邮件、收件人采集）：停止并说明边界。