TimePPT

用 resend/mailgun ，做好域名 spf 和 dkim ，营销邮件和验证码发送子域名分开

@layxy 我现在每次大小需求都会充分讨论并写需求文档，并让其按照当前代码框架基础上进行修改，需求 feature 带来的逻辑变更会在文档框架成型时候就基本知晓，尽量避免开发中的未知。所以你提到的这种直接大改流程情况我没太出现过。

再说到使用，需求阶段充分讨论，把这些交互细节，逻辑梳理清楚，再让模型去做，至少不会给自己添堵。

有一说一，每天每个用户发送验证码有限制是好设计。接口防刷，如果一旦被刷你邮件发送服务不止是被爆账单，如果是自建邮箱，域名评级也会降，很容易被各收件方拉黑。

@NNCandy 是的，我曾经主持过几次类似的内部需求，最好的办法就是先统一内部意见，然后尽可能通过工程手段简化用户的配置成本（不管是面向公众的 C 端产品还是内部的 B 端工具）。Gateway 的好处是横向扩展性，而且即使不是统一的 SSO ，也可以通过引导用户去内部平台配置账号授权来代替本地 config 配置。
对话流内也不是说不能配，就是很麻烦。目前市面上做的体验比较好的是 Muse 这样的 Personal Agent ，预置一些 Connector ，一旦用户触发，则在对话里弹出账号授权提示，做配置，校验，然后生效。但总觉得如果是内部系统这么搞没必要。
其实你提供的 skill 只是 Agent 接入的一个语义 interface ，重点还是如何工程化服务本身。

你这个问题太大了，context 不足没法给到合适的建议。
比如鉴权，是不是都是内部系统，有没有统一的账号体系和 sso 登录，情况都不一样。
如果纯内部服务，有统一账号/SSO ，最好的办法是你做一个 gateway 服务统一包一层，gateway 做代理鉴权和返回，而不是每个用户都各种本地配 config

@rxswift 告别家 UI/UX 抄袭需要专利申请的。没记错的话抽象的纯 UI/UX 都是没法申请专利的，脱离具体软硬件的 UI 是没法申请专利，UX 需要具体到独到的交互流程。且专利权具有地域性。

这种事，大多时候最多公开声讨下。