（可选）使用 Ask Devin 为代码库划定范围
如果你的应用中已经有内部工具，在编写规格说明之前，可以使用 Ask Devin 来了解现有的实现模式。这样做在你希望新工具与现有架构保持一致时尤其有用：根据这些回答，在你的规格说明中补充具体的文件引用、组件名称和模式，这样 Devin 构建的新工具就能与你现有的内部工具保持一致。你也可以直接在 Ask Devin 中发起 Devin 会话，它会把已学到的全部内容作为上下文带入。
编写详细规格说明
内部工具——PTO（带薪休假）追踪器、管理面板、数据脚本、CLI 工具——至关重要，却很少被优先处理。它们非常适合交给 Devin，因为需求定义清晰，使用人就是你的团队，而且相比像素级完美的设计，“能正确运行”更重要。请具体说明该工具做什么、会存储哪些数据，以及会接入哪些服务。你提供的细节越多，首个版本就越接近你的实际需求。你也可以使用 Ask Devin 来迭代完善你的需求说明——粘贴一个初稿，让它根据你的代码库找出遗漏之处或提出改进建议。
添加凭证
通过 Secrets 向 Devin 传递所需的任何 API key 或令牌——在本例中是 Slack webhook URL。最简单的方法是在开始会话之前将它们存储为组织机密：
- 前往 Settings > Secrets 并添加
SLACK_WEBHOOK_URL - Devin 以环境变量的形式访问机密，因此这些值不会被硬编码进你的源代码中。
组织机密必须在启动会话之前添加——它们会在会话启动时被注入。或者，你也可以在会话期间通过聊天提供机密；当 Devin 发现缺失的环境变量时，它也会主动向你索取所需的任何凭证。
通过斜杠命令引导会话
会话开始后，你可以使用斜杠命令来引导 Devin 的工作流：
/plan— 让 Devin 在编写任何代码之前先创建一个详细的实现计划。在它开始构建之前，先审查该计划并提出修改建议。/test— 让 Devin 运行所有测试并验证其工作成果。在每个主要里程碑之后使用此命令，以便及早发现问题。/review— 让 Devin 在发起 PR 之前，自行审查代码中的错误、边界情况和风格问题。
/plan，每个功能构建完成后使用 /test，在发起最终 PR 之前使用 /review。Devin 负责构建并验证其可正常运行
Devin 将内部工具视为正式生产功能的一部分——它会编写代码、添加测试，然后在其内置浏览器中打开应用，验证 UI 是否能够端到端正常工作。
- 梳理你的代码库 —— 找到你的
DataTable和Calendar组件，阅读你的 Prisma schema，并研究现有的/internal/页面布局 - 创建数据库迁移 —— 通过 Prisma 添加
pto_requests和pto_balances表 - 构建页面 —— 在
/internal/pto下创建请求提交表单、经理审批队列、日历视图和余额仪表盘 - 集成 Slack —— 在提交请假请求以及请求被批准或拒绝时发送 webhook 通知
- 编写测试 —— 为带薪休假余额（PTO balance）计算和日期重叠检测编写单元测试，为请求端点编写 API 测试，为审批工作流编写集成测试
- 在其浏览器中打开应用 —— 访问每个页面，提交一条测试带薪休假（PTO）请求，从经理视图中批准它，验证日历是否更新，检查仪表盘数据，并测试诸如日期重叠和超出余额等边界情况
- 打开一个 PR —— 交付所有内容：迁移、种子脚本、应用代码、测试，以及解释如何使用该工具的 README 小节
通过 Devin Review 审查该拉取请求（PR）
Devin 创建 PR 后，使用 Devin Review 来审查这些更改。Devin Review 对你的代码库上下文有完整的理解，能够在整个 diff 中发现缺陷、安全问题以及风格不一致之处。