#234 的字句層清單收了一組借來的物理動詞：撐、扛、垮、頂、掛在、站得住、咬合、啃。那張卡把它們歸成物理化錯配，偵測方法是問這個動詞照字面成立需要什麼物理條件。2026-10-14 的修訂把其中「撐」的足夠性斷言改歸到「問題」那一類（#374）：它佔著需求與判斷標準的位置，修法是寫出需求、判斷標準與機制，換成同義詞不算修好。

這張卡把同一個判斷推到清單裡的每一個動詞。每一個借來的物理動詞都佔著一個內容格，而不同的動詞佔住的格不同，所以改寫時要寫出的內容也不同。物理條件的問法負責找出候選；找到之後先判斷它佔住哪一格，再寫出那一格的內容。

動詞與它佔住的內容

類別常見詞形佔住的內容改寫要寫出的
足夠性斷言撐得住、撐不住、撐起、能撐、扛得住、頂得住需求、判斷標準要滿足什麼需求、滿足到什麼程度算夠、靠什麼機制滿足或在哪一點不再滿足
失效結果拖垮、壓垮、打垮、垮掉、扛不住、頂不住、會垮失效的形態與傳遞的路徑哪個元件失效、失效成什麼樣子（變慢、無回應、崩潰、資料錯誤），以及經由哪一項共用的資源傳到別處
負擔硬扛、扛起、交給某方自己扛、啃誰承擔、承擔什麼工作、代價是什麼承擔者是誰、要做哪幾件事、付出的是人力、時間、維護成本還是前置知識
關係掛在、咬合、咬得最深兩個對象之間的關係與它的程度關係動詞（依賴、隸屬、由誰管理）或程度的狀態詞（耦合最緊）
可信度站得住、站不住讀者讀完之後該產生的判斷多數時候整句不寫；必須寫時，寫出它成立依賴的前提與證據的範圍
字面或技術掛在 volume 上、程序掛在 session 上設定或系統裡實際存在的附掛關係不必改

「扛」與「垮」各跨兩類，判斷看句子：「平台扛掉 patch 與憑證」是負擔（誰做了哪些工作），「服務上線後怎麼扛負載」是足夠性；「一個故障拖垮整個服務」是失效結果，「這套說法會垮」在論證裡是可信度。

失效結果這一類的資訊落差最大。「拖垮」是全站最常見的一個詞形，讀者讀到它只知道後果嚴重，不知道是哪一種後果，也不知道經由什麼傳過去。「讓一個可以降級的功能故障拖垮整個服務的接流量能力」實際要說的是：readiness 綁了一個非必要的依賴，那個依賴一壞，整個服務就被移出接流量的名單。寫成機制，讀者知道該把那個依賴移出 readiness；寫成「拖垮」，讀者只能記住「要小心」。

負載情境裡的容量、過載、故障擴散、突發緩衝與耗盡時間

撐、扛、垮出現在負載情境時，背後至少有五件不同的事，而每一件在站內都已經有業界術語與知識卡：

常見寫法實際在講的事業界術語（站內知識卡）句子要寫出的內容
撐得住、撐不住、扛得住元件在判斷標準下能處理多少負載Saturation Point、Headroom Budget、Throughput負載的單位與量、判斷標準（如延遲百分位數的門檻、錯誤率）、哪一項資源先飽和、餘裕多少
壓垮、扛不住、打垮負載超過容量之後發生什麼Backpressure、Load Shedding、Retry Storm超過之後的機制（佇列變長、延遲非線性上升、逾時引發重試把負載放大）與系統怎麼自保
拖垮一個元件故障或變慢，讓別的元件失效Cascading Failure、Blast Radius、Bulkhead共用的是哪一項資源（連線池、執行緒、同步呼叫）、傳遞路徑、用什麼隔離
撐過尖峰有時間限制的突發，靠緩衝度過Queue Depth、Little’s Law超出容量的速率乘上持續時間，對照緩衝能容納多少，以及恢復需要多久
撐多久、撐不久資源以某個速率耗盡9.6 容量規劃模型目前用量、成長速率、上限，推算出的耗盡時間點與要提前多久行動

「負載」這個詞本身也要寫出單位：每秒請求數、同時連線數、每秒寫入數、單筆資料量與讀寫比例會讓不同的資源飽和，「負載很高」沒說是哪一種。單位的定義見 9.2 Workload Modeling。

負載超過容量之後服務的表現分成哪幾級（變慢、無回應、崩潰）、各級的判斷標準、由哪一層監控看到與應對，是 backend/09-performance-capacity 目錄頁 Backlog 裡的一個待辦項目，由那個模組的教材承接。本卡停在「句子要寫出什麼」這一層。

數字的寫法：與「不寫會取代讀者查證的東西」一起看

要求寫出負載量與判斷標準，容易被執行成把數字寫進通則句，例如「單台 PostgreSQL 撐得住每秒三千筆」。這句話的讀者會照抄一個不屬於他系統的值，違反 docs/rules/writing.md〈不寫會取代讀者查證的值〉（舊版的原則十二）。所以容量句分兩種位置寫：

  • 通則句：寫出句子的形狀與去哪裡量。「在服務設定的延遲門檻下，壓測量到的每秒處理量就是容量；瓶頸看哪一項資源先到飽和」。
  • 文章自己的範例情境：可以寫具體數字，同時寫出數字來自範例的哪一次量測或推算，讓讀者知道它屬於那個情境。

只套前一條規則而不套這一條，修法本身就會產生新的違規。

非負載的用法

清單裡的動詞也出現在與負載無關的句子，修法相同（寫出佔住的內容），要寫出的內容不同：

  • 「靠一條跨前後端的資料契約撐住」：佔住的是「保證什麼不變量、由誰檢查」，寫成「這條資料契約保證同一筆訂單只結帳一次，違約時消費端的檢查會擋下」。
  • 「spinner 撐不住使用者的耐心」：佔住的是等待時間與使用者能接受的長度，寫出那個長度與該給的進度回饋。
  • 「橋接與適配器撐住過渡期」：佔住的是相容性要維持多久、維持哪些介面。

偵測

1python3 scripts/physical-verb-scan.py                       # 全站分類計數（預設排除 report 與 skills）
2python3 scripts/physical-verb-scan.py --list 失效結果        # 列出某一類的每一行
3python3 scripts/physical-verb-scan.py content/backend        # 只掃指定路徑

腳本依詞形與同一行是否有負載詞預先分類，是啟發式。2026-10-14 全站 620 行命中：足夠性（負載）171、失效結果（故障擴散）86、關係 88、字面或技術 82、足夠性（其他）71、失效結果（過載）57、突發緩衝 30、負擔 12、失效結果（其他）12、耗盡時間 10、可信度 1。已知的分流誤差：「關係」裡有不少是設定裡的實際附掛（IAM policy、trust policy 掛在某個身分上），屬於字面或技術；「扛」與「垮」跨類的那些要看句子改判。分類是交給逐篇改寫的起點，不是判定。

改寫不做全站一次替換：每一處要寫出那個情境自己的需求、門檻或機制，替換腳本寫不出這些內容。

論述基礎與限制

本卡的依據是一次規則修訂與一次全站掃描。修訂來自一位讀者的指認：「撐」先前以借用物理直覺禁用，而它是「問題」的變體，修法要描述滿足需求的標準與機制；同一位讀者再指出清單裡的其他動詞也要一起評估。分類表是主 session 依全站抽樣歸納的，每一類各看過數句到十數句，沒有逐行判讀；腳本的類別計數是啟發式的結果，誤差方向見〈偵測〉。負載情境的容量、過載、故障擴散、突發緩衝與耗盡時間和站內知識卡的對應已逐一確認卡片存在，沒有逐張核對卡片內容與這裡的描述是否一致。

跟其他抽象層原則的關係

判讀徵兆

訊號該做的事
句子裡有撐、扛、垮、頂、掛在、站得住、咬合、啃先判斷它佔住哪一格（足夠性、失效結果、負擔、關係、可信度、字面），再寫出那一格
「拖垮」「壓垮」讀完只知道後果嚴重寫出哪個元件失效成什麼樣子、經由哪一項共用資源傳過去
「撐得住」被改成「足以支持」「可靠」「維持不久」同一個空位換了個詞，回報為未修；寫出需求、判斷標準與機制
修法把一個具體容量數字寫進通則句改寫成句子的形狀與去哪裡量；具體數字只留在文章自己的範例情境並標明來源
「負載很高」「流量太大」沒有單位寫出是哪一種負載（請求數、連線數、寫入數、資料量）

Case

2026-10-14，同一個 session 先依讀者指認把「撐」的足夠性斷言改歸到「問題」那一類（#234、#374 的修訂），並取消系統負載的豁免；讀者接著指出負載議題值得專門討論「撐不住」是變慢、崩潰還是無回應，交給正在寫相關內容的另一個 session；再指出「除了撐，寫作 skill 列出的其他動詞也可以加入評估考量」。