Skip to main content
1

（可选）使用 Ask Devin 确定代码库范围

如果你不确定你的应用目前是如何处理支付的，或者不清楚在规格文档中应该参考哪些文件和模式，可以先使用 Ask Devin 进行分析：使用这些答案来完善你的规格文档——引用具体的文件、数据表名称和模式，这样 Devin 就能构建出能够自然融入你代码库的功能。你也可以直接在 Ask Devin 中启动 Devin 会话，它会将已经获取的所有信息作为上下文保留下来。
2

添加 Stripe 沙盒密钥

Devin 需要 Stripe 的 test-mode 密钥来创建结账会话并验证 webhook 处理程序。请始终使用沙箱凭据——切勿将生产环境的 Stripe 密钥提供给 Devin。最简单的方法是在开始会话之前，将其存储为组织密钥：
  1. 前往 Settings > Secrets 并添加：
  2. Devin 以环境变量的形式访问这些值，因此它们永远不会被硬编码到你的源代码中。
组织密钥必须在开始会话之前添加——它们会在会话启动时注入到环境中。或者，你也可以在会话期间通过聊天提供密钥；当 Devin 发现缺少环境变量时，也会主动向你请求所需的凭据。
3

提交你的 Checkout 规格说明

将你的规格说明——无论是来自 PRD、Linear 工单，还是一条详细的 Slack 消息——直接粘贴到 Devin 中。一个好的结账规格应涵盖定价档位、支付流程，以及成功支付后的处理逻辑。结构越清晰越好。A good spec for Devin includes three things: what to build (pricing tiers, checkout flow, webhook handler), where it lives (routes, tables, files), and how it fits in (existing patterns to follow). You don’t need to specify every implementation detail — Devin investigates your codebase to fill in the gaps.
4

Devin builds and verifies in the browser

Devin reads your spec, explores the codebase for matching patterns, then implements across the full stack. Before opening a PR, it runs your app locally and opens its built-in browser to verify the checkout flow works end-to-end.Here’s what that looks like for the Stripe checkout example:
  1. Creates the migration — Adds the subscriptions table with columns for user_id, stripe_subscription_id, plan, status, and current_period_end
  2. Builds the pricing page — Creates the three-tier pricing cards at /pricing, each with a “Subscribe” button that posts to the checkout API
  3. Implements checkout session creation — Builds POST /api/checkout/sessions that creates a Stripe Checkout session with the correct price ID, customer email, and redirect URLs
  4. Adds the webhook handler — Implements POST /api/webhooks/stripe with signature verification, checkout.session.completed event handling, and database updates
  5. Builds the success page — Creates /checkout/success that fetches the Stripe session, displays the plan name, amount charged, and a “Go to Dashboard” link
  6. Writes tests — Tests for webhook signature verification (valid, invalid, missing), checkout session creation, and the plan-update database logic
  7. Opens the browser — Starts the dev server, navigates to /pricing, clicks “Subscribe” on the Pro tier, verifies the Stripe Checkout redirect works, and checks that the success page renders correctly after a test payment
  8. Opens a PR — Delivers all changes with a summary of what was implemented and how it was verified
The browser verification step catches issues that unit tests miss — a pricing card that doesn’t trigger checkout, a redirect URL that 404s, or a success page that fails to load session details. 如果你定义了本地测试 skill，Devin 会在其构建的每个功能上自动执行这些步骤。
5

Iterate from the PR

Once the PR is open, send follow-up prompts in the same session to extend or adjust the checkout flow.
6

Review the PR with Devin Review

Once Devin opens the PR, use Devin Review to review the changes. Devin Review has full context of your codebase and can catch bugs, security issues, and style inconsistencies across the diff. You can ask follow-up questions in the review chat — for instance, “Does the webhook handler validate the event type before processing?” — and Devin will answer grounded in the actual code.