# HACTS-08｜最小必要管理與休眠專案：為什麼不持續管理，也可能是一種有效治理

## 從專案資產的休眠權、管理內生負債與風險事件觸發，到人類注意力主權與 AI 原生組織的最小治理原理

**English title:** *Minimal Necessary Governance and Dormant Projects: Attention Sovereignty, Option Preservation, and Risk-Triggered Portfolio Stewardship in Human–AI Production*  
**系列：**《人機耦合時代的時間主權與創造自由》（Human–AI Coupling, Temporal Sovereignty, and Creative Freedom；HACTS）  
**篇次：** 08／10（第三卷第一篇；承接 HACTS-00～07）  
**文件編號：** EML-HACTS-2026-08-v0.1  
**版本：** v0.1  
**日期：** 2026-10-17（Asia/Taipei）  
**思想提出與研究策劃：** Neo.K  
**AI 協作研究與論文初稿整理：** GPT-6  
**研究場域：** EveMissLab／無界智庫  
**文件性質：** 理論論文／人機耦合生產／組合式專案治理／風險觸發監督／休眠資產／時間主權／可否證研究綱領  
**狀態：** 詳細研究初稿；未經同儕審查；本文的新增機制與係數尚待獨立實證  
**Canonical source：** 本 UTF-8 Markdown 檔案；正式數學原始碼僅使用 ` $...$ ` 與 `$$...$$`  
**重要邊界：** 最小必要管理不是無治理；靜態封存不是持續安全更新；研究休眠不能免除法律、合約、安全、服務或資料保護義務。

**作者：** Neo.K  
**機構：** EveMissLab／一言諾科技有限公司  

---

## 摘要

AI 協助研究者、創作者與微型組織快速建立大量理論、原型、程式庫、網站、遊戲和工具，使可保存的成果數量可能遠快於人類可持續管理的注意力增長。既有多專案管理觀點傾向解決「如何把所有項目看清楚、排好優先級、建立進度與維護清單」的問題；然而，對擁有大量已完成階段性成果、尚未承諾外部交付、且未必需要持續更新的研究資產而言，這種全面管理本身可能成為新的工作來源。為了減少一百個專案的負擔而逐一盤點、分級、更新、檢討，甚至建立另一個 AI Agent 長期追蹤所有專案，可能反過來擴張治理時間、通知量與人類決策佇列。本文把這一現象稱作「管理內生增殖」（Endogenous Governance Proliferation）：對既有選擇權投入更多管理，卻使管理活動持續生成新的管理義務。

本文提出「最小必要管理與休眠專案」（Minimal Necessary Governance and Project Dormancy，簡稱 **MNGPD**）框架。核心主張不是讓所有專案無條件停止維護，而是將「資產仍然存在」「專案仍具有未來選擇權」「現在存在必須履行的義務」「當下需要人類投入」分成四個不同命題。若一項成果沒有正在運行的服務、外部依賴、合約承諾、資料安全暴露或可觀測的不可逆損失，它可以被妥善保存而不進入高頻管理流程；若其對外服務、相依安全、金流或使用者承諾持續存在，則最低治理義務仍需可靠履行。**研究資產的存量並不自然生成等量的待辦義務。**

本文引入「義務來源帳本」「有效休眠集合」「人類注意力治理預算」「管理增殖迴路」「事件觸發治理」「可恢復性閘門」與「對外依賴例外」等操作性概念。以有限期多專案決策模型表達管理、保存、委任與退出的成本；在明示假設下推導週期檢查頻率與風險事件率的關係，並比較固定排程與風險觸發的監督效益。本文尤其強調：只需為能夠觀測且應由誰承擔的義務設立管理路徑，不應把 AI 產生的新構想、延伸方案或尚未承諾的 Phase 自動升格為人類必須完成的工作。

八組數值思想實驗、十四項可否證假說及四種實證設計展示本文的成立區域與反例。模型預測在「可安全保存、外部責任低、事件稀疏、人工檢查成本高」的區域，選擇性低干預可能降低總管理人時而不顯著降低有效資產保存率；但在「對外暴露高、偵測品質差、使用者高度依賴、重啟成本增長快」的區域，低干預可能反而增加事故、責任與未來損失。因此 MNGPD 不是所有專案都採用同一休眠政策的普遍公式，而是以**最低必要安全與責任條件為硬約束，最小化持續佔用人類注意力的治理行動**。

本文承接 HACTS-07 的未來自我技術等待選擇權，並與 EveMissLab 既有 HODR、HAVT、AI 原生多專案治理、EVEMISS Registry、委任時間論、HDUS／ANDO 治理架構相接。其哲學結論是：**有能力管理，不代表每一刻都有必要管理；有能力繼續創造，不代表所有尚存的創造都必須持續索取創作者的時間。** 成熟的人機耦合組織不以人類永遠在線和所有專案持續前進為前提，而應能讓不再需要被管理的成果安靜存在，並保留必要時重新啟動、重新授權、修改方向或體面退出的自由。

**關鍵詞：** 最小必要管理、休眠專案、低干預治理、管理內生增殖、專案選擇權、管理成本、風險觸發、事件驅動監督、人類時間主權、注意力稀缺、認知待命、軟體資產組合、有效保存、重新啟動、外部承諾、AI 原生組織、委任治理、可否證命題。

---

# 0. 研究問題：為什麼連「少管一些專案」都可能變成管理專案？

## 0.1 情境的反直覺性

設想某位獨立研究者在 AI 協作後累積大量程式庫、研究原稿、遊戲原型與內部工具。這些成果的進度不一致：部分已可獨立驗證、部分可直接部署、部分僅用作未來研究的語義與工程參考。面對數量龐大的資產，傳統流程會要求先列出所有清單、逐一標記狀態、設定責任人、排定更新週期、分配標籤、生成提醒並建立儀表板。

但如果清單有一百個項目，每項每月只需要十分鐘決策，光是例行審查就要花費一千分鐘；而每次審查還可能新增補文件、修相依、開 Issue、更新 Roadmap、通知 Agent 的工作。於是以降低管理負擔為名，建立了一套自我延續的新工作結構。

這不表示所有整理都是浪費；若涉及付費客戶、正式對外服務、安全風險或專案交接，紀錄與管理可以有很高價值。真正的問題是：**為何一項已保存、暫不需要行動的資產，必須被反覆喚醒成為今天的工作？**

## 0.2 四個命題必須分離

對成果 $i$ 而言，以下陳述彼此不等價：

1. **存在命題**：現在存在可識別的成果或原稿。
2. **選擇權命題**：未來存在可恢復、可修改或可利用的可能路徑。
3. **責任命題**：存在需要遵守的法律、合約、權利、安全或對外服務義務。
4. **即時行動命題**：此時此刻需要人工、AI 或機器執行特定治理行動。

即使前兩項為真，也不必推出第四項；第三項為真，也不必然要求人類逐日審閱，而可能要求一套合格的自動監測、服務團隊或受權委任。本文最小命題為：

$$
\mathrm{AssetExists}_i=1
\quad\not\Rightarrow\quad
\mathrm{ImmediateHumanTask}_i=1.
$$

又有：

$$
\mathrm{FutureOption}_i>0
\quad\not\Rightarrow\quad
\mathrm{ContinuousManagement}_i>0.
$$

但反面必須保留：

$$
\mathrm{ExternalDuty}_i=1
\quad\Rightarrow\quad
\mathrm{QualifiedDutyHandling}_i=1.
$$

最後一個式子是規範性要求，並不證明任何既定法域或服務契約都已被履行。

## 0.3 何謂「有效管理」

在本文中，管理不是介面操作量、報告數、提醒數或已建立的流程數。管理是一種使合法義務、風險控制、可恢復性及資源選擇被正確處理的行動集合。

因此，一套工作繁忙但不斷創造低價值審查的系統，未必比一套只在明確需求或風險出現時行動的系統治理品質更高。

---

# 1. 系列與既有研究的邊界：避免重新發明已存在的論文

## 1.1 HACTS-00～07 的承接

| 篇次 | 已回答的核心問題 | 本篇所新增的問題 |
|---|---|---|
| HACTS-00 | 為何高 AI 產能不自動帶來時間主權 | 人是否能把「不必管理」制度化 |
| HACTS-01 | 產能提高也可能內生生成更多工作 | 管理行動本身能否再生產管理需求 |
| HACTS-02 | 失效配額可能反向安排人類時間 | 管理系統是否受到例行提醒與計時觸發支配 |
| HACTS-03 | 高創造滿足與疲勞可同時存在 | 高投入者能否在不失去資產的情況下結束一段投入 |
| HACTS-04 | Agent 結果佇列與人類待命是不同負荷 | 通知與審核何時應真正進入人類注意力 |
| HACTS-05 | 繼續、延後、休眠、退出及回返構成不同決策 | 哪些休眠狀態可以不持續審查仍保留實際自由 |
| HACTS-06 | 不同研究具有不同歷史窗口與先發風險 | 管理是否能被窗口事件觸發而非固定逐日推進 |
| HACTS-07 | 保存可重啟研究資產可能保留未來選擇權 | 如何不把資產保存變成永久管理債務 |

本篇不再重新推導全部技術等待價值，而專注於**休眠之後需要多少、何種、由誰執行的治理**。第 09 篇才深入處理企業資金與生存期限，第 10 篇才深入設計 HDUS／自主組織中的具體 AI 人類節奏契約。

## 1.2 已存在的 EveMissLab 研究

**[I1]《AI 原生多專案治理與來源可信性》**已提出跨倉庫的資產組合、來源血緣、權限與風險分級，並指出單一儲存庫管理不足以處理大量軟體資產。本文不同之處在於：完整治理能力可以存在，但未必應對所有專案高頻啟用。

**[I2]《EVEMISS Registry：分級產品索引與管理控制台》**已區分 PUBLIC、PREVIEW、INTERNAL、PRIVATE，以及產品、研究、網域與專案之間的索引關係。本文不是再設計另一座更複雜的中樞，而是提出：索引應支援**低注意力可用性**；不需要以增加排程、統一盤點或對所有專案產生進度更新作為成功條件。

**[I3] HODR-II／IV**已提出選擇權囤積、可能性負債、生產—現實化失衡與停止規則稀缺。本文將它們轉寫為管理層的問題：「每次整理是不是又生成更多必須回覆的任務？」

**[I4] HAVT-06／07**已把時間主權與不被最快技術節奏強迫同步建立為制度性命題。本文將其應用至個人專案及 AI 原生組織的日常治理。

**[I5] AI 原生分散式組織與委任時間論**已區分操作員退出和治理退出。本篇新增的是：如果沒有實際義務或高價值事件，人類也未必需要執行「治理判斷」；但若有不可替代的外部責任，必要監督仍不能因休眠口號而消失。

**[I6] HDUS Enterprise Governance Runtime**已區分 Policy、Authority、Decision、World Commit，拒絕把所有治理狀態壓成 `allowed=true/false`。本文沿用此分離，避免把 `dormant` 當成可以繞過授權與責任的通行證。

**[I7] HACTS-07**已提出有效保存、可恢復性與重新啟動門檻；本文僅使用其接口，不冒充重新提出同一思想。

## 1.3 本文提出的增量

本文新增的具名整合框架為 **MNGPD**，包含三個互相關聯、但待檢驗的命題：

- **管理內生增殖命題**：管理活動可能生成額外管理工作，使本來用於降低負擔的系統成為新負擔。
- **有效休眠命題**：若資產可保存、即時風險與外部承諾得到可靠處理，專案可以在沒有例行人類干預時保留部分可行價值。
- **風險觸發最小治理命題**：在特定偵測品質、損失結構與監督成本條件下，只處理需要處理的事件可能優於全面週期性檢查。

這些不是本文首創所有基本思想；組織注意力、有限理性、風險監測、實質選擇權與 SRE 已有直接先行文獻。新穎性若成立，應來自**把 AI 大規模產出、休眠資產、持續注意力、人類節奏及硬性治理義務結合成一套可否證模型**，不能只靠命名宣告原創。

---

# 2. 外部研究與相鄰理論：我們已知道什麼？

## 2.1 組織的稀缺資源包含決策者注意力

Ocasio（1997）在企業注意力觀點中指出，組織行為受到決策者注意力如何被規則、資源、關係與溝通渠道分配所影響 [E1]。這項研究使「增加一套管理儀表板」不必然等於「增加有效治理」：儀表板若持續把低價值問題放在人類眼前，可能擠壓真正重要的問題。

Sims（2003）的理性忽略（Rational Inattention）研究，則把有限資訊處理能力視為決策模型中的約束 [E2]。本文採用的是**注意資源有限、取得和處理資訊有成本**這個結構，不宣稱已對個別研究者的注意力建立精確神經測量。

Leroy（2009）在工作任務切換研究中，使用實驗觀察未完成任務的注意力殘留與後續任務表現的關聯 [E3]。然而本篇不能因此直接認定每項休眠研究必然會讓人疲勞；真正待驗證的是管理提醒能否使原本低活動的成果重新占用認知資源。

## 2.2 探索與利用不是單一進度表

March（1991）區分組織學習中的探索新可能與利用既有知識，並分析時間與資源分配的張力 [E4]。把所有探索候選視為當期交付，會消滅探索的選擇權；反之，永遠不外化，則可能失去學習與經濟回饋。本篇要求把「候選資產」「已承諾交付」「實際風險」分帳。

Simon（1956）的有限理性與滿意化觀點提供另一種對照：在完整比較極昂貴時，依足夠好的判準停止搜尋可能合理 [E5]。這不等於不用驗證安全門檻，而是說不需要對所有低風險選項做無限精細的最優化。

## 2.3 維運與重複治理負擔已有實務理論

Google 的 SRE「消除 toil」工作將部分重複、人工、可自動化、戰術性且缺乏持久價值的工作視為需限制的負荷 [E6–E7]。本篇並不把每次例行檢查都當成 toil：事故應變、合約審查、資安升級或不可逆發布批准可能非常必要。重點是分辨**哪一些工作真正改變風險或義務狀態，哪一些只是重複證明尚未出現新事件**。

## 2.4 持續監測必須與風險相稱

NIST SP 800-137 提出資訊安全持續監測的原則，目的包括了解資產、威脅、漏洞與控制有效性，並能依風險及時行動 [E8]。它不是「所有私人研究文件都要每天人工打開」的規範；其監測對象、頻率及責任，應依服務暴露與風險決定。本篇的事件驅動模型與這種風險導向思維相容，但具體演算法並非 NIST 官方要求。

## 2.5 GitHub 封存不是安全承諾的終止魔法

GitHub 官方文件說明封存後倉庫變為唯讀，並可重新解除封存；封存前官方建議處理議題與說明 [E9]。但 GitHub 同時指出，**Dependabot 不掃描已封存的儲存庫** [E10]。因此不能把 GitHub `archive=true` 解讀為「程式沒有風險」「第三方使用者已經被保護」「先前合約自動終止」。

OpenSSF 的 OSPS Baseline 強調對已發布軟體提供可理解的支援範圍與停止安全更新的說明 [E11]；OpenSSF 的選型指引也將失去維護視為下游使用者的重要風險指標 [E12]。這些證據是本文保留「公共依賴例外」的原因。

## 2.6 原始碼保存是價值，但不是可執行保證

Software Heritage 的 SWHID 使特定版本原始碼取得持久識別符 [E13]；然而「原始碼仍然可識別」與「今天或十年後一定能執行」之間存在工具鏈、依賴、資料、作業系統、硬體與法定權利差距。本文把有效保存視為有門檻的資產條件，而非只要 GitHub Repo 存在便自動滿足。

## 2.7 不要把拒絕結束的承諾誤當成責任感

Brockner（1992）討論對失敗方案加碼投入的承諾升高現象 [E14]。雖然本文主要研究休眠，但持續管理所有項目也可能受到沉沒成本、身分認同與過往努力影響。然而「退出是理性」同樣不是普遍命題；某些持續維護是真正履行第三方責任，不能只以個人主觀負荷判斷。

---

# 3. 關鍵概念：資產、義務、行動與可用注意力

## 3.1 資產存量

定義 $\mathcal P_t$ 為時間 $t$ 可識別的專案／研究資產集合，並以 $N_t=|\mathcal P_t|$ 表示資產數。注意：資產可能是一篇論文、一個程式倉庫、一份實驗證據、一個模型權重版本或一個單純的可恢復設計草案；不能僅憑計數把不同類型等價。

## 3.2 外部義務

對資產 $i$ 定義：

$$
\mathbf d_i(t)=
\bigl(
 d_i^{law},d_i^{contract},d_i^{service},d_i^{security},d_i^{privacy},d_i^{dependency}
\bigr).
$$

這些欄位分別是適用法律、合約、已承諾服務、安全處置、個資／機密，以及與其他正在運作系統之相依義務。它們是不同來源的實際責任，不能只用專案是否活躍或是否公開推定為零。

另一種私人承諾，例如「我最近想把這個遊戲原型完成」，可以是個人目標，但除非成為有效外部承諾，不應直接與服務安全和合約義務放在同一強制層級。

## 3.3 行動需要

令 $G_i(t)$ 表示專案 $i$ 在 $t$ 時需要的有效治理行動集：

$$
G_i(t)=
\{a\mid a\ \mathrm{is\ needed\ to\ satisfy\ obligations\ or\ prevent\ unacceptable\ loss}\}.
$$

低風險保存專案可以出現 $G_i(t)=\varnothing$ ；若服務正在運行、憑證到期或重大漏洞已被確認，則 $G_i(t)$ 可能非空。這裡的「需要」受責任證據與風險閾值約束，而不是只看 AI 建議書是否產生新的 Phase。

## 3.4 人類時間與機器時間不得混算

令當期人類治理負荷為：

$$
H_t^{gov}=H_t^{decision}+H_t^{review}+H_t^{interrupt}+H_t^{recovery}.
$$

而 AI 執行成本表示為不同帳本：

$$
C_t^{AI}=C_t^{tokens}+C_t^{tools}+C_t^{runtime}+C_t^{verification}.
$$

即使 AI 用很短時間完成分類，人類讀完結果、作出不可替代決定，以及被通知打斷的成本依然需要計入。反之，AI 可在低干預授權範圍內完成的操作，也不必強迫換算為人類的主動工作時數。

## 3.5 時間主權的最小定義

這裡沿用 HAVT 與 HACTS-05 的方向：時間主權不是「不工作」本身，而是主體可以在基本義務與資源可行條件下，自主決定工作、探索、等待、休息及改變方向的有效能力。

因此：

$$
N_t\uparrow
\quad\not\Rightarrow\quad
H_t^{gov}\uparrow.
$$

此處是不蘊涵關係，而非宣稱兩者必然負相關。

---

# 4. 專案休眠的操作性定義：不是完全忘記，也不是持續追趕

## 4.1 有效休眠

稱資產 $i$ 處於「有效休眠」（Effective Dormancy），當且僅當在明示觀察區間內至少滿足：

1. 當期不存在必須持續開發的外部交付義務，或已合法安排替代履約者；
2. 研究原始資料、程式、版本、必要授權與回溯證據達到其預定重啟用途的最低保存門檻；
3. 已停止不必要的高頻通知、主動產出、無期限 Agent 任務與默認自動開新 Phase；
4. 現存的服務暴露、支付、個資、權限、憑證、外部依賴與合理可預見風險仍由合適渠道監督；
5. 未來存在可以重新決定是否恢復、移轉或終止的路徑，且不把未來重新啟動當成不可撤回的義務。

其中第 4 項屬於**有效休眠與疏忽棄置**的分界；第 5 項則接續 HACTS-07 的選擇權。

## 4.2 休眠不是 GitHub 上唯一一個按鈕

`Archived repository` 是程式碼託管平台的狀態；`Dormant research asset` 是本文的研究治理概念。兩者可能重疊，但並不相等。

例如：私人、完全離線且已記錄環境的研究程式碼，即使 Repo 不設為 archived，仍可實際休眠；反之，一個開源庫即使 archived，下游系統仍可能持續引用舊版本，安全與支援訊息未必能完全停止。

因此：

$$
\mathrm{RepositoryArchived}_i=1
\quad\not\Rightarrow\quad
\mathrm{NoResidualRisk}_i=1.
$$

## 4.3 何時可以不安排下次審查日期？

對於真正離線、無服務、無金流、沒有他人依賴且保存介面穩定的研究資產，下一次審查可以由「出現實際研究需求」「重啟請求」「外部合作機會」「授權或備份異常」觸發，而不是固定每月檢討。這不意味著沒有任何資料備份或安全設計；備份檢核可由底層共同保存系統承擔，而不需要每個 Repo 分別召開工作檢討會。

對有網路暴露或使用者依賴的成果，則應由相應的資安監測、營運責任與服務期限決定，不得照搬無期限免檢查的做法。

## 4.4 休眠和退休

休眠（Dormant）保留再啟動路徑；退休（Retired）可以明確結束產品、版本或維護承諾，並依法安排通知、資料處置及支援終止。退休可能保留一份歷史文件，但不必保留原服務可繼續執行的能力；反之休眠有時只停止主動研發而保留最小維運。兩者不是一個可隨便互換的標籤。

---

# 5. 管理內生增殖：治理為何也會創造新任務？

## 5.1 一個治理過程的回饋迴路

管理者打開某個長期未更新的項目，可能因此追加「更新文件」「修正標籤」「補單元測試」「建立下一版本 Roadmap」「比較最新模型」「加一個 Agent 看守」。這些工作有的必要、有的不必要，卻都會進入新的管理清單。

候選治理迴路為：

$$
\mathrm{Review}
\rightarrow
\mathrm{NewFindings}
\rightarrow
\mathrm{NewProposedTasks}
\rightarrow
\mathrm{NewReviewLoad}
\rightarrow
\mathrm{MoreReview}.
$$

真正的關鍵不是發現問題，而是**誰決定某項發現足以形成新的責任**。若不經由明確的選擇與外部義務校核，便把所有改善建議提升為待辦任務，則管理過程可能無界擴張。

## 5.2 佇列動態

令 $D_t$ 為尚未處理的治理佇列， $A_t$ 為真正必要、外部進入的治理事件， $M_t$ 為當期管理／審查活動數， $\alpha_t$ 為每次審查額外生成的後續待辦平均數， $C_t$ 為完成或合法關閉的治理事項數。提出概念式：

$$
D_{t+1}
=
\max\left(0, D_t+A_t+\alpha_tM_t-C_t\right).
$$

此式僅描述一種可能的會計關係， $\alpha_tM_t$ 不一定都是浪費，也可能揭露之前未發現的真實風險。它的用處是將**新增必要義務**與**新增選擇性改善方案**分帳。

若長期具有：

$$
\mathbb E[A_t+\alpha_tM_t]
>
\mathbb E[C_t],
$$

未解決管理佇列就可能持續增加。但此不等式不是 AI 產能越高就必然成立，也不意味著應禁止揭露新的安全問題。

## 5.3 內生新增工作不等於必要的工作

將管理衍生的工作再拆成：

$$
\alpha_tM_t
=
N_t^{duty}+N_t^{proposal}+N_t^{noise},
$$

其中三者分別是可追溯義務、可選擇提案與低資訊增量雜訊。這是分類帳本而不是「三種工作有固定比例」的實驗結果。

新的治理制度應讓 $N_t^{duty}$ 進入必要工作流程， $N_t^{proposal}$ 留在低打擾的候選庫，而 $N_t^{noise}$ 可以在權限與證據條件下直接不採納。**候選不自動升格為承諾**是阻止管理自我增殖的關鍵邊界。

## 5.4 三種錯誤激勵

第一種激勵是「空白儀表板焦慮」：管理者覺得每天必須出現新更新，否則系統不像在工作。第二種是「永遠下一個 Phase」：AI 發現每個功能都可改善，於是沒有停止條件。第三種是「委任反向負擔」：Agent 大量生成管理報告，但真正的閱讀、驗證、確認和決策仍全部交給人類。

本文不預設三者普遍存在，而是將其作為可被工具日誌、時間使用、通知與決策結果測量的候選機制。

---

# 6. 最小必要管理不等於管理不足

## 6.1 最小不是最少檔案、最少規則或最少人

治理質量必須考慮事故防止、第三方權益、可恢復性、合法性與成本。只要可以維持品質與責任，同一結果由更少干預達成，才有資格稱為「最小必要」。若省略監測導致資料洩漏、交易錯誤或使用者損害，即使工時降低，也不是有效治理。

## 6.2 硬約束優先

對制度策略 $\pi$ 的候選目標寫為：

$$
\min_{\pi}\ \mathbb E\left[
\sum_{t=0}^{T}\gamma^t
\left(
 w_H H_t^{gov}
 +w_A C_t^{AI}
 +w_F C_t^{money}
 +L_t^{residual}
 +C_t^{lostOption}
\right)
\right],
$$

條件是：

$$
\pi\in\mathcal F_{law}
\cap\mathcal F_{contract}
\cap\mathcal F_{safety}
\cap\mathcal F_{privacy}
\cap\mathcal F_{authority}.
$$

其中 $\gamma$ 為折現係數， $H_t^{gov}$ 是人類實際治理時間， $C_t^{AI}$ 是 AI／工具成本， $C_t^{money}$ 是其他支出， $L_t^{residual}$ 是未避免的損失， $C_t^{lostOption}$ 是管理不足而喪失未來重啟選擇的代價。權重 $w_*$ 用於建立可比較的分析刻度，並非把所有權利或生命價值全部貨幣化；某些條件不可被正的財務收益抵銷。

這不是已證明的唯一最佳目標函數，只是提供實驗辨識與策略比較的候選表示。

## 6.3 真正可行的最低治理

定義：

$$
G_t^*
=
\underset{G\in\mathcal G_t^{feasible}}{\arg\min}
\ C_G(G),
$$

其中 $\mathcal G_t^{feasible}$ 僅包含在特定當期風險、外部義務及資產保存門檻下，仍符合明示硬條件的治理方案。最小管理不是「所有系統都不監督」，而是選擇**能滿足基本條件而占用資源最少的有效監督**。

## 6.4 注意：有時候更多管理就是必要

若發現安全漏洞、重要合約爭議、付費使用者重大障礙或資料遺失徵兆，增加審查與處置是合理的；若一項研究產物高度依賴將被關閉的外部服務，預先遷移也可能比放置更省總成本。本文的主張只是在預設狀態上，避免以資產數量代替真實風險及實際義務。

---
# 7. 義務來源帳本：哪一件事真的有必要被管理？

## 7.1 四類不同的來源

對一項待辦提案，第一個問題不是「要排在第幾優先」，而是「它究竟為什麼成為工作？」本文先區分四種來源：

| 類型 | 產生條件 | 可否單方面放棄 | 應進入何種流程 |
|---|---|---|---|
| 外部強制義務 | 適用法律、合約、已明確作出的服務承諾、法定資料保留或刪除 | 通常不能任意單方面撤銷既有責任 | 明確負責者、證據、期限、必要行動 |
| 風險處置需要 | 已知漏洞、對外暴露、將造成不可接受損失的安全或可靠性問題 | 需符合風險標準與適用責任，不可任意忽略 | 風險事件、授權處置、可稽核結案 |
| 主體自選承諾 | 個人認真選定的一段研究、創作或商業目標 | 通常可修改，但受具體承諾與後果約束 | 自主計畫、可重審時間與停止條件 |
| 尚未承諾的候選 | Agent 建議、靈感、下一個 Phase、可能的合作或產品延伸 | 原則上可不採納 | 低打擾選擇權庫，不自動形成待辦 |

四類資料的記錄形式不必全都很複雜。關鍵在於：一筆新資料能說明是誰、因何種權限或外部條件，將某個構想正式轉為需要執行的事項。

## 7.2 「這件事很好」不構成執行義務

在高度 AI 協作環境下，模型可以不斷提出改善機會。對於每一個有價值的建議，若都自動加入排程，管理系統將把「可能有幫助」誤認為「必須完成」。這個推理錯誤可寫為：

$$
\mathrm{UsefulSuggestion}_i=1
\quad\not\Rightarrow\quad
\mathrm{CommittedTask}_i=1.
$$

在本文中，承諾需要可識別的授權來源，例如明確的自我決策、具有合法效力的外部義務，或事先授權 Agent 依指定門檻自主採納。超出授權的提案必須停留在候選層。

## 7.3 最小記錄不是零記錄

研究作者不必替每篇私人論文制定維護 SLA，但仍可能需要保留：版本、來源、作者／協作者責任、已做過的驗證、相依文件及公開限制。對於正式服務，則可能需要更完整的 owner、事故通道、資料保留與服務下線資訊。**治理資料深度應服從責任深度，而不是服從資產數量。**

## 7.4 已經對外承諾的事項不能靠標籤消失

把一個網站放進 `dormant` 或 `archived`，不表示域名就不會過期、API 就不會洩漏資料、訂閱付款就會自動停止、下游使用者就會即刻知道其不再受支援。對外依賴的有效結束可能需要通知、遷移、停止部署、撤銷憑證、資料處理與必要留存。

本文因此要求：任何使對外服務「退出活動集合」的操作，都必須區分研究活動停止與外部義務結束；若後者尚未結束，不可把整個服務標記為無人負責。

---

# 8. 有效休眠集合與硬性風險閘門

## 8.1 不用一套巨型分類法管理所有事物

若每一項資產都必須人工選擇二十個分類欄位，為了建立休眠權反而會破壞休眠權。因此本文傾向使用少量對治理有實際意義的旗標，而非要求將全部研究納入固定等級階層。

考慮以下可觀察狀態：

$$
\mathbf z_i=
\bigl(
 x_i^{live},x_i^{public},x_i^{user},x_i^{money},x_i^{data},x_i^{legal},x_i^{recover}
\bigr).
$$

依序表示：是否有正在運行的對外服務、公開可取得內容、實際依賴者、財務承諾、敏感資料或權限、法律或合約限制，以及必要的可恢復能力。此向量不是業界統一標準，亦不應以一個布林標籤取代完整的證據；它是一個讓系統知道「是否可以安靜保存」的最低決策接口。

## 8.2 有效休眠集合

令 $\mathcal D_t$ 表示當期滿足有效保存與外部義務處理條件的資產集合：

$$
\mathcal D_t=
\left\{i\in\mathcal P_t\mid
Q_i^{rec}\ge q_i^{min},\ 
R_i^{unhandled}\le r_i^{max},\ 
D_i^{unassigned}=0
\right\}.
$$

其中 $Q_i^{rec}$ 為可恢復性代理、 $q_i^{min}$ 為依目的設定的最低門檻， $R_i^{unhandled}$ 表示未被適當處理的風險， $D_i^{unassigned}$ 是沒有合格承接者的實際義務。 $r_i^{max}$ 不能取代法律硬規定，也不能允許以高經濟收益抵銷不可接受的權利或安全損害。

資產進入 $\mathcal D_t$ 不代表它毫無未來價值，反而代表在現在這個時點，其價值可以在足夠保存的情況下，不持續要求人的主動管理。

## 8.3 危險的誤分類

尤其要排除：

- 仍對外接收金流、處理資料的網站，卻只因很少更新就被視為無風險；
- 仍被其他服務呼叫的內部 API，卻因缺少最近提交紀錄就被忽略；
- 具有安全更新期待的已發布軟體，被誤認為 GitHub archive 後風險消失；
- 私人研究倉庫中留有正式環境金鑰，卻當作純靜態檔案保存；
- 含他人版權、資料或機密的材料，在未檢查權利時直接開源；
- 含有必須依法保留或刪除的資訊，卻只按研究者偏好處理。

這些失敗不會因低干預治理而變得可以接受。

## 8.4 風險與監測方式相互決定

同一個程式專案在離線原型階段、私有試驗階段、開源發布階段和付費服務階段，所需要的治理層級可能完全不同。所以有效休眠集合是**依時點、暴露和承諾改變的動態集合**，不是永久貼上標籤便再也不看。

---

# 9. 最小治理成本模型：哪些成本會被儀表板藏起來？

## 9.1 不能只算維護工時

對資產組合 $\mathcal P$，提出治理成本分解：

$$
C_G=
\sum_{i\in\mathcal P}C_i^{direct}
+
\sum_{i<j}C_{ij}^{coupling}
+
C^{index}
+
C^{alerts}
+
C^{switch}
+
C^{transitions}.
$$

各項分別是直接維護、專案之間的相依成本、索引系統、通知處理、注意力切換及狀態變更。這一表示並不宣稱所有成本都能直接以同一貨幣準確相加；在實證中，應分別記錄分鐘、實際貨幣及風險，再依研究目的作權重敏感度分析。

## 9.2 管理系統本身的固定成本與新增成本

任何新的「全域專案中樞」可能帶來初始建立成本 $F_G$，與每新增專案的邊際治理成本 $m_G$：

$$
C_G(N)=F_G+Nm_G+C^{cross}(N).
$$

若這套系統使 $m_G$ 下降，且減少了重複操作，其投資可能合理；若它要求每一項新研究都填寫更詳細的欄位、安排自動回報、人工核准，則 $m_G$ 可能下降有限，甚至增加。僅觀察 dashboard 的功能數無法判斷效益。

## 9.3 注意力的離散成本

人類每次被通知並不只消耗閱讀通知的幾秒鐘，也可能有上下文恢復成本。此成本不應直接套用單一實驗室平均值；研究上至少應分別測量通知處理、原任務恢復、發生錯誤的比例及休閒時的打擾程度。

## 9.4 局部節省與全局節省可以相反

讓一個 Agent 每天自動整理全部 Repo，可能讓某個人的點擊數下降；但如果因此增加了成本昂貴的人工審核與失敗後恢復，全系統仍可能更貴。

本文因此以**系統性的人類有效介入量**，而不是某個子工具的執行速度，評估治理是否真正變輕。

---

# 10. 日曆檢查與事件觸發：何時不必每週都看一次？

## 10.1 固定檢查的假設

考慮單一專案，假設其在沒有人工檢查時，潛在重要事件以長期平均到達率 $\lambda$ 發生；每次檢查的等價成本為 $c$ ；若一個事件發生後未被發現，每延後一天造成等價損失率 $h$。假設事件彼此獨立、相對於固定檢查時點均勻到達、每次檢查都能發現相關事件，且未處理期間損失按時間線性增加。

每隔 $T$ 天檢查一次時，平均偵測延遲為 $T/2$，每單位時間的簡化成本近似：

$$
J_{periodic}(T)
=
\frac{c}{T}
+
\frac{\lambda h T}{2}.
$$

這個公式沒有包含固定損失、跨事件相關、未檢出的偽陰性、監測設備失效、法律時限或突發不可逆事件，因此只是一個透明的研究基準，不可直接當作生產服務的部署規則。

## 10.2 最適檢查間隔的條件推導

若 $c>0$ 、 $\lambda h>0$ 且其他限制暫不作用，則：

$$
\frac{dJ_{periodic}}{dT}
=-\frac{c}{T^2}+\frac{\lambda h}{2}.
$$

令導數等於零得：

$$
T^*=\sqrt{\frac{2c}{\lambda h}}.
$$

且：

$$
\frac{d^2J_{periodic}}{dT^2}
=\frac{2c}{T^3}>0.
$$

因此在上述假設下存在唯一內部極小值。代回可得：

$$
J_{periodic}(T^*)=\sqrt{2c\lambda h}.
$$

這表示：事件到達頻繁、延誤代價高時，合理檢查間隔可能較短；事件罕見且每次檢查昂貴時，可以較長。**它不是越少檢查越好，而是風險與檢查成本必須一起進入模型。**

## 10.3 外部責任優先於數學內部最適

若安全或合約要求最長檢查間隔 $T_{max}$，則實際候選可寫為：

$$
T_{feasible}^*=\min(T^*,T_{max}).
$$

若存在更加嚴格的法定通知或事故反應期限，上式仍需要相應約束與獨立證據。若事件造成不可逆或非線性損失，平均線性成本的假設應被捨棄，不能用漂亮的平方根公式掩蓋尾部風險。

## 10.4 事件觸發的另一條路徑

設事件偵測器的真事件偵測率為 $s$，誤報率為每天 $f$ 件；每次人工確認的成本為 $a$ ；真正事件平均發生率為 $\lambda$ ；被發現後處理的平均延遲為 $d$ ；未偵測事件的平均未處置損失為 $L_0$ ；維持感測器的每日成本為 $c_0$。

構造同樣透明但不完整的成本代理：

$$
J_{event}
=
 c_0
 +a(s\lambda+f)
 +(1-s)\lambda L_0
 +s\lambda h d.
$$

其含義是基礎監測、事件及誤報核驗、漏報損失，以及被正確發現事件的延遲損失。若外部服務有特定高嚴重度事故，仍需要獨立的硬性分級與反應上限；這裡不可以平均值掩蓋單次不可接受的災害。

## 10.5 事件驅動未必更好

事件驅動只有在感測可靠、誤報可控、影響有限且具備及時回交能力的條件下，才可能降低人工干預。若偵測器品質差、日常噪音很多、漏報嚴重，則定期人工檢查或更直接的專業監控可能更合適。

對不暴露於網路、沒有他人依賴的靜態研究檔案，有時連「每項各自裝一個警報器」都沒有必要；只需依賴共用儲存平台的完整性與備份驗證。這就是本文對「最小」二字的實際要求。

---

# 11. 多專案的觀測配置：風險高的少數，與可安靜保存的多數

## 11.1 全體等頻審查的內含假設

如果組織對所有專案都要求每月更新，等於預設每一項資產的事件頻率、損失程度、資料老化、承諾期限和人工檢查成本相近；而這在多模態研究與多產品組織中往往不成立。

單純規定「每個 Repo 每月一次」雖然容易管理，卻可能忽略真正需要緊急處理的少數活躍服務，也可能無謂喚醒大量低風險研究資產。

## 11.2 不以單一分數代表所有風險

對專案 $i$ 建議保留風險向量，而不是只提供一個 0～100 的整體分數：

$$
\mathbf r_i
=\bigl(r_i^{security},r_i^{privacy},r_i^{financial},r_i^{dependency},r_i^{recovery},r_i^{promise}\bigr).
$$

安全與權利中的硬性條件不能被商業收益分數抵銷。只有在已明示合格條件後，才可對剩餘風險進行資源優化。

## 11.3 跨專案風險並非獨立

兩個單獨低風險的研究或服務，可能共享過期相依、同一部署金鑰、域名、帳戶權限或對外資料來源。若只按單一 Repo 判定，很可能遺漏共通暴露。一般化殘餘損失可包含關聯項：

$$
L_{portfolio}
=\sum_i L_i^{single}
+\sum_{i<j}L_{ij}^{dependency}.
$$

相依風險不一定為正，有些共用基礎設施能降低重複安全成本；其方向應由實際架構與失效情境識別。

## 11.4 最小管理的單位不必是專案

如果十個低活動 Repo 都使用同一個加密備份、共同版本記錄或同一個可信的資料保存制度，那麼它們可能由同一套底層完整性檢測保障，而不必各自安排十次人工檢查。另一方面，一個單一 Repo 若部署多個不同風險的正式服務，可能需要多套不同的監測。

因此：

$$
\mathrm{GovernanceUnit}
\neq
\mathrm{RepositoryUnit}.
$$

應依真實的責任、服務、資料和失效邊界劃分，而不是依檔案倉庫的行政數量機械配置。

## 11.5 非同步監測不等於要求人類永遠待命

只有事件達到授權範圍之外、明確的風險門檻，才應把人類重新拉回治理橋接層。低風險偏差、可自動恢復的事件和非必要改善建議，應在 AI／系統內部處理或安靜保存；否則所謂自主組織仍然只是一台幫人類製造通知的機器。

---

# 12. 再啟動與回返：不管理之後如何避免失去資產？

## 12.1 未完成不等於可恢復

一個多年未更新的程式倉庫如果有完整原始碼、依賴、環境、可執行測試及清楚的技術目標，與一個只剩下一張未命名截圖的研究專案，具有完全不同的再啟動成本。有效休眠需要遵守 HACTS-07 所提出的最低可恢復門檻，而不是把所有停工項目都算成未來資產。

## 12.2 低成本保存的六個要素

對未涉及第三方限制的研究產物，最低保存介面通常包括：識別名稱與版本、原始碼或原始論文來源、必要的環境與相依指示、重要驗證結果、公開／授權邊界，以及可辨認的重啟入口。具體深度依研究內容而定。

但若某項產物已可被完整引用且沒有執行需求，未必需要長期維護一套可即時執行的環境；若產物是複雜生成模型或精密實驗，則可能需要保存權重版本、資料規格、評測程序及硬體軟體條件。保存的目標應由未來可重建用途決定。

## 12.3 不必強迫保留原先 Roadmap

重新啟動時的主體可以發現某個專案已失去價值、原目標被取代、現有工具已經改變，或自己根本不再對它有興趣。這些結果不應被一律標記為管理失敗。**保留回返權，不等於替未來自己設定不可撤銷的回返義務。**

## 12.4 最小可回返契約

本文提出三個階段：

1. **保存門檻**：足以讓授權者理解這是什麼、有哪些可靠證據、能否重啟，以及哪些權利或安全限制仍存在。
2. **觸發入口**：出現新的研究意圖、外部需求、合作資源、指定高價值事件或必須處理的風險。
3. **重估決策**：重新評估續做、改造、轉移、公開、退休或持續休眠，並記錄真正改變外部狀態的行動。

這不是要求所有專案每年重做一份企劃，而是保證其在被真正喚醒時，能正確辨識資產與責任。

## 12.5 動態回返閾值

令 $V_i^{restart}(t)$ 為在新資訊下重啟的預期可實現價值， $C_i^{restart}(t)$ 為完整重啟成本， $K_i^{now}$ 為當期有限人類時間、財務與替代專案的機會成本。重啟的簡化必要條件可寫為：

$$
V_i^{restart}(t)
-C_i^{restart}(t)
-K_i^{now}>0.
$$

這不是充分條件，因為仍需通過合法性、權限、資源、風險及真實的個人選擇；即使估值為正，研究者也可以保留不做的自主空間。

---

# 13. 一個最小的事件驅動治理政策

## 13.1 概念契約而非需要另建的大平台

對既有 EVEMISS Registry 或 HDUS／ANDO，可在不推翻現有架構下加入小型治理政策。以下 YAML 是**文件介面示例**，不是聲稱系統已經部署或是平台原生設定格式。

```yaml
asset_id: research-asset-opaque-id
artifact_ref: verified-version-reference
project_mode: dormant_candidate
live_service: false
public_downstream_dependency: false
financial_commitment: false
sensitive_runtime_access: false
external_obligation_owner: null
preservation_status: verified
human_review_schedule: null
allow_agent_generate_new_roadmap_tasks: false
allow_agent_change_visibility: false
allow_agent_change_license: false
wake_on:
  - explicit_owner_request
  - verified_dependency_event
  - preservation_failure
  - new_external_commitment
escalation_policy:
  safety_event: qualified_owner_review
  legal_or_privacy_event: qualified_owner_review
  ordinary_ideas: silent_candidate_store
```

一旦出現外部使用者、實際金流或敏感資料，就不應沿用 `false` 旗標直接休眠，必須重新校核真正的責任與對外暴露。

## 13.2 由候選到承諾的門檻

允許 Agent 自主整理研究背景、建議幾種可能的後續方向；但沒有明確授權時，不能把這些建議加入人類的固定待辦，也不能自行新增每週會議。即使 Agent 自動完成部分低風險工作，也不代表它可以擅自變更開源許可、公開私人 Repo、刪除資料、簽署交易或對外承諾服務。

## 13.3 休眠期間能做的事

休眠不排除必要的共同備份、完整性檢查與受權的基礎安全機制。但任何超出必要範圍的升級，例如「幫你把這個半年沒碰的研究重新設計成新產品」，應被視為新候選，而非休眠期間的自動義務。

## 13.4 喚醒之後的上限

重新啟動也不應產生「一醒來就必須完成所有未處理事項」的效果。合理策略是：先恢復理解與最低可用環境，判定是否值得當下繼續，再決定有限的範圍。若新證據顯示已不值得，合法關閉也是一種有效結果。

---

# 14. AI 原生組織：讓治理能力提高，而不是讓人的義務同步提高

## 14.1 兩種相反的自主組織

形式上的多 Agent 組織，可以不斷巡檢、建立 issue、開新分支，最後要求人類每天簽核。另一種設計則允許低風險事項在權限範圍內完成，真正重要的責任被明確處理，其餘研究資產保持靜默。兩種組織使用的 AI 模型可以一樣，但對人類時間主權的影響完全不同。

## 14.2 治理權限與生產能力分離

沿用 HDUS 的架構原則：能產生一段程式碼不代表可以修改正式產品，能看見私有資料不代表可以公開，能提出下一階段不代表有權創造新的工作承諾。建議最小執行不變量：

$$
\mathrm{AIPropose}
\neq
\mathrm{HumanCommit}
\neq
\mathrm{WorldCommit}.
$$

## 14.3 可恢復、可暫停、可升級的委任

一個組織必須能說明：哪些工作可以在休眠期間保持低頻自動執行，哪些事件要立即升級，預算耗盡時能否安全停下，若權限過期或執行環境改變應否撤銷授權，以及已經發生的世界變更如何核對。這些是必要的治理工程，不應因強調「最小管理」而省略。

## 14.4 不允許 Agent 用低價值提醒占用全部人類頻寬

設一個允許的人工通知容量 $B_H^{notify}$，並以風險與授權門檻決定何事可以占用。若超過容量，不能簡單延後所有訊息；應先分辨重大安全事件的即時路由、一般服務問題的受權處置，以及低優先候選的安靜保存。危急事件需要有效的獨立通道，而不是混在大量普通想法中。

## 14.5 離線不是治理失敗

如果使用者選擇一天完全不處理研究，或一段時間專心投入其他生活活動，而系統能依既有授權安全運作，並在需要人類的節點保持清楚回交，那麼人類退出日常操作未必是效率損失。若系統只是把全部待審查工作堆積到使用者回來之後，則仍未真正解決治理瓶頸。

---
# 15. 八組可重算的數值思想實驗

## 15.1 實驗地位與共同假設

以下八組數值是為了檢查數學式的內部一致性、識別成立條件與展示反例而選定的**思想實驗**。它們不是 EveMissLab 的實際專案測量結果，不是 GitHub 官方平均事件率，不是已完成的使用者研究，也不是對某個人創業成功機率的預測。所有「單位」都是可比較的研究代理值；實際部署應重新校準人類工時、時間價值、財務與風險。

前述定期檢查模型使用：

$$
J_{periodic}(T)=c/T+\lambda hT/2.
$$

其中 $T$ 為天， $c$ 是每次檢查的等價成本， $\lambda$ 是每天的平均相關事件數， $h$ 是每個未被發現事件延後一天的等價損失； $J$ 是每天的平均等價成本。事件模型使用：

$$
J_{event}=c_0+a(s\lambda+f)+(1-s)\lambda L_0+s\lambda hd.
$$

這些模型刻意簡化現實，不能用來取代法定最長反應時間、資安標準或其他硬性責任。

## 15.2 情境 A：低風險、低事件率的靜態資產

設每次檢查成本 $c=10$ 、事件率 $\lambda=0.01$ ／日、延誤損失參數 $h=8$。則：

$$
T^*=\sqrt{\frac{20}{0.08}}=15.8114\ \mathrm{days}.
$$

最小平均成本：

$$
J_{periodic}(T^*)=\sqrt{1.6}=1.2649.
$$

若仍每天檢查，則：

$$
J_{periodic}(1)=10+0.04=10.04.
$$

在這組假設下，將檢查週期加長確實可減少成本。但若資產不存在上述事件過程，或有法律、保存、相依與權利上的其他觸發機制，就需要重建模型，不能宣稱十五天是所有私人研究最理想的固定週期。

## 15.3 情境 B：對外事件頻率高的系統

保持 $c=10$，改為 $\lambda=0.30$ ／日、 $h=20$：

$$
T^*=\sqrt{\frac{20}{6}}=1.8257\ \mathrm{days}.
$$

$$
J_{periodic}(T^*)=\sqrt{120}=10.9545.
$$

同樣的「少檢查」策略不再有 A 那種長週期的合理性。不同資產即使同屬一個 GitHub 帳戶，真正相關的治理頻率也可以不同。

## 15.4 情境 C：有明確外部反應上限

承接 B 的數值，假設已有外部服務承諾要求最長間隔為一天。則必須使用 $T\leq1$ 的可行條件；在簡化模型下，選擇 $T=1$ 得：

$$
J_{periodic}(1)=10+\frac{0.30\times20}{2}=13.
$$

成本高於不受約束的內部最適值 $10.9545$，但此額外成本可能是履行真實服務義務的必要代價。**不能為了降低管理成本而把已承諾的反應上限當作可自由忽略的參數。**

## 15.5 情境 D：全體月檢與選擇性檢查

考慮有 $120$ 項不同形式的研究／工程資產。若全部每月人工檢查一次，每項平均 $12$ 分鐘，總人工審查時間為：

$$
H_{all}=120\times12=1440\ \mathrm{min}=24\ \mathrm{h}.
$$

假設事先的合法性與風險校核顯示，只有 $15$ 個項目需要在此月人工審查，其餘項目由可靠底層保存或服務機制承接；另有 $4$ 件實際事件，每件需 $25$ 分鐘：

$$
H_{select}=15\times12+4\times25=280\ \mathrm{min}.
$$

即 $4$ 小時 $40$ 分鐘。兩者相差：

$$
1440-280=1160\ \mathrm{min}=19\ \mathrm{h}\ 20\ \mathrm{min}.
$$

但若另外 $105$ 項資產中隱含未處理的重大安全風險，這個「節省」就不可信。選擇性策略必須以風險與責任條件被正確辨識為前提；模型不能先假設沒風險，再宣稱省工時。

## 15.6 情境 E：事件驅動監測在高品質感測器下較省

沿用情境 B 的事件強度 $\lambda=0.30$ 、 $h=20$ ；假設感測器真事件偵測率 $s=0.98$ 、每天誤報 $f=0.05$ 、每次人工確認成本 $a=2$ 、每日監測成本 $c_0=1$ 、平均反應延遲 $d=0.10$ 日、漏報事件的等價損失 $L_0=50$。則：

$$
J_{event}
=1+2(0.98\times0.30+0.05)
+0.02\times0.30\times50
+0.98\times0.30\times20\times0.10
=2.576.
$$

在這組明示假設下，事件驅動成本低於情境 B 的週期檢查最小值 $10.9545$。但其中 $L_0=50$ 是示意損失；真實資安或個資事件的損害可能極不對稱，不能以平均成本就判斷其為可接受監控方案。

## 15.7 情境 F：差的感測器使事件驅動反而更昂貴

與情境 E 相同的基礎事件率、損失與人工確認單價，改為偵測率 $s=0.50$ 、誤報率 $f=8$ 件／日，平均延遲 $d=1$ 日：

$$
J_{event}
=1+2(0.50\times0.30+8)
+0.50\times0.30\times50
+0.50\times0.30\times20\times1
=27.8.
$$

它明顯高於原先的週期策略。此例直接反駁「只要做事件觸發，就一定更有效率」。AI Agent 若不斷輸出大量低品質管理警報，可能重新構成人類注意力負擔。

## 15.8 情境 G：保存品質影響未來可重啟價值

考慮兩種研究資產保存方案，預期未來有效收益代理皆為 $100$。方案甲的恢復成功率 $p_A=0.9$ 、保存成本 $5$ 、重啟成本 $15$ ；方案乙則有 $p_B=0.7$ 、保存成本 $1$ 、重啟成本 $35$。

簡化期望剩餘價值分別是：

$$
V_A=0.9\times100-5-15=70,
$$

$$
V_B=0.7\times100-1-35=34.
$$

即使方案乙保存得更便宜，因恢復率與重啟成本較差，保留下來的未來選擇權也可能較少。但保存得更好不代表要每天檢查；重要的是**在休眠前達到足夠的可恢復門檻**。

## 15.9 情境 H：管理新增工作造成的治理佇列變化

設定初始待處理佇列 $D_t=20$，當期確實必要的新事件 $A_t=5$ 、完成或合法關閉 $C_t=8$ 、審查操作數 $M_t=10$。若平均每次審查產生 $\alpha=0.5$ 件需繼續處理的新工作，則：

$$
D_{t+1}=
\max(0,20+5+0.5\times10-8)=22.
$$

若授權與責任閘門能將選擇性改善提案留在不打擾人類的候選層，使真正進入人工治理佇列的有效平均新增率降為 $0.1$，則：

$$
D_{t+1}=
\max(0,20+5+0.1\times10-8)=18.
$$

這並不代表把本來必要的五件安全事故壓下去；它只描述「把可選建議當成待辦」與「可選建議先保存」之間的不同。若所謂減少工作實際上是漏掉了重大問題，此策略即失效。

## 15.10 八組算例比較

| 情境 | 改變的主要條件 | 示例結果 | 重要界線 |
|---|---|---|---|
| A | 低事件率、人工檢查昂貴 | $T^*=15.8114$ 日； $J^*=1.2649$ | 不能外推到正式服務 |
| B | 高事件率／高延誤成本 | $T^*=1.8257$ 日； $J^*=10.9545$ | 須調整頻率 |
| C | 服務反應上限為 1 日 | $J(1)=13$ | 合約和安全硬約束優先 |
| D | 120 項平均月檢改為風險選擇性檢查 | $24$ 小時降為 $4$ 小時 $40$ 分 | 須先校核未監督風險 |
| E | 監測高偵測率、低誤報 | $J_{event}=2.576$ | 需要可靠回交機制 |
| F | 監測低偵測率、高誤報 | $J_{event}=27.8$ | 事件驅動可能更差 |
| G | 保存品質與重啟成本不同 | $V_A=70$ 、 $V_B=34$ | 不是所有原型都保有同等選擇權 |
| H | 管理衍生任務被不同方式納入佇列 | $D_{t+1}=22$ 或 $18$ | 不得把必要事故當雜訊壓下 |

這些示意結果可由附錄 A 的原始程式直接重算。

---

# 16. 更一般的組合式決策：從逐個專案到整體時間資產

## 16.1 每項專案的最佳決策不必等於全體最佳

每一個項目都可能有「再改善一下」的正邊際價值，但所有改善要求加總後，可能超過實際可用人類時間與財務緩衝。若單獨評估每個專案，會忽略它們對同一主體注意力、資金、生活安排與外部責任的競爭。

因此令 $a_i(t)$ 表示對項目 $i$ 的當期動作，候選動作集合包含繼續、有限委任、有效休眠、公開靜態成果、安排退休、真正退出等。對全體專案的資源限制寫為：

$$
\sum_i H_i(a_i,t)+H_t^{cross}
\le B_t^{human},
$$

$$
\sum_i C_i(a_i,t)+C_t^{infra}
\le B_t^{cash}.
$$

其中 $B_t^{human}$ 是主體願意且可持續投入的工作時間，不能由 AI 額度或未來預測自動決定； $B_t^{cash}$ 則是實際可用資金，不含尚未入帳的假設收益。

## 16.2 人類節奏優先不是否定成果價值

有時候今天繼續完成一款遊戲、向外公開一項研究，可能很有價值；有時候把同一資產封存，留待未來環境和合作條件改善，也同樣合理。本文不以低工作量作為唯一目標，而要求外部承諾被處理後，當事人可實質改變自己對各種成果的投入比例。

## 16.3 最低必要管理的三種候選政策

**全面排程政策**：所有項目均要求固定日曆檢查。其優勢是容易掌握一般狀態；缺點是注意力成本隨項目數量上升，可能出現多餘流程。

**全面不干預政策**：所有項目不檢查、不安排責任。其優勢是短期人力成本低；缺點是在對外服務、安全風險與依賴存在時可能造成重大損害。

**義務／事件條件政策**：先完成最低必要的責任辨識與保存，再將資源投入有明確事件、不可延後承諾或值得自主選擇的工作；其餘資產保留低干擾狀態。本文研究的主要候選是第三者，但不能預先宣稱它對所有領域均優越。

## 16.4 有效休眠可以是中間狀態而非終局判決

進入休眠不一定表示項目「失敗」，更不要求永久決定今後不做。暫停本身可以避免人類使用今天有限的注意力去完成明天成本可能更低的工作。這一點直接承接 HACTS-07，但是否有效仍需檢查重啟成本、歷史窗口、實際興趣及資產保存。

## 16.5 資產沉積與人類生活不互斥

成熟的知識生產組織可讓已驗證的成果保留在可追溯檔案、程式庫或預印本中，並讓作者在另一次自然需要時才繼續。對外成熟產品則另有維護與客戶責任。將二者區分，既可保存研究的積累性，也能避免所有未完事項永遠占據創作者的每個工作日。

---

# 17. 十四項可否證假說

下列假說僅在預先定義的資產範圍、責任閘門與觀察時間內提出，不是任何個體的心理診斷或公司管理既定事實。每項均應預註冊主要結果及足以限制或推翻命題的反向觀察。

## H1｜資產數量與治理工時非必然線性

**預測：** 在控制對外服務、金流、依賴及風險後，採取有效休眠治理的組合，其人工治理工時對新增低風險資產數的敏感度，低於全面週期檢查的組合。

**可能反駁：** 新增低風險靜態資產仍導致等比例或更高治理工時，且無其他明顯品質或風險改善可解釋。

## H2｜管理內生增殖可被直接觀察

**預測：** 未設候選升格門檻的專案巡檢會顯著提高新增管理待辦數，其中有一部分在事後被判定為非必要。

**可能反駁：** 所有新增待辦均是之前未發現的必要義務，或改善提案未引起任何額外人類負擔。

## H3｜義務來源分帳降低候選誤升格

**預測：** 將外部義務與自主候選分帳，會減少非必要待辦與人工審批頻率，而不降低真實事故處置率。

**可能反駁：** 分帳未改變待辦結構，或增加真實事件漏處理率。

## H4｜在低事件率條件下較長檢查間隔可降低總成本

**預測：** 在事件率低、事件損失可控且每次檢查昂貴的樣本中，風險校準的較長檢查間隔會降低總成本。

**可能反駁：** 被延後發現的損失超過檢查成本節省，或事件率被低估。

## H5｜在高風險及高依賴條件下低干預不應預設較優

**預測：** 服務暴露或使用者依賴越高，不監測所引起的殘餘風險越可能超過人工監督成本。

**可能反駁：** 經同等品質監測與實際事故測量後，高風險服務在可靠無人干預下仍更安全；此時應修正人類介入需求，而非固守人工檢查。

## H6｜事件驅動效益受偵測品質中介

**預測：** 在真事件偵測率高、誤報率低時，事件觸發治理比固定週期檢查減少人類治理時間；相反條件可能導致負效益。

**可能反駁：** 在偵測品質相近的比較下，兩種策略差異主要由未建模因素主導且理論預測無辨識力。

## H7｜通知噪音會侵蝕所謂自主管理收益

**預測：** 即使 Agent 的實際執行成功率提高，若多餘警報與確認同時增加，使用者的注意力中斷和主觀待命負荷可能上升。

**可能反駁：** 通知上升但無任何可量測的注意力中斷或恢復成本，且其他條件下長期效益仍改善。

## H8｜高品質保存提高未來重啟成功率

**預測：** 在控制專案類型、時距與工具條件後，具有完整來源、相依、驗證和最低重啟入口的資產，未來恢復測試通過率高於缺少這些材料者。

**可能反駁：** 保存品質與重啟結果無關，或保存成本超過可測量的重啟價值。

## H9｜保存策略存在足夠好門檻而非越多越好

**預測：** 達到基本可恢復門檻後，某些額外文件和持續重構對重啟品質的邊際改善低於其成本。

**可能反駁：** 在觀察範圍內，額外保存投入一直有顯著更高的淨收益，且未出現邊際效益下降。

## H10｜平台封存狀態不能替代真實責任檢查

**預測：** 對外仍有依賴的已封存軟體，其安全、權利或支援風險不會因唯讀狀態自動消失。

**可能反駁：** 在限定環境中，所有外部依賴均已明確終止，且不存在可觀測殘餘風險；此時單一案例可視為正確退休，而非推翻一般的區分原則。

## H11｜全面月檢未必提高有效治理覆蓋率

**預測：** 在低風險資產比例高的組合中，增加全體週期檢查可能提高記錄數，但不同比例提高真正義務事件的準時處理率。

**可能反駁：** 全體巡檢穩定地發現並修正高價值隱性風險，且收益高於新增治理成本。

## H12｜人類可自主選擇高投入，而非必須低工時

**預測：** 可暫停、可拒絕、可修改目標的制度，能在不強迫降低自願創作時數的情況下提高可支配時間自主感。

**可能反駁：** 人類受制度影響沒有更大選擇空間，或制度不合理地阻止高投入創作。

## H13｜事件驅動治理存在失敗閾值

**預測：** 誤報頻率、漏報損失及回交延遲存在使事件驅動方案不再優於週期檢查的可識別區域。

**可能反駁：** 在充足變異的實驗資料中，成本差異不受這些因素影響，或無法用模型描繪出任何穩定閾值。

## H14｜時間主權成效不應只由產出或維護量評估

**預測：** 即使兩組有相近的成果品質、風險處理及外部收入，讓研究者減少非必要治理負擔的制度，仍可能提高其生活節奏的主觀可控性與實際退出能力。

**可能反駁：** 低干預制度沒有改善退出能力、可支配時間或恢復，而且伴隨相同或更高的負責任工作負擔。

## 17.1 避免自我保護式定義

本篇不允許把任何正面結果都歸因於 MNGPD，將所有反面結果都說成是使用者「不夠理解」。若嚴格紀錄的資料顯示特定類型資產需要高頻監督，或最小管理增加重啟失敗，模型就應收縮適用範圍。若低干預策略只是在短期內節省時間，但把成本推遲到未來，則應把未來重啟、事故及失效成本納入評估，不得僅報告當期工時。

---
# 18. 實證研究設計：要如何分辨有效休眠與管理疏忽？

## 18.1 研究目標與基本準則

驗證最小必要管理，不應只問「人類有沒有花比較少時間」。一個充分的研究必須同時測量：人類治理工時、干擾和注意力恢復、已存在義務的處理品質、安全與服務事件、財務成本、有效資產保存與未來重啟能力。

最重要的設計限制是：**不能把真實使用者置於未監督的高風險服務中，只為了測量低監督是否更省事。** 下列實驗原則上先使用研究型資產、模擬環境、經確認為低風險的靜態內容或已具合格最低安全控制的服務。

## 18.2 主要結果指標

定義單一研究週期 $[0,T]$ 的主要指標：

$$
H^{gov}_{0:T}=
\sum_{t=0}^{T}H_t^{gov},
$$

表示全部人工治理時間；須拆解讀取、審查、確認、切換與失敗恢復。再定義：

$$
Q_{duty}=
\frac{N_{required\ duties\ handled\ on\ time}}
{N_{required\ duties\ observed}+\epsilon},
$$

表示實際需要履行之事項的準時處理比例；若分母為零，該期間應報告「無觀測事件」，而不把 $Q_{duty}$ 誤說成百分之百安全。若漏掉的事件在觀察後才被發現，應補入審核後的事件母體與修訂紀錄。

還應報告：

- $N_{interrupt}$：人類工作或休閒中斷次數；
- $T_{resumption}$：返回原本任務的實際時間；
- $N_{falseAlert}$ ／ $N_{missedAlert}$：通知誤報與漏報；
- $Q_{restore}$：在標準恢復程序下重新取得可理解、可驗證成果的成功率；
- $C_{total}$：含 AI、平台、通知及人工成本的總成本；
- $U_{tempo}$：研究者對自己可暫停、改變節奏與拒絕新任務之能力的主觀量表；
- $N_{externalHarm}$：實際第三方損害、服務事故及需補救事件。

如果研究只報告 $H^{gov}$ 降低，而忽略 $N_{externalHarm}$ 或 $Q_{restore}$ 下降，就不足以支援 MNGPD。

## 18.3 實驗 A：專案組合的管理政策交叉比較

選擇多組研究型資產，先核對外部責任並依風險分層。在適合低干預比較的範圍內，隨機或交叉安排三種政策：固定日期檢查、事件條件檢查、以及由既有保存系統保障的靜態休眠。觀察治理人時、產出品質、重複通知及新產生的候選待辦。

需要注意，同一研究者在不同週期可能習得新習慣，且不同專案會彼此影響。因此可考慮以專案群作隨機化單位、調整順序並使用階段性切換；若無法滿足隨機化，應明確標為準實驗而非隨機實驗。

## 18.4 實驗 B：事件監督偵測品質實驗

在模擬的事件與事故資料上，建立固定檢查與事件觸發兩種處置策略。讓事件率、偵測率、誤報率、延遲損失及合約反應上限具有可控變異，預先登記理論對策略優劣翻轉閾值的預測。

此設計可以先在合成事件與受控沙盒進行，不需要讓真實客戶暴露於漏報風險。若未來進入正式服務，必須在外部責任及風險控制不劣的最低界線之上比較效率，而不是把不安全政策當成一般實驗條件。

## 18.5 實驗 C：休眠保存與重啟實驗

以可合法保存且不含敏感資料的研究程式、數學推導或可重現實驗為對象，隨機採取「達到最低門檻後停止修改」「高頻持續文件維護」「最低保存不完整」等受控對照。對必要資產不應故意製造資料遺失；所謂低保存品質可用隔離副本模擬，而完整原始檔仍妥善保留。

經過不同等待時間後，讓未參與原始開發的人員或另一組受權 AI／人類團隊進行盲測重啟，記錄重新理解、執行、驗證、修正以及識別權限邊界所需時間。研究重點不是 README 字數，而是可恢復的有效結果與整體保存成本。

## 18.6 實驗 D：個人創作者與微型組織的縱向資料

招募願意提供有限度匿名化資料的創作者和獨立開發者，利用經同意的低頻自陳、既有工具事件紀錄與匿名化通知統計，追蹤數週至數月的治理負荷變化。可比較取消不必要的固定檢討、改採安靜候選庫、建立外部義務閘門前後的差異。

應避免強迫參與者每天填寫冗長日誌來研究「管理負荷如何降低」，否則研究本身成為新的管理負擔。必要的事故與權利資料應分離保存，避免為了研究而蒐集私人 GitHub 原始碼、API 金鑰或未公開商業文件。

## 18.7 因果識別陷阱

**自我選擇**：本來風險低的人較可能主動使用休眠策略，不能把低事故率全歸因於政策。  
**難度分布**：簡單靜態文件與公開服務不能混為一組。  
**觀察窗口**：短期工時下降可能只是將重啟成本推往未來。  
**隱性服務依賴**：未被登記的客戶、第三方使用者或資料流程可能使表面低風險組合其實高風險。  
**報告偏差**：AI 生成的完成報告不等於有效完成或外部事故未發生。  
**共同依賴**：專案共享同一帳號、儲存、權限和維護者，觀測單位不是完全獨立。  
**主觀滿足差異**：有人熱愛管理並願意投入，不能把這種選擇誤寫成被壓迫；要測量他是否有實際退出或改變節奏的能力。

## 18.8 統計與發布要求

至少應在研究前固定主要結果變數、低干預適用門檻、反應時限、研究中止條件、效果量與不確定區間報告方式。若樣本不足以識別重要差異，就應如實報告不確定，而非將未顯著結果誤稱完全相同。研究者應記錄未觀測事件及資料缺口，對高嚴重度事故提供明確稽核途徑。

---

# 19. 強反論：什麼時候「少管理」是一個壞主意？

## 19.1 隱藏的義務比表面工作更多

若一項看似私人使用的工具實際為數十個網站提供核心 API，省略管理就可能中斷其他服務。可見 Repo 數量不是合理的責任邊界。最小治理必須在建立責任映射後才可安全生效；無法辨識責任時，合理結論不是「假設沒有責任」，而是標記不確定並安排有界的必要核查。

## 19.2 真正重要的事件不一定有可靠感測器

某些品質衰退、倫理風險或資料使用權問題，可能沒有即時技術警報。例如外部資料授權條款變動、訓練資料來源疑慮、看似正常但逐漸偏離承諾的模型行為。此時低頻抽查或人工專業判斷仍可能不可替代；純事件觸發並非萬能。

## 19.3 技術債可能隨時間非線性惡化

若長期停止維護使舊環境無法重建、資料格式被取代、重要套件消失，或第三方接口被移除，真正的休眠成本可能在某一時點陡升。此情況下，有限而定期的環境保存工作可能比完全靜止更划算。其適當頻率應依可觀察的技術依賴壽命，而不是統一日期。

## 19.4 對外公開可能產生下游信賴

開源庫、研究資料及教程可以在作者不更新時繼續被引用。公開不等於永續承諾，但已存在的版本支援聲明、重大安全事實、合理通知及適用法律責任不能無視。作者可以選擇不再維護，但必須區分**今後不再提供新功能**與**過去已造成的特定法律義務或正在運作的風險**。

## 19.5 有些人很樂意用高強度方式持續研究

本文不是要求所有研究者都轉向低工作時數，也不認為熱愛工作的人必定缺少時間主權。若研究者具有可行的財務和生活條件、理解成本與後果，仍自由選擇密集創造，那也可能是自主性的表現。所謂治理改善只能提供更多實質選擇，不應替當事人規定唯一正確節奏。

## 19.6 管理帶來的額外工作可能是好事

主動巡檢若發現以前未察覺的嚴重漏洞、研究錯誤或權利衝突，即使增加待辦也可能是進步。MNGPD 不是追求低到不合理的 issue 數，而是避免**對沒有合理風險或外部義務來源的事物，機械產生必須履行的責任**。

## 19.7 組織記憶若持續減少也可能造成成本

如果保存文件過於稀少，以致團隊未來完全不理解專案，則省下的今日治理時間將轉成未來理解負債。本文因此要求「達到最低可恢復門檻」作為休眠的先決條件，而不是鼓勵刪除必要紀錄。

---

# 20. 應用介面：如何讓一個研究型公司真的具備休眠能力？

## 20.1 最少必要設計，不等於新建一座龐大平台

現有倉庫、檔案庫、版本控制、共同備份、權限管理或 EVEMISS Registry 已能承擔的功能，不需要因本文再建一套平行系統。目標是改變預設行為：管理系統不再把「所有項目每月前進」視為正常狀態，而接受「部分成果安全地不動」作為一種合格狀態。

## 20.2 新專案建立時

只在真正必要時記錄：基本識別與來源、是否對外運行或具有使用者、是否涉及敏感資料和金流、目前是否存在必須處理的義務、下一個合理可用的研究入口，以及有效保存的位置。不需要為每個最小概念自動生成幾十頁 Roadmap。

## 20.3 準備暫停時

確認核心成果已留下可理解的版本；必要的測試與環境資訊存在；正式服務如仍在運作，已有合格監測或停止／轉移方案；不必要的 Agent、排程、資源費用可被停止；並保留日後自由重審的路徑。

## 20.4 長期休眠時

低風險資產可由共同保存系統提供完整性保障；真正仍需監測的對外服務由有權限的營運／安全渠道負責。多餘的進度提醒、非必要升級、無期限 Agent 探索和自動創造待辦可以關閉。

## 20.5 再次需要使用時

重新取得版本及相依資訊，檢查授權、工具和安全情況是否改變；先運行最低可驗證恢復程序，再決定是否擴張。重新啟動應優先詢問「現在仍值得嗎？」而不是「以前規劃到第幾 Phase 了？」

## 20.6 公開與私人狀態分離

公開頁面可以如實聲明專案仍提供原始碼但暫不維護；內部頁面可以更完整列出風險和技術狀態；私人決策註記未必需要公開。公開發表、授權與商業承諾是不同事件，不能因改成公開 GitHub 而自動推斷是自由／開源軟體，也不能因成果已公開而取消保密義務的前期檢查。

## 20.7 低成本退場模板

若原始碼曾公開使用，可在 README、SUPPORT.md 或 SECURITY.md 等適當文件說明版本是否受維護、已知限制、替代方向及安全通報路徑；若服務即將下線，對應通知、資料匯出及必要合約處理應另行安排。本文只提出操作性類別，不能代替具體法域法律分析。

---

# 21. 哲學分析：不是所有存在都要求行動

## 21.1 未完成的事物可以擁有非當期價值

我們經常把「有可能做」與「應該做」連在一起，尤其在 AI 可以大幅降低執行門檻後，這種錯誤很容易擴大。創作者可能看見每項成果更遠的後續：新的研究分支、新的工具、新的產品，甚至新的收入路徑。這些可能性可以是真實且有趣的，但它們不因此產生同等強度的當期責任。

更準確地說，可能性是選擇的內容，責任是由特定規範或承諾賦予的約束；行動又需要考慮環境、資源與主體意願。三者在概念上不可混同。

## 21.2 不持續管理可以是負責任的保留

若一項成果已妥善保存、暫時沒有使用者、無未處理權利風險或正在運行的服務，讓它安靜存在，未必比繼續擴張更不負責。對創作者而言，這可能保留未來使用的選擇，並讓今天的人生時間回到其他真正想要投入的事情。

## 21.3 放手並非把未來當作已經完成

放手不等於宣稱未來的 AI 一定會替自己完成一切；也不等於任何人都應理解、採納、實現自己的研究。對未來保持開放，正是允許不同的作者、研究者、合作團隊、市場和技術環境給出意外的答案，而不必由最初提出構想的人控制所有歷史後果。

## 21.4 一個對稱的自由結構

如果人類有能力選擇更多研究路徑，卻不能合法且有效地停下其中任何一條，那麼可能性數量增加並不必然擴張其實質自由。真正的選擇包括開始、繼續、重新排序、保存、暫停、退出、轉移和回返，而不是只有「繼續」和「更加努力」兩個按鈕。

## 21.5 時間主權需要與財務現實共同成立

有些人不是因為高收入而能任意休息，反而是在資金很薄的條件下選擇保留研究。此時可持續現金流、固定支出、支援契約與生活安排，都會影響真正可行的休眠選項。若要讓公司活得夠久以等到更好的 AI、設備或合作，減少非必要管理本身可能有實質意義。但如果無法支付當下基本成本，單純休眠仍不能解決現金缺口。這部分留待 HACTS-09 具體分析。

---

# 22. 理論限制、適用範圍與開放問題

## 22.1 不是臨床診斷

本篇沒有診斷工作成癮、注意力疾病或心理障礙，也不把持續自主投入自動視為病理。它處理的是資產管理制度和主體時間配置的關係。若研究涉及心理狀態，應採合法同意的客觀與主觀資料，並尊重不同高投入創作者的差異。

## 22.2 不是普遍的「更少管理定律」

所有成本與安全結論都依賴風險、責任、事件頻率、偵測品質、資產性質與工具能力。某些大型企業、醫療或基礎建設系統需要嚴格、持續的合格監督；不能把本文低風險靜態資產的條件直接延伸。

## 22.3 候選責任可能有爭議

什麼屬於真正的外部義務，有時涉及法律、倫理、使用者合理期待和專業標準；這些不是任何演算法可以單方面最終裁定的事項。系統可記錄判斷與證據，但難題仍需要有權責的人類或合格機構處理。

## 22.4 數學模型沒有顯示全部路徑依賴

本文的平方根檢查式與線性排隊模型只是低維基準。真實服務的事故可能自我激發、群聚、跨系統蔓延，或有沉默的累積損失；偵測器也可能受對手行為操縱。任何對安全敏感的工程應選用與具體威脅相符的監測和驗證方法。

## 22.5 資產價值很難完整量化

論文、理論、遊戲構想與個人創造快樂，不能都由市場現金流單一估價。本文使用的等價成本只為了比較候選治理策略，無法替代主體真實的價值選擇與公共責任。

## 22.6 大量休眠可能形成別種組織風險

若休眠後的專案既無可靠來源也無有效搜尋入口，組織會累積「形式上還有資料、實際上不知在哪」的幽靈資產。最低索引和保存政策不可省略，否則名義上的時間紅利會轉成未來大量搜尋、重做與被迫重新發明。

## 22.7 未來工作

應研究高維風險監測、可校準的事件偵測、專案相依網路、研究成果長期可再現性、多 Agent 低打擾治理、人類注意力與財務緩衝的聯合效用，以及用真實資料估計何時需要從休眠轉為活躍。本文不是這些問題的終點。

---

# 23. 結論：當不需要持續管理時，讓成果安靜存在

本篇提出的最小必要管理，反對兩個對稱但同樣不理想的極端：一方面，任何新研究資產都被要求接受同樣進度追蹤、週期檢討與後續 Phase，從而讓管理活動反過來吞噬創作者的時間；另一方面，將所有專案全部交給不受監督的 Agent 或只按下封存，卻對正在使用的服務、已存在的安全和法律義務、第三方依賴及未來可恢復性置之不理。

真正的研究問題不是「管理是否愈少愈好」，而是：**在可靠履行已有義務、控制不可接受風險、保留必要研究資產的條件下，哪些治理行動仍然值得占用人類的時間？**

若部分成果已足夠好、可保存、可回返，且不存在需要立即處理的外部責任，讓其保持休眠可以是有效治理，而不必被解讀成怠惰或失敗。同時，若資產轉為外部服務或被其他人長期依賴，治理方式就必須依新事實更新，而不能躲在舊有的「休眠」標籤之下。

這裡提出一項可供後續研究的綱領性表述：

> **不被使用的產能可以留白，不需當期實現的選擇可以保存，不存在外部義務的資產可以安靜；但真正存在的風險、權利與責任，必須由可追溯且有能力的治理者處理。**

AI 原生組織的成熟，不能只以它每天執行多少任務、生成多少計畫或管理多少 Repository 衡量，也應觀察：在高能力、高資訊、高資產存量條件下，系統能否讓人的有效退出、改變節奏與安全回返成為日常可能。

一個人可以熱愛創造，持續保有大量理論與工程選擇，也可以在下一次真正想做的時候才重新啟動其中一部分。**不是所有已經存在的未來，都必須每天被管理。**

---
# 附錄 A｜八組思想實驗的可重算程式

下列程式只使用 Python 標準函式庫，供獨立核對第 15 節的模型算例。**程式的成功執行不等於對真實組織治理有效性的實證驗證。** 其用途是確認本文在既定參數下的數值前後一致；真實研究仍需要資料品質、模型識別與權利／風險閘門。

```python
from math import isclose, sqrt


def periodic_optimum(check_cost, event_rate, delay_rate):
    if check_cost <= 0 or event_rate <= 0 or delay_rate <= 0:
        raise ValueError("The closed-form optimum requires positive inputs.")
    interval = sqrt(2 * check_cost / (event_rate * delay_rate))
    cost = check_cost / interval + event_rate * delay_rate * interval / 2
    return interval, cost


def periodic_cost(check_cost, event_rate, delay_rate, interval):
    if interval <= 0:
        raise ValueError("interval must be positive")
    return check_cost / interval + event_rate * delay_rate * interval / 2


def event_cost(base, triage, sensitivity, event_rate,
               false_alerts, missed_event_loss, delay_rate,
               detection_delay):
    return (
        base
        + triage * (sensitivity * event_rate + false_alerts)
        + (1 - sensitivity) * event_rate * missed_event_loss
        + sensitivity * event_rate * delay_rate * detection_delay
    )


def remaining_option_value(probability, future_value,
                           preservation_cost, restart_cost):
    return probability * future_value - preservation_cost - restart_cost


def next_governance_queue(queue, true_arrivals, review_events,
                          generated_rate, closed):
    return max(0, queue + true_arrivals + generated_rate * review_events - closed)


# A — Low event rate
TA, JA = periodic_optimum(10, 0.01, 8)
assert isclose(TA, 15.811388300841896, rel_tol=1e-12)
assert isclose(JA, 1.2649110640673518, rel_tol=1e-12)
assert isclose(periodic_cost(10, 0.01, 8, 1), 10.04)

# B — Higher event rate and delay loss
TB, JB = periodic_optimum(10, 0.3, 20)
assert isclose(TB, 1.8257418583505538, rel_tol=1e-12)
assert isclose(JB, 10.954451150103322, rel_tol=1e-12)

# C — A contractual or safety upper bound of one day
assert isclose(periodic_cost(10, 0.3, 20, 1), 13.0)

# D — Periodic all-project reviews versus selective handling
all_review_minutes = 120 * 12
selective_minutes = 15 * 12 + 4 * 25
assert (all_review_minutes, selective_minutes) == (1440, 280)
assert all_review_minutes - selective_minutes == 1160

# E — Event-driven with accurate detection and low alert noise
JE = event_cost(1, 2, 0.98, 0.3, 0.05, 50, 20, 0.1)
assert isclose(JE, 2.576, rel_tol=1e-12)

# F — Event-driven with missed events and high alert noise
JF = event_cost(1, 2, 0.5, 0.3, 8, 50, 20, 1)
assert isclose(JF, 27.8, rel_tol=1e-12)

# G — Preservation quality and restart cost
VA = remaining_option_value(0.9, 100, 5, 15)
VB = remaining_option_value(0.7, 100, 1, 35)
assert (VA, VB) == (70, 34)

# H — New governance obligations generated per review
Q_high = next_governance_queue(20, 5, 10, 0.5, 8)
Q_low = next_governance_queue(20, 5, 10, 0.1, 8)
assert (Q_high, Q_low) == (22, 18)

print("HACTS-08 illustrative calculations: PASS")
```

---

# 附錄 B｜最低治理契約與可恢復性檢查表

以下檢查表只是研究型介面；實際高風險產品或公司必須依合法責任和風險補充，不得以此作為完成所有法規或資安要求的證據。

## B.1 休眠入口的必要問題

- [ ] 能辨識資產的實際來源、已完成版本與授權限制嗎？
- [ ] 需要日後重啟的材料是否達到最低可恢復門檻？
- [ ] 是否仍有正在運行的服務、排程、金流、資料處理或第三方依賴？
- [ ] 如有外部義務，是否已確認明確的負責者、服務期限與必要回交路徑？
- [ ] 不必要的固定通知、AI 自動續做與資源持續消費，是否有明確停止條件？
- [ ] 此次休眠是否可在不違反現有承諾的條件下進行？
- [ ] 是否保留可由未來的授權者重新判斷，而不是被過往 Roadmap 強制鎖定的入口？

## B.2 對外公開的必要問題

- [ ] 可見性、可利用授權、支援承諾與內容歸屬是否被分開處理？
- [ ] 是否清楚說明專案當下支援狀態，而非僅以 GitHub 更新日期讓人猜測？
- [ ] 是否確認沒有公開祕密、個資、受限文件及不應釋出的公司資料？
- [ ] 對其他人仍在使用的公開資產，是否有適當的安全或停止支援資訊？
- [ ] 已引用的研究或程式版本是否保有穩定的版本與來源紀錄？

## B.3 重新啟動的必要問題

- [ ] 這個專案現在仍值得做嗎？可以合法、可行地不做嗎？
- [ ] 與保存時相比，需求、模型、程式環境、授權及安全條件有何改變？
- [ ] 是否先做最低恢復與驗證，而不是立即擴張新的 Phase？
- [ ] 是否有新的真實對外義務產生？若有，誰負責？
- [ ] 是否保留改造、轉移、再次休眠或退休的選擇？

---

# 附錄 C｜術語與符號字典

| 符號／術語 | 操作性定義 | 容易發生的誤解 |
|---|---|---|
| $\mathcal P_t$ | 時點 $t$ 的可識別研究與專案資產集合 | 不等於待辦清單 |
| $\mathbf d_i(t)$ | 資產外部義務來源向量 | 不能只由公開／私人標籤推定 |
| $G_i(t)$ | 當期真正需要的有效治理行動集合 | 不等於 Agent 全部改善建議 |
| $\mathcal D_t$ | 在最低保存與責任條件下可有效休眠的資產集合 | 不是永遠不再理會的永久標籤 |
| $H_t^{gov}$ | 人類在管理與治理上的實際注意力投入 | AI 的運算時間不能直接取代 |
| $C_t^{AI}$ | AI 推理、工具、執行及驗證等成本 | 額度更多不代表收益等比成長 |
| $D_t$ | 真正進入治理流程的待處理佇列 | 不含所有尚未承諾的靈感 |
| $\alpha_t$ | 管理活動平均誘發後續治理工作數 | 不必都代表低價值；須分來源 |
| $T$ | 週期檢查的間隔天數 | 不是專案進度期限 |
| $c$ | 每次檢查成本 | 必須與其他數值使用相容單位 |
| $\lambda$ | 單位時間事件平均到達率 | 非普遍固定常數 |
| $h$ | 每事件每單位延遲時間的等價損失參數 | 不能掩蓋重大不可逆損失 |
| $s$ | 事件感測器的真事件偵測比例 | 必須用實際測試校準 |
| $f$ | 單位時間誤報數 | 誤報會占據人工注意力 |
| $Q_i^{rec}$ | 在指定使用目的下的最低可恢復性代理 | Git 提交存在不代表能恢復 |
| $V_i^{restart}$ | 新資訊下重新啟動的預期有效價值 | 不一定是金錢收益 |
| $B_t^{human}$ | 人類當期可持續且自願投入的時間預算 | 不應由剩餘 AI 額度自動決定 |
| $B_t^{cash}$ | 當期實際可用的財務資源 | 不含尚未實現的預期銷售收入 |
| *effective dormancy* | 已履行最低必要責任且可保留未來選擇的低活動狀態 | 不等於無安全保障的遺棄 |
| *governance proliferation* | 治理活動可能持續創造新治理事項 | 並非所有新發現都應被壓制 |
| *risk-triggered oversight* | 依可觀察義務與風險事件調整干預 | 不等於所有項目無期限免檢 |

---

# 附錄 D｜技術實作不變量與品質閘門

**G-1：資產存在不能自動生成待辦。** `exists=true` 不應直接導出 `human_task_due=true`。

**G-2：AI 建議不是人類承諾。** 所有新增正式義務要有可稽核的授權或外部來源。

**G-3：休眠不能取消外部義務。** 服務、金流、資料、合約與安全需要合法且明確的承接。

**G-4：低活動不能掩飾真實風險。** 監測頻率依風險與責任調整，而非只依最後一次 Git Commit。

**G-5：保存與發布分離。** 保存原稿不等於對外發布；發布不等於開源；授權不等於承諾永久維護。

**G-6：回返不等於強制續做。** 重新啟動可得出合理的退出或再次休眠結論。

**G-7：人類時間與機器時間分帳。** 自主 Agent 不能以更多推理事件掩蓋人類注意力負荷上升。

**G-8：高風險事件需獨立升級通道。** 重大事故不應與普通研究建議混在同一低優先通知佇列。

**G-9：所有公開對外狀態都要可稽核。** 名稱、可見性、授權、支援與實際部署情況不能只靠聊天記憶推斷。

**G-10：原稿與驗證結果不作無聲覆寫。** 新版本應保留來源、可核對的變更和原始研究身份。

**G-11：數學思想實驗不可誤報成實證成果。** 示意數值、實驗資料與統計結論保持不同證據等級。

**G-12：管理平台不必自動擴張。** 若現有 Registry、Repo、備份與權限工具足以達成治理，新增平台功能須以可驗證的負擔降低與風險改善為理由。

---

# 參考文獻｜外部學術與官方技術來源

**引用原則：** [E#] 為本文查閱的既有學術研究、官方工程文件或技術標準，僅支援其本身討論的對應機制，不宣稱它們已經驗證本篇整合模型。以下來源於 2026-10-17 檢視；對持續更新的技術文件，正式公開前應再次確認版本與具體內容。本文不存在由外部研究直接得出的「MNGPD 普遍最優」結論。

**[E1]** Ocasio, W. (1997). *Towards an Attention-Based View of the Firm*. *Strategic Management Journal*, 18(S1), 187–206. https://experts.illinois.edu/en/publications/towards-an-attention-based-view-of-the-firm/  
**用途與限制：** 組織注意力如何受到流程與結構分配；非 AI 休眠管理的直接實驗。

**[E2]** Sims, C. A. (2003). *Implications of Rational Inattention*. *Journal of Monetary Economics*, 50(3), 665–690. https://doi.org/10.1016/S0304-3932(03)00029-1  
**用途與限制：** 有限資訊處理能力及注意力配置；不直接測量創作者認知疲勞。

**[E3]** Leroy, S. (2009). *Why Is It So Hard to Do My Work? The Challenge of Attention Residue When Switching Between Work Tasks*. *Organizational Behavior and Human Decision Processes*, 109(2), 168–181. https://doi.org/10.1016/j.obhdp.2009.04.002  
**用途與限制：** 切換後殘留注意力的實驗研究；不能直接推定所有休眠專案都會引起相同效果。

**[E4]** March, J. G. (1991). *Exploration and Exploitation in Organizational Learning*. *Organization Science*, 2(1), 71–87. https://doi.org/10.1287/orsc.2.1.71  
**用途與限制：** 探索／利用與跨期組織學習的權衡；不預先指定任一具體專案需休眠。

**[E5]** Simon, H. A. (1956). *Rational Choice and the Structure of the Environment*. *Psychological Review*, 63(2), 129–138. https://doi.org/10.1037/h0042769  
**用途與限制：** 有限理性與足夠好判準；不是降低法定安全要求的根據。

**[E6]** Beyer, B., Jones, C., Petoff, J., & Murphy, N. R. (Eds.). (2016). *Site Reliability Engineering: How Google Runs Production Systems*, Ch. 5, *Eliminating Toil*. Google. https://sre.google/sre-book/eliminating-toil/  
**用途與限制：** 人工、重複及低持久價值的維運負荷識別；不代表所有常態服務監控都可取消。

**[E7]** Schrier, C., et al. (2018). *Eliminating Toil*. In *The Site Reliability Engineering Workbook*. Google. https://research.google/pubs/the-site-reliability-engineering-workbook-chapter-eliminating-toil/  
**用途與限制：** 對實務維運工作加以辨識與控制；不等同於本篇全部多專案治理模型。

**[E8]** Dempsey, K., et al. (2011). *Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations*. NIST SP 800-137. https://doi.org/10.6028/NIST.SP.800-137  
**用途與限制：** 風險導向資訊安全監督的基礎指引；不是本文平方根檢查頻率公式的來源或官方背書。

**[E9]** GitHub Docs. (2026 年查閱). *Archiving repositories*. https://docs.github.com/en/repositories/archiving-a-github-repository/archiving-repositories  
**用途與限制：** GitHub 唯讀封存及重新解除封存的官方功能說明；平台狀態不是法定義務終止證明。

**[E10]** GitHub Docs. (2026 年查閱). *Dependabot alerts*. https://docs.github.com/en/code-security/concepts/supply-chain-security/dependabot-alerts  
**用途與限制：** 說明 Dependabot 不掃描已封存儲存庫等官方限制；不代表其他所有安全措施或外部監測均不存在。

**[E11]** Open Source Security Foundation (OpenSSF). (2026-08-28). *Open Source Project Security Baseline*, v2026.08.28. https://baseline.openssf.org/versions/2026-08-28  
**用途與限制：** 支援範圍、維護生命週期及公開安全資訊的分級控制條目；並非所有實驗性私人原型均具有同一成熟度義務。

**[E12]** OpenSSF Best Practices Working Group. (2025 年發布，2026 年查閱). *Concise Guide for Evaluating Open Source Software*. https://best.openssf.org/Concise-Guide-for-Evaluating-Open-Source-Software.html  
**用途與限制：** 對開源依賴、維護性及下游風險的評估指引；不能證明單一專案必然脆弱。

**[E13]** Software Heritage. (2021-04-30 版本文件；2026 年查閱). *SoftWare Hash persistent IDentifiers (SWHIDs)*. https://docs.softwareheritage.org/devel/swh-model/persistent-identifiers.html  
**用途與限制：** 原始碼持久識別與來源可追溯性；不保證仍可編譯、部署或具有合法使用權。

**[E14]** Brockner, J. (1992). *The Escalation of Commitment to a Failing Course of Action: Toward Theoretical Progress*. *Academy of Management Review*, 17(1), 39–61. https://doi.org/10.5465/amr.1992.4279568  
**用途與限制：** 投入已失敗路徑時的承諾升高機制；不表示持續研發或長期維護本身是錯誤。

---

# 參考文獻｜EveMissLab／無界智庫既有研究與 HACTS 系列

以下 [I#] 為既有內部或公開研究來源，不代表所有內容都已公開授權，亦不代表通過外部同儕審查。其用途是避免對已存在的思想譜系進行重複首創宣告；本文未修改任何原始檔案或其存取權限。

**[I1]** *AI 原生多專案治理與來源可信性：從單一倉庫管理走向軟體資產組合治理*（2026-07-23，v0.1）。https://unboundedaxiom.org/p/lm-001729/

**[I2]** *EVEMISS Registry：分級產品索引與管理控制台設計文件*（2026-07-18，v0.1）。

**[I3a]** *HODR-II｜選擇權囤積與不可逆決策*（2026-09-26，v0.1）。  
**[I3b]** *HODR-IV｜AI 生產力與可能性空間爆炸*（2026-09-26，v0.1）。

**[I4a]** *HAVT-06｜從失業時間到時間主權*（2026-10-06，v0.1）。https://unboundedaxiom.org/p/lm-004988/  
**[I4b]** *HAVT-07｜多速度文明：拒絕、升階、退出與回返*（2026-10-06，v0.1）。https://unboundedaxiom.org/p/lm-004989/

**[I5a]** *從 AI 工具到 AI 組織：操作員退出問題*（2026-08-20，v0.1）。https://unboundedaxiom.org/p/lm-003327/  
**[I5b]** *委任時間論：自主 Agent、人類介入密度與治理槓桿*（2026-08-20，v0.1）。https://unboundedaxiom.org/p/lm-003321/

**[I6]** *HDUS Enterprise Governance Runtime：Policy、Authority、內部法律域與責任鏈*（2026-08-21，v0.1）。

**[I7]** *HACTS-07｜未來自我與技術等待選擇權：為什麼有些事情留給未來完成反而更合理*（2026-10-17，v0.1）。Canonical UTF-8 Markdown：`HACTS-07_未來自我與技術等待選擇權_v0.1_2026-10-17.md`。

**系列前作檔案：**

- `HACTS-00_從無限可做之事到有限可支配人生_v0.1_2026-10-16.md`
- `HACTS-01_生產力內生擴張悖論_v0.1_2026-10-16.md`
- `HACTS-02_額度重置與時間支配_v0.1_2026-10-16.md`
- `HACTS-03_自願性高投入的雙重狀態_v0.1_2026-10-16.md`
- `HACTS-04_代理並行與認知待命_v0.1_2026-10-16.md`
- `HACTS-05_時間主權的微觀決策_v0.1_2026-10-16.md`
- `HACTS-06_黃金窗口與歷史時間不對稱_v0.1_2026-10-16.md`
- `HACTS-07_未來自我與技術等待選擇權_v0.1_2026-10-17.md`

---

# 原稿品質、論證分級與承責聲明

1. **唯一正式原稿：** 本 UTF-8 Markdown 是此版本唯一 canonical source；聊天畫面僅用於討論和閱讀。
2. **數學分隔符保真：** 正式數學一律使用 ` $...$ ` 及 `$$...$$`。不使用 `\(...\)` 或 `\[...\]` 作為 source，不做 Unicode 數學符號回轉為 LaTeX。
3. **數學模型與數值證據分級：** 第 10 節的檢查間隔推導只在特定假設下成立；第 15 節的算例為思想實驗，並非實測事故率或已驗證的人類行為效應。
4. **外部研究謹慎對照：** 文獻僅支援注意力稀缺、有限理性、維運負荷與風險監督等既有機制；MNGPD 的整合命題需獨立測試。
5. **不取消外部責任：** 對外服務、個資、金流、合約、使用者安全與第三方權利不能透過 `dormant` 或 `archived` 標籤自行豁免。
6. **公開不等於開源：** 必須區分原始碼公開可見、正式使用許可、營運服務承諾與合法權利歸屬。
7. **最低管理不代表零保存：** 有效休眠需要依未來用途達到最低可恢復性門檻，並保護備份及來源。
8. **個人高投入可以是自主選擇：** 本篇反對把高創造強度直接等同病理，也反對讓 AI 產能直接支配人類時間。
9. **實際風險不應被平均數掩蓋：** 高嚴重度、非線性和不可逆事件應使用更嚴格的外部治理條件。
10. **AI 能力提升不保證休眠正收益：** 未來軟體技術、模型、硬體與商業條件可能改善，也可能惡化。
11. **版本歷史與權利不被偷偷變更：** 修改應以清楚版本號、新原稿與校驗紀錄處理，不得靜默覆蓋既有公開研究的時間證據。
12. **可被推翻：** 若具代表性的比較研究顯示低干預策略不能降低綜合治理負擔、造成更差的恢復或更多外部風險，應修改或限制本框架，而非重新定義所有反例為成功。
13. **研究方法與治理倫理一致：** 試驗不應要求參與者持續補充冗長的管理資料，也不應為了驗證低監督而故意使第三方處於不安全的條件。
14. **系列接口：** 後續 HACTS-09 將處理財務緩衝與可持續創業；HACTS-10 將提出人類節奏優先的自主 AI 組織實作契約，不在本篇宣稱已完成相關系統部署。

**END — HACTS-08 v0.1**
