這個概念出自哈佛商學院 Amy Edmondson 1990 年代的研究，而它的起點是一個反直覺的結果。她研究醫院團隊時預期表現好的團隊犯錯較少，資料卻顯示表現好的團隊回報的錯誤更多。追下去才發現差別出在回報率而非犯錯率——好團隊敢講，差團隊的錯誤只是沒有被記下來。後續三十年跨產業的研究從這裡展開。

它衡量的不是氣氛

最常見的誤讀是把它當成「大家相處愉快」。Edmondson 的框架把心理安全感與績效標準當成兩個獨立的軸：

• 兩者都高是學習區——敢講、也真的要求做到
• 安全感高而標準低是舒適區——相處愉快而沒有產出
• 標準高而安全感低是焦慮區——要求嚴格但沒人敢說做不到
• 兩者都低是冷漠區

導入時最容易滑向舒適區，因為「對人溫和」比「讓人敢講難聽的事」容易做到。兩個軸要分開看，是這個概念在操作上最要緊的一件事。

為什麼它是其他判斷的地基

一個組織的多數管理工具都預設回報反映實情：指標可信、檢討找得出原因、承諾說得出真話。心理安全感低的時候這個前提失效，而失效的形式是所有訊號都正常，只有結果不對——指標漂亮、檢討順利、時程準時給出，然後專案照樣失敗。

這也讓它特別難自我診斷：沉默的組織裡沒有人會回報「我們正在沉默」。可觀察的替代訊號是回報的方向性——壞消息與好消息的比例、誰先知道問題、問題從發生到被說出口隔多久。

跟相鄰概念的關係

無指責檢討（blameless postmortem）是它在事故場景的制度化：制度可以照抄，但講真話的意願不行，所以照抄制度而安全感沒建立起來的組織，檢討會變成另一種表演。偏差正常化描述的則是它失效之後群體會怎麼一路放寬標準——每次都沒出事，於是新標準成為基準。

這個概念不處理個人層。事故當事人為什麼看不見當時該看見的東西屬於 人的行為 那一側的認知限制，跟他敢不敢講是兩件事。

要往下讀

概念本身讀 Edmondson 的《The Fearless Organization》，選讀判斷與相鄰書目在 組織文化與心理安全感書單。它在事故流程裡怎麼落成制度，看 事故處理與復盤。

這個概念由社會學家 Diane Vaughan 在《The Challenger Launch Decision》（1996）提出。她重建挑戰者號失事的決策鏈之後，推翻了當時的通俗解釋——那不是有人違規或隱瞞。O 型環的侵蝕在先前多次飛行就出現過，每一次都沒有導致失敗，於是「有侵蝕」從異常訊號變成預期現象、再變成可接受風險的一部分。發射前那場著名的爭論裡，工程師拿不出「這次會出事」的證據，因為判斷基準早就移動過了。

它跟隱瞞的差別在哪裡

這個區分是整個概念的重點。隱瞞有一個知道真相的人；偏差正常化沒有——參與者不是壓下了警訊，是他們真心不再認為那是警訊。所以事後追查「誰知道而沒說」會落空，而落空之後常見的結論是「大家都盡力了、只是運氣不好」，那同樣錯過了真正可改的東西。

可改的東西是判斷基準怎麼被移動的：哪一次的例外沒有被記錄成例外、哪一個「這次先這樣」沒有設回收期限、哪個原本要簽核的動作變成口頭同意。這些是可以留下痕跡、也可以設計制度去攔的。

哥倫比亞號 2003 年失事後，調查委員會的報告直接引用了 Vaughan，並指出同一個模式在同一個組織裡再次完整發生——這也說明偏差正常化不是可以靠一次事故教訓「學會」的東西。

軟體團隊的對應形態

同一個機制在軟體組織裡很容易辨認，因為每一步都有當下的理由：

• 這次先跳過測試，因為要趕修這個線上問題
• 這次手動改生產環境，因為改設定比走流程快
• 這個警報先靜音，因為它最近一直誤報
• 這次先不寫檢討，因為影響範圍很小

單看每一條都不算離譜，而問題在於沒出事本身被當成了做法沒問題的證據。跑十次沒事的手動改機，跟跑十次沒事之後第十一次改錯，是同一個做法。

辨識訊號是「上次也是這樣」開始被用來當理由——那句話在說的正是基準已經移動。

跟相鄰概念的關係

它跟 心理安全感 都會讓組織收不到壞消息，但機制不同：心理安全感低的組織裡有人看見了而不敢講，偏差正常化的組織裡沒有人覺得那件事需要講。修法因此也不同——前者要改組織對壞消息的反應，後者要在制度上讓例外留下痕跡並強制回收。兩者疊在一起時最難救，因為既沒有人認為要講、就算有人想講也沒有安全的說法。

它跟 後見之明偏誤 是事故調查裡的一對：後見之明偏誤讓調查者以為當時的訊號很明顯，而偏差正常化解釋了那些訊號當時為什麼真的不明顯——它們已經被納入正常範圍了。忽略後者的調查會停在「他們怎麼會沒發現」，而那個問句無法產出任何改動。

要往下讀

完整的個案重建看 Vaughan 的原書，它是八百頁的學術專著；選讀判斷與較輕的替代路徑在 事故、歸因與無指責檢討書單。把例外留下痕跡、設定回收期限這類制度實作，看 事故處理與復盤。

打上げ管制隊是為單次發射編成的任務編組

JAXA 每次發射前公布的打上げ計画書（發射計畫書），「打上げの実施体制」一節用一句話交代這支隊伍的性質。H3 火箭 6 號機（30 形態試驗機）2026 年度打上げ計画書（PDF）的寫法是：

打上げ整備及びロケット打上げを行うため、図-2 に示す打上げ実施責任者を長とする打上げ管制隊を編成する。

大意：為了進行發射整備與火箭發射，編成一支以打上げ実施責任者（發射實施負責人）為隊長的打上げ管制隊。

「編成」承載的概念是任務編組：發射整備到發射是一段有起訖的任務，人員為這個任務組成一支隊，由單一隊長統領。JAXA 給大眾看的隊員專欄 プロジェクトSEED −種−（H-IIA 13 號機，2007）的開場白把這個性質講得更直白：

JAXAでは、H-IIAロケット打上げ時に、通常の組織の枠を超えた組織横断的な、「打上げ管制隊」が編成されます。

大意：H-IIA 火箭發射時，JAXA 會編成一支跨越平時組織框架、組織橫斷的打上げ管制隊。專欄裡每位隊員的署名同時標出班與平時所屬單位——企画班（企劃班）的隊員平時在筑波宇宙中心的資訊系統部門、総務・渉外班（庶務與對外聯繫）的隊員平時在鹿兒島宇宙中心管理課、射場安全班的隊員甚至是承包商公司派駐的人員。每次發射的計画書各附一張該次的編成圖，班的組成隨機型與任務調整。

同一批發射工作也能用常設組織的視角畫。2025 年 8 月公布的 H3 火箭 7 號機打上げ計画書（H3 各機的發射順序與機號不完全一致，7 號機先於 6 號機發射）畫的是鹿兒島宇宙中心的常設單位（ユニット是 unit、グループ是 group），圖上沒有「班」這一層；兩份文件的打上げ実施責任者是同一人，文件未說明什麼情況用哪一種畫法。兩種畫法對照出「編成」的語意：常設單位是平時的組織，班是為發射任務組起來的單位，同一批人在兩張圖上以兩種身分出現。

指揮結構把執行與安全監理分成兩條線

H3 6 號機計画書第 5 頁図-2「H３ロケット６号機打上げ管制隊組織」的結構如下。縮排代表下轄關係，主任右側橫線後接的是該主任管的班；圖中的日文詞：ロケット是火箭、システム是 system，企画即企劃、広報即公關、渉外即對外聯繫、総務即行政庶務。

 1打上げ実施責任者（管制隊之長）
 2├─ 打上げ執行責任者
 3│    ├─ 企画管理主任 ─ 企画班、総務班、広報班、渉外班
 4│    └─ ロケット主任 ─ ロケット班、設備班
 5├─ 打上げ安全監理責任者
 6│    ├─ 飛行安全主任 ─ 飛行安全班
 7│    ├─ 射場主任 ──── 射場班
 8│    └─ 保安主任 ──── 射場安全班、警備班
 9├─ 法定保安責任者
10└─ システム安全評価責任者

隊長之下，執行與安全監理各有一位責任者。執行線下轄企画管理與ロケット兩位主任，涵蓋把火箭與地面設備整備到可發射狀態、以及時程預算公關這些協調工作；安全監理線下轄飛行安全、射場、保安三位主任，涵蓋發射對人員與周邊環境的風險。法定保安責任者與システム安全評価責任者直屬隊長，在兩條線之外。

安全側的獨立性在 H3 7 號機那份計画書的體制圖上更明顯：發射可否的判斷拆成総合、執行、安全監理三份，由三個人各持一份。「能不能發射」這個決定裡，安全監理側有自己獨立的一票；用單一個「發射指揮官」去概括這個結構，會抹掉安全側的獨立否決權——管制隊編成圖上的單一隊長是文件明文，判斷權的分持同樣是文件明文，兩者並存。

指揮的物理節點是総合指令棟（RCC：Range Control Center）。H-IIB 1 號機的種子島 press kit（PDF）術語表的定義：對發射前作業、地上安全、發射與追蹤的全部作業進行指令管制，同時是島內各雷達站、遙測站與下游追蹤所之間連絡調整的中樞。

班是分工單位、顆粒度隨任務調整

班承擔實際工作，分工循著「火箭本體、地面風險、協調行政」三個方向展開。把編成圖上的班名配上隊員專欄的第一人稱職掌自述（プロジェクトSEED，2007）與 press kit 的術語定義，各班的功能是：

• ロケット班、設備班（ロケット主任）：火箭本體與支撐它的地面設備。設備班（2007 年當時的班名是施設設備班）隊員的自述是「H-IIAロケットの打上げに関わるあらゆる設備のお守り役」（大意：與發射相關的所有設備的照護者）——火箭進場到升空為止，讓組裝與機能點檢所用的設備保持健全，讓發射作業能照時程進行；自述者所屬的射點系電氣係，工作是維護讓發射管制室能遠端操作與掌握火箭狀態（各部位壓力、溫度、閥門開度、電池充電）的通信與資料處理設備。ロケット班的職掌自述在公開材料裡沒有找到，從編成位置推斷是火箭本體側的整備、點檢與發射作業——press kit 術語表把「発射管制」定義為倒數時射點系作業的進行管理。
• 飛行安全班（飛行安全主任）：press kit 術語表把「飛行安全」定義為：守護地面安全，不受火箭投棄物（燃燒完畢的固體輔助火箭、分離後的第一段燃料箱等）或火箭異常飛行的危害。計画書的操作描述是「発射後のロケットの飛行安全については、取得された各種データに基づきロケットの飛行状態を判断し、必要がある場合には所要の措置を講ずる」（依取得的各種資料判斷火箭飛行狀態，必要時採取所需措施）。
• 射場安全班、警備班（保安主任）：射場安全班隊員的自述是「射点を含む射場全般の安全確保」——發射當天要確保以射點為中心半徑三公里的陸上、以及火箭飛行方向大範圍海上的安全。2005 年計画書的安全確保節寫出這套警戒作業的全貌：陸上人員管制並協請縣警與警署、海上以監視雷達與警戒船並協請海上保安本部、射場上空協請航空當局，對周邊船舶用黃旗、紅旗與煙火信號周知發射時刻。飛行安全班與射場安全班守的都是地面上的人，分工在威脅來源：射場安全班管發射作業現場與警戒區的進出，飛行安全班管升空後的火箭本身。
• 射場班（射場主任）：發射後的火箭追蹤與資料取得。射場班隊員（RCO，射場管制官: Range Control Officer）的自述：追蹤站遍布島內外——種子島內數站、小笠原追跡所，該次任務還經資料中繼衛星借用 NASA 的 Goddard 站；追蹤作業由各站擔當與計算係組成，RCO 指揮統括這一連串作業。press kit 術語表對 RCO 的定義一致：指揮統括雷達、遙測、通信等射場系設備與其運用者。
• 企画班（企画管理主任）：管制隊的「人、錢、資訊」。隊員自述的職掌是「打上げの組織編成、予算管理、スケジュール調整および気象観測業務など」（發射的組織編成、預算管理、時程調整與氣象觀測業務等）的協調工作，旗下另有情報ネットワーク管理係（資訊網路管理組）維持種子島、筑波與東京之間的網路與系統，發射實況轉播也由企画班員擔任。
• 総務班、渉外班、広報班（企画管理主任）：総務班管臨時器材（影印機、傳真機、兩百台臨時行動話機）的租借與維護調整、以及隊員的勞務管理；2007 年當時総務與渉外合併為一班，班長自述向十五個地元機關辦發射說明會屬総務側的業務、要人視察的交通食宿接待屬渉外側的業務。広報班對應媒體採訪、擔任發射實況與記者會轉播。

班名是跨年代穩定的分工詞彙，班的數量與層級則隨機型與年代改組。H-IIA 8 號機打上げ及び追跡管制計画書（2005）用的詞還是「打上げ隊」，十個主任直接掛在打上げ実施責任者之下，班也拆得最細（另有射点安全班、飛行解析班、施設班、品質管理班、ペイロード・インターフェース班等）；H-IIB 3 號機（2012）收斂成五位主任、「打上執行主任」的名稱首見、射場安全與警備也在這份合併到保安主任底下；執行與安全監理分成兩位責任者的層級，四份文件裡最早出現在 Epsilon 5 號機（2021）——該份在ロケット主任底下放的是ロケット班與ＰＩ班（ペイロードインタフェース班，酬載介面），沒有設備班。ロケット班、飛行安全班、射場安全班、企画班四個名稱在這四份跨二十年的文件裡全部出現——結構會改組，分工的詞彙不動。

氣象是掛在協調線下的業務、獨立成組是另一種體制設計

四份編成圖上都沒有気象班。氣象工作本身存在——2007 年的隊員自述把氣象觀測跟組織編成、預算管理、時程調整並列，同屬企画班的協調業務；氣象歸屬的正面證據只有這一條、年代較早。發射因天候延期是大眾對火箭發射最熟悉的印象，而四份編成圖都讓氣象以業務形式存在——業務的分量跟它有沒有獨立的編組是兩件事，由體制設計決定。

同一個功能在別的體制可以是獨立編組：台灣國家太空中心的一份 太空發射場域建置與安全考量簡報（2022）裡，發射單位底下有「天候監控小組」，太空中心側另有「天候及海域監控小組」。漫畫把氣象畫成跟射場安全、飛行安全同級的組別，對應的是這一種設計。

漫畫那組分法是編成的選錄

回到起點的那組並列：射場安全、飛行安全、設備、火箭四個組名跟 JAXA 編成圖上的班字面一致，四者也確實同層級——都是主任底下的班；發射指揮官對應圖頂點的打上げ実施責任者；氣象是企画班職掌下的業務。略去的是企画、総務、広報、渉外、射場、警備這半邊——協調、行政、公關與追蹤的工作，跟「發射當下誰在做什麼」距離較遠。這份名單是對編成的選錄，選的軸是發射當下的可見分工；編成圖自己的軸是責任歸屬，所以管理與對外那半邊在圖上跟安全側同樣是班。

這套組織概念的工程應用——把任務編組、安全分線、業務與編組之分抽成評估工作團隊設計的判讀方法——見 發射管制隊視角：評估工作團隊設計的判讀方法。

發射管制隊的體制事實（編成方式、指揮結構、各班分工、文件來源）整理在 火箭發射團隊的組織概念，本文取用時只帶結論。五個 lens 是對這套體制的選錄，選錄軸是「可遷移到軟體團隊的結構判準」——體制裡的法定角色（外部強制、無需判讀）與班名跨年代穩定（命名慣例、非結構選擇）因此不入選。

推導源頭：結構選擇要能被正當化

組織結構是被任務風險、協調成本與編組成本這類理由正當化的選擇；外部強制（法規、合約）也是合法的正當化來源——編成圖上「法定保安」這種名字裡就冠著法定的角色，理由寫在名字上。功能的存在與組的存在是兩個獨立的事實，中間隔著一個要被回答的理由。發射體制的分工單位是「班」（相當於小組）：氣象工作的分量明擺著（天候是計画書延期條款明列的理由），它仍然只是掛在企画班（企劃班）底下的一項業務、沒有自己的班；反過來，行政與公關這類看似外圍的工作，在編成圖上有正式的班。每個 lens 都在問同一個問題的一個面向：**這個結構選擇的成本，由什麼正當化？**給得出理由的結構留下，給不出的進缺口清單。

前置定位：受評團隊在編組成本光譜的哪一端

同一組 lens 在光譜兩端的判讀方向相反，跑 lens 之前先定位。

人類團隊的編組成本高：多一個組要實際派人、佔實際人力，於是失效方向是該編不編——大型任務捨不得抽人組任務隊，用日常組織硬扛跨部門協調；審查職能捨不得獨立，掛在交付主管底下當兼職。評估人類團隊時，lens 主要在找「缺了的結構」。

Agent 團隊的編組成本趨近零：多一個 agent 只是多一個定義檔，於是失效方向是不該編也編——每個功能都立一個 agent、名冊持續膨脹，每次任務的協調面積跟著變大，協調成本反過來成為主要成本。評估 agent 團隊時，lens 主要在找「多了的結構」與「有名無實的結構」。

方向差異只適用編組數量軸（要不要為功能成組）。協調結構——編成記錄、指揮中樞、交接承擔者——在兩端都往缺的方向失效：人類團隊靠默契與口頭補位、agent 團隊靠主 context 順手兼任，缺口的形式不同、缺是同一種缺。方向也是預設而非定律：它成立的前提是決策者自己承擔編組成本，編組是地位資源的組織裡（headcount 代表位階、成本由整個組織吸收），人類端同樣會過度編組。定位只影響先找什麼，lens 的判讀問題本身兩端通用。

主力 lens：常設 vs 編成

概念。發射管制隊是為單次發射跨越平時組織框架編成的任務編組：有單一隊長、有這次任務的編成圖、任務結束人員回歸常設單位。常設組織按專業分工存在、任務編組按任務需求存在：常設圖回答平時誰養這個能力，編成圖回答這次任務誰在場，兩張圖同時成立。

判讀問題。這件工作有起訖嗎？若有：這個任務的編成圖畫得出來嗎——誰參與、誰是這次的隊長、記錄在哪？任務結束時有解編動作嗎，還是任務隊悄悄變成常設組織？

條件-行動。跨專業或跨組件、有明確起訖、協調密度高的工作（大型 release、migration、incident），顯式編成：指定單一隊長、記錄這次的參與名單、結束時解編。日常反覆的工作由常設分工承擔，每次都編組是儀式成本。Agent 語境：agent 定義檔的名冊是常設層，每張任務單的 dispatch 是編成層；編成要留下記錄（這張任務由哪些 agent 參與、由誰統領），否則事後回答不了「這次是誰做的、誰該看結果」；名冊有四十個角色而每次任務實際只用五個，是常設層與編成層沒有分開的訊號。

失真邊界。發射的起訖由物理事件劃定（火箭進場到升空），軟體任務的起訖要自己定義——以 release 為單位、以 ticket 為單位、還是以 sprint 為單位，選擇不同編成的粒度就不同。起訖模糊時這個 lens 的判讀會空轉，先把任務單位定清楚再用。

主力 lens：執行與安全監理分線

概念。管制隊的指揮結構在隊長之下分成執行與安全監理兩條責任線，發射可否的判斷拆成三份由三人分持——安全側對「能不能發射」有獨立的一票，這一票的行使路徑迴避了交付壓力。

判讀問題。受評團隊裡，審查角色（QA、security、compliance、reviewer agent）掛在哪條線下？「不能上」這一票由誰持有，行使時要不要經過交付方的主管或同一個 orchestrator？

條件-行動。失敗不可逆、有合規要求、或資損等級高的交付，審查線獨立於交付線、否決不經交付方裁量。stakes 低的交付，同線內的角色帽子就夠，獨立線是過度設計。「高」的量尺是相對的：一次失敗的預期代價比維持獨立審查線的成本高出一個量級以上，獨立線才划算——帳面上一比一就打平，抓一個量級是給兩側的估計誤差留安全邊際。這把量尺以人類團隊為預設；agent 團隊要換算成本項——agent 審查線的維持成本趨近零，照原式算永遠該建獨立線，而 agent 端真正的成本是 gate 的誤擋摩擦（false block 的解除成本乘上發生頻率），量尺換成一次失敗的預期代價跟誤擋摩擦的比較。中間形態存在：judgment 分持可以是決策時刻的制度（go/no-go 會議三票缺一不可）而非常設的獨立部門。Agent 語境：reviewer agent 由交付 orchestrator dispatch、審查結果也回到同一個 orchestrator 彙整時，獨立性只是形式——它的否決可以被彙整層「綜合考量」掉。結構上的獨立要看否決的落點：reviewer 直接寫入 gate 狀態（例如 block flag、必過的 CI check），而非以報告形式交回給有裁量權的彙整者。連帶要查 gate 讀的訊號由誰寫入——被審方或裁量方能自己寫入通過訊號的 gate，是形式 gate。可觀察的失效訊號：reviewer 曾標 block 而該版本仍然上線、或審查結果連續多次沒有改變任何決定。

失真邊界。航太的獨立否決權由人命與法規正當化；多數軟體場景的失敗成本到不了那個量級，套用前先過上面那把量尺。這個 lens 的產出是「我們的失敗成本是什麼等級」這個回答本身。

一則常見的走法：團隊為了省協調成本，讓交付 orchestrator 兼管審查的派發與彙整；交付壓力升高後，彙整層開始對個別 block「綜合考量」；每次覆蓋單看都合理、審查報告照常產出，結構缺口沒有任何單一時點的異常訊號——裁量權在彙整者手上時，覆蓋不留結構痕跡；直到一次高代價的事故回查，發現 block 記錄一直存在、只是從來沒有進過 gate，重建的代價是把否決落點改成必過的 CI check、外加一輪回溯稽核。

主力 lens：業務 vs 編組

概念。氣象工作在發射體制的分量極重，卻在編成圖上沒有自己的班，以業務形式掛在企画班（企劃班）的協調職掌下；同一個功能在台灣的發射體系則獨立成「天候監控小組」。功能的分量與它是否獨立成組是兩個獨立變數，成組與否是體制設計的選擇。文件自己沒有說明氣象為何不設班；把兩案並排後，本文對「什麼能正當化一個組」採的詮釋是判斷權：執行工作可以被指派進任何既有組，判斷工作需要一個結構位置來歸屬與行使。判斷權是充分條件、不是唯一來源——編成圖上総務、広報這類班由顯式的責任歸屬正當化（對外協作面 lens 處理的正是這類結構）；本 lens 的判定線是：工作量與重要性不在合法理由清單上，替一個組給得出的理由要是判斷權或顯式責任歸屬其中之一。

判讀問題。這個功能需要獨立的判斷權或否決權嗎，還是純執行的分量？把它併進某個既有組，會失去什麼？

條件-行動。功能需要獨立判斷、持有否決權、或有專屬的責任邊界，編組。功能是純執行、可規則化、判斷可以依附在別的角色上，作為業務掛進協調線或既有組。Agent 語境（這一端的主判讀）：「這該是一個 agent，還是一個 hook、lint 規則、prompt 段落？」可規則化的檢查（格式、命名、連結有效性）做成確定性工具，比 agent 便宜且穩定；已有確定性 CLI 可呼叫的工作（formatter、fixer），agent 只是它的包裝時直接降級；需要情境判斷的工作才值得成為 agent。拿名冊裡每個 agent 問一次「它需要什麼獨立判斷」，給不出答案的就是零編組成本下自行增生的組；名冊另掃兩類衛生——已棄用仍在冊的（除籍）、高權限與零使用並存的（風險殘留，裁或降權）。人類團隊這端方向相反：功能被塞成某人的兼職、而它需要的是獨立判斷權（例如 security review 掛在最資深工程師的空閒時間），是該編未編的缺口。

失真邊界。業務與編組之間存在第三形態（輪值、虛擬小組、任務內臨時指派），二分是判讀的起點而非結論。氣象案例本身也證明同一功能存在兩種合法設計——lens 問的是受評設計自己的理由，而非提供標準答案。

次要 lens：指揮中樞

概念。發射體制的指揮有顯式的物理節點：総合指令棟（RCC）統管發射前作業、地上安全、發射與追蹤的全部指令管制，同時是各雷達站、遙測站之間連絡調整的中樞；追蹤鏈自己也有統括者（RCO、射場管制官，指揮各站設備與運用者）。資訊匯流的位置是被設計出來的——軟體團隊語境裡 war room / situation room 承擔的正是這個角色。

判讀問題。任務期間的單一資訊匯流點在哪？要知道現在的全局狀態，讀哪一份記錄——答案唯一才算有中樞。各執行單位的狀態由誰統括、用什麼形式（狀態檔、dashboard、頻道）？

條件-行動。並行單位達三個以上（單位兩兩之間各有一條直連通道，通道數隨單位數超線性成長，第三個單位起狀態分歧開始需要有人收斂）、或跨線協調存在時，設顯式中樞：單一的狀態記錄、單一的統括者。兩三個順序步驟的任務，主流程自身就是中樞，另立是儀式——中樞自己有維護成本，狀態記錄要有人更新、統括者的注意力被佔用，這也是它要被正當化的原因。Agent 語境：dispatch 狀態檔、PM agent、主 context 三者各持一部分狀態時，等於沒有中樞。恢復中斷的任務要讀三個來源拼湊，就是這個缺口的日常症狀。聚合視圖（把多來源算成一張表的工具）可以充當中樞，但要查它的失敗模式：讀不到某個來源時是浮上來還是靜默略過——靜默失敗的聚合視圖比沒有中樞更危險，它給出「已經匯流」的假象。

失真邊界。中樞是資訊角色而非權力角色。RCC 統管的是作業協調，否決權仍在安全線——把中樞設計成「所有決定都過它」，會把資訊節點變成決策瓶頸。

次要 lens：對外協作面

概念。編成圖的十個班裡有四個在管協調、行政、公關與對外（企画、総務、広報、渉外），加上射場班的追蹤與警備班，發射當下手不碰火箭的班超過半數——通俗介紹略去的正是這半邊。高風險任務的組織設計把非技術面顯式編進結構，跟安全側同樣是班。

判讀問題。受評編組裡，對外溝通與跨期交接（stakeholder 報告、handoff、changelog、公告）有沒有顯式的承擔者？沒有顯式指定時，這些工作實際落在誰身上——那個落點本身就是要被判讀的現狀。

條件-行動。任務有外部利害關係人、或有跨期交接需求時，顯式指定承擔者（一個角色或一個 agent），並把交接產出定成任務的出口條件。純內部的短任務，兼任可行，但 handoff 文件仍要有固定的產出位置。Agent 語境：進度報告與 handoff 沒有指定承擔者、由主 context 隱性承擔時，任務中斷最先被犧牲的就是它：中斷點之後的接手者拿到的是程式碼與半份記憶。健康形態的訊號：交接由固定機制產出（CLI、模板）、有偵測「寫了但沒歸檔」不同步的檢查、archive 有累積。

失真邊界。對外面的編組成本在人類端很實在（專職的溝通角色多數團隊養不起），判讀停在「有沒有顯式位置」，推導到「要有專職」就過頭了。

何時不適用

單人短任務與低協調密度的工作，五個 lens 都會空轉——結構選擇的成本趨近零時，正當化檢核沒有對象。探索期的工作（任務起訖未定、stakes 未知）先做再評，過早檢核會把探索凍結成結構；探索期的結束有訊號——任務的起訖能被定義、失敗成本能被估計時，跑第一次評估。方法論評估的是既有設計的正當性，從零設計團隊要回到任務本身推導（先盤操作與風險、再長出結構），拿 lens 清單當設計藍圖會生出「每個 lens 配一個機制」的過度設計；增量的結構問題（要不要多一個 agent、否決怎麼收）由對應 lens 的條件-行動承接，被排除的是從零的全案設計。

跟既有組織框架的分工：Team Topologies 這類框架給的是設計處方（該長出什麼形狀的團隊），本方法論做的是既有設計的正當化檢核，兩者接在不同時點；incident command（ICS）跟發射管制隊是同型體制（任務編組、單一指揮、獨立的安全角色），可互為佐證。Team Topologies 主張長壽團隊，跟常設 vs 編成 lens 相容——那是常設層的設計主張，lens 問的是任務層要不要另外編組。

使用流程與產出格式

1. 定位編組成本端：受評團隊是人類、agent、還是混合——這決定編組數量軸上找「缺的」還是「多的」；協調結構在兩端都查缺口。
2. 定義任務單位：以什麼為一次任務（release / ticket / incident），這是常設 vs 編成 lens 的前置條件。
3. 逐 lens 判讀：主力三個先跑（常設 vs 編成、安全分線、業務 vs 編組），次要兩個（指揮中樞、對外協作面）在並行單位達三個以上、或存在外部利害關係人時跑。
4. 記錄：每個 lens 記三件事——結構現狀、判讀問題的答案、正當化理由或缺口。
5. 彙整：缺口清單排序成待辦，給得出正當化理由的結構留下記錄，供下次重組時對照。

整套跑之外，日常症狀也可以觸發單一 lens（同一症狀可能指向多個 lens，表列的是首選入口）：

評估的量級：單人、手邊有編成記錄（agent 團隊的定義檔與 dispatch 記錄）時，五個 lens 是小時級的桌面演練；人類團隊要回答「否決由誰持有」這類問題通常得問到當事人，隨訪談對象數以天計。

評估自身也要過自己的 lens——它是一次有起訖的任務，出口條件是：評估記錄有固定位置與承擔者（進團隊的決策記錄或 repo，由發起評估的人歸檔）；判讀欄引可指認的證據（dispatch 記錄、block 事件、編成名單），寫不出證據的判讀標「證據缺口」並列補證行動、不算完成；「不適用」的判定寫進同一份記錄，標明退出訊號由誰複查；整套評估有兩個觸發點——第一次建立基線、之後每次重組；症狀觸發的單 lens 判讀不折抵這兩個觸發點。症狀偵測可規則化（記錄不存在、block 後仍上線，都是工具可偵測的訊號），lens 判讀才是判斷工作。

評估記錄的最小格式：

填出來的樣子（假想的 agent 開發團隊、節錄三列）：

下一步路由

• 體制事實與文件來源：火箭發射團隊的組織概念
• 同型的評估式方法論（從操作推導結構、訪談協議形態）：SaaS 選型訪談方法論
• 團隊設計的既有框架與其適用規模：組織結構與團隊設計書單，本方法論的判讀 lens 與那批框架處理的是同一組決定，差別在這裡從既有團隊往回評估、那裡從空白往前設計。