> ## 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 Desktop 的常见用例，包括代码生成、单元测试生成、代码文档编写、API 集成和代码重构。

总体来说，Devin Desktop 涵盖多种用例场景。不过，我们发现其中有些用例更为常见，尤其是在 Enterprise 客户的生产代码库中。

<div id="code-generation">
  ## 代码生成
</div>

<AccordionGroup>
  <Accordion title="样板代码">
    **建议：** Devin Desktop 很适合这一使用场景。Devin Desktop 提供单行建议、多行建议和中间填充 (FIM) 补全功能。

    **最佳实践：** 建议搭配使用 Next Completion (`⌥ + ]`) 、上下文固定、@ 提及和自定义上下文，以获得最佳效果。
  </Accordion>

  <Accordion title="前端开发任务">
    **建议：** Devin Desktop 很适合这一使用场景。Devin Desktop 提供单行建议、多行建议和中间填充 (FIM) 补全功能。

    **最佳实践：** 建议搭配使用 Next Completion (`⌥ + ]`) 、上下文固定、@ 提及和自定义上下文，以获得最佳效果。
  </Accordion>

  <Accordion title="后端开发任务">
    **建议：** Devin Desktop 很适合这一使用场景。Devin Desktop 提供单行建议、多行建议和中间填充 (FIM) 补全功能。

    **最佳实践：** 建议搭配使用 Next Completion (`⌥ + ]`) 、上下文固定、@ 提及和自定义上下文，以获得最佳效果。
  </Accordion>
</AccordionGroup>

<div id="unit-test-generation">
  ## 生成单元测试
</div>

<AccordionGroup>
  <Accordion title="生成单元测试并自动移除冗余测试用例">
    **说明：** 使用 Devin Desktop 的基础方式生成单元测试时，通常可以稳定完成 60–70% 的单元测试。边界情况的覆盖效果很大程度上取决于用户提供给模型的提示。

    **最佳实践：** 使用 @ 提及功能。遵循提示工程的最佳实践。示例如下：

    为 `@function-name` 编写单元测试，覆盖 X 和 Y 的所有边界情况 (例如电子邮件域名) 。

    使用 `@testing-utility-class` 为 `@function-name` 编写单元测试。
  </Accordion>

  <Accordion title="为测试执行生成示例数据">
    **说明：** 适合简单直接的用例。对于非常具体的 API 规范或内部库，Devin Desktop 往往无法充分掌握其中的细节，因此难以保证生成的示例数据质量。

    **最佳实践：** 明确说明你期望的接口。考虑任务的复杂性 (以及一次性 LLM 调用是否足以解决问题) 。
  </Accordion>
</AccordionGroup>

<div id="internal-code-commentary">
  ## 内部代码注释说明
</div>

<AccordionGroup>
  <Accordion title="生成行内注释和代码说明">
    **指南：** 对于这种用例，Devin Desktop 应该能很好地胜任。使用 Devin Desktop Command 或 Devin Desktop Chat 生成行内注释和代码说明。

    **最佳实践：** 尽可能使用 @ 提及和 Code Lenses，以确保 LLM 调用的作用域正确。
  </Accordion>

  <Accordion title="提出改进建议和澄清说明">
    **指南：** 一般来说，Refactor 按钮 / Devin Desktop Command 是提出改进建议的最佳方式。Devin Desktop Chat 最适合用来询问解释或澄清说明。这一项的界定稍微有些模糊，但 Devin Desktop 应该能很好地处理这两种情况。

    Devin Desktop Chat 最适合用来询问解释或澄清说明。

    这一项的界定稍微有些模糊，但 Devin Desktop 应该能很好地处理这两种情况。

    **最佳实践**：使用下拉提示 (也就是 Devin Desktop 的 Refactor 按钮) ——我们提供了专门设计的自定义提示，更有可能给出你预期的答案。
  </Accordion>

  <Accordion title="自动生成函数声明（C/C++/C#）">
    **指南**：完成这项工作的最佳方式是先创建头文件，打开聊天，@ 提及 cpp 文件中的函数，并让它为该函数编写对应的声明。然后对 cpp 文件中的每个函数逐步重复这一过程。这是确保整个过程中不出现幻觉的最佳方式。

    **最佳实践**：通常应避免通过一次 LLM 调用编写整个头文件。把工作拆分得更细，能显著提高生成代码的质量。
  </Accordion>
</AccordionGroup>

<div id="api-documentation-and-integration">
  ## API 文档与集成
</div>

<AccordionGroup>
  <Accordion title="在创建 API 时同步创建文档，并提供恰当的上下文">
    **Guidance**: 这与测试覆盖率类似：对于 API 规范中许多库都通用的部分，Devin Desktop 通常能够比较准确地加以完善。不过，对于专门为你的内部用例构建的内容，Devin Desktop 可能难以达到你期望的质量。

    **Best Practices**: 和测试覆盖率一样，尽可能引导 Devin Desktop 的模型理解 API 的工作方式以及应如何思考它，这样它就能更好地完善相关内容。
  </Accordion>

  <Accordion title="使用自然语言搜索仓库中的 API，并为集成生成代码">
    **Guidance**: Devin Desktop 单次 LLM 调用的上下文长度为 16,000 令牌。因此，根据你的搜索范围，Devin Desktop 的全仓库搜索能力可能不足以满足需求。面向整个仓库、涉及多个步骤和多处编辑的任务，将在即将推出的 Devin Desktop 产品中得到支持。

    从本质上讲，这是一个多步骤问题，单次调用的 LLM (即当前所有 AI 代码助手的现有能力) 并不擅长解决这类问题。此外，由于集成尤其脆弱，因此结果的准确性必须远高于其他用例。

    **Best Practices**: Devin Desktop 目前并不擅长解决这个问题。如果你想测试 Devin Desktop 当前功能的边界，可以先制定一个分步骤的计划，再针对每个步骤分别向 Devin Desktop 提供提示，并给出足够高层次的细节来引导 AI。
  </Accordion>
</AccordionGroup>

<div id="code-refactoring">
  ## 代码重构
</div>

<AccordionGroup>
  <Accordion title="代码简化与模块化">
    **指导**：使用 Devin Desktop Code Lenses 或 @ Mentions 来确保作用域设置合理，从而保证所有必要的上下文都能传递给 LLM。

    单次 LLM 调用的上下文长度是有限的。因此，具体是否会受到限制，取决于你的重构作用域；更广泛地说，这也是任何单次调用式 LLM 范式都会面临的问题。Devin Desktop 的 [Cascade](/zh/desktop/cascade) 现已支持整个代码仓库范围内的多步骤、多处编辑任务。

    **最佳实践**：尽可能将提示拆分得更细。用于重构的指令越简单、越短越好。
  </Accordion>

  <Accordion title="重组代码以提升可读性 / 可维护性">
    **指导**：使用 Devin Desktop Code Lenses 或 @ Mentions 来确保作用域设置合理，从而保证所有必要的上下文都能传递给 LLM。

    Devin Desktop 单次 LLM 调用的上下文长度为 16,000 个令牌。因此，具体是否会受到限制，取决于你的重构作用域；更广泛地说，这也是任何单次调用式 LLM 范式都会面临的问题。整个代码仓库范围内的多步骤、多处编辑任务将在即将推出的 Devin Desktop 产品中获得支持。

    **最佳实践**：尽可能将提示拆分得更细。用于重构的指令越简单、越短越好。
  </Accordion>
</AccordionGroup>