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

# 常见用例

> Windsurf 的常见用例，包括代码生成、单元测试生成、代码文档、API 集成和代码重构。

Windsurf 可满足多种场景的需求。但我们发现有些场景更为常见，尤其是在 Enterprise 客户的生产代码库中。

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

<AccordionGroup>
  <Accordion title="样板代码">
    **指南：** Windsurf 非常适合此类场景。它支持单行建议、多行建议以及中间填充（FIM）补全。

    **最佳实践：** 建议使用 Next Completion（`⌥ + ]`）、Context Pinning、@ Mentions 和 Custom Context，以获得最佳效果。
  </Accordion>

  <Accordion title="前端开发任务">
    **指南：** Windsurf 非常适合此类场景。它支持单行建议、多行建议以及中间填充（FIM）补全。

    **最佳实践：** 建议使用 Next Completion（`⌥ + ]`）、Context Pinning、@ Mentions 和 Custom Context，以获得最佳效果。
  </Accordion>

  <Accordion title="后端开发任务">
    **指南：** Windsurf 非常适合此类场景。它支持单行建议、多行建议以及中间填充（FIM）补全。

    **最佳实践：** 建议使用 Next Completion（`⌥ + ]`）、Context Pinning、@ Mentions 和 Custom Context，以获得最佳效果。
  </Accordion>
</AccordionGroup>

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

<AccordionGroup>
  <Accordion title="生成单元测试并自动移除冗余测试用例">
    **指南：** 通过 Windsurf 的基础用法，通常可稳定生成约 60–70% 的单元测试。边界情况的覆盖效果取决于用户对 AI 模型的提示质量。

    **最佳实践：** 使用 @ 提及。遵循提示工程最佳实践。示例：

    为 `@function-name` 编写单元测试，覆盖 X 和 Y 的所有边界情况（例如邮箱域名）。

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

  <Accordion title="为测试执行生成示例数据">
    **指南：** 适合“低垂果实”型用例。对于非常具体的 API 规范或内部库，Windsurf 对细节的了解可能不足，无法保证生成示例数据的质量。

    **最佳实践：** 明确说明你期望的接口。考虑任务的复杂度（以及一次性 LLM 调用是否足以完成）。
  </Accordion>
</AccordionGroup>

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

<AccordionGroup>
  <Accordion title="生成内联注释和代码说明">
    **指导：** Windsurf 非常适合此场景。使用 Windsurf Command 或 Windsurf Chat 生成内联注释和代码说明。

    **最佳实践：** 尽可能使用 @ 提及，并充分利用 Code Lens，确保 LLM 调用的上下文范围准确。
  </Accordion>

  <Accordion title="提出改进与澄清">
    **指导：** 通常使用 Refactor 按钮或 Windsurf Command 最适合请求改进建议；Windsurf Chat 则是询问解释或澄清的最佳位置。虽然描述略泛，但 Windsurf 在这两方面都能很好胜任。

    Windsurf Chat 是提出解释或澄清问题的最佳场所。

    这有点泛泛，但 Windsurf 在这两方面都应表现良好。

    **最佳实践**：使用下拉提示（即 Windsurf 的 Refactor 按钮）——我们提供了经过优化的自定义提示，更可能给出符合你预期的回答。
  </Accordion>

  <Accordion title="自动生成函数声明（C/C++/C#）">
    **指导**：最好的方法是先创建头文件，打开 Chat，在 cpp 文件中 @ 提及该函数，并让其编写头文件中的函数声明。然后对 cpp 文件中的每个函数依次执行此操作。这样能最大程度避免产生幻觉式内容。

    **最佳实践**：通常应避免用一次 LLM 调用尝试写完整个头文件。将任务细化能显著提升生成代码的质量。
  </Accordion>
</AccordionGroup>

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

<AccordionGroup>
  <Accordion title="在创建 API 的同时生成文档，并提供恰当的上下文">
    **指导**：这类似于测试覆盖率。对于许多库中通用的 API 规范部分，Windsurf 能够准确地加以补充说明；但对于你们内部特制的用例，Windsurf 可能难以达到你所期望的质量。

    **最佳实践**：与测试覆盖类似，尽可能引导 Windsurf 的 AI 模型以正确方式理解 API 的行为和意图，它就能产出更好的补充说明。
  </Accordion>

  <Accordion title="使用自然语言在仓库中搜索 API，并生成集成代码">
    **指导**：Windsurf 对单次 LLM 调用的上下文长度为 16,000 个 token。因此，根据你的搜索范围，Windsurf 的全仓搜索能力可能并不足够。针对整个仓库的多步、多次编辑任务将会在即将发布的 Windsurf 产品中提供支持。

    从本质上讲，这是一个多步问题，单次调用的 LLM（即当前所有 AI 代码助手的能力）并不擅长处理。此外，结果的准确性必须远高于其他场景，因为集成尤其脆弱。

    **最佳实践**：Windsurf 目前并不适合高效解决该问题。如果你想测试 Windsurf 现有能力的上限，请先制定分步计划，并在每一步以充分的细节单独提示 Windsurf，以更好地引导 AI。
  </Accordion>
</AccordionGroup>

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

<AccordionGroup>
  <Accordion title="代码简化与模块化">
    **指导**：使用 Windsurf Code Lenses 或 @ 提及来正确限定作用域，确保将所有必要上下文传递给 LLM。

    单次 LLM 调用的上下文长度是有限的。因此，取决于重构范围，这一限制可能带来问题（单次调用的 LLM 范式亦然）。面向整个仓库的多步、多处编辑任务现已在 Windsurf 的 [Cascade](/zh/windsurf/cascade) 中支持。

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

  <Accordion title="重构以提升可读性与可维护性">
    **指导**：使用 Windsurf Code Lenses 或 @ 提及来正确限定作用域，确保将所有必要上下文传递给 LLM。

    Windsurf 的单次 LLM 调用上下文长度为 16,000 个 token。因而，视重构范围而定，该上下文长度可能成为限制（单次调用的 LLM 范式亦然）。面向整个仓库的多步、多处编辑任务将于后续的 Windsurf 产品中提供支持。

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