生成式 AI 拯救哪些遺產，又會放棄哪些（4/7）
前言
在第 3 回裡，我們確認到現代公民開發的基礎——RPA 與 no-code/low-code——潛藏著比神 Excel 更嚴重的債務風險。 沿著這條脈絡，生成式 AI 的出現究竟改變了什麼？
生成式 AI 能讀取既有的軟體資產，協助遷移或重新設計。 但那些沒有寫成程式碼的資產——no-code 與 RPA 的黑箱——即使對 AI 來說也難以實際拯救。
換句話說，未來會留下的負資產，很可能集中在「沒有被程式碼化的東西」。
全系列
- 洞悉公民開發的未來──歷史、現在、生成式 AI 以及更遠的前方 0/7
- 公民開發是 EUC 的回歸嗎？──神 Excel 的歷史教訓 1/7
- 神 Excel 真的是反派嗎？──從救世主到負資產 2/7
- 現代公民開發平台的明與暗 3/7
- 生成式 AI 拯救哪些遺產，又會放棄哪些 4/7 （本回）
- 公民開發不是萬能的──它是「草稿式開發」 5/7
- 視角錯位如何量產負資產 6/7
- 遺產仍會不斷誕生，也要馴服它──公民開發的未來圖像 7/7
生成式 AI 的強項──「解凍」程式碼資產
傳統上，遷移舊系統程式碼需要龐大的人力。 以 COBOL 或 VB 等舊語言寫成的上百萬行程式往往沒有文件，只能仰賴資深工程師分析。
生成式 AI 在此打開突破口。
-
自動化的程式碼閱讀 它能視覺化函式的相依關係，並從上下文推測變數或結構的意義。
-
語言轉換的輔助 產生從 COBOL 到 Java、從 VB 到 Python 等遷移草稿，成為移植作業的起點。
-
半自動化的重構 將義大利麵式的邏輯拆解成函式，生成測試碼，讓後續團隊能更順手地接手。
總之，只要資產仍以程式碼形式存在，AI 就能半自動將其「解凍」。 在這點上，生成式 AI 有望成為以程式碼為基礎的遺留系統更新的遊戲規則改寫者。
當然，「有程式碼就一定能救」並不成立。 若依賴環境已不存在，或掌握業務知識的人離開了，仍會留下 AI 無法補上的空缺。 但與只剩黑箱的資產相比，重生的可能性高出許多。
無法拯救的對象──從未程式碼化的資產
那麼，以 no-code 或 RPA 打造的資產又如何呢？
它們以 GUI 操作或流程圖存在，內部表現被封在廠商獨有的資料結構裡。 生成式 AI 最擅長處理文字，但面對加密或專有格式封裝的黑箱，分析極為困難。
例如 RPA 的「作業流程」，表面看似積木流程圖，實際上往往是加密的專案檔案。 no-code 的「應用」通常只能在廠商的雲端運行，根本沒打算以原始碼形式匯出。
在現實中，重新設計多半比救援來得快。 或許未來的研究能從操作錄影或截圖推測流程，但至少在現階段，直接承接黑箱化的資產幾乎不可能。
負資產的分水嶺──是否留存在程式碼裡
於是可以看見，未來負資產的分水嶺所在。
- 被保留成程式碼的資產，因生成式 AI 而開啟再利用、遷移與改善的道路。
- 未被程式碼化的資產，對生成式 AI 來說有大片不可見區域，只能重新設計。
也就是說，未來能否被拯救取決於 「我們是否讓它以程式碼形式留下」。 生成式 AI 讓這條界線更加鮮明。
展望──AI 不是萬能的救世主
生成式 AI 的確強大，但至少現在還遠非萬能。 它無法徹底拯救已經黑箱化的公民開發資產，也無法替過去的決策背書。
AI 迫使我們正視 「不寫程式碼的自由」所需付出的代價。 被 no-code 的即時效果吸引的組織會發現，AI 並不會拋出救生索，只能自己承擔重新設計的成本。
因此，下一回將深入探討 如何避免製造負資產──從治理設計的角度。