# 從靜態檔案到生成資料生命週期

## 論現代應用程式的可移除性標記、風險轉嫁與作業系統資料治理

**作者：Neo.K**\
**版本：v1.0 概念論文／系統設計命題稿**
**日期：2026 年 7 月**

***

## 摘要

現代應用程式早已不再只是「讀取檔案—執行程式—輸出結果」的簡單系統。編譯器、瀏覽器、開發工具、遊戲引擎、套件管理器、AI 應用、本機模型、代理系統與多媒體軟體，會持續生成大量快取、索引、中間表示、編譯產物、更新包、回復快照、模型權重、服務工作者資料、崩潰傾印、暫存工作區、推理快取與其他衍生物。然而，現代檔案系統與多數應用程式仍主要以「檔案存在」為核心管理單位，缺乏對資料之生成來源、依賴關係、可重建性、可移除性、重建成本、保留期限與任務完成狀態的明確描述。

本文提出一個核心命題：**凡由應用程式自動生成之資料，資料生成者原則上應負責聲明其生命週期與可移除性，而不應將判斷成本與刪除風險轉嫁給使用者。** 本文進一步區分使用者原始資料、不可重建資料、可重建資料、可重新下載資料、任務中間產物、效能快取、歷史回復資料、診斷資料、更新殘留與孤兒資料，並提出「生成資料生命週期宣告」與「衍生資料回收區」之系統架構。

本文主張，當代軟體已進入「大量生成資料時代」，但作業系統仍停留在「靜態檔案時代」。真正需要被管理的，已不只是檔案，而是資料之生成關係、資訊價值、可再生性與刪除後果。若此問題未被處理，AI 與 Agent 時代將使個人電腦、工作站與雲端環境逐步演化為不可理解的資料考古遺址。

***

## 關鍵詞

生成資料、資料生命週期、可移除性、可重建性、檔案系統、應用程式責任、快取治理、衍生資料、作業系統、AI Agent、資料本體論

***

# 1. 問題的起點：為何刪除 C 槽資料像拆炸彈？

對許多使用者而言，作業系統碟是一個特殊區域。

使用者可能知道：

* 有些檔案可以刪；

* 有些快取刪除後只會重建；

* 有些資料刪除後只是重新下載；

* 有些資料一旦刪除，程式會損壞；

* 有些資料若被誤刪，甚至可能導致作業系統無法正常啟動。

這導致一個極為現實的使用者行為：

> **在作業系統區，不確定的東西就不敢刪。**

這不是無知，而是合理的風險規避。

尤其對曾經因誤刪系統檔案而造成無法開機、被迫重灌作業系統的使用者而言，C 槽中的未知資料夾不只是「雜亂」，而是一種實際風險。此後每一次清理，都必須面臨同一個問題：

> 這個 5 GB 的資料夾到底是什麼？\
> 它能不能刪？\
> 刪了只是變慢，還是程式損壞？\
> 刪了只是重新下載，還是永久遺失？\
> 這是使用者資料，還是可重建產物？\
> 這是系統依賴，還是更新殘留？

而現代應用程式往往沒有回答。

這構成本文的第一個基本問題：

> **應用程式知道資料是如何生成的，為何使用者卻必須自己猜哪些資料可以刪？**

***

# 2. 現代應用程式已不是「程式＋檔案」

早期的軟體直覺相對簡單：

```text
程式
├── 執行檔
├── 設定檔
└── 使用者文件
```

但現代應用程式的資料鏈更接近：

```text
原始輸入
↓
解析結果
↓
中間表示
↓
索引
↓
快取
↓
編譯產物
↓
增量編譯資料
↓
模型下載
↓
模型轉換
↓
預處理結果
↓
縮圖
↓
Shader Cache
↓
Checkpoint
↓
Workspace Snapshot
↓
Crash Dump
↓
Update Package
↓
Rollback Package
↓
Service Worker Cache
↓
Telemetry Buffer
↓
Temporary Corpus
↓
Vector Index
↓
Inference Cache
↓
未知殘留
```

這裡的核心變化是：

> **現代軟體會大量生成「不是原始資料，但又長期存在」的資料。**

其問題不在於生成本身。

很多資料確實能提升：

* 效能；

* 回復能力；

* 穩定性；

* 離線使用；

* 編譯速度；

* 模型載入速度；

* 網頁回應速度；

* 推理效率；

* 使用體驗。

真正的問題是：

> **生成之後，應用程式往往不再向使用者解釋這些資料的狀態。**

***

# 3. 核心命題：資料生成者應負責聲明資料生命週期

本文提出第一核心命題。

## 命題 1：生成者生命週期責任命題

設應用程式 (A) 生成資料物件 (d)，則在合理可行範圍內，(A) 應聲明：

$$
L(d)=
\langle
o,r,x,c,t,p,s
\rangle
$$

其中：

* (o)：Origin，生成來源；

* (r)：Reconstructability，可重建性；

* (x)：Removability，可移除性；

* (c)：Reconstruction Cost，重建成本；

* (t)：Retention，建議保留時間；

* (p)：Dependency，依賴關係；

* (s)：State，當前生命週期狀態。

換句話說，對一個由應用程式生成的資料而言，至少應能回答：

1. 誰生成我？

2. 我由什麼生成？

3. 我能否重建？

4. 刪除我會損失資訊，還是只損失時間？

5. 我是否仍被使用？

6. 誰依賴我？

7. 我的任務是否已完成？

8. 我應保留多久？

9. 我是否已成為孤兒資料？

***

# 4. 問題的本質不是垃圾，而是資訊不對稱

傳統磁碟清理將問題理解為：

> 「垃圾太多。」

但本文認為更精確的問題是：

> **資料生成者與資料承擔者之間存在資訊不對稱。**

應用程式知道：

```text
這是快取。
這是更新殘留。
這是模型下載。
這是可重建索引。
這是已完成任務的中間產物。
這是失效工作區的孤兒資料。
```

使用者只看到：

```text
C:\Users\...\AppData\Local\...
C:\ProgramData\...
.cache
.workspace
.models
.blobs
objects
packages
artifacts
snapshots
storage
CacheStorage
GPUCache
Code Cache
```

於是產生極不對稱的責任結構：

$$
K_A(d) > K_U(d)
$$

其中：

* (K\_A(d))：應用程式對資料 (d) 的生成知識；

* (K\_U(d))：使用者對資料 (d) 的生成知識。

通常：

$$
K_A(d) \gg K_U(d)
$$

然而刪除決策卻由使用者承擔：

$$
R_U(d) \approx 1
$$

其中 (R\_U(d)) 表示使用者承擔主要風險。

因此形成矛盾：

$$
K_A(d) \gg K_U(d)
\quad \land \quad
R_U(d) \gg R_A(d)
$$

即：

> **知道最多的人不負責判斷，知道最少的人承擔刪除風險。**

這是本文所稱的：

# 資料刪除風險轉嫁

***

# 5. 為何「事情做完就標示可移除」不是困難問題？

本文不主張所有生成資料都要立即刪除。

真正需要的是：

> **狀態聲明。**

例如某工作完成後，應用程式可以把資料標記為：

```text
ACTIVE
```

表示仍在使用。

任務完成後改為：

```text
RECONSTRUCTABLE
```

若不再被引用：

```text
DISPOSABLE
```

若來源專案已不存在：

```text
ORPHANED
```

若超過保留期限：

```text
EXPIRED
```

因此可定義生命週期狀態集合：

$$
S_d \in
{
\text{ACTIVE},
\text{RETAINED},
\text{RECONSTRUCTABLE},
\text{DISPOSABLE},
\text{ORPHANED},
\text{EXPIRED},
\text{UNKNOWN}
}
$$

這並不要求作業系統理解所有應用程式內部邏輯。

只要求：

> **生成者告知系統。**

***

# 6. 生成資料的基本分類

本文提出以下最低限度分類。

## 6.1 使用者原始資料

例如：

* 原始碼；

* 文稿；

* 圖像原件；

* 影片原件；

* 使用者手動建立之專案；

* 使用者匯入之壓縮檔。

特徵：

$$
R(d)=0
$$

即不可由系統可靠重建。

原則：

> 禁止自動刪除。

***

## 6.2 不可重建資料

某些資料未必由使用者直接建立，但一旦遺失即無法恢復。

例如：

* 未同步之工作狀態；

* 唯一 checkpoint；

* 未提交之本機資料；

* 未備份之臨時錄音；

* 某些一次性擷取結果。

此類資料應被明確標為：

```text
NON_RECONSTRUCTABLE
```

***

## 6.3 可重建資料

例如：

* 索引；

* 某些 build artifacts；

* 可重新生成縮圖；

* 向量索引；

* 編譯中間結果。

特徵：

$$
R(d)=1
$$

但重建成本可能不同。

因此：

$$
C_r(d) \in [0,\infty)
$$

不能只標「可刪」，還應標示重建成本。

***

## 6.4 可重新下載資料

例如：

* 模型權重；

* 套件快取；

* 遊戲資源快取；

* 已知來源的安裝包。

此類資料不一定可由本機重建，但可從遠端重新取得。

因此可定義：

$$
D(d)=1
$$

其中 (D(d)) 表示可重新下載。

***

## 6.5 任務中間產物

例如：

* 轉檔中間檔；

* 編譯暫存；

* 解析快取；

* 臨時語料；

* AI 前處理產物。

其生命週期應與任務綁定：

$$
d \rightarrow T
$$

當：

$$
State(T)=Completed
$$

且不存在後續依賴時：

$$
State(d)\rightarrow Disposable
$$

***

## 6.6 效能快取

例如：

* Shader Cache；

* Browser Cache；

* GPU Cache；

* Code Cache；

* 推理快取。

其本質是：

> 用空間交換時間。

因此應明確顯示：

```text
刪除後果：效能暫時下降，資料可自動重建。
```

***

## 6.7 歷史回復資料

例如：

* Undo Snapshot；

* Autosave；

* Rollback；

* Recovery Copy。

此類資料不能簡單視為垃圾。

但應有期限：

$$
T_{expire}(d)
$$

例如：

* 保留 7 天；

* 保留 30 天；

* 保留最近 10 個版本。

***

## 6.8 診斷資料

例如：

* Crash Dump；

* Log；

* Trace；

* Debug Symbol Cache。

應預設有衰減與過期機制。

***

## 6.9 更新殘留

例如：

* 舊 installer；

* patch package；

* rollback artifact；

* OTA artifact。

應在系統穩定後轉為：

```text
DISPOSABLE_AFTER_STABILITY_WINDOW
```

***

## 6.10 孤兒資料

孤兒資料定義為：

$$
Parent(d)=\varnothing
$$

或：

$$
Reference(d)=0
$$

例如：

* 原專案已刪除；

* 原版本已卸載；

* 原任務已不存在；

* 原模型已替換；

* 原 workspace 已失效。

這類資料應成為高優先提醒對象。

***

# 7. 靜態檔案系統的本體論不足

現代檔案系統通常關心：

```text
檔名
大小
建立時間
修改時間
存取權限
擁有者
路徑
```

但在大量生成資料時代，更重要的是：

```text
生成者
來源
可重建性
可重新下載性
依賴關係
重建成本
任務狀態
保留期限
最後必要時間
刪除後果
```

因此本文提出：

> **現代檔案系統缺少生成關係。**

傳統檔案系統回答：

> 「這個檔案在哪裡？」

未來資料治理系統還必須回答：

> 「這個檔案為什麼存在？」

這是兩個完全不同的問題。

***

# 8. 從檔案本體轉向生成關係本體

設原始資料為 (S)，衍生產物為：

$$
S \rightarrow A_1 \rightarrow A_2 \rightarrow A_3 \rightarrow A_4
$$

其中：

* $A_1$ ：解析產物；

* $A_2$ ：編譯中間結果；

* $A_3$ ：最佳化結果；

* $A_4$ ：執行快取。

若每一層皆可由上游重建，則：

$$
A_i = f_i(A_{i-1})
$$

在理論上：

$$
I(A_i) < I(S)
$$

這裡的 (I) 不是檔案大小，而是「不可替代資訊價值」。

因此：

> 兩個同為 5 GB 的檔案，其保存價值可能完全不同。

例如：

* 5 GB 唯一研究資料；

* 5 GB 可重新下載模型；

* 5 GB Shader Cache；

* 5 GB 更新殘留。

檔案系統只看到：

$$
Size=5GB
$$

但使用者真正需要的是：

$$
Value(d), Rebuild(d), Risk(d)
$$

***

# 9. 可移除性不是二元問題

資料不應只有：

```text
可刪
不可刪
```

而應存在光譜。

定義可移除性：

$$
M(d)\in[0,1]
$$

其中：

* (M(d)=0)：不可移除；

* (M(d)=1)：完全可安全移除。

可進一步定義：

$$
M(d)=
F(R,D,P,C,T)
$$

其中：

* (R)：可重建性；

* (D)：可重新下載性；

* (P)：依賴程度；

* (C)：重建成本；

* (T)：時間敏感度。

例如：

### 使用者唯一原稿

$$
M(d)\approx0
$$

### Shader Cache

$$
M(d)\approx1
$$

### 可重新下載 20 GB 模型

$$
M(d)\approx0.8
$$

因為可移除，但重新下載成本高。

### 最近 24 小時 Autosave

$$
M(d)\approx0.2
$$

### 90 天前 Crash Dump

$$
M(d)\approx0.95
$$

***

# 10. 提案一：Application Data Lifecycle Manifest

本文提出：

# Application Data Lifecycle Manifest

# 應用資料生命週期清單

每個應用程式應聲明其資料類型。

例如：

```yaml
application: ExampleApp
version: 3.4

data_classes:
  - id: user_project
    category: USER_OWNED
    removable: false
    reconstructable: false

  - id: shader_cache
    category: PERFORMANCE_CACHE
    removable: true
    reconstructable: true
    rebuild_cost: low

  - id: local_model
    category: REDOWNLOADABLE
    removable: true
    redownloadable: true
    download_size: 4GB

  - id: old_update
    category: UPDATE_RESIDUE
    removable_after: 14d

  - id: crash_dump
    category: DIAGNOSTIC
    retention: 30d
```

***

# 11. 提案二：衍生資料回收區

本文區分：

## 傳統垃圾桶

表示：

> 使用者已決定刪除。

## 衍生資料回收區

表示：

> 應用程式已聲明該資料可被移除，但使用者尚未決定。

例如：

```text
衍生資料回收區

Chrome
- 一般快取：1.4 GB
- 本機模型：4.0 GB
- 離線網站資料：2.6 GB

NVIDIA
- Shader Cache：3.2 GB
- 更新殘留：5.3 GB

開發工具
- npm cache：3.2 GB
- uv cache：2.5 GB

[安全回收 7.8 GB]
[可重建資料 5.7 GB]
[可重新下載資料 4.0 GB]
[進階檢視]
```

***

# 12. 提案三：刪除後果必須被描述

現代系統常只問：

> 「確定要刪除嗎？」

這是極度低資訊量的警告。

更合理的介面應該是：

```text
刪除後果：

✓ 不會刪除使用者文件
✓ 不會影響登入狀態
✓ 不會影響作業系統
△ 下次啟動將重新生成約 2.8 GB 快取
△ 預估重建時間 3–12 分鐘

是否繼續？
```

這才是真正有意義的風險告知。

***

# 13. 提案四：任務完成後自動降級資料狀態

設任務 (T) 產生資料集合：

$$
D_T={d_1,d_2,\dots,d_n}
$$

當：

$$
State(T)=Completed
$$

系統應重新評估：

$$
State(d_i)
$$

若：

$$
Dependency(d_i)=0
$$

則：

$$
State(d_i)\rightarrow Disposable
$$

也就是：

> **事情做完了，就把檔案標示為可移除。**

這不是複雜的哲學要求，而是最基本的生命週期治理。

***

# 14. 提案五：未知資料本身也應被視為風險

若應用程式未聲明資料狀態：

```text
UNKNOWN
```

系統不應假裝它不存在。

反而應顯示：

```text
此應用程式有 8.2 GB 未聲明生命週期資料。
```

這可以形成新的軟體品質指標：

$$
G(A)=
\frac{
DeclaredData(A)
}{
GeneratedData(A)
}
$$

其中 (G(A)) 為應用程式資料治理率。

若：

$$
G(A)\rightarrow1
$$

表示應用程式對其生成資料有高透明度。

若：

$$
G(A)\rightarrow0
$$

則應用程式實際上把硬碟當成無責任垃圾場。

***

# 15. 為何遊戲盤與影片盤反而更乾淨？

這是一個極具諷刺性的現象。

許多使用者的遊戲碟可能是：

```text
F:\
├── SteamLibrary
├── Games
├── Emulator
└── Mods
```

影片碟可能是：

```text
D:\
├── Movies
├── Anime
├── Documentary
└── Projects
```

即使資料量巨大，使用者通常仍能理解：

* 這是什麼；

* 為什麼存在；

* 刪了會發生什麼；

* 是否可重新下載。

反而是專業工具、開發環境、瀏覽器與 AI 軟體：

```text
AppData\Local\xxx
ProgramData\xxx
.cache
.workspace
.models
.blobs
objects
packages
artifacts
snapshots
storage
CacheStorage
Code Cache
GPUCache
```

使用者無法判斷其意義。

因此產生一個諷刺：

> **資料越簡單，使用者越有控制權；系統越先進，資料生命週期反而越不透明。**

***

# 16. AI 時代將使問題急遽惡化

AI 應用可能生成：

* Embedding Cache；

* Vector Index；

* Local Model；

* Quantized Model；

* Checkpoint；

* Agent Trace；

* Browser State；

* Generated Preview；

* Multimodal Preprocessing；

* Temporary Corpus；

* RAG Index；

* Compiled Graph；

* Inference Cache；

* Tool Output；

* Session Snapshot。

其中許多資料：

* 可重建；

* 可重新下載；

* 有期限；

* 僅屬任務中間產物；

* 可能在任務完成後失去價值。

若仍沿用傳統檔案邏輯，使用者設備最終將變成：

> **資料考古遺址。**

***

# 17. Agent 時代的進一步問題

Agent 系統可能長期執行任務。

設 Agent (G) 在時間 (t) 生成資料：

$$
D_G(t)
$$

若生成速率：

$$
\frac{dD_G}{dt}>0
$$

而清理與生命週期治理速率：

$$
\frac{dC_G}{dt}\approx0
$$

則長期：

$$
D_G(t)\rightarrow\infty
$$

即使單次任務只留下少量資料，大量 Agent 任務仍會形成累積污染。

因此 Agent 應內建：

$$
Generate
\rightarrow
Declare
\rightarrow
Use
\rightarrow
Complete
\rightarrow
Downgrade
\rightarrow
Archive/Delete
$$

而不是只有：

$$
Generate
\rightarrow
Forget
$$

***

# 18. 應用程式責任原則

本文提出：

## 原則 1：生成即聲明

凡自動生成資料，應聲明其類型。

## 原則 2：完成即重評估

任務完成後，應重新評估衍生資料。

## 原則 3：可重建必標示

若資料可重建，應告知使用者。

## 原則 4：刪除後果透明

不得只顯示「確定刪除」。

## 原則 5：不可重建優先保護

唯一資料必須被區分。

## 原則 6：孤兒資料可見

來源失效之資料不得永久沉默存在。

## 原則 7：更新殘留有期限

更新完成後應進入保留窗口。

## 原則 8：未知即技術債

未聲明資料應視為資料治理缺陷。

***

# 19. 作業系統責任原則

作業系統也不能完全推給 App。

它至少應提供：

1. 統一生命週期 API；

2. 統一資料分類介面；

3. 可移除資料檢視；

4. 刪除後果說明；

5. 孤兒資料掃描；

6. 安全回收模式；

7. 空間壓力下的排序；

8. 依賴關係顯示。

例如：

```text
空間不足

建議回收：

A. 可安全重建資料：12.4 GB
B. 可重新下載資料：8.2 GB
C. 超期診斷資料：3.1 GB
D. 孤兒資料：6.8 GB
E. 未聲明資料：9.7 GB

不建議自動處理：
- 使用者原始資料
- 不可重建工作區
```

***

# 20. 一個簡化的形式模型

對任意資料 (d)，定義：

$$
\Phi(d)=
\langle
R_d,
D_d,
P_d,
C_d,
T_d,
U_d
\rangle
$$

其中：

* $R_d$ ：可重建性；

* $D_d$ ：可重新下載性；

* $P_d$ ：依賴強度；

* $C_d$ ：重建成本；

* $T_d$ ：時間敏感度；

* $U_d$ ：使用者唯一性。

定義移除分數：

$$
M(d)=
\alpha R_d
+
\beta D_d

\gamma P_d

\delta C_d

\epsilon T_d

\zeta U_d
$$

其中權重依系統策略調整。

當：

$$
M(d)\ge \theta
$$

則系統可將其列入：

```text
RECOMMENDED_FOR_CLEANUP
```

但不必自動刪除。

這保留了：

* 使用者控制權；

* 系統透明度；

* 風險可解釋性。

***

# 21. 與相對不可逆性之關係

現代軟體資料鏈具有高度非對稱性。

原始資料到衍生資料：

$$
S\rightarrow A
$$

通常容易。

但：

$$
A\rightarrow S
$$

可能困難、昂貴，甚至不可能。

因此不能把所有資料都視為等價檔案。

例如：

* 原始碼；

* 編譯後檔案；

* 中間表示；

* 快取；

* 日誌。

它們之間存在：

> 可生成性不對稱\
> 可逆性不對稱\
> 保存價值不對稱

因此資料生命週期管理實際上是在回答：

> **哪些資料是源，哪些資料是影？**

這也是傳統檔案系統最缺乏的資訊。

***

# 22. 使用者恐懼並非錯誤，而是系統失敗的訊號

當使用者面對 C 槽資料時不敢刪除，軟體工程常將其理解為：

> 使用者不懂電腦。

本文反對這種簡化。

若使用者無法知道：

* 資料來源；

* 刪除後果；

* 是否可重建；

* 是否屬系統依賴；

那麼「不刪」其實是理性策略。

也就是：

$$
Uncertainty\uparrow
\Rightarrow
DeletionRisk\uparrow
\Rightarrow
UserConservatism\uparrow
$$

因此使用者保守，不一定代表能力不足。

反而可能代表：

> **系統沒有提供足夠資訊。**

***

# 23. 設計倫理：誰製造資料，誰應解釋資料

本文提出一個最簡單的設計倫理：

> **應用程式製造資料，不應把理解資料的責任全部丟給使用者。**

若 App 可以：

* 自動生成；

* 自動更新；

* 自動快取；

* 自動下載模型；

* 自動建立工作區；

* 自動保存快照；

它也應該可以：

* 自動標記；

* 自動分類；

* 自動過期；

* 自動聲明；

* 自動提示。

因此問題不是：

> 做不做得到？

而是：

> 為什麼長期沒有被視為產品責任？

***

# 24. 更高層命題：從檔案治理轉向資訊生命週期治理

本文最終主張：

> **未來作業系統不應只管理檔案，而應管理資料之生成、依賴、可再生性與死亡。**

傳統系統：

$$
File = Bytes + Path
$$

未來系統：

$$
Data =
Bytes
+
Origin
+
Dependency
+
Reconstructability
+
Lifecycle
+
Risk
$$

這代表：

> 檔案不再只是存在物。\
> 檔案同時是生成鏈中的節點。

***

# 25. 結論

現代應用程式已進入大量生成資料時代。

但我們仍使用靜態檔案時代的管理思維。

今天真正的問題不是：

> 硬碟為什麼會滿？

而是：

> **為什麼明明是應用程式自己生成的資料，最後卻要使用者自己考古、猜測與承擔刪除風險？**

本文提出：

1. 生成者生命週期責任；

2. 可重建性聲明；

3. 可移除性標記；

4. 衍生資料回收區；

5. 任務完成後狀態降級；

6. 孤兒資料識別；

7. 刪除後果透明化；

8. 作業系統級生命週期 API。

最終命題可以濃縮為：

> **現代應用程式最大的資料管理缺陷之一，不是生成了太多資料，而是拒絕向使用者聲明生成資料的生命週期、可重建性與可移除性。**

再更直接一點：

> **應用程式製造資料，卻把理解資料的責任丟給使用者。**

而在 AI 與 Agent 時代，這個問題只會更嚴重。

若仍不改變，未來的個人電腦與工作站將不是智慧系統，而是：

> **由無數未知生成物堆積而成的資料考古遺址。**

***

# 附錄 A：建議狀態標準

```text
ACTIVE
仍在使用

RETAINED
保留中

RECONSTRUCTABLE
可重建

REDOWNLOADABLE
可重新下載

DISPOSABLE
可移除

ORPHANED
來源關係失效

EXPIRED
超過生命週期

NON_RECONSTRUCTABLE
不可重建

USER_OWNED
使用者原始資料

UNKNOWN
應用未聲明
```

***

# 附錄 B：最小生命週期宣告格式

```json
{
  "data_id": "cache-2026-07-08-001",
  "origin": "ExampleApp",
  "category": "PERFORMANCE_CACHE",
  "reconstructable": true,
  "redownloadable": false,
  "removable": true,
  "rebuild_cost": "low",
  "depends_on": [],
  "retention_days": 14,
  "state": "DISPOSABLE"
}
```

***

# 附錄 C：一句話版本

> **當代軟體已進入大量生成資料時代，但作業系統仍停留在靜態檔案時代；凡由應用程式生成之資料，生成者應負責聲明其生命週期、可重建性與可移除性，而不應將判斷成本與刪除風險轉嫁給使用者。**

***

# 附錄 D：特別聲明

本文並不主張所有快取、工作區、更新包或衍生資料都應被自動刪除，也不主張作業系統應越權替使用者做決策。

本文主張的是：

> **可見性、可解釋性、可分類性與可選擇性。**

真正的目標不是讓系統更積極地刪除，而是讓使用者終於知道：

> **什麼可以刪，為什麼可以刪，刪了會發生什麼。**