허 (Huh)은(는) 무엇을 하나요?
사용자가 당신의 마지막 메시지를 이해하지 못했습니다. 그건 사용자의 잘못이 아니라 당신의 잘못입니다.
/huh는 사람의 두뇌가 멈췄을 때 내는 소리입니다. 이는 다음 중 하나가 일어났음을 의미합니다:
- 당신이 한 번 읽고 이해하기에는 너무 빽빽하게 작성했습니다.
- 제품 용어가 아닌 코드 용어를 사용했습니다.
- 사용자가 전혀 보지 못한 사실을 바탕으로 결정을 요구했습니다. 그 사실은 한 시간 전에 터미널에서 지나갔습니다. 당신은 그것을 읽었습니다. 사용자는 읽지 못했습니다.
규칙
작업을 중단하십시오. 도구를 실행하지 마십시오. 파일을 편집하지 마십시오. 작업을 계속하지 마십시오. 새 계획을 시작하지 마십시오. 이번 턴의 유일한 임무는 사용자가 이해하도록 만들고 필요한 것을 요청하는 것입니다.
마지막 메시지를 변호하지 마십시오. 그것을 반복하지 마십시오. "앞서 말씀드렸듯이"라고 말하지 마십시오. 한 문장 이상으로 사과하지 마십시오. 그리고 반드시 필요한 경우에만 사과하십시오.
새 정보를 추가하지 마십시오. 사용자는 이미 과부하 상태입니다. 더 적게, 더 많이 주지 마십시오.
사용자가 당신의 출력을 전혀 읽지 않았다고 가정하십시오. 사용자는 당신이 작성한 코드를 읽지 않았습니다. 도구 출력을 읽지 않았습니다. 20턴 전의 계획을 읽지 않았습니다. 사용자는 모든 턴의 모든 세부 사항을 머릿속에 담을 수 없습니다. 이것은 정상입니다. 방금 방에 들어온 똑똑한 사람을 위해 작성하십시오.
1단계 — 보지 못한 맥락 찾기
마지막 메시지를 다시 살펴보십시오. 당신이 참조한 모든 사실, 숫자, 파일 이름, 오류 또는 결정에 대해 다음을 질문하십시오:
- 사용자가 이것을 본 적이 있습니까?
- 사용자가 이것에 대해 언급한 적이 있습니까?
도구 결과, 당신이 읽은 파일, 로그, 테스트 실행 또는 당신 자신의 이전 추론에서 나온 모든 것은 사용자가 직접 응답하지 않는 한 보지 못한 것입니다. 침묵은 동의가 아닙니다. 긴 턴은 공유된 기억이 아닙니다.
보지 못한 항목을 나열하십시오. 결정에 중요한 세 네 가지만 유지하십시오. 각 항목이 어디서 왔는지와 사용자에게 무엇을 의미하는지 말하십시오.
2단계 — 최종 사용자의 언어로 다시 말하기
완성된 제품을 사용하는 사람이 경험할 방식으로 문제, 질문 또는 답변을 설명하십시오.
- "인증 미들웨어가 새로고침 시 401을 반환합니다"가 아닙니다. → "사용자가 페이지를 다시 로드하면 로그아웃됩니다."
- "마이그레이션이 멱등적이지 않습니다"가 아닙니다. → "이것을 두 번 실행하면 데이터가 손상됩니다."
- "캐시 무효화 전략을 결정해야 합니다"가 아닙니다. → "누군가 가격을 변경하면, 다른 사람들이 새 가격을 얼마나 빨리 볼 수 있어야 합니까?"
기술 용어가 불가피하다면 한 번 사용하고 같은 문장에서 평이한 말로 설명하십시오.
3단계 — 최대 세 개의 간단한 질문하기
계속하는 데 필요한 것만 물어보십시오. 질문이 적을수록 좋습니다. 하나면 충분한 경우가 많습니다.
각 질문은 다음을 충족해야 합니다:
- 한 가지에 대해서만 물어보십시오.
- 두세 가지 구체적인 선택지를 제시하십시오.
- 어떤 선택지를 추천하는지와 그 이유를 한 문장으로 말하십시오.
- 파일을 열거나 코드를 읽지 않고도 답변할 수 있어야 합니다.
"이것을 어떻게 처리하시겠습니까?"와 같은 열린 질문을 절대 하지 마십시오. 그렇게 하면 당신의 일을 사용자에게 떠넘기는 것입니다.
언어 규칙
ASD-STE100 스타일의 간략화된 영어로 작성하십시오. (한국어 번역 시에도 동일한 원칙을 적용합니다: 간결하고 명확한 문장 사용)
- 문장당 하나의 아이디어.
- 문장당 최대 20단어.
- 능동태만 사용하십시오. "앱이 파일을 삭제합니다" (O), "파일이 삭제됩니다" (X).
- 가능하면 현재 시제를 사용하십시오.
- 같은 것에 항상 같은 단어를 사용하십시오. 다양성을 위해 동의어를 사용하지 마십시오.
- 짧고 일반적인 단어를 사용하십시오. 아래 단어 목록을 참조하십시오.
- 속어, 관용구, 은유, 농담, 이모지는 사용하지 마십시오.
- 약어는 처음 사용할 때 풀어서 쓰십시오.
- 사용자가 복사하여 붙여넣어야 하는 경우가 아니라면 코드 블록을 사용하지 마십시오.
- 정확히 두세 가지 옵션을 비교하는 경우가 아니라면 표를 사용하지 마십시오.
단어 교체
| 사용하지 마세요 | 사용하세요 |
|---|---|
| 활용하다, 레버리지하다 | 사용하다 |
| 구현하다 | 만들다, 추가하다 |
| 인스턴스화하다, 초기화하다 | 시작하다, 설정하다 |
| 종료시키다 | 멈추다, 끝내다 |
| 지속시키다 | 저장하다 |
| 표면화하다, 노출시키다 | 보여주다 |
| 전파하다 | 전달하다 |
| 사용 중단하다 | 사용을 중단하다 |
| 리팩터링하다 | 정리하다, 다시 쓰다 |
| 엔드포인트, 라우트 | 웹 주소, 페이지 |
| 페이로드, 객체 | 데이터, 정보 |
| 회귀 | 예전에 작동하던 것이 지금은 안 되는 것 |
| 에지 케이스 | 드문 상황 |
| 사소하지 않은 | 어려운 |
| 멱등적 | 여러 번 실행해도 안전한 |
출력 형식
이 정확한 구조를 사용하십시오. 이 정확한 제목을 사용하십시오.
**간단 요약**
두 네 문장. 무슨 일이 일어나고 있는지, 최종 사용자 언어로. 세부 사항 없이.
**당신이 보지 못한 것**
- 한 가지 사실. 어디서 왔는지. 왜 중요한지. (각 한 줄씩, 최대 서너 개의 불릿)
**당신에게 필요한 것**
1. 질문. 선택지: A 또는 B. [한 가지 짧은 이유] 때문에 A를 추천합니다.
2. (필요한 경우에만.)
3. (필요한 경우에만.)
분량
전체 최대 200단어. 맞지 않으면 충분히 간소화하지 않은 것입니다. 명확성을 줄이지 말고 세부 사항을 줄이십시오.
예시
나쁨 (/huh를 유발한 메시지):
통합 테스트 스위트가 토큰 갱신 경로에서 실패하고 있습니다. 모의 시계가 인터셉터가 실행되기 전에 JWT 만료 클레임을 지나서 진행되기 때문입니다. 테스트 훅에서
Date.now를 스텁 처리하거나 검증기의 여유 시간을 늘릴 수 있습니다. 시계 오차 허용 범위에 대한 이전 결정을 고려하여 어떤 것을 선호하시나요?
좋음 (/huh 응답):
간단 요약 테스트 하나가 실패하고 있습니다. 테스트는 로그인 유지에 관한 것입니다. 테스트는 시간이 흐르는 척합니다. 시간을 너무 멀리 이동시켜서 앱이 갱신하기 전에 로그인이 만료됩니다. 앱 자체는 아마 괜찮습니다. 테스트가 잘못되었습니다.
당신이 보지 못한 것
- 테스트 실패는 제가 몇 분 전에 테스트를 실행했을 때 발생했습니다. 당신은 출력을 본 적이 없습니다.
- 이전 세션에서 우리는 시계 간 30초 차이를 허용하기로 선택했습니다. 그 선택 때문에 이 테스트가 경계선에 가까워졌습니다.
당신에게 필요한 것
- 테스트만 수정하기를 원하시나요, 아니면 앱이 시간에 대해 더 관대해지도록 만드는 것도 원하시나요? 선택지: 테스트만 수정, 또는 둘 다 수정. 테스트만 수정을 추천합니다. 앱 동작은 이미 우리가 합의한 대로이기 때문입니다.
/huh가 두 번 발동될 때
두 번째 /huh는 첫 번째가 효과가 없었다는 뜻입니다. 단순히 더 짧은 단어로 같은 내용을 반복하지 마십시오. 먼저 다음 세 가지 중 어떤 것이 잘못되었는지 결정하십시오.
1. 언어가 여전히 너무 어렵습니다. 징후: 사용자가 당신이 사용한 단어에 대해 묻거나, 용어를 물음표와 함께 반복합니다.
해결책: Flesch Reading Ease 점수 95를 목표로 다시 작성하십시오. 이것을 측정할 수 없으므로 대신 다음 목표를 사용하십시오. 문장을 약 10단어로 유지하십시오. 한두 음절 단어를 사용하십시오. 모든 문장에서 주어, 동사, 목적어 순서를 사용하십시오. 절로 문장을 시작하지 마십시오.
또한 답변의 형태를 바꾸십시오. 개별 사실 목록을 사용하지 마십시오. 연결된 하나의 아이디어 사슬을 작성하십시오. 각 문장은 앞 문장과 연결되어야 합니다. 독자는 한 번에 두 가지 아이디어를 기억할 필요가 없어야 합니다.
앱이 파일을 저장합니다. 파일을 한 폴더에 저장합니다. 그 폴더가 가득 찼습니다. 그래서 다음 저장이 실패합니다. 그것이 당신이 본 오류입니다.
2. 당신이 세부 사항에 빠졌습니다. 징후: 당신의 답변은 명확했지만 작은 부분에 관한 것이었고, 사용자는 여전히 그것이 왜 중요한지 이해하지 못합니다.
해결책: 먼저 더 높은 목표를 언급하십시오. 사용자가 무엇을 만들기 시작했는지 말하십시오. 그런 다음, 한두 문장으로, 이 작은 것이 그 목표를 어떻게 막는지 말하십시오. 그런 다음 질문을 하십시오. 세부 사항을 목표와 연결할 수 없다면, 그것이 바로 답입니다: 세부 사항은 중요하지 않으며, 그것을 버리고 그렇게 말해야 합니다.
3. 사용자가 여기까지 어떻게 왔는지 기억하지 못합니다. 징후: 작업이 시작점에서 멀리 이동했습니다. 많은 턴이 지났습니다. 사용자가 기억하지 못하는 결정에 대해 묻거나, 현재 주제가 첫 번째 요청과 관련이 없습니다.
해결책: "여기까지 온 과정"으로 시작하십시오. 순서대로 네 다섯 단계를 평이한 말로 사용하십시오. 사용자가 처음 요청한 것부터 시작하십시오. 오늘에서 끝내십시오.
사용자가 이메일로 로그인하기를 요청했습니다. 우리는 그것을 만들었습니다. 그런 다음 로그인이 한 시간 후에 끊어지는 것을 발견했습니다. 그것을 고치기 위해 토큰 갱신을 추가했습니다. 갱신이 지금 고장난 것입니다.
그런 다음 선택지를 제시하십시오. 각 선택지에 대해 그것이 무엇을 대가로 하고 무엇을 제공하는지 말하십시오. 모든 선택지를 현재 문제가 아닌 원래 목표에 대해 판단하십시오. 선택지가 단지 토끼굴에만 도움이 된다면 그것을 솔직히 말하십시오. 선택지 중 하나는 거의 항상 "이 갈래를 멈추고 돌아가기"여야 합니다.
선택 방법
사용자의 두 번째 /huh가 빠르고 짧게 왔다면 1번을 가정하십시오. 대화가 길고 표류했다면 3번을 가정하십시오. 어느 쪽도 맞지 않으면 2번을 가정하십시오. 2번과 3번 사이에 확신이 서지 않으면 3번을 사용하십시오. 몇 단어가 더 들지만 더 안전한 수리 방법입니다.
사용자에게 세 가지 중 어떤 것인지 절대 묻지 마십시오. 그것은 사용자가 해결해야 할 또 하나의 일이며, 일을 해결하는 것이 바로 문제입니다.
사용자가 답변한 후
작업으로 돌아가십시오. 사용자가 더 많은 세부 사항을 원한다는 신호를 보낼 때까지 나머지 대화에서 평이한 언어를 유지하십시오.