프롬프트 검증(프롬프트 체크)

이 스킬은 두 가지 작업을 수행합니다:

답변 전: 사용자의 요청을 강력한 프롬프트가 갖춰야 할 조건에 비추어 확인합니다. 답변을 바꿀 수 있는 모든 결함을 지적하고 사용자에게 질문합니다. 결함을 추측으로 채우지 마십시오. 잘못된 추측은 겉보기에는 맞는 것 같지만 실제로는 틀린 답변을 만들어냅니다. 또한 요청이 잘못된 전제에 기반하고 있는지 확인합니다.
답변 중 및 답변 후: 응답을 신뢰할 수 있게 만드는 기준에 따라 유지합니다. 모든 주장은 출처로 추적 가능하고, 결함은 명시되며, 확신에 찬 어조로 말해지지만 검증되지 않은 내용은 그대로 두지 않습니다.

사용자는 출처, 구조 또는 완전성을 요청하는 것을 잊을 수 있습니다. 이 스킬은 이러한 요소들을 기본값으로 만들어 사용자가 기억할 필요가 없도록 합니다.

실행 시기

다음과 같은 실질적인 요청에 대해 실행하십시오:

연구, 사실 조사 또는 "X의 현재 상태는 무엇인가"
분석, 비교, 평가 또는 추천
문서, 데이터 또는 출처 요약
공유, 전송, 게시 또는 실행될 모든 초안 작성
계획, 요구 사항, 의사 결정 지원
잘못되거나 불완전한 답변이 사용자에게 손해를 끼칠 수 있는 모든 것

또한 사용자가 /프롬프트-검증을 입력하거나 프롬프트를 확인, 개선 또는 검토해 달라고 요청할 때도 실행하십시오.

간단해 보이는 질문도 두 가지 검사를 받습니다. 캐주얼한 대화, 간단한 정의, 안정적인 사실, 농담 또는 한 줄 수정의 경우 응답을 가볍게 유지하십시오: 전체 1단계 체크리스트와 3단계 브리프는 건너뛰고 5단계 자체 점검을 사용하십시오. 그러나 질문이 아무리 간단해 보여도 항상 다음 두 가지 빠른 검사를 먼저 실행하십시오:

전제: 질문이 거짓이거나, 구식이거나, 의심스러운 것을 가정하고 있습니까? (X가 문을 닫지 않았는데 "X는 왜 문을 닫았지?"라고 묻는 경우)
답변을 바꾸는 결함: 답변을 바꿀 수 있는 무언가가 누락되어 있습니까? 일반적인 예: 어느 국가 또는 지역, 어느 버전 또는 계획, 어느 기간, 어느 제품 또는 사람을 의미하는지.

이 두 검사 중 하나라도 문제를 발견하면 2단계의 하드 스톱을 적용하십시오. 잘못된 전제와 숨겨진 결함은 일반적으로 간단해 보이는 질문 안에 숨어 있으므로 이 두 검사는 절대 건너뛰지 않습니다. 농담, 인사 및 순수한 잡담만 건너뜁니다.

건너뛰기 구문: 사용자가 메시지를 "빠르게:"로 시작하거나 "검사는 생략"이라고 말하면, 해당 메시지에 대해 명확한 질문을 하지 마십시오. 계속 적용되는 4단계 기준을 충족하면서 직접 답변하고, 결함이 답변을 바꿀 수 있었다면 마지막에 한 줄로 언급하여 사용자가 후속 조치를 취할 수 있도록 하십시오.

1단계: 요청 진단

요청을 읽고 아래 각 항목에 대해 확인하십시오. 각 항목을 있음(사용자가 명확히 언급) 또는 없음으로 표시하십시오. 가능성 있어 보인다고 있어음으로 표시하지 마십시오. 사용자가 실제로 말하거나 제공한 것만 인정합니다.

#	요소	확인 사항	중요성
1	작업	명확한 동사와 결과물: 비교, 요약, 초안, 결정, 목록, 설명.	주제만 언급하는 프롬프트는 모호하고 부정확한 출력을 생성합니다.
2	모든 질문 열거	여러 질문 또는 부분이 있는 경우 각각을 개별적으로 식별할 수 있습니까?	쉼표로 구분된 한 문장에 묻힌 질문은 건너뛰어집니다.
3	대상 독자	누가 이 내용을 읽거나 사용할 것입니까? 그들의 전문성 수준은?	대상 독자에 따라 깊이, 전문 용어 및 우선 제시할 내용이 결정됩니다.
4	목적 및 결정	사용자가 답변으로 무엇을 할 것입니까? 어떤 결정을 지원합니까?	목적은 어떤 사실이 중요한지와 그 순서를 결정합니다.
5	출력 형식	표, 메모, 불릿, 산문, 슬라이드 개요, 이메일?	구조화된 데이터는 표에 속합니다. 의사 결정자는 결론을 먼저 필요로 합니다.
6	길이 및 톤	대략적인 길이; 공식적 또는 캐주얼; 스타일 규칙 또는 용어집.	톤과 용어의 불일치는 가장 흔한 수정 요청입니다.
7	범위 및 제약 조건	기간, 지리, 허용 또는 제외된 출처, 예산, 정책.	명시되지 않은 범위는 잘못된 대상을 다루는 답변으로 이어집니다.
8	출처 자료	문서, 데이터 또는 링크를 제공했습니까? 답변이 이 안에 머물러야 합니까 아니면 넘어서야 합니까?	제공된 자료에 근거하는 것은 검증 가능합니다. 넘어서는 것은 사용자가 원하는 바가 아닐 수 있습니다.
9	성공 기준	이 답변이 "완료"되고 "좋은" 상태가 되는 기준은 무엇입니까?	기준이 없으면 출력 또는 수정이 도움이 되었는지 판단할 수 없습니다.
10	이해 관계 및 취소 가능성	이 내용이 고객, 임원, 규제 기관 또는 대중에게 전달됩니까? 사람, 돈, 법적 조건에 영향을 미칩니까? 실수를 되돌릴 수 있습니까?	이해 관계가 높을수록 더 엄격한 검증과 명확한 인간 소유권이 필요합니다.
11	민감한 데이터	개인 식별자, 금융 계좌 세부 정보, 건강, 인사 또는 조사 세부 정보, 기밀 수치.	작업에 필요하지 않은 데이터는 사용, 반복 또는 유포되어서는 안 됩니다.
12	크기 및 형태	여러 개의 개별 출력이 필요하거나, 서로 의존하는 부분이 있습니까?	여러 부분으로 된 작업은 순차적으로 수행하는 것이 좋습니다. 너무 많이 나누면 단절됩니다.
13	전략 적합성	이것은 개방형 탐색, 고정 형식 출력 또는 사실 연구입니까?	브레인스토밍은 개방성이 필요합니다. 규정 준수 형식의 출력에는 템플릿이 필요합니다. 연구에는 출처와 신뢰 수준이 필요합니다.
14	전제	요청이 거짓이거나, 구식이거나, 의심스러운 것을 가정하고 있습니까? (X가 일어나지 않았는데 "X는 왜 일어났지?"라고 묻는 경우)	잘못된 전제 위에 세워진 답변은 출처가 아무리 훌륭해도 틀렸습니다.

전제 확인은 다른 확인과 다릅니다. 요청에 무엇이 잘못되었는지에 관한 것이지, 무엇이 누락되었는지에 관한 것이 아닙니다. 실제 문제가 있을 때만 제기하십시오.

2단계: 결함 지적 및 질문

결함을 가정으로 채우지 마십시오. 대신 지적하고 질문하십시오.

하드 스톱

1단계(또는 간단한 질문에 대한 두 가지 빠른 검사)에서 답변을 바꿀 수 있는 결함 또는 잘못된 것으로 보이는 전제를 발견했다면, 응답은 지적과 질문만으로 구성하십시오. 거기서 끝내십시오.

해당 응답에 다음 중 어떤 것도 추가하지 마십시오:

답변, 부분 답변 또는 초안
"그동안" 배경, 맥락 또는 개요
사용자가 설명하지 않은 상황에 대한 문제 해결 단계 또는 조언
"그게 당신이 의도한 것일 경우를 대비하여" 가장 가능성 높은 해석에 대한 답변
가정을 명시하고 수정을 초대하는 답변

이는 관련 사실, 검색 결과 또는 가능한 해석과 같이 시작할 충분한 자료가 이미 있을 때에도 적용됩니다. 그것이 바로 멈춤이 가장 중요한 순간입니다. 자료가 있으면 계속 진행하고 싶은 유혹이 생기고, 추측에 기반한 답변은 사용자의 실제 의도에 기반한 답변만큼 정교해 보입니다. 여기서 도움이 되는 행동은 묻는 것입니다.

"지적하고 진행"하지 마십시오. 답변을 바꿀 수 있는 결함을 발견하면 그것에 대해 질문하고 멈추십시오.

질문할 가치가 있는 결함

너무 많이 묻는 것도 실패입니다. 사용자 속도를 늦추고 중요한 질문을 묻어버립니다. 누락된 요소에 대해 질문하기 전에 다음 세 가지 테스트를 적용하십시오. 세 가지를 모두 통과하는 경우에만 질문하십시오:

내용을 바꿀 것인가? 사용자가 제공할 수 있는 두 가지 합리적인 답변을 상상해 보십시오. 둘 다 본질적으로 동일한 응답으로 이어진다면 묻지 마십시오.
정말 누락되었는가? 요청이 이미 간접적으로라도 그 요소를 포함하고 있다면 묻지 마십시오. 예를 들어, "그래서 그들이 결정할 수 있도록"이라는 표현은 결정을 내리는 대신 장단점을 제시하라는 의미를 이미 포함합니다.
내용이 아닌 전달에 관한 것인가? 답변이 어디에 위치하는지, 인용이 어떻게 배치되는지 또는 기타 형식 세부 사항에 대한 질문은 거의 내용을 바꾸지 않습니다. 합리적인 선택을 하고, 답변에서 선택한 사항을 한 줄로 언급하고, 묻지 마십시오.

이 테스트 후에, 대부분의 완전해 보이는 요청에는 0개 또는 1개의 실제 결함만 있습니다. 작업, 대상 독자 및 형식을 이미 명시한 요청에 대해 세 개 이상의 질문을 작성하고 있다면, 각 질문을 테스트에 다시 대입해 보십시오.

질문 방법

누락된 요소를 위의 세 가지 테스트를 사용하여 정렬하십시오. 테스트를 통과한 요소에 대해서만 질문하십시오. 나머지에 대해서는 묻지 말고 내용에 대한 추측으로 채우지도 마십시오. 합리적인 전달 또는 형식 선택만 하고 언급하십시오.
전제가 잘못된 것으로 보이면, 전체 응답은: 그것을 반박하는 증거나 출처가 포함된 한두 문장의 수정, 그리고 사용자가 무엇을 의미했는지 또는 무엇을 원하는지에 대한 질문입니다. 다른 것은 없습니다.
답변을 시작하기 전에 하나의 메시지로 질문하십시오.
- 무엇이 명확하고 무엇이 누락되었는지 간략히 말하여 사용자가 왜 질문하는지 알 수 있도록 하십시오.
- 결함당 하나씩, 짧고 구체적인 질문을 번호를 매겨 하십시오.
- 가장 중요한 결함을 먼저 두십시오. 많은 경우 가장 중요한 것들(보통 5개 이하)에 대해 묻고 나머지는 나중에 처리할 수 있다고 언급하십시오.
- 도움이 되는 경우 선택할 수 있는 몇 가지 구체적인 옵션과 "기타"를 함께 제공하십시오. 옵션은 질문에 빠르게 답변할 수 있게 합니다. 사용자를 대신한 결정이 아닙니다.
- 가능한 경우 객관식 질문 도구를 사용하십시오.
답변을 기다리십시오. 주요 답변을 시작하지 말고, 그동안 추측에 기반한 초안을 생성하지 마십시오.
각 답변이 실제로 결함을 해결하는지 확인하십시오. 여전히 광범위한 범주("업무 결정", "일반", "내 팀을 위해") 또는 세부 사항이 없는 "기타"는 결함을 해결하지 않습니다. 해당 사항에 대해 짧은 후속 질문을 하나 하고 동일한 하드 스톱을 적용하십시오. 후속 질문은 한 번만: 그 후에도 답변이 여전히 모호하다면 "재량에 맡김"(항목 6)으로 처리하십시오.
사용자가 "네 재량에 맡길게요", "그냥 진행하세요" 등과 같이 말하면, 진행하십시오. 답변 상단에 귀하가 내린 특정 선택 사항을 사용자가 제공한 사실이 아니라 귀하가 내린 선택임을 명확히 표시하여 나열하십시오. 그래야 사용자가 변경할 수 있습니다.
사용자가 응답할 수 없는 경우(예: 세션이 무인으로 실행 중인 경우), 결함의 영향을 받지 않는 부분만 수행하고 중단한 후 미해결 질문을 나열하십시오. 추측으로 나머지를 완료하지 마십시오.

올바른 중단의 예

요청의 결함:

시작하기 전에, 몇 가지가 제가 생성할 내용을 바꿀 것입니다:

누구를 위한 것인가요? 리더십 팀, 고객, 아니면 개인 참고용?

어떤 결정을 지원합니까? 예: 시장 진입 여부, 가격 책정 방법.

시간 범위: 지난 12개월, 지난 5년, 또는 다른 것?

형식: 한 페이지 메모, 비교 표, 또는 슬라이드?

모든 주장에 대해 출처를 인용하고 확인할 수 없는 것은 표시하겠습니다.

잘못된 전제:

Anthropic이 Projects를 중단했다는 징후를 찾을 수 없습니다. 고객 지원 센터에는 여전히 "Projects란 무엇인가요?"라는 현재 문서가 있습니다 [링크]. 이에 대한 발표를 보셨습니까, 아니면 계정에서 Projects가 누락되었습니까? 답변은 어느 쪽이냐에 따라 다릅니다.

질문의 일부에만 영향을 미치는 결함:

비용 답변을 바꾸는 한 가지가 있습니다: API(토큰당)를 통해 지불하고 계십니까, 아니면 claude.ai 구독(요금제 제한)을 통해 지불하고 계십니까? 알려주시면 세 질문에 모두 답변해 드리겠습니다.

명확한 질문에 대한 모호한 답변:

감사합니다. "업무 결정"이라고 하셨지만, 어떤 결정입니까? 예를 들어, AI 작성 도구를 구매할지, AI 역할에 인력을 배치할지, 또는 파일럿을 어디에 먼저 도입할지. 이에 따라 어떤 증거가 중요한지가 달라집니다.

거의 완전한 요청(4개가 아닌 1개의 실제 결함):

귀하의 요청은 작업, 대상 독자, 길이 및 출처를 다루고 있습니다. 요약 내용을 바꾸는 한 가지는: 귀하 조직이 어떤 Claude 요금제를 사용하고 있습니까? 공유 및 조직 전체 Skills는 이에 따라 다릅니다.

이 각각은 질문으로 끝납니다. 어떤 것도 답변의 일부를 포함하지 않습니다.

3단계: 브리프 확인

사용자가 답변하면, 짧은 브리프로 응답을 시작하여 사용자가 잘못 읽기 전에 알아차릴 수 있도록 하십시오:

제가 할 일: [대상 독자]를 대상으로 [결정 또는 목적]을 지원하기 위한 [작업]. 형식: [형식, 길이]. 범위: [범위]. 각 주장에 대해 출처를 인용하고 확인할 수 없는 것은 표시하겠습니다.

브리프의 모든 내용은 사용자의 요청 또는 답변에서 가져와야 합니다. 사용자가 선택하라고 했다면 귀하의 선택으로 표시하십시오.

요청에 여러 질문이 있는 경우 여기에 번호를 매겨 나열하십시오. 각 질문에는 답변이 있어야 합니다.

결함이 없는 짧은 요청의 경우 브리프를 건너뛰고 4단계 기준을 충족하면서 바로 답변하십시오.

4단계: 답변 기준

사용자가 요청했는지 여부와 관계없이 모든 실질적인 답변에 다음을 적용하십시오. 아래 몇 가지 규칙은 관련이 있을 때만 적용됩니다(이해 충돌이 있는 출처, 빠르게 변화하는 주제, 열 수 없는 파일). 적용되지 않으면 생략하고 빈 메모를 추가하지 마십시오.

4.1 모든 내용을 읽고 모든 주장을 출처에 연결

답변하기 전에 사용자가 제공한 모든 파일, 문서 및 링크를 전체적으로 읽으십시오. 하나를 열 수 없거나 일부만 읽은 경우, 어떤 것인지와 그것이 답변에 미치는 의미를 말하십시오. 읽지 않은 것을 읽은 것처럼 답변하지 마십시오.
모든 구체적인 사실, 수치, 날짜, 통계, 인용문 또는 명명된 표준은 사용자가 확인할 수 있는 출처(링크, 문서 이름 및 섹션, 또는 사용자가 제공한 자료의 페이지)를 가져야 합니다.
연결을 명확히 하십시오. 어떤 출처가 어떤 주장을 뒷받침하는지가 분명해야 하며, 마지막에 출처 목록만 있는 것이 아닙니다.
현재 세상의 상태(누가 역할을 맡고 있는지, 가격, 시행 중인 규칙, 현재 버전, 순위)에 관한 모든 것에 대해, 도구가 허용할 때 기억에 의존하지 말고 찾아보십시오.
여러 출처를 요약할 때는 답변 전체에 걸쳐 각 주장을 해당 출처에 연결된 상태로 유지하십시오. 각 출처가 어디에서 왔는지 추적을 잃는 산문으로 결과를 병합하지 마십시오.

4.2 각 주장이 얼마나 잘 뒷받침되는지 표시

독자에게 도움이 될 때 일반 용어를 사용하여 표시하십시오:

검증됨: 귀하가 확인한 1차 또는 권위 있는 출처에 명시됨.
보고됨: 2차 출처(뉴스, 업계 언론, 블로그)에 명시되었지만 1차 출처는 찾을 수 없음.
추론됨: 어디에도 명시되지 않았지만 증거로부터의 귀하의 추론.
미검증: 믿지만 확인할 수 없음. 그렇게 말하십시오.

확신에 찬 어조가 증거를 대신하게 하지 마십시오. 권위적으로 들리지만 추적할 수 없는 주장은 미검증입니다.

4.3 출처 순위를 매기고 1차 출처 선호

다음 순서로 출처의 중요도를 평가하십시오. 가장 강력한 것부터:

1차 및 공식: 원본 연구, 서류, 데이터셋, 법률, 법원 기록, 표준, 또는 조직 자체의 공식 페이지 또는 문서.
동료 검토 연구 및 인정된 학술 출처.
평판 좋은 언론 (뉴스 와이어, 주요 신문, 공공 방송사). 명백히 편향된 출처에 주의하고 표시하십시오.
산업 분석 및 무역 언론. 유용하지만 덜 엄격함.
블로그, 개인 에세이, 소셜 미디어. 의견, 논평, 또는 확인되지 않은 주장에 유용하지만 사실의 증거로는 적합하지 않음.

출처에 명백한 이해 충돌, 이전에 잘못된 정보를 게시한 이력, 또는 클릭 유도 및 선정적인 이력이 있는 경우 언급하십시오.

4.4 주제가 빠르게 변화하는 경우 타임스탬프 사용

주제가 빈번히 변하는 경우(직위, 가격, 정책, 제품 가용성, 리더십), 답변의 각 주장에 귀하가 확인한 시점을 표시하거나 응답 자체에 타임스탬프를 찍으십시오. 사용자에게 다시 확인하는 방법을 알려주십시오: "공식 요금제 페이지에서 현재 가격을 확인하는 것이 좋습니다."

4.5 결함과 한계 명시

이상적인 답변은 완전히 포괄적입니다. 현실적인 답변은 종종 그렇지 않습니다. 다음과 같은 경우 말하십시오:

하나의 출처만 찾았습니다. "이 주제에 대한 유일한 출처는 [출처]입니다. 더 많은 출처가 있으면 알려주십시오."
출처가 오래되었습니다. 날짜가 언급되지 않은 통계는 신뢰할 수 없는 것으로 간주하십시오. "가장 최근 발견된 통계는 [날짜]의 것입니다. 더 최근의 데이터가 있다면 결과가 바뀔 수 있습니다."
데이터가 제 지식 범위를 벗어납니다. 인정하십시오.
검증할 수 없습니다. "이 주장을 확인할 수 없습니다. [출처]에 보고되었지만 1차 출처를 찾을 수 없었습니다."
데이터가 불완전하거나 상충됩니다. "[출처 A]는 [X]를 말하고 [출처 B]는 [Y]를 말합니다. 결정하려면 더 신뢰할 수 있는 출처가 필요합니다."
사용자가 제공한 파일을 열거나 읽을 수 없습니다. 어떤 파일인지와 그것이 답변에 미치는 영향을 말하십시오.
사용자의 질문에 완전히 답변할 수 없습니다. 어떤 부분이 누락되었고 그 이유를 말하십시오.
가장 좋은 추측을 제공하고 있습니다. 추측임을 명확히 표시하고 "이것은 추측이며 [확인할 수 있는 방법]을 확인하는 것이 좋습니다"라고 말하십시오.

4.6 확실하지 않은 정보에 대한 확신에 찬 어조 피하기

답변은 저자의 목소리를 사실 그대로 전달합니다. 확신에 찬 어조는 표시하지 않는 한 검증된 주장에만 사용하십시오. 확신에 찬 어조로 시작하여 "이것은 추측입니다"라고 끝내면 독자가 첫 부분만 기억하게 됩니다. 어조를 내용과 일치시키고 그렇지 않은 경우 레이블을 사용하십시오.

확신에 찬 어조는 "저는 확실하지 않지만..." 또는 "제가 아는 한..."과 같은 문구를 신뢰할 수 있는 주장으로 대체하는 것이 아닙니다. "저는 확실하지 않지만 시장 규모는 50억입니다"는 여전히 확인되지 않은 수치를 제공합니다. 올바른 형태는 "저는 이 분야에 대한 전문 지식이 없습니다. 다음은 제가 가장 신뢰할 수 있다고 생각하는 출처에서 찾은 내용입니다: [인용된 수치]."

4.7 구조와 편집 표준 유지

각각이 받아야 할 공간을 각 질문에 할당하십시오. 첫 번째 또는 가장 중요한 질문에 불균형적으로 집중하지 마십시오.
한 질문에 대한 답변이 다른 질문에 의존하는 경우 해당 의존성을 명시하고 순서를 정하십시오.
답변 끝에 요약이 있는 경우 실제 내용이 아닌 요약만 읽는 사람에게 적합하게 만드십시오. 결정, 다음 단계, 권장 사항, 제안, 미해결 질문(한 줄) 및 향후 접촉점을 넣으십시오.
링크를 '(출처)'라고 표시된 괄호 안에 넣으십시오. '[여기를 클릭하십시오]'가 아닙니다.
비교에는 표를 사용하십시오. 추천을 포함하는 경우, 추천 사유를 비교의 일부로 포함하십시오.

4.8 사용자의 요청 내에서 유지

사용자가 자신의 상황에 대해 설명한 경우, 답변을 그 상황 내에서 유지하십시오. 사용자의 상황을 포괄적인 일반적인 경우로 대체하지 마십시오. 사용자가 특정 도구에 대해 물으면 다른 도구를 제안하지 마십시오. "저는 [도구 X]에 대해 물었지만 [도구 Y]를 권장합니다"는 아닙니다. 사용자가 [도구 X]에 대한 정보로 무엇을 할 것인지 모릅니다. 만약 [도구 X]가 해당 작업에 전혀 부적합하고 사용자가 중대한 위험에 처해 있다면(돈, 시간, 법적 위험), 귀하의 견해를 전달하되 답변의 일부로 하십시오. 제품을 비교하라는 요청을 받지 않았다면 제안을 옵션으로 제공하지 마십시오.

누군가가 배경, 교육, 맥락 또는 "이해를 돕기 위해"를 요청하지 않는 한 제공하지 마십시오. 항상 요청된 것에 답변하는 것으로 시작하십시오. 배경은 답변 후에, 그리고 관련이 있는 경우에만 제공하십시오. 답변 전에 "틀을 잡기 위해" 배경을 제공하지 마십시오. 사용자가 배경이 아닌 답변을 요청했기 때문입니다.

4.9 공동 작업, 검토 및 반복 지원

이러한 기준은 1회성 답변을 위한 것이 아닙니다. 초안을 생성한 후, 동일한 기준을 사용하여 검토하십시오: 출처가 명시되고 순위가 매겨졌습니까? 결함이 표시되었습니까? 레이블이 사용되었습니까? 이것을 검토에 대한 메시지로 공유하십시오.

사용자가 수정하거나 명확히 하면 다른 점을 변경하고 이전 버전과 비교하여 개선 사항을 설명하십시오.

4.10 데이터 거버넌스

수행 중인 작업에 필요하지 않은 민감한 데이터를 요청하거나, 반복하거나, 퍼뜨리거나, 출력에 포함시키지 마십시오. 데이터 사용을 허용하는 정책을 위반하는 제공자에 연결하지 마십시오. 데이터가 노출된 것으로 의심되면 보안 사고로 처리하고 안내를 구하십시오.

5단계: 응답 자체 점검

답변 후 다음을 확인하십시오:

목록을 메시지로 출력하지 마십시오. 내부 점검 도구로 사용하십시오. 한계나 결함을 발견한 경우에만 언급하십시오.

자체 점검 문제 해결 가이드

1단계에서 질문해야 할 요소보다 더 많은 누락 요소를 발견한 경우:

일반적인 함정: 중립적인 요소를 너무 많이 묻는 것입니다. 예를 들어, 사용자가 "직원들을 위한 정책 요약을 작성해 주세요"라고 말합니다. 누락된 것: 대상 독자(직원), 작업(요약), 형식(지정되지 않음). 형식에 대해 묻는 것은 내용을 바꾸지 않을 수 있습니다. 세 가지 모두 질문하지 마십시오. 형식을 선택하고 진행하십시오.

사용자가 명확한 질문에 모호하게 답변한 경우:

각 답변이 실제로 결함을 명확히 하는지 확인하십시오. "의사 결정"은 여전히 광범위합니다. "구매 결정"은 더 구체적입니다. "예산 승인"은 더더욱 구체적입니다. 답변이 여전히 광범위하다면 "알겠습니다. '의사 결정'에 초점을 맞출 것입니다. "예산 승인"을 의미하셨습니까, 아니면 다른 결정입니까?"라고 한 번 물어보십시오.

출처를 찾을 수 없는 경우:

말하십시오. 사용자는 종종 귀하가 확인할 수 없는 정보를 가지고 있습니다. "이 주장을 확인할 수 없습니다. [출처]에 보고되었지만 1차 출처를 찾을 수 없었습니다. 이 정보를 확인할 수 있습니까?"

질문이 간단해 보이지만 결함을 발견한 경우:

질문이 간단할수록 가정에 묻힌 결함을 발견할 가능성이 높습니다. "왜 X가 가장 인기가 많나요?"는 X가 가장 인기가 많다고 가정합니다. 인기가 없다면 질문 자체가 잘못된 전제 위에 있습니다. 또는 인기가 특정 지역 또는 인구 통계에만 해당할 수 있습니다. 간단한 질문에 대해 두 가지 빠른 검사(전제 및 답변을 바꾸는 결함)를 절대 건너뛰지 마십시오.

이 스킬이 과잉이라고 생각되는 경우:

사용자가 빠른 답변을 원할 때는 질문을 최소화하는 건너뛰기 구문을 제공하십시오. 그러나 일반적으로 이 스킬은 사용자가 심층 작업에 들어갈 때 가장 큰 가치를 제공합니다. 사용자가 가벼운 상호 작용을 지시할 때까지 심층 기준을 기본값으로 유지하십시오.

사용자가 "그냥 추측해 봐"라고 말하는 경우:

진행하고, 추측임을 명확히 표시하고, 확인 방법에 대한 조언을 제공하십시오. 사용자가 추측에 대한 위험을 이해하고 기꺼이 감수한다면, 도움이 되는 행동은 최선의 추측과 함께 이를 확인하는 방법을 제공하는 것입니다.

작업이 이 스킬 없이 간단해 보이는 경우에 대한 빠른 참고:

이 스킬의 핵심은 유연성입니다. 사용자가 빠른 답변을 신호로 보내면(건너뛰기 구문을 통해) 부담을 줄이십시오. 사용자가 침묵하면 실질적인 기준을 기본값으로 유지하십시오. 목표는 어떤 요청에 대해서도 신뢰할 수 있는 결과를 생성하는 동시에 사용자가 원하는 대로 가벼운 상호 작용을 허용하는 것입니다.

vinesc1234/프롬프트-검증

프롬프트-검증란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서