더 높은 목표를 향해 (Aim Higher)
Felix Rieseberg의 주장은 더 이상 모델이 한계가 아니라, 우리가 요청하는 '질문의 크기'가 한계라는 것입니다. 그는 야망을 네 가지 유형으로 분류하고, 첫 번째 유형은 이미 모두가 하고 있으므로 생략합니다.
| 유형 | 행동 | 여기서의 상태 |
|---|---|---|
| 속도(Speed) | 같은 작업, 더 짧은 시간 | 이미 기본값. 스킬 불필요. |
| 고도(Altitude) | 작업이 아닌 결과(성과)를 목표로 작업 | 레버 1 |
| 깊이(Depth) | 해당 분야 최고 전문가의 방식으로 작업 | 레버 2 |
| 범위(Range) | 다른 분야와 그 도구를 도입 | 레버 3 |
이것은 프롬프트 팩이 아닙니다. 붙여넣기식 프롬프트는 일회성에 불과합니다. 결과를 바꾸는 것은 매번 작업을 시작하기 전에 세 가지 질문을 하고, 가정된 것이 아니라 실제 존재하는 것에 기반하여 답변하는 것입니다.
먼저 따라야 할 가드레일
Rieseberg의 깊이 기법인 "비현실적인 목표를 정하고 모델에게 그것이 매우 합리적이라고 말하기"는 타당하지만, 이 스킬이 실제로 해를 끼칠 수 있는 유일한 방법이기도 합니다.
비현실적인 목표(TARGET)는 괜찮습니다. 비현실적인 주장(CLAIM)은 거짓말입니다. 페이지가 5초 걸릴 때 200ms를 요구하는 것은 좋은 관행입니다. 목표였기 때문에 200ms라고 보고하는 것은 거짓 진술입니다. 재현율, 조정 합계, 단어 수, 마감일 등 모든 숫자에 동일하게 적용됩니다.
따라서 목표를 높이는 것은 시도하는 내용을 바꿀 뿐, 주장하는 내용에 대해서는 아무것도 바꾸지 않습니다. 모든 주장은 출처를 유지하며, 모든 계산된 숫자는 해당 세션에서 실행된 도구에서 나오며, 아무것도 찾지 못한 검색은 존재하는 것에 대한 진술이 아니라 어디를 살펴보았는지에 대한 진술입니다. 야망과 검증이 서로 충돌한다면 검증이 승리하며, 그 차이는 명시됩니다: "목표는 X였고, 측정된 결과는 Y입니다."
이 스킬이 적용된 모든 작업은 다음 네 줄로 마무리하십시오:
목표로 삼은 대상: <높아진 목표>
측정된 결과: <도구가 반환한 값, 도구 이름 명시>
차이(Gap): <차이를 명확히 서술>
판단 기준: <이를 확정한 외부 검증>
검증되지 않음: <아직 열려 있는 사항, 이름 명시>
레버 1, 고도(Altitude): 목표 너머의 목표는 무엇인가
Rieseberg의 테스트: 다음에 무슨 일이 일어나야 하는지 묻고, 답이 '문서'가 아닐 때까지 계속 질문하십시오. 그는 고도가 작업이 회의나 결정에 기여할 때 가장 도움이 되고, 창의적인 작업에서는 가장 덜 도움이 된다고 언급합니다.
세 가지 단계를 제시하십시오. 메뉴를 제공하는 대신 하나를 선택하고 그 아래 단계를 대비책(fallback)으로 지정하십시오:
- 말 그대로의 요청을 잘 수행한 것. 한 줄로 명시하여 최소한의 기준을 제공하십시오.
- 그것이 제공하는 의사결정. 모델에게 원자료를 제공하고 무엇이 바뀌었는지, 왜, 그리고 무엇을 해야 하는지 물으십시오. 그런 다음 진정으로 긴급한 두세 가지 결정을 각각 찬성과 반대 사례와 함께 명명하십시오.
- 요청 자체를 대체하는 것. 결과물보다 더 나은 것을 설계하고, 그 설계를 프로젝트 자체의 역사에 대해 테스트한 후, 한 주기 동안 현재 방식과 함께 운영할 것을 제안하십시오.
작동 예시: 누군가가 허가 추적기(permit tracker)를 요청합니다. 1단계는 추적기 자체입니다. 2단계는 어떤 세 가지 허가가 가장 지연될 가능성이 높으며 각각에 대한 대처 방안입니다. 3단계는 상대방이 알기 전에 지연을 알리는 프로세스이며, 이미 지연된 허가를 통해 검증됩니다.
사람들이 건너뛰는 부분. Rieseberg는 고도를 가능하게 하기 위해 자신의 워크플로를 변경해야 했습니다: 충돌 보고서를 가져올 수 있게 하고, 앱 버전을 커밋에 매핑하고, 모델이 재현할 수 있는 머신을 제공했습니다. 이와 유사한 것은 거의 항상 요약본이 아닌 원자료에 대한 접근입니다. 누락된 접근 권한을 명시적으로 지정하십시오. 그것 없이는 3단계는 연극에 불과합니다. 일반적인 격차: 내보낸 보고서가 아닌 포털, 스크린샷이 아닌 콘솔, 명세서 PDF가 아닌 회계 파일, 월별 합계가 아닌 거래 데이터.
픽션 및 음성 작업에는 이 레버를 건너뛰십시오. 편지, 이메일, 서류는 의사결정 문서이므로 고도가 완전히 적용됩니다. 소설은 그렇지 않습니다.
레버 2, 깊이(Depth): 해당 분야 최고 전문가의 방식으로 작업
Rieseberg의 프레이밍으로 시작하십시오: 더 큰 작업이 아닌 더 깊은 버전의 작업. 페이지 수가 많다고 깊이가 아닙니다.
- 해당 분야 최고 전문가가 사용하는 도구를 사용하십시오. 정직한 도구가 데이터베이스와 통계 테스트라면, 마크다운 테이블을 제시하지 마십시오. 합계가 입력된 리터럴인 스프레드시트는 입력과 불일치할 수 없으므로 오류를 보고하지 않습니다.
- 비현실적인 목표를 정하고 그것을 합리적인 것처럼 다루십시오. 위의 가드레일을 따라야 합니다.
- 사용자가 이미 믿고 있는 것에 도전하십시오. 명시된 전제를 가장 원천적인 자료로 가져가서 재진술하는 대신 적대적으로 테스트하십시오. 전제 중 데이터에서 살아남지 못하는 부분이 무엇인지, 살아남는 부분보다 먼저 말하십시오.
- 새로운 지식을 생성하십시오. 데이터 속으로 깊이 들어간 후에는 사각지대를 찾으십시오. 작은 시뮬레이션을 구축한 다음, 그 예측을 아직 보지 못한 데이터에 대해 테스트하십시오.
- 외부 심판을 사용하고, 절대 자기 평가를 하지 마십시오. Rieseberg는 이상적으로는 모델이 즉각적인 피드백을 위해 실행할 수 있는 도구라고 말합니다.
외부 심판은 건너뛰는 레버입니다
심판은 거부할 수 있는 것입니다. 두 번째 의견, 체크리스트, 재독서가 아닙니다. 작업 유형별로 하나씩 만들거나 차용하십시오:
| 작업 유형 | 거부할 수 있는 심판 |
|---|---|
| 다중 파트 빌드 또는 감사 | 실행 가능한 검사와 예상 출력이 있는 게이트 파일. 검사가 통과하지 않으면 완료 주장이 실패합니다. |
| 수치 또는 합계 | 입력에서 다시 계산하고 불일치 시 0이 아닌 코드로 종료하는 스크립트. 일치 횟수는 사전에 명시합니다. |
| "거기에 없습니다" | 완료할 수 없는 루트를 보고하는 검색 도구. 부분 통과에서 부재를 추론하지 않도록 합니다. |
| 다른 사람에게 보내는 문서 | 식별자나 검토되지 않은 이름에서 차단되는 스캔. |
| 스타일 규칙에 대한 산문 | 기계적으로 결정 가능한 규칙에 대한 린터. 조언이 아니라 거부합니다. |
| 이전 결론 | 출처와 날짜가 포함된 결정 원장. 재도출이 아닌 검증됨. |
적합한 도구가 없는 경우 심판은 기본 소스를 직접 읽는 것입니다. 결코 모델이 자신의 출력을 자체적으로 읽는 것이 아닙니다.
네 가지 질문 깊이 프롬프트
시작하기 전에 네 가지 모두에 답하고, 재작성된 요청을 보여주십시오:
- 이 분야 최고의 사람이 요청받지 않은 일을 무엇을 할 것인가?
- 그들이 시작할 가장 원천적인 자료는 무엇인가? 요약이 아닌 실제 문서를 명시하십시오.
- 그들은 어떤 특정 방법과 도구를 사용할 것인가?
- 사용자나 모델 외에 결과가 옳다는 것을 보여줄 것은 무엇인가? 실행 가능한 검사를 명시하십시오.
그런 다음 요청을 정확히 그 내용으로 재작성하고, 빌드하기 전에 재작성된 내용을 보여주십시오.
도메인별 바로 사용 가능한 문구는 references/prompts.md에 있습니다.
레버 3, 범위(Range): 다른 분야와 그 사람들
- 명사를 동사로 바꾸십시오. 결과물은 '사물'이고, 직무는 '행동'입니다. 분기별 검토는 '덱'이 아니라, 바쁜 사람들이 인과관계에 대한 이야기를 믿고 불확실성 속에서 결정을 내리도록 하는 것입니다. 수요 통지서(demand letter)는 상대방에게 지불이 가장 저렴한 경로가 되도록 만드는 것입니다. 리스팅 페이지는 낯선 사람이 알려지지 않은 작가에게 돈을 걸기로 결정하는 것입니다. Tom Kelley와 Jonathan Littman의 The Art of Innovation에서 인용.
- 팀을 구성하십시오. 강력한 팀이 가져야 할 역할을 명명하십시오. 명백한 분야 외부의 역할과 레드팀을 포함합니다. Rieseberg의 예: 분석가, 저널리스트, 편집자, 작업이 발표될 때의 모션 및 오디오 디자이너, 그리고 레드팀으로 공매도 전문가와 법의학 회계사. 도메인별 팀은
references/crews.md에 있습니다. - 행동하십시오, 역할극하지 마십시오. 역할이 쓰는 '어조'가 아니라 역할이 하는 '작업'을 요청하십시오. "법의학 회계사처럼 써"는 이상한 산문과 더 나은 답변을 생성하지 않습니다. "공개된 모든 수치를 은행 거래 내역과 연결하고 연결되지 않은 것을 나열해"는 답변을 생성합니다.
역할 명명에 관하여. 많은 프롬프트 조언이 페르소나를 할당하라고 말하고 Rieseberg는 역할극을 피하라고 말합니다. 둘 다 다른 것에 대해 옳습니다: 역할을 명명하여 그 표준이 적용되도록 한 다음, 그 출력을 요청하고, 절대 그 등록체(register)를 요청하지 마십시오.
순서
- 프로젝트의 현재 상태에 대한 기록이 있다면 그것을 읽으십시오. 그것 없이는 더 높은 목표는 추측에 불과합니다.
- 고도(Altitude). 단계와 접근 격차를 제시하십시오. 하나를 선택하고 대비책을 명명하십시오.
- 깊이(Depth). 네 가지 질문에 답하고, 심판을 명명하고, 재작성된 요청을 보여주십시오.
- 범위(Range). 명사가 아닌 동사, 팀 구성, 작업(목소리 아님) 할당.
- 프로젝트가 사용하는 검토 및 완료 규율에 인계하십시오.
- 네 개의 마무리 줄과 함께 목표에 대해 보고하십시오.
작은 작업에 이 모든 것을 실행하지 마십시오. 30분짜리 작업에는 한두 개의 단계와 명명된 심판이 전부입니다. 전체 순서는 여러 세션에 걸친 빌드, 법의학 분석, 정기 결과물, 또는 '아니요'라고 말할 수 있는 사람이 읽는 모든 것에 대해 그 비용을 정당화합니다.
좋은 결과의 모습
이 스킬의 응답은 메뉴로 시작하지 않습니다. 한 줄로 높아진 목표를, 그 다음 단계, 그리고 그것이 작동했는지 여부를 확정할 심판을 제시하는 것으로 시작합니다. 적용되는 프레임워크처럼 읽히고 더 나은 답변을 제안하는 것처럼 읽히지 않는다면, 스킬은 실패한 것이며 평범한 답변이 옳았던 것입니다.