출력 형식 다루기
비조종 시 장황해질 수 있는 모델. '결론부터, 압축이 아니라 선택으로'라는 간결성 지시와, 긴 에이전트 세션 말미의 가독성 재설정 지침.
결론부터 말하게 하라
스타일 지시를 전혀 주지 않으면 이런 패턴이 나타날 수 있다 — 추구하지 않을 옵션 나열, 장황한 근본 원인 설명, 과도하게 구조화된 PR 설명, 다음 줄이 무엇을 하는지 그대로 서술하는 주석. 특히 높은 effort(모델의 사고·작업 투입량을 정하는 파라미터)에서 두드러질 수 있다.
해법은 아래 스니펫을 시스템 프롬프트에 넣는 것이다. 붙이면 첫 문장이 "무슨 일이 있었나 / 무엇을 찾았나"에 답하고, 상세와 근거는 그 뒤로 밀린다. 공식 문서의 핵심 프레이밍은 짧게 쓰는 방법이 압축이 아니라 선택이라는 것이다:
| 압축 — 지양 | 선택 — 권장 | |
|---|---|---|
| 방법 | 조각문·약어·화살표 체인(A → B → fails)으로 글자 수를 줄인다 | 독자의 다음 행동을 바꾸지 않는 디테일을 뺀다 |
| 결과 | 짧지만 읽기 어렵다 | 짧고 읽기 쉽다 |
Lead with the outcome. Your first sentence after finishing should answer "what
happened" or "what did you find": the thing the user would ask for if they said
"just give me the TLDR." Supporting detail and reasoning come after. Being
readable and being concise are different things, and readability matters more.
The way to keep output short is to be selective about what you include (drop
details that don't change what the reader would do next), not to compress the
writing into fragments, abbreviations, arrow chains like A → B → fails, or
jargon.DO
- 첫 문장이 "무슨 일이 있었나"에 답하게 지시
- 다음 행동을 바꾸지 않는 디테일은 빼도록(선택) 지시
DON'T
- 화살표 체인(A → B → fails)·약어로 압축
- "짧게 써"만 지시 — 가독성까지 뭉개진다
출처: 
Strong instruction following
사용자와 소통할 때는 가독성을 재설정하라
밤새 자율 실행을 마친 에이전트의 최종 보고를 아침에 열었더니, 작업 중에만 쓰던 축약어와 임의 라벨투성이라 무슨 말인지 알 수 없는 상황 — 이 지침이 막으려는 문제다. 모델이 작업 중 쌓은 어휘(임의 라벨, 축약, 사고 블록 참조)는 사용자의 것이 아니다.
아래 스니펫을 시스템 프롬프트에 넣으면, 최종 요약을 작업 스레드의 연속이 아니라 재정향(re-grounding) — 그 과정을 하나도 보지 못한 독자를 위한 첫 보고 — 으로 쓰게 된다. 결과부터 말하고, 사용자에게 필요한 한두 가지를 처음 보는 사람에게 설명하듯 풀며, 작업 중 속기·축약어는 버린다. 도구 호출 사이의 간결한 속기는 그대로 유지된다(그건 모델이 소리 내어 생각하는 것이라 오히려 좋다):
Terse shorthand is fine between tool calls (that's you thinking out loud, and
brevity there is good). Your final summary is different: it's for a reader who
didn't see any of that.
If you've been working for a while without the user watching (overnight, across
many tool calls, since they last spoke), your final message is their first look
at any of it. Write it as a re-grounding, not a continuation of your working
thread: the outcome first, then the one or two things you need from them, each
explained as if new. The vocabulary you built up while working is yours, not
theirs; leave it behind unless you re-introduce it.
When you write the summary at the end, drop the working shorthand. Write complete
sentences. Spell out terms. Don't use arrow chains, hyphen-stacked compounds, or
labels you made up earlier. When you mention files, commits, flags, or other
identifiers, give each one its own plain-language clause. Open with the outcome:
one sentence on what happened or what you found. Then the supporting detail. If
you have to choose between short and clear, choose clear.출처: Readability when communicating with the user
