コパイロット編集とエージェント モード: IDE での複数ファイル編集とスタンドアロン開発
これまでのところ、インライン提案アシスタントおよびエージェントとして Copilot を検討してきました。 GitHub で働く自営業。ただし、非常に強力な中間領域があります。 副操縦士の編集 e エージェントモード、機能をもたらします 複数ファイルの編集とスタンドアロン実行を IDE で直接実行できます。編集する代わりに 一度に 1 ファイルずつ、複数のファイルに影響を与える変更を記述してそのままにすることができます。 Copilot がすべての変更を一貫して調整します。
この記事では、利用可能な高度な編集モードについて詳しく説明します。 編集モード ガイド付き複数ファイル編集の場合、 エージェントモード のために 自己修復による自律的な実行、 プランモード まずは計画を立てるために アクションの e 次の編集提案 (NES) 予測編集フローの場合 そして液体。
シリーズ概要
| # | アイテム | 集中 |
|---|---|---|
| 1 | 基礎と考え方 | セットアップとメンタリティ |
| 2 | コンセプトと要件 | アイデアから MVP まで |
| 3 | バックエンドのアーキテクチャ | APIとデータベース |
| 4 | フロントエンドの構造 | UIとコンポーネント |
| 5 | 迅速なエンジニアリング | MCP プロンプトとエージェント |
| 6 | テストと品質 | ユニット、統合、E2E |
| 7 | ドキュメント | README、API ドキュメント、ADR |
| 8 | デプロイとDevOps | ドッカー、CI/CD |
| 9 | 進化 | スケーラビリティとメンテナンス |
| 10 | コーディングエージェント | 自律的な開発 |
| 11 | 自動コードレビュー | AI を活用したレビュー |
| 12 | 現在位置 → 編集とエージェントモード | 複数ファイルの編集 |
| 13 | GitHub スパーク | AI ネイティブのマイクロアプリ |
| 14 | 副操縦士スペース | 共有コンテキスト |
| 15 | AIモデル | マルチモデルと選択 |
| 16 | カスタマイズ | カスタム命令 |
| 17 | 企業 | 組織的な導入 |
| 18 | 拡張機能 | コパイロット拡張機能 |
| 19 | 安全性 | セキュリティとコンプライアンス |
副操縦士の編集モード
Copilot は、IDE でいくつかの対話モードを提供し、それぞれが次の目的に向けて設計されています。 異なるレベルの自律性と複雑さ。違いを理解することは、 それぞれの状況に応じて適切なモードを選択することが重要です。
編集モードの比較
| モード | 自律性 | ほうき | IDEをサポート | 使用事例 |
|---|---|---|---|---|
| インライン提案 | 最小限 | 現在の行/ブロック | みんな | リアルタイムのコード補完 |
| 編集モード | 平均 | 指定されたファイル | VS コード、Visual Studio、JetBrains | 選択した複数のファイルにわたる調整された変更 |
| エージェントモード | 高い | プロジェクト全体 | VS コード、Visual Studio、JetBrains | 自己修復機能を備えた自律タスク |
| プランモード | チェック済み | プロジェクト全体 | VS コード、JetBrains、Eclipse、Xcode | 実行前の計画 |
| コーディングエージェント | 最大 | 完全なリポジトリ | GitHub (クラウド) | 完全自律型タスク (PR) |
コパイロット編集: 複数ファイルの編集
副操縦士の編集 それはあなたが説明することを可能にするモダリティです 自然言語の変更を複数のファイルに一度に適用します。 直接のコンテキストに基づいて動作するインライン提案とは異なり、編集は 選択したファイル間の関係が考慮され、一貫した変更が生成されます。
コパイロット編集ワークフロー
- ファイルを選択します: 編集する必要があるファイルを Copilot コンテキストに追加します。
- 変更について説明します: 達成したいことを自然言語で説明する
- 変更を確認します: Copilot は、提案された変更を含む各ファイルの差分を表示します
- 反復: 変更が完璧でない場合は、リクエストを調整します
- 適用する： 自分が正しいと思う変更は受け入れ、他の変更は拒否する
副操縦士の編集にアクセスする方法
異なる IDE でのアクティベーション
| FDI | ショートカット | メニュー | 注意事項 |
|---|---|---|---|
| VSコード | Ctrl+Shift+I (Win/Linux) / Cmd+Shift+I （マック） |
「表示」>「副操縦士の編集」 | サイドバーの専用パネル |
| ビジュアルスタジオ | Ctrl+Shift+. |
「編集」>「副操縦士の編集」 | Copilot のチャット パネルに統合 |
| ジェットブレインズ | Ctrl+Shift+I |
[ツール] > [コパイロット] > [編集] | IntelliJ IDEA、WebStorm、PyCharm など |
実践例: 複数ファイルのリファクタリング
コントローラーから検証ロジックを抽出して、 専用のミドルウェアで、コントローラー、ルート、テストを同時に更新します。
初期状態 - インライン検証を備えたコントローラー
// File: src/controllers/user.controller.ts (PRIMA)
import {{ '{' }} Request, Response } from 'express';
import {{ '{' }} UserService } from '../services/user.service';
export class UserController {{ '{' }}
constructor(private userService: UserService) {{ '{' }}}
async createUser(req: Request, res: Response) {{ '{' }}
// Validazione inline nel controller
const {{ '{' }} email, name, password } = req.body;
if (!email || !email.includes('@')) {{ '{' }}
return res.status(400).json({{ '{' }} error: 'Invalid email' });
}
if (!name || name.length < 2) {{ '{' }}
return res.status(400).json({{ '{' }} error: 'Name too short' });
}
if (!password || password.length < 8) {{ '{' }}
return res.status(400).json({{ '{' }} error: 'Password too short' });
}
const user = await this.userService.create({{ '{' }} email, name, password });
res.status(201).json(user);
}
async updateUser(req: Request, res: Response) {{ '{' }}
const {{ '{' }} id } = req.params;
const {{ '{' }} email, name } = req.body;
if (email && !email.includes('@')) {{ '{' }}
return res.status(400).json({{ '{' }} error: 'Invalid email' });
}
if (name && name.length < 2) {{ '{' }}
return res.status(400).json({{ '{' }} error: 'Name too short' });
}
const user = await this.userService.update(id, {{ '{' }} email, name });
res.json(user);
}
}
副操縦士の編集を求めるプロンプト
Estrai tutta la logica di validazione dal UserController in un
middleware dedicato. Crea:
1. Un file src/middleware/validation.middleware.ts con funzioni
di validazione riutilizzabili usando class-validator
2. Un file src/dto/user.dto.ts con le classi DTO per CreateUser e UpdateUser
3. Aggiorna il controller per rimuovere la validazione inline
4. Aggiorna src/routes/user.routes.ts per usare il middleware di validazione
5. Aggiorna i test in tests/controllers/user.controller.test.tsCopilot Edits は 5 つのファイルを分析し、調整された編集を生成します。結果を見てみましょう ファイルごとに。
生成されたファイル - src/dto/user.dto.ts
// File: src/dto/user.dto.ts (GENERATO da Copilot Edits)
import {{ '{' }} IsEmail, IsString, MinLength, IsOptional } from 'class-validator';
export class CreateUserDto {{ '{' }}
@IsEmail({{ '{' }}}, {{ '{' }} message: 'Invalid email format' })
email: string;
@IsString()
@MinLength(2, {{ '{' }} message: 'Name must be at least 2 characters' })
name: string;
@IsString()
@MinLength(8, {{ '{' }} message: 'Password must be at least 8 characters' })
password: string;
}
export class UpdateUserDto {{ '{' }}
@IsOptional()
@IsEmail({{ '{' }}}, {{ '{' }} message: 'Invalid email format' })
email?: string;
@IsOptional()
@IsString()
@MinLength(2, {{ '{' }} message: 'Name must be at least 2 characters' })
name?: string;
}
生成されたファイル - src/middleware/validation.middleware.ts
// File: src/middleware/validation.middleware.ts (GENERATO)
import {{ '{' }} Request, Response, NextFunction } from 'express';
import {{ '{' }} validate } from 'class-validator';
import {{ '{' }} plainToInstance } from 'class-transformer';
export function validateBody(dtoClass: any) {{ '{' }}
return async (req: Request, res: Response, next: NextFunction) => {{ '{' }}
const dtoInstance = plainToInstance(dtoClass, req.body);
const errors = await validate(dtoInstance, {{ '{' }}
whitelist: true,
forbidNonWhitelisted: true
});
if (errors.length > 0) {{ '{' }}
const messages = errors.flatMap(err =>
Object.values(err.constraints || {{ '{' }}})
);
return res.status(400).json({{ '{' }}
error: 'Validation failed',
details: messages
});
}
req.body = dtoInstance;
next();
};
}
更新されたファイル - src/controllers/user.controller.ts
// File: src/controllers/user.controller.ts (DOPO - senza validazione)
import {{ '{' }} Request, Response } from 'express';
import {{ '{' }} UserService } from '../services/user.service';
export class UserController {{ '{' }}
constructor(private userService: UserService) {{ '{' }}}
async createUser(req: Request, res: Response) {{ '{' }}
// La validazione è gestita dal middleware
const {{ '{' }} email, name, password } = req.body;
const user = await this.userService.create({{ '{' }} email, name, password });
res.status(201).json(user);
}
async updateUser(req: Request, res: Response) {{ '{' }}
const {{ '{' }} id } = req.params;
const {{ '{' }} email, name } = req.body;
const user = await this.userService.update(id, {{ '{' }} email, name });
res.json(user);
}
}編集モードとエージェント モード
編集モードとエージェント モードの基本的な違いは自律性のレベルにあります。 そして、Copilot が実行できるアクションの種類についても説明します。
操作上の違い
| 待ってます | 編集モード | エージェントモード |
|---|---|---|
| 作業ファイル | 明示的に選択されたファイルのみ | 自分でファイルを見つけて編集する |
| ファイルの作成 | 新しいファイルを作成しません | 新しいファイルやフォルダーを作成できます |
| コマンドの実行 | 端末コマンドを実行しません | コマンド (npm、build、test) を実行できます。 |
| 自己修正 | 手動によるフィードバックが必要です | エラーを検出して自己修正します |
| コンテクスト | 選択したファイル + 開いているファイル | ワークスペース全体 + ターミナル出力 |
| ユーザーの確認 | あらゆる変更のリクエスト | 端末コマンドの場合のみ必須 |
| スピード | 高速化 (コンテキストの減少) | 遅い (詳細な分析) |
| リスク | 低 (範囲が限定されている) | 中 (より自律的なアクション) |
エージェント モード: IDE での自律開発
エージェントモード Copilot の最も高度なモードです IDEで。編集モードとは異なり、エージェントはファイルシステムを参照できます。 ファイルを作成し、ターミナルでコマンドを実行します。そして最も重要なことは、 自己修正 何か問題が起こったとき。
自己修復: インテリジェントな自己修正
エージェントモードの最も特徴的な機能は、 自己修復。 エージェントは、エラーを引き起こすコード (コンパイル、lint、テスト) を生成すると、分析を行います。 エラー メッセージを自分で確認し、次の手順を繰り返して問題の修正を試みます。 成功するか反復制限に達するまでループします。
自己修復サイクル
- 世代： エージェントはリクエストに基づいてコードを作成します
- 確認する： ビルドまたはテストを実行して正確さを検証します
- エラー分析: エラーがある場合は、エラー メッセージ全体を読み取ります。
- 診断： 原因の特定 (型の欠落、インポートの誤り、構文)
- 修正： 修正を適用し、ステップ 2 に戻ります。
- 成功またはエスカレーション: N回繰り返しても失敗すると、ユーザーに助けを求めます。
処理されるエラーの種類
エージェントモードが自律的に管理するエラー
| エラーの種類 | Esempio | 戦略を修正する | 成功率 |
|---|---|---|---|
| TypeScript 型エラー | Property 'x' does not exist on type 'Y' |
プロパティの追加またはタイプの修正 | 高 (90% 以上) |
| インポートが欠落しています | Cannot find module '../services/user' |
正しいインポートを追加するか、ファイルを作成します | 高 (95%+) |
| 構文エラー | Unexpected token, expected ';' |
構文を修正します | 高 (95%+) |
| 依存関係が欠落している | Cannot find package 'lodash' |
実行します npm install |
高 (90% 以上) |
| テストは失敗しました | Expected 42 but received undefined |
テストを分析して実装を修正する | 中 (60-70%) |
| 実行時エラー | TypeError: Cannot read property of undefined |
null チェックを追加またはロジックを修正します | 中 (50-70%) |
| 構成エラー | Invalid configuration option 'x' |
設定ファイルを修正します | 中 (60-80%) |
| 複雑な論理エラー | 明確なメッセージのない不正確な結果 | 人間の助けが必要な場合があります | 低い (30-40%) |
エージェント モードを有効にして構成する方法
VS コード構成 - settings.json
// .vscode/settings.json
{{ '{' }}
// Abilita Agent Mode (abilitato di default nelle versioni recenti)
"github.copilot.chat.agent.enabled": true,
// Configura quali comandi l'agente può eseguire senza conferma
"github.copilot.chat.agent.autoApprove": {{ '{' }}
// Comandi che non richiedono conferma
"allowedCommands": [
"npm test",
"npm run lint",
"npm run build",
"npx tsc --noEmit"
],
// Comandi che richiedono sempre conferma
"blockedCommands": [
"rm",
"git push",
"npm publish",
"docker"
]
},
// Limite di iterazioni per il self-healing
"github.copilot.chat.agent.maxIterations": 5,
// File e cartelle che l'agente non può modificare
"github.copilot.chat.agent.protectedPaths": [
".env",
".env.*",
"secrets/",
"*.key",
"*.pem"
]
}安全ガードレール
エージェント モードには、潜在的に危険なアクションを防止するように設計されたガードレールが含まれています。 特に運用環境では、これらを正しく構成することが重要です。
デフォルトのアクティブ保護
- 各ターミナルコマンドで確認が必要
- ファイルにアクセスできません
.env - 実行できません
git push確認なしで - システム構成ファイルは変更されません
- 無限ループを避けるための反復の制限
- 確認なしでは依存関係をインストールできません
カスタマイズ可能な保護機能
- 自己承認コマンド一覧
- ブロックされたコマンドのリスト
- 保護されたルート (編集不可)
- 最大反復回数
- 単一操作のタイムアウト
- 機密性の高い操作に関する通知
計画モード: アクションの前に計画を立てる
プランモード のステップを追加するモードです。 実行前の計画。すぐにファイルの編集を開始するのではなく、 Copilot はリクエストを分析し、必要に応じて明確な質問をして、ビルドします。 最初に承認、変更、または拒否できる詳細な実行計画 コードが触れられていることを確認します。
プランモードを有効にする方法
異なる IDE でのアクティベーション
| FDI | 方法 | 詳細 |
|---|---|---|
| VSコード | Shift+Tab 副操縦士のチャットで |
エージェントモードとプランモードを切り替える |
| ジェットブレインズ | Copilot Chat ツールバーの「計画」アイコン | すべての JetBrains IDE で利用可能 |
| 日食 | コパイロット メニュー > プラン モード | Copilot パネルに統合 |
| Xcode | コパイロット メニュー > プラン モード | ネイティブサポート |
計画モードのワークフロー
- リクエスト： 自然言語でタスクを説明する
- 分析: Copilot はコードベースを分析し、関連するファイルを特定します
- 質問 (オプション): リクエストがあいまいな場合は、明確な質問をしてください
- 床： 以下を使用して構造化された計画を生成します。
- 作成、編集、または削除するファイル
- 操作の順序
- 変更間の依存関係
- 実行するコマンド
- レビュー： 計画を確認して変更することができます
- 実行： 承認後、計画は段階的に実行されます
プランモードを使用する場合
プランモードの理想的なシナリオ
| シナリオ | プランモードを選択する理由 | 代替 |
|---|---|---|
| 複雑なリファクタリング | 計画が必要なすべてのファイルに影響していることを確認したい | エージェントモードではファイルがスキップされる場合がある |
| 新しいマルチコンポーネント機能 | 実装前にアーキテクチャを検証したい | 編集モードでは手作業が多すぎる |
| ライブラリの移行 | 影響を受けるファイルの完全なリストを確認したい | エージェントモードではファイルを忘れてしまう可能性がある |
| 要件があいまいなタスク | 質問を明確にすることで不必要な作業を回避できます | エージェントモードは想定していて間違っている可能性があります |
| クリティカルコード | あらゆる変更を完全に制御したい | なし: プラン モードが最良の選択です |
Esempio Pratico: Plan Mode per Feature Complessa
Richiesta in Plan Mode
Aggiungi un sistema di notifiche in-app al progetto.
Requisiti:
- Modello Notification con titolo, messaggio, tipo, letto/non letto
- Service per CRUD notifiche
- Controller con endpoint REST
- Componente Angular con icona campanella e badge contatore
- WebSocket per aggiornamenti real-time
- Test per service e controller
Piano generato da Copilot
# Piano di Implementazione: Sistema Notifiche
## Domande Chiarificatrici
1. Vuoi persistere le notifiche su database o solo in memoria?
-> Risposta: Database (PostgreSQL con Prisma)
2. Le notifiche devono essere per utente specifico o broadcast?
-> Risposta: Per utente, con possibilità di broadcast
3. Quale libreria WebSocket preferisci?
-> Risposta: Socket.io (gia presente nelle dipendenze)
## File da Creare (5)
1. src/models/notification.model.ts - Schema Prisma e tipi
2. src/services/notification.service.ts - Business logic
3. src/controllers/notification.controller.ts - Endpoint REST
4. src/gateways/notification.gateway.ts - WebSocket gateway
5. frontend/src/app/components/notification-bell/ - Componente Angular
## File da Modificare (4)
1. prisma/schema.prisma - Aggiungere modello Notification
2. src/routes/index.ts - Registrare route notifiche
3. src/app.ts - Registrare WebSocket gateway
4. frontend/src/app/app.component.ts - Aggiungere notification-bell
## Comandi da Eseguire (3)
1. npx prisma migrate dev --name add-notifications
2. npm test -- --testPathPattern=notification
3. npm run build
## Ordine di Esecuzione
Phase 1: Backend (modello, service, controller)
Phase 2: WebSocket (gateway, eventi)
Phase 3: Frontend (componente, integrazione)
Phase 4: Test e verifica
## Stima: ~45 minuti di esecuzione agentNext Edit Suggestions (NES)
Next Edit Suggestions è una funzionalità che predice la sequenza di modifiche che probabilmente farai dopo un'operazione iniziale. Invece di suggerire solo il completamento della riga corrente, NES analizza il pattern della tua modifica e anticipa dove dovrai intervenire successivamente.
Come Funziona NES
Il meccanismo è intuitivo: fai una modifica in un punto del codice, e Copilot identifica automaticamente altri punti del file (o del progetto) che devono essere aggiornati di conseguenza. Un indicatore visuale appare nel gutter dell'editor, mostrando dove sono disponibili suggerimenti di modifica.
Interazione con NES
| Azione | Shortcut | Effetto |
|---|---|---|
| Navigare al prossimo suggerimento | Tab |
Il cursore si sposta al prossimo punto di modifica |
| Accettare il suggerimento | Tab (quando sul suggerimento) |
La modifica viene applicata |
| Rifiutare il suggerimento | Esc |
Il suggerimento scompare |
| Vedere tutti i suggerimenti | Icone nel gutter dell'editor | Indicatori visivi mostrano tutte le posizioni |
Casi d'Uso di NES
Scenari in cui NES Eccelle
| Scenario | Modifica Iniziale | Suggerimenti NES |
|---|---|---|
| Rinomina variabile | Rinomini userData in userProfile |
Suggerisce l'aggiornamento in tutti i punti dove la variabile è usata |
| Aggiunta parametro | Aggiungi un parametro options a una funzione |
Suggerisce di aggiornare tutti i chiamanti e il JSDoc |
| Cambio tipo | Cambi il tipo di ritorno da string a UserResponse |
Suggerisce aggiornamenti nei consumatori del valore |
| Aggiunta campo | Aggiungi un campo avatar all'interfaccia User |
Suggerisce aggiornamenti nelle factory, test, mapping |
| Cambio pattern | Converti un callback in async/await | Suggerisce la conversione in tutti i pattern simili nel file |
| Aggiunta import | Usi un nuovo tipo nel file | Suggerisce l'import statement corretto |
Esempio: Rinomina con NES
変数の名前を変更するとします data in userProfile
ファイル内に 15 個のオカレンスが含まれています。 NES がなければ、手動で検索して置換するか、
IDEリファクタリングを使用します。 NES では、このプロセスがシームレスになります。
NESでの編集の流れ
// Step 1: Rinomini la prima occorrenza
const userProfile = await fetchUserData(userId);
// ^^^^^^^^^^^ modifica manuale
// Step 2: NES mostra indicatori nel gutter su tutte le altre occorrenze
// Linea 15: [NES] data.name -> userProfile.name
// Linea 23: [NES] data.email -> userProfile.email
// Linea 31: [NES] return data; -> return userProfile;
// Linea 45: [NES] if (data) -> if (userProfile)
// Step 3: Premi Tab per navigare al primo suggerimento
// Step 4: Premi Tab per accettare
// Step 5: Ripeti fino a completare tutte le occorrenze
// Risultato: tutte le 15 occorrenze aggiornate con pochi Tabガター内のインジケーター
NES はエディターのガター (数字の左側の列) で視覚的なインジケーターを使用します。 行) を使用して、提案が利用できる場所を示します。 VS Code では、インジケーターは また、視覚的な確認を容易にするために、ツールチップに構文の強調表示も含まれています。 提案された変更の内容。
ファミコンの利点
- 繰り返し編集する場合は 3 ～ 5 倍高速に編集できます
- 部分的な名前変更エラーを減らす
- ファイル間でも機能します
- 意味論的なコンテキストを理解する
- 正規表現や検索置換は必要ありません
- 明らかではない変化も予測します
NES の制限事項
- (現時点では) VS Code でのみ利用可能
- 望ましくない変更を示唆する可能性があります
- 必ずしもすべての一致が見つかるわけではありません
- 品質はパターンの鮮明さによって決まります
- 複雑なリファクタリングは処理しません
- 提案を検討する際には注意が必要です
シンボルを意識した編集
のような言語の場合 C++ e C#、Copilot は統合されました 単純なパターンマッチングを超えたコンパイラレベルの理解 テキスト的な。ザ」シンボルを意識した編集 シンボル、タイプ、依存関係を分析します これにより、プロジェクト規模で意味的に正しいリファクタリング操作が可能になります。
仕組み
従来のテキストベースの編集とは異なり、シンボル認識編集では 含める言語サーバー プロトコル (LSP) 情報:
- ステートメント: シンボルが定義されている場所
- 参考文献: シンボルが使用されている場所
- 種類： 各シンボルの種類とその関係
- 範囲: 各シンボルの可視性
- 依存関係: どのファイルがシンボルに依存するか
シンボル対応言語のサポート
| 言語 | FDI | サポートレベル | サポートされている操作 |
|---|---|---|---|
| C++ | Visual Studio 2026 | 完了 | 名前変更、署名変更、抽出方法、移動タイプ |
| C# | Visual Studio 2026 | 完了 | 名前の変更、署名の変更、インターフェイスの抽出、実装の生成 |
| TypeScript | VSコード | 部分的（LSP経由） | NES で名前を変更し、インポートを更新 |
| ジャワ | ジェットブレインズ | 部分的 | 名前の変更、参照の更新 |
| パイソン | VS コード / JetBrains | 基本 | 状況に応じた提案を使用して名前を変更する |
例: C# でのメソッド シグネチャの変更
シンボル認識編集 - メソッド署名の変更
// PRIMA: Metodo originale in UserService.cs
public async Task<User> GetUserById(int id)
{{ '{' }}
return await _repository.FindAsync(id);
}
// MODIFICA: Aggiungi parametro 'includeOrders' alla firma
public async Task<User> GetUserById(int id, bool includeOrders = false)
{{ '{' }}
var user = await _repository.FindAsync(id);
if (includeOrders)
{{ '{' }}
user.Orders = await _orderRepository.FindByUserIdAsync(id);
}
return user;
}
// SYMBOL-AWARE: Copilot identifica TUTTI i 23 chiamanti nel progetto
// e suggerisce aggiornamenti per ciascuno:
// File: UserController.cs (linea 45)
// PRIMA: var user = await _userService.GetUserById(id);
// DOPO: var user = await _userService.GetUserById(id, false);
// File: OrderController.cs (linea 78)
// PRIMA: var user = await _userService.GetUserById(userId);
// DOPO: var user = await _userService.GetUserById(userId, true);
// File: UserServiceTests.cs (linea 112)
// PRIMA: var result = await service.GetUserById(1);
// DOPO: var result = await service.GetUserById(1, false);
// ... e cosi via per tutti i 23 riferimenti先進的な実践例
さまざまな編集モードを組み合わせた実際のシナリオをいくつか見てみましょう 複雑な問題を解決するために。
例 1: エージェント モードで機能を追加する
エージェント モードのプロンプト - ページネーションの追加
Aggiungi paginazione a tutti gli endpoint che restituiscono liste.
Requisiti:
- Query params: page (default 1), limit (default 20, max 100)
- Risposta: {{ '{' }} data: T[], meta: {{ '{' }} page, limit, total, totalPages } }
- Endpoint coinvolti: GET /users, GET /orders, GET /products
- Aggiorna i test esistenti per verificare la paginazione
- Aggiorna la documentazione OpenAPI
Pattern da seguire: vedi src/utils/pagination.ts (se esiste) o crealoエージェント モードはコードベースを分析し、3 つのエンドポイントを見つけ、ページング ユーティリティを作成します。 コントローラーとサービスを変更し、テストとドキュメントを更新します。テストの場合 プロセス中にエラーが発生した場合、エージェントはエラーを分析して自己修正します。
例 2: 移行に計画モードを使用する
計画モード - ライブラリの移行のプロンプト
Migra il progetto da Moment.js a Day.js.
Contesto:
- Moment.js e usato in 15 file
- Usiamo i plugin: timezone, relative-time, duration
- I test usano mock di Moment.js
- Il formato delle date in DB e ISO 8601
Requisiti:
- Sostituire tutti gli import di moment con dayjs
- Configurare i plugin equivalenti
- Aggiornare i format string se necessario
- Aggiornare tutti i test
- Rimuovere moment dalle dipendenze
- Verificare che il build compili senza errori
プランモードで生成されたプラン
# Piano di Migrazione: Moment.js -> Day.js
## Analisi Impatto
File impattati: 15
Test impattati: 8
Plugin da sostituire: 3
## Phase 1: Setup (5 min)
1. npm install dayjs
2. Creare src/utils/dayjs-config.ts con plugin
## Phase 2: Migrazione File (20 min)
File da modificare (ordine per dipendenze):
1. src/utils/date-helpers.ts (utility condiviso)
2. src/services/report.service.ts
3. src/services/scheduling.service.ts
4. src/controllers/report.controller.ts
... (altri 11 file)
## Phase 3: Test (10 min)
1. Aggiornare mock in tests/setup.ts
2. Aggiornare assertion nei test
3. Eseguire test suite completa
## Phase 4: Cleanup (5 min)
1. npm uninstall moment @types/moment
2. Verificare build
3. Verificare bundle size (atteso: -200KB)
## Rischi Identificati
- Il plugin timezone di Day.js ha API diversa
- Alcuni format string sono diversi
- I mock nei test potrebbero richiedere refactoring編集モードのベスト プラクティス
モード選択ガイド
| 状況 | 推奨モード | モチベーション |
|---|---|---|
| 単一の機能を完了する | インライン提案 | 高速かつ十分な即時コンテキスト |
| 2～3 個の関連ファイルを編集する | 編集モード | ファイルの制御、調整された変更 |
| 完全な機能を実装する | エージェントモード | ファイルの作成、コマンドの実行、自己修正 |
| 多数のファイルを使用したクリティカルなリファクタリング | プランモード | 計画は実行前に検証可能 |
| 名前の変更と更新を繰り返す | ファミコン | 予測的、高速、タブで移動 |
| 大規模プロジェクトでのメソッド シグネチャの変更 | シンボル認識 + NES | ファイル間の意味理解 |
| 緊急ではないタスク、不明なコードベース | プランモード + エージェントモード | 最初に計画し、その後監督を受けながら実行します |
トラブルシューティングと一般的な問題
高度な編集モードでは、特定の設定で問題が発生する可能性があります 状況。最も一般的な問題を診断して解決する方法は次のとおりです。
よくある問題と解決策
| 問題 | 原因 | 解決 |
|---|---|---|
| エージェント モードでは関連ファイルが見つかりません | 型破りな構造または隠しファイル | プロンプトでファイル パスを指定します |
| 自己修復の無限ループ | 修正しても解決されない構造的エラー | やめて、基本的な問題を手動で修正してください |
| 編集モードは編集しすぎます | プロンプトの範囲が広すぎます | 何を変更し、何を変更しないのかを具体的にする |
| ファミコンは出ない | 拡張機能が古いか機能が無効になっています | 拡張機能を更新し、設定を確認してください |
| 計画モードでは不完全な計画が生成される | コンテキストが不十分、またはプロジェクトが大きすぎる | コンテキストを追加するか範囲を制限する |
| ターミナルコマンドが失敗する | 環境が構成されていないか、依存関係が欠落しています | まずプロジェクトが手動でコンパイルされていることを確認してください |
| ファイル間の変更の不一致 | エージェントは変更の間にコンテキストを失います | 小さなタスクに分割するか、計画モードを使用します |
エージェントを停止するタイミング
警告標識
- 同じエラーで 3 回以上の反復
- 変更により問題が悪化する
- エージェントが無関係なファイルを変更する
- 生成されたコードは論理的に意味がありません
- 不要な依存関係が追加される
- テストは合格しましたが、ロジックが間違っています
是正措置
- プレス
Ctrl+C止める - アメリカ合衆国
git diffすべての変更を確認するには - あなたがやる
git stashogit checkout復元する - より多くのコンテキストを含めてリクエストを言い換えます
- タスクをサブタスクに分割する
- プランモードに切り替えてより詳細に制御
概要と次のステップ
Copilot の高度な編集モードが仕事のやり方を変える 私たちのIDEで。自律エージェントによるインライン提案から複数ファイルの調整編集まで 自己治癒から行動前の計画まで、それぞれのモダリティに適切な役割があります 最新の開発者ツールキットに含まれています。
重要なポイント
- 編集モード 特定のファイルに対する調整された変更の場合: ファイルを選択すると、Copilot が一貫した変更を生成します。
- エージェントモード 自己修復機能を備えた自律タスクの場合: エージェントはプロジェクトを探索し、コマンドを実行して自己修復します。
- プランモード 完全な制御: 最初に計画し、後で実行します。複雑なタスクや重要なコードに最適です。
- 次の編集提案 スムーズな編集: Tab で移動し、Tab で受け入れます。名前の変更と繰り返しの更新を数秒で実行できます。
- シンボルを意識した編集 セマンティック リファクタリング: Visual Studio における C++ および C# のコンパイラ レベルの理解。
シリーズの進行状況
| # | アイテム | Stato |
|---|---|---|
| 1 | 基礎と考え方 | 完了 |
| 2 | コンセプトと要件 | 完了 |
| 3 | バックエンドのアーキテクチャ | 完了 |
| 4 | フロントエンドの構造 | 完了 |
| 5 | 迅速なエンジニアリング | 完了 |
| 6 | テストと品質 | 完了 |
| 7 | ドキュメント | 完了 |
| 8 | デプロイとDevOps | 完了 |
| 9 | 進化 | 完了 |
| 10 | コーディングエージェント | 完了 |
| 11 | 自動コードレビュー | 完了 |
| 12 | 副操縦士の編集とエージェント モード | 完了 |
| 13 | GitHub スパーク | Prossimo |
| 14 | 副操縦士スペース | 近日公開 |
| 15 | AIモデル | 近日公開 |
| 16 | カスタマイズ | 近日公開 |
| 17 | 企業 | 近日公開 |
| 18 | 拡張機能 | 近日公開 |
| 19 | 安全性 | 近日公開 |
次の記事では、詳しく見ていきます GitHub スパーク、のためのプラットフォーム この言語を使用してブラウザから直接 AI ネイティブのマイクロアプリケーションを作成します コードを書いたりインフラストラクチャを構成したりする必要がなく、自然です。