非本科系用 AI 寫程式，到底該學什麼？一個郵差的開發觀察 - Ward

我是郵差。日常工作跟程式碼沒有任何關係。

但這半年，我用 Claude Code 建了一套自己的開發系統——可行性判定閘門、品質透鏡、審查框架、hook 護欄、記憶管理系統——跑在本地伺服器上，cron job 定時抓氣象資料，Chrome Extension 已經上了 Chrome Web Store。

這不是在炫耀，是在描述一個起點：我沒有資工學位，沒有工程師職稱，沒有受過正統訓練。但現在我有一套自己能讀懂、能維護、能繼續長的開發框架。

這篇是我在走的過程中的觀察和反思，不是教學文。我想回答的問題只有一個：在 AI 可以幫你寫 code 的時代，像我這樣的人到底該學什麼？

---

先回答那個最直接的問題

「我需要回去念資工系嗎？」

不需要。但需要持續學觀念。

AI 已經取代了大量過去「念四年資工才能做的事」，同時製造了一個新的缺口——那個缺口是 AI 填不了的。

AI 已經能做的（不值得花時間學）	AI 做不到的（這才要學）
語法記憶、boilerplate	系統思維 — 東西怎麼壞的
基礎 debug 步驟	架構決策 — trade-off 的「為什麼」
API 用法查詢	模糊需求 → 明確規格
文檔撰寫、測試生成	安全直覺 — 知道哪裡會被攻擊
程式碼生成	判斷力 — AI 產出到底對不對

arXiv 2605.11027 把這個轉變命名為 intent-centric software engineering：從「以程式碼為中心」轉向「以意圖為中心」。¹ 重點不再是你會不會寫 for loop，是你能不能把想做的事講清楚，然後判斷 AI 做出來的東西對不對。

這個判斷力，不是天生的，不是跟 AI 用久了就自動長出來的。它需要刻意培養，而且有一套可以描述的學習路徑。

---

我的學習路徑：碰到才學，學完變成規則

我沒有在開始之前系統性地「學完 Python」或「學完軟體工程」。我的路徑更接近這樣：

碰到問題 → AI 幫我修好 → 我問「為什麼這樣修？」
→ AI 提到一個術語（比如 race condition）
→ 我追問「race condition 是什麼？」
→ AI 用我正在寫的 code 當範例解釋
→ 我理解了 → 把這個觀念寫成框架規則
→ 下次碰到類似問題，框架自動攔截

這個模式，在學習理論裡有兩個名字。

Just-in-Time Learning（即時學習） vs Just-in-Case Learning（以防萬一學習）。傳統教育走的是 Just-in-Case：先把所有東西學起來，以防萬一你以後用得到。問題是，大多數「以防萬一」的東西你永遠用不到，用到的時候也早忘光了。JIT 的邏輯相反：碰到了再學。AI 讓 JIT 真正可行，因為它可以即時成為你的家教，用你手上正在做的東西當教材。²

Constructionism（建構主義），MIT 的 Seymour Papert 在 1970 年代提出：人在「建造東西給別人看」的過程中學得最好，不是在聽講或閱讀的過程中。³ 用 AI 建一個實際跑起來的系統，就是建構主義的現代實踐。

把兩個結合：邊做邊學，碰到才學，學完變成規則，規則讓下次做得更深。

這個螺旋不是直線升級，它是迭代的——每一圈都比上一圈深一點，每一圈的「壁」都不一樣，每一圈都需要學新的觀念才能突破。

---

但這不是 vibe coding

這裡有個很重要的區別，我想說清楚。

Karpathy 2025 年定義 vibe coding：「順著感覺走、按 Accept All、不讀 diff、忘記程式碼存在。」⁴ 聽起來很爽，實際代價被量化了：

• 38–62% 的 AI 生成程式碼含安全漏洞 ⁵
• 7 起記錄在案的生產事故——API key 外洩、認證繞過、零點擊 RCE——全因缺乏安全原語 ⁶
• 研究發現 AI 使用者的自我評估顯著高於實際表現，而且 AI 識字率越高，過度自信越嚴重 ⁷

最後一點最反直覺：用 AI 越熟練的人，越容易高估自己。 這是 Dunning-Kruger 效應的 AI 版。

我的做法跟 vibe coding 的根本差別在於有沒有驗證。AI 說「改好了」不算完成，要實際跑過、回讀比對才算。這不是我多謹慎——是我被騙過幾次之後，被迫在框架裡建入強制驗證機制：寫入→讀取→比對，這個閉環缺一步就不算收尾。

驗證這件事，也有學習理論支撐。Schön 的「反思實踐（reflection-in-action）」描述的就是這個：真正的學習發生在行動中的反思，不是行動之後的回顧。⁸ 你在跑的過程中問「這樣對嗎」「AI 這樣做的原因是什麼」，那個問題本身就是學習。

按 Accept All 跳過了這一步。跳過就是快速遺忘。

---

開發的細膩度到哪邊，觀念就到哪邊

用 AI 開發大半年了，經過無數次實務驗證，我體會出這一句話。

你的框架能設計到什麼粒度，反映的就是你理解軟體到什麼深度。

這有點像東方禪宗說的——同樣的動作，在不同階段，內心的體會完全不同。

拿我自己做的事來說。我每天都在做同樣的動作：寫 CLAUDE.md 規則、跑 hook、問 AI 為什麼、把答案寫成框架。從第一個月到現在，動作沒變。但內心的理解，每一個階段都不一樣：

第一階段：照抄。 一開始我寫 CLAUDE.md，是看別人怎麼寫就照搬。「不要改沒有必要改的」「每次寫完確認」——這些規則對我來說只是文字，我知道要遵守，但不知道為什麼。就像禪宗初學者打坐，姿勢標準，心裡全是雜念。

第二階段：碰壁後理解。 幾次 AI 改了不該改的東西、幾次宣稱完成但其實沒改到——碰壁之後，那些規則突然有了重量。「不要改沒有必要改的」不再是一句話，而是一整個「blast radius」的觀念。我開始理解規則背後的「為什麼」，而不只是「是什麼」。就像禪修者不再刻意控制呼吸，而是開始覺察念頭本身。

第三階段：規則變直覺。 現在碰到一個新任務，我不需要翻 CLAUDE.md 去查對應的規則。我直覺知道「這個改動影響範圍大，先跑可行性判定」「這段 code AI 改得太順了，一定有問題」。規則已經內化成判斷力的一部分。動作一樣是寫規則、跑 hook、問 AI——但驅動這些動作的，不再是規則本身，而是理解。

禪宗有個公案叫「拈花微笑」——佛陀拈花，大迦葉微笑，以心印心，不立文字。同樣一朵花，百萬人看到的是花，大迦葉看到的是法。同樣一條 CLAUDE.md 規則，初學者看到的是限制，走過三個階段的人看到的是觀念的結晶。

一開始我的「框架」就是 CLAUDE.md 裡幾條規則。後來碰到的問題越來越複雜——怎麼判斷該不該做（可行性閘門）、怎麼確保改 A 不壞 B（影響範圍分析）、怎麼在 context 壓縮後不丟重要資訊（記憶系統）——框架就跟著長出來。不是我在設計框架，是問題在逼框架長出來。

每一個框架的長出來，都對應一次「我碰到一個問題，然後搞懂了一個觀念」。

這個過程在知識管理領域有理論支撐。Nonaka 的 SECI 模型（1995）描述知識的四種流動：社會化（分享）→ 外化（說出來/寫下來）→ 組合（整合成系統）→ 內化（變成直覺）。⁹ 我走的路線是：

1. 碰壁（有隱性知識的需求）
2. 問 AI 搞懂（知識由外部流入）
3. 把理解寫成規則（外化——把腦子裡的隱性知識變成顯性的機器可讀規則）
4. 框架跑起來驗證過（組合）
5. 下次同類情境直覺反應（內化）

2025 年的論文 arXiv 2603.14805 把這叫做 Knowledge Activation，並提出一個觀點：「每次 AI 不懂你的規則，你就要即時外化一次隱性知識——這正是 CLAUDE.md 存在的根本原因。」¹⁰

所以寫 CLAUDE.md 不只是設定檔管理。那是你的知識外化過程。 你寫進去的每一條規則，都代表你曾經內化了某個觀念，然後把它轉換成機器可以執行的格式。CLAUDE.md 有多精細，你的軟體觀念就有多深。

---

Boris 五層和我的位置——螺旋 vs 線性

Claude Code 的創造者 Boris Cherny 在 2026 年發布了 AI 採用五層模型：¹¹

層	角色	核心動作
L0 Gated	—	AI 被流程卡住，完全沒用到
L1 Assisted	你 + 1 agent	配對程式設計，每行都看
L2 Parallel	指揮官	多 agent 平行，Auto mode
L3 Supervised autonomy	管理者的管理者	Claude 寫幾乎所有 code
L4 AI-native	VP 導航	靠意圖和例外管理

這個模型設計的假設是：使用者本來就是工程師，AI 是他效率的倍增器，L4 的判斷力是既有存量。

但我的情況多了一條他沒畫的軸：判斷力本身也在成長。

我現在大概在 L2–L3 之間——可以同時跑多個子任務，讓 AI 自主做不少工作，自己在更高層做裁決和驗證。但我不是從既有的 L4 判斷力往下帶動 AI，我是跟 AI 一起、在做的過程中，把判斷力長出來。

這不是線性的 L1→L2→L3→L4，而是一個螺旋：

做 → 碰壁 → 問為什麼 → 學到觀念
→ 觀念變成框架規則 → 框架讓下次做得更深
→ 更深碰到更深的壁 → 再問為什麼 → ...

這跟 Kolb 經驗學習循環（1984）對應：具體經驗 → 反思觀察 → 抽象概念化 → 主動實驗 → 再循環。¹² AI 加速了每一步。但反思那一步不能跳過——跳過了，剩下的就是 vibe coding。

有一個直接佐證。2026 年的控制實驗發現，用 AI 配對程式設計的初學者，分數比對照組高了 14 分。但一週後重測，知識保留顯著更差。論文標題很直接：Fast and Forgettable。¹³ 做得快但沒反思 = 快速遺忘。

速度是 AI 帶來的，但學到什麼，還是要靠你自己決定要不要停下來想一秒。

---

ZPD：AI 作為認知鷹架

Vygotsky 的近側發展區（Zone of Proximal Development）：人在「靠自己差一點到、有人幫一把就到」的區間學得最好。那個「幫一把」的角色叫 MKO（More Knowledgeable Other）——傳統上是老師、師傅、更有經驗的同事。

AI 可以扮演這個角色。2025 年一篇系統回顧整理了 158 篇實驗研究，確認 AI 可以作為 MKO，在每個人的近側發展區即時提供鷹架：解釋你剛好需要的觀念，用你正在做的任務當例子，在你卡住的地方給提示，不在你已經懂的地方囉嗦。¹⁴

這是 AI 作為學習工具最強的地方：個人化的即時鷹架。傳統教室的老師是對全班說話的，AI 是只對你說話的。你的問題是什麼，它就解釋什麼。你不懂的程度在哪裡，它就從哪裡開始。

但也有一個嚴重的警告。

arXiv 2511.12822 提出「零發展區（Zone of No Development）」：如果你完全依賴 AI 而不自己思考，你就不是在近側發展區了——你在一個什麼都沒學到的舒適區。¹⁵

零發展區的特徵很好辨認：看到問題，直接丟給 AI，看 AI 修好，繼續往前。你沒有問「為什麼」，沒有確認自己理解了，只是讓 AI 把洞補起來，然後繼續踩下一個洞。

近側發展區和零發展區的差別只有一件事：你有沒有問「為什麼」。

按 Accept All = 零發展區。問「為什麼這樣修」再把答案寫成規則 = 近側發展區。同樣都在用 AI，學習效果天差地別。

---

JIT 的盲區：你不知道你不知道什麼

JIT 學習有一個結構性的弱點，我自己花了很長時間才意識到。

你只會問你知道要問的問題。

Rumsfeld 矩陣的 Unknown Unknowns——你不知道你不知道的東西——是 JIT 抓不到的。你不會問 AI「幫我檢查 race condition」，如果你連 race condition 這個概念都沒聽過。你不會問「這段 code 有沒有 SQL injection 風險」，如果你不知道 SQL injection 是什麼。

這也是 vibe coding 7 起生產事故的共同根源：不是 code 寫錯，是開發者根本不知道要防什麼。⁶ AI 按照給定的需求生成了符合需求的程式碼，但需求本身就缺了安全考量——因為開發者的認知地圖上沒有那個角落。

我的做法是用框架來補這個盲區。框架的核心功能之一，就是在你動手之前強制問你一些你自己不會想到的問題。可行性閘門裡有一條：「有什麼安全風險你沒有考慮到？」修補判定框架裡有一條：「改了這裡，哪些你不知道的地方可能受影響？」

你自己不知道要問，但框架知道——因為框架是從過去無數次「事後才知道應該問」的 LESSON 長出來的。

2026 年有人整理了讓 AI 幫你挖掘盲區的方法：Blind Spot Pass、Adversarial Interviews、Assumption Quizzes 等。¹⁶ 核心洞見是：「你的 prompt 只代表你的理解地圖，但真實的系統有地圖不覆蓋的複雜性。」不是讓你更聰明，是讓你有一個機制強迫自己問出超出理解地圖的問題。

框架扮演的就是這個角色。

---

反思不能跳過

我想在這裡特別說一件事，因為這是最容易被忽略的。

Schön 的反思實踐（reflection-in-action）說的是：真正的學習發生在行動中，不是行動之後。你在寫 code 的時候問「這樣做的理由是什麼」「AI 為什麼這樣選擇」——那個當下的疑問，就是學習的時刻。⁸

但現代的 AI 工具讓「不反思」變得極其容易。速度快、摩擦少、每一個 Accept 都像在說「這樣就好了，繼續往前」。累積下來，你做了很多事，但沒有真正學到什麼。

Fast and Forgettable 那篇論文的發現，我覺得值得重複說一次：AI 輔助程式設計讓初學者在當下表現好了 14 分，但一週後知識消退得更快。¹³ 速度和學習之間有一個隱藏的張力——AI 幫你把速度拉上去了，但學習還是需要你自己的反思來鞏固。

我的做法是把反思強制寫進流程。碰到一個新術語，追問。AI 修了一段 code，問為什麼這樣修。搞懂了一個觀念，把它寫成 CLAUDE.md 規則或記憶筆記。這不是額外的工作，這是讓學習實際發生的必要步驟。

---

真正的驅動力：好奇心和愛提問

到這裡你可能發現了——上面講的所有東西（JIT 學習、Constructionism、反思實踐、知識外化）都有一個共同的前提：你要先問。

不問，就沒有落差。心理學家 George Loewenstein 1994 年提出的 Information Gap Theory 說得很清楚：好奇心不是性格，是一種認知上的落差感——你知道一點，但不夠多，那個「不夠多」的感覺會像飢餓一樣驅動你去填補。¹⁷ fMRI 研究甚至證實，這個落差感會激活大腦的尾狀核，也就是動機與獎勵中樞。¹⁸

聽不懂術語，就是落差。問 AI「這個 race condition 是什麼意思？用我聽得懂的白話文說」——那個當下，落差被填補，觀念就內化了。不是死背定義，是理解這個詞在你正在做的事情裡到底代表什麼。維根斯坦說過，語詞的意義由它的「使用方式」決定，不是由字典上的定義決定。¹⁹ 問 AI 用白話翻譯術語，就是在學習這個術語在真實脈絡中怎麼被使用。

這種活的學習，比教科書有趣、比死背更深、比課堂更持久。

因為你是帶著「想知道」去問的。不是因為考試要考、不是因為學分要修。你碰到了一個問題，你想搞懂它，你問了，你懂了，你把答案寫成規則讓下次不用再問。這整個過程是你自己驅動的，不是課綱驅動的。

MIT Sloan 的 Hal Gregersen 研究了 200 多位頂尖創新者後得出結論：他們的共同特質不是知識量，是問出催化性問題的能力。²⁰ 2025 年 MIT 的執行教育課程直接以此為主題：「AI 時代領導力中 AI 取代不了的那個技能——問出更好的問題。」

這跟畢業就停止學習是完全相反的心態。

Carol Dweck 在 Stanford 的研究把這叫做 Growth Mindset vs Fixed Mindset。²¹ Fixed Mindset 認為能力是固定的——書讀完、證書領了、畢業了、學習終止。Growth Mindset 認為能力可以透過努力增長——畢業不是終點，是另一段學習的起點。Fortune 2026 年 7 月的文章直接點名這個現象叫「文憑陷阱」（credential trap）：學生理性地優化學歷而非知識，結果 AI 一來，學歷作為能力代理的功能直接崩潰。²²

如果你停止好奇、停止提問，你的 AI 能力也到盡頭了。

因為你只能去看別人分享的提示詞，複製貼上，當 copy cat。LinkedIn 上已經有人在批評這種「Copy-Paste Prompt 文化」的危險：你買了別人的問題框架，但你永遠學不到怎麼自己提問。²³ 提示詞市集的賣家提供的是「問題的商品化」，買家得到的是答案，但失去的是提問的能力——而提問才是那個最值錢的東西。

亞里士多德在《形上學》開篇第一句話就是：「所有人天生渴望知識。」²⁴ 兩千四百年前就說了。好奇心不是後天培養的習慣，是人類存在的根本屬性。AI 沒有好奇心。它回答問題，但它不會主動提問。你會。這就是你和它的根本差距。

---

把問題切細切小

有了好奇心和提問的習慣之後，下一個要學的是：怎麼拆問題。

你會問、你會想，這很好。但一個問題，有時候是好幾十個工作步驟才能完成的。你腦子裡想的是「我要一個能定時抓氣象資料的系統」，但這句話背後是：API 怎麼呼叫、資料格式怎麼解析、存到哪裡、錯誤怎麼處理、cron 怎麼設定、log 怎麼看——每一個都是獨立的小問題，而且它們之間有先後順序、有相依性。

你一口氣把整個大問題丟給 AI，它可能會給你一個看起來能跑的東西。但如果你的 spec 不夠精準——非本科系的人，spec 通常不會精準，因為你不知道有哪些細節需要講清楚——AI 產出的東西就會是「大方向對但細節全歪」。

切細切小，是讓工作能夠細膩化、專注化的關鍵。

一次只做一件事。先把 API 呼叫搞定，確認資料拿得到。再處理解析格式。再處理儲存。再處理錯誤。再處理排程。每一步都驗證過才走下一步。這樣你不只是在「做完一個系統」，你是在每一步都搞懂一個觀念。

但非本科系的人，一開始不知道怎麼拆。你不知道一個「系統」到底包含哪些步驟、哪些步驟有先後、哪些可以平行。這很正常——拆問題本身就是一種觀念，需要練習才會。

這時候就是讓框架上場的時候。

讓 AI 幫你拆。你說出你想做的事，請 AI 列出步驟、標出相依性、排出執行順序。然後你看：這是不是你想要的方向？切得對不對？是不是你想要的目標？不對就告訴它哪裡不對，讓它重拆。這個「拆→看→回饋→再拆」的循環，本身就是在學習怎麼拆問題。

幾次之後你會發現，你自己開始會拆了。不用 AI 列步驟，你腦子裡已經自動在分解。這跟前面說的禪宗三階段一樣——一開始照 AI 拆的做，後來理解為什麼這樣拆，最後拆問題變成直覺。

有人會問：「那幹嘛不去念個幾年書，把電腦科學的精華學完？」

你可以。但非本科系的人要花多少時間才能追上本科四年的基礎？而且你真的需要全部嗎？你需要的可能只是其中 5% 跟你正在做的事直接相關的觀念。AI 吐出一個術語——比如 dependency injection、race condition、idempotency——你不用花一學期學完整門課，你只要問 AI「這是什麼？用我正在做的專案當例子解釋」，十分鐘就懂了。

這就是重點式學習。AI 是你的術語天書翻譯機。它把那些看起來很深的觀念，用你聽得懂的白話文、用你正在做的東西當範例解釋給你聽。你不需要讀完一本教科書才能理解一個觀念——你只需要在碰到它的當下，花十分鐘搞懂它。

做中學，比讀中學快。而且記得住。

因為你是帶著真實的問題去學的。那個觀念不是考卷上的填充題，是你昨天踩到的坑。這種記憶比任何教科書都深。

---

那 PhD 才會的東西呢？

有人在社群上提了一個我覺得很值得回應的觀點。

大意是這樣的：AI 再厲害，有一件事只有 CS 專業能做——驗證程式正確性。他舉的例子是 TLA+，由 2013 年圖靈獎得主 Leslie Lamport 設計的形式化驗證工具，可以在程式碼寫完之前，用數學方法證明演算法在所有可能的執行路徑下都是正確的。AWS 用 TLA+ 驗證了 S3、DynamoDB 等核心系統，7 個團隊都找到了用其他方法找不到的嚴重 bug。²⁵ 這位作者自己也說，他是讀了 PhD 才知道有 TLA+ 這種東西。

然後他話鋒一轉：現在可以用 Claude Code 讀程式碼，自動產出 TLA+ 規格，不用自己手寫了。

我看完覺得很有意思。因為他的結論其實跟他的論點打架了。

他想說的是「CS 專業不可取代」，但他舉的例子剛好證明 AI 正在把這種 PhD 等級的工具降低門檻。有人已經實際示範了一個三層流程：用 TLA+ 寫形式化規格 → 用 model checker 跑出所有可能的 violation → 再讓 Claude 根據規格實作程式碼。²⁶ 整個流程的結論是「從感覺驅動寫程式，變成規格驅動寫程式」——這不就是 AI 把 formal verification 從象牙塔拉到地面的過程嗎？

但我不是要說 TLA+ 不重要。我要說的是：你需要什麼程度的驗證，取決於你在做什麼。

你在做什麼	你需要的驗證	不需要的
興趣專案 / 土炮 POC	基礎安全意識 + 測試	TLA+、CS 學位
領域需求（像我的 EEBot）	+ 架構思維 + debug 能力	四年 CS
做產品給別人用	+ 安全審計 + 效能	PhD
分散式系統 / 金融 / 醫療	formal verification 等級的正確性保證	但 AI 能降低門檻

我寫的東西，不需要 TLA+。我需要的是「AI 說改好了，我回讀一次確認真的改了」——這是最基礎的驗證，但大多數 vibe coding 的人連這一步都跳過。

而真正在做分散式系統的人，的確需要更重的武器。但那個武器的門檻，正在被 AI 壓低。這跟前面說的 JIT 學習是一樣的邏輯：你不需要先花四年學完所有驗證方法，你需要在碰到「這個系統的正確性很重要」的時候，知道有 TLA+ 這種東西，然後讓 AI 幫你跑。

有一個量化數據值得放在這裡。2026 年的統計顯示，62% 的 AI 生成程式碼含安全漏洞，40% 的 vibe coding app 暴露了敏感資料，63% 的使用者是非開發者。²⁷ 這些數字說的不是「你需要念 CS」，是「你需要驗證」。而驗證有很多層次——從「跑一次看結果對不對」到「用形式化方法證明演算法正確」。你站在哪一層，取決於你在做的東西有多大的後果。

我的結論跟文章開頭一樣：你不需要回去念四年。但你需要知道，在你做的東西的那個複雜度，驗證長什麼樣子。然後學會在那個層次做驗證。

這件事，AI 可以教你。但按 Accept All 的人永遠不會問到這一層。

---

框架怎麼長出來的

寫到這裡，我想回頭說一件事：我的那些框架——可行性閘門、修補判定、品質透鏡——不是一開始就設計好的。它們是從碰壁裡長出來的。

每一個框架的出生都是同一個模式：

同一類問題碰了兩三次
→ 問「為什麼又發生」
→ 找到一個觀念能解釋它
→ 把觀念寫成規則
→ 規則用久了，長成框架

這個模式本身也是一個框架。而且它不只適用於寫程式。

我做天氣週報的時候，也在走同樣的迴圈：碰到「這次忘了報空品」→ 寫一條規則「紅害季節必查 PM2.5」→ 規則累積成 checklist → checklist 變成 runbook。寫 blog 也是：碰到「引用來源不存在」→ 寫一條「引用必須先 fetch 確認」→ 規則變成查證流程。

所以「建框架」不是一個只有工程師才做的事。任何領域的人，只要願意在碰壁之後多問一句「為什麼」，就會自然走上這條路。

但這裡有一個陷阱我花了很久才意識到。

框架越多，組合起來的認知負擔越大。12 套框架，每次做事之前要想「這次該用哪幾個」——這本身就變成一種決策負擔。研究顯示，決策疲勞會降低判斷品質，而框架本來是為了提升判斷品質設計的。框架太多反而把判斷品質拉回去，這是一個我沒預料到的對稱失敗。

解法不是「少用框架」，是找到框架底下的共同根基——讓你不用查 12 套框架，只需要問幾個根本問題。

---

五條第一性原則

我把所有框架的規則攤開，對每一條問「這條在保護什麼？」，一直往下剝，剝到不能再剝。

結果所有框架都回到五件事：

P1 — 你不知道你不知道什麼。

你的理解永遠是局部的。你看不到的地方不代表沒有問題。這就是為什麼需要發散搜尋（TDC）、需要盲點檢查、需要讓別人（或 AI）幫你看你的死角。

P2 — 做了就回不來。

有些行動可以撤銷，有些不行。不可逆的改變需要更多的事前確認。這就是可行性閘門（EFG）存在的原因——如果所有行動都能 Ctrl+Z，不需要事前判定。

P3 — 碰一個，動一片。

系統裡的東西互相連接。改 A 可能壞 B，而你不知道 B 在哪。這就是為什麼改 code 之前要看影響範圍（blast radius），為什麼安全漏洞特別危險——它的擴散路徑是你看不到的。

P4 — 你以為的不一定是真的。

你的判斷、AI 的輸出、工具的回報，都可能是錯的。「完成了」是一個需要驗證的宣稱，不是一個可以信任的回報。這就是我花最多時間建的那個閉環：寫了就讀、讀了就比、比了才報。

P5 — 你能做到什麼，取決於你理解到什麼深度。

AI 放大你的執行力，但不放大你的理解力。理解力只能靠「碰壁→追問→內化」的迴圈來長。這就是前面整篇文章在說的事——你不需要念四年資工，但你需要在碰壁的時候停下來問為什麼。

---

五個問題取代十二套框架

有了這五條，以後碰到任何問題——不管是寫程式、做天氣報告、還是寫文章——不用翻框架表，問五個問題就好：

問題	如果答案是「是」
我有沒有可能漏看了什麼？	先搜尋再動手
做錯了後果嚴重嗎？	先判定再執行
這個改動會波及哪裡？	先看影響範圍
我怎麼知道結果是真的？	做完要驗證
我理解這件事的深度夠嗎？	不夠就先學

五個問題，五秒鐘。²⁸

那 12 套框架是什麼？是這五個問題的展開版——當你回答「是」之後，框架告訴你具體怎麼處理。但入口只需要五個問題。

Addy Osmani 在 Google 的工程實踐文章裡寫過，第一性原則思維就是「把問題分解到最基礎的組成部分，從那裡開始推理，而不是從慣例或類比出發」。²⁹ 我走的路徑是反過來的——先從慣例（碰壁→寫規則→建框架）出發，累積到一個程度之後，再往回剝到第一性原則。但結果是一樣的：你最後手上拿的是幾條不能再簡化的真理，其他都是衍生。

這也是為什麼「學觀念」比「學框架」重要。框架會過時——工具換了、問題變了、你的判斷力成長了，框架就該退場。但 P1 到 P5 不會過時。「你不知道你不知道什麼」這件事，不管 AI 進步到什麼程度，對人類永遠成立。

---

五個給同路人的建議

如果你也是非本科系在走這條路，我的建議是：

1. 不要只按 Accept All

看 diff，問為什麼。不是每一行都要問，但遇到你不懂的地方，停下來問。至少要能用自己的話解釋「這段 code 在幹嘛」。能解釋 = 學到了。不能解釋 = 工具幫你過了這一關，但你還是卡在原地。

2. 學會拆問題，不學語法

AI 的執行力很強，但它需要你把大問題拆成小問題。「做一個系統可以自動抓資料」是大問題，AI 拿到這句話產出的東西通常不是你要的。「寫一個 Python 腳本每小時呼叫這個 API，把回傳的 JSON 存進 SQLite，如果 API 連線失敗就記 log」是小問題，AI 做得到。學會拆，比學語法更值錢。

3. 把學到的觀念寫下來

CLAUDE.md、筆記、任何形式都可以——外化比記住重要。你現在記住的觀念，三個月後可能忘了一半。但你寫下來的規則，三個月後還在、還會被框架執行。知識外化是把隱性知識變成顯性資產的唯一方式。

4. 建驗證機制，不是靠信任

不是你信任 AI，而是讓機制替你驗。Hook 強制閉環、框架的閘門條件、AI 說「完成了」就一定要回讀比對——這些機制讓你不需要每次都靠自己的判斷力，因為判斷力會疲勞，機制不會。

5. 定期問「有沒有我沒想到的風險」

這一題不是你能自己回答的——如果你知道那個風險，你早就想到了。你需要一個外部視角。可以問 AI，可以問框架，可以跑 adversarial pass。重點是把「問出盲區」這件事，從偶爾想到才做，變成每次動手前的例行步驟。

---

這算脫離傳統學習典範嗎？

是的，但有限定詞。

傳統：先學四年理論 → 再去實作（Just-in-Case）。

這個路徑：直接實作 → 碰到問題才學觀念 → 觀念內化成框架 → 框架指導下一次實作（JIT + Constructionism 螺旋）。

脫離的是「傳統教學典範」，沒有脫離「學習」本身。

你還是在學。只是學的東西從「語法和 API 用法」變成「系統思維和問題拆解」。學的方式從「坐教室聽四年」變成「做的過程中碰壁、反思、外化成規則」。

有一件事我很確定：觀念的深度決定開發的深度。你能想到的設計，上限就是你理解的上限。AI 可以幫你執行，但它執行的是你提出的問題——問題的品質，還是取決於你的理解。

所以學什麼？學問題。學拆問題的方式。學判斷 AI 答案的觀念基礎。學在不確定的時候知道自己不確定、然後去補那個缺口。

這些東西，沒有資工學位也能學到。郵差也能學到。

---

引用來源

---

免責聲明 本文為個人使用觀察與公開資料整理，僅供技術交流與學習方法討論參考。文中提及的學習理論、研究數據、工具功能均以撰文時（2026-07-21）公開資料為準。

每個人的學習路徑、背景知識、可投入時間不同，本文描述的方式不一定適用於所有人。AI 輔助開發有其固有風險（安全漏洞、品質問題、認知偏誤），使用者應自行評估並建立適合自己的驗證機制。

任何人依據本文內容所做的學習決策、工具選擇或開發方式調整，其結果由決策者自行承擔。

Footnotes

1. arXiv 2605.11027 — From Code-Centric to Intent-Centric Software Engineering ↩

2. From Just-in-Case to Just-in-Time Learning — Medium/AgenticAIs ↩

3. Papert’s Vision Realized: Constructionism and Generative AI — ResearchGate ↩

4. A Semantic History: How Vibe Coding Went From a Tweet to Prod — CodeRabbit ↩

5. Vibe Coding Security Statistics 2026 — vibeappscanner.com ↩

6. 7 Real Vibe Coding Failures — Autonoma ↩ ↩²

7. AI is a Dunning-Kruger Equalizer — ThinkPol ↩

8. Schön, D. A. (1983). The Reflective Practitioner: How Professionals Think in Action. Basic Books. ↩ ↩²

9. Nonaka, I., & Takeuchi, H. (1995). The Knowledge-Creating Company. Oxford University Press. ↩

10. Knowledge Activation: AI Skills as the Institutional Knowledge Primitive — arXiv 2603.14805 ↩

11. Boris Cherny — Steps of AI Adoption（claude.ai artifact） ↩

12. Applying Kolb’s Experiential Learning Cycle — ScienceDirect 2025 ↩

13. Fast and Forgettable: AI-Assisted vs Human Pair Programming — arXiv 2604.18538 ↩ ↩²

14. AI as a Digital Scaffold: Integrative Review of Vygotsky’s ZPD — gaexcellence.com ↩

15. The Unspoken Crisis of Learning: Zone of No Development — arXiv 2511.12822 ↩

16. Let AI Help You Uncover Unknown Unknowns — Medium ↩

17. Information Gap Theory — Psychology Fanatic（Loewenstein, 1994） ↩

18. The Psychology and Neuroscience of Curiosity — ScienceDirect（Kang et al., 2009 fMRI 研究） ↩

19. Wittgenstein, L. (1953). Philosophical Investigations. Blackwell.（語言遊戲理論：語詞的意義由使用方式決定） ↩

20. The Leadership Skill AI Can’t Replace: Asking Better Questions — MIT Sloan（Hal Gregersen） ↩

21. Dweck, C. S. (2006). Mindset: The New Psychology of Success. Random House. ↩

22. AI Didn’t Kill Higher Education — It Exposed the Credential Trap — Fortune（2026-07-07） ↩

23. The Hidden Danger of Copy-Paste Prompt Culture — LinkedIn Pulse ↩

24. Aristotle. Metaphysics, Book I, Chapter 1.（「所有人天生渴望知識。」） ↩

25. How Amazon Web Services Uses Formal Methods — Communications of the ACM（7 個團隊使用 TLA+ 驗證分散式系統，全部找到嚴重 bug） ↩

26. Beyond Vibe Coding: Using TLA+ and Executable Specifications with Claude — Medium（三層流程：TLA+ 規格 → model check → Claude 實作） ↩

27. Vibe Coding Security Statistics 2026 — OX Security / ACM TechBrief: Vibe Coding Lacks Key Safeguards（62% 漏洞率、40% 暴露敏感資料、63% 使用者為非開發者） ↩

28. Frontiers in Cognition — Decision Fatigue Integrative Review 2025（決策疲勞降低判斷品質）/ arXiv 2601.08045 — Cognitive Biases in LLM-Assisted Software Development（14 名開發者 2,013 個 AI 互動中的認知偏誤量化） ↩

29. Addy Osmani — First Principles for Software Engineers（Google 工程實踐：從基本原則推理，不從慣例出發） ↩