Windsurf は幅広いユースケースに対応しますが、なかでも本番コードベースで利用される Enterprise のお客様において、特に一般的なユースケースがいくつかあります。

​
コード生成

ガイダンス: このユースケースでは Windsurf が効果的に機能します。単一行候補、複数行候補、fill-in-the-middle（FIM）補完などの機能を活用できます。ベストプラクティス: Next Completion（⌥ + ]）、Context Pinning、@ Mentions、Custom Context を併用することで、最良の結果が得られます。
ガイダンス: このユースケースでは Windsurf が効果的に機能します。単一行候補、複数行候補、fill-in-the-middle（FIM）補完などの機能を活用できます。ベストプラクティス: Next Completion（⌥ + ]）、Context Pinning、@ Mentions、Custom Context を併用することで、最良の結果が得られます。
ガイダンス: このユースケースでは Windsurf が効果的に機能します。単一行候補、複数行候補、fill-in-the-middle（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ファイル内の各関数について同様に繰り返してください。これが途中のハルシネーションを防ぐ最善策です。ベストプラクティス: 1回のLLM呼び出しでヘッダーファイル全体を生成しようとするのは避けてください。作業を細かく分割することで、生成コードの品質が大幅に向上します。

​
APIドキュメントと統合

ガイダンス: これはテストカバレッジに近い考え方です。多くのライブラリに共通するAPI仕様の部分については、Windsurfが正確に注釈付けできます。一方で、社内固有のユースケース向けに特別に実装された部分については、期待する品質での対応が難しい場合があります。ベストプラクティス: テストカバレッジと同様、可能な限り、APIの意図や振る舞いをWindsurfのAIモデルにとって最適な思考手順で段階的に示すと、より適切な注釈付けが可能になります。
ガイダンス: 1回のLLM呼び出しにおけるWindsurfのコンテキスト長は16,000トークンです。したがって、検索範囲によってはリポジトリ横断の検索機能だけでは十分でない場合があります。リポジトリ全体にまたがるマルチステップ・マルチ編集のタスクは、今後のWindsurf製品でサポート予定です。これは本質的にマルチステップの課題であり、単発のLLM呼び出し（すなわち現行のAIコードアシスタントの機能）では対処が難しい領域です。さらに、統合は特に壊れやすいため、他のユースケース以上の高い精度が求められます。ベストプラクティス: 現時点のWindsurfでは、この課題を単独で解決するのは困難です。既存機能の限界を検証したい場合は、ステップごとの計画を作成し、各ステップについて詳細な指示を添えて個別にWindsurfへプロンプトし、AIを誘導してください。

​
コードのリファクタリング

ガイダンス: 必要なコンテキストがすべて LLM に渡るよう、Windsurf の Code Lenses または @ Mentions を使って適切にスコープを絞ってください。単一の LLM 呼び出しで扱えるコンテキスト長には上限があります。したがって、リファクタリングの範囲によってはこの制約が問題になることがあります（単発の LLM パラダイム全般に当てはまります）。リポジトリ全体にわたるマルチステップ・マルチ編集のタスクは、Windsurf の Cascade でサポートされています。ベストプラクティス: プロンプトはできるだけ細かく分解しましょう。リファクタリングの指示は簡潔で短いほど効果的です。
ガイダンス: 必要なコンテキストがすべて LLM に渡るよう、Windsurf の Code Lenses または @ Mentions を使って適切にスコープを絞ってください。Windsurf の単一の LLM 呼び出しで扱えるコンテキスト長は 16,000 トークンです。したがって、リファクタリングの範囲によっては、この制約が問題になることがあります（単発の LLM パラダイム全般に当てはまります）。リポジトリ全体にわたるマルチステップ・マルチ編集のタスクは、今後の Windsurf 製品でサポートされる予定です。ベストプラクティス: プロンプトはできるだけ細かく分解しましょう。リファクタリングの指示は簡潔で短いほど効果的です。