EpoCanvas 內容密度規範：字數估算、平均篇幅與四級閾值

完整解釋 EpoCanvas 目前字數估算演算法、四捨五入順序、全站平均篇幅、四級內容密度閾值、預計閱讀時間及品質評價邊界。

版本 v1.1.1 发表于 10/17/26 更新于 10/18/26

全站內容密度分級與度量規範

EES-003 平均篇幅 非質量認證

本站沿用“內容密度”這一介面名稱，但當前演算法實際度量的是文章平均篇幅。它能夠反映整體文本規模，不能自動證明語義資訊量、技術正確性或內容價值。

[!IMPORTANT] 當前字數估算實現基於部分 Markdown 語法符號清理後的緊湊字串長度與空白分段比較，不是 Markdown AST 語法樹層面的純文本提取，也不是工業級“中文字元數 + 英文詞彙”自然語言混合分詞。 本文以實際原始碼為準，不把擬議中的分詞改進描述成已落地能力。

1. 為什麼需要篇幅度量指標

建立篇幅度量指標，主要幫助讀者在進入文章閱讀之前形成清晰的心理與時間預期：

  1. 認知站點定位：本站的技術內容是以簡明速記與快查卡片為主，還是以長篇系統性專欄為主？
  2. 評估閱讀投入：讀者閱讀一篇典型文章，通常需要投入大致幾分鐘的時間？
  3. 觀察篇幅演進：隨著持續釋出新文章，全站的篇幅體量呈現怎樣的結構分佈？
  4. 保障資料可複核性：介面展示的“平均字數”與“密度等級”，能否由任意第三方通過公開程式碼和文章資料完整復算？

然而，技術人員必須時刻警惕指標異化。篇幅只是文本的一個物理表象特徵：

  • 一篇 400 字的精準故障復盤，如果清晰列出根因診斷、重現條件與修復程式碼，其工程價值可能極高；
  • 一篇 8000 字的長文，若充斥著無效依賴安裝日誌、重複表述或失效配置，其閱讀體驗依然是低劣的。

內容密度指標絕不是鼓勵創作者追求無意義長文的“考核工具”。

1.1 規範來源與程式碼對映

內容密度相關的閾值定義與計算演算法分佈於以下位置：

規範職責原始碼位置 / 對應介面核心邏輯說明
閾值與文案定義src/config/standards.ts匯出權威配置 standardsConfig.contentDensityLevels
單篇字數估算演算法src/lib/content.ts 中的 estimateWordCount()正則預清理、空白歸一化與長度比較
單篇閱讀時長預估src/lib/content.ts 中的 estimateReadingMinutes()基於 220 詞/分鐘常數的保底取整計算
全站均值聚合邏輯src/lib/site-metrics.ts 中的 calculateSiteMetrics()逐篇字數求和除以公開文章數並四捨五入
靜態快照生成指令碼scripts/sync-console-metrics.mjs構建期掃描 Markdown 檔案並生成 JSON 資產
邊緣介面資料輸出functions/api/console/data.ts直接讀取快照中的統計資料並輸出

當前執行的規範版本標識為 EES-2026.4，配置版本為 2.6.0。

2. 四級閾值完整階梯與技術定義

全站內容密度分為四個連續且互斥的等級階梯：

等級標識狀態程式碼徽章顯示四捨五入後平均篇幅官方命名典型文章特徵與篇幅結構
Lv.1Level 1 (Low)Lv.1 Low0–800 字微動態速記簡短排障記錄、單點備忘、工具配置單項清單
Lv.2Level 2 (Standard)Lv.2 Standard801–1500 字標準技術部落格包含背景、方案設計與程式碼落地的標準單篇博文
Lv.3Level 3 (High)Lv.3 High1501–3000 字詳實系統專欄跨模組聯動分析、帶前後對比與排錯路徑的進階長文
Lv.4Level 4 (Ultra)Lv.4 Ultra至少 3001 字硬核深度長文體系化全景架構、全鏈路原始碼剖析、完整生產重構專論

等級評定的判定輸入是全站文章總字數除以文章總量後經過四捨五入（Math.round）的整數。

區間端點為閉區間定義：

  • 800 字屬於 Lv.1，達到 801 字則晉升為 Lv.2；
  • 1500 字屬於 Lv.2，達到 1501 字則晉升為 Lv.3；
  • 3000 字屬於 Lv.3，達到 3001 字則晉升為最高階 Lv.4。

2.1 官方命名用語的技術邊界

“硬核深度長文”等名稱屬於本站內部展示用語。其嚴謹的技術定性應表述為：

在當前字數估算演算法口徑下，全站納入統計公開文章的算術平均篇幅達到了 3001 字元以上。

嚴禁將其曲解或宣傳為：

本站所有文章均已經通過國家或行業級技術含金量認證。

3. 度量流水線與資料流向

# 內容密度度量流水線
## 輸入文章集合
- 公開有效文章
- 排除 draft === true 草稿
- 頁面側排除 access 受限文章
- 多語言代表性版本去重
## 逐篇字數估算 (estimateWordCount)
- 讀取原始 Markdown 正文
- 字元級替換部分語法標記
- 摺疊連續空白字元
- 提取緊湊字串長度與空白分段
- 取兩者最大值作為估算值
## 全站聚合計算
- 累加全部入選文章字數 -> totalWords
- 獲取公開去重文章總量 -> totalPosts
- 算術相除並四捨五入 -> avgWordsPerPost
## 階梯匹配對映
- 0 至 800 -> Lv.1 Low
- 801 至 1500 -> Lv.2 Standard
- 1501 至 3000 -> Lv.3 High
- >= 3001 -> Lv.4 Ultra
## 技術解釋邊界
- 屬於字串長度物理估算
- 不等價於自然語言分詞
- 不代表程式碼可執行性
- 不衡量語義知識密度

4. 當前字數估算演算法逐步深度解析

在 src/lib/content.ts 中，estimateWordCount() 的核心邏輯實現如下：

export function estimateWordCount(entry: CollectionEntry<'posts'>): number {
  const plain = entry.body
    .replace(/[`#>*_[\]\(\)!-]/g, ' ')
    .replace(/\s+/g, ' ')
    .trim();

  if (!plain) return 0;

  const compact = plain.replace(/\s+/g, '');
  const latinTokens = plain.split(/\s+/).filter(Boolean).length;

  return Math.max(compact.length, latinTokens);
}

該演算法包含三個清晰的處理步驟：

4.1 第一步：字元級粗粒度符號清理

程式碼使用正規表示式對常見 Markdown 語法標記符號執行批次替換，將其替換為一個普通空格字元 ' '：

  • 反引號 `（用於程式碼塊與行內程式碼）；
  • 井號 #（用於標題標記）；
  • 大於號 >（用於引用塊）；
  • 星號 * 與下劃線 _（用於強調斜體與粗體）；
  • 方括號 [ 與 ]、圓括號 ( 與 )（用於超連結與圖片語法）；
  • 感嘆號 !（用於圖片語法字首）；
  • 連字元 -（用於列表項與分割線）。

關鍵技術侷限：這是一組無狀態的純字元替換，而非基於 Markdown AST 的語法節點解析。 例如：如果某個字元出現在程式碼塊內部、數學公式中、超連結 URL 裡或者普通正文中，都會被無差別替換為空格。

4.2 第二步：空白字元歸一化與空串檢查

演算法使用 replace(/\s+/g, ' ') 將製表符、連續回車換行與多個連續空格統一收斂為一個半形空格，並呼叫 .trim() 剝離首尾空白。若清理後的字串為空串，直接返回估算結果 0。

4.3 第三步：緊湊長度與分段計數取較大值

清理後的字串進入兩個指標的計算：

  1. compact.length：通過 plain.replace(/\s+/g, '') 剔除所有內部空格後，直接測量剩餘字串的物理字元長度；
  2. latinTokens：通過 plain.split(/\s+/).filter(Boolean).length 測量以空格分隔的單詞片段數量。

最終，函式呼叫 Math.max(compact.length, latinTokens) 返回兩者的較大值。

命名與演算法澄清：程式碼中的變數名 latinTokens 並不代表系統內建了拉丁語系自然語言分詞器，更不是大語言模型（LLM）的 Token 分詞概念。它僅僅是按空格分割後的片段計數。

4.4 JavaScript UTF-16 碼元長度的核心影響

在當前演算法中，compact.length 讀取的是 JavaScript 引擎原生的 String.prototype.length 屬性。在 ECMAScript 規範中，字串長度計算的是 UTF-16 碼元（Code Units）的數量。

它在物理上不等於：

  • 檔案的 UTF-8 編碼實際位元組數；
  • 真實世界中的 Unicode 碼點（Code Points）；
  • 人眼直觀看到的獨立字素簇（Grapheme Clusters）；
  • 中文現代漢語詞彙切分數量；
  • 英文實際合法詞彙數量。

對於大部分落在基本多語言平面（BMP, U+0000 至 U+FFFF）的常見中文字元與英文字母，一個字元對應一個 UTF-16 碼元。但對於需要代理對（Surrogate Pairs）表示的 Emoji 表情符號、擴充套件漢字或組合字元，單個視覺字元會佔據 2 個甚至更多個碼元長度。

5. 多樣化樣例與邊界行為分析

為了幫助讀者與開發者精確復算，以下列出典型輸入在當前演算法下的估算結果與技術成因：

樣例編號輸入正文樣本 (Raw Markdown Body)估算字數底層計算過程與技術歸因
S-01(空字串或純回車換行)0正則清理後無任何有效字元，返回 0
S-02系統架構重構實戰88 個標準漢字，每個字元佔 1 個 UTF-16 碼元
S-03Hello World10剔除空格後 compact 為 HelloWorld（長度 10）；分詞數 2；取較大值 10
S-04## 1. 核心架構設計8# 被替換為空格，留下 1. 與 6 個漢字，共 8 字元
S-05[GitHub 倉庫](https://github.com/shijianus)38方括號圓括號被替換，但 URL 字元被完整保留計入長度
S-06![架構圖](https://cdn.example.com/assets/arch-2026-v2.png)46圖片語法中的長 URL 未被剝離，其 URL 字元全量計入
S-07🚀 (單個火箭 Emoji)2屬於輔助平面字元（U+1F680），佔用 2 個 UTF-16 碼元
S-08👨‍👩‍👧‍👦 (家庭組合 Emoji)11由 4 個獨立人員 Emoji 加上零寬連線符（ZWJ）組合而成，共 11 個碼元

[!WARNING] 從樣例 S-05 與 S-06 可以看出當前演算法的一個重要特徵：Markdown 圖片語法中的資源 URL 會全量參與字數統計。 如果文章引用了大量攜帶長查詢引數的圖片 URL 或 Base64 編碼圖片，估算字數會被顯著抬高。這是無狀態字元替換演算法的固有缺陷，必須在未來版本中通過 AST 解析器予以升級。

6. 程式碼塊、公式與 HTML 標記在當前模型中的權重

程式碼正文全量計入：圍欄反引號（```）在第一步被替換為空格，但程式碼塊內部的函式名、變數名、關鍵字與註釋文字，均被當作普通文本參與緊湊字元長度與分段比較。演算法不具備語法分析器能力，無法區分可執行程式碼與死程式碼。程式碼能夠增加篇幅，但不代表其具備可執行性。

LaTeX 原始碼參與統計：數學公式（如 KaTeX 塊）在原始正文中以純文本形式存在。公式內的反斜槓、字母、花括號等符號均會作為文本字元計入統計。當前系統並未實現針對複雜數學公式的“等效閱讀難度加權折算”功能。

HTML 標籤名與屬性計入：若在 Markdown 中直接書寫 <div class="custom-card">，HTML 標籤名稱、class 類名與屬性值均未被預先剔除，同樣會貢獻物理字元數。因此，純粹依靠複雜的 HTML 巢狀可能在無意中膨脹估算篇幅。

7. 全站平均篇幅與聚合演算法

全站內容密度不是基於某一篇代表性長文決定的，而是對全站所有有效公開文章進行算術平均後的綜合體現。

7.1 計算公式與執行順序

設納入統計的公開文章總數為 NN，第 ii 篇文章經過 estimateWordCount() 計算出的字數為 WiW_i。

全站指標的計算流程如下：

TotalWords=∑i=1NWi\text{TotalWords} = \sum_{i=1}^{N} W_i AvgWordsPerPost={Math.round(TotalWordsN),N>00,N=0\text{AvgWordsPerPost} = \begin{cases} \text{Math.round}\left(\frac{\text{TotalWords}}{N}\right), & N > 0 \\ 0, & N = 0 \end{cases}

關鍵工程約束：

  1. 先計算浮點數商，再執行四捨五入；
  2. 算術平均等權原則：每一篇文章不論釋出時間早晚、不論閱讀量高低，在計算平均值時擁有完全平等的權重（權重均為 1N\frac{1}{N}）；
  3. 零樣本防禦：當 N=0N = 0 時，平均篇幅定義為 0，經匹配函式對映至 Lv.1，此時介面必須同時展示“暫無樣本”，避免給讀者造成已有微動態內容的錯覺。

7.2 教學演算案例

假定全站僅有 3 篇公開文章：

文章標識估算字數 WiW_i單篇對應密度區間
Article-A650 字Lv.1 微動態速記
Article-B1,400 字Lv.2 標準技術部落格
Article-C3,800 字Lv.4 硬核深度長文
全站累加5,850 字—

執行全站平均計算：

Average=58503=1950.0\text{Average} = \frac{5850}{3} = 1950.0 AvgWordsPerPost=Math.round(1950.0)=1950\text{AvgWordsPerPost} = \text{Math.round}(1950.0) = 1950

最終等級匹配：1950 落在 [1501,3000][1501, 3000] 區間內，全站內容密度判定為 Lv.3 High（詳實系統專欄）。

7.3 單篇評級與全站評級的嚴格區分

  • 在某些長文頁面中，介面可能會根據單篇字數（如 Article-C 的 3,800 字）打上“Lv.4 深度長文”的標籤；
  • 該標籤僅代表單篇內容的篇幅規模，讀者絕不能以此推論全站平均水平已經達到 Lv.4。全站評級必須以聚合計算後的全域性均值為唯一準繩。

8. 四捨五入對臨界值判定的敏感性分析

等級匹配不是直接對未取整的浮點數進行區間比較，而是對取整後的整數進行比較。在臨界點附近，四捨五入對最終等級起決定性作用：

原始相除浮點數平均值Math.round() 取整結果最終匹配等級技術判定說明
800.499800Lv.1 Low無法達到 801，維持 Lv.1
800.500801Lv.2 Standard觸發進位達到 801，成功晉升 Lv.2
1500.4991500Lv.2 Standard無法達到 1501，維持 Lv.2
1500.5001501Lv.3 High觸發進位達到 1501，成功晉升 Lv.3
3000.4993000Lv.3 High無法達到 3001，維持 Lv.3
3000.5003001Lv.4 Ultra觸發進位達到 3001，成功晉升 Lv.4

因此，在技術文件與介面文案中，必須使用精確的語言表述：

  • 表達“全站進入 Lv.4”時，準確說法應是“四捨五入後的全站平均篇幅達到 3001 字或以上”，而不應簡單表述為“平均超過 3000 字”。

9. 新增短篇內容對全站平均值的稀釋效應分析

算術平均值對樣本分佈的變化非常敏感。新增短篇技術速查或故障記錄，必然會對全站平均篇幅產生稀釋作用。

9.1 數學演練案例

假定全站原有 10 篇長文，總字數為 40,000 字，平均字數為 4,000 字，穩居 Lv.4（Ultra）。

此時，作者為了記錄一個突發線上依賴 Bug，新增釋出了一篇篇幅為 500 字的速記博文：

  • 新的總字數：40,000+500=40,50040{,}000 + 500 = 40{,}500 字；
  • 新的文章總篇數：10+1=1110 + 1 = 11 篇；
  • 新的平均字數：4050011≈3681.82→Math.round=3682\frac{40500}{11} \approx 3681.82 \to \text{Math.round} = 3682 字。

雖然均值依然在 Lv.4 區間內，但平均值瞬間下降了 318 字。若後續連續釋出多篇短文，全站密度可能自然回落至 Lv.3。

9.2 創作倡導原則

平均篇幅回落絕不代表站點的知識沉澱發生倒退。

  • 一個成熟的技術部落格既需要體系化的深度架構專論，也需要精準精煉的單點勘誤與環境速查；
  • 堅決反對為維持“Lv.4 Ultra”的徽章虛榮而刻意刪除有價值的短文，或者在短文中人為填充無關文字。指標服務於讀者，不可本末倒置。

10. 預計閱讀時間計算模型與程式碼閱讀特性

全站與單篇的預計閱讀時間，基於通用的常數估算模型計算。

10.1 逐篇估算與保底原則

單篇文章的預計閱讀分鐘數由 estimateReadingMinutes(entry) 計算：

export function estimateReadingMinutes(entry: CollectionEntry<'posts'>): number {
  const words = (entry.data as any).wordCount ?? estimateWordCount(entry);
  return Math.max(1, Math.round(words / 220));
}

其核心技術特徵：

  1. 基準閱讀速率：設定為每分鐘 220 個估算單位（WPM=220WPM = 220）；
  2. 四捨五入取整：使用 Math.round 而非向上取整 Math.ceil；
  3. 1 分鐘物理保底：通過 Math.max(1, ...) 確保哪怕是 50 字的極短文章，介面也至少提示“1 分鐘閱讀”，符合讀者的最少心理停留。

10.2 為什麼全站總閱讀時間不能用總字數直接相除

在全站指標聚合時，metrics.totalReadingMinutes 是逐篇文章預計閱讀分鐘數的直接累加和，即：

TotalReadingMinutes=∑i=1NReadingMinutesi\text{TotalReadingMinutes} = \sum_{i=1}^{N} \text{ReadingMinutes}_i

而非：

TotalReadingMinutes≠Math.round(TotalWords220)\text{TotalReadingMinutes} \ne \text{Math.round}\left(\frac{\text{TotalWords}}{220}\right)

數學差異證明： 若有 5 篇短文，每篇字數均為 60 字：

  • 逐篇計算：每篇 60/220≈0.2760 / 220 \approx 0.27，四捨五入為 0，但觸發保底返回 1 分鐘；5 篇累加得到 5 分鐘；
  • 彙總後相除：總字數為 300 字，300/220≈1.36300 / 220 \approx 1.36，四捨五入僅得到 1 分鐘。

因此，在複核全站閱讀時間時，必須嚴格執行逐篇累加邏輯。

10.3 程式碼閱讀的非線性特徵

閱讀一段 50 行的複雜併發排程程式碼，讀者需要反覆查閱變數定義、推導鎖競爭與上下文時序，其實際耗時可能是閱讀 50 個普通文字的數倍。 當前模型未對程式碼語法樹進行詞法深度加權，因此介面對外明確標註為“預計閱讀時間”，不代表讀者完全消化吸收該技術方案所需的實際工時。

11. 頁面側計算與 API 快照側的統計差異

如 EES-001 總綱中所述，當前系統存在頁面側（SSG）與快照側（Snapshot）的雙軌計算。在內容密度指標上體現如下：

  1. Access 受限文章差異：頁面側 getPublicPosts() 嚴格排除受限文章；快照指令碼 sync-console-metrics.mjs 目前未排查 access 配置。若倉庫存在受限文章，快照側計算出的總字數與平均字數可能略高於頁面側；
  2. 多語言歸組演算法差異：快照指令碼按檔名正則歸組，而頁面側優先讀取 i18nKey。若多語言版本的篇幅不一致，代表版本的選擇分歧會導致總字數出現微小出入；
  3. 正文掃描時機差異：API 輸出的字數完全依賴構建期生成的快照。在未執行重新構建的前提下，API 響應中的 servedAt 無論如何重新整理，其字數統計均保持快照生成那一時刻的值不變。

12. 卓越技術長文的結構化排版與寫作指南

高密度的技術長文必須具備清晰的工程層次，避免淪為難以閱讀的“文字牆”。推薦遵循以下結構化規範：

12.1 工程寫作的 10 項核心要素

  1. 問題背景與應用邊界：明確說明該方案解決的具體工業場景與適用版本；
  2. 技術選型與備選對比：客觀闡述為何選用當前架構，放棄了哪些替代方案；
  3. 架構全景圖或思維導圖：提供直觀的上下文視覺呈現；
  4. 可落地的完整配置與依賴清單：給出明確的版本號與環境基線；
  5. 最小可執行的核心程式碼實現：杜絕截斷關鍵邏輯的片段，保證復現性；
  6. 自動化驗證方法與預期輸出：提供具體的測試命令與預期控制台結果；
  7. 常見邊界缺陷與排錯指南：記錄作者踩坑與調優的真實軌跡；
  8. 效能消耗與資源邊界分析：說明併發上限、記憶體佔用或網路開銷；
  9. 鑑權與生產安全防護要點：提示許可權最小化原則與憑證防護；
  10. 部署、回滾與演進規劃：說明如何無縫釋出及失敗時的應急回滾手段。

12.2 排版元件的使用邊界

元件型別最佳適用場景嚴禁濫用場景
提示卡 (Callouts)強調破壞性變更、核心安全警示或配置前置條件通篇每一段都加提示卡，導致視覺焦點徹底渙散
標籤頁 (Tabs)呈現多平臺實現對比（如 Docker vs K8s，Linux vs macOS）將必須按順序依次執行的步驟切碎隱藏在不同 Tab 中
摺疊手風琴 (Accordion)放置詳盡日誌、長篇配置檔案全文、常見問答（FAQ）隱藏影響系統正常啟動的關鍵環境校驗步驟
思維導圖 (Mindmap)呈現全域性概念樹與模組依賴關係代替嚴謹的程式碼實現或演算法證明
表格 (Tables)引數對照、環境變數說明、測試基準對比在單元格中塞入大量多行連續長文本段落

13. 跨語言字元計數的限制

不同語言的文字長度、空白分隔習慣與 Unicode 表示方式不同。本站目前的估算器只處理字串長度與空白分段，沒有測量語義資訊量、閱讀難度或跨語言的「等價字數」。因此，跨語言比較只能理解為目前演算法口徑下的物理字元體量。

13.1 目前演算法能夠與不能夠說明的事

  1. CJK 文字：移除空白後，每個 UTF-16 碼元通常會直接增加緊湊字串長度；這是字串計數結果，不等於語素、詞彙或資訊量的精確統計。
  2. 拉丁文字與程式碼：空白分隔的 token 數會被計算，但最終仍取緊湊字串長度與 token 數的較大值。長單字、網址、程式碼與標記清理結果都可能影響估算值。
  3. 沒有人工語言權重：目前沒有根據語言、閱讀難度或語義深度進行校正，也沒有可信證據支持固定的字元倍率或資訊熵數字。跨語言文章應在同一語言內比較，或明確註明這項限制。

13.2 抽象語法樹 (MDAST) 精準純文本提取流水線規範 (PROPOSED)

針對當前演算法將圖片 URL 與 HTML 屬性混入字數的侷限，擬定下一代（v3.0）演算法技術路線：

原始 Markdown 文本
  │
  ▼ Remark 抽象語法樹解析器 (MDAST)
遍歷語法樹節點：
  ├── 剝離 image 與 imageReference 節點（完全剔除資源 URL 字串）
  ├── 剝離 html 節點（提取純文本，剔除標籤名稱與 class 屬性）
  ├── 對 code 程式碼節點：單獨提取並記錄有效程式碼字元數（獨立加權）
  └── 對 text 文本節點：
        - 中文/CJK 字元：通過 Unicode 範圍精確統計漢字字數；
        - 西文單詞：使用正規表示式 \b[A-Za-z0-9_-]+\b 統計純粹詞彙量；
        - Emoji 與複合符號：通過 Intl.Segmenter 按字素簇（Graphemes）精準計數。

該方案將使字數統計與自然閱讀體驗高度貼合，目前處於設計階段，待測試驗證完備後推行。

14. 核心核驗用例與質量自查清單

執行內容密度演算法迴歸測試與釋出的自查清單：

  • 空內容測試：純空正文輸入返回 0，全站無文章時正確回退至 Lv.1 並標註“暫無樣本”；
  • 中文獨立性測試：驗證中文字元不依賴空格即可正確計算字元長度；
  • 西文片段測試：驗證以空格分隔的英文句子能夠正確識別詞彙分段；
  • 整數邊界測試：驗證聚合平均值 800 仍屬 Lv.1、801 進入 Lv.2；1500/1501 與 3000/3001 亦應分別落在相鄰等級。calculateSiteMetrics() 會先以 Math.round 取得整數，再交給等級匹配函式，不應把 800.5 當成公開輸入契約；
  • 總閱讀時間累加測試：驗證總閱讀時間由各篇保底分鐘數求和得出，而非總字數直接相除；
  • 快照一致性核驗：對照 console-metrics.json 中的 totalWords 與頁面初始 HTML 中的數值；
  • 防刷與安全自查：核驗受限加密文章的敏感字數與標題未洩露至公開快照中。

15. 常見疑問深度解析

為什麼全英文技術文章計算出來的字數看起來比中文多很多？

當前演算法的核心分支讀取的是剔除空格後的字串緊湊長度（compact.length）。由於一個典型英文單詞（如 architecture）包含 12 個字母字元，在當前模型中貢獻 12 個估算單位，而一個表意的中文漢字僅貢獻 1 個單位。這屬於字元長度物理估算的天然特徵。跨語言對比時應當結合多語言語境客觀理解。

在一篇文章中插入大量流程圖與高畫質截圖，會自動提升內容密度等級嗎？

不會。系統不評估圖片的審美質量或資訊量。相反，由於無狀態字元替換演算法沒有按 AST 剔除圖片語法，較長的圖片連結字串反而會被誤計為字元數。我們強烈建議通過精煉的文字對圖片進行架構解讀，而非堆砌純圖。

全站等級達到 Lv.4，是否說明站點內的每一篇文章都超過了 3000 字？

不是。Lv.4 是全站所有納入統計公開文章的算術平均值。站點完全可能存在少量篇幅達到 8000 字的深度專論，將包含幾篇 600 字速記文章的整體均值拉高至 3000 字以上。全站等級反映宏觀結構，單篇文章篇幅應當檢視單篇閱讀時間標註。

剛剛釋出了一篇極長的新文章，為什麼 API 介面返回的全站字數沒有立刻改變？

因為指標 API 的總字數來自構建階段生成的靜態快照（console-metrics.json）。邊緣 API 僅在請求期重算與當前時刻強相關的動態欄位（如執行天數與滑動視窗發文數），不會每次請求動態掃描全站正文。新文章的字數將在下一次系統全量構建與部署生效後自動更新。