如何编写高效的提示
在 Devin 仓库中，我希望你构建一个工具，用于监控 Devin 运行所在远程机器的 RAM 和 CPU 使用情况。为此，请执行以下任务：
- 创建一个在 devin.rs 启动时自动运行的后台任务。
- 该任务应与本次 Devin 会话中使用的所有 fork 出来的远程机器建立连接，并监控它们的 RAM 和 CPU 使用情况。
- 如果使用率超过可用资源的 80%，发出一种新的 Devin 事件类型来告警这一情况（查看我们是如何使用 Kafka 的）。
- 以合理的架构方式实现，确保不会阻塞其他操作。你应该理解 Devin 子代理所使用的所有容器之间是如何相互交互的。
为什么这种方式效果很好
提供有用的上下文
- 细节： 指定了 Devin 代码仓库以及更宏观的目标（监控资源使用情况）。
- 好处： Devin 能清楚地了解工作范围和领域。
给出循序渐进的操作指引
- 细节： 包含诸如“创建一个后台任务”（create a background task）和“在使用率达到 80% 时触发事件”（emit an event at 80% usage）这样的任务。
- 好处： 将工作拆解为逻辑清晰的步骤。
定义清晰的成功标准
- 细节： 将“成功”定义为在使用率达到 80% 时触发特定事件。
- 好处： Devin 明确知道需要达成的目标。
参考现有模式和代码
- 细节： 提到了 Kafka 和容器交互。
- 好处： 鼓励复用已有的代码或设计方案。
最佳实践：建议与禁忌
立场鲜明，具体明确
立场鲜明，具体明确
建议做法：提供清晰的指令
- 原因： 如果没有清晰的路径，或者存在太多可能的理解方式，Devin 可能会陷入僵局。
- 做法：
- 帮 Devin 做出重要决策和判断。
- 提供具体的设计选型和实现策略。
- 明确定义范围、边界和成功标准。
- 示例： “通过在 order_items 表中的 order_id 和 product_id 列上添加复合索引，优化 orderService.js 中的 getOrderDetails 查询。重构该查询，将现有的相关子查询替换为与 products 表的 JOIN，用于获取产品详情。”
- 原因： 含糊的指令可能会让 Devin 实现出的方案与你的真实需求不一致。
- 做法：
- 避免在缺乏指引的情况下，让 Devin 自行做出重要设计或实现决策的表述。这可能导致结果出乎预期。
- 示例： 不要这样写：“提升我们数据库的性能。”
充分利用 Devin 的优势
充分利用 Devin 的优势
要做：选择Devin 擅长的任务
- 原因：
- 最大化效果： 将与 Devin 能力范围高度契合的任务交给它，可以用最少的精力和 ACUs 消耗获得最好的结果。
- 做法：
- 阅读本指南：何时使用 Devin
- 提供示例、模块、资源和模板，方便 Devin 参考和遵循。
- 分享文档站点的直接链接，让 Devin 能阅读诸如 API 请求体以及它可能尚不了解的特性等详细信息。
- 分享你希望 Devin 查阅和学习的具体文件名。
- 连接 MCP 集成，让 Devin 能访问 Figma 设计、数据库、监控工具等资源。
- 示例： 要做：“重构 Header 组件中的状态管理逻辑，改用 React 的 useReducer 钩子函数，以提升可扩展性和可维护性。确保保留现有全部功能，并为新的状态逻辑补充相应的单元测试。”
- 示例： 要做：“参考 authTemplate.rs，保证错误处理方式的一致性。”
- 示例： 要做：“参考 Sequelize 官方文档 https://sequelize.org/docs/v6/getting-started/ 中的迁移步骤。”
- 原因： 即使 Devin 能处理复杂工作，在你提供足够上下文和清晰方向时，它的表现才会最好。
- 做法：
- 对需要领域知识的任务，提供相关文档、示例或参考资料。
- 对于视觉相关的任务，通过 Figma MCP 提供 Figma 文件、参考设计或详细规格——Devin 可以基于这些进行构建，但不会凭空设计视觉风格。
- 对于移动应用任务，请注意 Devin 无法使用手机模拟器，因此需要你提供明确的测试标准。
- 示例： 不要这样写：“让这个应用看起来更好看”——而是应提供具体的设计规范或 Figma 文件。
- 示例： 不要这样写：“提升我们数据库的性能”——而是要明确说明需要优化哪些查询以及要达成哪些指标。
利用反馈循环
利用反馈循环
要做：建立清晰且频繁的检查机制
- 原因： 来自你以及测试/检查/linters 的频繁反馈，可以确保 Devin 有效纠正错误。
- 做法：
- 使用测试（单元/集成）来确认正确性。
- 保持构建校验、lint 检查和静态分析，以保证代码质量。
- 启用 Devin Review 并配合 Auto-Fix，让 Devin 自动响应评审意见和 CI 失败——形成一个闭环，使 PR 在无需你反复介入的情况下迭代至可合并的质量。
- 示例： 要做：“在每次迭代后运行 npm test。”
- 示例： 要做：“确保 CircleCI 上的流水线不会失败。”
- 示例： 要做：“在推送任何提交之前通过 ESLint/Prettier 检查。”
- 原因： 没有反馈，Devin 无法知道它的解决方案是否符合你的标准。
- 做法：
- 避免在未定义评估方式的情况下分配任务。
设置检查点
设置检查点
要做：设定清晰的检查点和子任务
- 原因： 将复杂任务拆分为更小的检查点有助于 Devin 保持专注，并减少错误。
- 方法：
- 将任务拆分成可验证的子任务，并为每个子任务开启一个 Devin 会话。
- 为每个子任务定义清晰的成功标准，并在需要时在子任务内部设置检查点。
- 要求 Devin 在完成每个检查点或子任务后进行汇报。
- 示例： 要做：“在处理数据集时，验证其至少包含 500 行数据，并且包含列 X、Y、Z。”
- 示例： 要做：“在修改 API 时，确认该 endpoint 返回状态码 200，并包含所有必需字段。”
- 示例： 要做：“在更新 UI 时，检查组件渲染时没有控制台错误，并且与设计规范一致。”
- 原因： 如果没有定义验证步骤，Devin 无法有把握地完成任务。
- 方法：
- 避免模糊的成功标准。
- 不要将验证步骤隐含或置之不理。
- 示例： 不要做：“确保它能正常工作就行。”
让 Devin 自测自己的工作成果
让 Devin 自测自己的工作成果
Devin 具备完整的桌面环境——shell、IDE 和浏览器。请让 Devin 在发起 PR 之前先自行测试自己的工作成果：
- 启动应用： “运行
npm run dev，并验证新页面是否在/settings路径下正确渲染。” - 浏览器测试： “打开浏览器，访问登录页，并确认 OAuth 流程能够成功完成。”
- 视觉校验： “在桌面（1440px 宽）和移动端（375px 宽）下分别截屏，并确认布局与设计一致。”
- 录屏： “录制你从头到尾测试结账流程的屏幕操作。”
使用 Playbooks 和 Knowledge
使用 Playbooks 和 Knowledge
对于重复性或复杂任务，我们建议使用并迭代优化 Playbooks。你可以在 高效使用 Playbooks 中了解更多。Playbooks 是可复用、可共享的提示模板，用于简化任务委派。比如，如果你希望 Devin 处理持续发生的 CI 构建失败问题，可以创建一个 Playbook，其中包含 Devin 每次应遵循的一般步骤。对于需要在所有会话中由 Devin 持续记住的上下文——例如编码规范、常见缺陷及修复方法、部署工作流或如何使用内部工具——请使用 Knowledge。在相关场景下，Knowledge 条目会被自动调用，因此你不需要在每条提示中重复相同的指令。你可以将 Knowledge 关联到特定仓库，或设置为全局生效。