跳转到主要内容
在指导 Devin 时，最重要的一点就是尽可能具体。就像你在请同事编写某段代码前，会先提供一份详细的需求或规格说明一样，对 Devin 也应如此。本指南将帮助你更好地组织和编写你的指令/提示，从而最大化 Devin 的价值。若想了解在更广泛场景下如何高效使用编程智能体的策略，请参阅我们的 Coding Agents 101 指南。

​
示例提示

在 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 和容器交互。
  • 好处： 鼓励复用已有的代码或设计方案。
在创建会话时，可以尝试使用 Prompt Improvement Button（提示优化按钮）（点击黄色警告圆圈图标查看反馈）
Prompt Improvement Button

​
最佳实践：建议与禁忌

建议做法：提供清晰的指令
  • 原因： 如果没有清晰的路径，或者存在太多可能的理解方式，Devin 可能会陷入僵局。
  • 做法：
    • 帮 Devin 做出重要决策和判断。
    • 提供具体的设计选型和实现策略。
    • 明确定义范围、边界和成功标准。
  • 示例： “通过在 order_items 表中的 order_id 和 product_id 列上添加复合索引，优化 orderService.js 中的 getOrderDetails 查询。重构该查询，将现有的相关子查询替换为与 products 表的 JOIN，用于获取产品详情。”
避免做法：将关键决策留给 Devin 自行决定
  • 原因： 含糊的指令可能会让 Devin 实现出的方案与你的真实需求不一致。
  • 做法：
    • 避免在缺乏指引的情况下，让 Devin 自行做出重要设计或实现决策的表述。这可能导致结果出乎预期。
  • 示例： 不要这样写：“提升我们数据库的性能。”
要做：选择Devin 擅长的任务
  • 原因：
    • 最大化效果： 将与 Devin 能力范围高度契合的任务交给它，可以用最少的精力和 ACUs 消耗获得最好的结果。让 Devin 执行远超出其当前能力范围的任务，往往会导致效果不佳。
  • 方法：
    • 阅读本指南：何时使用 Devin
    • 尤其对复杂或高级任务，提供示例、模块、资源和模板，方便 Devin 参考和遵循。
      • 分享文档站点的直接链接，让 Devin 能阅读诸如 API 请求体以及它可能尚不了解的特性等详细信息。
      • 分享你希望 Devin 查阅和学习的具体文件名。
    • 示例： 要做：「重构 Header 组件中的状态管理逻辑，改用 React 的 useReducer 钩子，以提升可扩展性和可维护性。确保保留现有全部功能，并为新的状态逻辑补充相应的单元测试。」
    • 示例： 要做：「参考 authTemplate.rs，保证错误处理方式的一致性。」
    • 示例： 要做：「参考 Sequelize 官方文档 https://sequelize.org/docs/v6/getting-started/ 中的迁移步骤。」
不要做：分配超出 Devin 核心能力范围的任务
  • 原因： 在缺乏充分指导的情况下，分配需要深度领域知识或大量设计决策的任务，会导致效率低下并浪费 ACUs。
  • 方法：
    • 避免在没有清晰说明或参考资料的情况下，让 Devin 执行需要大量创意或高层战略输入的任务。
    • 避免要求 Devin 完成依赖强视觉能力的任务，例如实现 Figma 设计；虽然 Devin 能查看网页，但它并不具备完美的“视力”。
    • 避免要求 Devin 创建移动应用，因为它无法使用真实手机，也不便于对自己的工作进行充分测试。
  • 示例： 不要做：「从零开始为我的网站创建一个全新的身份验证系统。」
  • 示例： 不要做：「把这个 Figma 模型图实现成一个 React 组件。」
  • 示例： 不要做：「构建一个由 AI 驱动的购物应用。」
应该做：通过完成部分任务进行协作
  • 原因： 有时由你来完成任务最后 20% 的工作会更快。
  • 方法：
    • 让 Devin 负责大部分实现工作，然后由你进行完善和打磨。
    • 使用 Devin 加速工作流中重复性的部分，而你专注于更关键的环节。
  • 示例： 应该这样做：“为新的 API 端点生成初始样板代码，然后我会把它集成到现有的认证系统中。”
不应该做：完全依赖 Devin 来完成整个复杂项目
  • 原因： 对需要细致理解或创造性解决问题的任务过度依赖 Devin，可能导致延误和次优结果。
  • 方法：
    • 避免将你明知需要大量人工参与才能有效完成的任务全部交给 Devin。
  • 示例： 不要这样做：“为我们的新生成式 AI 功能开发整个后端基础设施”
要做：建立清晰且频繁的检查机制
  • 原因： 来自你以及测试/检查/linters 的频繁反馈，可以确保 Devin 有效纠正错误。
  • 做法：
    • 使用测试（单元/集成）来确认正确性。
    • 保持构建校验、lint 检查和静态分析，以保证代码质量。
  • 示例： 要做：“在每次迭代后运行 npm test。”
  • 示例： 要做：“确保 CircleCI 上的流水线不会失败。”
  • 示例： 要做：“在推送任何提交之前通过 ESLint/Prettier 检查。”
不要：忽视反馈
  • 原因： 没有反馈，Devin 无法知道它的解决方案是否符合你的标准。
  • 做法：
    • 避免在未定义评估方式的情况下分配任务。
要做：设定清晰的检查点和子任务
  • 原因： 将复杂任务拆分为更小的检查点有助于 Devin 保持专注，并减少错误。
  • 方法：
    • 将任务拆分成可验证的子任务，并为每个子任务开启一个 Devin 会话。
    • 为每个子任务定义清晰的成功标准，并在需要时在子任务内部设置检查点。
    • 要求 Devin 在完成每个检查点或子任务后进行汇报。
示例：
  • 示例： 要做：“在处理数据集时，验证其至少包含 500 行数据，并且包含列 X、Y、Z。”
  • 示例： 要做：“在修改 API 时，确认该 endpoint 返回状态码 200，并包含所有必需字段。”
  • 示例： 要做：“在更新 UI 时，检查组件渲染时没有控制台错误，并且与设计规范一致。”
不要做：忽略具体的验证要求
  • 原因： 如果没有定义验证步骤，Devin 无法有把握地完成任务。
  • 方法：
    • 避免模糊的成功标准。
    • 不要将验证步骤隐含或置之不理。
  • 示例： 不要做：“确保它能正常工作就行。”
对于重复性或复杂的任务，我们建议使用并迭代优化 Playbooks。你也可以在高效使用 Playbooks中了解更多。Playbooks 是可复用、可共享的提示模板，用于简化任务委派。比如，如果你希望 Devin 持续处理 CI 构建失败问题，可以创建一个 Playbook，其中包含 Devin 每次应遵循的一般步骤。

​
结论

为任务提供足够的结构和清晰度，才能获得可靠且令人满意的结果。