AI 都會寫程式了,我還要學什麼?——從「做得出來」到學會開發的 30 天

本系列文章・21/25

第 1 章|實作跑在理解前面

  1. Day 1|做得出來,卻完全改不動
  2. Day 2|當實作跑得比理解更快

第 2 章|第一個產品:從做功能,到開始理解工作

  1. Day 3|功能是從觀察和許願長出來的
  2. Day 4|如果所有事情都能交給 LINE 機器人就好了
  3. Day 5|做自己的系統,不代表什麼都要自己做
  4. Day 6|把反覆確認的工作交給系統之後
  5. Day 7|一句「平常都這樣做」,後面藏了多少事情?
  6. Day 8|沒有告訴 AI 的事
  7. Day 9|系統知道怎麼做,不代表使用者就該這樣做
  8. Day 10|我以為功能做完,產品就完成了
  9. Day 11|看到 n8n 時,我以為找到做預約系統的方法了

第 3 章|第二個專案:理解工作的能力開始變成工程判斷

  1. Day 12|原來我在做翻譯
  2. Day 13|聽他怎麼說,也看他怎麼做
  3. Day 14|我開始能從工作流程看見系統需要做什麼
  4. Day 15|我開始能從工作流程看見產品應該如何被使用
  5. Day 16|以終為始:思考產品功能
  6. Day 17|從「這個功能怎麼做」開始看懂系統怎麼分工
  7. Day 18|系統分工之後,怎麼讓不同部分一起工作
  8. Day 19|把「為什麼這樣決定」也留下來
  9. Day 20|從「我要這個功能」到「系統必須保證什麼」

第 4 章|AI 寫大量程式後,我怎麼理解、判斷與相信實作?

  1. Day 21|我幾乎不讀程式碼,那我是怎麼理解系統的?目前閱讀
  2. Day 22|從理解工程概念,到形成自己的判斷
  3. Day 23|我已經能沿著系統思考,卻還不能沿著程式碼追問題
  4. Day 24|我不逐行讀程式碼,那我要怎麼知道 AI 做對了?
  5. Day 25|用測試約束 AI 改程式

Day 21|我幾乎不讀程式碼,那我是怎麼理解系統的?

本篇目錄
  1. AI Coding 工具本身也變了
  2. 我現在主要參與的是實作以前的理解
  3. 看不懂 design,我還是會繼續問
  4. Codex 寫完之後,我還是會追問「為什麼」
  5. 但「理解系統」和「能獨立修改」不是同一件事
  6. 這和 Day 1 到底差在哪裡?

現在這個委託專案有前端、後端、文件處理服務,也拆成多個 repo。

整套系統已經比 Day 1 那個個人網站複雜非常多。

但我實際開發時,幾乎不直接讀程式碼。

平常我很少打開某個檔案,去看一段邏輯到底怎麼寫;遇到 bug,也通常不是自己先進 codebase 找問題,而是把現象交給 Codex,讓它去定位。

如果只看「我有沒有親自讀很多 code」,現在甚至比 Day 1 更少。

但我對系統的理解,已經和當時很不一樣。

AI Coding 工具本身也變了

Day 1 做個人網站時,ChatGPT 主要還是在聊天視窗裡提供程式碼。

我說想做什麼,它產生 HTML、CSS、JavaScript,或者告訴我應該建立哪些檔案。

接著再由我把這些內容複製、貼進本機專案。

當時有一大段工作是:

AI 把程式碼交給我,我再把程式碼搬進專案。

現在的 Codex 已經可以直接讀取 workspace 裡的程式和文件、修改實際檔案,也能跨不同 repo 處理同一個需求,自己執行測試和檢查。

連「把程式真正寫進專案」這件事情,都已經可以大量交給 Agent。

所以我的日常工作也往前移了。

我現在主要參與的是實作以前的理解

有新的需求時,我通常不會直接叫 Codex 開始改程式。

前面會先走 Spectra/OpenSpec 的規格流程,把這次到底要解決什麼、準備怎麼做,以及可能影響哪些部分先討論清楚。

我會看自然語言寫成的 proposal、design 或其他文件。

如果牽涉操作介面,也會先看 UI 設計稿。

這些都不是程式碼。

但它們會先說明:

這次要改什麼。

使用者最後要怎麼完成工作。

哪些系統部分會參與。

不同部分之間大致怎麼配合。

資料可能怎麼流動。

有哪些條件需要被維持。

真正進到程式實作以前,已經先有一個我比較能讀懂,也能參與修改的版本。

這和 Day 1 很不一樣。

當時我常常直接從需求跳到一大段生成好的程式。

現在,中間多出了一整層可以先討論的東西。

看不懂 design,我還是會繼續問

當然,自然語言寫成的 design,不代表我一定看得懂。

有些工程機制對我來說還是很抽象。

這時候我的做法通常也不是直接打開程式碼,而是繼續問 Codex。

這個機制到底怎麼運作?

為什麼要這樣分?

如果換另一個方案,會多出哪些成本或限制?

如果第一次解釋太抽象,我會請它換成白話。

不同系統之間的關係比較複雜時,我也會請它畫 Mermaid,把資料或工作怎麼流動畫出來。

所以我現在很多對系統的理解,不是從一個個檔案往上拼。

更常是先理解:

這個需求在整套系統裡要怎麼成立。

接著再理解:

誰負責什麼。

彼此怎麼配合。

不同做法有什麼差別。

Codex 寫完之後,我還是會追問「為什麼」

真正開始 Coding 之後,我通常不會跟著逐行看。

如果出了 bug,也大多先讓 Codex 去定位。

但它找到問題、提出修改方式之後,我還是會繼續問背後的機制。

為什麼問題會出現在這一層?

原本的設計是怎麼運作?

為什麼需要經過另一個服務?

這次修改是在維持哪個條件?

所以我現在參與工程的方式,比較不像跟 Agent 一起逐行寫程式。

更接近:

讓 Agent 負責大量實作,但要求它把實作背後的機制講到我能繼續參與判斷。

但「理解系統」和「能獨立修改」不是同一件事

這裡有一個很重要的能力邊界。

我現在可以跟著討論:

某個需求可能牽涉哪些系統部分。

為什麼某個責任放在這一層。

不同方案會帶來什麼影響。

一次修改可能還需要同步調整哪些地方。

但如果把 Codex 拿掉,只剩下這幾個 repo,要我自己找到實際應該修改的程式、讀懂現有實作,再獨立完成修改,我沒有把握。

所以:

理解這套系統,和能不能不靠 Agent 自己完成修改,是兩件不同的事。

我目前做到的是前者的一部分。

後者還沒有。

這和 Day 1 到底差在哪裡?

Day 1 時,我也知道自己想要什麼,而且最後看得到網站真的動起來。

但需求和結果中間,那套網站到底怎麼組成、哪些部分怎麼互相影響,對我來說幾乎整塊都是黑盒。

ChatGPT 給我程式碼,我貼進去。

結果不對時,我不知道是哪個檔案有問題,也不知道改一個地方為什麼會影響另一個地方。

現在我直接看的程式碼反而更少。

但需求和結果中間,我已經看得到:

  • 工作流程
  • 規格
  • design
  • 系統責任
  • 資料流
  • 工程選擇
  • 不同方案的取捨

我不一定能直接確認它們最後對應到哪一段實作,但至少整套系統不再只剩「需求」和「結果」兩個端點。

所以 Day 1 到現在的差別,不是:

以前不會寫,現在會寫。

也不是:

以前看不懂 code,現在都看懂了。

更接近:

以前我幾乎看不到需求怎麼一路變成系統;現在我已經開始能看見中間的結構,也能參與其中一部分判斷。

但這又留下下一個問題。

如果我對很多工程概念的理解,都來自 Codex 的說明:

我聽懂了,到底代表什麼?

返回系列總覽 →