論述基礎與限制

這張卡來自 2026-10-27 一次全站空 section 的盤點。後端的可靠性模組與效能容量模組各有一組負載測試工具頁(k6、Gatling、JMeter、Locust),兩邊同一個工具的頁面標題一字不差。兩個唯讀分析的 agent 讀同一批頁面,給出相反的判定:一個依兩個模組的規劃(Backlog)寫的「需與對方界定角度分工」判成兩邊保留,一個依段落重疊判成併給效能容量模組。主 session 接著用 WRAP 從讀者的到達路徑分析,列出的選項全是搬移與合併(一個工具只留一頁、放在中立的位置、或一頁加兩篇各模組的概念文章)。使用者否決了這一組選項的前提:同一個工具放在不同的觀點下,內容本來就應該不同,要做的是把兩邊的內容區別開、各自深入;兩邊內容一樣的部分,抽成知識卡。

依這個方向回頭逐段對照 Gatling 那一組,重疊段落的主體是工具本身的事實,帶到模組觀點的只有連回本模組章節的那一兩句(可靠性那一頁把 assertion 連到效能退化的 release gate 章,效能容量那一頁把注入節奏連到找飽和點的章)。可靠性模組那一頁偏工具的使用手冊(最短路徑、simulation 結構、注入節奏、錄製腳本、JVM 調校,另有一節 assertion 與 CI 的子議題清單),效能容量模組那一頁偏工具的選型簡介(選型標準、取捨表、交付的證據);可靠性模組關心的「接 CI 擋 release」在效能容量模組那一頁寫得比在可靠性模組那一頁完整。k6 兩邊各有一篇深度文章,已經照觀點分開(可靠性模組寫 threshold 與 CI gate,效能容量模組寫從 JMeter 遷移);Gatling、JMeter、Locust 兩邊都只有 overview。個案只有這一組工具頁,判斷標準在別的配對上沒有量過;資安模組與可觀測性模組之間的配對形狀不同,是同一家業者的不同產品(Elastic Security 與 Elastic Stack、Datadog Security 與 Datadog),不是同一個工具的兩頁。

核心原則

同一個工具在兩個模組各有一頁時,兩頁是否重疊,取決於頁面從哪一端寫起。從工具往外寫(這個工具是什麼、怎麼裝、有哪些功能),兩頁拿到的是同一批材料,因為工具的事實不隨模組改變;從模組讀者要做的判斷往回推(這個模組的讀者帶著什麼要判斷的事,這個工具在那個判斷裡負責哪一個環節),兩頁拿到的是不同的材料,因為兩個模組的讀者要判斷的事不同。以負載測試工具為例:可靠性模組的讀者在負載測試這一段要決定這一版的效能有沒有退化、能不能過 release gate,證據怎麼交給下游;效能容量模組的讀者要決定目前的配置在延遲目標內處理得了多少請求、要加多少機器。同一個 Gatling,在前一種判斷裡負責產生 regression 的證據,在後一種判斷裡負責找出受測服務的飽和點。

分段時依序問兩件事:

  1. 這一段是不是操作細節(安裝、設定步驟、介面操作)。是的話屬於實作文章或官方文件,頁面連過去即可。
  2. 其餘的段落,原封不動放進另一個模組的同名頁面,還成立嗎。 這是假設性的問句,不論另一頁現在有沒有這一段;比對的是內容、順序與輕重,段標相同不算成立。兩頁都成立而且是一個概念的(工具所屬那一類做法的通用模型:負載測試的 open 與 closed model、注入節奏、虛擬使用者、施壓端飽和),屬於知識卡,兩頁原本的那一段都改成一句連到卡,各自寫出這個概念在本模組的判斷裡起什麼作用;兩頁都成立而拆不成單一概念的(版本沿革、JVM 調校、商業版與開源版的差異),是工具層的深度內容,寫成其中一個模組那邊的 deep article,另一頁連過去,因為建成卡會變成承擔好幾個語意責任的「Gatling 排錯」這類傘狀卡;只在本頁的模組成立的是本模組的觀點,留在本模組的頁面,並往下寫深;只在另一個模組成立的是寫錯頁的觀點,移到另一個模組的那一頁。

兩道問句分開問,因為操作細節放進另一頁也照樣成立,只問第二道的話它會被歸成知識卡。一段裡混了兩類以上(操作步驟與判斷、通用模型的事實與它在某個模組的後果)時,先照類別拆成幾段再逐段問。觀點段落裡用到通用概念時(容量那一頁的排錯段提到施壓端飽和),概念連到卡,排錯的順序與權重留在本頁。

兩頁差別最大的位置,是模組規定每一頁都要寫的標準章節:取捨表、排錯判讀、工具定位。這幾節的段標在兩頁相同,看起來最像該共用的內容,而兩個模組的工程師在這裡衡量的取捨不同,除錯時先查的症狀、查的順序與每一項的權重也不同。同樣看到 p99 變慢,可靠性的工程師先比對這一版跟基準的差距、找出退化的 endpoint,決定擋不擋 release;容量的工程師先確認施壓端沒有先飽和,再看受測服務哪一項資源先到頂。這幾節是讀者最需要、也最沒辦法從官方文件拿到的內容,所以兩頁都寫,各自照模組工程師的視角寫深。審查時一度把這些標準章節判成要移出頁面的共通內容,理由是兩頁的段標相同;使用者指出順序與權重本身就是觀點,這個判定才改過來。

重疊被看成「兩邊在維護同一份東西」時,直覺的處置是合併或指定唯一的家。照兩頁現在從工具往外寫的樣子合併,合併後的那一頁仍然從工具往外寫,留下來的是通用材料,另一個模組的觀點段落在那一頁沒有位置。這一點是推論:這次沒有實際合併任何一組頁面。重疊的成因在頁面從工具往外寫,處置也落在寫法上:分段、抽卡、各自往觀點裡寫深。

反模式

  • 把重疊當成住址問題:問「這份內容該放哪一邊」,答案只能在兩頁之間選一頁或搬到第三處,問題本身已經假設兩頁該寫同一份內容。
  • 規劃寫了「界定角度分工」而沒有判斷標準:兩個模組的規劃都寫了要跟對方界定角度,頁面照樣重疊,因為「角度」沒有落到任何一段可以檢查的位置。
  • 依哪一頁比較完整決定誰留下:完整度量的是通用材料寫得多不多,跟哪一頁的觀點比較有內容無關。
  • 同名的標題:兩頁都叫工具名,讀者在搜尋結果與連結文字上只看得到標題與 description,分不出兩頁的差別,作者也少了一個逼自己說出觀點的位置。

修法

  1. 兩頁並排,逐段依序問上面的兩道問句,把每一段歸成操作細節、知識卡、本模組的觀點三類。
  2. 歸成知識卡的段落,先查站上有沒有對應的卡(這一組有負載測試、飽和點與 workload model 的卡,open 與 closed model、注入節奏、虛擬使用者沒有卡),沒有就照建卡原則建卡,一段裡有幾個概念就拆成幾張,兩頁改成連卡。
  3. 歸成本模組觀點的段落,從本模組讀者要做的判斷往下寫深:可靠性模組寫 regression 證據的留存與交接、threshold 失敗怎麼擋 release;效能容量模組寫飽和點的找法、怎麼確認施壓端不是瓶頸、量測結果怎麼換算成受測服務要加的機器數。
  4. 標題與 description 寫出觀點(「Gatling:regression 證據與 release gate」對「Gatling:容量探測與注入節奏建模」)。
  5. 分類之後某一頁歸成本模組觀點的段落是 0 段時,那個模組的章節可以改成直接連卡;這一頁的去留另外決定,不在分段這一步裡刪頁或搬頁。

判讀徵兆

徵兆判讀
兩個模組的同名頁面,段標大半相同或內容可以互換兩頁都從工具往外寫,重疊的段落是知識卡或操作細節的候選
一個模組關心的判斷(例如 CI gate)在另一個模組的頁面寫得比較完整那一段沒有照觀點分配,搬回所屬的模組或抽成卡
分析時列出的選項全是合併、搬移、指定唯一的家選項建立在「兩頁該寫同一份內容」的前提上,先逐段分類再談搬
同一個工具的深度文章已經分得開,overview 卻重疊重疊在 overview 的寫法,不在資料夾結構
分類之後某一頁的觀點段落是 0 段那個模組的章節可以直接連卡;頁面的去留另外決定

跟其他抽象層原則的關係