构建 Stripe Checkout 流程
把结账需求说明和你的 Stripe 沙箱环境密钥交给 Devin，即可得到一个可用的支付流程——定价页面、Checkout session、webhook 处理程序和确认页面——并在浏览器中完成验证。（可选）使用 Ask Devin 确定代码库范围
如果你不确定你的应用目前是如何处理支付的，或者不清楚在规格文档中应该参考哪些文件和模式，可以先使用 Ask Devin 进行分析：使用这些答案来完善你的规格文档——引用具体的文件、数据表名称和模式，这样 Devin 就能构建出能够自然融入你代码库的功能。你也可以直接在 Ask Devin 中启动 Devin 会话，它会将已经获取的所有信息作为上下文保留下来。
添加 Stripe 沙盒密钥
Devin 需要 Stripe 的 test-mode 密钥来创建结账会话并验证 webhook 处理程序。请始终使用沙箱凭据——切勿将生产环境的 Stripe 密钥提供给 Devin。最简单的方法是在开始会话之前，将其存储为组织密钥：
- 前往 Settings > Secrets 并添加：
STRIPE_SECRET_KEY— 你的测试模式 secret key（密钥），可在 Stripe Dashboard 中获取STRIPE_WEBHOOK_SECRET— 你的 webhook endpoint settings 中的 signing secret（签名密钥）
- Devin 以环境变量的形式访问这些值，因此它们永远不会被硬编码到你的源代码中。
组织密钥必须在开始会话之前添加——它们会在会话启动时注入到环境中。或者，你也可以在会话期间通过聊天提供密钥；当 Devin 发现缺少环境变量时，也会主动向你请求所需的凭据。
提交你的 Checkout 规格说明
将你的规格说明——无论是来自 PRD、Linear 工单，还是一条详细的 Slack 消息——直接粘贴到 Devin 中。一个好的结账规格应涵盖定价档位、支付流程，以及成功支付后的处理逻辑。结构越清晰越好。一个好的 Devin 规格说明应包含三部分内容：要构建什么（定价档位、结账流程、webhook 处理器）、它位于哪里（路由、表、文件），以及它如何融入现有系统（需要遵循的现有模式）。你不需要指定每一个实现细节——Devin 会分析你的代码库来填补空白。
Devin 在浏览器中构建并验证
Devin 会阅读你的规格说明，探索代码库中匹配的模式，然后在整个技术栈上实现这些改动。在打开 PR 之前，它会在本地运行你的应用，并打开其内置浏览器，验证结账流程是否可以端到端正常运行。以下是 Stripe 结账示例中的实际表现：
- 创建迁移 — 添加
subscriptions表，并包含user_id、stripe_subscription_id、plan、status和current_period_end列 - 构建定价页面 — 在
/pricing创建三档定价卡片，每个卡片都有一个指向结账 API 的 “Subscribe” 按钮 - 实现结账会话创建 — 构建
POST /api/checkout/sessions，创建带有正确 price ID、客户邮箱和重定向 URL 的 Stripe Checkout 会话 - 添加 webhook 处理器 — 实现
POST /api/webhooks/stripe，包含签名校验、checkout.session.completed事件处理和数据库更新 - 构建成功页面 — 创建
/checkout/success，获取 Stripe 会话并展示方案名称、支付金额以及一个 “Go to Dashboard” 链接 - 编写测试 — 为 webhook 签名校验（有效、无效、缺失）、结账会话创建以及方案更新的数据库逻辑编写测试
- 打开浏览器 — 启动开发服务器，导航到
/pricing，在 Pro 档点击 “Subscribe”，验证 Stripe Checkout 重定向是否正常工作，并检查在测试支付后成功页面是否能正确渲染 - 打开 PR — 提交包含所有更改的 PR，并附上实现内容及验证方式的摘要
使用 Devin Review 审查此 PR
一旦 Devin 创建了 PR，使用 Devin Review 来审查这些更改。Devin Review 对你的整个代码库有完整的上下文，能够在 diff 中发现缺陷、安全问题以及风格不一致之处。你可以在审查聊天中继续追问，例如 — “webhook 处理程序在处理之前是否会验证事件类型？” — Devin 会基于实际代码给出回答。