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

本系列文章・1/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 1|做得出來,卻完全改不動

本篇目錄
  1. 做得出來,但不知道去哪裡改
  2. 我開始學前端,但很快就直接進了完整專案
  3. 我的學習順序開始變得很奇怪
  4. 我後來看見的,不只是 Coding
  5. 所以這個系列真正想問的是什麼?

2025 年 10、11 月左右,我曾經想做一個自己的個人創作網站。

當時的想法不算複雜。

我有 Podcast,也有電子報,希望透過 RSS feed,把散落在不同平台上的內容集中到自己的網站。

那時候我還沒有正式學過前端,但 ChatGPT 已經可以根據我的描述產生 HTML、CSS、JavaScript。

最早還是一個超大型的單一檔案。後來想做的東西越來越多,甚至在 ChatGPT 的協助下改用了 Vue,把網站拆成不同頁面。

但我的開發方式沒有因此改變多少。

ChatGPT 告訴我要建立哪些檔案、每個檔案放什麼,我就把它生成的程式碼一支一支複製、貼進專案。

當時我也不懂 GitHub Pages 是什麼,只是完全照著 YouTube 影片一步一步操作。

最後,網站真的部署起來了。

所以我確實:

做出了一個網站。

問題是,我完全改不動它。

做得出來,但不知道去哪裡改

只要結果和我想的不一樣,我很難判斷應該修改哪個檔案,更不用說找到是哪一段程式碼造成的。

即使只是局部調整,我最熟悉的做法還是重新向 ChatGPT 描述需求,請它重新產生程式碼,再把相關檔案逐一複製貼上。

我不是完全沒有接觸過程式。

過去使用 MATLAB 的經驗,至少讓變數、條件判斷和程式執行邏輯對我不算完全陌生。

但我那時候第一次很具體地感覺到:

「大概看得懂一小段程式在做什麼」,和「知道一套網站怎麼組成、出問題時應該去哪裡找」,中間還隔著很長一段距離。

也就是那時候,我產生了一個很直接的念頭:

我應該去學前端。

不是因為我思考過「AI 時代還需不需要學 HTML、CSS、JavaScript」。

也不是刻意決定要走什麼 AI-first 的學習路線。

原因單純得多:

我做得出來,但是我改不動。

我開始學前端,但很快就直接進了完整專案

2025 年 11 月底,我開始接受前端開發訓練。

我開始學 CSS,理解 DOM 和畫面的關係,也接觸了一些 JavaScript、TypeScript。

原本由 ChatGPT 一次吐給我的一大堆程式碼,逐漸變成一些可以辨認的東西。

但事情並沒有照著:

先把前端學熟,再開始做真正的產品。

這個順序發展。

到了 2026 年 2 月底,我有了一個很明確、自己真的想解決的產品需求。

基於長期使用諮商服務的觀察與經驗,我想嘗試做一套以 LINE OA 為主要互動入口的諮商所預約管理工具。

當時的我並沒有覺得自己「準備好了」。

我只是知道自己想解決什麼問題,也有一些希望做到的事情。

於是就直接拿這些需求去跟 AI 討論:

這個功能可以怎麼做?

這段流程還需要什麼?

遇到問題要怎麼改?

然後一個功能、一個功能地做下去。

從我開始正式學前端,到開始做第一個完整產品,中間大約只有三個月。

我沒有刻意決定跳過「手刻程式」的階段。

只是 AI Coding 工具能力快速進步,確實讓我某種程度跳過了:

先把程式寫得很熟,才開始做真正的東西。

我的學習順序開始變得很奇怪

我還沒有花很長時間把 JavaScript 寫熟,就已經開始遇到很多以前根本沒有想過的問題。

資料應該放在哪裡?

不同功能怎麼互相配合?

系統怎麼知道使用者現在做到哪一步?

誰可以看到、修改哪些東西?

功能做完之後,我要怎麼知道它真的可靠?

很多時候,我甚至是在真的撞到問題之後,才知道:

原來軟體開發裡早就有一套概念在處理這件事。

AI 可以很快把需求變成可以執行的程式,也讓我可以一邊做、一邊問、一邊理解。

但它同時產生了一個對我來說更大的問題:

當我還沒有經歷長時間手刻程式的練習,就已經可以開始做系統,我到底該怎麼學習「開發」?

這也是我想用接下來 30 天整理的事情。

我後來看見的,不只是 Coding

整理目前的開發經驗時,我大概可以把自己正在補的能力分成幾個方向。

產品上,我在學的是先看一件工作原本怎麼進行。

人在什麼地方反覆搬資料、確認資訊、切換工具?

新的資訊工具真正應該介入哪裡?

有些既有工具明明已經很好用,什麼時候應該直接沿用?

整理這個系列時,我把這種產品角色叫做:

「黏著劑」。

也就是去理解:

軟體到底應該黏在哪裡。

工程上,我則不斷碰到另一類問題。

一個做法現在可以運作,不代表需求增加之後仍然適合。

某個責任應該放在哪裡?

不同部分拆開之後要怎麼配合?

什麼條件不能被破壞?

最後又要拿什麼證據相信它真的成立?

我後來常把這一類問題簡化成:

邊界在哪裡。

Coding 能力對我來說,也逐漸不只是:

能不能從空白檔案把程式寫出來。

它還關係到我能不能閱讀程式、理解實作、找到問題、參與 Debug,以及繼續往下一層確認:

前面那些產品和工程判斷,最後到底有沒有真的被正確做進程式裡。

AI 則一直貫穿在這些事情中間。

它讓我更早開始做真正想做的東西,也讓我更快碰到原本可能還要很久以後才會遇到的問題。

所以這個系列真正想問的是什麼?

這個系列不是要證明:

不會寫程式也可以靠 AI 做軟體。

也不是要回答:

AI 會不會取代工程師。

我比較想整理的是另一件事:

當「先學會寫程式」不再是開始做產品的門檻,一個還在學習中的開發新手,會怎麼一路摸索自己到底還需要學會什麼?

而我的起點,就是那個:

做得出來,卻完全改不動的網站。

返回系列總覽 →