Code Formatter 更新: 複製CODE及HTML預覽

以下內容基於原文所描述的 Live Writer 外掛「Code Formatter」更新，聚焦兩大功能：Copy Code 與 HTML Preview，延伸並結構化 16 個具教學價值的實戰解決方案案例。每一案均以實作導向呈現，便於課程、專案與評測使用。

Case #1: 為文章程式碼區塊加入一鍵複製（Copy Code）

Problem Statement（問題陳述）

業務場景：技術部落格文章常包含大量範例程式碼。讀者若要複製，必須手動框選、避開行號與額外標記，容易誤選或漏掉行首縮排，且在手機上更不便。作者參考 MSDN 的 Copy Code 體驗，期望在貼文中提供一鍵複製。技術挑戰：瀏覽器剪貼簿權限限制、跨瀏覽器支援、避免把語法高亮的 HTML 標籤一併複製。影響範圍：讀者操作成本高、複製錯誤率高、降低文章實用性與分享轉換。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

缺少複製按鈕：文章頁面未提供「一鍵複製」的互動元素與事件。
剪貼簿 API 限制：未處理 navigator.clipboard 權限與 HTTPS 限制。
內容取得錯誤：使用 innerHTML 取得內容，導致複製到語法標籤而非純文字。

深層原因：

架構層面：外掛產生的 HTML 未包含結構化容器與可定位目標。
技術層面：未導入漸進式增強（clipboard API + fallback）策略。
流程層面：無跨瀏覽器測試與回退方案，讀者體驗未被納入發佈流程。

Solution Design（解決方案設計）

解決策略：在外掛發佈階段自動為每個程式碼區塊包裝容器與 Copy 按鈕，前端以 navigator.clipboard 實作主要路徑，並提供 execCommand 及手動選取的回退，確保不同瀏覽器與環境皆可複製純文字內容。

實施步驟：

注入標記與唯一識別
- 實作細節：每個 <pre> 包裝一層 .code-block，附上 data-target 與唯一 id。
- 所需資源：外掛（.NET/C#）內容過濾器
- 預估時間：4 小時
前端複製邏輯與回退
- 實作細節：navigator.clipboard -> execCommand -> 手動選取三段式回退；複製 textContent。
- 所需資源：原生 JS
- 預估時間：3 小時
視覺與可用性
- 實作細節：提供按鈕樣式、成功/失敗提示，避免誤觸。
- 所需資源：CSS、少量 JS
- 預估時間：2 小時

關鍵程式碼/設定：

<pre class="code-block" id="code-1">
  <code>// sample code line 1
int x = 1;</code>
</pre>
<button class="copy-btn" data-target="#code-1" aria-label="複製程式碼">Copy Code</button>

<script>
async function copyText(text) {
  // 1) 現代 API
  if (navigator.clipboard?.writeText) {
    await navigator.clipboard.writeText(text);
    return true;
  }
  // 2) 回退：execCommand
  const ta = document.createElement('textarea');
  ta.value = text;
  ta.style.position = 'fixed';
  ta.style.opacity = '0';
  document.body.appendChild(ta);
  ta.focus(); ta.select();
  const ok = document.execCommand('copy');
  document.body.removeChild(ta);
  return ok;
}

document.addEventListener('click', async (e) => {
  const btn = e.target.closest('.copy-btn');
  if (!btn) return;
  const target = document.querySelector(btn.dataset.target);
  const text = target?.textContent ?? '';
  try {
    const ok = await copyText(text);
    btn.textContent = ok ? 'Copied!' : 'Copy Failed';
    setTimeout(() => btn.textContent = 'Copy Code', 1500);
  } catch {
    btn.textContent = 'Copy Failed';
    setTimeout(() => btn.textContent = 'Copy Code', 1500);
  }
});
</script>

實際案例：文章中指出參考 MSDN 的「COPY CODE」體驗，將此功能加到貼文程式碼區塊。實作環境：前端（原生 JS+CSS），後端為 Live Writer 外掛產生 HTML，部落格平台（如 WordPress）。實測數據：改善前：讀者需手動框選與複製（2-3 步驟），易誤選。改善後：一鍵複製（1 步驟），並提供成功提示。改善幅度：步驟數由 2-3 降至 1（定性；作者未提供量化數據）。

Learning Points（學習要點）核心知識點：

navigator.clipboard 與 execCommand 的相容性與權限
使用 textContent 取得純文字而非 innerHTML
漸進式增強與回退策略設計

技能要求：

必備技能：HTML 結構化、原生 JS 事件處理、基本 CSS
進階技能：相容性策略設計、使用者回饋與無障礙屬性

延伸思考：

能否支援「複製帶行號/不帶行號」的切換？
HTTP 網站的權限限制與安全風險？
是否應記錄使用次數以評估成效？

Practice Exercise（練習題）

基礎練習：在現有頁面為單一 <pre> 加上複製按鈕（30 分鐘）
進階練習：支援多個區塊、唯一 id、自動提示（2 小時）
專案練習：將功能包成可重用元件並撰寫相容性測試（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：可在多瀏覽器一鍵複製並提供回饋
程式碼品質（30%）：模組化、易維護、語意化標記
效能優化（20%）：大量內容仍能即時回應
創新性（10%）：提供可配置選項（例如：是否含行號） ```

Case #2: 同步產出 HTML 原始碼與即時預覽（HTML Preview）

Problem Statement（問題陳述）

業務場景：撰寫 HTML 教學時，作者同時需要「展示原始碼」與「展示渲染結果」。過去需在編輯器切換到 HTML 模式，貼兩次相同內容，耗時且易不同步。技術挑戰：如何由單一來源同時生成可見的原始碼（需轉義）與可視預覽（需安全渲染）。影響範圍：作者工作量、貼文一致性、讀者理解效率。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

缺少自動化：外掛未將一段 HTML 同步生成兩種呈現。
易不同步：雙貼維護成本高，修正易漏。
安全風險：直接 innerHTML 可能執行不安全內容。

深層原因：

架構層面：未在發佈流程中加入內容轉換與安全渲染步驟。
技術層面：缺少 HTML 轉義與白名單渲染策略。
流程層面：依賴人工貼兩次，無機制保證一致性。

Solution Design（解決方案設計）

解決策略：在發佈階段偵測「html」語言的程式碼區塊，生成兩部分：1) 轉義後放入 <pre>；2) 經過淨化的可視預覽容器，並以樣式與邊框區隔。

實施步驟：

偵測與轉換
- 實作細節：偵測 ```html 區塊，對內容做 HTML 轉義與同步複製到預覽容器。
- 所需資源：外掛文字處理（.NET/C#）、或前端腳本
- 預估時間：4 小時
安全渲染與樣式
- 實作細節：使用白名單或 DOMPurify 淨化；以 .html-preview 包裹。
- 所需資源：DOMPurify（可選）、CSS
- 預估時間：3 小時

關鍵程式碼/設定：

<div class="html-sample">
  <pre><code class="lang-html">&lt;h3&gt;這是H3的效果&lt;/h3&gt;</code></pre>
  <div class="html-preview" aria-label="HTML 預覽"></div>
</div>

<script>
// 簡化示意：實務建議導入 DOMPurify
function sanitizeBasic(html) {
  return html.replace(/<script[\s\S]*?>[\s\S]*?<\/script>/gi, '');
}

document.querySelectorAll('.html-sample').forEach(box => {
  const code = box.querySelector('code').textContent;
  box.querySelector('.html-preview').innerHTML = sanitizeBasic(code);
});
</script>

<style>
.html-sample { border:1px solid #ddd; padding:8px; margin:12px 0; }
.html-sample .html-preview { border:1px solid #aaa; padding:8px; margin-top:8px; }
</style>

實際案例：原文示範以 div style=”border:1px solid” 包裹 h3 預覽，達到同頁展示原碼與渲染效果。實作環境：Live Writer 外掛產出 HTML；前端 JS 完成渲染；平台如 WordPress。實測數據：改善前：作者需切換模式並貼兩次相同 HTML。改善後：由單一來源自動產生兩種視圖，一次完成。改善幅度：操作步驟由 2 次貼上降為 1 次（定性）。

Learning Points（學習要點）核心知識點：

HTML 轉義與渲染的雙表示
內容安全策略（XSS 基礎）
以容器區隔樣式與語意

技能要求：

必備技能：字串處理、基本 DOM 操作
進階技能：DOMPurify 等淨化工具運用

延伸思考：

如何支援多段預覽與互斥顯示（折疊/展開）？
在無 JS 環境如何降級呈現？
是否需要支援 iframe 隔離？

Practice Exercise（練習題）

基礎練習：將一段 ```html 轉成原碼 + 預覽（30 分鐘）
進階練習：加入 DOMPurify 並提供顯示/隱藏切換（2 小時）
專案練習：做成 Live Writer/Markdown 外掛（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：可同步產生、樣式分離、安全渲染
程式碼品質（30%）：模組化、可測試
效能優化（20%）：多段內容載入順暢
創新性（10%）：支援多種預覽樣式 ```

Case #3: 防止 HTML 原始碼被瀏覽器誤解析

Problem Statement（問題陳述）

業務場景：在教學文中展示 HTML 原始碼時，若未轉義，瀏覽器會直接渲染，導致讀者看不到「原始碼」，而是看到結果。技術挑戰：正確且高效地將 < 與 > 等字元轉換成 HTML 實體；同時保留縮排與換行。影響範圍：讀者無法學到正確的標記寫法；文章可信度與可讀性下降。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

未進行 HTML 實體轉義。
使用 innerHTML 填充程式碼區塊而非 textContent。
未用 <pre> 或 white-space 保留空白與換行。

深層原因：

架構層面：缺少統一的轉義工具或函式。
技術層面：對 DOM API 的內容差異（innerHTML vs textContent）認知不足。
流程層面：缺少內容輸出前的驗證步驟。

Solution Design（解決方案設計）

解決策略：建立通用的 escapeHTML 函式，所有展示原始碼的路徑都走 textContent 或轉義後 innerHTML；使用 <pre> 與 CSS white-space: pre 控制格式。

實施步驟：

建立與封裝轉義函式
- 實作細節：統一提供 escapeHTML，覆用於所有輸出。
- 所需資源：JS 模組或後端工具
- 預估時間：1 小時
調整標記與樣式
- 實作細節：以 <pre> 呈現；CSS 指定 monospaced 字型與 white-space。
- 所需資源：CSS
- 預估時間：1 小時

關鍵程式碼/設定：

<pre><code id="html-code"></code></pre>
<script>
function escapeHTML(s) {
  return s.replaceAll('&', '&amp;')
          .replaceAll('<', '&lt;')
          .replaceAll('>', '&gt;');
}
const raw = '<h3>這是H3</h3>';
document.getElementById('html-code').innerHTML = escapeHTML(raw);
</script>
<style>
pre code { white-space: pre; font-family: ui-monospace, SFMono-Regular, Menlo, monospace; }
</style>

實際案例：原文 HTML 測試段落同時展示原碼與預覽，需確保原碼區塊已被正確轉義。實作環境：前端 JS/CSS；外掛輸出 HTML。實測數據：未提供（定性改善：預期誤渲染率趨近 0）。

Learning Points（學習要點）核心知識點：

innerHTML vs textContent 差異
HTML 實體轉義
使用 <pre> 與 CSS 控制空白

技能要求：

必備技能：基本 DOM 與 CSS
進階技能：建立通用工具模組

延伸思考：

若內容中包含反引號、實體嵌套如何處理？
是否需支援多語言轉義規則？

Practice Exercise（練習題）

基礎：將三段 HTML 字串正確轉義輸出（30 分鐘）
進階：撰寫單元測試涵蓋特殊字元（2 小時）
專案：封裝為 NPM/內部工具並應用於專案（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：所有特殊字元正確轉義
程式碼品質（30%）：簡潔可測試
效能優化（20%）：大文本轉義效能
創新性（10%）：API 設計友好 ```

Case #4: 保留並正規化程式碼縮排（使用示例 CountLeadingSpaces）

Problem Statement（問題陳述）

業務場景：貼文中的程式碼來自不同 IDE/貼上來源，常見不一致的左側縮排，影響閱讀。需要保留必要縮排又避免整段多餘空格。技術挑戰：辨識每行共同前置空白並移除，保留語意縮排；同時不破壞原始對齊。影響範圍：可讀性與複製後在 IDE 的貼上品質。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

不同來源的貼上縮排不一致。
沒有在發佈前自動正規化縮排。

 預設保留所有空白，等於保留多餘縮排。

深層原因：

架構層面：外掛缺少縮排正規化步驟。
技術層面：未計算最小共同縮排。
流程層面：依賴作者手動調整。

Solution Design（解決方案設計）

解決策略：在外掛中以行為單位掃描，計算最小前置空白，統一左移該空白數；保留語意縮排，輸出到 <pre>。

實施步驟：

計算共同縮排
- 實作細節：忽略空白行，計算最小 CountLeadingSpaces。
- 所需資源：C# 字串處理
- 預估時間：2 小時
重新組裝程式碼
- 實作細節：每行去除共同縮排；保留換行。
- 所需資源：外掛程式
- 預估時間：1 小時

關鍵程式碼/設定：

int CountLeadingSpaces(string line)
{
    int count = 0;
    foreach (char ch in line)
    {
        if (ch == ' ') count++; else break;
    }
    return count;
}

string NormalizeIndentation(string code)
{
    var lines = code.Replace("\r\n", "\n").Split('\n');
    int min = int.MaxValue;
    foreach (var l in lines)
    {
        if (string.IsNullOrWhiteSpace(l)) continue;
        int c = CountLeadingSpaces(l);
        if (c < min) min = c;
    }
    if (min == int.MaxValue) min = 0;
    for (int i = 0; i < lines.Length; i++)
    {
        var l = lines[i];
        lines[i] = l.Length >= min ? l.Substring(min) : l;
    }
    return string.Join("\n", lines);
}

實際案例：文中 C# CountLeadingSpaces 作為示例，用於縮排處理的模型程式。實作環境：.NET（外掛端）、輸出 HTML 前處理。實測數據：未提供（定性：貼文縮排整齊，複製至 IDE 貼上更一致）。

Learning Points（學習要點）核心知識點：

共同縮排計算
跨平台換行正規化（CRLF/LF）
輸出前處理流程

技能要求：

必備技能：C# 字串處理
進階技能：文本規則與邊界條件處理

延伸思考：

Tab 與空白混用如何處理？
是否提供保留原樣的選項？

Practice Exercise（練習題）

基礎：實作 NormalizeIndentation 並撰寫測試（30 分鐘）
進階：支援 tab=4/2 自訂換算（2 小時）
專案：整合至外掛產線並加上設定面板（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：各種縮排情境正確
程式碼品質（30%）：測試覆蓋邊界案例
效能優化（20%）：長檔案處理時間
創新性（10%）：彈性設定 ```

Case #5: 統一程式碼區塊的視覺樣式（加框與底色）

Problem Statement（問題陳述）

業務場景：外掛早期版本僅「加個框」，視覺上與網站版差異不大，但缺乏一致性與可讀性提升（字型、行高、捲動等）。技術挑戰：制定跨主題通用的程式碼樣式，不影響網站其他元素。影響範圍：可讀性、行長控制、讀者視覺負擔。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

樣式不一致，易受主題 CSS 影響。
未限制最大高度導致頁面過長。
字型與行高未特別設定。

深層原因：

架構層面：缺乏獨立命名空間的樣式。
技術層面：未使用 monospace 與 white-space 控制。
流程層面：未將樣式設計納入外掛輸出。

Solution Design（解決方案設計）

解決策略：定義 .code-block 樣式命名空間，設定背景、邊框、字型、行高、內距與水平捲動；限制高度並顯示捲軸。

實施步驟：

樣式設計與命名空間
- 實作細節：.code-block 下的 pre, code 都套用一致樣式。
- 所需資源：CSS
- 預估時間：1 小時
滾動與長行控制
- 實作細節：overflow auto；white-space: pre。
- 所需資源：CSS
- 預估時間：1 小時

關鍵程式碼/設定：

.code-block {
  border: 1px solid #e0e0e0;
  background: #f8f9fa;
  padding: 8px 12px;
  margin: 12px 0;
}
.code-block pre {
  margin: 0;
  max-height: 420px;
  overflow: auto;
}
.code-block code {
  font-family: ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
  font-size: 0.95rem;
  line-height: 1.5;
  white-space: pre;
}

實際案例：原文提及「加個框」，本方案將其擴充為一致風格套件。實作環境：前端 CSS；外掛輸出添加 .code-block 容器。實測數據：未提供（定性：閱讀舒適度提升）。

Learning Points（學習要點）核心知識點：

命名空間隔離樣式
monospace 與 white-space 的選擇
長內容滾動設計

技能要求：

必備技能：CSS 基礎
進階技能：跨主題相容

延伸思考：

暗色主題支援？
列印樣式優化？

Practice Exercise（練習題）

基礎：為現有 <pre> 套用樣式（30 分鐘）
進階：加入亮/暗主題切換（2 小時）
專案：封裝為可發佈的 CSS 模組（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：常見主題下樣式穩定
程式碼品質（30%）：可維護與覆用
效能優化（20%）：樣式最小化
創新性（10%）：主題化能力 ```

Case #6: 跨瀏覽器與大段文本的剪貼簿可靠性

Problem Statement（問題陳述）

業務場景：程式碼可能很長，讀者於不同瀏覽器/裝置（含行動端）複製，有時會失敗或延遲。技術挑戰：統一處理不同 API、權限提示、長文本效能與使用者回饋。影響範圍：複製成功率與整體使用體驗。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

僅使用單一路徑（如 execCommand）而缺少回退。
未處理 HTTPS/權限限制導致拒絕。
長文本同步操作造成 UI 卡頓。

深層原因：

架構層面：缺乏可復用的 copy 模組。
技術層面：不了解剪貼簿權限模型。
流程層面：未在多瀏覽器與裝置測試。

Solution Design（解決方案設計）

解決策略：封裝 async copy 模組（優先 clipboard.writeText），在拒絕時回退 execCommand，再回退為手動選取並高亮；加上 loading/成功提示。

實施步驟：

寫入模組化函式
- 實作細節：Promise-based，集中處理錯誤與回饋。
- 所需資源：JS
- 預估時間：2 小時
使用者回饋與長文本優化
- 實作細節：按鈕 pending 狀態、成功提示；長文本使用 requestIdleCallback（可選）。
- 所需資源：JS/CSS
- 預估時間：2 小時

關鍵程式碼/設定：

async function safeCopy(selector) {
  const node = document.querySelector(selector);
  const text = node?.textContent ?? '';
  try { await navigator.clipboard.writeText(text); return 'ok'; }
  catch {
    try {
      const ta = document.createElement('textarea');
      ta.value = text; document.body.appendChild(ta);
      ta.select(); document.execCommand('copy');
      document.body.removeChild(ta);
      return 'ok';
    } catch { 
      // fallback: 手動選取
      const range = document.createRange();
      range.selectNodeContents(node);
      const sel = window.getSelection();
      sel.removeAllRanges(); sel.addRange(range);
      return 'manual';
    }
  }
}

實際案例：支援 Copy Code 體驗在更多環境下穩定運作。實作環境：前端 JS；跨瀏覽器測試。實測數據：未提供（定性：失敗率下降、回退可用）。

Learning Points（學習要點）核心知識點：

Async API 與回退
權限/HTTPS 限制
使用者回饋設計

技能要求：

必備技能：Promise/async JS
進階技能：效能與體驗優化

延伸思考：

是否記錄失敗並上報以改善？
在 PWA/離線情境的表現？

Practice Exercise（練習題）

基礎：整合 safeCopy 到按鈕事件（30 分鐘）
進階：加入 pending/成功/失敗 UI（2 小時）
專案：打造可發佈的 clipboard 工具庫（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：多瀏覽器成功率
程式碼品質（30%）：封裝與測試
效能優化（20%）：大文本不卡頓
創新性（10%）：指標監測 ```

Case #7: 非 HTTPS 環境的剪貼簿權限與降級策略

Problem Statement（問題陳述）

業務場景：舊站或個人部落格可能仍為 HTTP，導致 Clipboard API 無法使用。技術挑戰：在不變更基礎設施的前提下，提供可用的降級體驗。影響範圍：複製功能不可用，讀者體驗下降。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

navigator.clipboard 需 HTTPS。
未提供回退方案。
使用者不知原因（缺乏提示）。

深層原因：

架構層面：站點未升級 HTTPS。
技術層面：未實作回退。
流程層面：缺少環境偵測與提示。

Solution Design（解決方案設計）

解決策略：檢查 location.protocol，若非 https，直接走 execCommand 或手動選取，並提示升級 HTTPS 的好處與連結說明。

實施步驟：

環境偵測與切換
- 實作細節：runtime 判斷協定，切換路徑。
- 所需資源：JS
- 預估時間：0.5 小時
使用者教育提示
- 實作細節：顯示浮層告知「已使用相容模式」，建議升級 HTTPS。
- 所需資源：JS/CSS
- 預估時間：1 小時

關鍵程式碼/設定：

const secure = location.protocol === 'https:';
async function copySmart(text) {
  if (secure && navigator.clipboard?.writeText) return navigator.clipboard.writeText(text);
  // fallback path
  const ta = document.createElement('textarea');
  ta.value = text; document.body.appendChild(ta);
  ta.select(); document.execCommand('copy'); document.body.removeChild(ta);
}

實際案例：提升 Copy Code 在 HTTP 站的可用性。實作環境：前端 JS。實測數據：未提供（定性：功能可用性提升）。

Learning Points（學習要點）核心知識點：

安全上下文概念
回退設計與提示

技能要求：

必備技能：JS 基礎
進階技能：產品化提示與 A/B

延伸思考：

是否導入 Service Worker 與 HTTPS 一併規劃？
對 SEO 與安全的影響？

Practice Exercise（練習題）

基礎：加入協定偵測切換（30 分鐘）
進階：製作非安全上下文提示（2 小時）
專案：協助站點完成 HTTPS 遷移計畫（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：HTTP 也可複製
程式碼品質（30%）：降級清晰
效能優化（20%）：提示不干擾
創新性（10%）：教育性內容 ```

Case #8: 外掛產線設計：發佈時自動插入 Copy/Preview 標記

Problem Statement（問題陳述）

業務場景：作者希望「一次貼上」就能自動擁有 Copy 按鈕與 HTML 預覽，而非手動插入 HTML。技術挑戰：在 Live Writer 的發佈管線中偵測程式碼區塊，產生對應標記與唯一 id。影響範圍：作者編輯效率、內容一致性。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

外掛僅輸出基本框線，未插入互動標記。
沒有內容轉換器處理 ``` 語法或 <pre>。
缺少 id 與 data 屬性以供 JS 掛載。

深層原因：

架構層面：外掛無中介層處理內容。
技術層面：未建立正則/解析器。
流程層面：作者需手動維護標記。

Solution Design（解決方案設計）

解決策略：在發佈事件中，掃描內容，將程式碼區塊以 .code-block 包裹，附帶唯一 id 與 copy 按鈕；對 html 類型則加上 .html-preview 容器。

實施步驟：

內容解析與轉換
- 實作細節：使用 Regex 或 Markdown 解析器產生 HTML。
- 所需資源：.NET/C#
- 預估時間：5 小時
唯一 id 與按鈕注入
- 實作細節：以遞增計數器生成 id；插入按鈕與 data-target。
- 所需資源：.NET/C#
- 預估時間：2 小時

關鍵程式碼/設定：

var codeCount = 0;
string TransformCodeBlock(string html)
{
    // 簡化示意：尋找 <pre><code class="lang-xxx">...</code></pre>
    return Regex.Replace(html,
        @"<pre>\s*<code(?: class=""([^""]+)"")?>([\s\S]*?)</code>\s*</pre>",
        m => {
            var lang = m.Groups[1].Value; var content = m.Groups[2].Value;
            var id = $"code-{++codeCount}";
            var btn = $"<button class=\"copy-btn\" data-target=\"#{id}\">Copy Code</button>";
            var preview = lang.Contains("html") ? "<div class=\"html-preview\"></div>" : "";
            return $"<div class=\"code-block\"><pre id=\"{id}\"><code class=\"{lang}\">{content}</code></pre>{btn}{preview}</div>";
        }, RegexOptions.IgnoreCase);
}

實際案例：原文外掛「一次到位」展現 HTML 原碼與預覽意圖，對應此產線設計。實作環境：.NET（Live Writer 外掛）、Regex 或解析器。實測數據：未提供（定性：作者不再手動插入標記）。

Learning Points（學習要點）核心知識點：

內容處理管線與正則解析
唯一 id 生成策略
產生可掛載的 data-* 屬性

技能要求：

必備技能：C#、Regex
進階技能：解析器/AST 思維

延伸思考：

是否使用真正的 Markdown 解析器以提升穩定性？
如何避免與 CMS 二次過濾衝突？

Practice Exercise（練習題）

基礎：以 Regex 包裝 code block（30 分鐘）
進階：支援 ``` 語法與多語言（2 小時）
專案：完成 Live Writer 外掛的發佈鉤子（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：能自動注入所需標記
程式碼品質（30%）：穩定與易維護
效能優化（20%）：大文章處理速度
創新性（10%）：可配置與擴充 ```

Case #9: HTML 預覽的樣式干擾與隔離

Problem Statement（問題陳述）

業務場景：預覽區的 h3、p 等標籤容易被主題 CSS 改寫，顯示與預期不符。技術挑戰：既要顯示真實渲染，又要避免全站 CSS 汙染。影響範圍：教學準確性與讀者理解。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

CSS 全局影響，預覽區缺乏命名空間。
未使用隔離容器或 iframe。
樣式衝突未檢測。

深層原因：

架構層面：樣式無範疇限定。
技術層面：缺少隔離策略（BEM/Scope/iframe）。
流程層面：未在不同主題測試。

Solution Design（解決方案設計）

解決策略：以 .html-preview 容器加上 CSS scopes；必要時使用 sandboxed iframe 將預覽內容隔離，確保不受外部 CSS 影響。

實施步驟：

Scope 樣式
- 實作細節：.html-preview h3 { … }，僅限容器。
- 所需資源：CSS
- 預估時間：1 小時
iframe 隔離（可選）
- 實作細節：以 srcdoc 或動態注入，禁用腳本。
- 所需資源：前端 JS
- 預估時間：3 小時

關鍵程式碼/設定：

<div class="html-preview" aria-label="HTML 預覽"></div>
<style>
.html-preview h1,.html-preview h2,.html-preview h3 { margin: .5em 0; font-weight:600; }
.html-preview { border:1px solid #999; padding:8px; }
</style>

實際案例：原文以 div + border 呈現預覽，這裡更進一步做樣式隔離。實作環境：前端 CSS/JS。實測數據：未提供（定性：不同主題下呈現穩定）。

Learning Points（學習要點）核心知識點：

CSS 範疇化
iframe 隔離 trade-off
ARIA 區域標記

技能要求：

必備技能：CSS
進階技能：iframe 安全/效能考量

延伸思考：

SSR 預覽 vs 前端注入？
CodePen/JSFiddle 嵌入作為替代？

Practice Exercise（練習題）

基礎：為預覽加 scope 樣式（30 分鐘）
進階：以 iframe 隔離並比較差異（2 小時）
專案：做成可配置的隔離策略（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：樣式不被污染
程式碼品質（30%）：清晰可維護
效能優化（20%）：iframe 開銷可控
創新性（10%）：策略可配置 ```

Case #10: HTML 預覽安全淨化（防 XSS）

Problem Statement（問題陳述）

業務場景：將貼文中的 HTML 作為預覽插入頁面，若包含 script/event handler，可能執行惡意內容。技術挑戰：在不破壞教學內容的前提下，過濾危險標籤/屬性。影響範圍：網站安全、讀者安全與信任。複雜度評級：高

Root Cause Analysis（根因分析）

直接原因：

直接 innerHTML 注入未經過濾。
未限制事件屬性（on*）與 JS 協定（javascript:）。
無白名單策略。

深層原因：

架構層面：缺乏安全層。
技術層面：對 DOM XSS 防護認知不足。
流程層面：缺少安全審查與測試。

Solution Design（解決方案設計）

解決策略：導入 DOMPurify 等成熟淨化庫，使用嚴格白名單；或後端淨化，確保預覽容器只渲染安全標籤。

實施步驟：

導入淨化庫
- 實作細節：DOMPurify.sanitize(html,{ ALLOWED_TAGS, ALLOWED_ATTR}).
- 所需資源：DOMPurify
- 預估時間：1 小時
安全測試
- 實作細節：建立常見攻擊案例測試。
- 所需資源：測試腳本
- 預估時間：2 小時

關鍵程式碼/設定：

<script src="https://cdn.jsdelivr.net/npm/dompurify@3.0.6/dist/purify.min.js"></script>
<script>
const clean = DOMPurify.sanitize(userHtml, {
  ALLOWED_TAGS: ['h1','h2','h3','p','div','span','ul','li','a','b','i','strong','em'],
  ALLOWED_ATTR: ['href','title','style']
});
preview.innerHTML = clean;
</script>

實際案例：原文提供 HTML 預覽，安全層是必要延伸。實作環境：前端 JS；可轉為後端處理。實測數據：未提供（定性：降低 XSS 風險）。

Learning Points（學習要點）核心知識點：

XSS 基礎與白名單策略
第三方淨化庫
測試惡意樣本

技能要求：

必備技能：JS、基本安全概念
進階技能：安全測試設計

延伸思考：

是否以 iframe sandbox 實現更強隔離？
白名單維護與升級策略？

Practice Exercise（練習題）

基礎：導入 DOMPurify 並淨化一段 HTML（30 分鐘）
進階：撰寫 10 個 XSS 測案例子並驗證（2 小時）
專案：建立預覽安全中介層（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：危險內容不可執行
程式碼品質（30%）：配置清晰
效能優化（20%）：淨化效能
創新性（10%）：自動化安全測試 ```

Case #11: Copy Code 的無障礙（A11y）最佳化

Problem Statement（問題陳述）

業務場景：視障或鍵盤使用者需能操作 Copy Code；螢幕閱讀器需讀到正確語意。技術挑戰：ARIA 標籤、鍵盤焦點、狀態回饋與可視/不可視提示。影響範圍：法遵、體驗普適性。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

使用充當按鈕或缺少 aria-label。
沒有鍵盤事件（Enter/Space）。
成功訊息未對 assistive tech 可見。

深層原因：

架構層面：未將 A11y 納入元件設計。
技術層面：對 ARIA live region 認知不足。
流程層面：缺少 A11y 測試清單。

Solution Design（解決方案設計）

解決策略：使用

實施步驟：

結構與屬性
- 實作細節：button、aria-label、aria-controls 指向 code 區域。
- 所需資源：HTML
- 預估時間：1 小時
狀態回饋
- 實作細節：aria-live 區塊播報 Copied。
- 所需資源：JS
- 預估時間：1 小時

關鍵程式碼/設定：

<button class="copy-btn" aria-label="複製這段程式碼" aria-controls="code-1">Copy Code</button>
<div class="sr-only" aria-live="polite" id="copy-status"></div>
<script>
function announce(msg){ document.getElementById('copy-status').textContent = msg; }
document.querySelector('.copy-btn').addEventListener('click', async (e)=>{
  // ...copy logic
  announce('已複製到剪貼簿');
});
</script>
<style>.sr-only{position:absolute;left:-9999px;}</style>

實際案例：在 Copy Code 基礎上補齊無障礙支援。實作環境：前端 HTML/JS/CSS。實測數據：未提供（定性：鍵盤操作與 SR 支援）。

Learning Points（學習要點）核心知識點：

原生按鈕優勢
aria-live 使用
鍵盤可達性

技能要求：

必備技能：HTML/ARIA
進階技能：A11y 測試

延伸思考：

國際化（語系）播報文本？
高對比模式樣式？

Practice Exercise（練習題）

基礎：改用 button 並加 aria-label（30 分鐘）
進階：加入 aria-live 與鍵盤測試（2 小時）
專案：A11y 驗收清單與自動化檢測（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：鍵盤/閱讀器可用
程式碼品質（30%）：語意與屬性正確
效能優化（20%）：無多餘重排
創新性（10%）：A11y 指標化 ```

Case #12: 預覽區顯示切換與折疊，減少版面干擾

Problem Statement（問題陳述）

業務場景：同頁大量範例會占據空間，影響閱讀流。需要可折疊的預覽區，預設折疊以節省空間。技術挑戰：在不增加複雜度下，提供穩定的顯示/隱藏切換。影響範圍：閱讀體驗、可掃視性。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

預覽永遠展開。
無折疊控制與狀態記憶。
樣式與互動未規劃。

深層原因：

架構層面：缺乏可選功能控制。
技術層面：未提供簡單的折疊交互。
流程層面：預設配置無法覆蓋不同文章需求。

Solution Design（解決方案設計）

解決策略：為每個 .html-preview 增加「顯示/隱藏」按鈕，預設折疊；必要時持久化折疊狀態（localStorage）。

實施步驟：

標記與控制鈕
- 實作細節：按鈕控制相鄰預覽區展示。
- 所需資源：HTML/JS
- 預估時間：1 小時
狀態記憶（可選）
- 實作細節：以 key 記錄使用者偏好。
- 所需資源：JS
- 預估時間：1 小時

關鍵程式碼/設定：

<button class="toggle-preview" aria-expanded="false">Show Preview</button>
<div class="html-preview" hidden>...rendered...</div>
<script>
document.addEventListener('click', e=>{
  const btn = e.target.closest('.toggle-preview'); if(!btn) return;
  const preview = btn.nextElementSibling;
  const expanded = preview.hasAttribute('hidden');
  if (expanded) { preview.removeAttribute('hidden'); btn.textContent = 'Hide Preview'; btn.setAttribute('aria-expanded','true'); }
  else { preview.setAttribute('hidden',''); btn.textContent = 'Show Preview'; btn.setAttribute('aria-expanded','false'); }
});
</script>

實際案例：原文手動展示預覽，延伸為可折疊提升閱讀流。實作環境：前端 HTML/JS。實測數據：未提供（定性：長文可掃視性提升）。

Learning Points（學習要點）核心知識點：

可發現性與控制
aria-expanded 與 hidden
內容密度管理

技能要求：

必備技能：JS 事件與 DOM
進階技能：狀態持久化

延伸思考：

是否需記住每次展開狀態？
行動端手勢支援？

Practice Exercise（練習題）

基礎：加入預覽折疊（30 分鐘）
進階：狀態持久化（2 小時）
專案：做成可組態的 UI 元件（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：切換穩定
程式碼品質（30%）：語意標記正確
效能優化（20%）：無閃爍
創新性（10%）：狀態同步策略 ```

Case #13: 複製純文字以避免語法高亮 HTML 混入

Problem Statement（問題陳述）

業務場景：若使用語法高亮（加 span 標籤），直接複製 innerHTML 會導致讀者貼上含 HTML 的內容。技術挑戰：在保持頁面高亮的同時，提供「純文字」的複製內容。影響範圍：讀者貼上失敗或污染 IDE。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

取用 innerHTML 而非 textContent。
未儲存原始純文字版本。
高亮庫改寫 DOM。

深層原因：

架構層面：缺少 data-raw 或 Shadow DOM 隔離。
技術層面：對複製來源節點未明確。
流程層面：未在導入高亮時考慮複製行為。

Solution Design（解決方案設計）

解決策略：在產線中保留 data-raw 屬性存原始內容，複製時取 data-raw；或只對 的 textContent 讀取。

實施步驟：

產線保留原文
- 實作細節：在 保留未高亮的原文。
- 所需資源：外掛（.NET/C#）
- 預估時間：2 小時
複製時選對來源
- 實作細節：按鈕 handler 讀 data-raw 優先。
- 所需資源：JS
- 預估時間：1 小時

關鍵程式碼/設定：

<pre class="code-block" id="code-2"><code data-raw="int a=1;&amp;&amp;b==2;"> <span class="kw">int</span> a=1; </code></pre>
<script>
function getCopyText(node){
  return node.getAttribute('data-raw') || node.textContent || '';
}
</script>

實際案例：與 Copy Code 搭配，確保貼上為純文字。實作環境：外掛產線 + 前端 JS。實測數據：未提供（定性：避免 HTML 汙染）。

Learning Points（學習要點）核心知識點：

textContent vs innerHTML
data-* 儲存原值
高亮與複製的權衡

技能要求：

必備技能：DOM 操作
進階技能：外掛與前端協作介面

延伸思考：

是否改用 Shadow DOM 減少污染？
大片段 data-raw 對 DOM 體積影響？

Practice Exercise（練習題）

基礎：改用 textContent 複製（30 分鐘）
進階：產線注入 data-raw 並驗證（2 小時）
專案：高亮庫整合最佳化（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：純文字複製成功
程式碼品質（30%）：耦合度低
效能優化（20%）：DOM 體積控制
創新性（10%）：Shadow DOM 應用 ```

Case #14: 複製前清理尾隨空白與行尾（EOL）統一

Problem Statement（問題陳述）

業務場景：從網頁複製的程式碼帶有尾隨空白或最後多一行，貼到 IDE 觸發 Lint 警告。技術挑戰：複製時不改變語意但移除非必要空白，並統一行尾符號。影響範圍：開發者體驗、Lint 噪音。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

```
 常在最後帶有額外換行。
```
來源混用 CRLF/LF。
部分行尾有尾隨空白。

深層原因：

架構層面：無複製前過濾層。
技術層面：未處理行尾正規化。
流程層面：未納入細節最佳化。

Solution Design（解決方案設計）

解決策略：複製前以函式 normalize：去尾空白、合併多餘結尾換行、EOL 統一為 \n。

實施步驟：

正規化函式
- 實作細節：逐行 rtrim，最後 trimEnd + 轉 LF。
- 所需資源：JS
- 預估時間：0.5 小時
整合複製流程
- 實作細節：在 safeCopy 前套用。
- 所需資源：JS
- 預估時間：0.5 小時

關鍵程式碼/設定：

function normalizeForCopy(text) {
  return text.replace(/\r\n/g, '\n')
             .split('\n')
             .map(l => l.replace(/\s+$/,''))
             .join('\n')
             .replace(/\n+$/,'\n'); // 保留單一行尾
}

實際案例：提升 Copy Code 貼上品質。實作環境：前端 JS。實測數據：未提供（定性：Lint 噪音下降）。

Learning Points（學習要點）核心知識點：

行尾與空白清理
CRLF/LF 差異
貼上品質提升

技能要求：

必備技能：字串處理
進階技能：與 Lint/IDE 規則協作

延伸思考：

是否提供「保留原樣」選項？
特定語言是否需保留尾空白？

Practice Exercise（練習題）

基礎：整合 normalize 到複製流程（30 分鐘）
進階：加入選項開關（2 小時）
專案：做成可配置的清理模組（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：清理正確不破壞語意
程式碼品質（30%）：簡潔與測試
效能優化（20%）：大文本表現
創新性（10%）：可配置度 ```

Case #15: 生成唯一目標識別避免多區塊複製錯位

Problem Statement（問題陳述）

業務場景：一篇文章內有多個程式碼區塊，若使用重複 id 或不穩定選擇器，按下 Copy 可能複製到錯誤區塊。技術挑戰：在產線中保證唯一 id、穩定參照與正確對應。影響範圍：功能正確性、信任度。複雜度評級：低

Root Cause Analysis（根因分析）

直接原因：

硬編碼 id 或未檢查衝突。
使用 querySelector 但選到第一個相符節點。
動態內容插入導致索引偏移。

深層原因：

架構層面：缺少 id 生成器。
技術層面：選擇器策略不當。
流程層面：無自動化檢查。

Solution Design（解決方案設計）

解決策略：外掛維護遞增計數器生成 id；按鈕以 data-target 精準指向；前端透過 dataset 查找。

實施步驟：

唯一 id 生成
- 實作細節：code-1, code-2…；檢查 DOM 是否已存在。
- 所需資源：.NET/C#
- 預估時間：1 小時
精準選取
- 實作細節：data-target=”#code-1” 直接查找。
- 所需資源：HTML/JS
- 預估時間：0.5 小時

關鍵程式碼/設定：

string GenId(int n) => $"code-{n}";

const target = document.querySelector(btn.dataset.target);

實際案例：多段程式碼與多個 Copy 按鈕同頁使用。實作環境：外掛 + 前端。實測數據：未提供（定性：錯誤複製率下降）。

Learning Points（學習要點）核心知識點：

唯一性與選擇器設計
產線與前端契約
防呆與檢查

技能要求：

必備技能：C#/JS
進階技能：測試自動化（DOM 斷言）

延伸思考：

SSR/CSR 混合時 id 穩定性？
設計 data-testid 便於測試？

Practice Exercise（練習題）

基礎：多區塊正確複製（30 分鐘）
進階：新增動態插入情境測試（2 小時）
專案：建立 DOM 測試套件（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：對應正確
程式碼品質（30%）：契約清晰
效能優化（20%）：大頁面穩定
創新性（10%）：測試友好設計 ```

Case #16: 與 CMS/讀者環境相容（RSS/No-JS/AMP）之降級

Problem Statement（問題陳述）

業務場景：RSS 閱讀器、AMP 或關閉 JS 的環境中，Copy/Preview 無法工作或破版。技術挑戰：做到漸進增強，保證在無 JS 情況仍有可用內容。影響範圍：廣泛分發場景下的可用性。複雜度評級：中

Root Cause Analysis（根因分析）

直接原因：

互動功能依賴 JS。
樣式/腳本在 RSS/AMP 被剝除。
無 noscript 降級提示。

深層原因：

架構層面：未設計 Progressive Enhancement。
技術層面：不了解 RSS/AMP 限制。
流程層面：未測 RSS/AMP 呈現。

Solution Design（解決方案設計）

解決策略：預設輸出可讀的 <pre> 與轉義原碼；互動功能以 JS 增強；提供 noscript 提示與「Select All」備援。

實施步驟：

漸進增強標記
- 實作細節：功能不依賴 JS 仍可閱讀原碼。
- 所需資源：HTML
- 預估時間：1 小時
noscript 與備援
- 實作細節：顯示提示，提供一鍵 Select All 指引。
- 所需資源：HTML/JS
- 預估時間：1 小時

關鍵程式碼/設定：

<noscript>此頁已提供原始碼顯示。若需複製，請手動選取或啟用 JavaScript。</noscript>

實際案例：確保 HTML 測試與 Copy Code 在更多閱讀器中仍可被理解。實作環境：前端標記；RSS/AMP 檢視。實測數據：未提供（定性：可用性提升）。

Learning Points（學習要點）核心知識點：

Progressive Enhancement
RSS/AMP 限制
降級用戶教育

技能要求：

必備技能：HTML 基本功
進階技能：多渠道發佈思維

延伸思考：

是否提供「複製」連結直指原始檔（raw）？
AMP 版本的對應策略？

Practice Exercise（練習題）

基礎：加入 noscript 與備援文案（30 分鐘）
進階：RSS/AMP 檢視驗證（2 小時）
專案：建立多渠道發佈檢核表（8 小時）

Assessment Criteria（評估標準）

功能完整性（40%）：無 JS 可讀
程式碼品質（30%）：語意清晰
效能優化（20%）：無多餘資源
創新性（10%）：渠道友好 ```

===================== 案例分類 =====================

按難度分類
- 入門級（適合初學者）：Case 3, 5, 7, 12, 14, 15, 16
- 中級（需要一定基礎）：Case 1, 2, 6, 8, 9, 11, 13
- 高級（需要深厚經驗）：Case 10
按技術領域分類
- 架構設計類：Case 8, 9, 10, 16
- 效能優化類：Case 6, 14
- 整合開發類：Case 1, 2, 5, 7, 11, 12, 13, 15
- 除錯診斷類：Case 3, 6, 9, 14
- 安全防護類：Case 10
按學習目標分類
- 概念理解型：Case 3, 5, 7, 16
- 技能練習型：Case 1, 2, 6, 11, 12, 14, 15
- 問題解決型：Case 8, 9, 13
- 創新應用型：Case 10

===================== 案例關聯圖（學習路徑建議） =====================

建議先學順序（基礎到進階）： 1) Case 3（HTML 轉義基礎）→ 5（程式碼樣式）→ 1（Copy Code 基礎） 2) Case 2（原碼+預覽雙表示）→ 12（預覽折疊）→ 9（樣式隔離） 3) Case 14（複製品質）→ 13（純文字複製）→ 15（唯一 id） 4) Case 6（跨瀏覽器可靠性）→ 7（HTTPS 降級）→ 16（多渠道相容） 5) Case 8（外掛產線整合）→ 10（預覽安全）→ 11（A11y 完善）
依賴關係：
- Case 1 依賴 Case 3（正確取文本）與 Case 15（唯一目標）。
- Case 2 依賴 Case 3（轉義）與 Case 10（安全）。
- Case 6 建立在 Case 1 的複製功能上，補強可靠性。
- Case 9 建立在 Case 2 的預覽機制上，解決樣式干擾。
- Case 8 為整合樞紐，對多數前端案例提供結構支援。
完整學習路徑：
- 基礎篇：Case 3 → 5 → 1
- 預覽篇：Case 2 → 12 → 9
- 複製品質篇：Case 14 → 13 → 15 → 6 → 7 → 16
- 整合與安全篇：Case 8 → 10 → 11
- 最終，能完成一個具備 Copy Code、HTML 安全預覽、可及性、跨環境相容的內容產線與頁面體驗。

說明

原文未提供量化效益數據；本文以定性描述操作步驟與使用體驗改善方向。
範例程式包含 C#（外掛產線）與前端 HTML/JS/CSS（頁面互動），對應原文 Live Writer 外掛與網頁呈現的雙面向。

Code Formatter 更新: 複製CODE及HTML預覽

Case #1: 為文章程式碼區塊加入一鍵複製（Copy Code）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #2: 同步產出 HTML 原始碼與即時預覽（HTML Preview）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #3: 防止 HTML 原始碼被瀏覽器誤解析

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #4: 保留並正規化程式碼縮排（使用示例 CountLeadingSpaces）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #5: 統一程式碼區塊的視覺樣式（加框與底色）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #6: 跨瀏覽器與大段文本的剪貼簿可靠性

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #7: 非 HTTPS 環境的剪貼簿權限與降級策略

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #8: 外掛產線設計：發佈時自動插入 Copy/Preview 標記

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #9: HTML 預覽的樣式干擾與隔離

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #10: HTML 預覽安全淨化（防 XSS）

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #11: Copy Code 的無障礙（A11y）最佳化

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #12: 預覽區顯示切換與折疊，減少版面干擾

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #13: 複製純文字以避免語法高亮 HTML 混入

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #14: 複製前清理尾隨空白與行尾（EOL）統一

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #15: 生成唯一目標識別避免多區塊複製錯位

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Case #16: 與 CMS/讀者環境相容（RSS/No-JS/AMP）之降級

Problem Statement（問題陳述）

Root Cause Analysis（根因分析）

Solution Design（解決方案設計）

Facebook Pages

AI Synthesis Contents

Edit Post (Pull Request)

Post Directory