「已經不需要程式設計技能」論的對應

恐怕那其實不是指「程式設計技能」。
或者說，這可能只是「程式設計技能」這個詞定義的問題。

實際上很多人會把它想成 Python 的語法、JavaScript 的框架、SQL 的查詢結構 —— 換句話說就是對特定語言的語法知識。正因如此，在代碼代理（coding agent）盛行的時代，語法知識的重要性相對下降……這個觀點我是同意的。

那麼「程式設計技能已經不需要了」嗎？
那完全是錯誤的。

即便是用自然語言來指示 AI，如果沒有程式式的思考能力，也無法下出正確的指示。換句話說，無論是否使用自然語言，所做的本質上仍然是「程式」，而寫作者需要具備「程式設計技能」。

這裡所說的「程式設計技能」並不是語法知識，而是以計算思維（Computational Thinking, 以下 CT）為首的各種技能。

本文作為我自己的筆記，整理了關於「AI 時代的程式設計教育」以及「AI 時代所需技能」的調查內容，盡量避免淪為純粹主觀感想，並參考學術研究與各類文章進行描述。

三行重點摘要

• 「程式設計技能不重要」的論述，多半在談語法知識；但計算思維（Computational Thinking）仍然必要
• 用自然語言指示 AI 的行為本質上也是一種程式設計，仍需問題分解、抽象化、模式識別、流程設計等思維能力
• 把工作全部交給 AI 會阻礙技能成長。應把 AI 當作「思考的夥伴」，並主動參與以促進學習與判斷能力

「自然語言是最熱門的程式語言」

2023 年，OpenAI 創辦成員之一 Andrej Karpathy 曾說過：

The hottest new programming language is English.
（最熱門的新程式語言是英語）

這句話有時會被引用來支持「已經不需要學程式了」的說法。但其真正含意是相反的：它表示自然語言已能作為程式語言來運作，使用自然語言的一方也需要具備程式式的思維。

Schmidt & Runfola（2025 年）在論文 "Liberating Logic in the Age of AI" 中，以學術形式支持了這種變化：

What matters is no longer just fluency in traditional programming languages but the ability to think computationally by translating problems into forms that can be solved with computing tools.

（重要的已不僅是傳統程式語言的流利度，而是能以計算方式思考，將問題轉換成可由運算工具解決的形式）1

該論文也把提示工程（prompt engineering）的本質描述為：

Prompt engineering came to be understood as programming through the AI, rather than programming the AI.

（提示工程逐漸被理解為「透過 AI 來進行程式設計」，而非「對 AI 進行程式設計」）

雖然我對「提示工程」這個詞還有一些想法（可另文詳述），但重點在於：即便看起來是在用自然語言下指令，實際上做的事情本質仍是程式設計。

計算思維（Computational Thinking，CT）是什麼？

那麼，不是語法知識的「程式設計技能」具體是哪些能力？
其中一部分的答案就是計算思維（Computational Thinking，以下簡稱 CT）。

根據 BBC Bitesize 的定義，CT 有四個支柱2：

• Decomposition（分解）：把複雜問題拆成較小且易於處理的部分
• Pattern Recognition（模式識別）：找出問題內或問題間的相似性
• Abstraction（抽象化）：只聚焦重要資訊，忽略無關細節
• Algorithms（演算法設計）：為解決問題設計步驟化的流程

CT 是「把問題轉換成可被電腦解決的形式」的思考方式，獨立於特定程式語言。這些能力同樣適用於向 AI 下指令的情況。

（原文附有圖示，出處同上）

在 AI 編碼中的 CT 必要性

下面用具體例子說明 CT 的四個支柱在 AI 協作開發中如何發揮作用。

Decomposition（分解）

若只是對 AI 說「請幫我做一個電商網站」，與把工作細分成下面這類步驟，得到的成果品質會截然不同：

1. 設計商品資料的 schema
2. 建立商品列表 API 的端點
3. 實作購物車功能的 state 管理
4. 實作付款流程的驗證

把大問題以適當粒度拆解的能力，對 AI 與對人類團隊成員同樣重要。若分解不當，AI 會對模糊指示作出「大概上可行」的解讀，但結果可能不是你想要的。

此外，從需求規格（使用者端的規格）到功能規格（實作端的規格）的落地方式有很多種，選擇哪種實作不應完全交給 AI 去決定。人類需要檢視並回饋，這就要求具備外層的知識：知道可以有哪些分解元素、具備設計分解的知識與理解。

欄外：如何應對 token 限制 / 內容壓縮

我個人認為，在現階段的編碼代理與生成式 AI 的能力下，Decomposition 技能是最被考驗的一項。

原因在於現有模型的資源限制（例如 token 上限），在較大的專案中幾乎必然會發生「上下文被壓縮」的情況。這會導致程式中不應該遺失的細微差異被省略，成為 bug 或回歸（regression）的溫床。

透過分解與模組化設計，將對話切成多個執行緒或讓每個模組保持自洽的上下文，可以在一定程度上避免在上下文壓縮時出現的錯誤或回歸。我在這裡是基於經驗的觀察，尚未有實證研究完全支持此點，但實務上是值得注意的策略。

Abstraction（抽象化）

提示（prompt）的抽象程度如果太低或太高，都會出問題：

• 抽象度太低：逐條指定實作細節 → 無法發揮 AI 的強項
• 抽象度太高：「隨便做得好看點」→ 結果可能與預期大相逕庭

像是「需要認證、使用 JWT、refresh token 的有效期限為 7 天」這類只描述本質需求且適度粒度的表述，是良好抽象化的範例。這不僅需要 Abstraction 技能，也仰賴背後的領域知識。

Pattern Recognition（模式識別）

在一個 API 端點出現的問題，與另一個 API 出現的問題，看出它們的共通結構；辨識 CRUD 操作中的共通模式，並基於過去相似問題的解法導出有效解法。

能夠看穿問題間的相似性，是有效利用 AI 的基礎。不過若個人知識庫（所謂的「抽屜」）不夠豐富，這種模式識別的效果也會大打折扣。

資深工程師通常會憑藉豐富的「引經據典」瞬間辨識出相似問題，因此培養「引擎」數量（經驗）與在引擎內做類似搜索的能力都很重要。

Algorithms（演算法設計）

「先執行資料庫 migration，接著灌 seed 資料，然後再測試 API 端點」——若依賴關係或順序設計錯誤，即便每一步都正確，系統仍可能無法運作。

即便 AI 能產出個別零件，如何把這些零件按照正確順序與相依關係組合起來仍屬 CT 範疇。若對各零件的概念不夠理解，也無法正確下指示。

當然，對於一些通用或既定流程，AI 可以補完缺失的指令；但若完全交由 AI 決定 UI 行為或仕様控制，會導致產品基於 AI 的「最適值偏好（亦即常見價值觀）」而非人類設計者想要的差異化價值觀。

Sarah Chasins 教授的觀點：結構化能力

加州大學柏克萊分校（UC Berkeley）電腦科學教授 Sarah Chasins 在 YouTube 演講中強調，即便使用 AI 工具，對問題進行「結構化（structuring）」的能力依然不可或缺3。

Chasins 實驗室（PLAIT Lab）所開發的工具體現了這個理念。以為實驗生物學者設計的程式生成工具 Honeybee 為例，使用者需將（i）實驗做了什麼、（ii）產生了哪些資料、（iii）需要什麼分析／視覺化，這些資訊「結構化地」描述出來。換言之，即便 AI 會產生程式碼，使用者仍需能把問題結構化4。

另外，Jayagopal、Lubin、Chasins（2022）研究了程式合成工具對程式初學者的可學習性，指出即使有 AI 工具存在，使用者仍需基本的程式式思考能力5。

Chasins 的研究使命可以用她的話來表述：

To make programming a path to a more informed and evidence-driven society — not just a way to get wrong answers faster.

（把程式設計建構成通向一個更多依據證據、資訊相對充分社會的路徑——而不是只是一種「更快得到錯誤答案」的手段）4

使用 AI 的人會分成兩類：一類是「更快得到錯誤答案」的人，另一類是能運用 AI 並到達正確結論的人。這兩者之間的差異，很大程度來自於是否具備 CT。

證據①：AI 使用會阻礙技能形成（Anthropic 的研究）

接下來介紹四項證據研究。

Shen & Tamkin（2026）代表 Anthropic 進行了一項隨機對照試驗（RCT），招募了 52 名（主要為初階）軟體工程師，讓他們完成以 Python 非同步處理函式庫 Trio 為背景的編碼任務，並分成有 AI 輔助組與無 AI 輔助組；任務完成後進行 mastery quiz（熟練度測驗）6。

結果

重點發現是：AI 群在 mastery quiz 的平均分數比對照組低 17%（Cohen's d = 0.738，p = 0.01）。這相當於約兩個成績等級的差距。特別是在「除錯（debugging）」相關題目的差距最大，也就是說：辨識並修正 AI 產生程式碼錯誤的能力——這在 AI 時代最重要的技能之一——在 AI 群中受損最明顯。

AI 使用的六種模式

這篇研究對 AI 使用行為做了質性分析，發現了不同的使用模式，且與測驗成績有關。

低分模式（認知性外包／delegation）：

• AI Delegation：把所有事情都交給 AI，速度最快，但平均 quiz 分數低於 40%
• Progressive AI Reliance：起初自己寫，但逐漸依賴 AI，平均 quiz 分數低於 40%
• Iterative AI Debugging：自己寫程式，但每次 Debug 都交給 AI，平均 quiz 分數低於 40%

高分模式（主動參與）：

• Generation-then-comprehension：先讓 AI 生成程式碼，之後問「為何會這樣」等理解性問題，平均成績 ≥ 65%
• Hybrid code-explanation：同時要求生成程式與說明，閱讀說明並理解，平均成績 ≥ 65%
• Conceptual inquiry：只向 AI 詢問概念性問題，自己寫程式，平均成績 ≥ 65%

論文清楚指出：

Productivity benefits may come at the cost of skills necessary to validate AI-written code if junior engineers' skill development has been stunted by using AI in the first place.

（若初階工程師因使用 AI 而阻礙技能發展，生產力的提升可能建立在失去驗證 AI 所寫程式碼所需能力的代價上）

總之就是「會更快，但學不到東西」。此研究主要關注語法理解能力，但我也很關心未來關於 CT（如抽象化能力）是否也會被 AI 使用模式影響的研究。

證據②：認知外包（outsourcing）的危險性

密西根大學的 Mark Guzdial 教授是計算教育研究的先驅之一。他在 2026 年 2 月的部落格文章中，用汽車的比喻來說明 GenAI 與認知的關係7。

GenAI is not cognitive offloading. It's outsourcing. We don't think about how to do the tasks that we ask GenAI to do.

（GenAI 不是認知的卸載，而是外包。我們不再思考那些交給 GenAI 做的任務該怎麼做）

Guzdial 引用了 Apple 曾用過的廣告比喻：

Some of you may remember the Apple ads that emphasized the computer as a "bicycle for the mind."

（或許有人還記得 Apple 將電腦形容為「心智的腳踏車」的廣告）

腳踏車是用來「擴張人類身體能力」——利用腿力踏行能到更遠的地方；但 GenAI 更像是一台汽車。汽車確實擴張了行動範圍，但它不需要用到人的身體力氣。結果是，在汽車社會裡人的體能會退化。GenAI 亦是類似：因為可以不動腦就獲得結果，導致能力萎縮的風險。

Guzdial 的處方是「鍛鍊」：

We will have to figure out that we need to exercise our minds, even if GenAI could do it easier, faster, and in some cases, better.

（即便 GenAI 在某些情況下更簡單、更快或更好，我們仍需想出方法鍛鍊自己的思維）

證據③：語法知識與計算思維是不同的能力

萊頓大學（Leiden University）的 Felienne Hermans 在其著作 The Programmer's Brain（2021）中，詳細分析了程式設計師的認知過程8。

此研究的重要發現是：語法記憶（syntax knowledge）與認知過程（如 chunking、心智模型建構、模式識別）是完全不同的能力。

這點很關鍵。Hermans 透過教育語言 Hedy 的研究，展示了語法障礙與 CT 障礙是可以被分離的9。Hedy 透過逐步引入語法來降低語法障礙，但 CT 的挑戰仍然存在。

把這個觀點放到 AI 時代來看，可以說：

AI 事實上已把語法障礙降到幾乎為零，但 CT 的障礙依然存在。

不懂 Python 的 for 語法，AI 可以替你寫；但判斷「要對什麼做迴圈」、「為何需要迴圈」的能力，仍然是 AI 不能完全替代的。

證據④：提示工程本身即屬於 CT

Hsu（2025）在論文 "From Programming to Prompting" 中，明確說明了提示工程與 CT 的對應關係10。

CT 要素與提示工程的對應如下：

• Decomposition：把複雜任務拆成多個提示（prompt）
• Abstraction：萃取本質需求，以適當抽象度描述
• Pattern Recognition：辨識並重用有效的提示模式
• Algorithms：設計提示的執行順序與條件分支

Schmidt & Runfola（2025）也討論到，提示工程需要邏輯、抽象化、分解、模式識別等 CT 四個支柱1。

由此可見，儘管程式語言可能從 Python 轉變為自然語言，但所需的思考能力並未改變。

實務：與 AI 協作時的最佳實務

到此整理了多項證據，接下來談談「那要怎麼做？」的實務建議。前述 Anthropic 研究中找到的六種使用模式，本身就可以直接用作實務指南。

不該採取的模式

1. AI Delegation（全部交給 AI）

   「請實作這個功能」→ 直接採用 AI 產生的程式碼

   這樣完成任務最速，但不會獲得技能。當問題發生時，無法自行處理。

2. Progressive AI Reliance（逐漸依賴）
   起初自己做，但遇到瓶頸就越來越倚賴 AI。長時間開發時特別容易陷入此陷阱。

3. Iterative AI Debugging（把除錯工作交給 AI）
   自己寫程式，但每次出錯就請 AI 幫忙除錯。表面看起來有效率，但會阻礙除錯思維（在 AI 時代極為重要技能）的養成。

推薦的有效模式

1. Generation-then-comprehension（生成→理解）

   「請實作此函式」→ AI 生成後，接著問「為何採用此方式？」等理解性問題

   在生成之後追問理解性的問題，確認你真的懂它做了什麼。

2. Hybrid code-explanation（程式碼＋說明同時要求）

   「請實作此函式，並在每步驟以註解說明決策理由」

   同時要求程式碼與解釋，邊看邊理解生成物。

3. Conceptual inquiry（概念性詢問）

   「Trio 的 Nursery pattern 適合在哪些場景使用？」→ 在理解後自己寫程式

   讓 AI 輔助概念理解，程式碼自己撰寫。在面對錯誤並自行解決的過程中獲得最多學習。Anthropic 的研究也顯示這些模式在高分群中最常見，且完成速度也快。

AI 時代所需的技能組合

綜合以上證據，我認為 AI 時代的「程式設計技能」可歸納為以下六項。

CT 的四個支柱

• Decomposition（分解）：將問題拆成適當粒度的任務，並設計對 AI 的指令單位
• Abstraction（抽象化）：抽出本質需求，並以適切的抽象度撰寫規格
• Pattern Recognition（模式識別）：辨識有效的解法模式並將之應用到新問題
• Algorithms（演算法設計）：設計處理順序、相依關係與條件分支

再加兩項補充技能

• 驗證能力（Validation）：檢驗 AI 輸出是否符合規格與預期的能力。包含測試設計、行為驗證與規格比對等。重點不在於逐字讀懂每行程式碼，而是能以某種方式驗證其正確性。
• 除錯思維（Debugging thinking）：辨識預期與實際行為的差異，並切分原因。此能力不限於程式碼層級，也適用於規格層或設計層的通用問題解決思維。

我在此刻故意沒有把「讀懂程式碼」列為核心技能。就像過去會寫組合語言或操縱暫存器的人變少一樣，隨著抽象化進程，逐行閱讀 AI 生成程式碼會逐漸成為較低層次的技能。重要的是能驗證結果是否正確，而非一定要看懂每一行程式碼。

教育將如何改變？

Becker 等人（2023 年）的 SIGCSE 論文指出，AI 程式碼生成工具的出現並沒有讓程式設計「變簡單」，而是讓其「形態改變」11。語法錯誤之苦會減少，但問題分解、設計合理性判斷、以及輸出驗證等 CT 呈現的難度會浮上檯面。

Porter & Zingaro（2024）所著的 AI 前提 Python 教科書 Learn AI-Assisted Python Programming，也把「問題分解與提示設計」視為必要技能12。

日本情境

日本自 2020 年起在小學推動程式設計教育必修，文部科學省使用「程式設計的思考（プログラミング的思考）」這個詞彙。這個概念其實相當接近 CT。

然而在實務上，課程常偏重於操作 Scratch 等工具，未必能有效培養「思考力」。把方塊拼起來讓角色動起來，與「把問題分解、抽象化並設計步驟」並非同一件事。

我認為 AI 時代反而是文部科學省原意——培養真正的「程式設計思考」或 CT——更應被落實的時機。因為 AI 已經去除了語法障礙，剩下的就是思考的障礙。

坦率說，主張「上課應全面禁止生成式 AI」的論調，很多時候未能區分「思考能力的習得」與「知識的習得」。若把教學目標設定在「會寫程式步驟」這類形式性的標準，那確實使用生成式 AI 看起來會讓課程失去意義。但若教學重點是思考能力（問題分解、抽象化、驗證），那麼生成式 AI 可以作為教學的一部分工具。

結論是「教育跟不上 AI 社會的變化」。但這不是某個老師或國家的錯，而是整個教育體系在面對環境變動時的適應速度不夠快。現實上，真正能教授「不只是知識，而是透過 PBL 等方式培養思考能力」的教師比例，估計少於 10%——這不是在責怪老師，而是在指出結構性問題。

結論：程式設計的本質未曾改變

程式語言的歷史，實際上是一部抽象化的歷史。

低階語言：機器語言 → 組合語言 → C → Java、C++ → C#、Python → 自然語言（更高階）

在每個階段，下層抽象都變得不可見。組合語言時代的程式設計師會注意暫存器，C 時代會注意記憶體管理；但今天多數工程師不再需要關心那些細節。同理，在 AI 時代中，關注每一行程式碼的必要性也會逐漸降低。
（當然，像嵌入式工程師等特定領域仍然需要關注底層細節。）

但在每一個階段，不變的是：「組構結構化指示的能力」——也就是計算思維。問題分解、模式識別、抽象化、步驟設計——沒有這些能力，再強大的 AI 工具也無法產出正確結果。

因此 AI 協作時代的「程式設計技能」並非指某種語言的語法知識，而是指那種跨時代不變的本質能力：計算思維（Computational Thinking）。

參考文獻

1. Schmidt, D.C. & Runfola, D. (2025). Liberating Logic in the Age of AI: Going Beyond Programming with Computational Thinking. arXiv:2511.17696. https://arxiv.org/abs/2511.17696 ↩
2. BBC Bitesize. Introduction to computational thinking. https://www.bbc.co.uk/bitesize/guides/zp92mp3/revision/1 ↩
3. Chasins, S.E. YouTube 講演. https://www.youtube.com/watch?v=AFu7jzI0ExY
   ↩
4. Chasins, S.E. Research Mission. https://schasins.com/ ↩
5. Jayagopal, D., Lubin, J., & Chasins, S.E. (2022). Exploring the Learnability of Program Synthesizers by Novice Programmers. ACM UIST 2022. https://dl.acm.org/doi/abs/10.1145/3526113.3545659 ↩
6. Shen, J.H. & Tamkin, A. (2026). How AI Impacts Skill Formation. arXiv:2601.20245. https://www.anthropic.com/research/AI-assistance-coding-skills ↩
7. Guzdial, M. (2026). GenAI as automobile for the mind, and exercise as the antidote. Computing Ed Research Blog. https://computinged.wordpress.com/2026/02/16/genai-as-automobile-for-the-mind-and-exercise-as-the-antidote-a-metaphor-for-predicting-genais-impact/ ↩
8. Hermans, F. (2021). The Programmer's Brain. Manning Publications. ↩
9. Hermans, F. (2020). Hedy: A Gradual Language for Programming Education. ACM ICER 2020. https://dl.acm.org/doi/abs/10.1145/3372782.3406262 ↩
10. Hsu, H.P. (2025). From Programming to Prompting: Developing Computational Thinking through Large Language Model-Based Generative Artificial Intelligence. TechTrends. https://link.springer.com/article/10.1007/s11528-025-01052-6 ↩
11. Becker, B.A. et al. (2023). Programming is Hard — Or At Least It Used to Be. SIGCSE 2023. https://dl.acm.org/doi/abs/10.1145/3545945.3569759 ↩
12. Porter, L. & Zingaro, D. (2024). Learn AI-Assisted Python Programming: With GitHub Copilot and ChatGPT. Manning Publications. ↩

原文出處：https://qiita.com/hokutoh/items/cd68b09eccb18c1f7f3d