AI concluded my writing guide

writing-style-giude.md

Writing Style Guide

Core Philosophy

This author writes to challenge assumptions and reveal hidden mechanisms. The writing serves as a tool for readers to see through surface phenomena and understand underlying structures—whether in debugging systems, human psychology, or business models.

---

Narrative Structure

Opening Strategy

Pattern: Concrete Story → Surprising Twist → Universal Principle

• Begin with a specific, vivid anecdote (often personal or client-related)
• The story must contain an unexpected element that disrupts common assumptions
• Transition naturally from story to the broader concept it illustrates

Examples from corpus:

• ch0: Starts with conversation about food → leads to Asperger's diagnosis → explores epistemology of classification
• ch1: Friend's McKinsey internship → discomfort with consulting role → journey to boutique consulting

Why it works: The reader enters through a relatable scene, gets hooked by the twist, then accepts the abstract lesson because they've already experienced it concretely.

Section Development

Progressive Disclosure Pattern:

1. Present a phenomenon or question
2. Offer initial analysis or common interpretation
3. Introduce complicating factor or deeper layer
4. Arrive at nuanced conclusion

Avoid:

• Starting with definitions or theory
• Linear exposition without tension
• Presenting the "answer" before building the question

Transitions

Preferred style: Conversational bridges that acknowledge the reader's likely thought process

Examples:

• "你可能會想，有必要做這樣子的區分嗎？實際上..."
• "這邊有一個好消息..."
• "如果你在十年前問我..."

Avoid:

• Mechanical transitions ("接下來", "然後")
• Obvious signposting ("本節將探討...")

---

Sentence and Paragraph Architecture

Sentence Length and Rhythm

Preferred pattern: Variable rhythm with strategic short sentences

• Mix longer analytical sentences (20-40 characters) with punchy conclusions (8-15 characters)
• Use short sentences for emphasis, turning points, or provocative statements
• Long sentences are acceptable when building complex arguments, but must remain structurally clear

Example from ch1:

"他們幾乎都是顧問，而且是我想成為的那一種。" (Short, emphatic conclusion)

"這個槓桿相當的簡單明瞭，就是用人力資源去放大專業知識可以服務的範圍，但實際的情況卻複雜的多，因為專業知識、人力資源、定價、還有客戶群這四者必須匹配。" (Long, but structured with clear causal logic)

Paragraph Structure

Core principle: One idea per paragraph, but develop it fully

• Paragraphs range from 2-6 sentences
• Each paragraph should have internal tension or progression
• Avoid single-sentence paragraphs unless used for dramatic effect

Punctuation Philosophy

Comma usage: Liberal use to create breathing room and mimic spoken rhythm

• Prefer commas over periods when ideas are causally connected
• Use commas to set off parenthetical remarks

Parenthetical elements:

• Use parentheses () for clarifying examples or side notes
• Use dash — for emphatic asides (but sparingly)
• Use brackets [] for technical precision

Quotation marks:

• 「」for direct speech
• 『』for nested quotes or conceptual terms being examined
• Avoid scare quotes unless deliberately questioning a term's validity

---

Voice and Tone

Conversational Authority

Core tone: An expert speaking to an intelligent peer, not a teacher lecturing students

Characteristics:

• Direct address using "你" freely
• Willing to share personal uncertainty or past mistakes
• Challenges reader's assumptions without condescension
• Uses rhetorical questions to guide thinking, not to be coy

Example:

"我又如何確定我現在所認為的自身專業，就是市場最肯定的？或是更進一步的提問：「我真的了解了自己所有的潛力了嗎？」"

Skepticism and Challenge

Pattern: Question conventional wisdom, then provide alternative framework

• Frequently uses constructions like "然而", "但是", "實際上" to pivot from common view
• Challenges are evidence-based or logic-based, not merely contrarian
• Willing to disagree with established authorities (e.g., McKinsey model, traditional career advice)

Avoid:

• Aggressive or dismissive tone toward opposing views
• False balance (don't soften conclusions that have strong evidence)
• Apologetic hedging when making bold claims backed by reasoning

Use of Examples

Preference: Specific, often personal or observed cases

• Examples are detailed enough to be memorable
• Often involve named people or specific numbers
• Examples precede or follow theory, but rarely interrupt it mid-flow

Pattern:

1. Make abstract claim
2. Provide 1-2 concrete examples
3. Return to abstraction with enhanced understanding

---

Conceptual Vocabulary

Technical Terms

Approach: Introduce terms when needed, define through context

• Use English terms in parentheses after Chinese when first introduced
• Don't over-explain terms that educated readers should know
• For novel concepts (e.g., "隱性槓桿"), define through contrast and example rather than dictionary-style

Metaphors and Analogies

Use sparingly but effectively

Examples from corpus:

• "帶著榔頭去找釘子" (having a hammer, looking for nails)
• "正確到不可原諒" (correct to the point of being unforgivable)

Characteristics:

• Prefer common sayings or vivid imagery
• Avoid extended metaphors that take over the argument
• Metaphors should clarify, not decorate

Domain-Specific Language

Business/Consulting:

• Comfortable with terms like ROI, business pivot, metric, niche market
• Uses English terms when they're standard in the field
• Explains concepts through mechanism, not jargon

Technology/Systems:

• References like Bayesian classifiers, fMRI, telemetry tools
• Technical precision matters, but accessibility is prioritized

---

Structural Elements

Lists and Enumeration

When to use:

• Taxonomies or classifications (e.g., 三大類別, 四個共同點)
• Multi-part arguments where each part needs equal weight
• Comparisons or contrasts

Format:

• Numbered lists when order or hierarchy matters
• Bulleted lists when items are equal in importance
• Each list item should be substantial (not just keywords)

Avoid:

• Lists as a substitute for prose when a narrative would be clearer
• Excessive sub-bullets (rarely go beyond one level)

Tables

When appropriate:

• Presenting comparative data (e.g., revenue by company type)
• Organizing information that truly benefits from tabular structure

Style:

• Keep table headers clear and concise
• Include source citations
• Provide context in surrounding prose—don't let tables stand alone

Headers and Sections

Hierarchy:

• Main chapter/article title (#)
• Major sections (##)
• Subsections (###)
• Rarely go beyond ### level

Header style:

• Concrete and descriptive
• Can be provocative or question-based
• Avoid generic headers ("背景", "分析")

---

Argumentation Style

Building Claims

Preferred structure: Evidence → Inference → Implication

1. Present observable facts or research findings
2. Explain what these facts mean
3. Connect to broader principle or actionable insight

Example from ch0:

• Evidence: Research on Asperger's brain structure
• Inference: Different operating mode, not deficiency
• Implication: Testing requires telemetry tools, not behavioral checklists

Handling Counterarguments

Approach: Acknowledge, then refine or redirect

• Don't strawman opposing views
• Often presents common objections as questions reader might ask
• Uses counterarguments to strengthen final position

Pattern:

"你可能會想..." [present objection] → "實際上..." [refine the question]

Use of Authority

Selective citation of respected sources

• Names like David Maister, Marshall Goldsmith, Peter Drucker
• Citations are integrated into argument, not used as proof by authority
• Willing to critique even respected sources when logic demands it

---

Diction Preferences

Verbs

Prefer active, specific verbs:

• 掌握 (not 擁有)
• 建立 (not 創建)
• 應用 (not 使用 when referring to knowledge)

Avoid:

• Passive constructions unless deliberately emphasizing the object
• Vague verbs like 進行, 實施 when more specific options exist

Adjectives and Intensifiers

Use strategically, not decoratively

• Intensifiers should add precision: "極其特殊", "顯著的成效"
• Avoid stacking adjectives
• Prefer concrete description over evaluative adjectives

Warning signs of AI-like writing:

• Overuse of "關鍵", "重要", "深刻"
• Adjectives that don't add information

Conjunctions and Transitions

Frequent use:

• 然而, 但是, 也因此 (to show contrast or causation)
• 同時 (to add parallel points)
• 換句話說, 白話一點的講法 (to rephrase for clarity)

Avoid:

• Mechanical transitions: 首先, 其次, 最後
• Overuse of 另外, 此外 (use sparingly)

---

Special Patterns

Rhetorical Questions

Used frequently for three purposes:

1. To frame the reader's likely question:

   "你是否相信自己一定會成功？為什麼？"

2. To challenge assumptions:

   "我又如何確定我現在所認為的自身專業，就是市場最肯定的？"

3. To transition to new sections:

   "已經起心動念想要開始從事顧問了，第一步該從哪裡開始呢？"

Avoid:

• Rhetorical questions as filler
• Questions that are immediately answered (unless the immediate answer is itself surprising)

Personal Anecdotes

When and how to use:

• Reserve for opening hooks or key turning points
• Must be genuinely relevant, not decorative
• Often involves vulnerability or past mistakes
• Can be third-person (clients, colleagues) to maintain some distance

Pattern:

"我本人是走第二條路：我先是得到一個機會..." [specific details] → [lesson learned]

Parenthetical Asides

Common patterns:

1. Examples: "（比方說：如何做茶杯）"
2. Clarifications: "（他們通常都有明顯領先、甚至是原創的方法論）"
3. Alternative phrasings: "（白話一點的講法，就是名校畢業生）"

Frequency: Moderate use—don't overload prose with parentheticals

---

What to Avoid

AI-Generated Writing Tells

Excessive formality:

• ❌ "在此背景下", "基於以上分析"
• ✅ "也因此", "既然如此"

Lifeless abstraction:

• ❌ "實現價值最大化"
• ✅ "創造高價值"

Redundant emphasis:

• ❌ "非常重要的關鍵點"
• ✅ "關鍵點" or just make the point

Over-hedging:

• ❌ "可能在某種程度上具有一定的參考價值"
• ✅ "有參考價值" or state the limits clearly

Structural Pitfalls

Avoid:

• Starting sections with definitions ("所謂的X是指...")
• Ending with summary paragraphs that just repeat what was said
• Topic sentences that announce what the paragraph will do
• Gratuitous subheadings that break natural flow

Tonal Mistakes

Don't:

• Preach or moralize
• Use corporate buzzwords uncritically
• Adopt a distant, academic tone
• Sound apologetic when making bold but well-supported claims

---

Quality Checklist

Before finalizing any piece, verify:

1. Opening: Does it start with a concrete scene or provocative claim, not theory?
2. Flow: Do paragraphs connect through logic, not mechanical transitions?
3. Voice: Does it sound like a smart person talking, not a formal report?
4. Specificity: Are examples concrete enough to be memorable?
5. Punctuation: Are commas used to create rhythm, not just grammatical obligation?
6. Challenge: Does it question at least one common assumption?
7. Utility: Will the reader have a new mental model or actionable insight?

---

Adaptation for AI Use

When providing feedback on drafts:

1. Check for authenticity: Flag prose that sounds generic or "AI-like"
2. Evaluate structure: Confirm the piece follows concrete-to-abstract pattern
3. Test claims: Ensure assertions are backed by mechanism or evidence
4. Verify tone: Confirm the voice is conversational authority, not academic distance
5. Assess specificity: Push for more concrete examples if the piece feels abstract

When revising based on this guide:

• Don't mechanically apply every rule—use judgment
• Do prioritize voice and structure over individual word choices
• Focus on eliminating AI tells and restoring natural rhythm
• Remember the goal is reader transformation, not information delivery

---

Meta-Principles

1. Truth over style: If clarity requires breaking a style rule, break it
2. Rhythm matters: Read aloud to check flow
3. Respect the reader: Assume intelligence, reward attention
4. Earn the abstraction: Concrete before abstract, always
5. Challenge productively: Question assumptions to build better frameworks, not just to provoke

---

This guide is a tool, not a rulebook. Use it to evaluate and improve writing while maintaining the essential quality: authentic expertise communicated with clarity and confidence.

wrting-style-guide-v2.md

Writing Style Guide v2.0

Based on analysis of three exemplary pieces: ch0 (epistemology/debugging), ch1 (boutique consulting), and Interactive Development (technical)

---

Core Philosophy

This author writes to challenge assumptions and reveal hidden mechanisms. The writing serves as a tool for readers to see through surface phenomena and understand underlying structures—whether in debugging systems, human psychology, business models, or technical practices. The goal is not merely to inform but to transform the reader's mental models.

---

Narrative Structure

Opening Strategy

Pattern: Concrete Story → Surprising Twist → Universal Principle

The opening must accomplish three things in sequence:

1. Ground in specificity: Start with a vivid, personal anecdote or observed scenario
2. Introduce disruption: Present an unexpected element that challenges common assumptions
3. Pivot to abstraction: Transition naturally to the broader concept the story illustrates

Examples from corpus:

ch0 (epistemology):

A客戶連續一個月吃同一道菜而昏倒 
→ 「你是亞斯吧？」測驗結果32分的震驚
→ 引出貝葉氏分類器 vs 遙測工具的epistemology

ch1 (business):

同學去麥肯錫實習的對話
→ 「你不會覺得去給那些管理階層建議，好像有哪裡怪怪的？」
→ 引出精品顧問的商業模式

Interactive Development (technical):

小時候得水痘的故事
→ 父親說「小孩不是小一號的成人」
→ 引出互動式開發在不同規模系統的差異

Why it works: The reader enters through a relatable scene, gets hooked by the twist, then accepts the abstract lesson because they've already experienced it concretely. The story is not decoration—it's the foundation of understanding.

Critical: The opening story must be memorable and specific. Avoid generic scenarios like "有一次我遇到一個問題..." Instead: "2008年，我的研究所同學在麥肯錫實習..." Specificity creates credibility.

---

Section Development

Progressive Disclosure Pattern:

1. Present a phenomenon or question
2. Offer initial analysis or common interpretation
3. Introduce complicating factor or deeper layer
4. Arrive at nuanced conclusion

Example from Interactive Development:

1. 互動式開發在小系統很自然
2. 一般認為它會自然延續
3. 但實際上容易在系統成長後流失
4. 必須有意識地維護

Avoid:

• Starting with definitions or theory ("所謂的X是指...")
• Linear exposition without tension
• Presenting the "answer" before building the question

---

The Role of Analogy

NEW in v2.0: Analogies can serve as structural scaffolding, not just occasional decoration.

Two modes of analogy use:

Mode A: Point-of-Illustration Analogy

Use an analogy to clarify a single concept, then move on.

Example from ch1:

"帶著榔頭去找釘子" (having a hammer, looking for nails)

Characteristics:

• Appears once or twice
• Clarifies a specific point
• Does not organize the entire piece

Mode B: Structural Analogy (NEW)

Use an analogy to organize the entire argument.

Example from Interactive Development:

"小孩不是小一號的成人" as the organizing metaphor for "小型系統 ≠ 大型系統的縮小版"

Characteristics:

• Introduced in opening
• Echoed in conclusion ("正如『小孩並不是小一號的成人』所提醒的...")
• Provides interpretive framework throughout

When to use structural analogy:

• When the analogy has genuine explanatory power
• When it helps readers remember the core insight
• When the mapping is clear and doesn't require constant re-explanation

When NOT to use:

• When the analogy is merely decorative
• When the mapping breaks down or becomes confusing
• When technical precision would be clearer

---

Transitions

Preferred style: Conversational bridges that acknowledge the reader's likely thought process

Common patterns:

• "你可能會想，有必要做這樣子的區分嗎？實際上..."
• "這邊有一個好消息..."
• "如果你在十年前問我..."
• "儘管好處是如此地明顯..." (設置對比)

Avoid:

• Mechanical transitions ("接下來", "然後", "首先其次最後")
• Obvious signposting ("本節將探討...")
• Academic formality ("在此背景下", "基於以上分析")

---

Sentence and Paragraph Architecture

Sentence Length and Rhythm

Preferred pattern: Variable rhythm with strategic short sentences

• Mix longer analytical sentences (20-40 characters) with punchy conclusions (8-15 characters)
• Use short sentences for emphasis, turning points, or provocative statements
• Long sentences are acceptable when building complex arguments, but must remain structurally clear

Example from ch1:

"他們幾乎都是顧問，而且是我想成為的那一種。" (Short, emphatic conclusion)

"這個槓桿相當的簡單明瞭，就是用人力資源去放大專業知識可以服務的範圍，但實際的情況卻複雜的多，因為專業知識、人力資源、定價、還有客戶群這四者必須匹配。" (Long, but structured with clear causal logic)

Example from Interactive Development:

"這就導致一個問題：" (Short setup for the problem)

"如果我只是想要修改某一個元件的一些設定值，比方說，將某個元件的 port 從 8080 改成 8089，每一次修改後就得重啟整個系統，而整個系統的啟動往往慢到可以中斷心流。" (Long problem description with concrete example)

---

Paragraph Structure

Core principle: One idea per paragraph, but develop it fully

• Paragraphs range from 2-6 sentences
• Each paragraph should have internal tension or progression
• Avoid single-sentence paragraphs unless used for dramatic effect

NEW in v2.0: In technical writing, a paragraph can be structured as:

1. Problem statement
2. Code example
3. Explanation of why the code solves the problem

Example from Interactive Development:

[Problem] 商務邏輯與服務的緊密耦合問題
[Code] (def web-handler ...)
       (run-jetty #'web-handler {:port 8080})
[Explanation] #' 表示 var 引用，讓系統在執行期間保留對變數的「間接」存取...

---

Punctuation Philosophy

Comma usage: Liberal use to create breathing room and mimic spoken rhythm

• Prefer commas over periods when ideas are causally connected
• Use commas to set off parenthetical remarks

Parenthetical elements:

• Use parentheses () for clarifying examples, side notes, or English terms
  • "（比方說：如何做茶杯）"
  • "（business logic）"
  • "（白話一點的講法，就是名校畢業生）"
• Use dash — for emphatic asides (but sparingly)
• Use brackets [] for technical precision or inline notes

Quotation marks:

• 「」for direct speech
• 『』for nested quotes or conceptual terms being examined
• Avoid scare quotes unless deliberately questioning a term's validity

Colon usage:

• Use colon to introduce examples or explanations
• Common pattern: "這就導致一個問題：" followed by detailed explanation

---

Voice and Tone

Conversational Authority

Core tone: An expert speaking to an intelligent peer, not a teacher lecturing students

Characteristics:

• Direct address using "你" freely
• Willing to share personal uncertainty or past mistakes
• Challenges reader's assumptions without condescension
• Uses rhetorical questions to guide thinking, not to be coy

Example from ch1:

"我又如何確定我現在所認為的自身專業，就是市場最肯定的？或是更進一步的提問：「我真的了解了自己所有的潛力了嗎？」"

Example from Interactive Development:

"我經常想起這句話，尤其當我觀察 Clojure 的互動式開發機制時..."

Key distinction: The "我" in these examples is not self-centered—it's used to share genuine observation and invite the reader into a thought process.

---

Skepticism and Challenge

Pattern: Question conventional wisdom, then provide alternative framework

• Frequently uses constructions like "然而", "但是", "實際上" to pivot from common view
• Challenges are evidence-based or logic-based, not merely contrarian
• Willing to disagree with established authorities or common practices

Example from Interactive Development:

"儘管好處是如此地明顯，互動式開發卻是在系統逐步發展時，容易意外流失的特性之一。"

Avoid:

• Aggressive or dismissive tone toward opposing views
• False balance (don't soften conclusions that have strong evidence)
• Apologetic hedging when making bold claims backed by reasoning

---

Use of Examples

Preference: Specific, often personal or observed cases

In non-technical writing:

• Examples are detailed enough to be memorable
• Often involve named people or specific numbers
• Examples precede or follow theory, but rarely interrupt it mid-flow

In technical writing (NEW in v2.0):

• Code examples are executable and concrete, not pseudocode
• Each code example is contextualized with problem and explanation
• Examples show the minimal viable demonstration, not exhaustive coverage

Pattern:

1. Make abstract claim
2. Provide 1-2 concrete examples (with code if technical)
3. Return to abstraction with enhanced understanding

---

Conceptual Vocabulary

Technical Terms

Approach: Introduce terms when needed, define through context

• Use English terms in parentheses after Chinese when first introduced
  • "元件 (component)"
  • "商務邏輯 (business logic)"
• Don't over-explain terms that educated readers should know
• For novel concepts (e.g., "隱性槓桿"), define through contrast and example rather than dictionary-style

NEW in v2.0: For technical writing, provide formal definitions when introducing domain-specific concepts:

Example from Interactive Development:

"這邊先提出一個互動式開發的定義：

互動式開發是一種開發機制，允許開發者在系統運行時，對系統之中的任意小區段程式碼進行即時的修改、執行與觀察..."

When to use formal definitions:

• When the term is central to the piece and non-standard
• When precision matters for the argument
• When the definition itself challenges common understanding

When NOT to use:

• For widely known technical terms (REPL, API, etc.)
• When context makes the meaning obvious
• When the definition would interrupt narrative flow

---

Metaphors and Analogies

Two modes (as discussed in Narrative Structure section):

1. Point-of-illustration: Quick clarification, then move on
2. Structural: Organize the entire piece

Characteristics of good metaphors/analogies:

• Prefer common sayings or vivid imagery
• Draw from everyday experience or other domains
• Should clarify, not decorate
• If extended, must carry genuine explanatory weight

Examples:

• Point-of-illustration: "帶著榔頭去找釘子", "正確到不可原諒"
• Structural: "小孩不是小一號的成人" → 小型系統 vs 大型系統

---

Domain-Specific Language

Business/Consulting:

• Comfortable with terms like ROI, business pivot, metric, niche market
• Uses English terms when they're standard in the field
• Explains concepts through mechanism, not jargon

Technology/Systems:

• References like Bayesian classifiers, fMRI, telemetry tools
• Technical precision matters, but accessibility is prioritized
• Uses both Chinese and English terms fluidly (e.g., "元件 (component)")

Programming (NEW in v2.0):

• Uses standard Clojure/programming terminology
• Code formatting follows community conventions
• Comments in code are in English (per user preference)
• Balances technical precision with readability

---

Structural Elements

Lists and Enumeration

When to use:

• Taxonomies or classifications (e.g., "三大類別", "四個共同點")
• Multi-part arguments where each part needs equal weight
• Comparisons or contrasts
• NEW: Diagnostic checklists (problem + solution patterns)

Format:

• Numbered lists when order matters OR when creating a sequential diagnostic checklist
• Bulleted lists when items are equal in importance
• Each list item should be substantial (not just keywords)

NEW in v2.0: Diagnostic Checklist Pattern

Used when presenting a series of independent problems, each with its own solution.

Example from Interactive Development:

## 流失理由 1：元件 (component) 與系統的緊密耦合
[Problem description]
解法是...

## 流失理由 2：商務邏輯 (business logic) 與服務 (service) 的緊密耦合
[Problem description]
解法是...

Characteristics:

• Each item is self-contained (problem + solution)
• Order doesn't matter (not sequential steps)
• Reader can skip to relevant sections
• Numbered for easy reference, not because sequence matters

When to use diagnostic checklist:

• Troubleshooting guides
• Common pitfalls with solutions
• Multiple independent failure modes
• Reader needs to identify which situation applies to them

Avoid:

• Lists as a substitute for prose when a narrative would be clearer
• Excessive sub-bullets (rarely go beyond one level)

---

Tables

When appropriate:

• Presenting comparative data (e.g., revenue by company type)
• Organizing information that truly benefits from tabular structure

Style:

• Keep table headers clear and concise
• Include source citations
• Provide context in surrounding prose—don't let tables stand alone

Note: Tables can slightly interrupt prose rhythm, so use judiciously. If a table appears, ensure it's genuinely the best format for the information.

---

Headers and Sections

Hierarchy:

• Main chapter/article title (#)
• Major sections (##)
• Subsections (###)
• Rarely go beyond ### level

Header style:

• Concrete and descriptive
• Can be provocative or question-based
• NEW: In diagnostic patterns, use "問題 + 具體描述" format
  • "流失理由 1：元件 (component) 與系統的緊密耦合"
  • Not just "問題一" or "耦合問題"

Avoid generic headers:

• "背景", "分析", "結論"
• "介紹", "概述"

---

Code Integration (NEW in v2.0)

When writing technical pieces with code:

Code Block Principles

1. Executable over pseudocode

   • Show real, runnable code
   • Prefer complete examples over fragments when possible

2. Minimal viable demonstration

   • Show just enough to illustrate the point
   • Don't show exhaustive edge cases unless that's the point

3. Context sandwich pattern:

   [Problem statement]
   
   ```code
   (example code)
   

   [Explanation of how code solves the problem]

Example from Interactive Development:

[Problem] 需要局部控制元件生命週期

[Code] 
(def web-handler ...)
(run-jetty #'web-handler {:port 8080})

[Explanation]
在 Clojure 中，#' 表示 var 的引用（var reference），它讓系統在執行期間保留對變數的「間接」存取...

Code Formatting

• Use standard language conventions (Clojure indentation, etc.)
• Inline code uses backticks: web-handler, #'var-name
• Code comments in English (per user preference)
• Keep examples focused—don't show full implementations unless necessary

Explaining Code

• Don't explain every line
• Focus on the key mechanism that solves the problem
• Assume reader has basic familiarity with the language
• Explain why this approach works, not just what it does

---

Argumentation Style

Building Claims

Preferred structure: Evidence → Inference → Implication

1. Present observable facts or research findings
2. Explain what these facts mean
3. Connect to broader principle or actionable insight

Example from ch0:

• Evidence: Research on Asperger's brain structure
• Inference: Different operating mode, not deficiency
• Implication: Testing requires telemetry tools, not behavioral checklists

Example from Interactive Development:

• Evidence: 系統啟動會將所有元件綁定在一起
• Inference: 任何元件變動都需要重啟整個系統
• Implication: 需要局部控制元件生命週期的機制

---

Handling Counterarguments

Approach: Acknowledge, then refine or redirect

• Don't strawman opposing views
• Often presents common objections as questions reader might ask
• Uses counterarguments to strengthen final position

Pattern:

"你可能會想..." [present objection] → "實際上..." [refine the question]

---

Use of Authority

Selective citation of respected sources

• Names like David Maister, Marshall Goldsmith, Peter Drucker
• Technical references (HoneySQL, Ring, specific libraries)
• Citations are integrated into argument, not used as proof by authority
• Willing to critique even respected sources when logic demands it

NEW in v2.0: When referencing libraries/tools:

• Link to source when first mentioned
• Explain why this tool is better, not just that it exists
• Compare to alternatives when relevant

Example from Interactive Development:

"如果不幸使用的函式庫是 YeSQL 的話，這兩點通常都難以做到。因為 YeSQL 的設計如下：[具體問題]

解法是更換為像 HoneySQL 這樣的函式庫..."

---

Diction Preferences

Verbs

Prefer active, specific verbs:

• 掌握 (not 擁有)
• 建立 (not 創建)
• 應用 (not 使用 when referring to knowledge)
• 導覽 (navigate—NEW from Interactive Development)
• 補充, 驗証, 觀察 (technical precision—NEW)

Avoid:

• Passive constructions unless deliberately emphasizing the object
• Vague verbs like 進行, 實施 when more specific options exist

---

Adjectives and Intensifiers

Use strategically, not decoratively

• Intensifiers should add precision: "極其特殊", "顯著的成效", "意外流失"
• Avoid stacking adjectives
• Prefer concrete description over evaluative adjectives

Warning signs of AI-like writing:

• Overuse of "關鍵", "重要", "深刻"
• Adjectives that don't add information

---

Conjunctions and Transitions

Frequent use:

• 然而, 但是, 實際上 (to show contrast or causation)
• 同時 (to add parallel points)
• 也因此 (therefore)
• 換句話說, 白話一點的講法 (to rephrase for clarity)
• 儘管...卻是... (to set up contrast—NEW)

Avoid:

• Mechanical transitions: 首先, 其次, 最後
• Overuse of 另外, 此外 (use sparingly)
• Academic formality: 在此背景下, 基於以上

---

Special Patterns

Rhetorical Questions

Used frequently for three purposes:

1. To frame the reader's likely question:

   "你是否相信自己一定會成功？為什麼？"

2. To challenge assumptions:

   "我又如何確定我現在所認為的自身專業，就是市場最肯定的？"

3. To transition to new sections:

   "已經起心動念想要開始從事顧問了，第一步該從哪裡開始呢？"

Avoid:

• Rhetorical questions as filler
• Questions that are immediately answered (unless the immediate answer is itself surprising)

---

Personal Anecdotes

When and how to use:

• Reserve for opening hooks or key turning points
• Must be genuinely relevant, not decorative
• Often involves vulnerability or past mistakes
• Can be third-person (clients, colleagues) to maintain some distance
• NEW: Can draw from childhood or family experiences when they carry genuine insight

Examples:

• First-person professional: "我本人是走第二條路：我先是得到一個機會..."
• Third-person client: "A 客戶很得意地告訴我，她高中時..."
• Childhood memory: "小時候，我姊姊得了水痘..." (NEW from Interactive Development)

Pattern:

[Specific story with concrete details] → [Lesson learned or principle illustrated]

---

Parenthetical Asides

Common patterns:

1. Examples: "（比方說：如何做茶杯）"
2. Clarifications: "（他們通常都有明顯領先、甚至是原創的方法論）"
3. Alternative phrasings: "（白話一點的講法，就是名校畢業生）"
4. English terms (NEW): "（component）", "（business logic）"
5. Technical notes (NEW): "（例如只關掉 :web）"

Frequency: Moderate use—don't overload prose with parentheticals

---

Conclusion Techniques (NEW in v2.0)

Three observed patterns:

Pattern A: Philosophical Elevation (ch0)

End by connecting to broader values or epistemological principles.

Example from ch0:

"確定為真、對真實的確信，可以讓我們對做出的結論深具信心，而這將有助於我們挑戰權威、勇於創新、開創新局。"

When to use: When the piece has philosophical or methodological implications

---

Pattern B: Reflective Question (ch1)

End with a personal, introspective question that invites the reader to examine themselves.

Example from ch1:

"你是否相信自己一定會成功？為什麼？

• 是因為充滿情緖張力的，絕對不允許自己再被一個德不配位的愚蠢上司開除？
• 是因為正確到不可原諒的話，好像也沒有那麼困難，自己每天都在說？
• 還是因為客戶已經上門拜託了、訂單直接寄到信箱裡？"

When to use: When the piece is about personal transformation or decision-making

---

Pattern C: Poetic Parallelism (Interactive Development—NEW)

End with a rhythmic series of parallel clauses that elevate from concrete to abstract.

Example from Interactive Development:

"這樣的投資是值得的。它讓開發者更深入理解系統，讓心流更容易出現，讓為測試設計的函數有了新的用途，讓編輯器整合成為實用的開發介面，也讓我們更容易設計出真正高度解耦的系統。"

Structure:

• Start with assertion: "這樣的投資是值得的。"
• Follow with parallel clauses: "讓...讓...讓...讓...也讓..."
• Move from concrete benefits to abstract principles
• End on highest-level abstraction

When to use:

• When multiple benefits need to be synthesized
• When you want to end with inspirational momentum
• When the piece has been analytical and needs an emotional lift

Key technique: Use "讓" (cause/enable) to maintain grammatical parallelism while varying the object of each clause.

---

Pattern D: Echo the Opening (also seen in Interactive Development—NEW)

Circle back to the opening metaphor or story.

Example from Interactive Development:

Opening: "小孩不是小一號的成人" Conclusion: "正如『小孩並不是小一號的成人』所提醒的，互動式開發在小型系統中看似自然、順暢，一旦系統逐漸擴大，就必須有意識地維護..."

When to use: When you've used a structural analogy throughout the piece

---

How to choose:

• Technical pieces with broad implications → Pattern C (Poetic Parallelism) or Pattern D (Echo)
• Business/methodology pieces → Pattern B (Reflective Question) or Pattern A (Philosophical Elevation)
• When in doubt → Pattern D if you have a strong opening metaphor, otherwise Pattern C

Avoid:

• Summary conclusions that just repeat what was said
• Weak trailing off without a clear landing
• Introducing new ideas in the conclusion

---

What to Avoid

AI-Generated Writing Tells

Excessive formality:

• ❌ "在此背景下", "基於以上分析"
• ✅ "也因此", "既然如此", "實際上"

Lifeless abstraction:

• ❌ "實現價值最大化"
• ✅ "創造高價值"

Redundant emphasis:

• ❌ "非常重要的關鍵點"
• ✅ "關鍵點" or just make the point

Over-hedging:

• ❌ "可能在某種程度上具有一定的參考價值"
• ✅ "有參考價值" or state the limits clearly

Generic technical writing:

• ❌ "這個方法有很多優點"
• ✅ List specific benefits with concrete examples

---

Structural Pitfalls

Avoid:

• Starting sections with definitions unless the definition itself challenges assumptions
• Ending with summary paragraphs that just repeat what was said
• Topic sentences that announce what the paragraph will do
• Gratuitous subheadings that break natural flow
• Code examples without context or explanation

---

Tonal Mistakes

Don't:

• Preach or moralize
• Use corporate buzzwords uncritically
• Adopt a distant, academic tone
• Sound apologetic when making bold but well-supported claims
• Over-explain code that should be self-evident to the target audience

---

Quality Checklist

Before finalizing any piece, verify:

1. Opening: Does it start with a concrete scene or provocative claim, not theory?
2. Flow: Do paragraphs connect through logic, not mechanical transitions?
3. Voice: Does it sound like a smart person talking, not a formal report?
4. Specificity: Are examples concrete enough to be memorable?
5. Punctuation: Are commas used to create rhythm, not just grammatical obligation?
6. Challenge: Does it question at least one common assumption?
7. Utility: Will the reader have a new mental model or actionable insight?
8. Code (if applicable): Are code examples executable, contextualized, and focused?
9. Conclusion: Does it land with impact rather than trail off?

---

Document-Type Specific Guidance (NEW in v2.0)

For Technical Writing

Additional requirements:

• Define specialized terms formally when they're central to the argument
• Use code examples that are executable and minimal
• Follow the "problem → code → explanation" pattern
• Balance technical precision with accessibility
• Explain why technical choices matter, not just what they are

Can be more flexible with:

• Use of numbered lists (diagnostic checklists are fine)
• Formal definitions (when precision matters)
• Technical terminology (assume educated audience)

---

For Business/Methodology Writing

Additional requirements:

• Use concrete numbers and names when possible
• Challenge common practices with evidence
• Provide actionable frameworks
• Balance idealism with pragmatism

Can be more flexible with:

• Personal anecdotes (more frequent)
• Rhetorical questions (to guide decision-making)
• Direct advice ("你應該...")

---

For Philosophical/Epistemological Writing

Additional requirements:

• Build from concrete examples to abstract principles
• Use analogies to make abstract concepts tangible
• Challenge conventional categories or classifications
• End with broader implications for thinking or practice

Can be more flexible with:

• Abstract vocabulary (when necessary)
• Extended analogies (when they carry weight)
• Longer build-up before revealing the point

---

Adaptation for AI Use

When providing feedback on drafts:

1. Check for authenticity: Flag prose that sounds generic or "AI-like"
2. Evaluate structure: Confirm the piece follows concrete-to-abstract pattern
3. Test claims: Ensure assertions are backed by mechanism or evidence
4. Verify tone: Confirm the voice is conversational authority, not academic distance
5. Assess specificity: Push for more concrete examples if the piece feels abstract
6. Code quality (if technical): Verify code is executable and well-contextualized
7. Opening power: Ensure the opening story has a genuine "twist" that disrupts assumptions
8. Conclusion impact: Check that the ending lands with one of the established patterns

---

When revising based on this guide:

• Don't mechanically apply every rule—use judgment
• Do prioritize voice and structure over individual word choices
• Focus on eliminating AI tells and restoring natural rhythm
• Remember the goal is reader transformation, not information delivery
• For technical pieces: Balance precision with accessibility
• For code: Show, don't just tell—let executable examples do the teaching

---

When AI generates new content:

High-risk areas to watch:

• Opening stories (AI often creates generic scenarios)
• Code examples (AI may produce non-idiomatic or overly complex code)
• Conclusions (AI tends to summarize rather than elevate)
• Analogies (AI may extend metaphors beyond their useful range)

Medium-risk areas:

• Transitions (watch for mechanical "首先其次")
• Technical explanations (watch for over-explanation)
• Lists (watch for keyword-only items without substance)

Lower-risk areas:

• Sentence rhythm (easier to fix in revision)
• Punctuation (mechanical issue)
• Terminology consistency (straightforward to check)

---

Meta-Principles

1. Truth over style: If clarity requires breaking a style rule, break it
2. Rhythm matters: Read aloud to check flow (especially true for Chinese prose)
3. Respect the reader: Assume intelligence, reward attention
4. Earn the abstraction: Concrete before abstract, always
5. Challenge productively: Question assumptions to build better frameworks, not just to provoke
6. Code teaches: In technical writing, good code examples are worth a thousand words
7. Land the conclusion: Don't trail off—end with impact using one of the established patterns

---

Version History

v1.0: Based on ch0 (debugging/epistemology) and ch1 (boutique consulting)

• Established core philosophy and narrative patterns
• Defined voice, tone, and structural elements
• Created AI-detection guidelines

v2.0: Added Interactive Development (technical writing)

• New: Structural analogy vs. point-of-illustration analogy distinction
• New: Code integration patterns and technical writing guidelines
• New: Diagnostic checklist enumeration pattern
• New: Four conclusion techniques (philosophical, reflective, poetic parallelism, echo)
• New: Document-type specific guidance
• Expanded: Role of formal definitions in technical contexts
• Refined: Examples now span business, philosophy, and technical domains

---

This guide is a tool, not a rulebook. Use it to evaluate and improve writing while maintaining the essential quality: authentic expertise communicated with clarity, confidence, and rhythm.

prompt

請根據 WRITING_STYLE_GUIDE_v2.md 評估這篇草稿。

這篇是 [技術文/商業文/哲學文]，請特別注意：
- [根據文體選擇重點]

風格名稱

論證式實用主義 (Argumentative Pragmatism)

核心寫作 DNA

1. 「為什麼」優先於「是什麼」
2. 設置預期再打破
3. 從具體到抽象
4. 質疑權威/常識

已經定下的部分

✅ 核心 DNA（思考路徑、價值觀、敘事策略）
✅ 開場策略（故事 → 抽象）
✅ 論證邏輯（證據 → 推論 → 意涵）
✅ 功能詞使用（然而、也因此、實際上）

還在演化的（50-70% 穩定）：

🔄 結尾技巧（還在探索不同方法）
🔄 幽默的使用（機智 vs 荒誕，還在調整）
🔄 文體彈性（成人 vs 兒童，還在拓展）