Community라이팅 & 에디팅github.com

Gyanesh5/plain-zh

평범한 중국어 출력 규범. 두 가지 용도: 글쓰기 전 형태 잡기(사전 예방), 완성 후 검토 및 수정(사후 정리). 용어 규율, 독자 보정, 구조 신호, 문체 경계의 네 가지 계층을 다루며, 규칙은 증거 강도에 따라 등급을 표시합니다. 중국어 기술 문서 작성, 교육 강의, AI 어시스턴트 응답 생성 및 검토에 적합합니다.

plain-zh란 무엇인가요?

**Gyanesh5/plain-zh**는 사람이 읽기 좋은 중국어 출력을 위한 AI 에이전트 스킬입니다. 이 스킬의 핵심은 '정의 후 사용', '하나의 개념에 하나의 용어', '제목에 비유 금지', '평범한 구조'라는 네 가지 원칙에 기반하여 중국어 기술 문서, 교육 콘텐츠, AI 응답을 생성할 때 더 명확하고 간결하며 인간 친화적인 스타일을 유지하도록 돕습니다. `SKILL.md` 파일에는 용어 규율, 독자 보정, 구조 신호, 문체 경계, 수정 규율의 다섯 가지 주요 섹션(총 22개의 세부 규칙)이 포함되어 있으며, 각 규칙은 '실측', '인지', '공학', '약정'의 네 가지 증거 등급으로 표시되어 실용성과 신뢰성을 보장합니다. 이 스킬은 일반 Claude Code, Cursor, Codex 등 AI 에이전트 플랫폼에서 사용 가능하며, '생성 모드'와 '검토 모드' 두 가지로 작동합니다. 생성 모드는 글을 쓰기 전에 적용하여 사전에 문체를 제어하고, 검토 모드는 완성된 텍스트에 대해 단계별 보고서를 생성하고 승인 후 수정합니다. '프로젝트 용어집 메커니즘'을 지원하여 사용자 명령, 프로젝트 용어집, 스킬 기본값 간의 우선순위를 명확히 정의하고, `mattpocock` 스킬 등 타사 워크플로우와 호환되도록 설계되었습니다. `plain-zh`는 단순한 문법 검사기를 넘어, AI 출력의 일반적인 문제(예: 동의어 남용, 불필요한 경고성 어조, 구조적 혼란 등)를 타겟팅하여 사람의 인지 부담을 줄이고 가독성을 높이는 데 중점을 둡니다.

지원 대상✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/Gyanesh5/plain-zh/tree/HEAD

Installed? Explore more 라이팅 & 에디팅 skills: steipete/notion, langchain-ai/langchain, bytedance/podcast-generation · View all 6 →

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

이 에이전트 스킬이 미리 로드된 새 채팅을 엽니다.

문서

plain-zh 평범한 중국어

사람이 읽는 중국어: 용어는 정의한 후 사용하며, 하나의 개념에는 하나의 이름만 사용하고, 비유는 제목에 넣지 않으며, 구조는 평범하게 유지합니다.

각 규칙 끝에 증거 등급을 표시합니다:

  • 〔실측〕 lieflat-less-ai-tone의 270쌍 동일 주제/동일 사실 대조 말뭉치, 두 차례 동일 방향
  • 〔인지〕 인지 과학 근거 (Pinker의 저주, Cowan의 작업 기억 용량)
  • 〔공학〕 성숙한 공학 관행 (ASD-STE100 제어된 글쓰기, 중국어 문서 배열 가이드)
  • 〔약정〕 본 프로젝트 설계 약정, 실험 증거 없음, 필요에 따라 조정 가능

두 가지 모드

생성 모드 (글쓰기 전 로드): 글을 쓰기 전에 독자와 용어집을 결정하고, 작성 후 P1-P7로 자체 점검합니다. POLICY.md는 이 모드의 8줄 요약 버전으로, AGENTS.md / CLAUDE.md / SOUL.md에 포함하여 상주시키기에 적합합니다.

검토 모드 (완성된 원고에 대해 작업): '검토 모드 워크플로'에 따라 보고서를 작성하고, 확인을 기다린 후 수정합니다.

프로젝트 용어집 메커니즘

생성과 검토 모두 먼저 프로젝트 용어 원천을 확인한 후 작업을 시작합니다:

  1. 용어 원천 우선순위: 사용자의 현재 명령어 > 프로젝트 용어집 (CONTEXT.md, GLOSSARY.md, 용어 대조표) > 본 규범 기본값. 프로젝트에서 이미 정한 용어는 그대로 사용하며, 본 규범에 따라 기존 용어를 다시 쓰지 않습니다.
  2. 타사 워크플로와의 공존: 프로젝트가 mattpocock 유형의 스킬 (wayfinder, to-spec 등)을 실행할 때, 해당 CONTEXT.md의 용어, 명령어 및 은유어 (wayfinder=작업 지도, grill=질의 판정, to-tickets=구현 티켓 분해, 도착=목표 달성, 안개 진입=보류/미정)도 함께 프로젝트 약정으로 소비합니다. 인터페이스 용어는 P3에 따라 이중 트랙으로 처리합니다.
  3. 점진적 관리: 기존 문서는 다시 작성하지 않으며, 의사 결정 파일의 증거 체인이 우선합니다. 프로젝트에 용어집이 없고 한 번의 검토에서 3개 이상의 미대조 용어가 발견되면, 보고서 끝에 용어 대조표 추가를 권장하며, 이후 새 문서는 대조표를 따릅니다.

R1 용어 규율

P1 먼저 정의하고 사용하기 〔인지〕

모든 용어, 약어, 파일명, 필드명, 도구명은 처음 등장하기 전에 반드시 정의하거나 중영 대조를 제시해야 하며, 갑자기 등장할 수 없습니다. 판단 방법: 독자가 이전에 이 단어를 본 적이 있는가? 본 적이 없다면, 한 문장으로 그것이 무엇인지 설명해야 합니다.

  • 수정 전: build_assets.py 돌리면 돼
  • 수정 후: 먼저 저장소에 있는 리소스 패키징 스크립트 build_assets.py로 패키징한 다음 실행 (동격어로 직접 쓰고, 괄호를 추가하지 않음; 괄호가 정말 필요한 경우 P18 참고)

보존: 본문 위에서 이미 정의된 단어; 대상 독자의 상식에 속하는 단어.

P2 동일 개념에 동일 용어 〔실측〕

하나의 개념은 처음부터 끝까지 하나의 이름을 사용합니다. 동의어를 번갈아 사용하지 않고, 중간에 새로운 표현을 만들지 않습니다.

증거: 동의어 재명명 AI 0.83-0.86회/문단, 인간 0.49회; 한 문단 내 2회 이상 등장하는 문단의 비율, AI 20.6-22.5%, 인간 8.4%.

  • 수정 전: 같은 문단에서 '최적화/향상/개선'을 번갈아 사용하여 같은 것을 말함
  • 수정 후: 전체 글에서 '최적화'로 통일

보존: 문학적 지칭 변화; 공식적으로 용어를 도입할 때의 '일명 X'.

P3 용어 첫 등장 시 대조, 자체 번역어 금지 〔공학〕

통용되는 번역어가 있으면 통용 번역어를 사용; 없으면 첫 등장 시 '중국어(English)'로 쓰고, 이후 본문에서는 중국어를 사용. 자체 제작한 은어식 번역어 및 통계 은어를 금지합니다.

  • 수정 전: '템플릿 chrome 오종 세트', '최빈값 회귀', '이치수'
  • 수정 후: '템플릿화된 인터페이스 요소(chrome): 제목줄, 메타 정보 문자열, 대시 태그', '평균으로의 회귀'

보존: 업계 고정 영어 (API, CI/CD); 팀이 원문을 유지하기로 약정한 단어 (프로젝트 용어집 참고).

인터페이스 용어 이중 트랙: 슬래시 명령어, 레이블 (Label, Status, Type), 설정 키는 에이전트의 호출 인터페이스이므로 원문을 유지하고 번역하지 않음; 단, 인간 본문에 들어갈 때는 첫 등장 시 대조 제공.

  • 수정 전: '05번 티켓 grill 시 먼저 사용자와 확인'
  • 수정 후: '05번 티켓 grill(질의 판정) 시 먼저 사용자와 확인'

기계 메타데이터 줄 (Label, Status, Blocked by 등)은 파일 헤더 메타데이터 영역에 집중 배치하며, 본문에 흩어지지 않도록 함; 문단 제목은 중국어 또는 중영 이중 언어 병기, 전체 문단을 영어 제목으로 유지하지 않음.

P4 비유 할당량 〔약정〕

각 개념에 최대 하나의 비유만 사용하며, 비유는 설명이 필요한 곳에만 등장하고, 제목에 들어가거나 용어로 반복 사용되지 않습니다. 모델은 비유의 적절성을 판단할 수 없으며 (모델 간 합의 0-40%), 사후 필터링이 신뢰할 수 없으므로 원천에서 제한합니다.

  • 수정 전: 제목 '1. 출신과 그것이 해결하려는 문제'; '세 개의 기둥 / 기둥 하나 / 기둥 둘'을 장(chapter) 프레임워크로 사용
  • 수정 후: 제목 '1. 출처: 이것이 해결하는 문제'; '세 가지 원칙 / 원칙 하나'

보존: 사용자가 명시적으로 요청한 스타일; 교육 장면에서 효과가 확인된 비유 (개념당 하나로 제한).

R2 독자 보정

P5 독자와 사전 지식 목록 〔인지〕

글을 쓰기 전에 먼저 두 가지를 결정: 누구를 위해 쓰는지, 무엇을 기본적으로 알고 있다고 가정하는지. 글은 독자가 이미 구축한 개념만 참조합니다. 지식의 저주 (curse of knowledge): 저자가 아는 것을 독자가 반드시 아는 것은 아니며, 저자는 이 격차를 가장 간과하기 쉽습니다.

P6 미정의 약어 할당량 〔인지〕

100자당 최대 1개의 미전개 약어. 작업 기억은 한 번에 약 4개의 미지 항목을 보유하므로, 연속 약어는 독자로 하여금 '멈추고 의문을 갖게' 합니다. 할당량을 초과하면 먼저 전개하거나 삭제합니다.

P7 교차 도메인 개념에 유추 제공 〔인지〕

독자의 도메인 밖 개념을 도입할 때는, 독자 도메인 내 유추와 유추의 실패 경계를 함께 제시합니다. 유추는 입문을 담당하고, 경계는 정보 왜곡을 방지합니다.

  • 예시: '레지스터는 주차 공간과 같습니다. 각 공간에는 하나의 값만 넣습니다. 하지만 레지스터에는 '꽉 찼다'는 개념이 없으며, 쓰면 덮어씁니다.'

R3 구조 신호

증거 강도 순으로 정렬. 지적은 죄가 아니라 힌트입니다; 각 경우마다 문맥으로 돌아가 성립 여부를 판단합니다.

P8 반전 투 〔실측 3.4배〕

'X가 아니라 Y다', '당신은 X라고 생각하지만, 실은...', '겉으로는... 실은...', '차라리 X라고 하기보다는 Y라고 하는 것이 낫다'. 대부분의 경우 직접 판단을 내립니다.

  • 수정 전: '모델이 베끼는 것이 아니라, 평균으로 회귀하는 것입니다'
  • 수정 후: '모델은 누군가를 표절하는 것이 아니라, 통계적으로 가장 흔한 작문을 출력하는 것입니다'

보존: 실제 오해를 바로잡는 경우 ('오류는 저장 단계에서 발생하는 것이지, 업로드 단계에서 발생하는 것이 아닙니다').

P9 힌트어 콜론 〔실측 3.8배〕

'한 마디로 요약:', '핵심은:', '핵심은 다음과 같습니다:', '이유는 다음과 같습니다:'. 힌트어가 정보를 담고 있지 않으면 삭제하고, 직접 결론을 씁니다; 앞부분이 실제로 위 문장을 받는 경우에는 콜론을 마침표로만 바꿉니다.

P10 연결 고리 〔실측: AI 중위 7연결, 인간 2〕

문단 시작은 이전 문단의 마지막 문장 핵심어를 받아, 전체 글에서 점프가 없습니다. 연결 고리 중 1-2곳에 자연스러운 점프를 남겨 독자가 추론에 참여하게 합니다.

보존: 튜토리얼, 법률 문서 등 긴밀한 연결이 필요한 문체.

P11 동형 삼연 〔실측: AI 29.4%, 인간 10.7%〕

연속 세 문장이 동일한 문법 골격을 공유 (동일한 시작 구조, 동일한 종결 리듬). 그 중 하나를 분리: 병합, 분할 또는 어순 변경, 내용을 삭제하지 않음.

보존: 의도적 수사 (연설, 격문); 목록체; 서사 진행의 세 가지 사건.

P12 번역체 4가지 구조 〔실측〕

네 가지만 처리: 너무 긴 전치 수식어 (중심어 앞 수식어가 15자 초과, 또는 연속 두 개의 '의'); '~할 때...' 전치 종속절; '~에 관해서는', '~에 있어서는' 등의 화제 껍질; 인접 문단의 첫 부분에서 연속으로 '그러나, / 따라서, / 또한,'를 이정표로 사용. 분해할 수 있으면 분해하고, 실제로 시간이나 논리 기능을 수행하는 경우 보존.

P13 열거와 압축 밀도 〔실측: 모점 열거 AI 3.21 vs 인간 1.78회/천자, 대조 재측정密集 병렬 AI 1.45배, 두 차례 동일 방향〕

하나의 절(clause)에서 병렬 항목은 3개를 초과할 수 없음; 초과 시 목록으로 펼치거나, 요약 후 출처 링크 제공. 숫자 집합 단어 금지 - '모니터링 4종 세트', '비교 6종 세트', 'diff 3종 세트' 등은 항목별로 명시하거나, 첫 등장 시 정의를 펼친 후 약어 사용. 슬래시 열거도 동일 판정.

  • 수정 전: 'M7은 페이지 재작업/매개변수 중요도/나쁜 라운드 조기 중단/모니터링 4종/Retry/양식 포함'
  • 수정 후: 'M7은 6개 항목 포함: Agent 페이지 재작업, 매개변수 중요도 분석, 나쁜 라운드 조기 중단, 4가지 모니터링 (GPU 곡선, 시간 예상, 데스크탑 알림, loss 이중선), 원클릭 Retry, 양식 개선'

보존: 명령줄 매개변수, 오류 코드표, 목록체 문서의 본래 열거; 모점 3항 병렬은 정상적인 작성법 (X급 교훈: 문장 내 병렬은 인간도 자주 사용), 4항 이상이고 구조가 동형일 때만 처리.

P14 단어표 가중치 하향 〔실측: 차이 유의미하지 않음〕

'역량 강화, 그립, 클로저, 심화, 침전' 등 단어표에 적중하더라도 낮은 가중치 힌트만 제공하며, 단독으로 수정 사유가 되지 않음. 구조 신호 (P8-P12)가 단어표보다 우선합니다.

X급 (절대 수정 안 함): 다음 특징은 대조 재측정 결과 구분력이 없거나 방향이 반대이므로, 감지하더라도 수정하지 않음 - 서수사 소제목, '이는 ~을 의미합니다' 식의 재진술, 빈 회전문 목록 도입, '먼저/다음으로/요약하자면', 의문문, 문장 길이 균일화 개선, 정확한 숫자 나열.

R4 문체 경계

P15 극적 프레임은 명시적 요구 필요 〔약정〕

교실 페르소나 ('교구 배부 완료', '강의 시작', '표본관'), 연극 내레이션, 인터뷰 프레임, 서스펜스 예고 ('잠깐만 —')는 사용자가 명시적으로 요청할 때만 활성화. 기본값은 평이하게 서술.

P16 금구 할당량 〔약정〕

격언식 요약은 글당 최대 1곳. '한 마디로 가져간다' 식의 마무리 예고 금지.

P17 중영 혼합 배열 〔공학〕

중국어와 영어 사이에 공백 추가; 중국어 문맥에서는 전각 문장 부호 사용; 숫자와 단위 사이에 공백 추가. 세부 사항은 중국어 문서 배열 가이드 (sparanoid/chinese-copywriting-guidelines)를 따릅니다.

P18 문장 부호와 괄호 〔공학: GB/T 15834—2011, CY/T 154—2017〕

주석 작성법 우선순위: 동격어 직접 쓰기 > 괄호 > 대시. 동격어로 쓸 수 있는 주석은 괄호를 사용하지 않음; 괄호는 '본문과 이어 읽지 않아도 되는' 각주에 사용; 대시 주석은 본문에 속하며 이어 읽어야 하므로, 중국어 기술 문서에서는 드물게 사용 (고밀도 대시는 실측에서 AI 작문 지문으로 확인됨).

  • 동격어 (선호): 먼저 저장소에 있는 리소스 패키징 스크립트 build_assets.py로 패키징한 다음 실행
  • 괄호 (각주): 일괄 내보내기 지원 (관리자 권한 필요)
  • 대시 (연결 주석, 드물게 사용): 정말 필요하면 두 글자 선 —을 사용하며, 두 글자 공간을 차지하고 끊어지지 않으며, 앞에 보통 문장 부호를 붙이지 않음

괄호 전각/반각은 내용과 인접 환경에 따라 판정하며, 전체 글에서 체계를 통일 (CY/T 154의 일관성 원칙):

상황형태예시
쌍으로 번역 '중국어(English)'전각, 앞뒤 공백 없음메시지 큐(Message Queue)
중국어 포함 주석전각, 앞뒤 공백 없음일괄 내보내기 지원 (관리자 권한 필요)
순수 영어, 숫자, 버전 번호 인용반각, 괄호 전 공백Spring Boot (v3.2.0) 기반 개발
괄호가 코드나 파일명에 인접반각, 양쪽 공백build.sh 실행 (처음 실행 시 의존성 다운로드) 후 재시작

알려진 차이: 출판 관례에서는 '중국어(English)'에 전각 사용 (GB/T 15834, 가이드 예시); 일부 공학 규범은 순수 영어 내용에 대해 반각 + 공백을 일관되게 사용 (Gengo). plain-zh 기본값은 전각 대조, 반각 공학 인용; 프로젝트에 자체 약정이 있으면 약정을 따르며, 전체 글에서 전환하지 않음.

기타 하드 규칙:

  • 괄호는 중첩 사용 금지; 반드시 중첩이 필요하면 안팎으로 다른 형태 사용 (밖〔〕 안())
  • 문장 내 괄호는 주석이 붙은 단어 바로 뒤에 위치하며, 끝에 마침표를 붙이지 않음; 문장 외 괄호는 문장 끝 구두점 뒤에 위치
  • 따옴표: 간체 기본 "", 중첩 ''; 직각 따옴표 「」 『』는 번체 또는 프로젝트 약정으로 「」를 사용하는 상황에 사용하며, 전체 글 통일
  • 생략 부호는 …… 사용, 세 개의 마침표 사용 금지
  • 중국어 문장 내 영어 병렬 항목은 여전히 모점 사용 (예: at the bus stop、at the railway station)
  • 괄호 주석은 문단당 2곳을 초과할 수 없으며, 연속 각주는 본문으로 펼쳐서 작성

보존: 코드 블록 및 명령줄 내 반각 괄호; 수학 공식 괄호; 표 내 간결한 괄호; 프로젝트 기존 배열 약정.

R5 수정 규율 (검토 모드 적용)

P19 최소 변경

한 곳의 지적은 해당 문제를 해결하는 데 필요한 부분만 수정하고, 덤으로 다듬지 않으며, 인접한 글자를 건드리지 않음. 많이 수정할수록 새로운 오류가 발생할 가능성이 높아짐. 확신이 없으면 원문 유지.

P20 정보 보존

사실, 숫자, 한정어, 귀인, 부정 범위를 완전히 보존. '아마'를 '확실히'로 바꾸지 않고, '계획'을 '완료됨'으로 바꾸지 않음. 수정으로 추가된 모든 실질 단어는 원문에서 출처를 제시할 수 있어야 함.

P21 구조 유지

제목 수준, 장(chapter) 순서, 문단 순서, 목록/표/참조/코드 블록의 위치를 원래대로 유지. 제목을 수정하기 전에 전체 글의 참조와 앵커를 확인.

P22 수정 후 자체 점검

항목별 점검: 새로 추가된 실질 단어에 출처가 있는가? 모든 용어가 첫 등장 시 정의되었는가 (P1-P3)? 인터페이스 용어가 대조되었는가 (P3)? 제목에 비유가 없는가 (P4)? 미정의 약어 할당량을 충족하는가 (P6)? 반전 투와 힌트어 콜론이 처리되었거나 보존 이유가 명시되었는가 (P8-P9)? 열거와 압축 밀도가 적절하고 숫자 집합 단어가 없는가 (P13)? 문장 부호와 괄호가 규정을 준수하고 동격어가 우선 사용되었는가 (P18)? 극적 프레임이 활성화되지 않았거나 사용자가 요청한 것인가 (P15)?

세 가지 수준의 판단 분담

  • 셀 수 있는 지표 (약어 개수, 비유 밀도, 동어 교체, 대시 밀도): 스크립트화 가능, 본 프로젝트는 detect 인터페이스 예약
  • 문장 의미 판단 (지적 성립 여부, 보존 경계 적용 가능 여부): 모델이 본 파일의 폐쇄적 판단 기준에 따라 항목별로 판단, 확신 없으면 '확인 필요' 표시
  • 비유 적절성: 후보만 나열하고 사용자가 판단하며, 모델은 평가하지 않음

검토 모드 워크플로

  1. 전체 글을 읽고, 문체와 독자를 판단하며, 보존해야 할 주장, 데이터 및 한정어 목록 작성
  2. P1-P18에 따라 항목별로 검사. 각 지적은 다음 기록: 규칙 번호, 원문 위치, 수정 방법, 판정 (수정 예정 / 보존 / 오탐지 / 확인 필요). 보존에는 구체적인 이유를 제시해야 하며, '읽기에 자연스럽다'는 설명만으로는 부족
  3. 보고서 작성: R1-R4별로 지적 그룹화 (원문, 수정 방법, 판정), 통계 분류 (용어 유형 / 구조 유형 / 문체 유형). 사용자에게 전체 제안 세트에 대해 '제안대로 수정' 또는 조정 요청만 요청하고, 항목별 결정을 요구하지 않음
  4. 확인 수신 후 수정, P19-P21 준수. 각 수정 사항은 '원문, 수정 후, 적중 규칙 번호' 기록
  5. 수정 후 P22에 따라 자체 점검, 수정 전후 대조 출력 (수정 부분에 삭제선 및 삽입 표시), 수정 예정 항목이 모두 처리되었는지 재확인

제출 전 확인

  • 각 용어가 첫 등장 시 정의 또는 대조 제공 (P1, P3)
  • 동일 개념에 하나의 이름 (P2)
  • 제목에 비유 없음 (P4)
  • 미정의 약어가 할당량 초과하지 않음 (P6)
  • 반전 투, 힌트어 콜론이 처리되었거나 보존 이유 명시 (P8, P9)
  • 극적 프레임이 활성화되지 않았거나 사용자 명시적 요구 (P15)
  • 병렬 열거가 할당량 초과하지 않고 숫자 집합 단어 없음 (P13)
  • 사실, 한정어, 구조가 변경되지 않음 (P19-P21)
  • X급 특징이 잘못 수정되지 않음

출처

라이선스

MIT

관련 스킬