AI がコードベースのスタイルを壊さないようにカーソル ルールを設定する

Cursor を使用して最初の 1 か月間、エージェントの編集はすべてうまくいきましたが、まだ間違っていると感じました。リポジトリでスペースが使用されているタブ、名前付きのコードベースでのデフォルトのエクスポート、CI が拒否するスタイルで書かれたテストなどです。修正ではプロンプトが改善されませんでした。それはルールファイルであり、正しく設定されていました。

カーソルは、リポジトリ内の .cursor/rules からルールを読み取ります。まず、パッケージ マネージャー、インポート順序、命名規則、コードベースで使用される一般的なデフォルトとは異なる 2 つまたは 3 つのパターンなど、交渉の余地のないものをカバーする 1 つのプロジェクト レベルのルール ファイルから始めます。約 50 行以内に収めてください。誰も保守しないルール ファイルは、モデルが無視することを学習するノイズになります。

過小評価されている機能は、ディレクトリごとのルールです。私たちのコンポーネントディレクトリには、関数コンポーネントのみ、プロップはインラインで入力され、デフォルトのエクスポートはなしというルールが適用されます。サーバー ディレクトリには別のものが追加されます。クライアント側のインポートはなく、すべてのハンドラーが入力を検証します。この分割は、グローバル ファイルに記述したものよりも出力品質に優れた効果をもたらしました。これは、モデルが参照するのは、モデルが接続しているファイルに適用されるルールのみであるためです。

3 つのルールは、純粋な繰り返しによってその地位を獲得しました。まず、「編集後、既存の lint コマンドを実行し、発生したすべてのエラーを修正します。」 2 番目: 「好みのスタイルではなく、編集中のファイルのインポート スタイルに一致させてください。」 3 番目: 「変更に新しい依存関係が必要な場合は、インストールする代わりに立ち止まって尋ねてください。」最後のパッケージは、必要なパッケージを diff で 5 つ見つけた後に作成されました。

私がやめたこと: すべてのチャット メッセージでスタイルの指示を繰り返すことです。ルールを設定すると、プロンプトで意図 (何を構築するか、何を回避するか) が説明され、ルール ファイルがハウス スタイルを処理します。プロンプトは短くなり、出力はより一貫性のあるものになりました。これはゲーム全体に当てはまります。

メンテナンスの習慣の 1 つは、エージェントが同じ間違いを繰り返した場合、チャットで叱るのではなくルールを追加することです。チャットの修正は会話とともに機能しなくなります。ルールファイルは複合されます。私のルール ファイルは 1 週間に約 2 行ずつ増加しており、各行にはバグ修正が含まれています。

よくある質問:

Q: ルール ファイルはカーソルを遅くしますか?

Ａ：特に目立ちません。これらはプロンプトとともにコンテキストに挿入されます。実際の代償は、ルール ファイルが肥大化して注目が薄れてしまうことです。そのため、私はコードベースが大きくなりすぎたルールに上限を設け、ルールを削除しています。

Q: ルールはリポジトリにコミットする必要がありますか?

A: はい、チーム全体に利益をもたらしたい場合は、リンター構成のように扱います。個人の設定は、プロジェクト ファイルではなくユーザー レベルのルールに保持します。

Q: ルールは、単に適切なシステム プロンプトを作成することとどのように異なりますか?

A: ルールはスコープ内のすべてのリクエストに自動的に適用され、セッションをまたいで存続し、コードとともにバージョン管理されます。頭の中にあるシステム プロンプトはあなた以外の誰にも利益をもたらしませんが、新しいチャットを開始するたびに消えてしまいます。