> ## Documentation Index
> Fetch the complete documentation index at: https://docs.devin.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# 如何高效指导 Devin

> 如何获得最佳效果

在指导 Devin 时，最重要的一点就是**尽可能具体**。就像你在请同事编写某段代码前，会先提供一份详细的需求或规格说明一样，对 Devin 也应如此。本指南将帮助你更好地组织和编写你的指令/提示，以便更高效地使用 Devin。若想了解在更广泛场景下如何高效使用编程智能体的策略，请参阅我们的 [Coding Agents 101 指南](https://devin.ai/agents101)。

<div id="how-to-write-effective-prompts">
  ## 如何编写高效的提示
</div>

下面是一个示例提示，用来展示如何进行有效的指令编写：

<Note type="info">
  在 Devin 仓库中，我希望你构建一个工具，用于监控 Devin 运行所在远程机器的 RAM 和 CPU 使用情况。为此，请执行以下任务：

  * 创建一个在 devin.rs 启动时自动运行的后台任务。
  * 该任务应与本次 Devin 会话中使用的所有 fork 出来的远程机器建立连接，并监控它们的 RAM 和 CPU 使用情况。
  * 如果使用率超过可用资源的 80%，发出一种新的 Devin 事件类型来告警这一情况 (查看我们是如何使用 Kafka 的) 。
  * 以合理的架构方式实现，确保不会阻塞其他操作。你应该理解 Devin 子代理所使用的所有容器之间是如何相互交互的。
</Note>

<div id="why-this-works-well">
  ### 为什么这种方式效果很好
</div>

<CardGroup cols={2}>
  <Card title="提供有用的上下文" icon="circle-info">
    * **细节：** 指定了 Devin 代码仓库以及更宏观的目标 (监控资源使用情况) 。
    * **好处：** Devin 能清楚地了解工作范围和领域。
  </Card>

  <Card title="给出循序渐进的操作指引" icon="list-ol">
    * **细节：** 包含诸如“创建一个后台任务” (create a background task) 和“在使用率达到 80% 时触发事件” (emit an event at 80% usage) 这样的任务。
    * **好处：** 将工作拆解为逻辑清晰的步骤。
  </Card>

  <Card title="定义清晰的成功标准" icon="check">
    * **细节：** 将“成功”定义为在使用率达到 80% 时触发特定事件。
    * **好处：** Devin 明确知道需要达成的目标。
  </Card>

  <Card title="参考现有模式和代码" icon="code">
    * **细节：** 提到了 Kafka 和容器交互。
    * **好处：** 鼓励复用已有的代码或设计方案。
  </Card>
</CardGroup>

<div id="best-practices-dos-and-donts">
  ## 最佳实践：建议与禁忌
</div>

<AccordionGroup>
  <Accordion title="立场鲜明，具体明确" icon="bullseye">
    **建议做法：提供清晰的指令**

    * **原因：** 如果没有清晰的路径，或者存在太多可能的理解方式，Devin 可能会陷入僵局。
    * **做法：**
      * 帮 Devin 做出重要决策和判断。
      * 提供具体的设计选型和实现策略。
      * 明确定义范围、边界和成功标准。
    * **示例：** "通过在 order\_items 表中的 order\_id 和 product\_id 列上添加复合索引，优化 orderService.js 中的 getOrderDetails 查询。重构该查询，将现有的相关子查询替换为与 products 表的 JOIN，用于获取产品详情。"

    **避免做法：将关键决策留给 Devin 自行决定**

    * **原因：** 含糊的指令可能会让 Devin 实现出的方案与你的真实需求不一致。
    * **做法：**
      * 避免在缺乏指引的情况下，让 Devin 自行做出重要设计或实现决策的表述。这可能导致结果出乎预期。
    * **示例：** 不要这样写："提升我们数据库的性能。"
  </Accordion>

  <Accordion title="充分利用 Devin 的优势" icon="rocket">
    **要做：选择[Devin 擅长的任务](when-to-use-devin#evaluating-tasks-for-devin)**

    * **原因：**
      * **最大化效果：** 将与 Devin 能力范围高度契合的任务交给它，可以用最少的精力和 ACUs 消耗获得最好的结果。
    * **做法：**
      * 阅读本指南：[何时使用 Devin](when-to-use-devin)
      * 提供示例、模块、资源和模板，方便 Devin 参考和遵循。
        * 分享文档站点的直接链接，让 Devin 能阅读诸如 API 请求体以及它可能尚不了解的特性等详细信息。
        * 分享你希望 Devin 查阅和学习的具体文件名。
      * 连接 [MCP 集成](/zh/work-with-devin/mcp)，让 Devin 能访问 Figma 设计、数据库、监控工具等资源。
      * **示例：** 要做："重构 Header 组件中的状态管理逻辑，改用 React 的 useReducer 钩子函数，以提升可扩展性和可维护性。确保保留现有全部功能，并为新的状态逻辑补充相应的单元测试。"
      * **示例：** 要做："参考 authTemplate.rs，保证错误处理方式的一致性。"
      * **示例：** 要做："参考 Sequelize 官方文档 [https://sequelize.org/docs/v6/getting-started/](https://sequelize.org/docs/v6/getting-started/) 中的迁移步骤。"

    **不要：在复杂任务中省略必要上下文**

    * **原因：** 即使 Devin 能处理复杂工作，在你提供足够上下文和清晰方向时，它的表现才会最好。
    * **做法：**
      * 对需要领域知识的任务，提供相关文档、示例或参考资料。
      * 对于视觉相关的任务，通过 [Figma MCP](/zh/work-with-devin/mcp) 提供 Figma 文件、参考设计或详细规范——Devin 可以基于这些进行构建，但不会自行设计视觉风格。
      * 对于 Android 应用，Devin 可以在 [Android 模拟器](/zh/onboard-devin/environment/android-emulation) 上进行构建和测试。对于 iOS 应用，Devin 无法使用手机模拟器，因此需要你提供明确的测试标准。
    * **示例：** 不要这样写："让这个应用看起来更好看"——而是应提供具体的设计规范或 Figma 文件。
    * **示例：** 不要这样写："提升我们数据库的性能"——而是要明确说明需要优化哪些查询以及要达成哪些指标。
  </Accordion>

  <Accordion title="利用反馈循环" icon="rotate">
    **要做：建立清晰且频繁的检查机制**

    * **原因：** 来自你以及测试/检查/linters 的频繁反馈，可以确保 Devin 有效纠正错误。
    * **做法：**
      * 使用测试 (单元/集成) 来确认正确性。
      * 保持构建校验、lint 检查和静态分析，以保证代码质量。
      * 启用 [Devin Review](/zh/work-with-devin/devin-review) 并配合 [Auto-Fix](/zh/work-with-devin/devin-review#auto-fix)，让 Devin 自动响应评审意见和 CI 失败——形成一个闭环，使 PR 在无需你反复介入的情况下迭代至可合并的质量。
    * **示例：** 要做："在每次迭代后运行 npm test。"
    * **示例：** 要做："确保 CircleCI 上的流水线不会失败。"
    * **示例：** 要做："在推送任何提交之前通过 ESLint/Prettier 检查。"

    **不要：忽视反馈**

    * **原因：** 没有反馈，Devin 无法知道它的解决方案是否符合你的标准。
    * **做法：**
      * 避免在未定义评估方式的情况下分配任务。
  </Accordion>

  <Accordion title="设置检查点" icon="check-double">
    **要做：设定清晰的检查点和子任务**

    * **原因：** 将复杂任务拆分为更小的检查点有助于 Devin 保持专注，并减少错误。
    * **方法：**
      * 将任务拆分成可验证的子任务，并为每个子任务开启一个 Devin 会话。
      * 为每个子任务定义清晰的成功标准，并在需要时在子任务内部设置检查点。
      * 要求 Devin 在完成每个检查点或子任务后进行汇报。

    **示例：**

    * **示例：** 要做："在处理数据集时，验证其至少包含 500 行数据，并且包含列 X、Y、Z。"
    * **示例：** 要做："在修改 API 时，确认该 endpoint 返回状态码 200，并包含所有必需字段。"
    * **示例：** 要做："在更新 UI 时，检查组件渲染时没有控制台错误，并且与设计规范一致。"

    **不要做：忽略具体的验证要求**

    * **原因：** 如果没有定义验证步骤，Devin 无法有把握地完成任务。
    * **方法：**
      * 避免模糊的成功标准。
      * 不要将验证步骤隐含或置之不理。
    * **示例：** 不要做："确保它能正常工作就行。"
  </Accordion>

  <Accordion title="让 Devin 自测自己的工作成果" icon="desktop">
    Devin 具备完整的桌面环境——shell、IDE 和浏览器。请让 Devin 在发起 PR 之前先自行测试自己的工作成果：

    * **启动应用：** "运行 `npm run dev`，并验证新页面是否在 `/settings` 路径下正确渲染。"
    * **浏览器测试：** "打开浏览器，访问登录页，并确认 OAuth 流程能够成功完成。"
    * **视觉校验：** "在桌面 (1440px 宽) 和移动端 (375px 宽) 下分别截屏，并确认布局与设计一致。"
    * **录屏：** "录制你从头到尾测试结账流程的屏幕操作。"

    这样可以让 Devin 像你一样对自己的改动进行 QA——在你查看 PR 之前就完成质量检查。
  </Accordion>

  <Accordion title="使用 Playbooks 和 Knowledge" icon="book">
    对于重复性或复杂任务，我们建议使用并迭代优化 [Playbooks](/zh/product-guides/creating-playbooks)。你可以在 [高效使用 Playbooks](/zh/product-guides/using-playbooks) 中了解更多。Playbooks 是可复用、可共享的提示模板，用于简化任务委派。比如，如果你希望 Devin 处理持续发生的 CI 构建失败问题，可以创建一个 Playbook，其中包含 Devin 每次应遵循的一般步骤。

    对于需要在所有会话中由 Devin 持续记住的上下文——例如编码规范、常见缺陷及修复方法、部署工作流或如何使用内部工具——请使用 [Knowledge](/zh/product-guides/knowledge)。在相关场景下，Knowledge 条目会被自动调用，因此你不需要在每条提示中重复相同的指令。你可以将 Knowledge 关联到特定仓库，或设置为全局生效。

    <Tip>**Playbooks vs. Knowledge：** Playbooks 适用于与具体任务绑定的分步骤操作流程。Knowledge 适用于跨会话广泛适用的通用建议、约定和上下文。</Tip>
  </Accordion>
</AccordionGroup>