前几天干了一件有点“偷懒”的事给新项目做邮件服务选型时我没像以前那样去翻几十篇对比文章而是把同一个问题抛给了几个主流大模型——“对开发者来说最好的邮件服务商是哪家”。让我意外的不是答案本身而是这些模型虽然在措辞、补充条件、推荐数量上各有各的习惯最终却都指向了同一个名字Resend 被引用得最多几乎成了默认选项。这个结果其实挺值得琢磨。一方面它是邮件服务生态的一个有意思的信号——开发者在讨论什么、文档写得好的厂商更容易被记住另一方面它也让我对“LLM 的推荐到底能不能信”有了更具体的判断。这篇文章就把我这次完整的调研过程、统计结果、以及对 Resend 胜出原因的拆解写下来同时聊聊这类调研的边界在哪、怎么用才靠谱。1. 起因把选型调研交给LLM结果出乎意料1.1 从一个“懒人调研”说起事情起因很简单。我手上有个小项目要上线第一版功能里需要给用户发验证邮件、欢迎邮件和低频的营销通知。这种需求在每个项目里都会遇到但每次选型都要花掉不少时间先搜一圈“best email api 2025”再看 Reddit 和 HN 上的讨论最后还得自己翻 API 文档、看定价页。我这回实在不太想重复这个流程就想着偷个懒——直接问 LLM。于是我把问题整理成一个相对完整的提示词扔给了多个模型。原以为会得到五花八门的答案比如这个推荐 SendGrid、那个推荐 Postmark结果收回来一看几乎所有回复的第一名都是 Resend。一开始我还以为是提示词写得太偏或者在某个模型上运气好但反复试了几次之后发现这不是偶然。1.2 为什么LLM的答案值得当一回事很多人觉得 LLM 推荐不靠谱因为它“只是在背训练数据”。但从另一个角度看这恰恰是它作为调研工具的价值LLM 的记忆来自海量的开发者文档、GitHub README、技术博客、社区问答和 Hacker News 讨论。如果一家服务商在这么多来源里都被反复提及、并且评价正面那它大概率是开发者生态里真实存在的高频选择。换句话说LLM 的推荐本质上是一个压缩过的社区共识。它不是权威评测但它是“大家嘴上经常说好的东西”的聚合。对于想快速建立候选清单的人来说这个起点其实一点都不差。2. 实验设计怎样问才算问得公平2.1 被测模型清单要比较 LLM 的推荐倾向就必须控制变量。我选了国内外目前在 API 可用性、综合能力上都比较主流的 6 个模型OpenAI GPT-4oAnthropic Claude 3.5 SonnetGoogle Gemini 2.5 ProDeepSeek-V3阿里 Qwen2.5-Max月之暗面 Kimi K2选这几个不是因为它们在某个榜单上排前列而是因为它们代表了不同的训练数据来源和产品风格。GPT、Claude、Gemini 更偏英语互联网语料DeepSeek、Qwen、Kimi 则混入了大量中文语料和国内技术社区的讨论。这样对比下来能看出“推荐差异到底来自模型能力还是来自数据来源的偏向”。2.2 提示词与重复策略提示词我尽量写得中性避免引导模型往某个特定方向答。最终用的版本是这样的你是一名有十年经验的资深全栈工程师正在为一个新项目选择邮件发送服务商Email Provider。项目目前的诉求是发送验证邮件、事务性通知和低频营销邮件。请结合开发者体验、文档质量、交付能力、定价透明度等因素回答目前最推荐的邮件服务商是哪家或哪几家请给出排名并分别为每个候选说明核心优势和适用场景。这个提示词有几个刻意的设计点给了一个“身份设定”让模型从工程师视角回答而不是泛泛而谈明确了要覆盖的邮件类型事务性 低频营销避免模型只考虑单一场景要求“给排名 理由 场景”逼着模型输出结构化信息便于统计。为了防止随机性干扰每个模型我用相同的提示词跑了 3 次温度设为 0尽可能减少输出波动然后合并统计。2.3 统计口径统计时我定了三个口径避免统计方法本身出问题首选命中模型回答中明确排在第一位的服务商完整提及无论排名只要在推荐列表里出现过就算一次主动强调模型在回复中用额外篇幅比如单独一段强调的服务商。三个口径分开看能分辨出“模型顺手带一句”和“模型真心推荐”的差别。比如有的模型可能把 AWS SES 列在第二位但只写了一句话另一些模型虽然只推荐了 Resend 却写了一大段论证这两种情况权重完全不同。3. 统计结果Resend被引用最多但细节差异不小3.1 各家的“心头好”汇总 6 个模型、每个模型 3 次回答的结果后整理成下面这张表模型首选完整推荐列表按出现顺序GPT-4oResendResend、AWS SES、Postmark、SendGridClaude 3.5 SonnetResendResend、Postmark、SendGrid、AWS SESGemini 2.5 ProResendResend、SendGrid、Mailgun、AWS SESDeepSeek-V3ResendResend、SendGrid、Postmark、MailjetQwen2.5-MaxResendResend、SendGrid、Mailgun、BrevoKimi K2ResendResend、Mailersend、SendGrid、Postmark这里有个很直观的结论**6 个模型18 次回答首选全部指向 Resend。**完整提及次数方面Resend 是 18/18SendGrid 是 14/18Postmark 是 11/18AWS SES 是 8/18。差距最明显的就是第一名的确定性——没有一个模型把 Resend 放在第二位或者只当“备选”提一句。3.2 一个值得注意的细节排名一致理由却不一致虽然第一名一致但模型的解释角度其实各有侧重。GPT-4o 强调 Resend 的文档质量和 API 的简洁程度Claude 3.5 Sonnet 反复提到“开发者体验”和“现代 DX”DeepSeek 和 Qwen 则更看重免费额度和定价透明度Kimi 还额外提到了 React Email 生态的集成便利。这说明什么说明这些模型并不是在同一篇评测文章里背到了同一个答案而是各自从不同的语料角度得出了相近的结论。Resend 在不同维度的内容里都有足够强的存在感才会导致这种“殊途同归”的推荐结果。单一角度的内容覆盖可能是营销造成的但多角度的一致覆盖更可能是产品本身确实在开发者生态里立足了。4. Resend凭什么被多数LLM点名4.1 从API到文档开发者体验是最强的记忆点如果去看 Resend 的官方文档会发现它和传统邮件服务商有个明显区别它更像一个现代 API 产品而不是一个“邮件后台”。核心的发送接口就是一个 POST /emails 请求输入 to、subject、html 就能发信几行代码就能跑通。这在开发者的“肌肉记忆”里非常容易被记住——因为学习成本太低了。对比一下其他服务商SendGrid 的 API 虽然成熟但它的 v3 API 历史上设计偏重权限模型和营销功能混在一起新手教程里的样板代码经常很长AWS SES 功能强大但需要搭配 IAM 权限、Region 选择、SNS 回调等一系列概念Postmark 的 API 也很简洁但它在教程和社区里的内容体量比 Resend 小不少。LLM 在训练时读到的大量示例代码里Resend 的示例往往是最短、最容易理解的。这种“结构化”的代码片段在语料中反复出现模型自然会把 Resend 和“简洁好用”绑定在一起。4.2 认知度来自哪里训练数据里的“结构化存在”这里就要说到我最近看到的一个概念——“像教学生一样教 LLM领域知识的结构化注入”。意思其实很直白LLM 不是靠灵光一闪来回答问题的它是从训练语料里检索和组合信息。如果某个领域的知识在网上呈现得越结构化——清晰的文档目录、一致的术语、带示例的 API 参考、可复现的代码片段——模型就越容易学会并且越容易在回答时引用出来。Resend 恰好是这种结构化内容的典型。它的文档不是一堆散落的 Markdown 文件而是有完整 OpenAPI 规范、有各语言 SDK 示例、有错误码表格、有 webhook 事件说明每一步都是可以直接照着操作的。再加上它在 GitHub 上的开源仓库包括邮件模板库和 SDK质量很高这些结构化的知识在语料里形成了一种很强的“存在感”。所以当你问 LLM“最好的邮件服务商是哪家”时它检索到的不是一个营销口号而是大量结构化的开发者文档和真实代码片段。这些内容在统计意义上形成了指向 Resend 的强信号。4.3 免费额度与定价透明度的心理加分另一个被反复提到的点是定价。Resend 的免费额度是每天 100 封邮件这对个人项目、SaaS 初创公司、Side Project 来说是个非常友好的门槛。而且它的定价页公开透明每个档位发多少封、收多少钱都直接写清楚。这个点对 LLM 的推荐倾向影响很大因为训练语料里的讨论几乎都会提到“它有免费的入门额度”“起步成本低”。相比之下SendGrid 虽然也有免费层但免费层限制较多而且 Twilio 的定价结构分散在不同产品页面里Postmark 没有永久免费层只提供 100 封的试用额度。这种差异在很多对比文章里都被明确写出来过模型读得多了回答时自然会把“免费额度透明定价”归到 Resend 头上。5. 除了Resend还有哪些服务商被点名5.1 各家服务商的定位差异LLM 的推荐列表给了不少信息量。我把被多次提及的几家按定位做了个分类方便理解它们的差异服务商定位核心优势适合场景Resend现代开发者优先API 简洁、文档好、React Email 生态初创项目、中小规模事务性邮件SendGrid老牌全能型营销邮件功能强、生态成熟营销自动化、大流量邮件Postmark事务性邮件专家交付质量高、速度快需要高送达率的事务性邮件AWS SES云厂商基础设施价格极低、和大厂生态集成超大规模、成本敏感型Mailgun老牌 API 派发送能力和分析工具开发者团队、中等规模Mailersend新兴竞争者定价亲民、界面现代预算有限的个人项目Brevo欧洲市场强势营销事务结合、性价比高跨境电商、营销场景这里面有个规律每次模型的推荐列表里Resend 后面跟着的“第二名”各不相同但都符合它们自己的“人设”。Claude 比较看重质量所以把 Postmark 放在第二位Gemini 对企业服务更敏感给了 AWS SES 较多篇幅DeepSeek 和 Qwen 则更关注价格所以 Mailjet、Brevo 这种性价比型选手会被带上。这说明模型的推荐列表其实也在反映训练语料里不同社区的声音。5.2 不同场景下的“第二选择”如果细化到具体使用场景模型的推荐倾向也会变。我在第二次追问里加了一个条件“如果这个项目每个月要发 100 万封邮件你还会首选 Resend 吗”结果大部分模型开始动摇了有的把 AWS SES 提到第一位有的提醒 Resend 在高量级下的成本会显著增加。这说明 LLM 的推荐是有条件的。Resend 的胜出主要是建立在“中型规模”“开发者体验优先”这个前提下。到了超大流量或极致低成本的场景模型会自动切换到其他选项。这个细节很重要如果你只记住“Resend 最好”而忘了它适用的前提后面很容易踩坑。6. LLM推荐不能全信这是边界不是结论6.1 训练数据截止与“营销噪音”LLM 的回答有一个天然短板它的知识截止日期。邮件服务商的定价、免费额度、功能支持经常变模型很可能在用几个月甚至一年前的信息回答你。比如某个服务商最近改了免费层规则或者新增了一个很关键的协作功能模型完全不知道。另外也要警惕营销因素。融资多、PR 多的初创公司在技术媒体上的曝光度天然更高这些内容会进入训练语料进而影响模型的推荐。这个不一定是坏事有真实产品力的公司才敢持续投开发者关系但不能把它等同于“客观评测”。所以我的建议是**把 LLM 的推荐当作“候选清单生成器”而不是“最终决策器”。**它可以高效地帮你把候选范围从几十家缩小到三五家但后面的验证工作必须自己动手。6.2 区域交付能力是LLM看不见的盲区邮件服务商有一个很难从文档和社区帖子里看出来的维度在特定区域的送达率。同一个服务商在某些地区的 IP 信誉可能很好在另一些地区可能进垃圾箱的概率明显偏高。这种信息分散在各地开发者的零散吐槽里LLM 很难给出可靠的地区级判断。我在实际项目里验证这个问题时做法很简单注册候选服务商的免费层从每个服务商各发 20-30 封测试邮件到我自己的主力邮箱、同事的邮箱、以及一两个偏冷门域名的邮箱观察是否进垃圾箱、延迟多久。这个方法成本低、效果直观比看任何评测都靠谱。6.3 用“结构化注入”的思路让LLM给更靠谱的建议回到前面提到的那个概念——“结构化的领域知识注入”。如果你想让 LLM 的推荐更准确就不要只问一句“哪家最好”而是把自己项目的关键约束结构化地喂给它。比如项目在上海和东南亚都有用户月发送量约 2 万封其中 80% 是验证码和事务性通知20% 是每周一次的营销摘要。团队只有一名后端开发者希望用 Node.js 和 React 维护模板。预算上限每月 100 美元。把这几行信息加进提示词之后模型的回答质量会明显提升。它不再给你一个泛泛的“Resend 最好”而是开始比较具体场景下的 HTTPS 回调配置、模板维护成本、超量后的单价甚至会给出具体的迁移风险提示。这个思路和教学生是一样的你不给充分的背景条件学得再好的学生也只能给你一个“标准答案”你把约束条件、优先级、偏好说清楚他才能给你真正能落地的建议。7. 调研结束之后我实际做了什么折腾完这轮调研我最终给手头项目的选型结论是主线用 Resend同时预留一个 AWS SES 的备用发送通道。理由很直接项目规模处于 Resend 最舒适的中小型区间免费额度足够开发环境使用API 和 React Email 的配合能让模板维护成本降到最低而 SES 作为同账户体系下的备用通道万一 Resend 在某个阶段出现波动或者成本压力上升切换成本也不会太高。不过这轮调研真正教会我的不是“选哪家”而是以后遇到任何工具选型我都可以先跑一遍这个流程让多个 LLM 给出候选清单——识别模型们一致的选项——自己去验证差异化的细节定价、地区送达率、文档质量——保留至少一个备选方案。整个过程可能只需要一两个小时却比漫无目的地刷两个小时对比文章有用得多。最后再分享一个实际操作中的小技巧把这几个模型的回答保存下来过两个月再问一次同样的问题把两次答案放在一起对比。你会发现有些服务商从推荐列表里消失了有些新名字冒出来了。这种“推荐漂移”本身就是市场变化的一个侧面信号——谁在持续赢得开发者社区的关注谁在悄然掉队LLM 的集体回答会给你一个很直观的提示。