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

​
代码生成

指南： Windsurf 非常适合此类场景。它支持单行建议、多行建议以及中间填充（FIM）补全。最佳实践： 建议使用 Next Completion（⌥ + ]）、Context Pinning、@ Mentions 和 Custom Context，以获得最佳效果。
指南： Windsurf 非常适合此类场景。它支持单行建议、多行建议以及中间填充（FIM）补全。最佳实践： 建议使用 Next Completion（⌥ + ]）、Context Pinning、@ Mentions 和 Custom Context，以获得最佳效果。
指南： Windsurf 非常适合此类场景。它支持单行建议、多行建议以及中间填充（FIM）补全。最佳实践： 建议使用 Next Completion（⌥ + ]）、Context Pinning、@ Mentions 和 Custom Context，以获得最佳效果。

​
单元测试生成

指南： 通过 Windsurf 的基础用法，通常可稳定生成约 60–70% 的单元测试。边界情况的覆盖效果取决于用户对 AI 模型的提示质量。最佳实践： 使用 @ 提及。遵循提示工程最佳实践。示例：为 @function-name 编写单元测试，覆盖 X 和 Y 的所有边界情况（例如邮箱域名）。使用 @testing-utility-class 为 @function-name 编写单元测试。
指南： 适合“低垂果实”型用例。对于非常具体的 API 规范或内部库，Windsurf 对细节的了解可能不足，无法保证生成示例数据的质量。最佳实践： 明确说明你期望的接口。考虑任务的复杂度（以及一次性 LLM 调用是否足以完成）。

​
内部代码注释

指导： Windsurf 非常适合此场景。使用 Windsurf Command 或 Windsurf Chat 生成内联注释和代码说明。最佳实践： 尽可能使用 @ 提及，并充分利用 Code Lens，确保 LLM 调用的上下文范围准确。
指导： 通常使用 Refactor 按钮或 Windsurf Command 最适合请求改进建议；Windsurf Chat 则是询问解释或澄清的最佳位置。虽然描述略泛，但 Windsurf 在这两方面都能很好胜任。Windsurf Chat 是提出解释或澄清问题的最佳场所。这有点泛泛，但 Windsurf 在这两方面都应表现良好。最佳实践：使用下拉提示（即 Windsurf 的 Refactor 按钮）——我们提供了经过优化的自定义提示，更可能给出符合你预期的回答。
指导：最好的方法是先创建头文件，打开 Chat，在 cpp 文件中 @ 提及该函数，并让其编写头文件中的函数声明。然后对 cpp 文件中的每个函数依次执行此操作。这样能最大程度避免产生幻觉式内容。最佳实践：通常应避免用一次 LLM 调用尝试写完整个头文件。将任务细化能显著提升生成代码的质量。

​
API 文档与集成

指导：这类似于测试覆盖率。对于许多库中通用的 API 规范部分，Windsurf 能够准确地加以补充说明；但对于你们内部特制的用例，Windsurf 可能难以达到你所期望的质量。最佳实践：与测试覆盖类似，尽可能引导 Windsurf 的 AI 模型以正确方式理解 API 的行为和意图，它就能产出更好的补充说明。
指导：Windsurf 对单次 LLM 调用的上下文长度为 16,000 个 token。因此，根据你的搜索范围，Windsurf 的全仓搜索能力可能并不足够。针对整个仓库的多步、多次编辑任务将会在即将发布的 Windsurf 产品中提供支持。从本质上讲，这是一个多步问题，单次调用的 LLM（即当前所有 AI 代码助手的能力）并不擅长处理。此外，结果的准确性必须远高于其他场景，因为集成尤其脆弱。最佳实践：Windsurf 目前并不适合高效解决该问题。如果你想测试 Windsurf 现有能力的上限，请先制定分步计划，并在每一步以充分的细节单独提示 Windsurf，以更好地引导 AI。

​
代码重构

指导：使用 Windsurf Code Lenses 或 @ 提及来正确限定作用域，确保将所有必要上下文传递给 LLM。单次 LLM 调用的上下文长度是有限的。因此，取决于重构范围，这一限制可能带来问题（单次调用的 LLM 范式亦然）。面向整个仓库的多步、多处编辑任务现已在 Windsurf 的 Cascade 中支持。最佳实践：尽可能将提示拆解得更细。用于重构的指令越简洁、越短越好。
指导：使用 Windsurf Code Lenses 或 @ 提及来正确限定作用域，确保将所有必要上下文传递给 LLM。Windsurf 的单次 LLM 调用上下文长度为 16,000 个 token。因而，视重构范围而定，该上下文长度可能成为限制（单次调用的 LLM 范式亦然）。面向整个仓库的多步、多处编辑任务将于后续的 Windsurf 产品中提供支持。最佳实践：尽可能将提示拆解得更细。用于重构的指令越简洁、越短越好。