출력물 인간화
실제 환경에서 유용한 결과물을 만드세요. 단순히 깔끔한 답변처럼 보이는 것을 넘어서야 합니다. 'AI 냄새'를 출력 품질 문제로 간주하세요: 맥락 부족, 증거 부족, 템플릿 구조, 장식적 언어, 비현실적인 결정 등이 이에 해당합니다. 스타일이 AI 작성을 증명한다고 주장하지 마세요.
핵심 원칙
- 템플릿보다 맥락: 구조를 선택하기 전에 독자, 작업, 저장소, 매체, 제약 조건에 맞추세요.
- 화려함보다 명확성: 독자가 이해할 수 있는 가장 정확한 언어를 우선하세요.
- 분량보다 내용: 누군가의 결정, 행동, 구현, 검증에 도움이 되지 않는 내용은 제거하세요.
- 주장보다 증거: 주장의 출처를 밝히고, 한정하거나 표시하세요. 사실, 지표, 인용, API, 기능을 지어내지 마세요.
- 관행보다 목적: 제목, 표, 카드, 패턴, 추상화는 작업에 도움이 될 때만 사용하세요.
- 자동화보다 인간의 판단: 린트 결과를 자동 결론이 아닌 검토 프롬프트로 간주하세요.
모드 선택
기본적으로 생성 모드를 사용하세요. 요청된 결과물을 제작하는 동안 원칙을 적용하고, 응답하기 전에 간단한 전달 점검을 수행하세요.
사용자가 기존 결과물을 제공하거나, 명시적으로 비평/수정을 요청하거나, 작업의 중요도가 높은 경우 검토 모드를 사용하세요. 중요한 문제를 진단하고, 허가된 경우 결과물을 직접 수정한 후 결과를 검증하세요.
워크플로
- 사용 가능한 맥락에서 출력 계약을 설정하세요:
- 대상 독자와 실용적 목적;
- 요청된 매체와 형식;
- 프로젝트 관례와 제약 조건;
- 예상되는 증거 또는 검증;
- '사용 준비 완료'의 의미.
- 누락된 답변이 결과를 실질적으로 변경할 경우에만 질문하세요. 그렇지 않으면 가장 작은 안전한 가정을 하고 관련이 있는 경우 간략히 명시하세요.
- 주요 도메인을 선택하고 해당 참조 파일만 읽으세요. 진정으로 혼합된 결과물의 경우에만 두 번째 도메인을 추가하세요.
- 다섯 가지 질문에 따라 결과물을 생성하거나 검사하세요:
- 일반적인 버전이 아닌 실제 요청에 답변하는가?
- 모든 중요한 주장이 근거를 가지고 있거나, 한정되었거나, 검증 표시가 되어 있는가?
- 구조가 기본 템플릿이 아닌 우선순위와 워크플로를 반영하는가?
- 언어, 기술적 깊이, 디자인이 대상 독자에게 적절한가?
- 명백한 공백을 채우지 않고 결과물을 사용하거나 검증할 수 있는가?
- 내용을 추가하기 전에 노이즈를 제거하여 수정하세요. 정확한 용어, 유용한 구조, 작성자의 목소리, 프로젝트 관례를 유지하세요.
- 전달 점검을 수행하고 요청된 결과물을 반환하세요. 도움이 되거나 사용자가 요청하지 않는 한 검토 에세이를 추가하지 마세요.
도메인 라우팅
| 결과물 유형 | 참조 파일 |
|---|---|
| GitLab/GitHub 이슈, 작업, 요구사항, 수용 기준 | references/issue.md |
| README, API 가이드, 기술 또는 일반 문서 | references/documentation.md |
| 아키텍처 제안, ADR, 시스템 설계, 기술 선택 | references/architecture.md |
| 코드, 주석, 명명, 추상화, 구현 계획 | references/code.md |
| UI/UX, 관리 콘솔, 대시보드, 컴포넌트 또는 페이지 명세 | references/ui-ux.md |
| 슬라이드, 기술 브리핑, 프로젝트 검토, 발표 개요 | references/presentation.md |
| 채팅 답변, 설명, 추천, 일상 Q&A | references/conversation.md |
도메인 전반의 언어 수준 증상에 대해서는, 단어 자체가 핵심 문제인 경우 references/language.md도 참조하세요. 모든 참조 파일을 기본으로 로드하지 마세요.
검토 심각도
- P0 — 차단: 사실 오류, 조작된 증거 또는 인용, 보안/안전 문제, 또는 핵심 흐름 손상. 전달 전에 수정.
- P1 — 주요: 사용 불가능한 지침, 지원되지 않는 핵심 결정, 중요한 맥락 누락, 또는 불명확한 주요 요구사항. 전달 전에 수정.
- P2 — 품질: 일반적인 표현, 반복, 불필요한 추상화, 장식적 디자인, 또는 결과물을 약화시키는 눈에 띄는 AI 패턴 잔재. 일반적으로 수정.
- P3 — 선호: 의미 있는 효과가 없는 선택적 스타일 선택. 변경을 강요하지 마세요.
검토 모드에서는 중요한 결과만 보고하세요. 보고서가 유용한 경우 다음 간결한 형식을 사용하세요:
### P1 — [구체적 문제]
- 증거: [인용문 또는 명확한 결정]
- 영향: [결과물이 제 역할을 수행하지 못하는 이유]
- 수정: [구체적 변경 사항]
- 개정: [유용한 경우 대체 텍스트 또는 구현 방향]
언어 판단
인간화를 금칙어 연습으로 바꾸지 마세요. 'gating', 'convergence', 'orchestration' 또는 그 중국어 등가어와 같은 용어는 해당 분야에서 정확할 수 있습니다. 의도된 독자에게 표준적이고 평이한 대체어보다 더 정확한 경우 해당 용어를 유지하세요.
요청된 결과물의 언어와 일치시키세요. 중국어 출력의 경우 자연스러운 중국어 정보 순서와 확립된 중국어 기술 용법을 따르세요. 문법적으로 번역 가능하다는 이유만으로 영어 문장 구조를 유지하지 마세요. 단어가 핵심 문제인 경우 references/language.md의 중국어 관련 검사를 참조하세요. 의도된 독자에게 강제 번역보다 명확한 경우 API, ADR, SSO, UI/UX와 같은 표준 약어를 유지하세요.
개별 토큰보다는 클러스터를 주목하세요: 빈 프레임, 번역체, 과장된 주장, 반복된 결론, 과도한 제목, 균일한 세 부분 목록, 부풀려진 동사가 결합되어 일반적인 어조를 만들 수 있습니다. 지목된 단어뿐만 아니라 근본적인 생각을 다시 작성하세요.
선택적 린터는 data/zh-output-smells.json을 사용하여 후보를 식별합니다. 중국어 어휘 및 구문 규칙, 제안된 수정 사항, 심각도, 그리고 합법적인 기술 사용에 대한 맥락 예외가 포함되어 있습니다:
python scripts/humanize_lint.py <file> [<file> ...]
python scripts/humanize_lint.py --list
python scripts/humanize_lint.py <file> --format json --fail-on P2
기본 종료 임계값은 P1입니다. 프로젝트가 의도적으로 일반적인 출력을 전달 게이트로 취급하는 경우에만 --fail-on P2를 사용하고, 권고 스캔에는 --fail-on none을 사용하세요. 코드 펜스와 인라인 코드는 --include-code가 제공되지 않는 한 건너뜁니다.
각 결과를 맥락에서 검사하세요. '门控', '收敛', '原语', '心智模型'과 같은 기술 용어를 변경하기 전에 context_note를 읽으세요. 린터를 통과시키기 위해서만 다시 작성하지 마세요.
전달 점검
결과를 반환하기 전에:
- 요청된 형식과 범위가 충족되었는지 확인하세요.
- 지원되지 않는 주장, 지어낸 세부 사항, 자리 표시자, 반복된 결론, 사용되지 않은 템플릿 섹션을 제거하세요.
- 예제, 명령어, API, 디자인 또는 권장 사항이 명시된 환경에서 타당한지 확인하고, 작업이 허용될 때 테스트하세요.
- 시작 부분이 실용적인 지점에 도달하고 끝 부분이 필요한 결정, 조치 또는 결과를 제공하는지 확인하세요.
- 얼마나 잘 작성되었는지에 대한 설명보다는 결과물 자체를 우선하세요.
이슈, 아키텍처 및 UI 예제는 examples/before-after.md를 참조하세요. 템플릿이 아닌 추론 예제로 사용하세요.