HunkBB/학술 글쓰기 휴머나이저

학술 글쓰기 휴머나이저은(는) 무엇을 하나요?

작성자가 설명하고 뒷받침할 수 있는 구체적이고 읽기 쉬운 연구 글쓰기를 생성하세요. 기본적으로 모듈 A–I를 사용하고 작업에 따라 깊이를 조절하세요. 의미, 사실, 기술적 정확성, 실제 저자 기여를 보존하세요. 충실도, 가독성, 적절한 등록을 별도로 평가하세요. 한 영역의 개선이 다른 영역의 개선을 의미하지 않습니다.

초안 작성 또는 편집 전 등록 설정하기

• 공식 제안서, 정책 보고서 및 기타 학술 문서의 경우 기본적으로 형식적이고 분석적이며 정확하고 절제된 산문을 사용하세요. 논리를 전개하고, 확립된 분야 용어를 사용하며, 유용한 문장 복잡성을 유지하세요. 연락 이메일의 경우 전문적인 직설법과 적절한 개인 호칭을 사용하세요. 이메일과 첨부된 제안서를 구분하세요. 수신자가 교수라고 해서 모든 문서가 대화체가 되는 것은 아닙니다.
• intake-and-voice.md의 명시적 선호도를 적용하세요. 이 판은 새로 작성되는 공식 학술 산문(부정 및 축약형 포함)에서 avoid_would_will: true를 기본값으로 사용합니다. 이는 프로젝트 스타일 선호도이지 보편적인 학술 금지 사항이 아닙니다. 정확한 목적, 제안된 설계 또는 조건 구문을 사용하여 다시 쓰고 불확실성과 제안/완료 상태를 보존하세요. 정확한 인용문, 제목 및 참고 문헌 텍스트는 보호하세요. 이 선호도를 모든 조동사로 확장하거나 조동사를 현재형으로 기계적으로 대체하지 마세요. 사용자의 명시적인 작업별 선호도가 이 기본값을 무시할 수 있습니다.
• 사실 및 의미 충실도를 제약 조건으로 취급하세요. 명시적 작업/기관 요구 사항, 확인된 사용자 선호도, 장르, 그다음 일반 편집 제안을 사용하여 스타일 선택을 해결하세요. Wikipedia 관찰이 이를 무시하지 않습니다. 요구 사항이 실제로 충돌하는 경우 의미를 조용히 삭제하지 말고 구체적인 충돌을 표면화하세요.
• 편집에서 이미 요청된 등록과 목적을 충족하는 구절은 보존하세요. 초안 작성에서는 작문하기 전에 등록을 설정하세요. 먼저 대화체 초안을 만든 다음 학술 어휘로 장식하지 마세요.

입력 설정하기

1. 청중, 장르, 대상 프로그램/교수, 언어, 분량, 마감일, 출력 형식 및 원고 초안을 식별하세요. 등록, 독자 전문성 및 확인된 언어 선호도를 기록하세요. 연락 이메일, 관심 연구 노트, 공식 지원서 및 프로토콜을 구분하세요.
2. 제공된 이력서, 출처 및 실제 저자 샘플을 읽으세요. intake-and-voice.md와 intake-template.md를 사용하여 사실, 출처, 충돌 및 음성 상태를 기록하세요. 이력서에 보고된 사실과 독립적으로 확인된 사실을 구분하세요.
3. 가능한 경우 정확한 프로그램/자료 요구 사항을 확인하세요. process-and-review.md를 참조하세요. 학과 정책에서 국가 규칙을 추론하지 마세요. 알 수 없는 정책은 알 수 없음을 의미합니다.
4. 중요하지 않은 공백에도 불구하고 유용한 작업을 계속하세요. 답변이 제안서에 실질적으로 영향을 미치는 경우에만 한 묶음의 자료 질문을 하세요. 진정한 산문 샘플이 없으면 기록된 장르/등록 선호도를 따르고 음성 보정이 불완전하다고 표시하세요. 확인된 선호도는 개인 음성을 인증하지 않습니다. 대안을 제안하거나 작성자 결정을 표시하고 발명하지 마세요.

아홉 가지 모듈 모두 적용하기

모듈	작업	완료 증거
A — 음성	실제 저자 샘플에서 지원되는 경향을 일치시키고 장르에 맞게 조정하세요.	샘플 출처 및 관찰된 선호도, 또는 명시적인 미보정 상태.
B — 배경	경험, 기술, 결과 및 접근 권한 주장을 조정하세요.	해결되지 않은 충돌을 제외하거나 플래그 지정한 사실 장부.
C — 질문	질문, 메커니즘, 모집단 및 적절한 기여를 명시하세요.	답변 가능한 질문 및 문헌에 기반한 기여.
D — 방법	데이터, 단위, 측정, 설계, 가정 및 한계를 정렬하세요.	실행 가능성 확인 및 기술/인과 구분.
E — 적합성	연구자의 관련 1차 작업을 읽고 실제 설계 선택과 연결하세요.	발명된 관계나 가용성 없이 구체적인 연결.
F — 언어	완전한 맥락 스타일 검사와 기록된 등록을 사용하여 약한 구절을 수정하세요.	명확한 논증, 적절한 학술 어휘 및 안정적인 등록, 보호된 의미 유지, 효과적인 구절 유지.
G — 출처	각 핵심 주장에 대한 출처 신원과 뒷받침을 확인하세요.	접근 수준과 한계가 포함된 주장-출처 장부.
H — 결정	실제 입력, 결정, 수정 및 AI 역할을 보존하세요.	실제 변경 기록, 작성자 결정 및 적절한 공개.
I — 검토	가능하면 독립적으로 검토하고 연구 질문을 제기하세요.	증거 기반 비판과 작성자가 답변해야 할 질문.

세 번의 패스로 초안 작성 및 수정하기

패스 1: 연구 내용

B, C, D, E 및 G에 대해 research-checks.md를 읽으세요.

• 새 글쓰기의 경우 명시적 가정과 함께 집중된 작업 질문을 공식화한 다음 장부에서 초안을 작성하세요. AI가 제안한 주제는 제안된 것으로 표시하고 확립된 개인적 동기로 표시하지 마세요.
• 기존 초안의 경우 사본을 보존하고 언어 편집과 실질적 변경을 구분하세요. 방법/범위가 변경되어야 하는 경우 이유를 설명하고 작성자 검토 필요를 표시하세요. 작성자의 프로젝트를 조용히 대체하지 마세요.
• 문헌 공백을 주장하기 전에 출처를 확인하세요. 인용, 데이터 접근, 표본 크기, 효과, 협업 또는 경험을 절대 발명하지 마세요. 실제 DOI가 주장에 대한 뒷받침을 확립하지 않습니다.
• 기술 목록보다 실행 가능한 핵심 연구를 선호하세요. 사용할 수 없는 데이터에 대한 사용 가능한 대비책을 제공하세요. 제안된 연구 선택은 작성자 확인을 보류 중으로 표시하세요.
• 검색이 불가능할 때 제공된 증거를 사용하고 확인 한계를 명시하세요. 수행되지 않은 검색을 수행된 것으로 설명하지 마세요.

패스 2: 표현

language-editing.md, rewrite-examples.md 및 wikipedia-coverage.md를 읽으세요. 적용 범위 참조에는 날짜가 있는 Wikipedia 출처의 모든 실질적 제목과 스타일/마크업 페이지가 포함되며 범위별 작업이 포함됩니다. 이는 분류기가 아닌 편집 리소스입니다.

1. 의미 장부를 고정하세요: 사실, 숫자, 행위자, 작업/접근 상태, 기술적 정의, 추론 강도, 인용 및 연구 결정. 이를 보존하거나 실질적 변경을 명시적으로 기록하세요.
2. 각 적용 가능한 적용 범위 행에 대해 수정, 이유 있음 유지 또는 존재하지 않음을 기록하세요. 컨텍스트별 행에는 해당 없음을 사용하세요. 상위 행을 라우팅 검사로 취급하세요. 반복된 발견을 통합하세요. 역사적/비효율적 지표 행을 안전장치로 읽고 삭제 지침으로 읽지 마세요. 전체 감사를 위해 처리 장부를 사이드카로 유지하고 사용자에게 의미 있는 변경 사항만 제시하세요.
3. 논증, 공식 구조 또는 등록을 수리해야 하는 구절에는 단락 다시 쓰기를 사용하세요. 필요한 명제를 단락의 분석적 목적에 맞게 구성하고 증거, 해석 및 자격을 연결하세요. 질문 시작이나 개인 행동 서술을 강요하지 마세요. 구절이 이미 작동하는 경우(휴머나이즈 요청 포함) 가벼운 편집을 사용하거나 문구를 유지하세요.
4. 논증 흐름, 부풀려진/모호한 주장, 구문/문구, 등록, 어시스턴트 잔여물/형식 및 인용 위생에 대해 별도의 패스를 실행하세요. 제출 산문과 편집 노트를 분리하고 해석에 영향을 미치는 연구 한계는 텍스트에 유지하세요. 측정을 정확하게 정의하고 대상 독자 수준에서 익숙하지 않은 개념을 설명하세요. 모든 단락을 프로토콜 체크리스트나 평이한 설명으로 바꾸지 마세요.
5. 반복되는 시작, 균일한 단락 구조, 불필요한 요약, 어색한 귀인 및 밀도에 대해 전체 초안을 읽으세요. 기술적 반복, 유효한 대조, 불확실성, 기능적 복잡한 문장 및 저자가 지원하는 특성을 보존하세요. 기록된 어휘 선호도를 맥락적으로 확인하세요(회피가 활성화된 경우 would/will 포함). 각 예외를 검토하세요. 오류, 발명된 경험, 강제된 짧은 문장, 무작위 어휘 또는 구두점 규칙을 추가하지 마세요.
6. 의미 장부와 비교하세요. style-review.md를 사용하여 충실도, 독자 경험 및 등록을 별도로 검토하세요. 하나라도 실패하면 영향을 받는 구절을 수정하고 다시 검토하세요. 명확성을 손상시키거나 연구 상태를 변경하는 공식적인 문구를 수락하지 마세요. 남은 편집이 미용적인 경우 중단하고 해결되지 않은 문제를 보고하세요.

패스 3: 확인 및 검토

H 및 I에 대해 process-and-review.md를 읽으세요. review-template.md를 사용하세요.

1. 변경된 숫자, 사실, 인과 진술 및 귀인을 장부와 대조 확인하세요.
2. 실질적 변경을 전 → 후 → 이유로 설명하고 작성자 확인이 필요한 추가 사항을 식별하세요.
3. 가능하면 의도된 평결이나 편집 근거 없이 초안, 요구 사항, 사실 및 출처를 독립적인 에이전트에게 제공하세요. style-review.md를 사용하여 충실도, 가독성 및 등록을 별도로 평가하세요. 원시 검토와 불일치를 보존하세요. 그렇지 않으면 자체 검토로 표시하세요. A/B 비교의 경우 중립 레이블을 무작위화하고 비교 가능한 범위/길이를 사용하세요. 부록으로 이동된 내용을 공개하세요.
4. 기여, 데이터, 식별, 측정, 실행 가능성 및 동기에 대해 5–8개의 질문을 생성하세요. 생성된 답변이 사용자의 이해를 증명한다고 주장하지 마세요. 작성자가 응답할 때까지 이해는 테스트되지 않은 상태입니다.
5. 정당화된 수정을 적용하고 남은 문제를 명시하세요. 한 사례가 국가 전체, 교차 플랫폼 또는 탐지기 성능을 검증하지 않습니다.

유용할 때 로컬 헬퍼 사용하기

Python 3로 실행하고 이 디렉터리를 기준으로 스크립트를 확인하세요:

python3 scripts/review_text.py audit draft.md --output audit.json
python3 scripts/review_text.py diff before.md after.md --output changes.html
python3 scripts/style_audit.py draft.md --output style-audit.json

타사 종속성, 네트워크, API 키 또는 탐지기 계정이 필요하지 않습니다. 헬퍼는 기계적 후보와 시각적 diff를 보고합니다. style_audit.py는 제한된 로컬 사전 점검일 뿐 완전한 의미론적 Wikipedia 검토가 아닙니다. 해당 트리거는 편집 프롬프트이지 검증된 분류 임계값이 아닙니다. 개수를 객관적 목표로 최소화하지 마세요. 발견 사항을 수동으로 검사하고 합법적인 사용을 보존하세요. 스크립트는 참조를 확인하지 않으며, 연구 타당성을 평가하지 않으며, 진위를 추론하지 않으며, AI를 탐지하지 않습니다. 개수를 AI 백분율로 변환하지 마세요. 입력 파일을 보존하세요. 승인 없이 미발표 글쓰기를 제3자에게 보내지 마세요.

탐지기 상태 정확하게 보고하기

날짜가 있는 증거에 대해 evidence-and-detectors.md를 읽으세요.

• 글쓰기 품질 검토와 탐지기 측정을 분리하세요.
• 실제 실행 없이 보고하세요: "Turnitin: 테스트되지 않음. 해당 백분율을 추정할 수 없음." 다른 공급업체의 점수, 주관적인 백분율 또는 언어 모델 판단을 절대 대체하지 마세요.
• 진정한 보고서가 있는 경우 제품, 날짜, 제출된 버전/해시, 리터럴 결과, 의미 및 한계를 기록하세요. 이를 작성자의 실제 AI 기여로 표시하거나 합격을 보장하지 마세요.
• 절대 미탐지를 약속하거나 초안 기록, 보고서, 소급 날짜 또는 최소화된 AI 사용 진술을 조작하지 마세요.

전달하기

수정된 텍스트, 간결한 변경 사항 및 실질적인 작성자 결정을 반환하세요. 전체 제안서의 경우 출처 장부, A–I 검토, 스타일 처리, 탐지기 상태 및 토론 질문도 제공하세요. 대표적인 전/후 구절을 보여주고 독자 대상 개선 사항과 의도적으로 유지된 의미 있는 사례를 설명하세요. 검토 노트를 제출 산문과 분리하세요. 해결되지 않은 실질적 결정은 작업 초안으로 표시하고 제출 준비가 되지 않았음을 표시하세요. 개인 사실/샘플을 이 재사용 가능한 스킬 외부의 사용자 프로젝트에 보관하세요.

작업에 맞게 표시되는 편집 기록을 조정하세요. 짧은 구절의 경우 간결한 몇 가지 글머리 기호와 실질적인 해결되지 않은 문제를 사용하고 요청하지 않는 한 전체 제안서 검토 장치를 첨부하지 마세요. 유용할 때 상세한 감사 기록을 별도로 유지하세요.