f8b21af4be
10_Wiki/Topics 대규모 정리: - 오류 캡처/미완성 stub 문서 227개 제거 - 교차폴더 중복 43클러스터 병합 (63파일 → redirect) - 링크명 정규화: 깨진 링크 수정·redirect 직결·개념 매핑 ~2,400건 - 카테고리 MOC 6개 신규 생성 - Graph 섹션 미해결 related-keyword 링크 10,058건 제거 Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
170 lines
4.9 KiB
Markdown
170 lines
4.9 KiB
Markdown
---
|
|
id: wiki-2026-0508-articulateness
|
|
title: Articulateness
|
|
category: 10_Wiki/Topics
|
|
status: verified
|
|
canonical_id: self
|
|
aliases: [명료성, articulation, prompt clarity, plain language, technical writing]
|
|
duplicate_of: none
|
|
source_trust_level: B
|
|
confidence_score: 0.85
|
|
verification_status: applied
|
|
tags: [communication, writing, prompt-engineering, technical-writing, plain-language, llm-collab]
|
|
raw_sources: []
|
|
last_reinforced: 2026-05-10
|
|
github_commit: pending
|
|
tech_stack:
|
|
language: writing / communication
|
|
applicable_to: [Prompt Engineering, Documentation, PR Description, Spec Writing]
|
|
---
|
|
|
|
# Articulateness
|
|
|
|
## 📌 한 줄 통찰
|
|
> **"매 thought 의 high-resolution output"**. 매 head 의 fuzzy idea 의 매 lossless 의 transmit. 매 AI 시대 의 가장 큰 leverage — 매 prompt 의 articulate = 매 output 의 quality. 매 vocabulary 의 X, 매 clarity 의 win.
|
|
|
|
## 📖 핵심
|
|
|
|
### 매 components
|
|
1. **Vocabulary precision**: 매 정확 단어 선택. 매 vague vs specific.
|
|
2. **Structural clarity**: 매 conclusion-first (BLUF, Bottom Line Up Front).
|
|
3. **Nuance**: 매 audience 의 calibrate.
|
|
4. **Cohesion**: 매 logical flow 의 transition.
|
|
5. **Concision**: 매 superfluous word 의 cut.
|
|
|
|
### 매 BLUF (Bottom Line Up Front)
|
|
- ❌ "Background, then build-up, then conclusion."
|
|
- ✅ "Conclusion. Then evidence."
|
|
|
|
→ 매 reader 의 시간 존중.
|
|
|
|
### Plain Language (매 modern standard)
|
|
- 매 short sentence (15-20 word).
|
|
- 매 active voice ("X did Y" > "Y was done by X").
|
|
- 매 concrete > abstract.
|
|
- 매 jargon 의 explain.
|
|
- 매 multinational 의 translation 의 friendly.
|
|
|
|
→ US Plain Writing Act (2010), GOV.UK style guide.
|
|
|
|
### 매 prompt engineering 의 articulateness
|
|
1. **Specific**: 매 "write a poem" → "매 4-line haiku 의 autumn".
|
|
2. **Constraint**: 매 length, 매 style, 매 audience.
|
|
3. **Example**: 매 few-shot.
|
|
4. **Role**: 매 "act as senior backend engineer".
|
|
5. **Output format**: 매 JSON, 매 bullet, 매 markdown.
|
|
|
|
### 매 technical writing 의 hierarchy
|
|
1. **README**: 매 30-second pitch.
|
|
2. **Tutorial**: 매 narrative, hand-holding.
|
|
3. **How-to**: 매 task-oriented.
|
|
4. **Reference**: 매 exhaustive.
|
|
5. **Explanation**: 매 conceptual.
|
|
|
|
→ Diátaxis framework.
|
|
|
|
### Anti-clarity 의 source
|
|
- 매 jargon 의 over-use.
|
|
- 매 passive voice.
|
|
- 매 nominalization ("perform an analysis" > "analyze").
|
|
- 매 abstract noun ("optimization", "leverage").
|
|
- 매 throat-clearing ("It is important to note that...").
|
|
|
|
## 💻 패턴
|
|
|
|
### Prompt template (specific + constraint)
|
|
```
|
|
Role: Senior TypeScript backend engineer.
|
|
Task: Refactor this function for testability.
|
|
Constraints:
|
|
- Keep the public signature unchanged.
|
|
- Extract DB call to a repository interface.
|
|
- Return a Result<T, E> instead of throwing.
|
|
- Output: code only, no explanation.
|
|
|
|
Input:
|
|
{{code}}
|
|
```
|
|
|
|
→ 매 vague "make it better" 의 X.
|
|
|
|
### PR description template
|
|
```markdown
|
|
## Why
|
|
[1-2 sentence motivation]
|
|
|
|
## What changed
|
|
- bullet
|
|
- bullet
|
|
|
|
## How to verify
|
|
- [ ] step 1
|
|
- [ ] step 2
|
|
|
|
## Risk
|
|
[regression area / rollback plan]
|
|
|
|
## Out of scope
|
|
[what NOT done — prevent reviewer churn]
|
|
```
|
|
|
|
### Plain language rewrite
|
|
```
|
|
❌ Original (50 words):
|
|
"It is recommended that users should consider implementing
|
|
appropriate validation mechanisms in order to ensure that
|
|
input data is properly sanitized before being processed."
|
|
|
|
✅ Rewrite (10 words):
|
|
"Validate input before processing."
|
|
```
|
|
|
|
### Articulateness 의 self-check
|
|
```
|
|
1. 매 첫 sentence 의 conclusion?
|
|
2. 매 sentence avg < 25 word?
|
|
3. 매 active voice 의 80%+?
|
|
4. 매 jargon 의 explain or replace?
|
|
5. 매 reader 의 next step 의 clear?
|
|
```
|
|
|
|
## 🤔 결정 기준
|
|
| 상황 | 우선 |
|
|
|---|---|
|
|
| Spec / RFC | Structural clarity + precision |
|
|
| README | BLUF + plain language |
|
|
| PR description | Why + what + risk |
|
|
| LLM prompt | Specific + constraint + format |
|
|
| Slack / async | Concise + actionable |
|
|
| Customer-facing | Plain + nuance |
|
|
|
|
**기본값**: BLUF + active + concise + concrete.
|
|
|
|
## 🔗 Graph
|
|
- 변형: [[Plain-Language]] · [[Technical-Writing]]
|
|
- 응용: [[Prompt_Engineering|Prompt-Engineering]] · [[PR-Template]]
|
|
- Adjacent: [[Vocabulary-Expansion]]
|
|
|
|
## 🤖 LLM 활용
|
|
**언제**: 매 prompt 의 craft. 매 doc / spec / PR write. 매 communication 의 review.
|
|
**언제 X**: 매 creative writing 의 nuance 의 sacrifice. 매 poetic context.
|
|
|
|
## ❌ 안티패턴
|
|
- **Throat-clearing**: 매 "It is important to note that..."
|
|
- **Passive voice abuse**: 매 actor 의 hide.
|
|
- **Jargon dump**: 매 audience 의 ignore.
|
|
- **Burying lede**: 매 conclusion 의 끝.
|
|
- **Nominalization**: "perform an analysis" 의 "analyze".
|
|
- **Vague prompt**: 매 "make it better" 의 LLM 에 unhelpful.
|
|
|
|
## 🧪 검증 / 중복
|
|
- Verified (Plain Writing Act, GOV.UK style, Diátaxis).
|
|
- 신뢰도 B.
|
|
- Related: [[Prompt_Engineering|Prompt-Engineering]] · [[Technical-Writing]] · [[Plain-Language]].
|
|
|
|
## 🕓 Changelog
|
|
| 날짜 | 변경 |
|
|
|---|---|
|
|
| 2026-05-08 | Phase 1 |
|
|
| 2026-05-10 | Manual cleanup — BLUF + Plain Language + Diátaxis + prompt template |
|