/** * 코드 리뷰 map-reduce 프롬프트. * * 일반 에이전트 채팅은 코드 리뷰처럼 입력이 큰 작업을 단일 호출로 처리하다 * 약한 로컬 모델에서 빈 응답(첫 토큰 EOS)으로 무너진다. /review 는 /meet 와 같은 * map-reduce 로 이를 우회한다: * - Map : 파일 하나씩 독립 리뷰 → 파일별 발견사항(근거 인용) * - Reduce: 파일별 노트를 통합 → 우선순위가 매겨진 최종 리뷰 보고서 * 입력이 작게 쪼개지므로 약한 모델도 끝까지 생성할 수 있고, lost-in-the-middle 도 준다. */ /** [Map] 파일 1개를 리뷰해 발견사항만 추출. 근거(라인/코드 인용) 필수, 날조 금지. */ export function buildReviewFilePrompt(relPath: string, content: string, idx: number, total: number, focus: string): string { const focusBlock = focus.trim() ? `\n# 리뷰 초점 (사용자 지정 — 우선 점검)\n${focus.trim()}\n` : ''; // 라인 번호를 붙여 모델이 정확한 위치를 인용하게 한다(환각 위치 방지). const numbered = content.split('\n').map((l, i) => `${String(i + 1).padStart(4, ' ')}| ${l}`).join('\n'); return `# 임무 당신은 시니어 코드 리뷰어다. 아래 **단일 파일**(${idx}/${total}번째)을 리뷰해 발견사항만 추출하라. 최종 보고서는 나중에 모든 파일 노트를 합쳐 작성하므로, 여기서는 이 파일에 대한 사실 기반 발견사항을 **누락 없이** 뽑는 것이 임무다. ${focusBlock} # 점검 항목 - **버그/오류**: 논리 오류, 경계 조건, null/undefined, 예외 미처리, 경쟁 조건, 자원 누수 - **보안**: 입력 검증 누락, 인젝션, 비밀정보 하드코딩, 안전하지 않은 역직렬화/권한 - **성능**: 불필요한 반복·할당, N+1, 동기 블로킹, 비효율 자료구조 - **설계/구조**: 책임 분리, 결합도, 중복, 추상화 누락/과잉 - **가독성/유지보수**: 네이밍, 죽은 코드, 매직 넘버, 주석/타입 부재 # 규칙 (할루시네이션 방지 — 반드시 준수) - **이 파일에 실제로 있는 코드만** 근거로 삼는다. 없는 함수·호출·취약점을 지어내지 말 것. - 각 발견사항에는 **위치(라인 번호)** 와 **근거가 되는 코드 일부(짧게 인용)** 를 붙인다. - 확실하지 않으면 단정하지 말고 "확인 필요"로 표시한다. - 이 파일이 전반적으로 양호하면 발견사항을 억지로 만들지 말고 "특이사항 없음"이라고 적는다. - 다른 파일·외부 맥락을 가정하지 말 것(이 파일만 본다). [파일 경로] ${relPath} [파일 내용 — "라인번호| 코드" 형식] \`\`\` ${numbered} \`\`\` # 출력 형식 (이 파일에 해당 항목이 없으면 "없음") ## 파일: ${relPath} ### 발견사항 - [심각도: 높음|중간|낮음] [분류: 버그|보안|성능|설계|가독성] (L<라인>) 설명 — 근거: "코드 일부" · 개선 제안: 구체적으로 무엇을 어떻게 바꿀지 (특이사항이 없으면 "- 특이사항 없음") ### 한줄 요약 이 파일의 역할과 전반 상태를 한 문장으로.`; } /** [Reduce] 파일별 노트를 통합해 우선순위가 매겨진 최종 코드 리뷰 보고서 작성. */ export function buildReviewReducePrompt(notes: string, projectLabel: string, fileCount: number, focus: string): string { const focusBlock = focus.trim() ? `\n# 리뷰 초점 (사용자 지정)\n${focus.trim()}\n` : ''; return `# 임무 아래는 \`${projectLabel}\` 의 파일 ${fileCount}개를 파일별로 리뷰한 노트다. 이 노트만 근거로 **통합 코드 리뷰 보고서**를 작성하라. ${focusBlock} # 규칙 - **노트에 있는 발견사항만** 사용한다. 노트에 없는 문제를 새로 지어내지 말 것. - 여러 파일에 공통으로 나타나는 문제는 묶어서 "공통/구조적 이슈"로 정리한다. - 심각도와 영향 범위를 기준으로 **우선순위**를 매긴다(높은 심각도·넓은 영향 우선). - 각 이슈에는 파일·라인 위치를 유지한다(근거 추적 가능하게). - 비판만 하지 말고 잘 설계된 점도 짚는다. [파일별 리뷰 노트] ${notes} # 출력 형식 (정확히 이 구조, 한국어) # 코드 리뷰 보고서 — ${projectLabel} ## 1. 총평 전반적 품질·구조·주요 위험을 3~5줄로 요약. 비참석자도 상태를 파악할 수 있게. ## 2. 우선 개선 사항 (Top 우선순위) 가장 시급한 것부터 번호 매겨 정리. 각 항목: [심각도] 문제 — 위치(파일:라인) — 개선 방향. ## 3. 분류별 발견사항 ### 🐞 버그/오류 ### 🔒 보안 ### ⚡ 성능 ### 🧩 설계/구조 (공통 이슈 포함) ### 📖 가독성/유지보수 (각 항목에 파일:라인 + 한 줄 개선 제안. 해당 분류에 발견사항이 없으면 "발견사항 없음".) ## 4. 잘된 점 유지·강화할 가치가 있는 설계·패턴. ## 5. 권장 다음 단계 실행 가능한 조치를 우선순위 순 체크리스트로.`; }