當軟體成長得比人的理解更快

把一個需求交給 Coding Agent，過一會兒，功能已經可以運行，測試也通過了。變更紀錄裡出現了許多檔案、新的結構，以及需求中沒有明確提到、卻由 Agent 順手處理的問題。

結果看起來不錯。幾次試用沒有發現明顯錯誤，工作便進入下一個需求。

但一些問題可能還沒有答案：為什麼採用這種實作？哪些行為來自明確的要求，哪些來自 Agent 的選擇？下一次修改觸及這裡時，什麼必須保留？

軟體已經向前走了。人的理解，還停留在出發時。

一、軟體在變化，人的認識如何延續

軟體不僅以程式碼和運行程序的形式存在於機器中，也作為一個有意義的對象存在於人的認識中。它用來做什麼，為什麼這樣工作，哪些選擇必須保留，哪些地方可以改變——這些認識讓人能夠持續塑造自己的軟體。

這種認識不需要涵蓋全部實作細節。一個人可以不了解底層的每一個函式，卻仍然知道軟體應當成為什麼，能夠判斷某次變化是否符合自己的意圖，並在需要時改變它。

在傳統開發中，系統複雜性和團隊更替會使人的認識與實作脫節；設計、編碼、除錯與修改，則讓人在改變軟體的過程中不斷建立和修正認識。

Coding Agent 改變了這件事的速度。它可以跳過其中許多需要人親自參與的步驟，直接完成大量實作。軟體繼續變化，人的認識卻未必隨之更新。

功能先完成，理解留到了後面：讀變更、追問原因、弄清它會影響哪裡。省下的編碼時間裡，又排進了這些工作。Agent 可以繼續生成，等待人理解的東西也可以繼續增加。

更難適應的，是軟體明明在按要求推進，卻越來越難說清自己對它有多熟悉。一整天都在分派任務、回答問題、檢查結果，每個 Agent 都有進展，但這些進展如何組成一個整體，還需要重新梳理。親手建構時逐漸形成的那種「知道它走到哪裡、接下來該怎麼改」的掌握，並不會隨著任務完成自動到來。

於是，自己的作品逐漸變得陌生。人還記得最初提出了什麼，卻越來越難說清現在的結果為什麼如此，過去的決定是否仍然有效，下一次修改又會影響什麼。這份「知道它是什麼、為什麼這樣，以及如何改變它」的連續性正在中斷，繼續塑造作品也變得困難。

二、即使 AI 做得更好，人仍有自主創作的權利

一個很自然的回答是讓模型變得更可靠：寫出更好的程式碼，發現更多錯誤，進行更完整的驗證。如果它足夠好，人是否就不再需要理解和決定作品應該成為什麼？

人在創作中的自主權，不以 AI 仍然會犯錯為前提。

「程式碼可以交給 AI，架構總還需要人。」這樣的回答把人的位置寄託在一項暫時領先的能力上。但如果模型連架構也做得很好呢？再退到驗證、系統理解，仍然會遇到同一個問題：一旦模型也擅長這件事，人是否就失去了參與的理由？

把這個問題推到極限：假設 AI 已經達到 AGI，能夠理解複雜系統，作出優秀的技術選擇，也能比人更充分地檢查實作。人是否就應該把創作中的決定也全部交出去？

只要仍然有人希望按照自己的意圖創作，願意親自決定作品的方向，這個問題就沒有消失。

作出更好決定的能力，不會自動賦予替人決定的權利。

人可以選擇把許多判斷交給 AI，也可以在某件事上保留決定權。可以接受建議、改變想法，甚至接受原來的選擇被證明並不合適。關鍵在於，這應當是理解之後的選擇，而不是軟體已經改變、事後才得知的結果。

自主創作的權利，不以人的能力超過 AI 為條件，也不取決於有多少人還想保留它。即使絕大多數人願意把一切交給 AI，剩下的那個人仍然有權決定自己的軟體應當成為什麼。

只要還有一個人希望自主創作，如何讓他的創作意圖持續有效，就仍然是一個需要回答的問題。

三、繼續塑造軟體，需要哪些能力

持續創作意味著，在最初的想法變成軟體之後，人仍然能夠理解重要選擇、改變方向、拒絕不符合意圖的結果，並繼續修改作品。創作中的自主權，需要落實為這些實際能力。

只能在 Agent 完成工作後點擊「接受」，卻不知道其中包含什麼重要選擇；可以拒絕，卻找不到改變結果的辦法；昨天明確表達的要求，在今天的修改中悄悄失效——這些情況下，人雖然還在批准結果，卻已經難以按照自己的意圖繼續創作。

要繼續塑造軟體，需要能夠回答一些具體問題：

• 軟體應當成為什麼，是否仍然清楚？
• 目前的實作如何回應了人的要求，是否能夠看見？
• 哪些重要選擇來自人，哪些來自 Agent，是否能夠分清？
• 改變方向時，是否能夠理解可能的影響並介入？
• 下一次實作變化後，過去明確作出的決定是否仍然有效？

例如，一個私人寫作工具被明確要求將內容保存在本機。檔案組織、儲存實作和許多內部細節，可以交給 Agent 決定。之後為了方便跨裝置使用，Agent 提出雲端同步。

但「內容是否離開本機」涉及創作者已經表達的決定。這一選擇需要被看見，它帶來的變化需要能夠被理解，然後才有接受或拒絕的機會。更方便、更穩定的結果，也可能偏離原來的要求。

測試可以幫助證明軟體按某種行為工作。人的判斷還需要回答：這種行為是否值得接受，是否符合希望持續維護的決定？

Agent 可以完成同步功能，檢查資料是否正確傳輸，修復實作中的錯誤。但是否應該讓內容離開本機、什麼證據足以接受這次改變、出了問題由誰負責，需要在執行之外作出明確安排。人的判斷要能夠決定工作朝哪裡走、何時停下來，而不是等一切完成之後再簽字。

四、讀完所有程式碼，就能繼續塑造軟體嗎

程式碼審查是一個直接的回答。Agent 寫出程式碼，由人閱讀，確認它做了什麼。

程式碼裡有模型報告未必提到的行為，有會影響維護的結構，也有只有深入實作才能判斷的問題。

但當生成速度不斷提高，讓人讀完全部產出，能否持續承擔這項任務？

即使不再逐行讀程式碼，一天的工作也可能仍然很滿：把模糊的要求說清楚，發現結果偏離了哪裡，決定該用什麼證據檢查，再把 Agent 引回正確的方向。每一步都需要經驗和專注。「程式碼幾乎沒看，工作卻一點也不輕鬆」，完全可以同時發生。

與此同時，閱讀程式碼本身也是形成理解的機會。讀同事的變更時，團隊能了解系統新增了什麼、為什麼這樣設計、以後修改時需要留意哪裡。減少閱讀之後，這些理解需要透過其他方式建立。

但如果變更排成長隊，人只能匆匆掃過再點批准，保留審查流程也未必保留了理解。關鍵是讓有限的注意力落在真正需要判斷的地方：設計時的重要取捨、影響大的變化，以及仍有疑問的結果。

真正需要回答的是：哪些選擇值得人持續理解？哪些實作細節可以在需要時深入調查？如何避免人的注意力被大量細節耗盡，卻錯過了真正需要決定的事情？

五、如果把程式碼換成長篇規格呢

另一種回答，是把人的工作轉向自然語言。先寫清楚軟體應該如何工作，再讓 Agent 根據規格實作它。或者讓 Agent 解釋程式碼，把系統轉換成人更容易閱讀的文件。

清晰的要求能減少誤解，文件能保存背景，好的解釋也能讓陌生的實作變得容易理解。但自然語言並不會自動消除閱讀的成本。

如果軟體包含大量行為與取捨，而另一份文件需要完整描述它，那麼這份文件也可能隨著實作一起成長。人會從讀不完程式碼，走向讀不完說明。即使每一句都比程式碼容易理解，總量依然可能超過人的時間與注意力。

更進一步，如果規格本身也是由 Agent 不斷補充，人只是批准它，那麼「這是人確認過的文件」仍然不能說明人真正理解了其中每一個決定。

軟體已經擁有的行為、Agent 對這些行為的描述，以及人真正理解並願意維護的決定，是三件不同的事。

有了完整的紀錄和說明，人仍未必知道如何繼續塑造軟體。重要的事情需要能夠被找到，今天如何成立需要能夠被理解，下一次改變時有哪些選擇也需要能夠被看見。

結語：讓人繼續自主創作

實作成本下降，讓更多人有機會把想法變成軟體。人也應當能夠理解並持續塑造自己的作品。

這份自主權不限於軟體。任何創作中，交給 AI 什麼、自己決定什麼，都應由創作者選擇。

Finite Ground 的使命，是讓人在 AI 不斷擴展創作可能性的時代，仍然能夠按照自己的意圖創作，並持續塑造自己的作品。

Noema 從軟體領域回應這個使命，讓人的創作意圖在實作不斷變化時持續有效。

如果有一天，AGI 接管了人類生活的全部，所有人也都放棄了自己的自主權，這個問題就不再成立，Finite Ground 也就失去了存在的理由。

只要還有一個人不願放棄自主權，就有繼續做下去的理由。

AI 可以讓更多想法成為現實。決定作品應當成為什麼的權利，仍然屬於不願放棄它的人。