从一封邮件开始：我的第一个 Agent Skill 开发记录

项目地址：email-skills

1.前言

最近注意到了一些关于邮件礼仪的讨论。虽然电子邮件已经是一个很老的工具，但在联系导师、投递简历、汇报工作或者发送正式材料时，很多人还是会在按下发送键之前反复纠结：主题应该怎么写？称呼要不要特别正式？抄送谁比较合适？附件文件名有没有讲究？催促对方会不会显得不礼貌？

我最开始的想法很简单：既然这些问题具有比较固定的检查逻辑，能不能把它们整理成一个 Agent Skill，让 AI 在写邮件时自动遵循一套相对稳定的流程？

于是就有了 email-skills。这是一个用于起草、检查和改写中英文电子邮件的小型 Skill，也是我第一次完整尝试 Skill 的设计、封装、安装和开源发布。

这个项目大概不会有很多用户。毕竟它解决的问题很窄，一份写得足够详细的 Prompt 也能完成其中不少工作。不过对我来说，它更像是一次从零开始的实验：借一个容易理解的场景，搞清楚 Agent Skill 到底是什么，以及一套个人工作流要怎样才能被稳定地交给另一个 AI 使用。

2.Skill 和 Prompt 有什么区别

最初我也会把 Skill 理解成“保存起来的 Prompt”。实际做完之后，我觉得这个说法只对了一部分。

普通 Prompt 更像一次性的任务说明。每次需要时，我都要重新告诉模型邮件的背景、检查项、输出格式和注意事项。Skill 则是一个可以被 Agent 自动发现并按需加载的工作流，其中不只包含写作要求，还可以定义：

  • 什么情况下应该调用它；
  • 接到任务后按照什么顺序处理；
  • 哪些信息可以合理补全，哪些必须询问用户；
  • 哪些内容属于礼仪建议，哪些可能涉及法律或组织制度；
  • 最终应该交付什么格式的结果；
  • 在发送前必须检查哪些风险。

一个最小的 Skill 本质上就是一个目录和其中的 SKILL.md：

1
2
3
4
email-skills/
├── SKILL.md
├── README.md
└── LICENSE

SKILL.md 开头使用 YAML front matter 声明名称和描述：

1
2
3
4
---
name: email-skills
description: 检查、改写和起草中文或英文电子邮件，并根据沟通对象、关系、目的和风险调整主题、收件人、抄送、语气、正文、附件与落款。
---

其中 description 很重要，因为 Agent 会根据它判断用户当前的请求是否应该触发这个 Skill。正文则负责告诉 Agent 具体应该怎样完成任务。

所以 Skill 的价值不一定是提供模型完全不知道的新知识，也可以是把一套经常重复、容易遗漏的工作方法固化下来。它更接近一份写给 Agent 的操作手册，而不是某一句神奇咒语。

3.先弄清楚“规范”到底是什么

这个项目最花时间的部分，其实不是写 SKILL.md，而是调查国内是否存在统一的电子邮件规范。

一开始很容易产生一种印象：既然媒体、高校和企业经常宣传邮件礼仪，那么应该存在一份国家标准，规定主题、称呼、正文、回复时间和落款应该怎么写。但真正查找之后会发现，“有相关标准”和“有一套面向所有人的邮件写作国标”是两回事。

国内确实存在电子邮件相关的标准和管理文件，但它们的适用范围并不相同。例如，有些标准主要规定邮件系统、地址、协议和安全技术；DA/T 32—2021 公务电子邮件归档管理规则 关注的是公务电子邮件的形成与归档；涉及商业广告邮件、政务应用和保密时，也有相应的管理要求。

然而，普通人日常写邮件时常见的“主题要清楚”“不要滥用回复全部”“附件要在正文中说明”“催办时给出明确期限”等，大多仍属于通行礼仪或组织内部规则，不能随意说成全国统一的强制标准。

因此我在 Skill 中把依据分成了五个层级：

  1. 法律合规：法律、行政法规或部门规章明确要求的事项；
  2. 官方标准：现行国家标准或行业标准中的要求；
  3. 组织规则：学校、公司或项目内部制定的制度；
  4. 通行礼仪：广泛采用但通常不具有强制力的实践；
  5. 个人偏好：某位收件人或某个团队自己的习惯。

这个区分后来成了整个 Skill 最重要的设计原则。AI 很容易把“大家通常这样做”说成“国家规定必须这样做”，听起来很权威，实际却不准确。与其追求一个绝对正确的邮件模板，不如让它先说明结论属于哪个层级，并在用户询问现行规定时重新核验官方来源。

4.把邮件写作拆成一条工作流

确定边界之后，剩下的工作就是把平时模糊的写作经验拆成明确步骤。

目前这个 Skill 会先识别邮件场景、双方关系、沟通目的、期望动作和截止时间，然后判断用户是在起草新邮件、回复、转发、催办，还是只想做发送前检查。之后依次检查：

  • To、CC 和 BCC 是否放对了人；
  • 主题能否概括事项和动作；
  • 开头是否需要说明身份和联系缘由；
  • 正文有没有把核心信息与期望动作说清楚；
  • 日期、期限、附件名称和权限是否一致；
  • 语气是否适合双方关系；
  • 是否存在误发、隐私、保密或过度承诺的风险；
  • 落款能否让对方正确识别发件人。

例如，给导师发邮件和给熟悉同事发邮件显然不应该使用同一套语气。正式不等于堆砌敬语，礼貌也不等于把简单事项写成一篇公文。Skill 的目标不是把所有邮件变成统一模板，而是在保留用户原意的前提下，让对方更容易理解“发生了什么、需要做什么、什么时候完成”。

如果缺少的信息不影响整体起草，Skill 会使用 [姓名]、[课程名称]、[截止时间] 这样的占位符，而不是自行编造。只有当缺失信息会改变责任、期限或法律风险时，才应该停下来询问用户。

5.免责声明也是设计的一部分

在准备开源时，我还考虑了一个现实问题：如果有人使用这个 Skill 生成了不合适的邮件，是否会回来追究项目作者？

开源许可证不能让作者自动免除一切责任，但清楚说明工具的能力边界仍然很有必要。因此项目 README 的开头放置了醒目的限制与警告，说明它只用于辅助起草和检查，不构成法律、合规、保密或人力资源方面的专业意见，也不能保证输出适用于所有组织和场景。

项目还特别提醒使用者在发送前自行核对收件人、事实、日期、附件、权限和内部制度。对于国家秘密、商业秘密、个人信息、合同承诺、劳动争议或营销群发等高风险事项，应交给有权限的负责人或专业人员复核。

这并不是简单地在 README 里写一句“后果自负”，而是把风险控制同时写进 Skill 的实际行为：不虚构身份和附件、不擅自改变责任与期限、不轻易声称“保证合规”，发现敏感信息时主动提醒最小化披露。

我最后选择了 MIT License。它足够简单，也包含常见的“按现状提供”和免责条款。对这样一个小型实验项目来说，许可证、README 警告和 Skill 内部的行为约束结合起来，比单独放一段免责声明更完整。

6.让 Skill 可以一条命令安装

Skill 托管在 GitHub 后，可以直接通过 Skills CLI 安装：

1
npx skills add AndyYang12345/email-skills --agent codex --global

如果希望跳过交互确认：

1
npx skills add AndyYang12345/email-skills --agent codex --global --yes

安装器会读取仓库中的 Skill，并放入对应 Agent 的技能目录。用户也可以直接使用 Git 克隆：

1
git clone https://github.com/AndyYang12345/email-skills.git ~/.agents/skills/email-skills

安装完成后，可以显式调用：

1
2
$email-skills 帮我检查这封给导师的邮件，保持原意，不要过度恭敬：
……

也可以直接描述任务，让 Agent 根据 description 自动判断：

1
帮我起草一封申请实验室实习的邮件。

Skills CLI 还会通过匿名安装遥测统计 Skill 的安装次数，用于 skills.sh 的排行榜和发现页面。也就是说，一个公开仓库只要被用户通过 npx skills add 正常安装，就能够自动进入统计，不需要专门提交应用商店审核。

当然，能够安装不代表会有人使用。名称、描述、README、示例和项目本身是否真正解决问题，仍然决定了它能走多远。

7.这次小实验让我学到了什么

做完之后，我发现创建一个能运行的 Skill 并不难。真正困难的是把自己脑中默认存在的判断过程讲清楚。

如果只写“帮用户润色邮件”，模型当然也能工作，但每次输出可能使用不同的标准。只有继续追问：什么叫合适？信息不全怎么办？什么时候应该提醒风险？哪些说法需要查证？什么内容绝对不能编造？一套可复用的工作流才会逐渐成形。

这个过程也让我意识到，Skill 不一定非要宏大。它可以只是一个很小的工具，用来保存个人经常使用的工作方式。即使最后只有自己使用，把经验从零散 Prompt 整理成可安装、可版本管理、可分享的项目，本身也已经有价值。

另一方面，这个项目目前仍有明显局限：

  • 规范依据需要持续核验，不能依赖一次调查永久有效；
  • 不同行业、学校和公司的内部制度差异很大；
  • 邮件是否得体最终仍与具体的人际关系有关；
  • Skill 可以降低遗漏概率，但不能替用户承担发送责任；
  • 目前没有系统化测试集，效果主要依靠实际使用继续迭代。

所以我暂时不会把它包装成一个成熟产品。这更像是我的第一个 Agent Skill 样本：从一个具体问题出发，完成资料调查、规则设计、风险边界、项目封装、GitHub 开源和 CLI 分发的完整流程。

下一次再遇到适合固化的重复任务时，我应该就能更快地判断：它究竟只需要一条 Prompt，还是值得被整理成一个真正的 Skill。

8.项目链接

如果你也在尝试为自己的 Agent 编写 Skill，希望这篇记录能提供一点参考。项目仍处于实验阶段，欢迎阅读源码、提出建议，但请务必在真正发送邮件之前，再亲自检查一遍收件人、事实和附件。