# AI 原生多專案治理與來源可信性

## 從單一倉庫管理走向軟體資產組合治理

**作者：** Neo.K  
**協作撰寫：** GPT-5.6 Thinking  
**機構：** 一言諾科技有限公司（EVEMISS Technology Co., Ltd.）／EveMissLab  
**版本：** v0.1  
**日期：** 2026 年 7 月 23 日  
**文件性質：** 公開研究論文／概念架構

---

## 摘要

軟體開發正在由「少量專案、長週期維護」轉向「大量專案、快速生成與持續演化」。在 AI Agent、程式生成、研究自動化與多產品營運逐漸普及後，一名個人開發者、一間新創公司或一個研究團隊，在短時間內擁有數十至數百個程式專案，將不再是例外。

然而，現有程式碼託管平台的核心管理單位仍是單一倉庫。使用者可以逐一調整倉庫描述、權限、標籤、分支、文件與發布流程，卻缺乏一個能理解「整個軟體資產組合」的治理層。當專案數量持續增加，真正的瓶頸不再只是如何產生更多程式碼，而是如何回答以下問題：

1. 這些專案分別是什麼？
2. 哪些仍在活躍維護？
3. 哪些已被取代、封存或僅供參考？
4. 哪些屬於原創，哪些源自分支、模板、鏡像或衍生修改？
5. 哪些操作可由 AI Agent 自動完成，哪些必須經過人類審批？
6. 如何維持授權、來源、責任與變更紀錄的可信性？

本文提出「AI 原生多專案治理」概念，主張未來的軟體管理單位應由單一倉庫提升為軟體資產組合。系統不只管理程式碼，也管理專案身分、生命週期、來源血緣、原創貢獻、授權狀態、風險等級與代理權限。

本文進一步提出「來源可信性」不應被簡化成「是否為 Fork」或單一原創度百分比，而應拆解為來源類型、上游關係、本地貢獻、轉化深度與判定信心。透過此架構，AI Agent 可以協助人類管理大量專案，但其能力必須始終受限於明確的治理政策、權限邊界與可稽核流程。

---

# 1. 從程式生成瓶頸到治理瓶頸

過去的軟體工程主要瓶頸是：

$$
\text{設計成本}
+
\text{程式撰寫成本}
+
\text{測試成本}.
$$

在 AI Agent 與生成式程式開發出現後，程式產生速度快速提升。原本需要數週或數月完成的原型，可能在數小時或數日內建立。

因此，新的總成本逐漸轉變為：

$$
\text{理解成本}
+
\text{維護成本}
+
\text{治理成本}
+
\text{責任成本}.
$$

專案越容易建立，專案數量就越容易膨脹。當數量超過個人注意力與人工管理能力時，開發者可能逐漸失去對自身軟體資產的完整認識。

這形成一種新型態的軟體債務：

> 不是不知道如何修改某一段程式，而是不知道自己究竟擁有哪些專案、它們彼此有何關係，以及哪些仍值得維護。

本文將此稱為：

$$
\boxed{\text{軟體資產認知債務}}
$$

---

# 2. 單一倉庫模型的限制

現有平台通常提供：

- 倉庫權限；
- 分支保護；
- Issue 與 Pull Request；
- 專案文件；
- Actions 與部署；
- 標籤、Topics 與描述；
- 組織與團隊。

這些功能本身足夠強大，但它們主要圍繞單一倉庫運作。

當使用者擁有上百個專案時，問題不再是：

> 如何設定這個倉庫？

而是：

> 哪些倉庫應該套用同一套規則？  
> 哪些屬於同一個產品家族？  
> 哪些是研究原型，哪些是正式產品？  
> 哪些只應唯讀保存？  
> 哪些專案之間存在來源或衍生關係？

這表示未來需要一層高於倉庫的平台：

$$
\boxed{
\text{Repository Management}
\rightarrow
\text{Portfolio Governance}
}
$$

---

# 3. 軟體資產組合治理

本文將多專案治理定義為：

> 對一組跨倉庫、跨組織、跨公司與跨代理的軟體資產，進行身分辨識、分類、生命週期管理、來源追蹤、權限控制、變更審批與責任稽核。

一個完整的軟體資產組合，至少包含：

- 原創產品；
- 研究工具；
- 實驗原型；
- 網站；
- 內部服務；
- 外部 Fork；
- 鏡像；
- 模板衍生專案；
- 插件或擴充；
- 已封存版本；
- 上游參考；
- 授權受限資產。

因此，治理系統不能只知道「倉庫名稱」，還要知道：

$$
R=(I,C,L,P,O,G),
$$

其中：

- $I$ ：專案身分；
- $C$ ：分類與產品關係；
- $L$ ：生命週期；
- $P$ ：來源與血緣；
- $O$ ：所有權與責任；
- $G$ ：治理與權限政策。

---

# 4. AI Agent 的角色

AI Agent 適合處理大量、重複且需要語義理解的工作，例如：

- 閱讀專案文件；
- 分析目錄與程式結構；
- 辨識倉庫用途；
- 建議分類；
- 比較專案相似度；
- 檢查文件完整性；
- 建議描述與標籤；
- 產生整理計畫；
- 建立文件修改提案。

但 AI Agent 不應因為可以執行操作，就被視為有權執行操作。

本文提出：

$$
\boxed{
\text{Agent Capability}
\neq
\text{Agent Authorization}
}
$$

更完整地說：

$$
\boxed{
\text{Agent Capability}
\subseteq
\text{Policy Authorization}
\subseteq
\text{Platform Permission}
}
$$

AI Agent 能做什麼，是技術能力問題；AI Agent 被允許做什麼，是治理問題。

---

# 5. 來源可信性

## 5.1 Fork 不等於全部來源關係

平台所標記的 Fork 只是來源關係的一種。

一個專案可能是：

- 正式 Fork；
- 手動複製後重新建立；
- 從上游匯入；
- 鏡像；
- 模板產生；
- 插件；
- 大量改寫的衍生作品；
- 多來源整合；
- 完全原創但使用大量開源依賴。

因此：

$$
\boxed{
\text{Not Marked as Fork}
\not\Rightarrow
\text{Original}
}
$$

同樣地：

$$
\boxed{
\text{Uses Open-Source Dependencies}
\not\Rightarrow
\text{Derivative Work}
}
$$

## 5.2 來源可信性的多維模型

本文主張來源可信性應至少分成四個維度。

### 來源類型

專案的主要起源，例如：

- 原創；
- 正式分支；
- 脫離分支；
- 鏡像；
- 模板衍生；
- 插件；
- 衍生專案；
- 多來源組合；
- 未知。

### 上游保留程度

目前專案中仍保留多少上游內容。

### 本地貢獻程度

目前專案中有多少架構、功能、測試、文件、介面或研究內容由本地團隊新增。

### 判定信心

系統對來源判定有多大把握。

因此不應只輸出：

```text
原創度：72%
```

而應輸出：

```text
來源類型：衍生專案
本地貢獻：主要
上游保留：中等
轉化深度：架構級
判定信心：高
```

---

# 6. 原創度的認識論限制

「原創」並不是單一、完全可量化的自然屬性。

至少存在：

- 程式碼原創；
- 架構原創；
- 介面原創；
- 演算法原創；
- 文件原創；
- 研究命題原創；
- 商業整合原創；
- 資料與內容原創。

一個專案可以保留大量上游底層程式，卻加入完全不同的產品架構；也可能幾乎全部重新撰寫，但僅重現既有概念。

因此，原創度判定只能是：

$$
\boxed{
\text{多證據推定}
}
$$

而不是絕對證明。

較可信的公開表述是：

- 未偵測到直接上游；
- 原創專案，使用開源依賴；
- 修改型分支；
- 研究衍生專案；
- 鏡像；
- 插件或擴充；
- 來源尚待確認。

而不是：

- 百分之百原創；
- 完全無任何外部影響；
- 絕對不存在相似來源。

---

# 7. 生命週期治理

當專案數量增加，所有專案都保持「活躍」是不現實的。

建議將生命週期分為：

```text
IDEA
EXPERIMENTAL
ACTIVE
MAINTENANCE
SUPERSEDED
ARCHIVED
REFERENCE
UNKNOWN
```

生命週期治理的核心不是刪除舊專案，而是讓每個專案有明確位置。

例如：

- `ACTIVE`：主要產品或研究；
- `MAINTENANCE`：穩定但低頻更新；
- `SUPERSEDED`：已由新專案取代；
- `ARCHIVED`：不再修改；
- `REFERENCE`：外部參考、鏡像或研究材料；
- `UNKNOWN`：尚未完成辨識。

---

# 8. 風險分級與人類審批

不同操作不能具有相同權限。

可以區分：

## 低風險

- 讀取；
- 分類；
- 建議描述；
- 建議標籤；
- 建立分析報告。

## 中風險

- 修改 README；
- 建立文件分支；
- 建立 Pull Request；
- 更新非核心 metadata。

## 高風險

- 修改程式；
- 修改 CI/CD；
- 修改部署；
- 合併 Pull Request；
- 更改存取權限。

## 關鍵風險

- 刪除倉庫；
- 改變可見性；
- 修改密鑰；
- 移轉所有權；
- 解除保護規則。

因此，AI 原生治理系統應採用：

$$
\boxed{
\text{Inspect}
\rightarrow
\text{Plan}
\rightarrow
\text{Preview}
\rightarrow
\text{Approve}
\rightarrow
\text{Apply}
}
$$

而不是：

$$
\text{Natural Language}
\rightarrow
\text{Immediate Execution}.
$$

---

# 9. 多公司與多組織治理

未來一個使用者可能同時管理：

- 個人專案；
- 公司專案；
- 研究組織；
- 公開社群；
- 私有客戶專案；
- 合作專案。

因此治理範圍必須是階層式的：

$$
\text{User}
\rightarrow
\text{Company}
\rightarrow
\text{Organization}
\rightarrow
\text{Repository}
\rightarrow
\text{Branch／Resource}.
$$

每一層都可能有不同：

- 所有者；
- 授權者；
- Agent；
- 資料邊界；
- 風險政策；
- 公開規則；
- 審批流程。

這使得「多租戶」不只是商業 SaaS 的需求，也是個人管理多身份、多組織與多代理時的基本需求。

---

# 10. 公開展示與內部判定應分離

內部系統可以保存：

- 相似度；
- 候選上游；
- 原創貢獻區間；
- 風險；
- 授權警告；
- 判定信心；
- 人工覆核紀錄。

但公開頁面只需顯示清楚且不誤導的分類。

例如：

```text
Original Research Software
Modified Fork
Community Localization Derivative
Plugin / Extension
Upstream Mirror
Archived Reference
```

這避免把尚未完全確定的機器判定，直接轉化成法律或聲譽主張。

---

# 11. AI 原生軟體治理的市場需求

此類系統適用於：

- 擁有大量 Side Projects 的個人開發者；
- AI 高產量程式創作者；
- 多產品新創公司；
- 研究實驗室；
- 開源基金會；
- 多品牌企業；
- 擁有大量 Legacy Repositories 的大型公司；
- 需要同時管理多個 Agent 的團隊。

未來的競爭優勢不只來自「誰能生成更多專案」，也來自：

> 誰能持續理解、維護、分類、治理與淘汰自己所生成的專案。

---

# 12. 核心命題

## 命題一：生成能力提高必然增加治理壓力

當專案生成成本下降時，專案數量傾向上升；若治理能力不變，軟體資產認知債務將持續增加。

## 命題二：倉庫不是未來最高治理單位

單一倉庫管理無法充分表達產品家族、公司結構、來源關係與跨專案政策。

## 命題三：原創度必須多維化

原創度不能由 Fork 標記或單一百分比充分描述。

## 命題四：代理能力必須低於治理授權

AI Agent 的工具能力不能自動轉化為操作權。

## 命題五：公開展示必須低於內部判定強度

內部系統可保留複雜推定，公開資訊則應使用保守、可解釋的分類。

---

# 13. 結論

軟體工程正在進入一個新階段。

過去，人類需要解決：

> 如何完成一個程式專案？

未來，人類與 AI Agent 還必須解決：

> 如何治理數百個由人類、AI、上游社群與多公司共同形成的軟體資產？

因此，需要從：

$$
\text{Code Hosting}
$$

提升到：

$$
\boxed{
\text{AI-Native Software Portfolio Governance}
}
$$

這個治理層必須同時處理：

- 專案身分；
- 分類；
- 生命週期；
- 來源血緣；
- 原創貢獻；
- 授權；
- 權限；
- 審批；
- 稽核；
- 公開展示。

最終，AI Agent 不只是替人類操作程式碼平台，而是成為軟體資產組合的認知助手與治理執行者。

但其基本邊界必須始終成立：

$$
\boxed{
\text{Agent Capability}
\subseteq
\text{Policy Authorization}
\subseteq
\text{Human Governance}
}
$$