NEO.K / PLDST程式語言設計師風格譜系
編號PLDST-010
版本v1.0
日期2026-07-30
作者Neo.K
狀態公開版／第二部核心風格原型正式論文

下載 PDF ↓回到論文索引 ↗

設計一致性、相容性與社群演化：語言何時應堅持原則，何時應接受歷史？

摘要

程式語言進入長期使用後，設計者與共同體會持續面對一個無法永久迴避的衝突：

應該為了更一致、更安全、更清楚的設計修正歷史，還是應該保護既有程式、工具、組織知識與使用者信任？

若永遠優先原則，語言可能頻繁破壞程式、分裂生態並耗盡使用者；若永遠優先相容，早期偶然、錯誤預設與不理想介面可能被永久保留，形成規格膨脹、教學負擔與設計化石。

Go 將 Go 1 相容承諾視為最重要的設計選擇之一，並在 Go 1.21 以語言版本、GODEBUG、中央文件與 Runtime metrics 進一步保存「規格允許改變、但真實程式仍可能依賴」的舊行為。Python 的 PEP 387 將語法、行為、C API、例外及公共介面納入相容政策，要求不相容變更具有高收益／破壞比、經過至少兩年的棄用期，並以 Soft Deprecation 保留「不再鼓勵，但也不預定移除」的 API。Rust 以「穩定而不停滯」為核心承諾：一旦功能進入 Stable，原則上持續支援；真正需要不相容表面變更時，透過 opt-in Edition、跨 Edition 互操作與 cargo fix --edition 將破壞限制在可選遷移中。C++ 由 WG21 在廣泛硬體、產業與既有程式碼約束下演化，其正式原則要求與舊 C++ 的相容應預設可用，但相容也使語言長期保存多代構造。ECMAScript 的 Annex B 更直接把部分具有「不理想特性」的 Web Legacy 行為列入規範：若沒有大量既有網頁依賴，本可刪除，但瀏覽器仍必須支援。Swift 則同時發展 Source compatibility、ABI stability、Module stability、Library evolution、Upcoming Feature Flags、Code migration 與社群相容測試套件，展示相容不是單一布林值，而是一組跨編譯器、來源、模組與二進位邊界的工程制度。[R1][R2][R3][R4][R5][R6]

本文提出 一致性—相容性—演化模型（Coherence–Compatibility–Evolution Model, CCEM）：

E=(Q,C,B,M,G,L,J)\mathcal{E} = ( \mathbf{Q}, \mathbf{C}, \mathbf{B}, \mathbf{M}, \mathbf{G}, \mathbf{L}, \mathbf{J} )

其中：

本文區分四種一致性：

  1. 概念一致性；
  2. 表面一致性；
  3. 行為一致性；
  4. 制度一致性。

並區分七種相容性：

  1. 來源相容；
  2. 二進位／ABI 相容；
  3. 行為相容；
  4. 資料與序列化相容；
  5. 工具與建置相容；
  6. 生態與依賴相容；
  7. 組織知識相容。

核心命題為：

向後相容⇏舊設計仍被認為良好\boxed{ \text{向後相容} \not\Rightarrow \text{舊設計仍被認為良好} }

以及：

修正不一致⇏破壞就是正當的\boxed{ \text{修正不一致} \not\Rightarrow \text{破壞就是正當的} }

成熟語言不應把相容性當成絕對禁令，也不應把「設計更漂亮」視為破壞使用者的充分理由。更合理的判準是：

只有當不一致造成明確且持續的安全、正確性、可理解性或演化阻塞，而新設計具有足夠收益、可限制破壞範圍、可提供工具化遷移、可經社群驗證並保存長期信任時，破壞才可能正當。

關鍵詞： 程式語言設計、向後相容、設計一致性、語言演化、棄用、Edition、ABI、Legacy、治理、PLDST

第一部分　一致性不是「所有東西長得一樣」

一、概念一致性 QcQ_c

概念一致性指：

例如：

所有資源都遵循一致所有權
所有錯誤都使用一致傳播模型
所有集合都遵循相似迭代抽象

概念一致不要求語法完全相同，而要求深層規則可組合。

二、表面一致性 QsQ_s

表面一致性包括：

它能降低記憶負擔，但過度追求表面對稱，可能迫使不同概念使用相同語法而增加歧義。

三、行為一致性 QbQ_b

行為一致性回答：

這是相容性政策經常真正保護的層級。

四、制度一致性 QgQ_g

制度一致性指：

語言技術一致，但治理任意，同樣會失去社群信任。

五、一致性向量

Q=(Qc,Qs,Qb,Qg)\mathbf{Q} = ( Q_c, Q_s, Q_b, Q_g )

一個語言可以：

第二部分　相容性不是一個布林值

六、來源相容 CsC_s

舊來源碼能否由新工具鏈：

而不需要修改。

來源相容仍需區分：

完全無修改
只需警告
可由工具自動修改
需人工遷移
僅特定語言模式

七、二進位與 ABI 相容 CaC_a

舊 Binary 能否與新：

共同運行，而不重新編譯。

ABI 相容牽涉：

Swift 將 ABI stability、Module stability 與 Library evolution 明確區分，正是因為它們並非同一保證。[R6]

八、行為相容 CbC_b

舊程式即使仍能編譯，也可能因：

改變結果。

因此：

SourceCompatible⇏BehaviorCompatibleSourceCompatible \not\Rightarrow BehaviorCompatible

Go 1.21 的 GODEBUG 機制即處理「規格允許改，但實際程式可能依賴舊行為」的灰區。[R1]

九、資料相容 CdC_d

包括：

語言與 Library 改變可能破壞保存多年或跨版本交換的資料，即使來源和 ABI 完全不變。

十、工具與建置相容 CtC_t

包括：

工具往往是有效語言的一部分。只保證 Parser 接受舊語法，不足以保證專案可建置。

十一、生態與依賴相容 CeC_e

包括：

Rust Edition 強調不同 Edition crate 可互操作，避免語言修正將 Package 生態切成不相容島嶼。[R3]

十二、組織知識相容 CoC_o

包括：

語言破壞不只重寫程式，也可能使多年組織知識折舊。

十三、相容向量

C=(Cs,Ca,Cb,Cd,Ct,Ce,Co)\mathbf{C} = ( C_s, C_a, C_b, C_d, C_t, C_e, C_o )

「此變更向後相容」若未指明維度，就是不完整聲明。

第三部分　歷史負擔的六種類型

十四、活躍設計 Active Design

仍被認為合理，且推薦新程式使用。

十五、相容性化石 Compatibility Fossil

被保留是因為既有程式依賴，而非現代設計仍偏好。

ECMAScript Annex B 的說明極為直接：相關 Web Legacy 功能具有不理想特性，若沒有大量既有網頁使用，本應從規格刪除；但瀏覽器仍須支援。[R5]

十六、軟性棄用 Soft Deprecation

Python PEP 387 將 Soft Deprecation 定義為：

它適合：

十七、硬性棄用 Hard Deprecation

包含：

硬性棄用是破壞流程，不只是文件標籤。

十八、事故性穩定 Accidental Stabilization

某項行為可能因：

形成事實契約，即使從未被正式設計。

成熟共同體需決定：

十九、實驗性負擔 Experimental Debt

Preview、Nightly、Provisional、Feature flag 的價值，是在功能永久承諾前取得真實證據。

若實驗狀態：

就會形成影子相容負擔。

第四部分　破壞成本模型

二十、直接修改成本 BmB_m

包括：

二十一、語義風險 BsB_s

自動遷移後程式可能：

二十二、生態協調成本 BeB_e

多層依賴需要：

二十三、信任成本 BjB_j

若使用者認為：

他們可能：

二十四、破壞向量

B=(Bm,Bs,Be,Bj)\mathbf{B} = ( B_m, B_s, B_e, B_j )

設計美學收益若不足以支付這些成本，就不構成正當破壞。

第五部分　修正歷史的正當性

二十五、安全必要性

若舊行為：

破壞相容較可能正當。

但仍需：

二十六、語義錯誤

若規格或實作行為：

可以考慮修正。

「我更喜歡另一種語法」通常不足。

二十七、規模阻塞

某些早期設計在小型系統可接受，卻在大型生態造成：

此時修正可能是生態持續成長的前提。

二十八、收益—破壞比

Python PEP 387 使用「Benefit to breakage ratio」作為基本政策語言。[R2]

可表示為：

J(Δ)=Safety+Correctness+Coherence+FutureCapacityMigration+SemanticRisk+EcosystemCost+TrustCostJ(\Delta) = \frac{ Safety+ Correctness+ Coherence+ FutureCapacity }{ Migration+ SemanticRisk+ EcosystemCost+ TrustCost }

只有 J(Δ)J(\Delta) 足夠高，且沒有成本更低的替代方案，才進入破壞流程。

第六部分　遷移不是附錄，而是設計的一部分

二十九、警告

好的警告應：

三十、自動修正

例如：

自動修正應區分：

機械等價
可能改變行為
需人工確認
無法自動修正

三十一、版本化行為

Go 1.21 讓 GODEBUG 預設值依主套件 go.mod 中的 Go 版本選擇，使新 Toolchain 能保留舊版本行為。[R1]

此模式可表示：

Behavior=f(ToolchainVersion,DeclaredLanguageVersion,CompatibilityFlags)Behavior = f( ToolchainVersion, DeclaredLanguageVersion, CompatibilityFlags )

優勢：

風險：

三十二、Edition

Rust Edition 將部分不相容表面變更：

它不是 Fork，也不是傳統完全不相容 major version。

三十三、Upcoming Feature Flags

Swift 允許專案逐項啟用預定進入下一重大語言模式的 Source-breaking change，並要求提案描述 Source compatibility 影響。[R6]

這使：

三十四、相容測試套件

Swift Source Compatibility Test Suite 將真實開源專案納入持續整合，用來在 Compiler 變更合併前發現來源相容回歸。[R6]

這是一個重要原則：

相容性不能只依規格推論，也需要以真實生態驗證。

第七部分　六種一致性—相容風格

三十五、承諾優先型

代表：

特徵：

優勢：

風險：

三十六、棄用治理型

代表：

特徵：

優勢：

風險：

三十七、穩定而不停止型

代表：

特徵：

優勢：

風險：

三十八、歷史疊加型

代表：

特徵：

優勢：

風險：

WG21 的 Language Evolution 原則將與較舊 C++ 的順暢相容列為預設要求；這是一種制度性保守，而非單一人物偏好。[R4]

三十九、Web 現實保存型

代表：

特徵：

優勢：

風險：

四十、分層穩定與遷移型

代表：

特徵：

優勢：

風險：

第八部分　相容性何時成為負債

四十一、不安全預設不能修正

若相容政策使語言無法：

歷史便直接阻礙安全。

四十二、所有舊行為都成為教學負擔

新手不只需學現代推薦方式，也要理解：

即使「可以不使用」，閱讀舊程式仍需掌握。

四十三、規格與實作矩陣爆炸

每個新功能都要與：

交互測試。

四十四、設計一致性只能靠社群規範

語言無法移除不理想構造時，常依賴：

這可以有效，但也意味語言規格與實際推薦語言分裂。

第九部分　破壞何時成為暴力

四十五、只為美學

僅因：

而要求大規模遷移，通常正當性不足。

四十六、沒有真實資料

若未測量：

就無法合理估計破壞。

四十七、把成本推給無權使用者

語言共同體決定修正，卻由：

支付全部遷移成本，會削弱正當性。

四十八、沒有雙軌與回退

若新版本：

破壞半徑會放大。

四十九、把反對者寫成落後

使用者可能反對破壞，不是因為不理解新設計，而是因為：

成熟治理需要理解真實成本。

第十部分　社群正當性

五十、程序正當性

包括：

五十一、代表正當性

誰參與決策？

「社群決定」不能只代表最能參加會議的人。

五十二、結果正當性

即使程序完整，結果仍需：

五十三、補償正當性

若共同體要求使用者遷移，也應提供：

五十四、信任方程

可啟發式表示：

Trustt+1=Trustt+Transparency+Predictability+Support−Surprise−ArbitraryException−UnpaidBreakageTrust_{t+1} = Trust_t + Transparency + Predictability + Support - Surprise - ArbitraryException - UnpaidBreakage

它不是精確社會科學量表，而是制度檢查框架。

第十一部分　設計決策矩陣

五十五、堅持原則

較適合堅持原則的情況：

五十六、接受歷史

較適合接受歷史的情況：

五十七、雙層處理

常見最佳方案不是二選一，而是：

舊行為保留
+
新程式預設新行為
+
明確版本／Edition／Profile
+
遷移工具
+
跨層互操作

五十八、刪除判準

一項歷史功能可考慮移除，需回答：

是否有明確傷害？
是否有可靠替代？
使用率多高？
能否自動遷移？
資料與 ABI 是否受影響？
是否已充分警告？
生態是否已有時間反應？
是否有例外與回退？
決策者是否承擔支援？

第十二部分　PLDST 風格判定

五十九、一致性指紋

Conceptual coherence
Surface uniformity
Behavioral consistency
Governance consistency
Tolerance for exceptions
Tolerance for profiles

六十、相容性指紋

Source compatibility
ABI compatibility
Behavior compatibility
Data compatibility
Tool compatibility
Ecosystem compatibility
Organizational compatibility

六十一、演化指紋

Deprecation period
Soft deprecation
Feature gates
Edition／language mode
Migration tools
Compatibility flags
Cross-version interop
Legacy isolation
Removal willingness
Exception authority

六十二、設計師比較問題

  1. 他認為何種不一致不可接受？
  2. 他願意為一致性破壞多少舊程式？
  3. 他保護哪一種相容性？
  4. 哪些相容性可犧牲？
  5. 是否區分 Stable、Experimental 與 Private？
  6. 是否提供自動遷移？
  7. 是否接受版本化語義？
  8. 是否允許 Legacy profile？
  9. 誰能批准例外？
  10. 使用者如何參與或反對？
  11. 舊功能保留是認同還是化石？
  12. 破壞後由誰支付維護與支援？

六十三、不能只給「保守／激進」分數

一個共同體可能：

必須保留多維向量。

第十三部分　PLDST SKILL 規格

六十四、輸入

designer_or_governance_body
language
version_range
feature_or_change
compatibility_policy
proposal
migration_tools
ecosystem_evidence

六十五、分析管線

重新網路搜尋
→ 一致性目標抽取
→ 相容性向量
→ Public／Private／Experimental 邊界
→ 破壞範圍
→ Legacy 分類
→ 遷移與回退
→ 治理與例外權
→ 生態證據
→ 正當性分析
→ 第二輪事實校對
→ 風格報告

六十六、JSON 雛形

{
  "change": "edition-gated syntax change",
  "coherence_goal": "remove an ambiguous legacy form",
  "compatibility": {
    "source": "breaking only after opt-in",
    "binary": "not split by edition",
    "behavior": "version-dependent",
    "ecosystem": "cross-edition interoperation"
  },
  "migration": {
    "warning": true,
    "automatic_fix": true,
    "manual_review": "sometimes required",
    "rollback": "retain old edition"
  },
  "governance": {
    "proposal_required": true,
    "stable_feature_removed": false
  },
  "legacy_status": "supported but not preferred"
}

六十七、SKILL 禁止事項

不得：

第十四部分　限制

六十八、相容性無法完整測量

真實生態包含：

任何相容測試都只是樣本。

六十九、Bug fix 與行為破壞邊界模糊

使用者可能依賴 Bug；修正後：

需區分：

規格相容
實作相容
生態相容

七十、安全例外可能被濫用

治理者可以用「安全」合理化任意破壞。需要：

七十一、相容政策也會演化

Go、Python、Rust、C++、ECMAScript 與 Swift 的政策及工具都可能改變。後續個案必須重新查核當時版本。

七十二、社群不是單一利益主體

新使用者、舊系統、Compiler、Library、企業、安全團隊與教育者對相容有不同需求。不存在無成本共識。

第十五部分　第二輪事實與概念校對紀錄

七十三、Go

已重新核對 Go 1 Compatibility 與 Go 1.21 相容文章：

本文沒有把 Go 相容承諾寫成零例外的永久行為凍結。

七十四、Python

已重新核對當前 Active 的 PEP 387：

本文沒有把所有底線開頭名稱簡化成絕對可任意破壞，仍保留 PEP 對特殊名稱與文件邊界的限定。

七十五、Rust

已重新核對 Edition Guide、RFC 3085 與 Migration Guide：

本文沒有把 Edition 描述成傳統 major-version 生態分裂。

七十六、C++

已重新核對 WG21 官方資料、SD-10、SD-8 與 Stroustrup 的 HOPL 回顧：

本文沒有聲稱 C++ 永不破壞，也沒有將現代相容政策只歸於 Stroustrup。

七十七、ECMAScript

已重新核對 2026-07-17 更新的 ECMAScript 2027 Draft 與 Annex B：

本文把它分類為相容性化石與 Legacy 隔離，而非核心設計推薦。

七十八、Swift

已重新核對 Swift 官方 Source Compatibility Test Suite、Upcoming Feature Flags 與 Library Evolution 文件：

本文沒有把所有 Swift Package 都寫成具有 Binary evolution 保證。

第十六部分　結論

設計一致性、向後相容與社群演化並不是三個可以分開處理的議題。

一致性決定語言是否仍然可理解；相容性決定使用者是否能相信升級；治理決定誰有權要求所有人支付改變成本。

本文提出：

E=(Q,C,B,M,G,L,J)\mathcal{E} = ( \mathbf{Q}, \mathbf{C}, \mathbf{B}, \mathbf{M}, \mathbf{G}, \mathbf{L}, \mathbf{J} )

並將語言歷史分成：

Active design
Compatibility fossil
Soft deprecation
Hard deprecation
Accidental stabilization
Experimental debt

成熟演化不等於永遠不破壞，也不等於每隔幾年重設語言。它需要：

明確問題+足夠收益+最小破壞+分層相容+工具遷移+跨版本互操作+公開治理+社群支持\boxed{ \text{明確問題} + \text{足夠收益} + \text{最小破壞} + \text{分層相容} + \text{工具遷移} + \text{跨版本互操作} + \text{公開治理} + \text{社群支持} }

因此：

LegacyPreserved⇏LegacyEndorsed\boxed{ LegacyPreserved \not\Rightarrow LegacyEndorsed }

同時：

CleanerDesign⇏LegitimateBreakage\boxed{ CleanerDesign \not\Rightarrow LegitimateBreakage }

PLDST 對設計師與治理共同體最關鍵的問題，不再只是：

他保守還是激進？

而是：

他認為哪些原則值得讓使用者支付遷移成本？他保護哪一種相容性？他如何區分活躍設計與歷史化石？當破壞不可避免時，是否提供版本邊界、工具、回退、證據與足夠正當性？當歷史不可刪除時，是否能將 Legacy 隔離，使新程式不必永遠重複舊錯誤？

最終原則為：

保護使用者信任∧保留修正歷史的能力∧不把相容變成停滯，也不把進步變成暴力\boxed{ \text{保護使用者信任} \quad\land\quad \text{保留修正歷史的能力} \quad\land\quad \text{不把相容變成停滯，也不把進步變成暴力} }

附錄 A　一致性—相容分析卡

語言：
版本／時期：
變更：
一致性目標：
現有行為：
Legacy 類型：
來源相容：
ABI 相容：
行為相容：
資料相容：
工具相容：
生態相容：
組織相容：
受影響範圍：
安全收益：
未來演化收益：
遷移方式：
自動修正：
人工修正：
版本模式：
回退：
棄用期：
例外批准者：
真實生態測試：
信任風險：
證據：
信心：

附錄 B　破壞准入卡

問題是否具體：
現有傷害：
是否安全問題：
替代方案：
不破壞方案：
受影響使用率：
Benefit／breakage ratio：
是否可工具化：
資料／ABI 影響：
跨版本互操作：
警告期：
支持期限：
回退機制：
例外與救濟：
社群參與：
決策紀錄：

附錄 C　來源與參考文獻

[R1] Go Project, “Go 1 and the Future of Go Programs,” “Go 1 Compatibility,” and Russ Cox, “Backward Compatibility, Go 1.21, and Go 2,” 2023.
— Go 1 相容承諾、GODEBUG、語言版本、Metrics 與 Go 2 的相容演化。

[R2] Python Enhancement Proposals, “PEP 387 – Backwards Compatibility Policy” and “PEP 5 – Guidelines for Language Evolution.”
— Public API、收益／破壞比、棄用期、Soft Deprecation 與 Steering Council 例外。

[R3] Rust Project, The Rust Edition Guide, RFC 2052, RFC 3085, RFC 1105, and Release Channels RFC 507.
— Stability without stagnation、Edition、跨 Edition 互操作、遷移工具與 Stable API 生命週期。

[R4] ISO/IEC JTC1/SC22/WG21, “SD-10: Language Evolution Principles,” “SD-8: Standard Library Compatibility,” WG21 official committee pages; Bjarne Stroustrup, “Evolving a Language in and for the Real World: C++ 1991–2006.”
— C++ 相容預設、Library 介面界線、國際標準治理與歷史演化。

[R5] Ecma TC39, ECMAScript Language Specification, Annex B, and “The TC39 Process.”
— Web Legacy Compatibility、Stage 4、實作與年度規格。

[R6] Swift Project, “Swift Source Compatibility Test Suite Now Available,” “Using Upcoming Feature Flags,” and “Library Evolution in Swift.”
— Source compatibility、Upcoming feature、ABI、Module stability、Library evolution 與生態回歸測試。

附錄 D　PLDST 演化標記

[Q-C] Conceptual coherence
[Q-S] Surface coherence
[Q-B] Behavioral coherence
[Q-G] Governance coherence

[C-S] Source compatibility
[C-A] ABI compatibility
[C-B] Behavioral compatibility
[C-D] Data compatibility
[C-T] Tool compatibility
[C-E] Ecosystem compatibility
[C-O] Organizational compatibility

[L-A] Active design
[L-F] Compatibility fossil
[L-S] Soft deprecation
[L-H] Hard deprecation
[L-X] Accidental stabilization
[L-E] Experimental debt

[M-W] Warning
[M-F] Automatic fix
[M-V] Versioned behavior
[M-E] Edition／mode
[M-R] Rollback
[M-I] Cross-version interoperation