스키마부터 만드는 프롬프트

출력부터 설계하고 프롬프트를 써

깔끔한 프롬프트는 결과를 소비할 코드의 데이터 모양을 먼저 알아. 다음 처리 단계가 {verdict, reason_codes, sla_tier}를 기다린다면 스키마부터 만든 뒤 그 값을 채우는 프롬프트를 써야 해. 그러면 작성자에게는 도움이 돼 보이지만 파서가 쓰지 못하는 출력을 막을 수 있어.

스키마를 단일 기준으로 삼아

스키마를 프롬프트와 함께 소스 관리에 넣어.
프롬프트, 검증기, TypeScript 형식이나 Python Pydantic 모델 같은 소비자가 같은 스키마를 나눠 써.
스키마를 바꾸면 프롬프트도 함께 바뀌게 해. 불편이 아니라 안전장치야.
선택 필드는 반드시 표시해. 모델이 어느 필드를 생략해도 되는지 추측하게 두지 마.

필드마다 의미를 풀어줘

프롬프트는 각 필드의 뜻, 허용값, 값이 없을 때의 행동을 설명해야 해. 열거값 이름만 보고는 알 수 없는 업무 의미를 스키마 안에 숨겨두지 마.

Code

스키마를 프롬프트로 연결하기·markdown

## Output schema (verdict_v3)
- verdict: string, one of [approve, reject, hold]
- reason_codes: array of strings, 1–3 entries from the enum below
- sla_tier: string, one of [silver, gold, platinum]
- notes: string, optional, ≤ 200 chars

## Field semantics
- approve = full approval. reason_codes must include 'ok'.
- reject = denied. reason_codes must include the policy that triggered.
- hold = needs human review. reason_codes must explain what info is missing.
- sla_tier = take from the customer record; do not infer.
- notes = optional human-readable summary; omit if no value to add.

출력부터 설계하고 프롬프트를 써

스키마를 단일 기준으로 삼아

필드마다 의미를 풀어줘

Code

External links

Exercise

Progress

댓글 0