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

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

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

摘要

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

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

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

本文提出「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 來源可信性的多維模型

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

來源類型

專案的主要起源，例如：

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

上游保留程度

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

本地貢獻程度

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

判定信心

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

因此不應只輸出：

原創度：72%

而應輸出：

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

6. 原創度的認識論限制

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

至少存在：

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

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

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

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

而不是絕對證明。

較可信的公開表述是：

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

而不是：

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

7. 生命週期治理

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

建議將生命週期分為：

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. 公開展示與內部判定應分離

內部系統可以保存：

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

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

例如：

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} }

AI原生多專案治理與來源可信性_公開論文_v0.1