跳转到主要内容
请务必阅读 何时使用 Devin 和 如何有效指示 Devin 获取更多关键提示。

添加新的 API 端点

良好做法
“创建一个新的端点 /users/stats，返回一个 JSON 对象，其中包含用户总数以及平均注册年龄。使用我们在 PostgreSQL 中现有的 users 表。你可以参考 statsController.js 中的 /orders/stats 端点了解响应结构。确保新的端点被纳入 StatsController.test.js 测试套件覆盖范围。”
为什么这种方式有效：
  • 清晰指定了路由和预期响应格式
  • 引用了现有代码作为模板
  • 明确了数据源（users 表）
  • 包含测试覆盖要求


糟糕做法
“添加一个用户统计端点。”
为什么这种方式失败：
  • 未具体说明需要包含哪些统计信息
  • 未提及数据源
  • 未参考现有模式
  • 缺少测试要求

用于展示数据的前端功能

良好做法
“在 UserProfileComponent 中添加一个下拉框，展示用户角色列表（admin、editor、viewer）。使用 DropdownBase 的样式。当选择某个角色后，调用现有 API 设置该用户角色。通过检查选择结果是否更新了数据库中的用户角色来进行验证。有关如何正确编写测试，请参考你的知识库。”
为什么这种方式有效：
  • 指明了具体组件
  • 列出了要包含的具体角色
  • 引用了已有样式组件
  • 定义了用户交互流程
  • 包含验证步骤


糟糕做法
“让用户个人资料页面更“用户友好”。加一个方式让他们能修改角色，并确认功能正常。”
为什么这种方式失败：
  • “用户友好”是主观概念
  • 未提到具体 UI 组件
  • 用户交互流程不清晰
  • 验证标准含糊不清

​
更多示例

​
良好示例

编写单元测试

“为 AuthService 的 login 和 logout 方法添加 Jest 测试，确保这两个函数的测试覆盖率至少达到 80%。参考 UserService.test.js 作为示例。实现完成后，运行 npm test -- --coverage，并确认覆盖率报告中这两个函数的覆盖率都大于 80%。同时确认在有效和无效凭证情况下测试都能通过，并且 logout 能正确清除会话数据。”
为什么是良好示例？ 有清晰的成功指标（80% 覆盖率），提供了可供 Devin 参考的示例（UserService.test.js），并且范围明确，包含具体的验证步骤。

迁移或重构现有代码

“将 logger.js 从 JavaScript 迁移到 TypeScript。我们已经有 tsconfig.json 和用于验证的 LoggerTest.test.js 测试套件。确保能够无错误编译通过，并且不要修改现有配置！迁移完成后，通过以下方式验证：1）运行 tsc 确认没有类型错误；2）运行 npm test LoggerTest.test.js 执行测试套件，确保所有测试通过；3）检查代码库中所有现有的 logger 方法调用在迁移后仍然可以正常工作且没有类型错误。”
为什么是良好示例？ 有清晰的模板（tsconfig.json）和测试套件用于即时反馈，还有具体的编译和验证步骤。

更新 API 或数据库查询

“我们将从 pg 切换到 sequelize（请阅读 https://sequelize.org/api/v6/identifiers）。请将 UserModel 的查询更新为使用 Sequelize 方法。参考 OrderModel 了解在当前代码库中的实现方式。实现完成后，通过以下方式验证：1）运行 npm run test:integration UserModel.test.js，检查所有集成测试是否通过；2）在包含 1000 个用户的测试数据集上检查执行时间，确认查询性能没有下降；3）运行 npm run test:e2e user-flows.test.js，验证所有 CRUD 操作在端到端流程中仍然保持数据完整性。”
为什么是良好示例？ Devin 可以模仿已知模式，并且有明确的参考（OrderModel.js）。提供了文档链接以便 Devin 知道需要查阅，同时包含具体的性能和功能验证步骤以及精确的测试命令。

​
不佳示例

开放式代码审查

“找出我们代码库中的问题并修复它们”
为什么不佳？ 这个请求过于笼统，而且要求 Devin 在单个会话中完成太多任务。Devin 在会话时间过长时可能会变得困惑。

视觉设计类任务

“完全照着这份 Figma 设计稿来实现”
为什么不佳？ 这是一个主观的视觉需求。Devin 无法像人类一样“看见”，也无法在细节上做到完全一致。它并未针对这类用例进行优化。

高度复杂且模糊的项目

“为我们的应用构建一个新的微服务架构。”
为什么不佳？ 这是一个非常庞大且缺乏结构的任务，需要进行架构决策和权衡取舍。更好的做法是将复杂项目拆分为多个阶段：
  1. 让 Devin 分析你的代码库
  2. 让 Devin 提出具体的架构方案
  3. 为实现每个部分创建单独的会话