为什么要把 AI、表单和邮件连起来

很多网站会把 AI 做成一个孤立玩具，把联系表单做成另一个孤立模块。结果是：用户聊完一轮，什么都没沉淀；发起联系时，又得把需求重新说一遍。

正式站不该这样。

当前站点已经把这三件事收成一条最小可用链路：

• 访客可以先在 /ai-lab 里做需求梳理或媒体 brief
• 结果可以一键带入 /contact
• 联系页会通过服务端 SMTP 发出邮件，并保留来源与 AI 摘要

这意味着站内 AI 不再只是“会回答”，而是开始承担真实分诊动作。

现在已经跑通的部分

1. AI 结果可以直接带去联系页

当前文本助手与媒体规划结果，都支持继续带入联系页：

• source：标记来源于哪个入口
• message：保留原始需求
• aiSummary：保留 AI 预梳理结果

这样联系页收到的不是一句模糊的“想做个网站”，而是一段已经整理过的需求起点。

2. 联系表单会真实发邮件

当前联系表单不是摆设。

• 优先走 /root/.config/feishu-smtp.env
• 不可用时 fallback 到 /root/.config/qqmail.env
• 敏感凭证只留在服务端环境
• 表单输入会先经过 zod 校验

如果邮件链路暂时失败，页面也会明确提示用户回退到微信，不会让人误以为已经提交成功。

3. 已补最基本的安全与稳态

当前这条链路已经补上几项正式站该有的底线：

• 表单 honeypot 字段，降低最基础的垃圾提交
• 频率限制，避免短时间刷接口
• 服务端超时控制
• 失败时明确降级文案

这不是全部安全工作，但至少已经从 demo 级别跨进了可上线的底线范围。

为什么这条链路重要

对服务型网站来说，最有价值的不是一个“看起来很聪明”的 AI，而是一个能帮你更快收到高质量线索的系统。

当 AI 先把问题收敛，联系表单再带着摘要发邮件时，后端收到的信息会明显更可用：

• 用户是谁
• 想做什么
• 这次最在意的结果是什么
• AI 已经帮忙做了哪层整理
• 下一步应该继续微信聊、邮件跟进，还是直接约沟通

这就是 AI 分诊真正开始进入业务流程的地方。

下一步会继续补什么

后续会继续沿着这条线补强：

• 更明确的邮件模板与分流字段
• AI 摘要与媒体结果的统一归档
• 与 COS 结果层进一步打通
• 更完整的错误码、健康检查与降级策略

下一步建议

如果你正在做的是服务型官网、AI 入口页、或需要把图片 / 视频能力接进站点，最省时间的方式不是先谈模型，而是先让站点具备这条最小闭环：AI 分诊 → 联系表单 → 服务端邮件 → 人工跟进。