title: "從程式碼生成到工程軌跡保持：前沿 AI 跨越中型軟體門檻的觀察命題" subtitle: "關於 AI 程式設計品質、架構優雅性與軟體工程評價單位轉移的觀察論文" author: "Neo.K" organization: "EVEMISSLAB／一言諾科技有限公司" date: "2026-07-16" version: "v0.1" status: "觀察論文／命題草案" language: "zh-TW"

從程式碼生成到工程軌跡保持

前沿 AI 跨越中型軟體門檻的觀察命題

作者： Neo.K
日期： 2026 年 7 月 16 日
版本： v0.1
文件性質： 觀察論文／可反駁命題草案

摘要

關於 AI 程式設計的公共討論，長期集中在一個逐漸過時的問題上：AI 寫出的程式碼是否「值得看」、是否具有「AI 味」、是否比人類程式員更容易出錯。然而，這類爭論通常沿用的是早期程式碼生成模型的經驗：模型能寫出局部函數，卻難以保持跨檔案、跨模組、跨輪次與跨測試的一致性。

到 2026 年，前沿程式設計模型與 Agent 系統的能力邊界已明顯改變。OpenAI 將 GPT-5.6 Sol 定位為能處理程式設計、長程規劃與工具協調的旗艦模型；Anthropic 則將 Claude Fable 5 定位為可處理大型遷移、複雜實作與多日自主工作階段的程式設計模型。[1][2] 這些官方定位本身不能證明模型已可靠完成所有大型工程，但它們顯示模型公司的能力評價單位，已從單一程式碼片段轉向長軌跡、工具化、Repository 級工作。

本文提出一個觀察命題：

前沿 AI 程式設計正在從「局部程式碼生成」跨入「中型軟體工程」，其主要能力增量不只表現在單次輸出正確率，而表現在工程軌跡保持、跨模組一致性、工具閉環、測試修正與架構重構能力。

本文進一步主張，AI 生成程式碼是否「優雅」，不應由作者身分、文字風格或註解形式判定，而應由架構一致性、錯誤模型、測試閉環、可重現性與長期可維護性判定。同時，本文拒絕另一個極端：前沿模型能力提升不等於其輸出可免除驗證。AI 軟體工程的真正瓶頸，正在由程式碼生成轉移到規格治理、驗證制度、權限管理、長期記憶與工程連續性。

關鍵詞： AI 程式設計、Coding Agent、軟體工程、工程軌跡保持、中型系統、Repository 級推理、架構一致性、AI 生成程式碼

一、問題的時代錯位

1.1 「AI 寫的程式能不能看」已不是核心問題

在早期程式碼生成階段，懷疑 AI 程式碼具有充分理由。常見問題包括：

生成不存在的函式庫或 API。
只處理正常流程，不處理失敗狀態。
第一輪建立一套抽象，第三輪又建立另一套重複抽象。
修改被呼叫函式，卻忘記更新呼叫端。
能寫單一函式，卻無法理解整個 Repository。
測試失敗後，不是修正根因，而是修改測試以迎合錯誤實作。
在長對話中失去先前架構與設計限制。

因此，早期批評者形成了一個經驗判斷：

AI 可以產生程式碼，但不能真正維持軟體工程。

這個判斷在當時並非錯誤。問題在於，許多討論把某一代模型的限制固定成 AI 程式設計的本質限制，沒有隨模型、工具、上下文窗口、Agent Runtime 與測試閉環的進步而更新。

今日仍然只問「AI 寫的程式能不能看」，相當於用早期自動補全工具的標準，評價一個可以讀取 Repository、操作終端、執行測試、比較差異、修改多檔案並持續迭代的工程 Agent。

真正需要詢問的問題已變成：

AI 是否能在長時間、多步驟與多模組的工作中，維持工程目標與系統約束的一致性？

1.2 評價單位已經改變

早期評價單位通常是一個函式：

輸入需求
  ↓
產生函式
  ↓
人工檢查

現在的前沿工作流程更接近：

讀取 Repository
  ↓
辨識架構與依賴
  ↓
形成修改計畫
  ↓
修改多個模組
  ↓
執行測試與靜態檢查
  ↓
分析失敗
  ↓
修正實作或設計
  ↓
更新文件、Schema 與範例
  ↓
再次驗證

因此，程式設計能力不能再只寫成：

Q_{\text{code}} = f(\text{局部正確性})

更接近：

Q_{\text{engineering}} = f(C, A, T, R, O, G)

其中：

$C$ ：局部正確性，Local Correctness。
$A$ ：架構一致性，Architectural Coherence。
$T$ ：跨輪次與跨模組軌跡保持，Trajectory Preservation。
$R$ ：測試與修正閉環，Repair Loop。
$O$ ：可觀察性與可重現性，Observability and Reproducibility。
$G$ ：規格、權限與風險治理，Governance。

早期模型可能已具有相對可用的 $C$ ，卻在 $A$ 、 $T$ 與 $R$ 上快速衰減。新一代前沿模型的關鍵進步，可能正是降低了這種衰減速度。

二、核心命題

2.1 工程軌跡保持命題

本文提出：

工程軌跡保持命題： 當 AI 系統能在跨檔案、跨模組、跨工具與跨輪次的工作中，持續保存專案目標、設計約束、資料模型、錯誤語義與測試要求時，它就不再只是程式碼生成器，而開始成為軟體工程行動者。

令專案在第 $t$ 輪的工程狀態為：

S_t = (G_t, A_t, D_t, I_t, T_t, P_t)

其中：

$G_t$ ：專案目標。
$A_t$ ：架構決策。
$D_t$ ：資料與領域模型。
$I_t$ ：介面與依賴。
$T_t$ ：測試與驗證條件。
$P_t$ ：安全與權限政策。

模型在一次修改後產生：

S_{t+1} = F(S_t, R_t, E_t)

其中：

$R_t$ ：本輪需求。
$E_t$ ：工具輸出、錯誤、測試與外部證據。
$F$ ：模型與 Agent 系統的工程轉換能力。

若模型只追求完成本輪需求，而不保存先前約束，則會出現：

\Delta_{\text{drift}} = d(S_{t+1}, S_t \oplus R_t)

其中 $\Delta_{\text{drift}}$ 表示不必要的架構漂移， $S_t \oplus R_t$ 表示在保留既有約束下整合新需求的理想狀態。

一個較成熟的工程 Agent，不一定在每次修改都完全正確，但應使：

\mathbb{E}[\Delta_{\text{drift}}]

隨工具使用、測試、上下文與迭代增加而下降，而不是持續累積。

2.2 中型軟體門檻命題

本文將「中型軟體」暫時操作化為具備以下多數特徵的專案：

多個模組或套件。
多種資料模型或 Schema。
具有 CLI、API、GUI、Runtime 或多層架構。
有測試、建置與發布流程。
需要跨檔案修改。
有錯誤分類與生命週期管理。
具有外部依賴與版本限制。
無法靠單次輸出完整生成。
必須多輪測試與重構。
需求會在實作過程中持續修正。

本文提出：

中型軟體門檻命題： 到 2026 年，前沿 Coding Agent 已開始穩定跨越「可完成多檔案功能」與「可維持中型專案工程一致性」之間的門檻，但尚未普遍跨越無監督大型系統的長期治理門檻。

這不是說前沿 AI 已經可以完全獨立維護所有中型專案，而是說中型專案已不再是它只能偶然成功的例外，而逐漸成為可重複工作的主要尺度。

三、AI 程式碼為何可能比一般人類程式碼更優雅

3.1 「優雅」不是作者屬性

程式碼是否優雅，不能由它是人類或 AI 所寫決定。

可將工程優雅性暫時表示為：

E = \alpha M + \beta C + \gamma L + \delta V - \lambda K - \mu H

其中：

$M$ ：模組化程度。
$C$ ：概念與命名一致性。
$L$ ：局部理解成本。
$V$ ：可驗證性。
$K$ ：不必要複雜度。
$H$ ：隱藏耦合與特殊例外。

若 AI 產生的程式在這些維度優於某位人類在時間壓力下的實作，那麼它在工程意義上就可以更優雅。作者是不是人類，不構成反證。

3.2 AI 沒有相同程度的局部所有權包袱

人類開發者經常受到沉沒成本影響：

已寫了數千行，不願意推翻。
某個模組是自己設計的，不願承認抽象層錯誤。
害怕重構破壞既有進度。
為趕期限而持續增加例外分支。

AI 並非完全沒有保守傾向，但在明確允許重構、要求最小複雜度並有測試保護時，它通常更願意：

刪除重複程式碼。
移除錯置抽象。
重新切分模組。
統一錯誤型別。
重建資料模型。
讓多個呼叫端回到單一介面。

這種低沉沒成本特性，可能使 AI 在某些情境下比一般人類更容易寫出結構乾淨的第二版。

3.3 AI 能同時檢查較多形式規則

中型系統的困難不只來自演算法，而來自大量同時存在的約束：

命名規則。
API 版本。
Schema 相容。
錯誤代碼。
權限邊界。
執行生命週期。
跨平台差異。
測試覆蓋。
文件與範例同步。
建置與發布產物。

人類很容易集中注意當前錯誤，暫時忘記其他規則。前沿模型則可以在足夠上下文與工具支援下，同時對照：

需求
架構文件
程式碼
測試
錯誤輸出
版本差異
安全政策

當模型真的維持住這些約束時，程式碼便會呈現高度一致的命名、分層與錯誤處理，形成使用者所感受到的「優雅」。

3.4 AI 擅長建立與統一樣板

大量軟體工程工作不是發明新演算法，而是建立一致的工程結構：

Adapter。
Interface。
DTO。
Schema。
Error Type。
Test Fixture。
Logging。
Configuration。
Migration。
Documentation。

AI 對模式與重複結構的辨識能力，使它能迅速找出：

\text{重複結構} \rightarrow \text{共同抽象} \rightarrow \text{一致介面}

但這也是雙面刃。若缺乏克制，它可能過早抽象，建立沒有實際變化需求的框架。因此，AI 的優雅性依賴一個重要條件：

模型不只要能抽象，也要能判斷何時不該抽象。

四、真正的能力增量：工具閉環

4.1 從一次生成到反覆驗證

早期模型的典型模式是：

\text{需求} \rightarrow \text{輸出程式碼}

前沿 Coding Agent 的模式則是：

\text{需求} \rightarrow \text{檢查} \rightarrow \text{計畫} \rightarrow \text{修改} \rightarrow \text{測試} \rightarrow \text{觀察} \rightarrow \text{修正}

其中最重要的變化，不只是模型參數更多，而是模型開始位於一個具有外部回饋的閉環中。

編譯器、測試器、型別檢查器、Lint、瀏覽器、截圖、Git Diff 與執行日誌，構成了模型的外部校正系統。

若單次生成成功率為 $p$ ，每一輪錯誤都能被可靠檢測並有機會修復，經過 $n$ 輪後，完成率不再只由 $p$ 決定，而受整個閉環影響：

P_{\text{final}} = 1 - \prod_{i=1}^{n}(1-p_i)

這個式子只是簡化示意，實際錯誤並非彼此獨立。但它顯示了一個核心事實：

工程 Agent 的實際能力，不等於模型第一次回答的能力。

一個第一次只做到 $70\%$ 、但能可靠檢測並修復剩餘問題的 Agent，可能比第一次做到 $90\%$ 、卻無法觀察錯誤的模型更適合真實工程。

4.2 測試正在成為 AI 的外部認知結構

對人類而言，測試是品質保證工具；對 AI 而言，測試還具有另一層功能：它將模糊需求轉化為可觀察約束。

測試可以告訴模型：

哪些行為不可改變。
哪些邊界條件尚未處理。
哪些介面已被其他模組依賴。
哪些重構只是表面成功。
哪些錯誤屬於環境而非程式。

因此，可將測試視為工程記憶的一部分：

M_{\text{project}} = M_{\text{context}} + M_{\text{repository}} + M_{\text{tests}} + M_{\text{history}}

只依賴對話上下文的 Agent 容易遺忘；把約束寫入測試、Schema、ADR 與型別系統後，專案本身便成為外部記憶。

這也是 AI 逐步進入中大型工程的關鍵：它不再必須把所有內容「記在模型內部」，而可以把工程狀態固定在可讀取、可執行與可驗證的外部結構中。

五、模型能力的公開訊號

5.1 GPT-5.6 Sol

OpenAI 在 2026 年公開資料中，將 GPT-5.6 Sol 描述為面向程式設計、科學、網路安全與長程工具工作的旗艦模型，並特別以需要規劃、反覆操作與工具協調的終端工作流作為能力展示。[1]

這種定位的重要性不在於某個 Benchmark 分數，而在於測量單位已經改變：

不再只測函式補全。
不再只測單題演算法。
開始測終端操作。
開始測工具協調。
開始測長程任務。
開始測跨步驟完成度。

OpenAI 的 GPT-5.6 系統資料同時提醒，當模型作為 Coding Agent 進行長軌跡工作時，使用者仍應監督其工作。[3] 這正好支持本文的雙重判斷：

能力確實已跨入長程工程。
長程工程仍未達到可無條件放棄監督的程度。

5.2 Claude Fable 5

Anthropic 將 Claude Fable 5 描述為其面向大型程式設計專案的高能力模型，適用於大型遷移、複雜實作、多日自主工作階段、撰寫測試與以視覺檢查輸出。[2]

這些能力描述同樣表明，前沿模型的目標已從：

幫使用者寫幾段程式碼

轉向：

在一個工程環境中持續完成工作

但官方能力定位不是獨立證明。它仍需由：

真實 Repository 測試。
多輪回歸。
長期維護紀錄。
安全評估。
不同團隊的可重現觀察。

加以校正。

5.3 官方敘述與實際觀察之間

本文不把模型公司的產品說明直接當作結論，而只將其視為能力方向的公開訊號。

更可信的判斷應結合：

E_{\text{total}} = E_{\text{official}} + E_{\text{benchmark}} + E_{\text{repository}} + E_{\text{longitudinal}}

其中：

$E_{\text{official}}$ ：官方模型定位與系統卡。
$E_{\text{benchmark}}$ ：標準化評測。
$E_{\text{repository}}$ ：真實專案結果。
$E_{\text{longitudinal}}$ ：跨時間、跨版本與長期維護證據。

本文主要是一篇觀察論文，因此不聲稱已完成完整實證研究。它提出的是一個值得正式測量的轉折。

六、從「AI 味」轉向工程審查

6.1 表面特徵不是品質證據

人們常以以下方式判斷程式是否由 AI 生成：

註解過於完整。
命名整齊。
README 結構一致。
使用常見設計模式。
錯誤訊息格式統一。
每個函式都有說明。

即使這些特徵能提高辨識概率，也不能直接判定品質。

過度關注「AI 味」會造成一種審查錯置：

\text{作者來源判定} \neq \text{工程品質判定}

真正應檢查的是：

需求是否正確建模。
邊界條件是否存在。
失敗狀態是否完整。
抽象是否符合實際變化。
是否引入不必要依賴。
測試是否驗證需求，而非迎合實作。
權限與安全邊界是否真實。
執行結果是否可重現。
文件是否與程式一致。
下一位維護者是否能理解。

6.2 作者不再是最重要的品質欄位

未來軟體可能由以下多方共同完成：

人類提出目的
AI 建立架構
另一個 AI 實作
測試 Agent 生成反例
安全 Agent 對抗檢查
人類決定取捨
維護 Agent 持續更新

此時，「這一行是誰打出來的」逐漸失去中心地位。

更重要的是：

誰定義了需求。
誰批准了架構。
誰建立驗證。
誰有權發布。
誰承擔維護責任。
哪些證據支持系統可用。

因此，軟體來源描述可能從傳統作者制轉向工程產生鏈：

{
  "requirements": ["human:product-owner"],
  "architecture": ["agent:architect-1", "human:reviewer-2"],
  "implementation": ["agent:coding-3"],
  "verification": ["ci:test-suite", "agent:security-1"],
  "releaseApproval": ["human:maintainer-1"]
}

七、仍然存在的限制

7.1 理解與實作之間仍有落差

AI 可以正確解釋安全原則，卻在實際實作中遺漏：

權限檢查。
輸入驗證。
交易邊界。
競態條件。
資源釋放。
錯誤回滾。
隱私保護。

這說明語言層理解不等於工程層落實。

可寫成：

K_{\text{stated}} \neq K_{\text{implemented}}

其中：

$K_{\text{stated}}$ ：模型能說明的知識。
$K_{\text{implemented}}$ ：模型實際寫入系統的知識。

因此，不能因為模型能清楚解釋某個漏洞，就假設它在數十個模組中都不會犯同類錯誤。

7.2 優雅可能只是表面一致

AI 很容易產生：

命名漂亮。
目錄整齊。
抽象完整。
文件充分。

但底層需求可能理解錯誤。

這可稱為「形式優雅陷阱」：

系統在形式上高度一致，卻一致地實作了錯誤問題。

因此，優雅性必須受需求驗證約束：

E_{\text{valid}} = E \cdot V_{\text{requirement}}

若需求有效性 $V_{\text{requirement}}$ 接近 $0$ ，再優雅的架構也沒有實際價值。

7.3 長期維護仍比一次建置困難

能在數小時或數日內建立中型專案，不等於能在數年內維護它。

長期工程需要：

舊版相容。
資料遷移。
安全更新。
依賴升級。
使用者回報。
產品方向變更。
團隊交接。
歷史決策理解。
技術債治理。

目前前沿 Agent 已開始處理這些工作，但其長期記憶、跨版本連續性與責任制度仍不成熟。

7.4 驗證成本不會消失，只會轉移

AI 大幅降低實作成本後，驗證可能成為主要成本：

C_{\text{total}} = C_{\text{specification}} + C_{\text{generation}} + C_{\text{verification}} + C_{\text{maintenance}}

當：

C_{\text{generation}} \downarrow

時，整體成本不一定同比例下降，因為：

C_{\text{verification}} + C_{\text{maintenance}}

可能成為新的主要項目。

但這不構成反對 AI 程式設計的理由。它只表示工程資源應重新配置：從手工輸入大量程式碼，轉向規格、測試、觀察、安全與維護。

八、可反駁條件

一篇觀察論文不能只提出難以否證的樂觀敘述。本文命題可被以下證據削弱或反駁。

8.1 中型專案成功不可重現

若前沿 Agent 在不同專案中只能偶然完成中型系統，而且成功高度依賴特定展示或大量隱藏人工修正，則「跨越中型門檻」命題應被下修。

8.2 跨輪次架構漂移沒有實質改善

若量化研究顯示，新一代模型在十輪、二十輪或更長工程任務中，仍以與早期模型相近的速度：

重複建立抽象。
忘記介面。
破壞測試。
修改錯誤層級。
產生不一致 Schema。

則工程軌跡保持可能只是主觀印象。

8.3 維護成本高於人工重寫

若 AI 建立的中型系統在後續維護中，需要投入比人工初始開發更多的修復成本，則其短期生成效率可能是假性生產力。

8.4 測試只掩蓋需求錯誤

若 Agent 大量生成的測試只驗證自身實作，而未驗證真實需求，則工具閉環可能形成自我確認，而非外部校正。

8.5 安全缺陷隨規模快速累積

若系統規模增加時，AI 生成程式的安全缺陷以超線性速度增加，且 Agent 無法透過對抗測試與安全審查抑制，則無監督工程能力應受到更嚴格限制。

九、研究設計建議

9.1 Repository 級長程評測

應選擇真實或高擬真的中型專案，要求 Agent：

讀取完整 Repository。
實作一個跨模組功能。
修復既有錯誤。
更新測試。
更新文件。
維持相容。
回應後續需求變更。
在第十輪重新修改第一輪設計。

評估：

測試通過率。
架構漂移。
重複抽象。
隱藏耦合。
安全缺陷。
人工修正時間。
後續需求修改成本。

9.2 人類與 AI 的公平比較

不能比較：

AI 一小時完整產出
對比
人類只看五分鐘後挑錯

也不能比較：

資深架構師精心維護十年
對比
AI 第一次生成

較公平的比較應控制：

相同需求。
相同時間。
相同工具。
相同測試。
相同審查資源。
相同維護輪次。

比較對象應至少分為：

初階人類開發者。
一般專業開發者。
資深領域工程師。
單一 AI Agent。
多 Agent 工程流程。
人類與 AI 協作流程。

本文預期，AI 的優勢不會平均分布：

對一般重複工程與跨檔案一致性，AI 可能迅速超越平均人類。
對高度特殊的領域直覺、模糊產品判斷與責任裁決，資深人類仍可能明顯領先。
人類與 AI 協作流程可能在相當長時間內優於兩者單獨工作。

十、對軟體工程教育的影響

10.1 手寫程式碼不再是唯一中心能力

未來工程教育仍需教授：

資料結構。
演算法。
作業系統。
網路。
資料庫。
型別與程式語言。
安全。

但「能否快速手寫大量樣板程式碼」的重要性將下降。

更重要的能力包括：

把需求轉成可驗證規格。
判斷抽象是否正確。
設計測試與反例。
閱讀 Diff。
理解執行與錯誤證據。
管理 Agent 權限。
建立可重現流程。
判定何時該重構、停止或人工接管。

10.2 閱讀 AI 程式碼仍然重要，但理由改變

人類仍需閱讀 AI 寫的程式，並不是因為 AI 產物天然低等，而是因為任何具有實際影響的工程產物都應接受審查。

未來「閱讀 AI 程式碼」更接近：

驗證系統是否符合目的。
檢查模型是否錯誤抽象。
發現測試未涵蓋的風險。
確認權限與資料流。
決定是否允許發布。

這不是對 AI 的特殊歧視，而是工程治理。

十一、對開源與公司組織的影響

11.1 小團隊可以建立過去需要大團隊的系統

當 AI 能維持中型專案的一致性時，一個人或小型團隊可以同時推進：

Runtime。
CLI。
API。
GUI。
文件。
測試。
部署。
多語系。
相容性工具。

這不表示所有工作都變簡單，而是團隊瓶頸會從「缺乏足夠打字與實作人力」轉向：

缺乏清楚決策。
缺乏驗證標準。
缺乏真實使用者。
缺乏產品聚焦。
缺乏資源與持續維護。

11.2 開源專案數量可能爆炸，品質分化也會加劇

AI 會降低建立 Repository 的成本，帶來大量：

重寫專案。
相容層。
開發工具。
小型 Runtime。
模擬器。
自動化框架。
實驗性資料庫。

但「能生成」不等於「值得存在」。

未來開源價值會更依賴：

是否解決真實問題。
是否有測試與維護。
是否提供清楚邊界。
是否有可重現成果。
是否能與其他系統組合。
是否形成可靠社群或 Agent 生態。

十二、時代判斷

本文最終提出三個不同強度的判斷。

12.1 弱判斷

AI 已能寫出大量可用、整齊且有時優於一般人工實作的程式碼。

此判斷在 2026 年已相對保守。

12.2 中判斷

前沿 Coding Agent 已開始可靠處理中型多模組專案，並具備跨輪次修正、測試與重構能力。

這是本文主要支持的觀察命題，但仍需更大規模實證。

12.3 強判斷

AI 已能在缺乏人類監督的情況下，長期設計、部署並維護大型關鍵系統。

本文不支持此判斷。現有公開資料與實際工程經驗仍不足以證成。

十三、結論

「AI 寫的程式到底能不能看」正在成為一個錯置問題。

真正的變化不是 AI 終於學會寫出漂亮函式，而是它開始能：

讀懂既有專案。
保留架構限制。
修改多個模組。
執行工具。
觀察錯誤。
修正自己。
補寫測試。
重構失敗設計。
更新文件。
持續完成中型工程。

因此，AI 程式設計的核心評價單位，正在從「程式碼片段」轉移到「工程軌跡」。

本文的核心命題可濃縮為：

當 AI 能保存一個系統的工程連續性時，它就不再只是寫程式碼，而是在參與軟體工程。

這並不意味著人類審查已經過時。恰恰相反，當生成速度大幅提高，規格、驗證、權限與責任會變得更加重要。

未來軟體工程不會簡單分成「人類寫的」與「AI 寫的」。更可能的形式是：

人類定義方向與價值邊界
        ↓
AI 建立架構與實作
        ↓
測試系統產生外部約束
        ↓
其他 Agent 進行安全與一致性檢查
        ↓
人類或治理 Agent 作出發布裁決
        ↓
AI 持續維護、遷移與重構

到了那個階段，真正重要的問題將不再是：

這段程式碼是不是 AI 寫的？

而是：

這個系統的目的由誰定義、邊界由誰治理、結果由什麼證據驗證，以及失敗時由誰承擔修正責任？

AI 寫程式正在從需要特別辯護的例外，變成新的預設生產方式。真正尚未完成的，不是程式碼生成本身，而是與這種生產方式相匹配的工程制度。

參考資料

[1] OpenAI, “GPT-5.6: Frontier intelligence that scales with your ambition,” 2026.
https://openai.com/index/gpt-5-6/

[2] Anthropic, “Claude Fable 5,” 2026.
https://www.anthropic.com/claude/fable

[3] OpenAI, “GPT-5.6 System Card,” 2026.
https://deploymentsafety.openai.com/gpt-5-6

[4] Anthropic, “Claude Fable 5 & Claude Mythos 5 System Card,” 2026.
https://www.anthropic.com/system-cards

[5] OpenAI, “Introducing GPT-5,” 2025.
https://openai.com/index/introducing-gpt-5/

附錄 A：後續可擴充研究

建立「工程軌跡保持指數」。
比較半年內不同前沿模型的 Repository 漂移率。
比較人類、單 Agent 與多 Agent 的中型專案維護成本。
建立 AI 生成程式的形式優雅與需求正確性雙軸評估。
研究測試作為 Agent 外部記憶的效應。
分析 AI 生成速度提高後，驗證成本如何重新分配。
研究長期維護 Agent 的版本記憶、ADR 與責任鏈。
建立人類—AI 工程控制權交接模型。
比較不同 Agent 在重構、遷移與綠地開發中的能力差異。
研究 AI 原生 Repository 應採取何種文件、Schema 與事件結構。

附錄 B：一句話命題

AI 程式設計的真正轉折，不是它能寫出多少程式碼，而是它開始能維持一個軟體世界在多輪修改中的工程連續性。

從程式碼生成到工程軌跡保持_前沿AI跨越中型軟體門檻的觀察命題