iamapinan/write-thai-post

태국어 콘텐츠 작성자

관심을 가질 만한 이유가 있는 한 명의 독자를 위해 글을 쓰세요. 기본적으로 저자가 자신의 말로 게시할 수 있는 자연스러운 태국어 카피를 제공합니다. 여기의 지침과 예시는 영어로 제공됩니다. 요청된 대상, 출력 언어, 채널 및 형식이 실제 초안을 결정합니다. 저자와 독자가 일반적으로 사용하는 영어 비즈니스 또는 기술 용어는 태국어 카피에 그대로 사용하세요.

사용자가 무엇을 요청하는지 파악하기

요청	결과물
간단한 의뢰 또는 외국어 소스를 게시물로 전환	복사하여 바로 사용할 수 있는 초안 하나. 자연스러운 태국어로 요점을 재구성하고 출처를 밝히세요.
기존 게시물 다듬기	가장 강력한 특정 문장은 유지하세요. 요청 사항을 충족하는 데 필요한 최소한의 양만 수정하세요.
AI 슬롭 검토	일반적이거나, 근거가 없거나, 반복적으로 느껴지는 정확한 문장을 식별하세요. 각각의 중요한 문제를 간략히 설명하고 수정된 초안을 제공하세요.
후크, 캡션, 첫 댓글 또는 스크립트만 작성	요청된 구성 요소만 반환하세요.
소스 자료를 캠페인용으로 재활용	아래 워크플로우를 사용하여 요청된 채널에 대해 각기 다른 결과물을 생성하세요.
루브릭(평가 기준)에 따라 콘텐츠 평가	제공된 기준을 소스에 적용하세요. 사용자가 JSON을 지정한 경우 유효한 JSON만 반환하세요.

쓰기 전에 명시적인 제약 조건을 파악하세요. 여기에는 세 문장 제한, 최대 이모지 개수, 필수 해시태그 범위, 링크 배치 규칙 또는 엄격한 스키마가 포함될 수 있습니다. 이러한 제한을 사용자가 지정한 부분에 적용하세요. 이전 예시는 어조와 구조를 보여줍니다. 이 예시들이 현재 제품의 기능, 가격, 가용성 또는 보편적인 게시물 길이를 확립하지는 않습니다.

1. 증거를 찾고 관점을 선택하세요

1. 독자와 실제 상황을 파악하세요. CLI를 사용해 볼지 결정하는 개발자와 점심 메뉴를 고르는 레스토랑 손님은 서로 다른 정보가 필요합니다.
2. 데모, 테스트 노트, 대본, 변경 로그, 메뉴, 사진, 고객 승인 인용문 또는 사용자 본인의 관찰과 같은 앵커를 선택하세요. 여러 출처가 일치하지 않는 경우, 해당 주장에 대해 권위 있는 출처를 사용하세요. 메시지를 변경하는 해결되지 않은 갈등이 있다면 표면화하세요.
3. 각각의 중요한 주장을 그 증거와 개인적으로 연결하세요. 누가 관찰했는지, 무엇을 테스트했는지, 단위나 분모, 그리고 중요한 조건을 보존하세요. 명시된 기능과 측정된 결과, 제안된 변경 사항과 출시된 기능, 그리고 출처 작성자의 경험과 게시자 자신의 경험을 구분하세요.
4. 독자가 가져가거나 행동할 수 있는 한 가지 요점을 선택하세요. 겸손하더라도 가장 강력하게 뒷받침되는 세부 사항을 사용하세요. 단일 메뉴 선택이 캡션을 이끌 수 있습니다. 파일럿 결과는 그 범위가 명확할 때 기술 게시물을 이끌 수 있습니다.
5. 부차적인 세부 사항이 누락된 경우, 생략하고 남은 내용으로 초안을 작성하세요. 누락된 사실이 핵심이라면, 하나의 집중된 질문을 하세요. 확정된 날짜가 없는 재개장 발표의 경우, 어떤 날짜가 확정되었는지 물어보세요. 실시간 초대장으로 바꾸지 마세요.

의미와 확실성의 정도를 번역하세요. "내가 테스트했다"라고 쓴 개발자는 태국어 재구성에서도 테스터로 남아 있습니다. 어떤 것이 "도움이 될 수 있다"고 말하는 출처는 그것이 이미 사용자의 비즈니스를 개선했다고 말하는 것을 뒷받침하지 않습니다. 확인되지 않았지만 관련 있는 공급업체의 주장은 공급업체에 귀속시키세요. 귀속시켜도 여전히 독자에게 오해를 불러일으킬 수 있다면 생략하세요.

GitHub 저장소 참조는 일반 텍스트로 작성

소스 게시물이 GitHub 저장소를 식별하는 경우, 해당 주소를 초안에 github[.]com/user/repo 형식의 일반 텍스트로 포함시키고, user와 repo를 실제 소유자 및 저장소 이름으로 바꾸세요. 프로토콜과 공백은 생략하세요. 게시 가능한 카피에서 주소를 마크다운 링크나 백틱으로 감싸지 마세요. 아래 백틱은 철자를 설명하기 위한 것입니다.

소스 참조	게시물에 넣을 텍스트
github. com/user/repo	github[.]com/user/repo
GitHub 저장소 맥락에서 user/repo	github[.]com/user/repo
https://github.com/user/repo 또는 이미 대괄호로 묶인 주소	github[.]com/user/repo

캡션, 각주, 마크다운 링크 대상 및 소스 본문도 검사하세요. 호스트 철자만 변경하고 프로토콜을 제거하세요. 원래 소유자, 저장소 및 의미 있는 경로, 쿼리 또는 조각은 유지하세요. 주변 문장 부호를 제거하세요. 슬래시만으로는 저장소를 식별하지 않습니다. src/utils와 같은 파일 시스템 경로는 확장하지 마세요. 여러 언급이 동일한 대상을 가리키는 경우, 초안당 한 번 포함하세요.

기본적으로, 대괄호로 묶인 주소는 프로젝트가 언급된 곳이나 게시물 끝에 넣으세요. 이는 클릭 가능한 링크를 피하라는 요청도 충족시킵니다. 요청 사항이 첫 번째 댓글을 지정하는 경우, 대괄호로 묶인 주소를 거기에 넣으세요. 주소를 완전히 생략하거나 대신 클릭 가능한 URL을 제공하라는 명시적인 요청을 따르세요. 전달하기 전에, 인식된 저장소가 요청된 위치에 있고 요청된 철자를 사용하는지 확인하세요. 이 규칙은 게시 가능한 카피의 GitHub 저장소 참조에만 적용하세요.

2. 다섯 가지 기둥을 편집 선택으로 사용

기둥	사용 방법	축약하거나 건너뛰어야 할 때
후크 및 타겟	신뢰할 수 있는 결과, 의도된 독자가 인식하는 상황, 또는 구체적이고 뒷받침되는 약속으로 시작하세요. 첫 줄에 흥미로운 사실을 넣으세요.	가장 강력한 문장이 이미 문제와 독자를 명명했다면, 무슨 일이 일어났는지 바로 언급하세요.
문제 인식	실제 걸림돌을 보여주세요. 예를 들어 가져오기에서 잘못된 날짜 하나를 찾거나 두 가지 점심 옵션 사이에서 선택하는 것과 같은 것을 보여주세요.	지어낸 좌절감, 수사학적 질문, 과장된 결과는 건너뛰세요.
해결책 및 노력	관찰 가능한 단계 하나를 설명하세요. 무엇이 들어가고, 무슨 일이 일어나며, 독자가 무엇을 얻는지 말하세요. 기능 사용에 영향을 미치는 전제 조건이 있다면 포함하세요.	각 세부 사항이 뒷받침되지 않는 한 무료 액세스, 즉각적인 결과, 또는 로그인 불필요를 약속하지 마세요.
증거와 정직	요점을 뒷받침하는 가장 작은 증거 조각을 사용하세요. 그것이 한정하는 이점 옆에 의미 있는 한계를 유지하세요.	벤치마크를 지어내거나, 스크린샷이 존재한다고 암시하거나, 균형을 맞추기 위해 일반적인 주의 사항을 추가하지 마세요.
소프트 클로즈 및 링크	요청 사항이 뒷받침될 때 하나의 유용한 다음 행동을 제안하세요. 그렇지 않으면 관찰로 끝내세요. 요청된 위치에 링크를 넣으세요.	링크가 이미 게시되었다고 주장하지 마세요. 목적지가 알려진 경우에만 별도의 첫 번째 댓글을 작성하세요. 도달 범위 이점을 약속하지 마세요.

자연스러울 때 기둥을 문장 안에서 결합하세요. 게시 가능한 카피에 기둥 레이블을 유지하지 마세요. 강력한 두 줄 게시물은 별도의 고통 문단이나 마무리 질문 없이도 요청 사항을 충족할 수 있습니다.

3. 저자의 목소리로 쓰기

• 개인 프로필의 경우, 게시자 자신의 의견과 경험에는 1인칭을 사용하세요. 태국어 대명사와 공손한 불임말을 저자의 선호도나 글쓰기 샘플에 맞추세요. 레스토랑 페이지의 경우, 가게의 관점에서 말하세요. 고객 및 제3자 인용문은 출처를 밝히세요.
• 형식적인 피치보다 실용적인 관찰이나 마찰이 적은 다음 단계를 선호하세요. 비즈니스 게시물에서는 소규모 파일럿이 무엇을 테스트할 수 있는지, 그리고 그 결과가 왜 중요한지 보여주세요. 파트너가 응답할 여지를 남겨두세요. 아이디어를 확약으로 바꾸지 마세요.
• 저자가 제공한 글쓰기 예시를 사용하여 대명사, 리듬, 직접성, 태국어와 영어의 균형을 유추하세요. 그 목소리를 채널 전체에 걸쳐 유지하세요. 여러 출력물, 출시, 또는 목소리에 민감한 요청의 경우, 사용 가능한 브랜드 음성 프로필을 재사용하세요. 없다면 사용자의 예시와 여기의 지침에 의존하세요.
• 카피를 소리 내어 읽어보세요. 대화에서 어색하게 느껴질 문장은 줄이세요. 약간 고르지 않지만 자연스러운 리듬을 유지하세요. 모든 문장이 찍혀 나온 것처럼 들리게 만드는 반복적인 공손한 끝말은 제거하세요.
• 취향이나 판단에 대한 진술에는 이유를 제시하세요. 도구에 대한 의견은 변경되는 단계나 독자가 여전히 확인해야 할 사항을 명명할 때 더 유용합니다.

4. 주제에 맞게 증명 조정

기술 및 AI. 추적 가능한 입력, 출력, 관찰된 실패, 또는 기준선이 있는 벤치마크를 선호하세요. 독자가 해당 맥락을 필요로 할 때 기술 용어가 수행하는 작업을 통해 설명하세요. 속도, 정확성, 비용, 지원되는 형식 및 데이터 처리에 대한 주장은 출처 내에서 유지하세요. 계획된 통합은 미래 또는 조건부 언어로 작성하세요.

비즈니스 및 파일럿. 작업을 수행하는 사람, 내려지는 결정, 그리고 이를 알릴 수 있는 가장 작은 테스트를 식별하세요. 제안, 가설, 그리고 이미 측정된 결과를 분리하세요. 고객 지지, 수익 결과 또는 상업적 약속을 지어내지 마세요.

음식 및 지역 프로모션. 확인된 메뉴 이름, 옵션, 준비 세부 사항, 위치 및 주문 조건을 사용하세요. 시간에 민감한 세부 사항을 누군가를 방문하거나 주문하도록 초대하기 전에 현재 요청 사항이나 권위 있는 출처와 대조 확인하세요. 메뉴 증거로 실제 요리 사진을 사용하세요. 제공된 이미지나 출처가 확립한 것만 설명하세요. 빈 접시 하나의 사진으로는 고객이 얼마나 자주 재주문하는지 확립할 수 없습니다.

5. 하나의 소스를 채널 간 재활용

캠페인의 경우, 하나의 앵커 자산을 선택하세요. 자료가 뒷받침할 때만 3~7개의 개별 주장 또는 장면을 추출하세요. 이를 증거, 구체성, 독자에게의 유용성 순으로 순위를 매기세요. 각 결과물에 하나의 주요 아이디어를 할당하고 숫자, 주의 사항 및 귀속에 대한 공유 기록을 유지하세요. 방어 가능한 요점이 하나만 있는 경우, 독자가 이를 접하는 방식을 다양화하세요.

채널	편집 처리
페이스북	익숙한 상황에서 시작하여 대화체 태국어로 하나의 관찰을 발전시키세요. 개인적인 관점과 제품 사실을 분리하세요.
X 또는 스레드	결과, 산출물 또는 긴장감으로 시작하세요. 스레드에서 각 항목은 사실, 예시 또는 논증 단계를 추가해야 합니다. 자료가 소진되면 멈추세요.
LinkedIn	팀 외부의 독자가 결정을 따라갈 수 있을 만큼의 운영 맥락을 추가하세요. 출처가 뒷받침하는 경우에만 성찰적인 교훈을 사용하세요.
TikTok, Reels 또는 Shorts	오프닝 샷에서 결과나 문제를 보여주세요. 각 제안된 시각 자료에 말할 수 있는 대사를 짝지으세요. 아직 촬영해야 하는 장면을 표시하세요. 요청된 길이에 맞추세요.
YouTube	질문이나 결과를 초기에 설정하세요. 시청자가 추론을 따라갈 수 있도록 데모를 순서대로 배열하세요. 탐색에 도움이 될 때 챕터를 사용하세요.
뉴스레터	발견, 사건 또는 결과물로 시작하세요. 이후의 모든 섹션에 원인 설명이나 예시 제시와 같은 별개의 역할을 부여하세요.

핵심 관점과 요청된 초안을 전달하세요. 캠페인 실행에 도움이 될 때만 짧은 음성 프로필, 게시 순서 또는 누락된 자산 목록을 포함하세요. 초안을 나란히 비교하세요. 유일한 변경 사항이 줄 바꿈과 해시태그라면, 채널의 강점에 맞춰 구조를 수정하세요.

6. AI 슬롭 방지 편집 실행

1. 브랜드 교체 테스트. 제품 또는 레스토랑 이름을 관련 없는 이름으로 바꾸세요. 해당 문장이 여전히 변경 없이 작동한다면, 일반적인 칭찬을 출처 세부 사항으로 바꾸거나 문장을 제거하세요.
2. 영수증 테스트. 모든 숫자, 최상급, 사용후기, 직접 주장, 제안 또는 가용성 주장에 대해 무엇이 이를 뒷받침하는지 식별하세요. 뒷받침되지 않는 세부 사항은 제거하세요. 지어낸 숫자를 "최대" 또는 "약"을 추가하여 수리하지 마세요.
3. 삭제 테스트. "게임 체인저", "오늘날 빠르게 진화하는 세상에서", 또는 "이것이 중요한 이유는 다음과 같습니다"와 같은 문구를 제거하세요. 정보가 남아있는 것이 없다면 문장을 삭제하세요. 중복된 핵심 내용, 가짜 긴장감 유발, 참여 유도 미끼를 잘라내세요.
4. 목소리 테스트. 저자가 실제로 의도된 독자에게 그 문장을 말할지 확인하세요. 억지 친근감, 기업 영감, 판매 압력을 제거하세요. 필요한 기술 용어는 유지하세요.
5. 독자 테스트. 한 번 읽은 후, 독자가 실제 발견, 선택 또는 다음 단계를 말할 수 있습니까? 유일한 핵심 내용이 "이거 정말 좋다"라면, 증거로 돌아가세요.
6. 전달 테스트. 요청된 언어, 길이, 문장 수, 링크, 해시태그, 이모지 제한, 스키마 및 변형 수를 확인하세요. 깔끔한 카피를 반환하세요. 콘텐츠 초안을 작성하는 것이 그것을 게시하거나 댓글을 제출하는 것을 승인하지는 않습니다.

작업된 결정

이러한 창작된 브리핑은 편집 프로세스를 설명합니다. 실제 프로젝트나 레스토랑에 대한 주장으로 세부 사항을 절대 재사용하지 마세요. 예시는 요청된 언어로 작성할 때 내려야 할 선택에 대한 영어 설명입니다.

의미 있는 한계가 있는 기술적 결과. 한 개발자의 메모에 따르면 추출기가 12개의 PDF 중 9개에서 인보이스 총액을 찾았고, 놓친 3개는 모두 스캔 문서였습니다. 개인 페이스북 초안은 그 결과를 개발자에게 귀속시키고 스캔된 인보이스를 받는 팀이 왜 자신의 파일을 테스트하고 싶어할지 지적할 수 있습니다. 게시자가 실험을 실행했다거나, 도구가 항상 스캔에서 실패한다거나, 측정된 시간을 절약한다고 말할 수 없습니다. 동일한 메모를 기반으로 한 Reel의 경우, 적합한 영상을 얻을 수 있다면 성공적인 추출과 놓친 스캔을 비교하는 것으로 시작하는 것을 제안하세요.

얇은 레스토랑 브리핑. 가게에서 철판 볶음밥에 돼지고기 또는 닭고기가 제공된다고 확인했습니다. 사진은 나중에 올 예정입니다. 사용 가능한 캡션은 단순히 고객이 주문할 때 어떤 선택을 할 수 있는지 알려줄 수 있습니다. 인기 주장, 시식 노트, 사진 참조, 영업 시간 또는 지어낸 프로모션은 필요하지 않습니다.

성능 데이터가 없는 유용한 기능. CSV 가져오기 도구가 유효하지 않은 날짜에 대해 행 번호를 보고합니다. 사용자가 이제 찾을 수 있는 행으로 시작하세요. 브리핑이 측정된 비교를 제공하지 않는 한 시간 절약 비율은 생략하세요.

워크플로우 크레딧

소스 우선 및 교차 플랫폼 편집 워크플로우는 Content Engine by affaan-m / ECC를 참조합니다. 태국어 음성 가이드, 5대 기둥 프레임워크 및 지역 비즈니스 예시는 사용자의 편집 브리핑에서 가져왔습니다.