なぜCursorは、すでにプロジェクトにある実装を使うのではなく、セットを書き換えたがるのでしょうか? このような不満はよくあることですが、Cursorは「 既存コードの再利用 」で明確に答えを示しています。「新しい実装を書くかどうか決める前に既存の実装を見つける」と明示的に求めなければ、デフォルトで新しいバージョンを生成する可能性があります。
なぜこんなことが起きているのでしょうか?
AI編集者は完成や生成に長けていますが、「生成」は「倉庫にとって最適」という意味ではありません。 特に古いプロジェクトや複数人による共同プロジェクト、モノリポジトリでは、より現実的なアプローチは既存のモデルに従うことです。 しかし、プロンプトが単に「ログインチェックの書き方を手伝ってください」や「キャッシュレイヤーを追加してください」だけなら、取得段階を飛ばして新しいホイールを直接作成することも十分可能です。
より実用的な解決策
最も直接的な方法は、モデルを変えるのではなく、ルールを前面に置くことです。 公式の考え方は、まずCursorにリクエストを「すでにこのコードがあるかどうか」に書き直してもらい、まずコードベースを検索し、その後新しい実装を作るかどうか決めるというものです。 着陸時には以下のことができます:
- プロジェクトルールにはこう記されています:まず類似した実装を探し、その後に新しいコードを生成してください。
- 質問をするときは、まず既存の使用状況、既存のコンポーネント、既存のサービスを見つけ、すぐに書き換えないでください。
- キーファイルの「@Files」やチャットコンテキストで明確なポイントを設け、数行のコードだけを操作させないでください。
この種の問題の核心は「カーソルは再利用されない」ではなく、まず再利用しなければならない作業命令を出すわけではありません。 順序が正しく設定されると、通常はより安定して動作し、既存のコードベースに適合するコラボレーターのような存在になります。
