企业官网建设流程全解析

• 人工智能
• AI Agent
• 大模型
• AI 应用
• 媒体生成

本文基于开源仓库 xiaobei 中公共技能 skills/email-ops/SKILL.md 展开，系统讲解该技能如何代替用户完成「先起草、再发送」的完整邮件操作：包括六类商务邮件的结构化起草模板、现有线程读取与跟进节奏判断、发件账号与渠道选择、基于 SMTP 的底层发送实现，以及发送后的状态报告与跟进策略。读完本文，你将掌握在小贝智能体环境中驱动 email-ops 完成首次触达、回复跟进、会前确认、会后跟进、合作提案与引荐接收等真实场景邮件任务的方法，并理解其 wrapper 调用链与 send_email.py 的底层实现原理。

一、技能定位与运行前提

email-ops 是 xiaobei 仓库中的公共技能。根据 skills/README.md 的技能清单，它面向"邮件读写与发送"场景，适用范围为全部 crew 可用；在 config-templates/openclaw.json 中，email-ops被列入默认 crewmain（小贝）的skills列表，同时也在 config-templates/openclaw-awk.json 中出现，说明其为多 crew 共享的基础能力（注意：content-producer crew 的 DENIED_SKILLS 中明确排除 email-ops，属于例外配置）。

SKILL.md 的 frontmatter 元数据给出了该技能声明式的能力约束：

name: email-ops description: 邮件操作技能。代替用户起草并发送邮件。 metadata: openclaw: emoji: 📨 always: false requires: bins: - python3 env: - SMTP_SERVER - SMTP_USER - SMTP_PASSWORD

运行前提有三点：

• Python 3：底层发送脚本 send_email.py 只使用 Python 标准库smtplib、ssl、email.mime，零第三方依赖，因此任何带 python3 的环境即可运行；
• SMTP 环境变量：SMTP_SERVER、SMTP_USER、SMTP_PASSWORD三项必需。按仓库部署约定（见 config/daemon.env.template 的说明），技能密钥统一写入~/.openclaw/.env（所有 openclaw 进程都会加载），用户无需修改 daemon.env.template；config/README.md亦将SMTP_*列为占位就位的环境变量；
• always: false：该技能不是每次会话自动执行，而是由 Agent 按需调用。

二、Step 1：确定邮件类型与上下文

起草任何邮件之前，必须先明确邮件类型与上下文。SKILL.md 定义了六种邮件类型：

需要收集的信息包括：目标姓名、职位、公司；发件账号（公司域名邮箱 / 个人邮箱）；是否有现有线程（如有需先读取）；目标（签客户 / 找合作 / 接触投资人 / 其他）；关系温度（陌生 / 见过面 / 有过合作）。

规则：未提供邮件类型时，根据上下文推断；推断不确定时先问用户，不要擅自假设。

三、Step 2：读取现有线程（仅 B/C/D/F 类型）

回复或跟进类邮件必须先读取历史线程，避免重复提问或内容脱节。操作路径：

1. 确认邮件客户端（通常为系统默认邮件客户端，通过 shell 或 browser 访问）；
2. 定位线程：搜索发件人邮箱或公司名，找到最近的往来邮件；
3. 提取关键信息：最后一封邮件的日期、发件方、核心内容；对方提出的问题 / 尚未回答的点；之前承诺的事项（如"我会发资料给你"）；是否已有报价或提案在线程中。

跟进距离判断直接决定措辞强度：

• 上次邮件距今< 48h→ 正常速度跟进；
• 3–7 天→ 轻推，语气平和；
• > 7 天→ 需要重新建立上下文，别假设对方记得之前内容。

四、Step 3：选择发件账号与渠道

账号选择规则：

• 有公司域名邮箱时，B2B 场景优先用公司邮箱；
• 个人引荐 → 用个人邮箱，更暖；
• 与投资人沟通 → 优先公司邮箱（显示专业度）；
• 发件人名称格式：完整姓名 + 公司名，例如张三 <zhangsan@company.com>。

渠道确认规则：

• 对方之前用邮件回复 → 继续邮件；
• 对方之前提到微信 → 建议换到微信，邮件只发摘要；
• 没有回复记录 → 默认邮件。

五、Step 4：六类邮件起草模板

SKILL.md 为每一类邮件提供了可直接投喂给 LLM 的结构化 Prompt 模板，包含背景变量、格式要求与返回格式。以下完整继承并给出可替换的占位符说明。

A. 首次触达（定制化）

LLM Prompt: "起草一封与潜在合作伙伴或投资人建立联系的信件，发给 {姓名}（{职位} @ {公司}）。 背景： - 发件人：{姓名}，{职位}，{公司及一句话介绍} - 目的：{目的，例如：探讨数据采集服务合作} - 找他的理由：{个性化理由，例如：看到贵公司近期发布了...} - 关系温度：陌生 / 通过 {中间人} 引荐 格式要求： - 中文 - Subject：10 字以内，具体到对方业务，不用感叹号 - 正文 3 段，总计 120-150 字： 段 1：为什么写这封邮件（个性化切入） 段 2：我方能提供的价值（从对方视角，不是自我介绍） 段 3：一个低摩擦 CTA（15 分钟通话 / 一封回复即可） - 结尾不用"谢谢" / "期待您的回复" 等套话 返回格式： Subject: [主题行] --- [正文]"

要点：首次触达强调个性化与对方视角，Subject 精简到 10 字以内且必须具体到对方业务，结尾用低摩擦 CTA 而非客套话。

B. 回复 / 跟进

LLM Prompt: "起草一封跟进邮件，基于以下线程上下文。 线程摘要： - 上次发件方：{我方/对方} - 上次时间：{N 天前} - 未回答的问题：{具体内容} - 之前的承诺：{如有} 当前目的：{推进到下一步，例如：确认是否收到提案 / 约下次通话时间} 要求： - 中文，简短，不超过 80 字正文 - 不要重复上封邮件的所有内容 - 如果是 3 天以上的跟进，先一句话刷新上下文 - 结尾一个明确问题或提议，不要 open-ended 收尾 返回格式： Subject: Re: [原主题] --- [正文]"

要点：跟进邮件要短（≤80 字），不重复历史内容，收尾必须是明确的问题或提议，避免开放结尾。

C. 会前确认

LLM Prompt: "起草一封会议确认邮件。 会议信息： - 对象：{姓名} @ {公司} - 时间：{日期 + 时间 + 时区} - 形式：{视频会议/面谈，如视频则附链接} - 议程重点：{1-2 个核心议题} 要求： - 中文，简短，不超过 60 字正文 - 确认时间 + 附议程 + 如有附件说明 - 语气专业但不冷漠 返回格式： Subject: 确认：{时间} 与 {对方公司} 的会议 --- [正文]"

要点：会议确认要极简（≤60 字），核心是时间、议程、附件三个要素，同时注明时区。

D. 会后跟进

LLM Prompt: "起草一封会后跟进邮件。 会议信息： - 对象：{姓名} @ {公司} - 会议时间：{刚才 / N 天前} - 关键结论：{达成了什么共识} - 我方下一步行动：{例如：发送方案文档 / 安排 demo} - 对方下一步行动：{例如：内部讨论后反馈} - 期望截止时间（如有）：{具体日期} 要求： - 中文，简洁，正文不超过 100 字 - 结构：感谢 + 关键共识一句话 + 双方后续行动 + 期望时间点 - 语气温暖，不催促 返回格式： Subject: 跟进：关于 {核心议题} --- [正文]"

要点：会后跟进按「感谢 → 共识 → 双方行动 → 时间点」四段结构，明确双方下一步责任，但不催促。

E. 合作提案 / 报价

LLM Prompt: "起草一封合作提案邮件，发给 {姓名} @ {公司}。 提案内容： - 合作类型：{例如：数据服务 API 接入 / 渠道分销合作} - 核心价值：{我们能解决他们的什么问题} - 方案要点：{2-3 个关键条款或功能点} - 报价（如有）：{价格/商务条件} - 附件：{如有方案 PDF 等} 背景：{是否有过会议讨论？对方的痛点是？} 要求： - 中文 - Subject：直接说明提案内容，不用"关于合作"这类模糊标题 - 正文 4 段，总计 150-200 字： 段 1：背景引用（基于上次沟通的某个点） 段 2：方案概述 + 核心价值 段 3：关键条款或亮点（可用简短列表） 段 4：建议下一步（阅读附件 / 确认细节） - 附上附件提示（如有） 返回格式： Subject: [主题] --- [正文]"

要点：提案邮件 Subject 必须直接说明内容（拒绝"关于合作"式模糊标题），正文 4 段引用上次沟通背景、概述方案价值、列出关键条款、给出下一步建议。

F. 引荐接收

LLM Prompt: "起草一封接收引荐的邮件。 引荐信息： - 引荐人：{姓名} - 被引荐对象：{姓名} @ {公司} - 引荐人的邮件内容摘要：{引荐语} 我的背景：{一句话介绍} 目的：{和被引荐对象想聊什么} 要求： - 中文 - Subject：Re: [引荐人邮件主题]（三方 CC 格式） - 正文 3 段，100 字以内： 段 1：感谢引荐人（CC 他） 段 2：向新认识的人自我介绍 + 为什么有价值聊 段 3：提议具体时间通话或 CTA - 语气：暖而不过分 返回格式： To: {被引荐人邮箱} CC: {引荐人邮箱} Subject: Re: [原主题] --- [正文]"

要点：引荐接收采用三方 CC 结构——To 写被引荐人、CC 写引荐人，正文首段感谢引荐人，全程保持"暖而不过分"的语气。

六、Step 5：发送邮件与 wrapper 调用链

默认行为是起草，不发送。只有用户明确说"发送"/"帮我发"时才执行发送。

发送时通过 PATH 调用 wrapper，无需拼接脚本路径：

email-ops \ --to "{收件人邮箱}" \ --subject "{主题}" \ --body "{正文}"

这里的email-ops是一个薄转发 wrapper。仓库的 wrapper 机制（详见 docs/d21-symlink-skill.md 与 scripts/lib/skill-wrappers.sh）设计目标很明确：弱模型（小参数模型）经常拼错脚本绝对路径（漏workspace-前缀、下划线与短横线错位等），因此为单一入口的 skill 统一提供<skill-name> <cmd>的 PATH 调用风格。部署时 email-ops.sh 会被ln -sfn软链到~/.openclaw/bin/email-ops，ensure_openclaw_bin_in_path再把~/.openclaw/bin幂等注入~/.zshrc/~/.bashrc的 PATH。wrapper 本身只是一个exec转发壳：

#!/usr/bin/env bash set -euo pipefail SELF="${BASH_SOURCE[0]}" while [ -L "$SELF" ]; do SELF="$(readlink -f "$SELF")"; done SCRIPT_DIR="$(cd "$(dirname "$SELF")" && pwd)" exec python3 "$SCRIPT_DIR/scripts/send_email.py" "$@"

注意 wrapper 通过readlink -f解析软链，保证SCRIPT_DIR始终指向技能真实目录，因此无论从~/.openclaw/bin还是直接调用都指向同一个 send_email.py。

发送实现：send_email.py 的底层逻辑

send_email.py 是真正的发送核心，全部使用 Python 标准库。其环境变量语义：

命令行参数方面，--to与--subject必填；正文二选一：--body（直接传纯文本正文）或--body-file（从文件读取，正文较长时更稳妥，读取失败会返回Body file not found错误并退出码 1）。

底层发送逻辑要点：

• 端口分叉：当SMTP_PORT == 465时使用smtplib.SMTP_SSL（一开始就建 SSL 连接）；否则走smtplib.SMTP+starttls()（STARTTLS 加密，端口 587 或 25），连接超时 30 秒；
• From 头构造：用email.utils.parseaddr解析SMTP_FROM，再以formataddr生成显示名 <地址>格式，与 SKILL.md 中"完整姓名 + 公司名"的发件人规范一致；
• 消息结构：MIMEMultipart("alternative")+MIMEText(body, "plain", "utf-8")，即纯文本 UTF-8 邮件；
• 输出为 JSON：成功返回{"ok": true, "to": "...", "message": "sent"}，失败返回{"ok": false, "to": "...", "error": "..."}并以退出码 1 退出，便于 Agent 程序化解析；
• 精细化异常分类：SMTPAuthenticationError（认证失败）、SMTPRecipientsRefused（收件人拒绝）、SMTPDataError（数据错误，可能是垃圾邮件拦截）、SMTPConnectError（连接失败，会提示检查SMTP_SERVER/SMTP_PORT）、TimeoutError（连接超时）。

发送后确认

检查 Sent 文件夹（通过邮件客户端 browser 访问 或 IMAP SENT 路径） 确认：消息是否在 Sent 中可见？

若无法在 Sent 中确认，不得声称已发送成功，应如实报告状态。

七、Step 6：输出状态报告

每次操作结束后输出结构化报告，便于用户与后续流程读取：

MAIL OPS REPORT ─────────────── 发件账号： 收件人： 邮件类型： 主题： 草稿： [邮件正文] 状态：drafted / sent / blocked / awaiting-approval 后续建议： - 若无回复，{N} 天后跟进 - 跟进方式：[邮件 / 微信 / LinkedIn]

状态字段取值包括：drafted（仅起草）、sent（已发送）、blocked（被拦截/失败）、awaiting-approval（等待用户批准发送）。

八、跟进时间参考

SKILL.md 给出的跟进节奏表是邮件运营的核心策略依据：

关键原则：跟进不是简单重发——无回复后要改变切入角度；两次无回复后应暂停，切换渠道（微信 / LinkedIn 等）或等待新的触机窗口。

九、常见错误与处理

这些处理规则与 send_email.py 的异常分类一一对应：认证失败对应SMTPAuthenticationError，发送拒绝对应SMTPRecipientsRefused/SMTPDataError。整体原则是宁可停下来询问用户，也不猜测或虚构。

十、在项目业务流中的调用场景

email-ops 并非孤立技能，它在 xiaobei 的多个业务 crew 技能中被明确作为发送链路的一环：

• lead-hunting：线索获取后通过 Email 联系，先校验email-ops所需环境变量是否齐全，若不全则跳过 Email 步骤并记录；齐全则使用 email-ops 发送，且每封邮件之间保持 30–60 秒间隔（批量防封策略）；
• investor-hunting：对 high 匹配度的投资人，使用 investor-outreach 生成话术，经用户确认后用 email-ops 发送；
• investor-outreach：发送邮件依赖email-ops；
• investor-materials：投资人触达需要发送材料时，"email-ops发邮件，investor-outreach写话术"形成分工。

由此可以看到完整的业务链路：话术生成（investor-outreach / lead-hunting）→ 用户确认 → email-ops 起草与发送 → 状态报告 → 按跟进表安排下次触达。这与 docs/d21-symlink-skill.md 记录的实测结论一致——email-ops 的 wrapper 转发链路（email-ops→send_email.py）已通过验证。

结语

email-ops 是一套"流程严谨、默认只起草、发送有据可查"的邮件操作技能：六类结构化 Prompt 模板保证内容质量与一致性，wrapper + PATH 调用消除弱模型路径拼接错误，纯标准库的 send_email.py 让部署零依赖，JSON 输出与精细化异常分类让 Agent 可以可靠地接入业务链路。对需要在获客、投资人沟通等场景中稳定发送商务邮件的团队来说，这套从起草规范到发送实现的完整方案可以直接复制使用：配置SMTP_SERVER/SMTP_USER/SMTP_PASSWORD（必要时加SMTP_PORT/SMTP_FROM）后，即可通过email-ops --to ... --subject ... --body ...完成发送，并依据跟进时间表安排后续触达节奏。

• 人工智能
• AI Agent
• 大模型
• AI 应用
• 媒体生成