讓 AI 如虎添翼的五項基本人類技能

你不需要計算機科學學位就能使用 AI 程式設計工具開發軟體。但你確實需要一小組技能，而這些技能是任何 AI 都無法取代的。這些是不可或缺的基礎 — 讓一切成為可能的根基。

簡短清單

技能	為什麼不可或缺
Git	你的安全網 — 復原任何操作、無所顧忌地分支、永不丟失工作
TDD	讓 AI 生成的程式碼保持誠實的方法論
終端機操作	AI 工具住在終端機裡；你需要能閱讀它們的輸出
英文	文件、錯誤訊息和 AI 提示在英文下效果最佳
品味	AI 生成選項；你決定哪個是正確的

就這樣。五件事。其他的一切 — 語言語法、框架 API、設計模式 — AI 都替你處理了。^[1]

Git — 你的安全網

Git 是你手中最重要的工具。不是因為你需要掌握 rebase 或 cherry-pick — AI 會處理這些 — 而是因為 Git 給了你 無所顧忌地實驗 的能力。^[2]

你真正需要知道的

指令	功能	使用時機
`git status`	顯示哪些內容有變更	每次 AI 工作階段前後
`git diff`	顯示確切的變更	提交前審閱 AI 所做的修改
`git add` + `git commit`	儲存一個存檔點	每次達到可運作狀態後
`git log`	變更歷史	需要了解發生了什麼時
`git stash`	暫時擱置變更	想嘗試不同方法時
`git checkout -- file`	復原對某個檔案的變更	AI 把某個東西弄得更糟時
`git worktree`	同時在多個分支上工作	想並行探索想法時

心智模型

把 Git 想成 無限的復原功能。每次提交都是一個你可以返回的存檔點。這意味著：

自由嘗試有風險的變更 — 你隨時可以回頭
讓 AI 自由實驗 — 如果它把某個東西搞壞了，就回滾
同時進行多個想法 — 分支讓你並行探索
接受前先審閱 — git diff 讓你看到 AI 究竟改了什麼

AI 會為你建立提交、分支和 Pull Request。但你應該了解這些是什麼，因為你是那個決定何時儲存、何時分支、何時合併的人。

Git Worktrees — 平行宇宙

值得早點學習的一個 Git 功能是 worktrees。Worktree 讓你可以在獨立的目錄中簽出不同的分支 — 而不影響你當前的工作：

bash

# 為新功能建立 worktree
git worktree add ../my-feature -b feature/new-idea

# 在其中工作
cd ../my-feature
claude    # 在這個分支中啟動 AI 工作階段

# 回到你的主要工作 — 未受影響
cd ../vmark

這與 AI 程式設計工具搭配使用特別強大：你可以讓一個 AI 工作階段在功能分支上實驗，同時保持你的主分支乾淨且可運作。如果實驗失敗，只需刪除 worktree 目錄。沒有混亂，沒有風險。

不要跳過 Git

沒有 Git，一次糟糕的 AI 編輯就可能毀掉數小時的工作，而且無法復原。有了 Git，最壞的情況永遠是 git checkout -- .，你就回到最後一次存檔了。在做任何其他事情之前，先學好 Git 基礎。

TDD — 讓 AI 保持誠實的方法

測試驅動開發是將 AI 程式設計從「希望它能運作」轉變為「證明它能運作」的方法論。這不只是一個好的實踐 — 它是你用來驗證 AI 生成的程式碼確實按照你要求的方式運作的主要機制。^[3]

RED-GREEN-REFACTOR 循環

TDD 遵循嚴格的三步驟循環：

1. RED     — 寫一個描述你想要什麼的測試。它會失敗。
2. GREEN   — 請 AI 寫讓測試通過所需的最少程式碼。
3. REFACTOR — 在不改變行為的情況下清理。測試仍然通過。

這與 AI 程式設計工具搭配效果極好，原因如下：

步驟	你的角色	AI 的角色
RED	描述預期行為	協助撰寫測試斷言
GREEN	驗證測試通過	寫實作
REFACTOR	判斷程式碼是否足夠乾淨	執行清理

為什麼 TDD 在使用 AI 時更重要

當你自己寫程式碼時，你對它有隱性的理解 — 你知道它做什麼，因為是你寫的。當 AI 寫程式碼時，你需要一個 外部驗證機制。測試就是那個機制。^[4]

沒有測試，會發生什麼：

你請 AI 加入一個功能
AI 寫了 200 行程式碼
你讀了，它看起來是對的
你部署了
它壞掉了某個你沒注意到的東西 — 一個微妙的邊界情況、型別不符、差一的錯誤

有了 TDD：

你把行為描述成測試（AI 幫你寫）
測試失敗 — 確認它確實在測試某個真實的東西
AI 寫程式碼讓它通過
你執行測試 — 它通過了
你有了它能運作的證明，而不只是一種感覺

測試長什麼樣子

你不需要從頭寫測試。用白話描述你想要的，AI 就會寫測試。但你應該能夠讀懂測試：

// 「當使用者儲存文件時，已修改標記應清除」
it("儲存後清除已修改標記", () => {
  // 設定：將文件標記為已修改
  store.markModified("doc-1");
  expect(store.isModified("doc-1")).toBe(true);

  // 操作：儲存文件
  store.save("doc-1");

  // 驗證：已修改標記已清除
  expect(store.isModified("doc-1")).toBe(false);
});

模式永遠相同：設定、操作、驗證。一旦你認出這個模式，你就能讀懂任何測試 — 更重要的是，你可以告訴 AI 接下來要測試什麼。

邊界情況 — Bug 的藏身之處

TDD 真正的力量在於 邊界情況 — Bug 藏身其中的不尋常輸入和邊界條件。AI 自己想到這些的能力出人意料地差。^[5] 但你可以提示它：

「如果檔名是空的，會發生什麼？」「如果使用者快速連按兩下儲存按鈕呢？」「如果網路在請求進行到一半時中斷呢？」「如果檔名中有 Unicode 字元呢？」

每一個問題都會變成一個測試。每個測試都會成為一個保證。你想到越多邊界情況，你的軟體就越健壯。這正是人類的品味與 AI 的 實作速度 結合，產生兩者都無法單獨達到的成果的地方。

在實際工作中的 TDD 與 AI

以下是一個真實的工作流程：

你：   加入一個檢查檔名是否有效的函式。
       從一個失敗的測試開始。

AI：   [寫測試] it("拒絕空白檔名", () => { ... })
       [測試失敗 — RED ✓]

你：   現在讓它通過。

AI：   [寫 isValidFilename()]
       [測試通過 — GREEN ✓]

你：   為以下情況加入測試：只有空格、路徑分隔符、
       長度超過 255 個字元的名稱、null 位元組。

AI：   [寫 4 個測試，有些失敗]
       [更新函式以處理所有情況]
       [所有測試通過 — GREEN ✓]

你：   很好。如有需要，請重構。

AI：   [簡化正規表示式，保持測試通過 — REFACTOR ✓]

你沒有寫一行程式碼。但你做出了每一個決定。測試證明程式碼能運作。如果有人之後修改了這個函式，測試就會捕捉到迴歸問題。

覆蓋率棘輪

VMark 強制執行測試覆蓋率閾值 — 如果覆蓋率低於底線，建置就會失敗。這意味著每個新功能必須有測試。AI 知道這一點並會自動撰寫測試，但你應該驗證它們是否在測試有意義的行為，而不只是覆蓋程式碼行數。

終端機操作

AI 程式設計工具是命令列程式。Claude Code、Codex CLI、Gemini CLI — 它們都在終端機中執行。你不需要記住數百個指令，但你需要能熟練使用一小部分：

bash

cd ~/projects/vmark      # 導覽到某個目錄
ls                        # 列出檔案
git status                # 查看什麼有變更
git log --oneline -5      # 最近的提交
pnpm install              # 安裝依賴項
pnpm test                 # 執行測試

AI 會為你建議和執行指令。你的工作是 閱讀輸出 並了解事情是成功還是失敗。測試失敗的樣子與建置錯誤不同。「Permission denied」與「File not found」不同。你不需要自己修復這些 — 但你需要描述你看到的，讓 AI 去修復它。

從這裡開始

如果你從未用過終端機，從 MIT 的 The Missing Semester 開始 — 特別是第一堂關於 Shell 工具的課。一小時的練習就能讓你具備與 AI 程式設計工具合作所需的基礎。

英文能力

這不是在說你需要能寫出完美的散文。而是 閱讀理解 — 理解錯誤訊息、文件和 AI 的解釋。整個軟體生態系都在英文上運作：^[6]

錯誤訊息 是英文的
文件首先（而且通常只）以英文撰寫
Stack Overflow、GitHub Issues 和教學資源絕大多數是英文的
AI 模型在英文提示下的表現明顯更好（參見為什麼英文提示能產生更好的程式碼）

你不需要能流利地寫作。你需要：

閱讀一條錯誤訊息並理解大意
搜尋技術術語，搜尋效果更好
描述你想要什麼，表達得足夠清楚讓 AI 理解

如果英文不是你的第一語言，VMark 的 :: 提示快捷鍵會自動翻譯和精煉你的提示。但閱讀 AI 的回應 — 通常是英文的 — 是你會一直在做的事。

品味 — AI 無法取代的唯一事物

這是最難定義、也最重要的。品味是知道好的東西長什麼樣 — 即使你自己還無法打造它。^[7]

當 AI 提供三種方法來解決問題時，品味告訴你：

簡單的比聰明的好
依賴項更少的解法更可取
讀起來像散文的程式碼勝過「最佳化」的程式碼
如果 5 行就夠了，10 行的函式就值得懷疑

如何培養品味

使用好的軟體 — 注意什麼感覺對、什麼感覺笨拙
閱讀好的程式碼 — 在 GitHub 上瀏覽熱門的開源專案
閱讀輸出 — 當 AI 生成程式碼時，即使你無法自己寫，也要去讀
問「為什麼」 — 當 AI 做出選擇時，請它解釋取捨
反覆迭代 — 如果某個東西感覺不對，它可能確實不對。請 AI 再試一次

品味會複利增長。你讀的程式碼越多（即使是 AI 生成的），你的直覺就越好。在幾個月的 AI 輔助開發之後，你會發現 AI 遺漏的問題 — 不是因為你懂更多語法，而是因為你知道 結果應該是什麼感覺。

品味測試

AI 完成任務後，問自己：「如果我是使用者，這樣做感覺對嗎？」如果答案不是立即的「是」，就告訴 AI 哪裡感覺不對。你不需要知道如何修復 — 只需要說出感受。

你不需要什麼

同樣重要的是知道你可以安心跳過的事情：

你不需要	原因
程式語言精通	AI 寫程式碼；你審閱它
框架專業知識	AI 對 React、Rails、Django 的了解比大多數人都好
演算法知識	AI 實作演算法；你描述目標
DevOps 技能	AI 寫 CI 設定、Docker 檔案、部署腳本
記住設計模式	當你描述行為時，AI 套用正確的模式
多年經驗	新鮮視角 + AI > 沒有 AI 的經驗^[8]

這不意味著這些技能毫無價值 — 它們讓你更快、更有效率。但它們不再是 先決條件 了。你可以逐漸地、邊做邊學，讓 AI 在過程中教你。

複利效應

這五項技能 — Git、TDD、終端機、英文和品味 — 不只是相加。它們會 複利增長。^[9]

Git 安全網讓你自由實驗，更快速地培養品味
TDD 讓你對 AI 的輸出有信心，所以你可以移動得更快
終端機熟練度讓你能毫無阻礙地執行測試和 Git 指令
英文閱讀理解讓你能讀懂錯誤訊息和文件
品味讓你的提示更精確，進而產生更好的程式碼
更好的程式碼給你更好的學習範例

幾週的 AI 輔助開發之後，你會發現自己理解了從未正式學習過的東西。這就是複利效應在發揮作用 — 這也是為什麼這五項基礎，而且只有這五項，是真正不可或缺的。

「無程式碼」和「低程式碼」運動多年來一直試圖消除程式設計障礙。AI 程式設計工具更有效地實現了這一點，因為它們不限制你能建置的東西 — 它們根據自然語言描述，用任何語言、遵循任何模式，寫出任意的程式碼。參見：Jiang, E. et al. (2022). Discovering the Syntax and Strategies of Natural Language Programming with Generative Language Models. CHI 2022. ↩︎
Git 的分支模型從根本上改變了人們對實驗的態度。關於開發者工作流程的研究表明，使用頻繁、小型提交搭配分支的團隊，嘗試有風險變更的可能性顯著更高 — 因為失敗的成本接近於零。參見：Bird, C. et al. (2009). Does Distributed Development Affect Software Quality?. ICSE 2009. ↩︎
測試驅動開發由 Kent Beck 於 2002 年正式化，此後已成為專業軟體工程的基石。先寫測試的紀律迫使開發者在實作之前澄清需求 — 這種好處在「開發者」是需要精確指令的 AI 時變得更加強大。參見：Beck, K. (2002). Test-Driven Development: By Example. Addison-Wesley. ↩︎
關於 AI 程式碼生成的研究一致發現，除非由明確的測試案例引導，否則 AI 生成的程式碼通過功能測試的比率低於人工撰寫的程式碼。在提示中提供測試案例可使正確程式碼生成率提高 20–40%。參見：Chen, M. et al. (2021). Evaluating Large Language Models Trained on Code. arXiv:2107.03374; Austin, J. et al. (2021). Program Synthesis with Large Language Models. arXiv:2108.07732. ↩︎
AI 模型在邊界情況和邊界條件上的表現系統性地不佳。它們傾向於生成能處理常見輸入但在不尋常輸入上失敗的「快樂路徑」程式碼。這是基於 Transformer 的程式碼生成的一個已記錄的局限性 — 訓練資料偏向典型的使用模式。參見：Pearce, H. et al. (2022). Examining Zero-Shot Vulnerability Repair with Large Language Models. IEEE S&P 2022. ↩︎
英文以壓倒性的優勢主導了程式設計和技術文件。對 GitHub 公開儲存庫的分析顯示，超過 90% 的 README 檔案和程式碼注釋是英文的。同樣，Stack Overflow 的 2300 萬個問題也以英文為主。參見：Casalnuovo, C. et al. (2015). Developer Onboarding in GitHub. ESEC/FSE 2015. ↩︎
軟體工程中的「品味」— 區分好設計和壞設計的能力 — 越來越被視為一項核心技能。Fred Brooks 寫道，「偉大的設計來自偉大的設計師」，而不是偉大的流程。隨著 AI 接手了程式設計的機械性方面，這種審美判斷成為人類的主要貢獻。參見：Brooks, F. (2010). The Design of Design. Addison-Wesley. ↩︎
關於 AI 輔助程式設計的研究表明，經驗較少的開發者往往比專家從 AI 工具中獲益更多 — 因為「能描述」和「能實作」之間的差距在 AI 的幫助下大幅縮小。參見：Peng, S. et al. (2023). The Impact of AI on Developer Productivity. arXiv:2302.06590. ↩︎
「複利學習」的概念 — 基礎技能加速習得相關技能 — 在教育研究中早有定論。在程式設計中，理解幾個核心概念能解鎖在其上建立的一切的快速學習。參見：Sorva, J. (2012). Visual Program Simulation in Introductory Programming Education. Aalto University. ↩︎

讓 AI 如虎添翼的五項基本人類技能 ​

簡短清單 ​

Git — 你的安全網 ​

你真正需要知道的 ​

心智模型 ​

Git Worktrees — 平行宇宙 ​

TDD — 讓 AI 保持誠實的方法 ​

RED-GREEN-REFACTOR 循環 ​

為什麼 TDD 在使用 AI 時更重要 ​

測試長什麼樣子 ​

邊界情況 — Bug 的藏身之處 ​

在實際工作中的 TDD 與 AI ​

終端機操作 ​

英文能力 ​

品味 — AI 無法取代的唯一事物 ​

如何培養品味 ​

你不需要什麼 ​

複利效應 ​