来源与修改说明

• 基于 Corey Haines 的 marketingskills/skills/cold-email 适配。
• 上游许可证为 MIT；完整文本见本包 LICENSE。
• Agnes 适配相对上游新增：产品信息卡与资料缺口追问、事实/推断分栏、五段首封与渠道开发信场景、固定输出分区路由、邮件正文禁语（禁止流程口吻写入正文）、中文首封约 150 字、发送前人工检查、统一输出语言规则及中文调用示例。保留的上游延伸资料在 references/，使用时受下方延伸资料边界约束。

B2B 冷启动邮件

帮助用户先澄清“谁的什么问题、为什么现在值得联系、能证明什么、希望对方做什么”，再写一封可人工审核的 B2B 冷启动邮件。目标是相关、清楚、可核查的首次沟通，不是伪造亲近感或承诺回复率。

何时调用

当用户要求：

• 根据产品介绍、官网摘录或案例写开发信、陌生拜访邮件或销售首封；
• 为某个职位、行业或公司类型改写冷邮件；
• 审查冷邮件的相关性、证据、个性化、CTA 或过度承诺；
• 设计基于新价值的邮件跟进或回复草稿。

不要因“群发、找邮箱、导入线索、发信、自动暂停序列、CRM 更新、LinkedIn 自动化”单独调用。说明本 Skill 只能交付文案和人工操作清单；实际数据、发送、退订与系统操作由用户在已获授权的工具中完成。

使用边界

1. 资料来源。 只使用用户粘贴/上传的资料、现有产品营销上下文，或当前会话中实际读取且用户指定的公开页面。不得声称自动识别、抓取或验证了潜在客户官网、CRM、社交资料、邮箱或私有信息。
2. 个性化。 仅使用收件人能合理预期被用于业务沟通的职业、角色、公司或公开业务信号。避免敏感、私人或无法在一句话内解释来源的变量。
3. 事实。 不把推断写成事实；不编造客户案例、结果、资质、共同联系人、近期事件或个人观点。没有证据时用待确认项或删去。
4. 发送与合规。 不发送邮件，也不判断某一法域下的合规性。草稿中标出发送前需要核对的身份、退订、地址、受众和技术要求；由用户及其法务/运营流程决定是否发送。

SOP

1. 路由请求

识别用户要的是：首封、跟进、回复、审查、停止联系，还是发送前检查。按下方「输出分区路由」只生成对应资产；资料充足时的默认是完整首封（分区 1–6）。

当发件方是厂家、品牌方或贸易商，收件方是经销商、代理商、零售渠道或进口商时，先选择以下渠道开发信场景。不要将 SaaS 的“痛点—结果—预约演示”框架机械套用到产品分销。

若无法判断场景，采用“陌生产品介绍”，并将需要补足的信号列入信息卡。

2. 先生成两张信息卡，资料不足时追问

优先读取已有的产品营销上下文；再使用用户提供的产品资料、附件或实际可读取的公开产品页。先区分发件方产品与潜在客户公司，输出以下信息卡，不直接跳到模板。

发件方产品信息卡

收件方相关性卡

若以下任一项缺失，先用不超过四个问题补齐：目标角色/细分市场、产品解决的问题、至少一项可用证据或明确无证据、希望对方采取的动作。用户不补充时，仍可给一个带 [待确认] 占位符的骨架和缺口说明，但不要伪造细节。

3. 用五段结构写首封

篇幅以说清一个主张和一个 CTA 为准，默认按下表控制（按汉字或英文词计；署名与联系方式另计）：

延伸资料中的更短篇幅建议可作为风格参考；与上表冲突时以本表为准。参数再多也只写入与切入点最相关的 1–2 项，用加长空洞套话凑字数。

1. 主题行：准确反映正文，不伪造 Re:/Fwd:，给 2–3 个与正文相关的选项。
2. 相关观察：一句可溯源的公司、角色或行业信号；没有可靠信号时，直接以该角色常见问题开场，不假装研究过个人。
3. 问题或风险：把观察与一个具体业务摩擦相连；区分事实与合理假设。
4. 针对性价值与证据：说明产品如何帮助应对该问题，最多用一项能支持该说法的证据；没有证据则以能力描述替代结果承诺。
5. 单一低摩擦 CTA：要求一次清晰、容易拒绝或回复的动作，例如“这是否是你当前在处理的问题？”不要在首封同时索要会议、转介绍和资料下载。

输出时同时附上 事实/推断/待确认 对照表，逐条列出开场、价值和证据所依据的资料。

渠道开发信的语气与价值表达

• 使用厂商对商业伙伴的平实口吻：清楚说明“我是谁、产品是什么、为什么联系、希望对方下一步做什么”。避免“革命性”“领先”“强强联合”“长期共赢”等空泛合作话术。
• 若没有具体收件方信号，不假装了解对方的选品规划。可用条件化表达，例如“若贵司正在评估该品类新品”。
• 面向经销商的价值优先是其可评估的商业信息：产品类别差异、目标区域/渠道匹配、已确认的认证、已有市场覆盖、售后或物料支持。只有用户提供证据时才能出现；终端消费者卖点只作为产品说明，不能自动转换为渠道收益。
• 第一次陌生联系的目的是让对方决定是否继续了解，不是完成渠道资格审查或谈定合作。产品介绍模式优先请求“是否接收资料”；已核实的渠道匹配或展会后，才可请求简短会议。

4. 写跟进和回复

每封跟进必须新增一项价值：不同问题角度、补充证据、简短资源、明确澄清或礼貌结束。不要只写“跟进一下”，不要重复相同 CTA。若收到拒绝、退订或要求停止联系，提供停止后续触达的人工操作提示，不继续生成说服性跟进。

回复草稿先识别意图：有兴趣、时机不对、转介绍、异议、拒绝/退订或无关。只回应对方实际提出的问题；不要擅自承诺价格、集成、时间表或结果。

5. 发送前人工检查

资料充足的首封/跟进在分区 6 只给简短核对要点。当用户明确问「能否发送 / 是否合规 / 发送前检查」时，改用或另附下列较完整清单，仍不声称已完成任何验证、不发送、不认证法域合规：

• 发件人、回复地址、域名和主题是否真实且与正文一致；
• 目标受众、所在法域、个人数据来源及联系依据是否由用户的合规流程确认；
• 是否提供清晰的退订/停止联系方法，以及商业邮件所需的身份和地址信息；
• 证据、案例数字、客户名称和个性化观察是否均可核查并获准使用；
• 发送系统是否满足用户适用的认证、退订和声誉监控要求；
• 是否有拒绝、退订、投诉或退信记录需要先排除。

输出格式

目的在于让用户一眼区分“用于判断的资料”与“可直接复制发送的邮件”。不要把邮件正文混在解释、卡片或事实说明之间。

输出分区路由

先按请求类型选择输出形态；不要对所有请求机械套用完整六个分区。

除非上表另有规定，或用户明确要求 JSON/只要邮件，资料充足的首封与跟进必须使用下列 Markdown 分区。

输出语言

先确定输出语言，并让标题、信息卡、策略、主题行、邮件正文、事实表和发送前检查保持同一语言。

1. 用户明确指定“用中文/英文/德文输出”“write in English”等，指定语种优先。
2. 未指定语种时，按用户指令的主要自然语言输出：中文指令用中文，英文指令用英文。
3. 产品资料、官网摘录、品牌名、型号、认证名或参数的语言不改变输出语言；它们按原文保留或作必要翻译，并标明原始术语。
4. 收件人所在国家或市场不自动改变输出语言。若用户需要实际发送给特定语言市场，应由用户明确指定语言；否则按上述规则生成。
5. 若用户指令本身无法判断主要语言且没有指定语种，先用一个问题确认；不要擅自混合中英文标题或正文。

## 1. 信息卡

### 发件方产品信息卡
| 字段 | 当前信息 | 状态 |
|---|---|---|
| 服务对象 | ... | 已确认 / 待确认 |
| 问题 | ... | 已确认 / 待确认 |
| 能力与证据 | ... | 已确认 / 待确认 |

### 收件方相关性卡
| 字段 | 当前信息 | 状态 |
|---|---|---|
| 对象与业务信号 | ... | 事实 / 未知 |
| 相关性假设 | ... | 推断 |
| 目标动作 | ... | 已确认 / 待确认 |

## 2. 邮件策略
> **受众：** ...  
> **主问题：** ...  
> **价值与证据：** ...  
> **唯一 CTA：** ...

## 3. 主题行
- ...
- ...

## 4. 可直接复制的邮件

### 版本 A
```text
邮件正文，只放收件人会看到的内容。
```

## 5. 事实与待确认项
| 类型 | 内容 | 邮件中的处理 |
|---|---|---|
| 事实 | ... | 已采用 |
| 推断 | ... | 条件化表达 / 未采用 |
| 待确认 | ... | 未采用 |

## 6. 发送前检查
- ...

具体规则（在「输出分区路由」选定形态之后适用）：

1. 邮件正文必须置于标注为 text 的代码块中，代码块外不得重复正文。邮件包含称呼、正文、CTA、署名和停止联系文字（如适用）。
2. 需要信息卡时，两张卡必须各自有三级标题和独立 Markdown 表格；每项用 已确认、待确认、事实、推断 或 未知 标示状态。不得将卡片写成散段文字。
3. 需要邮件策略时，必须使用引用块，固定展示受众、主问题、价值与证据、唯一 CTA 四项，避免与正文混排。
4. 有两个版本时，各版本各用一个独立 text 代码块；不能在同一代码块中混写多个版本。
5. 资料不足、审查、停止联系、仅发送前检查时，严格按路由表输出，不要为了“格式完整”强行补齐六个分区。
6. 用户只要求“改成中文/英文”“换一种表达”“调整主题行”且上下文或正文资料充足时，仍应重新输出完整六个分区；仅当用户明确说“只要邮件”“只要主题行”或“不要分析”时才可省略其他分区。
7. 语言切换后，所选形态下的标题、表格字段、策略、主题行和代码块内邮件必须一并切换；品牌名、型号、认证名和未经用户要求翻译的产品参数可保留原文。

首封内容完整性规则

• 产品资料含有多项可确认参数时，正文优先选择 1–2 项与切入点最相关的参数，避免只堆一个参数或罗列全部规格。技术规格是事实，不自动等同于用户收益、市场需求或销售证明。
• 若首封 CTA 是“接收产品资料”或“是否有兴趣了解”，不要同时要求采购量、补货节奏、预算或合作条款。这些信息可留到对方回复后的下一轮沟通。
• 当“稳定供货”只是用户希望达成的合作目标，而非已有产能、交期或补货机制证据时，只能将其表述为“愿意讨论供货安排”，不能写成“可稳定供货”或“补货可预期”。

邮件正文禁语（流程口吻不得出现）

text 代码块内只能是收件人会看到的商务表述。下列内容属于本 Skill 的内部写作约束，不得写进邮件正文（可留在信息卡、策略或事实表）：

• 元叙述 / 流程说明：如“首封只说明…”“本封仅…”“按开发信结构…”“低摩擦 CTA”“待确认占位”“信息卡”“可核对信息（作为自我标注）”等；
• 对写作策略的旁白：如“不承诺销量/利润（作为自我声明句）”“我不会再跟进（若非收件人需要的停止联系说明）”以外的作者自言自语；
• 把参数选择规则说给对方听：应直接写出那 1–2 项参数本身，而不是解释“为什么这封只写两点”。

正确写法：直接陈述产品、参数与请求。错误写法：首封只说明两点可核对信息：容量为 4L…。应改为：产品为 4L IH 智能电饭煲；如需评估，我可提供对应型号检测报告。

调用示例

• “根据下面的产品介绍，先提炼产品信息卡和待确认项，再给我写一封发给 100–500 人 SaaS 公司 VP Sales 的英文开发信；不能证实的客户成果不要写。”
• “我只知道我们帮电商团队减少人工报表时间。请先问我最关键的四个问题，再写一封冷启动邮件骨架。”
• “审查这封冷邮件：标出没有证据的说法、虚假的个性化和 CTA 问题；只用我提供的事实重写两版。”
• “客户回复说现在没有预算。帮我写一封不施压的回复，并给我一个停止继续触达的人工检查项。”

延伸资料

按需要查阅：references/personalization.md、references/frameworks.md、references/subject-lines.md、references/follow-up-sequences.md、references/deliverability.md 与 references/reply-handling.md。这些材料用于改善草稿结构与措辞，不替代本 SOP 的资料来源、事实核验和发送边界。

使用边界：

1. 允许取用： 框架结构名称、主题行长度习惯、跟进节奏思路、投递清单项、回复意图分类。
2. 禁止照抄为用户事实： 示例中的客户名、百分比、会议时长或其他结果数字（尤其 frameworks.md）。只有用户提供的证据才能写入邮件。
3. 禁止声称已执行： 退订抑制、CRM 写入、序列暂停、邮箱验证、LinkedIn 或多渠道自动化。reply-handling.md 中的 agent 操作表仅作人工流程参考；本 Skill 只输出文案与人工操作提示。
4. 包内另有 references/benchmarks.md、linkedin-outreach.md、multichannel-cadence.md、outbound-plays.md。默认不要主动查阅；若用户明确要求相关文案思路，仍只交付草稿与人工清单，不提供自动化操作步骤，也不声称已连接 CRM、广告或 LinkedIn 工具。文中指向其他 Skill 的链接在本包中不可用，忽略即可。