企业官网建设流程全解析

前几天干了一件有点“偷懒”的事：给新项目做邮件服务选型时，我没像以前那样去翻几十篇对比文章，而是把同一个问题抛给了几个主流大模型——“对开发者来说，最好的邮件服务商是哪家？”。让我意外的不是答案本身，而是这些模型虽然在措辞、补充条件、推荐数量上各有各的习惯，最终却都指向了同一个名字：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-4o
• Anthropic Claude 3.5 Sonnet
• Google Gemini 2.5 Pro
• DeepSeek-V3
• 阿里 Qwen2.5-Max
• 月之暗面 Kimi K2

选这几个不是因为它们在某个榜单上排前列，而是因为它们代表了不同的训练数据来源和产品风格。GPT、Claude、Gemini 更偏英语互联网语料，DeepSeek、Qwen、Kimi 则混入了大量中文语料和国内技术社区的讨论。这样对比下来，能看出“推荐差异到底来自模型能力，还是来自数据来源的偏向”。

2.2 提示词与重复策略

提示词我尽量写得中性，避免引导模型往某个特定方向答。最终用的版本是这样的：

你是一名有十年经验的资深全栈工程师，正在为一个新项目选择邮件发送服务商（Email Provider）。项目目前的诉求是发送验证邮件、事务性通知和低频营销邮件。请结合开发者体验、文档质量、交付能力、定价透明度等因素，回答：目前最推荐的邮件服务商是哪家或哪几家？请给出排名，并分别为每个候选说明核心优势和适用场景。

这个提示词有几个刻意的设计点：

• 给了一个“身份设定”，让模型从工程师视角回答，而不是泛泛而谈；
• 明确了要覆盖的邮件类型（事务性 + 低频营销），避免模型只考虑单一场景；
• 要求“给排名 + 理由 + 场景”，逼着模型输出结构化信息，便于统计。

为了防止随机性干扰，每个模型我用相同的提示词跑了 3 次，温度设为 0（尽可能减少输出波动），然后合并统计。

2.3 统计口径

统计时我定了三个口径，避免统计方法本身出问题：

1. 首选命中：模型回答中明确排在第一位的服务商；
2. 完整提及：无论排名，只要在推荐列表里出现过就算一次；
3. 主动强调：模型在回复中用额外篇幅（比如单独一段）强调的服务商。

三个口径分开看，能分辨出“模型顺手带一句”和“模型真心推荐”的差别。比如有的模型可能把 AWS SES 列在第二位但只写了一句话，另一些模型虽然只推荐了 Resend 却写了一大段论证，这两种情况权重完全不同。

3. 统计结果：Resend被引用最多，但细节差异不小

3.1 各家的“心头好”

汇总 6 个模型、每个模型 3 次回答的结果后，整理成下面这张表：

这里有个很直观的结论：**6 个模型，18 次回答，首选全部指向 Resend。**完整提及次数方面，Resend 是 18/18，SendGrid 是 14/18，Postmark 是 11/18，AWS 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 后面跟着的“第二名”各不相同，但都符合它们自己的“人设”。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 的集体回答会给你一个很直观的提示。