跳转到主要内容
我们的示例应用是一个使用 Django Python Web 框架编写的在线教育平台。最近有人提交了一个 PR，将 SendGrid 邮件 API 集成到该应用中。在本教程中，我们将让 Devin 尝试实现自己的 SendGrid 集成，以展示它如何与第三方 API 协同工作。
在我们的提示中，我们向 Devin 提供了关于如何以及在何处集成 SendGrid hooks 的具体指令，并让 Devin 回退到上述 PR 合并之前的一个更早的提交哈希，以便为集成提供一个干净的起点。你可以在这里查看此次 Devin 实时会话。
Devin 检查代码库，确认应用中不存在会与本次集成冲突的既有邮件功能实现。
接下来它继续实现 SendGrid API，并提示我们提供 API 凭证。我们可以在 Devin 的环境中将这些凭证配置为 Secrets，这样之后它就可以将其作为环境变量（ENV）访问。
在拿到正确的 API 凭证之后，Devin 完成了对 SendGrid 的实现。
当我将 Devin 的 SendGrid 实现与我们在开头链接的实际已合并 PR 进行对比时，我注意到有几个显著的改进：
- Devin 在一个新的 email.py 模块中配置了 SendGrid，而不是和视图本身放在同一个文件中。它还会根据 SendGrid 的响应状态码返回 True 或 False，以指示邮件发送是否成功。
- Devin 使用了 Python 内置的 logging 模块而不是 print（这是 PR 审阅者特别指出的问题）。
- Devin 还让发件人邮箱（From email）可配置，而不是写死在代码里，同时在 ENV 变量不存在时添加了一个默认值。
- Devin 为其 mailInstructor 方法添加了异常处理。
在核心实现完成后，我可以让 Devin 通过在我的邮箱地址下添加一个 instructor 账号来测试应用。为了测试应用，它还需要依次安装并配置所有依赖，例如 PostgreSQL 服务器以及相关的 Python 库。
Devin 很快遇到了一个错误，这是因为我从未为我的 SendGrid 账户提供 FROM 地址。Devin 实际上在它的 Browser 中打开 API 文档，来弄清这里发生了什么，并理解错误信息和实现方面的最佳实践：
我可以回到 Secrets 对话框中，添加一个供 Devin 访问的 SENDGRID_FROM_EMAIL 变量。
我还让 Devin 使用默认的 SendGrid 用户名「apikey」，因为我尚未为该 API 设置子账户：
Devin 注意到我的请求和实现需求是可以泛化的，并提示我添加它今后可以使用的知识：
如果你愿意，你也可以进一步编辑这条知识，补充更多细节，以便在你团队未来计划开展的会话中复用这些策略。
在花了几分钟完成环境配置和搭建后，Devin 顺利结束了这次会话，我也在收件箱里看到了这封邮件。我并没有真正为 SendGrid 模板配置实际内容，但 API 请求已成功，因此 Devin 的工作就完成了！
如果我选择提交 PR，Devin 已经为我起草好了消息，其中详细说明了它在应用中所做的全部更改以及这些更改的工作方式：
立即注册试用 Devin，解决一个长期积压在你团队待办列表里的 API 集成难题。 
