# 從「我不會」到「如何取得能力」
## Agent 時代的可實作性預設、工具邊界與能力重建

**版本：** v0.1  
**日期：** 2026-07-25  
**研究場域：** EveMissLab 實驗站  
**研究發起與核心命題：** Neo.K  
**協作整理：** EveMissLab AI  

---

## 摘要

生成式 AI 早期主要被理解為回答問題、生成文字或輔助搜尋的工具；然而，隨著 Agent、Skill、開源程式庫、程式執行環境與自動化工作流逐步整合，部分使用者的技術心智已出現明顯改變。當他們看見一項他人完成的工具、應用或工作方法時，第一個問題不再只是「我是否具備相同專業」，而逐漸轉為：「這項能力能否安裝、調用、拆解、修改、模仿、重新實作，並保存為可重複使用的能力？」

本文將此轉變稱為**可實作性預設的逆轉**。傳統情境下，個體通常預設某件事無法完成，除非自己已具備必要技術；Agent 時代則可能逐漸形成另一種預設：某項成果原則上值得先被拆解與嘗試，只有在辨識出資金、資料、物理條件、法規、責任或驗證能力等真正限制後，才判定其暫不可行。

本文並不主張專業知識已失去價值，也不主張 AI 能消除所有技術門檻。相反地，本文認為專業能力正在重新分工：部分執行知識可被 Skill、程式碼、模板與 Agent 工作流物件化；人類的重要性則更多轉向問題定義、約束設定、來源選擇、架構決策、結果驗證與責任承擔。這使「我會不會」逐漸轉化為「我能否取得並治理這項能力」，同時也可能產生新的認知與能力階級。

**關鍵詞：** Agent、Skill、GitHub、開源、能力取得、可實作性預設、技術教育、人機協作、認知階級

---

## 一、問題的出現：看到別人的成果後，人類先問什麼？

在傳統技術環境中，當個體看見一個陌生工具、網站、程式、研究流程或數位產品時，最自然的判斷通常是：

> 我會不會製作這個東西？

這個問題背後隱含了一條相對固定的能力取得路徑：

$$
\text{學習理論}
\rightarrow
\text{掌握工具}
\rightarrow
\text{反覆練習}
\rightarrow
\text{形成熟練}
\rightarrow
\text{完成產出}
$$

如果個體不會程式設計、不熟悉伺服器、不理解資料庫或沒有設計經驗，他往往會直接把某個成果歸入「我無法完成」的範圍。即使程式碼已經開源，安裝、依賴、錯誤排除、設定、部署與修改等最後一公里障礙，仍足以使開放的知識在實際上維持封閉。

Agent 的出現改變的並不只是產出速度，而是個體對「技術可接近性」的預設。

部分熟練使用者現在可能先問：

1. 是否已有現成 Skill？
2. 是否有 GitHub 開源專案？
3. Agent 能否協助安裝與排除錯誤？
4. 現有工具能否透過 API、外掛或腳本擴充？
5. 若不能安裝，能否依照功能規格重做一個版本？
6. 既有介面、文風、流程或架構能否被 Agent 學習？
7. 完成後能否封裝為自己的 Skill、模板或工作流？

此時，「不會」不再立即構成終點，而成為能力取得流程的起點。

---

## 二、可實作性預設的逆轉

本文把兩種心智模式區分如下。

### 2.1 傳統的不可行預設

$$
\neg K(u,x)
\Rightarrow
\neg F(u,x)
$$

其中：

- $K(u,x)$ 表示使用者 $u$ 已掌握完成任務 $x$ 的知識；
- $F(u,x)$ 表示使用者 $u$ 能完成任務 $x$ 。

這個模式近似於：

> 如果我不具備知識，我就不能完成。

它在過去具有相當高的現實合理性。因為知識、工具、實作與排錯通常集中在同一個人或同一個專業團隊內。

### 2.2 Agent 時代的能力取得預設

Agent 協作下，更合理的形式是：

$$
F(u,x)
=
f(
I_u,
A,
S,
O,
D,
V,
R
)
$$

其中：

- $I_u$ ：使用者的意圖定義與主動性；
- $A$ ：Agent 的推理、執行與工具能力；
- $S$ ：可取得的 Skill、程式碼、模板與規格；
- $O$ ：開源資源與外部知識；
- $D$ ：任務拆解與委任品質；
- $V$ ：驗證能力；
- $R$ ：現實資源與限制。

因此，「不知道如何親手完成」不再必然推出「無法完成」：

$$
\neg K_{\mathrm{full}}(u,x)
\nRightarrow
\neg F(u,x)
$$

使用者可能尚未掌握全部技術，但仍能透過 Agent、開源資源、測試工具與專業審查完成某種程度的成果。

本文將這種改變稱為：

> **可實作性預設的逆轉：先假定某項能力值得被取得與驗證，再依據真正限制判定可行性，而不是先依據個體既有技能宣布不可行。**

這不是「什麼都做得到」的樂觀主義，而是把不可行判斷從直覺提前否決，改為經過拆解後的工程判斷。

---

## 三、成果不再只是產品，而是能力圖譜

一個完整產品容易給人以不可分割的印象。使用者看見的是網站、軟體或服務整體，而不是其內部結構。

但 Agent 擅長將整體要求拆分為較小的子任務。產品因而可被重新描述為：

$$
P
=
F
+
D
+
I
+
W
+
E
+
O
+
G
$$

其中：

- $F$ ：功能模組；
- $D$ ：資料與資料結構；
- $I$ ：介面與互動；
- $W$ ：工作流；
- $E$ ：執行與部署環境；
- $O$ ：營運與維護；
- $G$ ：治理、法規與責任。

當一項成果被拆成這些部分，問題會從「我能不能做出整個產品」轉為：

- 哪些模組已有成熟套件？
- 哪些部分已有開源實作？
- 哪些可以透過 API 取得？
- 哪些可以由 Agent 根據規格生成？
- 哪些需要人類設計或專家確認？
- 哪些限制屬於技術問題？
- 哪些其實是資料、法規、資金與責任問題？

這種拆解會把大量「神祕的完整成果」轉化為一組可調查、可分工、可測試的問題。

因此，Agent 時代的重要能力並不是盲目相信 AI 能完成一切，而是能夠把一個看似完整的外部成果轉換成**能力依賴圖譜**。

可以把它表示為一個有向圖：

$$
G_x=(N_x,E_x)
$$

其中：

- $N_x$ 是任務 $x$ 所需的功能、知識、工具與資源節點；
- $E_x$ 是各節點之間的依賴關係。

當圖譜建立後，每個節點可以被標記為：

$$
\{\text{已掌握},\text{可安裝},\text{可調用},\text{可生成},\text{需學習},\text{需外包},\text{暫不可行}\}
$$

「他們能做，我為何不行」於是從情緒性的比較，轉變為可被驗證的能力工程問題。

---

## 四、GitHub 從程式碼倉庫轉向能力公共層

GitHub 長期以來已是全球重要的程式碼與協作基礎設施。但對大量非工程使用者而言，程式碼公開並不等於能力可用。

傳統開源的隱性障礙包括：

- 不知道應選擇哪個專案；
- 不理解授權條款；
- 不知道如何安裝依賴；
- 無法判斷專案是否仍被維護；
- 看不懂錯誤訊息；
- 不知道如何修改；
- 不清楚如何部署；
- 無法建立測試與安全檢查。

Agent 開始介入這些障礙：閱讀儲存庫、解釋架構、建立計畫、修改程式碼、執行測試、修正錯誤並產生提交。GitHub 的官方文件已把雲端 coding agent 描述為能夠研究儲存庫、建立實作計畫、修改分支、執行測試並建立拉取請求的非同步工作者。[1] GitHub 也開始支援多種第三方 coding agents 在同一平台接受任務並回交可審查的變更。[2]

這表示 GitHub 的功能正發生一種結構性轉換：

$$
\text{Source Availability}
\rightarrow
\text{Agent Readability}
\rightarrow
\text{Executable Adaptation}
\rightarrow
\text{Capability Acquisition}
$$

也就是：

1. 原始碼公開；
2. Agent 能讀取與解釋；
3. Agent 能安裝、修改與測試；
4. 使用者能把它轉化為自己的可用能力。

GitHub 2025 年度資料顯示，平台已有超過 1.8 億名開發者，2025 年新增超過 3,600 萬名使用者，且 AI 工具的普及與帳號成長、儲存庫活動增加同時發生。[3] 這項資料不能單獨證明 Agent 已使所有人都成為開發者，但至少顯示「程式碼平台＋AI 輔助」正在快速擴大參與者與產出活動。

因此，GitHub 不應再只被理解為專業工程師的程式碼倉庫。它正在逐漸成為一個可由 Agent 搜尋、閱讀、重構與搬運的**全球能力公共層**。

---

## 五、Skill：把工作方法物件化

Agent Skill 的重要性不只在於縮短提示詞。

目前的開放格式通常以一個包含 `SKILL.md` 的資料夾為核心，並可附帶腳本、參考文件、模板與其他資源。Agent Skills 官方說明將其描述為一種輕量、開放且可攜的能力擴充格式，用來封裝專門知識與工作流程。[4] Claude Code 的官方文件也把 Skill 定義為可建立、管理與分享的能力單元，並指出其可在符合開放標準的多種工具之間使用。[5]

本文將一個 Skill 形式化為：

$$
S=(K,P,T,C,V,M)
$$

其中：

- $K$ ：完成任務所需的領域知識；
- $P$ ：程序與步驟；
- $T$ ：可調用工具與腳本；
- $C$ ：限制、權限與邊界；
- $V$ ：驗證與完成判準；
- $M$ ：模板、參考資料與可重用資產。

Skill 的意義在於：原本散落於個人經驗、教學文件、檢查表和程式碼中的工作方法，可以被封裝為版本化、可調用、可修改的能力物件。

它使能力取得路徑從：

$$
\text{先完整理解}
\rightarrow
\text{再嘗試使用}
$$

部分轉變為：

$$
\text{先調用}
\rightarrow
\text{觀察結果}
\rightarrow
\text{理解結構}
\rightarrow
\text{修改程序}
\rightarrow
\text{重新封裝}
$$

這不代表理解變得不重要，而是理解可以由「所有行動之前的資格門檻」，轉變為「在使用、失敗與修改過程中逐步深化的能力」。

此外，像 `AGENTS.md` 這類開放格式，開始讓專案以可預測的位置向不同 coding agents 提供安裝方式、測試命令、程式風格與專案慣例；其官方網站稱已有超過六萬個開源專案採用此格式。[6] 這代表開源專案不只開始對人類提供 README，也開始主動建構「可供 Agent 進入與工作的說明層」。

換句話說，開源正在從：

> 把程式碼交給其他人。

進一步轉向：

> 把如何在這個系統中工作的方法交給其他 Agent 與人類。

---

## 六、風格能否被 Agent 學習？

除了功能與程序之外，Agent 也使「風格」開始部分物件化。

這裡的風格不只指文字語氣，還包括：

- 文件結構；
- 命名規則；
- 程式碼慣例；
- 介面配置；
- 視覺元件選擇；
- 錯誤處理方式；
- 論證節奏；
- 研究文件格式；
- 專案分支與提交規則；
- 團隊對完成品質的判斷。

若一個風格能被表示為範例、規則、模板、測試與評分條件，Agent 便可能在一定程度上學習並重現它。

可以將可學習風格表示為：

$$
L_{\mathrm{style}}
=
E+R+T+J
$$

其中：

- $E$ ：範例；
- $R$ ：明示規則；
- $T$ ：模板與結構；
- $J$ ：品質判斷與反饋。

但本文必須區分兩種不同的「風格」。

第一種是**可觀察與可規則化的中層風格**，例如版面、用詞、架構、命名和流程。這類風格較容易被 Agent 學習。

第二種是**問題選擇與價值判斷的深層風格**，例如：

- 為什麼此刻選擇這個問題？
- 哪個異常值得繼續研究？
- 哪個正確答案其實沒有價值？
- 何時應當放棄既有架構？
- 哪個尚未被證明的方向值得投入？

這些深層判斷往往依賴長期經驗、價值體系、責任感與情境理解，不能因為 Agent 能模仿表面產出，就被宣稱已完整複製。

因此，更準確的命題是：

> Agent 可以使大量工作風格成為可記錄、可傳授與可重用的技術資產，但不能因此推論創造者的整體判斷結構已被完整複製。

---

## 七、從工具使用者到工具重建者

傳統軟體教育通常訓練使用者在既有介面內操作。軟體有什麼功能，使用者便完成什麼工作；軟體沒有功能，使用者只能等待更新、購買其他產品或放棄需求。

Agent 協作者則可能形成不同的工具觀：

> 工具邊界只是現有實作的邊界，不必然是任務本身的邊界。

當現有工具缺少功能時，他可能繼續嘗試：

1. 尋找外掛；
2. 尋找替代軟體；
3. 連接 API；
4. 編寫自動化腳本；
5. 修改開源專案；
6. 讓 Agent 根據需求建立原型；
7. 把新功能封裝成可重用 Skill。

因此可以區分五個層級：

### 第一層：工具接受者

只能使用軟體既有功能。

### 第二層：工具選擇者

能在多種產品中選擇較合適者。

### 第三層：工具連接者

能以 API、外掛、自動化與資料交換組合工具。

### 第四層：工具重建者

能讓 Agent 依規格修改或重新製作工具。

### 第五層：能力制度建構者

能把完成方式保存為 Skill、規格、測試、模板與可重複工作流，使其他人或 Agent 再次使用。

這種分層顯示，真正的能力差距已不再只是「誰會使用更多軟體」，而逐漸轉為「誰能跨越工具邊界並建立新能力」。

---

## 八、「他們能做，我為何不行」的工程化

這句話在過去常被視為勵志語言，甚至容易滑向低估專業難度的自我鼓舞。

在 Agent 時代，它可以被轉化為一套相對嚴格的分析程序。

### 8.1 第一步：成果辨識

先確認他人究竟完成了什麼，不把宣傳語言等同於實際能力。

### 8.2 第二步：功能拆解

建立功能、資料、介面、工作流、部署、維護與治理清單。

### 8.3 第三步：能力來源分類

對每個節點標記：

- 自己已具備；
- Agent 可協助；
- 有現成 Skill；
- 有開源專案；
- 有 API 或商業服務；
- 需要學習；
- 需要專家；
- 需要資本或實體資源。

### 8.4 第四步：最小原型

不直接複製完整產品，而先驗證最關鍵功能。

### 8.5 第五步：建立完成判準

要求測試、樣例、錯誤紀錄、版本差異或外部審查，避免把「生成了一些內容」誤認為「完成了產品」。

### 8.6 第六步：確認真正限制

真正不可跨越或暫不可跨越的限制可能包括：

- 專有資料；
- 高額算力；
- 硬體製造；
- 法規許可；
- 安全責任；
- 專利與授權；
- 通路與市場；
- 長期維護；
- 高風險專業驗證。

完成上述程序後，「我為何不行」才不再只是自信，而成為一個可以被證偽的工程命題。

---

## 九、能力取得不等於專業消失

Agent 能降低執行門檻，但不會自動消除專業差距。

原因在於，專業知識至少有四種功能：

1. **生成能力：** 知道如何完成；
2. **判斷能力：** 知道哪些方案合理；
3. **診斷能力：** 知道錯誤發生在哪裡；
4. **責任能力：** 知道何時不能部署或必須停止。

Agent 最容易替代或放大的通常是第一項中的部分執行步驟。越接近高風險、模糊情境與不可逆後果，後三項的重要性越高。

因此，能力取得的實際效果更適合表示為乘法：

$$
C_{\mathrm{effective}}
=
A_{\mathrm{agent}}
\times
I_{\mathrm{human}}
\times
V_{\mathrm{verification}}
\times
R_{\mathrm{resource}}
\times
G_{\mathrm{governance}}
$$

其中任一項接近零，整體有效能力都會大幅下降。

例如：

- Agent 很強，但使用者無法清楚描述需求；
- 原型可以生成，但沒有測試；
- 功能可行，但資料來源非法；
- 程式可以運作，但沒有人能承擔安全責任；
- Skill 可安裝，但已過時或遭污染。

所以，AI 並不是把能力免費交給所有人，而是把大量取得成本從「多年預先訓練」轉移到「問題形成、資源搜尋、持續修正、驗證與治理」。

---

## 十、主動性將成為新的放大器

Agent 時代最容易被忽略的一點，是 AI 可能同時降低技術門檻並放大主動性差距。

對缺少主動性的使用者而言，AI 主要仍是：

- 搜尋摘要；
- 文字改寫；
- 問答工具；
- 娛樂內容生成器。

對願意持續尋找方法的使用者而言，AI 則可能成為：

- 技術解說者；
- 安裝助手；
- 除錯者；
- 程式實作者；
- 研究協作者；
- 多工具編排者；
- 文件與制度封裝者。

由此形成正回饋：

$$
\text{嘗試}
\rightarrow
\text{獲得小成果}
\rightarrow
\text{提高可行性感}
\rightarrow
\text{委任更複雜任務}
\rightarrow
\text{形成更多可重用能力}
$$

也可能形成負回饋：

$$
\text{一次失敗}
\rightarrow
\text{判定 AI 無用}
\rightarrow
\text{只進行低價值使用}
\rightarrow
\text{持續得到普通結果}
\rightarrow
\text{再次確認 AI 無用}
$$

OpenAI 2026 年公布的 Agent 使用研究指出，Agent 正使知識工作的基本單位從短暫互動轉向可委任的長程任務；在其觀察中，能力提高與低摩擦取得會讓使用者逐步委任更長、更複雜且跨職能的工作。[7] 這項研究主要反映前沿使用者，不能直接代表所有人口，但它支持一項重要推論：使用者並非只因模型升級而自動獲得更多能力，還需要逐步形成「哪些事情值得交給 Agent」的經驗。

---

## 十一、教育順序可能發生反轉

傳統教育常採用：

$$
\text{先學完整理論}
\rightarrow
\text{通過測驗}
\rightarrow
\text{最後實作}
$$

Agent 時代可能增加另一條路徑：

$$
\text{先提出想完成的任務}
\rightarrow
\text{與 Agent 建立原型}
\rightarrow
\text{在失敗處學習}
\rightarrow
\text{補足所需理論}
\rightarrow
\text{修改並驗證}
$$

這並不意味基礎教育應被取消，而是學習可能由「內容順序」轉向「能力取得循環」。

一個可能的循環是：

$$
L_{n+1}
=
\mathcal{R}
(
L_n,
T_n,
E_n,
F_n
)
$$

其中：

- $L_n$ ：第 $n$ 輪已掌握的知識；
- $T_n$ ：當輪任務；
- $E_n$ ：執行與錯誤；
- $F_n$ ：Agent、人類或測試提供的反饋；
- $\mathcal{R}$ ：反思與修正過程。

在這種模式中，Skill 不是替代學習，而是可執行教材；GitHub 專案不是只有程式碼，而是可被拆解的案例；Agent 則是把問題、文件、程式與實驗連接起來的學習介面。

GitHub 所介紹的規格驅動開發也反映類似趨勢：不是讓 Agent 直接產生一段看似可用的程式，而是先建立可持續修改的規格，並讓規格成為生成、測試與驗證的共同來源。[8] 這使「會使用 Agent」逐漸從提示技巧轉向需求表達、規格形成與驗證能力。

---

## 十二、可檢驗的研究假說

本文屬於概念性論文，但仍可提出可被實驗檢驗的假說。

### 假說一：可實作性預設與 Agent 經驗相關

較熟悉 Agent 的使用者，在遇到陌生數位產品時，較可能先進行拆解、搜尋與原型驗證，而不是直接判定自己不會。

### 假說二：Skill 會降低首次完成成本

對具有明確步驟與可測試結果的任務，使用適當 Skill 的受試者，其首次完成時間與程序遺漏率會低於只使用一般聊天指令者。

### 假說三：先使用再解釋可提高短期完成率

在初學任務中，先使用 Skill 完成範例、再由 Agent 解釋原理的組別，短期完成率可能高於先接受完整理論教學的組別。

### 假說四：驗證能力決定能力取得上限

在 Agent 能力相同的條件下，擁有測試、查證與錯誤診斷能力者，能完成更高風險與更複雜的任務。

### 假說五：工具邊界觀可預測創造行為

把軟體功能視為可修改者，比把軟體視為封閉成品者，更可能建立外掛、工作流、腳本或新型應用。

---

## 十三、建議實驗設計

### 實驗 A：工具邊界反應測試

向受試者提出一個現有軟體缺少的功能，記錄其第一與第二反應：

- 放棄；
- 搜尋其他產品；
- 尋找外掛；
- 搜尋 GitHub；
- 讓 AI 編寫腳本；
- 讓 Agent 建立原型；
- 重新定義需求。

比較不同 Agent 使用經驗群體的反應分布。

### 實驗 B：同模型能力取得差異

提供所有受試者相同模型、相同時間與相同需求，觀察其能否：

- 建立規格；
- 拆分任務；
- 選擇外部資源；
- 產生原型；
- 建立測試；
- 記錄失敗；
- 封裝可重用結果。

### 實驗 C：Skill 與純提示比較

比較三組：

1. 無 Agent；
2. 一般 Agent 對話；
3. 使用完整 Skill 的 Agent。

測量完成時間、錯誤率、可重複性與使用者理解程度。

### 實驗 D：風格學習邊界

提供同一創作者的一組範例、規則與模板，要求 Agent 重現風格；再加入需要新情境判斷的任務，以區分表面風格模仿與深層問題選擇能力。

---

## 十四、限制與反例

本文的主張至少有六項限制。

### 14.1 原型不等於產品

Agent 能快速生成原型，但安全、維護、相容性、效能、法規與營運仍可能需要長期工程。

### 14.2 開源不等於免費

開源專案仍可能需要算力、雲端服務、維護人力、授權審查與部署成本。

### 14.3 可生成不等於可驗證

若使用者無法判斷成果是否正確，生成能力可能只會增加錯誤產出的規模。

### 14.4 相似不等於合法

Agent 能重現功能或風格，不代表可以違反著作權、商標、專利、授權或不正當競爭規範。

### 14.5 技術可行不等於社會可行

醫療、金融、公共安全、教育與治理系統不應只以「能不能做出來」決定是否部署。

### 14.6 能力取得可能擴大不平等

願意學習、具備驗證能力、能取得高階模型與運算資源的人，可能比其他人更快累積可重用能力。Agent 降低單一任務門檻，卻可能提高長期能力累積的差距。

---

## 十五、結論

Agent、Skill 與開源生態正在改變人類面對技術成果時的第一個問題。

過去，人們傾向先問：

> 我會不會？

現在，一部分使用者開始問：

> 這項能力要如何被取得、安裝、拆解、重建、驗證與保存？

這是一項比「AI 幫助寫程式」更深的改變。它表示個體不再必須先完整擁有一項專業，才能嘗試進入該專業的產出流程；他可以透過 Agent 調動工具、程式碼、文件與外部知識，先建立一個可驗證的能力組合。

但這並不意味專業消失。專業的重要性正從部分重複執行，轉移到問題形成、架構選擇、異常診斷、驗證、治理與責任。真正的新能力不是讓 AI 替人完成所有事情，而是：

$$
\text{意圖}
\rightarrow
\text{能力圖譜}
\rightarrow
\text{資源取得}
\rightarrow
\text{Agent 執行}
\rightarrow
\text{驗證}
\rightarrow
\text{能力保存}
$$

「他們能做，我為何不行」因而不再只是一句自我激勵。它開始可以被轉化為一套技術調查：

- 他們做了什麼？
- 需要哪些能力？
- 哪些能力已經開源？
- 哪些可由 Skill 搬運？
- 哪些可由 Agent 重建？
- 哪些需要人類學習？
- 哪些必須由專家負責？
- 真正不可跨越的限制究竟在哪裡？

當一個人習慣這樣思考，他就很難再只是既有工具的消費者。他開始把技術世界看成可拆解、可組合、可學習與可重建的能力空間。

這正是 Agent 時代「可實作性預設」的核心：

> **不是預設一切都能做到，而是不再因為自己尚未學會，就提前宣布事情做不到。**

---

## 參考資料

[1] GitHub Docs. “About GitHub Copilot cloud agent.”  
https://docs.github.com/en/copilot/concepts/agents/cloud-agent/about-cloud-agent

[2] GitHub Docs. “About third-party coding agents.”  
https://docs.github.com/en/copilot/concepts/agents/about-third-party-coding-agents

[3] GitHub. “Octoverse 2025: A new developer joins GitHub every second as AI leads TypeScript to #1.” Updated 2026-02-28.  
https://github.blog/news-insights/octoverse/octoverse-a-new-developer-joins-github-every-second-as-ai-leads-typescript-to-1/

[4] Agent Skills. “Agent Skills Overview.”  
https://agentskills.io/home

[5] Anthropic. “Extend Claude with skills.” Claude Code Documentation.  
https://code.claude.com/docs/en/skills

[6] AGENTS.md. “A simple, open format for guiding coding agents.”  
https://agents.md/

[7] OpenAI. “How agents are transforming work.” 2026-06-25.  
https://openai.com/index/how-agents-are-transforming-work/

[8] GitHub. “Spec-driven development with AI: Get started with a new open source toolkit.” 2025-09-02.  
https://github.blog/ai-and-ml/generative-ai/spec-driven-development-with-ai-get-started-with-a-new-open-source-toolkit/

---

## 後續研究接口

本文為系列第一篇。後續可依序延伸：

1. 《能力取得革命：Skill、GitHub 與 Agent 如何重構學習》
2. 《風險分級審閱：當人類不再逐字閱讀 AI 產出》
3. 《人類對 AI 的耐心分化：從閱讀耐心到委任耐心》
4. 《從幻覺爭論到可靠性工程：前沿 AI 風險敘事的轉移》
5. 《AI 認知生產階級：同一模型下的不平等擴張》
6. 《AI 時代的能力、耐心與認知階級：從幻覺下降到智能生產分層》