이 템플릿은 Ollama, LM Studio, Jan 또는 비슷한 실행기에서 돌아가는 Llama, Mistral, Phi, Qwen, Gemma 같은 로컬 모델을 위해 썼어요. 짧은 역할, 하나의 작업, 단단한 제약을 써요. 이 패턴은 “이걸 더 좋게 만들어 주세요” 같은 막연한 요청보다 7B나 13B 모델에서 더 안정적이에요.
대괄호 안을 모두 바꾼 다음 대괄호는 지우세요. 규칙은 그대로 두세요. 그래도 모델이 흔들리면 이 세 가지를 순서대로 하세요. 규칙을 원문보다 위로 옮기고, 지시가 위쪽에 가깝게 남도록 원문을 줄이고, 실행기에서 온도(temperature)를 약 0.2로 낮추세요. 컨텍스트 창에 가까우면 프롬프트부터 세어 보세요. 토큰 계산기는 토크나이저가 아니라 추정치지만, 프롬프트가 길어지는 시점은 알 수 있어요.
프롬프트당 작업은 하나예요. “메일을 쓰고, 번역도 하고, 슬라이드도 만들어 주세요”는 프롬프트 세 개예요.
출력 모양을 이름 붙이세요. 글머리표, 단어 수 제한, JSON 키, 또는 “코드만”.
빼야 할 것을 말하세요. “서두는 넣지 마세요”만으로도 로컬 모델의 잡담이 많이 줄어요.
글쓰기
짧은 글 또는 게시물
개요가 아니라 완성된 글이 필요할 때 쓰세요. 주제를 좁히면 7B 모델에서도 동작해요.
당신은 분명하고 간결한 글쓴이예요.
작업: [주제]에 대한 블로그 글을 쓰세요.
요구사항:
- 길이: 약 400단어
- 독자: [누구]
- 말투: 담백하게, 과장 없이
- 구성: 두 문장의 시작, 제목이 있는 세 부분, 두 문장의 마무리
- 통계를 지어내지 마세요
글만 출력하세요.
짧게 유지해야 하는 이메일
길이를 제한하고 다뤄도 되는 요점을 적지 않으면, 로컬 모델은 이메일을 불필요하게 늘려요.
업무 이메일을 쓰고 있어요.
받는 사람: [이름 또는 역할]
목적: [요청 / 소식 / 거절]
넣어도 되는 요점:
- [요점 1]
- [요점 2]
규칙:
- 120단어 미만
- 인사는 한 줄을 넘기지 마세요
- “평안하시길 바랍니다”는 쓰지 마세요
이메일만 출력하세요.
제품 설명
[제품]의 제품 설명을 쓰세요.
써도 되는 사실:
- [사실]
- [사실]
- [사실]
규칙:
- 70에서 90단어
- 상대를 “당신”으로 부르세요
- “최고”나 “보장”처럼 확인되지 않은 주장은 하지 마세요
- 구호가 아니라 구체적인 사용 하나로 끝내세요
설명만 출력하세요.
코딩
함수 하나, 언어 하나
“앱”이 아니라 함수를 요청하세요. 언어 버전을 적으세요. 프레임워크, 테스트, README를 한 번에 넣으면 작은 모델은 헤매요.
당신은 신중한 Python 3.11 개발자예요.
작업: [X를 하는] 함수를 하나만 쓰세요.
입력: [유형]
출력: [유형]
규칙:
- 두 줄짜리 독스트링을 넣으세요
- 이 경계 경우를 처리하세요: [경우]
- 메인 블록이나 사용 예는 넣지 마세요
- 함수만 반환하세요
파일을 다시 쓰지 않고 버그 설명하기
코드를 검토하고 있어요. 파일 전체를 다시 쓰지 마세요.
코드:
[붙여넣기]
글머리 정확히 3개로 반환하세요.
1. 가장 가능성 높은 버그
2. 왜 생기는지
3. 고칠 수 있는 가장 작은 변경
확실하지 않으면 그 글머리에 “확실하지 않음”이라고 쓰세요. 스택 트레이스를 지어내지 마세요.
프로젝트가 아니라 조각만 변환하기
다음 [JavaScript] 함수를 [Python]으로 바꾸세요.
규칙:
- 동작은 같게 유지하세요
- 이름이 내용을 드러내게 하세요
- 한 줄이 자명하지 않을 때만 주석을 하나 다세요
- 변환된 함수만 반환하세요
코드:
[붙여넣기]
요약과 메모
고정된 글머리 요약
본문을 글머리 정확히 5개로 요약하세요.
규칙:
- 각 글머리는 완전한 문장 하나예요
- 본문에 나온 숫자와 이름은 유지하세요
- 본문에 없는 배경은 더하지 마세요
- 제목도, 마무리 문단도 넣지 마세요
본문:
[붙여넣기]
회의 메모를 결정과 할 일로
이 거친 메모를 두 목록으로 바꾸세요. 결정과 할 일.
규칙:
- 결정: 메모에서 합의했다고 한 것만
- 할 일: 각 줄은 동사로 시작하고, 이름이 있으면 그 이름을 적으세요
- 담당이 없으면 “담당: 적혀 있지 않음”이라고 쓰세요
- 새 할 일을 더하지 마세요
메모:
[붙여넣기]
짧은 요약과 무시할 것
본문을 읽고 다음을 반환하세요.
1. 40단어 이하의 짧은 요약
2. 중요한 세부 세 가지
3. 중요해 보이지만 결정에는 필요 없는 세부 두 가지
제품을 추천하지 마세요.
본문:
[붙여넣기]
번역과 다시 쓰기
이름을 유지하는 번역
[영어]에서 [스페인어]로 번역하세요.
규칙:
- 제품 이름, URL, 코드는 그대로 두세요
- 중립적인 말투를 쓰세요
- 번역을 설명하지 마세요
- 문장이 모호하면 가장 글자 그대로인 뜻을 번역하고 뒤에 “[모호]”를 붙이세요
본문:
[붙여넣기]
읽기 수준에 맞게 다시 쓰기
바쁜 비전문가가 따라갈 수 있게 본문을 다시 쓰세요.
규칙:
- 원문과 거의 같은 길이
- 짧은 문장
- 숫자는 모두 유지하세요
- 원문에 없는 예는 더하지 마세요
본문:
[붙여넣기]
사실은 그대로 두고 말투만 바꾸기
문단을 더 차분한 말투로 다시 쓰세요.
규칙:
- 원래 없던 사과는 더하지 마세요
- 마감이나 금액은 빼지 마세요
- [80]단어 미만으로 유지하세요
문단:
[붙여넣기]
분석과 결정
위험 검토
당신은 응원단이 아니라 실용적인 검토자예요.
대상: [기능, 계획, 또는 초안]
제약: [시간, 예산, 또는 도구]
다음을 반환하세요.
1. 위험 세 가지, 각각 한 문장
2. 범위를 줄이는 방법 하나
3. 예 또는 아니요, 한 문장의 이유와 함께
지표를 지어내지 마세요.
두 선택지 비교
[결정]에 대해 선택지 A와 선택지 B를 비교하세요.
선택지 A: [사실]
선택지 B: [사실]
기준, 선택지 A, 선택지 B 열로 된 표를 일반 텍스트로 반환하세요.
그다음 한 문장: [제약]이 우선이면 어느 쪽을 고를지.
세 번째 선택지는 더하지 마세요.
구조화된 추출
null이 있는 JSON
키를 알려 주고, 필드가 없을 때 어떻게 할지도 말하세요. 그렇지 않으면 로컬 모델은 그럴듯한 날짜나 가격을 지어내요.
정확히 이 키로 JSON을 추출하세요: name, date, amount, currency.
규칙:
- 본문이 값을 말하지 않으면 null을 쓰세요
- amount는 문자열이 아니라 숫자예요
- 키를 더하지 마세요
- 마크다운 코드 펜스는 쓰지 마세요
본문:
[붙여넣기]
정책에서 점검 목록 만들기
정책 본문에서 사람이 해야 하는 행동만 나열하세요.
규칙:
- 한 줄에 행동 하나, 동사로 시작하세요
- 배경과 정의는 건너뛰세요
- 본문이 불명확하면 “불명확:”이라고 쓰고 그 구절을 인용하세요
정책:
[붙여넣기]
공부와 연습
내 메모로 퀴즈 만들기
아래 메모만 써서 질문과 답을 5개 쓰세요.
규칙:
- 단답 3개와 참/거짓 2개를 섞으세요
- 답은 메모로 뒷받침되어야 해요
- 각 답 뒤에 근거 구절을 따옴표로 인용하세요
메모:
[붙여넣기]
설명하고 멈추기
[개념]을, [선수 지식]은 알지만 [개념]은 모르는 사람에게 설명하세요.
규칙:
- 최대 150단어
- 구체적인 예 하나
- 역사 부분은 넣지 마세요
- 예 다음에 끝내세요. 이어지는 질문은 하지 마세요.
템플릿이 그래도 실패할 때
모델이 어떤 규칙을 무시하면, 그 규칙 하나만 프롬프트의 마지막 줄에 다시 적으세요. 로컬 모델은 가장 가까운 지시를 따르는 경우가 많아요. 친절한 서두를 붙이면 “답부터 바로 시작하세요”를 더하세요. 평범한 글쓰기 작업을 거부하면, 프롬프트가 너무 길거나 실행기의 시스템 프롬프트가 당신 것과 충돌하는 경우가 많아요. 당신 것을 줄이고 앱의 기본 시스템 메시지를 확인하세요.
다시 실행하기 전에 통과/실패를 보려면 프롬프트를 프롬프트 최적화에 붙여 넣으세요. 모델을 호출하지 않아요. 역할이 빠졌는지, 형식이 빠졌는지, 프롬프트가 아주 짧은지 아주 긴지만 표시해요.
