Cursorの進階テクニック大全と問題解決

作者：プログラマー NEO 原文リンク

AI分野の従事者として、またAI支援プログラミングの深いユーザーとして。

以下の数文は、あなたが最も知っておくべき、そして最も役立つと思うことです。たとえ以下のテクニックを見なくても、数秒間だけでも目を通すことをお勧めします。

LLMのコンテキストは制限されており、コンテキストが多いほど、あなたの意図を捉えるのが難しくなります。
LLMの出力は 深刻に 制限されており、現在一般的に使用されているのは最大で 8192 トークンです。
Cursor、Windsurf、Copilot、Clineのいずれもあなたのアシスタントに過ぎません。常に参加し、主導権と意思決定権を握ってください。

現在のCursorの最新バージョンは0.44.10です。

Cursor 使用テクニック

エージェントモード使用テクニック

検索による指定の代替

理由：Cursorエージェントモード内の検索機能を強制的にトリガーします。彼が見つけた断片 + コンテキストは、手動で複数のファイルを指定して得られる結果よりもはるかに良いです（ファイルを指定すると、彼は冒頭の一二百行しか読み込まないため、あなたが修正したい関数を読み込まない可能性があり、その時にコンテキストには無駄な干渉情報が増えてしまいます。これが皆さんが言う「バカになる」という現象です）。

コンテキスト指定を削除し、エージェントモードの自動検索をトリガーします。

上記の図のように、コンテキスト指定内容が空であり、エージェントモードの自動検索をトリガーしています。

同時に、説明内で以下を提供するように変更します：

明確なメソッド名
重要なクラス名
関連する変数名
具体的な機能説明

例を挙げます：

请帮我实现一个方法，功能是将一个字符串转换为大写，方法名为 `toUpperCase`，类名为 `StringUtils`，字符串变量名为 `str`。

ドキュメント処理

理由：ドキュメントは追加情報であり、CHAT では最も重要な指示情報とガイダンス情報のみを保持してください。過剰な情報はモデルがあなたのニーズを理解する妨げになります。

機能モジュール：Cursor Settings -> Features -> Docs：

直接貼り付けを避ける：

編集ボックスに大量のドキュメントを直接追加しないでください。ドキュメントをドキュメント設定に追加し、編集ボックス内で @ 記号を使用してドキュメント設定をトリガーしてください。

ドキュメント設定機能を使用する

ドキュメント指定：

プロジェクト共有に必要なデータのみを提供し、すべてのプロジェクトのドキュメントを共有しないでください。
トレーニングデータではカバーできない内容、例えば：新しいライブラリのドキュメントや開発インターフェースのドキュメントなどを追加することをお勧めします。
ドキュメントは自分で書くのが最良です（要求は簡潔で、強い個人のコーディングスタイルを持つこと）、方法の使用チュートリアルや簡潔なテキスト説明を提供し、スライスとインデックスが容易になるようにしてください。

ドキュメントリンク設定方法：

https://github.com/username/repo/blob/main/docs/doc.md

GitHub リポジトリを使用して文書を保存し、管理と更新を容易にします。
また、クラウドストレージサービス（例：アリババクラウド OSS）を使用することもできます。

ローカル文書を指定するには、Cursor 設定でローカル文書を有効にします。Cursor Settings -> Beta -> Notepads：

左側のサイドバーの下部にある Notepads に文書を追加します：

コンテキスト管理

理由：Cursor はアシスタントであり、意思決定の専門家ではありません。時には人が少し考えて決定を下すことが、Cursor には難しいこともあります。

コンテキストオーバーフローを避けるために、過剰な文書を提供しないでください。
重要な指示が無視されないようにしてください。
すべての情報ではなく、必要なコンテキスト情報を優先的に提供してください。
すべての問題を解決するために CHAT に頼ることは幻想です。問題を分解し、一つの問題を解決するために一つの CHAT を使用してください。

Lint 設定

理由：一部のプロジェクトでは余分な修正が発生し、時間を浪費します。ほとんどの場合、人は一目で問題が何かを理解できます。

自動 lint をオフにすることをお勧めします。
必要な場合は @lint を使用して手動でトリガーし、過度な自動化による干渉を避けてください。

フロントエンドチームへの注意

UI にバグがあると議論するよりも、インターフェースのスクリーンショットを提供した方が、思わぬ発見があるかもしれません。

Cursor ルール

Cursor ルールをうまく活用し、プロジェクトのルートディレクトリに .cursorrules ファイルを作成できます。Cursor は chat/composer でこのファイルの定義を参照します。
Cursor ルール内でプロジェクトで使用されるすべてのライブラリ（必要なもの）、UI スタイル、コーディング規範、プロジェクトモジュール定義などを指定してください。

https://cursor.directory/ には多くのルールが参考としてありますので、自分で定義することもできます。

よくある質問への対処

文字化けが発生した場合はどうすればよいですか？エラー例（友人とのチャットスクリーンショットから）：

グローバル utf-8 を使用してください。

中英日三言語混在で、46 ヶ所修正しましたが、いずれも文字化けはありませんでした。

与えられた文字化けの例と、その自動修正による正しい内容のスクリーンショットを添付します。

検索が不正確です：

より正確なキーワードを提供し、曖昧な説明を避けてください。
完全なメソッド名/クラス名/変数名などを使用してください。

agent モードの使用方法は？

あなたのバージョンがサポートしている場合、composer ページまたはポップアップの下部にあるチャットボックスの右下隅に以下のオプション（normal と agent）が表示されます。agent を選択すると白くなり、マウスをホバーすると agent モードを使用していることが表示されます。

checkpoints は戻らないのですか？

各 checkpoints の横には restore ボタンがあり、クリックすることでその時の状態に戻ることができます。

checkpoints が多すぎてどこに戻るかわからない場合や、checkpoints がなく restore ボタンがないバージョンにも適用されますか？

もしあなたが A メッセージを送信し、cursor が 1、2、3 の作業を行った場合、これらの作業を気にしないのであれば、A メッセージをダブルクリックし、再度 submit をクリックしてください。すると上記のポップアップが表示され、continue and revert を選択することで、cursor が A メッセージに基づいて再度リクエストを送信します。必要がない場合は、画面内の cancel をクリックしてキャンセルできます。

composer にカスタム（自分で提供した Key）モデルを設定するにはどうすればよいですか？

可能ですが、公式の Key のみです。

非公式の Key は、中継地点ではどうでしょうか？方法はありません。

cursor の composer はユーザーが設定したカスタムエンドポイントを使用しません。このようなニーズがある場合は、Cline を試してみてください。これは非常に使いやすい agent です（欠点：checkpoints がなく、行レベルの処理により一度に ctrl + z で元に戻せないため、タイムラインに多くの変更過程の汚れたバージョンが残ることになります。これは私が最も嫌う点です）。

新機能を実装したが、コードが複数のファイルに散らばっている場合は？

コンテキストを提供する必要はなく、agent モードのチャットボックスでファイル名と関連する必要なインターフェースの説明および新機能の説明を提供するだけで構いません（必要でない場合は特にコンテキストを指定しないでください。特にファイルが数百行から千行の場合は）。

AI にプロジェクトを要約させ、開発ガイドを生成させたいが、コードを変更させたくない場合はどうすればよいですか？

まず第一に、LLM のコンテキストと出力は制限されていることを明確にする必要があります。したがって、通常の Chat モードは必ず使用できません。なぜなら、すべてのコードを一度に提供することは不可能であり、それに対して数万行の開発ガイドを生成することも不可能だからです。
したがって、エージェント機能を持つツールを使用する必要があります。例えば、Cursor ComposeのエージェントモードやClineツールです。これらのツールは本質的に、1人の意思決定者と複数の実行者で構成されており、意思決定者がタスクを完了するために必要な操作手順を策定し、それを実行者に実行させます。意思決定と実行はそれぞれ独立した一回のチャットです。

したがって、考え方は非常にシンプルです。

プロジェクトファイルディレクトリのインターフェースを取得し、意思決定者が読み方ガイドを生成します。これは、あなたのリーダーがプロジェクトの読み方を教えてくれるようなものです。
実行者は、意思決定者が生成した読み方ガイドに基づいて、各ファイルを読み込み、ファイル内容の概要や関数インターフェースの概要を生成し、その読み取り結果を/docsディレクトリ内のプロジェクトと同じ構造のmdファイルに保存します（例：src/hello/prompt.py（いくつかのプロンプト定数を提供）=> docs/src/hello/prompt.md、src/hello/fillPrompt.py（プロンプト内で定義された変数などの情報を操作するためのいくつかのツール関数を提供）=> docs/src/hello/fillPrompt.md）。
すべての実行者が読み終えた後、思考者に渡し、各フォルダごとにまとめます（例えば：docs/src/hello/にはprompt.mdとfillPrompt.mdがあり、それらを整合させてまとめるとdocs/src/hello.mdが得られます）。このようにして再帰的に上に向かって繰り返し、最終的なdocs.mdが得られます。これが私たちが必要とするプロジェクト開発ガイドです。
実装：（続く、内容が多いため、必要に応じて続けます）Clineを使用する場合は、プロジェクトディレクトリとファイル構造を取得するためのMCPツールを作成し、既に閲覧および要約されたファイルをマークアップおよび取得できる必要があります。