Copilot 편집 및 에이전트 모드: IDE에서 다중 파일 편집 및 독립 실행형 개발
지금까지 우리는 인라인 제안 보조자 및 에이전트로서 Copilot을 살펴보았습니다. GitHub에서 일하는 자영업자. 그러나 매우 강력한 중간 영역이 있습니다. 부조종사 편집 e 에이전트 모드, 이는 다음과 같은 기능을 제공합니다. IDE에서 직접 다중 파일 편집 및 독립 실행형 실행이 가능합니다. 편집하는 대신 한 번에 한 파일씩 여러 파일에 영향을 미치는 변경 사항을 설명하고 그대로 둘 수 있습니다. Copilot은 모든 변경 사항을 일관되게 조정합니다.
이 문서에서는 사용 가능한 고급 편집 모드를 자세히 살펴보겠습니다. 편집 모드 안내된 다중 파일 편집을 위해, 에이전트 모드 에 대한 자가 치유를 통한 자율 실행, 계획 모드 먼저 계획을 세우기 위해 행동의 e 다음 편집 제안(NES) 예측 편집 흐름을 위해 그리고 유동적이다.
시리즈 개요
| # | Articolo | 집중하다 |
|---|---|---|
| 1 | 기초와 사고방식 | 설정과 사고방식 |
| 2 | 개념 및 요구사항 | 아이디어에서 MVP까지 |
| 3 | 백엔드 아키텍처 | API 및 데이터베이스 |
| 4 | 프런트엔드 구조 | UI 및 구성요소 |
| 5 | 신속한 엔지니어링 | MCP 프롬프트 및 에이전트 |
| 6 | 테스트 및 품질 | 단위, 통합, E2E |
| 7 | 선적 서류 비치 | 읽어보기, API 문서, ADR |
| 8 | 배포 및 DevOps | 도커, CI/CD |
| 9 | 진화 | 확장성 및 유지 관리 |
| 10 | 코딩 에이전트 | 자율적 개발 |
| 11 | 자동 코드 검토 | AI 기반 검토 |
| 12 | 현재 위치 → 편집 및 에이전트 모드 | 다중 파일 편집 |
| 13 | GitHub 스파크 | AI 기반 마이크로앱 |
| 14 | 부조종사 공간 | 공유 컨텍스트 |
| 15 | AI 모델 | 다중 모델 및 선택 |
| 16 | 맞춤화 | 맞춤 지침 |
| 17 | 기업 | 조직적 채택 |
| 18 | 확장 | 부조종사 확장 |
| 19 | 안전 | 보안 및 규정 준수 |
Copilot의 편집 모드
Copilot은 IDE에서 다양한 상호 작용 모드를 제공합니다. 자율성과 복잡성의 수준이 다릅니다. 차이점을 이해하는 것은 각 상황에 맞는 모드를 선택하는 것이 중요합니다.
편집 모드 비교
| 방법 | 자치 | 빗자루 | IDE 지원 | 사용 사례 |
|---|---|---|---|---|
| 인라인 제안 | 최소한의 | 현재 행/블록 | 모든 사람 | 실시간 코드 완성 |
| 편집 모드 | 평균 | 지정된 파일 | VS 코드, 비주얼 스튜디오, JetBrains | 선택한 여러 파일에 걸쳐 조정된 변경 사항 |
| 에이전트 모드 | 높은 | 전체 프로젝트 | VS 코드, 비주얼 스튜디오, JetBrains | 자가 치유 기능을 갖춘 자율 작업 |
| 계획 모드 | 체크됨 | 전체 프로젝트 | VS 코드, JetBrains, Eclipse, Xcode | 실행 전 계획 |
| 코딩 에이전트 | 최고 | 완전한 저장소 | GitHub(클라우드) | 완전 자율 작업(PR) |
Copilot 편집: 다중 파일 편집
부조종사 편집 설명할 수 있는 양식입니다. 자연어를 변경하여 한 번에 여러 파일에 적용할 수 있습니다. 즉각적인 컨텍스트에서 작동하는 인라인 제안과 달리 Edits는 다음을 수행합니다. 선택한 파일 간의 관계를 고려하고 일관된 변경 사항을 생성합니다.
Copilot 편집 작업흐름
- 파일 선택: Copilot 컨텍스트에 편집해야 하는 파일을 추가합니다.
- 변경 사항을 설명하세요. 달성하려는 목표를 자연어로 설명하세요.
- 변경사항 검토: Copilot은 제안된 변경 사항과 함께 각 파일의 차이점을 표시합니다.
- 반복: 변경 사항이 완벽하지 않은 경우 요청을 구체화하세요.
- 적용하다: 당신이 옳다고 생각하는 변화는 받아들이고, 다른 변화는 거부하라
Copilot 편집에 액세스하는 방법
다양한 IDE에서 활성화
| FDI | 단축키 | 메뉴 | 메모 |
|---|---|---|---|
| VS 코드 | Ctrl+Shift+I (윈/리눅스) / Cmd+Shift+I (스코틀랜드 사람) |
보기 > 부조종사 편집 | 사이드바의 전용 패널 |
| 비주얼 스튜디오 | Ctrl+Shift+. |
편집 > 부조종사 편집 | Copilot Chat 패널에 통합됨 |
| JetBrains | Ctrl+Shift+I |
도구 > Copilot > 편집 | 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.ts
Copilot Edits는 5개의 파일을 분석하고 조정된 편집을 생성합니다. 결과를 보자 각 파일마다.
// 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;
}
// 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();
};
}
// 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에서. 편집 모드와 달리 에이전트는 파일 시스템을 탐색할 수 있습니다. 파일을 생성하고 터미널에서 명령을 실행하며 가장 중요한 것은 자기 교정 뭔가 잘못되었을 때.
자가 치유: 지능적인 자가 교정
에이전트 모드의 가장 큰 특징은 자가 치유. 에이전트가 오류를 생성하는 코드(컴파일, 린팅, 테스트)를 생성하면 분석합니다. 오류 메시지를 직접 확인하고 다음 단계를 반복하여 문제를 해결해 보세요. 성공하거나 반복 제한에 도달할 때까지 반복합니다.
자가 치유 주기
- 세대: 에이전트는 요청에 따라 코드를 작성합니다.
- 확인하다: 정확성을 확인하기 위해 빌드 또는 테스트를 실행합니다.
- 오류 분석: 오류가 있으면 전체 오류 메시지를 읽습니다.
- 진단: 원인 파악(유형 누락, 잘못된 가져오기, 구문)
- 보정: 수정사항을 적용하고 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%) |
에이전트 모드를 활성화하고 구성하는 방법
// .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 코파일럿 채팅에서 |
에이전트 모드와 계획 모드 간 전환 |
| JetBrains | Copilot Chat 도구 모음의 "계획" 아이콘 | 모든 JetBrains IDE에서 사용 가능 |
| Eclipse | Copilot 메뉴 > 계획 모드 | Copilot 패널에 통합됨 |
| Xcode | Copilot 메뉴 > 계획 모드 | 기본 지원 |
계획 모드 워크플로
- 요구: 자연어로 작업을 설명합니다.
- 복수: Copilot은 코드베이스를 분석하고 관련 파일을 식별합니다.
- 질문(선택사항): 요청이 모호한 경우 명확한 질문을 하세요.
- 바닥: 다음을 사용하여 구조화된 계획을 생성합니다.
- 생성, 편집 또는 삭제할 파일
- 작업 순서
- 변경 사항 간의 종속성
- 실행할 명령
- 검토: 계획을 검토하고 수정할 수 있습니다.
- 실행: 승인 후 단계별로 계획이 실행됩니다.
계획 모드를 사용하는 경우
Scenari Ideali per Plan Mode
| Scenario | Perché Plan Mode | Alternativa |
|---|---|---|
| Refactoring complesso | Vuoi verificare che il piano tocchi tutti i file necessari | Agent Mode potrebbe saltare file |
| Nuova feature multi-componente | Vuoi validare l'architettura prima dell'implementazione | Edit Mode richiederebbe troppo lavoro manuale |
| Migrazione di libreria | Vuoi vedere l'elenco completo dei file impattati | Agent Mode potrebbe dimenticare file |
| Task con requisiti ambigui | Le domande chiarificatrici evitano lavoro inutile | Agent Mode potrebbe assumere e sbagliare |
| Codice critico | Vuoi il controllo totale su ogni modifica | Nessuna: Plan Mode è la scelta migliore |
Esempio Pratico: Plan Mode per Feature Complessa
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 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 agent
Next 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 |
변수가 사용되는 모든 지점에서 업데이트를 제안합니다. |
| 매개변수 추가 | 매개변수 추가 options 함수에 |
모든 호출자와 JSDoc을 업데이트할 것을 제안합니다. |
| 유형 변경 | 반품 유형 변경 string a UserResponse |
가치 소비자의 업데이트 제안 |
| 필드 추가 | 필드 추가 avatar 인터페이스에 User |
공장, 테스트, 매핑에서 업데이트를 제안합니다. |
| 패턴 변화 | 콜백을 async/await로 변환 | 파일의 모든 유사한 패턴으로 변환을 제안합니다. |
| 가져오기를 추가했습니다. | 파일에 새로운 유형을 사용합니다. | 올바른 import 문을 제안합니다. |
예: NES로 이름 바꾸기
변수의 이름을 바꾼다고 가정해 보겠습니다. data in userProfile
15번 발생하는 파일에서. NES가 없으면 수동으로 검색하고 교체해야 합니다.
IDE 리팩토링을 사용하세요. 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에서 표시기는 또한 시각적 검토를 용이하게 하기 위해 도구 설명에 구문 강조 표시가 포함되어 있습니다. 제안된 변경 사항 중
NES의 장점
- 반복 편집을 위한 편집 속도가 3~5배 더 빨라짐
- 부분적인 이름 변경 오류 감소
- 파일 간에서도 작동합니다.
- 의미론적 맥락을 이해합니다.
- 정규식이나 찾기-바꾸기가 필요하지 않습니다.
- 또한 명확하지 않은 변화를 예측합니다.
NES 제한 사항
- VS Code에서만 사용 가능(현재)
- 원치 않는 변경이 제안될 수 있습니다.
- 항상 모든 일치 항목을 찾는 것은 아닙니다.
- 품질은 패턴의 선명도에 따라 달라집니다.
- 복잡한 리팩토링을 처리하지 않습니다.
- 제안을 검토할 때 주의가 필요합니다.
기호 인식 편집
다음과 같은 언어의 경우 C++ e C#, Copilot이 통합되었습니다. 단순한 패턴 매칭을 넘어서는 컴파일러 수준의 이해 텍스트. 그만큼'기호 인식 편집 기호, 유형 및 종속성을 분석합니다. 파일 간에 의미상으로 올바른 리팩토링 작업을 프로젝트 규모에서 허용합니다.
작동 방식
기존의 텍스트 기반 편집과 달리 기호 인식 편집은 포함할 언어 서버 프로토콜(LSP) 정보:
- 진술: 기호가 정의된 위치
- 참고자료: 기호가 사용되는 곳
- 유형: 각 기호의 유형과 관계
- 범위: 각 기호의 가시성
- 종속성: 기호에 의존하는 파일
기호 인식 언어 지원
| 언어 | FDI | 지원 수준 | 지원되는 작업 |
|---|---|---|---|
| C++ | 비주얼 스튜디오 2026 | 완벽한 | 이름 바꾸기, 서명 변경, 추출 방법, 이동 유형 |
| C# | 비주얼 스튜디오 2026 | 완벽한 | 이름 바꾸기, 서명 변경, 인터페이스 추출, 구현 생성 |
| 타입스크립트 | VS 코드 | 부분(LSP를 통해) | NES로 이름 바꾸기, 가져오기 업데이트 |
| 자바 | JetBrains | 부분 | 이름 바꾸기, 참조 업데이트 |
| 파이썬 | 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 | 파일 간 의미 이해 |
| 긴급하지 않은 작업, 알 수 없는 코드베이스 | 계획 모드 + 에이전트 모드 | 먼저 계획한 후 감독하에 실행 |
문제 해결 및 일반적인 문제
고급 편집 모드에서는 특정 설정에서 문제가 발생할 수 있습니다. 상황. 가장 일반적인 문제를 진단하고 해결하는 방법은 다음과 같습니다.
일반적인 문제 및 해결 방법
| 문제 | 원인 | 해결책 |
|---|---|---|
| 에이전트 모드에서 관련 파일을 찾지 못합니다. | 틀에 얽매이지 않는 구조 또는 숨겨진 파일 | 프롬프트에서 파일 경로 지정 |
| 자가 치유 무한 루프 | 수정으로 해결되지 않는 구조적 오류 | 중지하고 기본적인 문제를 수동으로 해결하세요. |
| 편집 모드에서 편집을 너무 많이 함 | 프롬프트가 너무 광범위함 | 변경해야 할 사항과 건드리지 말아야 할 사항을 구체적으로 설명하세요. |
| NES가 나타나지 않습니다 | 확장 프로그램이 오래되었거나 기능이 사용 중지되었습니다. | 확장 프로그램 업데이트, 설정 확인 |
| 계획 모드가 불완전한 계획을 생성합니다. | 맥락이 부족하거나 프로젝트가 너무 크다 | 더 많은 컨텍스트를 추가하거나 범위를 제한하세요. |
| 터미널 명령이 실패함 | 환경이 구성되지 않았거나 종속성이 누락되었습니다. | 먼저 프로젝트가 수동으로 컴파일되는지 확인하세요. |
| 파일 간의 일관성 없는 변경 | 에이전트는 변경 사이에 컨텍스트를 잃습니다. | 더 작은 작업으로 나누거나 계획 모드를 사용하세요. |
에이전트를 중지해야 하는 경우
경고 신호
- 동일한 오류에 대해 3회 이상 반복
- 변화는 문제를 더욱 악화시킨다
- 에이전트가 관련 없는 파일을 수정합니다.
- 생성된 코드는 논리적으로 의미가 없습니다.
- 불필요한 종속성이 추가되었습니다.
- 테스트는 통과했지만 논리가 잘못되었습니다.
시정 조치
- 누르다
Ctrl+C멈추다 - 미국
git diff모든 변경 사항을 보려면 - 당신은
git stashogit checkout복원하다 - 더 많은 맥락으로 요청을 바꿔보세요.
- 작업을 하위 작업으로 나누기
- 더 많은 제어를 위해 계획 모드로 전환하세요
요약 및 다음 단계
Copilot의 고급 편집 모드는 작업 방식을 변화시킵니다 우리 IDE에서. 인라인 제안부터 조정된 다중 파일 편집까지, 자율 에이전트에서 자가 치유부터 행동 전 계획까지, 각 양식은 그 자리를 차지합니다. 현대 개발자 툴킷에서.
핵심 사항
- 편집 모드 특정 파일에 대한 조정된 변경의 경우: 파일을 선택하면 Copilot이 일관된 변경을 생성합니다.
- 에이전트 모드 자가 치유 기능을 갖춘 자율 작업의 경우: 에이전트는 프로젝트를 탐색하고 명령을 실행하며 자가 치유를 수행합니다.
- 계획 모드 완전한 통제를 위해: 먼저 계획하고 나중에 실행하세요. 복잡한 작업과 중요한 코드에 이상적입니다.
- 다음 편집 제안 원활한 편집을 위해: 탐색하려면 탭하고, 승인하려면 탭하세요. 몇 초 만에 이름을 바꾸고 반복적으로 업데이트할 수 있습니다.
- 기호 인식 편집 의미 체계 리팩토링: Visual Studio의 C++ 및 C#에 대한 컴파일러 수준 이해.
시리즈 진행
| # | Articolo | 상태 |
|---|---|---|
| 1 | 기초와 사고방식 | 완전한 |
| 2 | 개념 및 요구사항 | 완전한 |
| 3 | 백엔드 아키텍처 | 완전한 |
| 4 | 프런트엔드 구조 | 완전한 |
| 5 | 신속한 엔지니어링 | 완전한 |
| 6 | 테스트 및 품질 | 완전한 |
| 7 | 선적 서류 비치 | 완전한 |
| 8 | 배포 및 DevOps | 완전한 |
| 9 | 진화 | 완전한 |
| 10 | 코딩 에이전트 | 완전한 |
| 11 | 자동 코드 검토 | 완전한 |
| 12 | 부조종사 편집 및 에이전트 모드 | 완전한 |
| 13 | GitHub 스파크 | 다음 |
| 14 | 부조종사 공간 | 곧 출시 예정 |
| 15 | AI 모델 | 곧 출시 예정 |
| 16 | 맞춤화 | 곧 출시 예정 |
| 17 | 기업 | 곧 출시 예정 |
| 18 | 확장 | 곧 출시 예정 |
| 19 | 안전 | 곧 출시 예정 |
다음 기사에서는 살펴보겠습니다. GitHub 스파크, 플랫폼 언어를 사용하여 브라우저에서 직접 AI 기반 마이크로 애플리케이션 생성 코드를 작성하거나 인프라를 구성할 필요 없이 자연스럽습니다.







