發射管制隊的體制事實（編成方式、指揮結構、各班分工、文件來源）整理在 火箭發射團隊的組織概念，本文取用時只帶結論。五個 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 與那批框架處理的是同一組決定，差別在這裡從既有團隊往回評估、那裡從空白往前設計。