命令列、GitHub
與正規式

開啟終端機

終端機（terminal）是以文字指令操作電腦的程式。與以滑鼠操作的圖形介面（GUI）相比，命令列有下列優點：

• 可以重現：指令可以記錄下來，之後或在另一台電腦上重新執行，得到相同的結果；滑鼠操作則難以準確描述與重複。
• 可以大量處理：一行指令就能處理許多檔案，例如將資料夾中所有 .csv 檔一次複製到別處。
• 可以自動執行：多行指令可以寫成腳本（script），交由電腦依序執行。
• 許多工具只有命令列介面：Git、Python 套件的安裝，以及連線到遠端伺服器（例如實驗室的 GPU 主機）時，通常只能透過終端機操作。

點選「開始」，搜尋 PowerShell，開啟「Windows PowerShell」。以下所有指令都在這個視窗中輸入。

按 ⌘ + 空白鍵，輸入 Terminal（終端機）並按 Enter。以下所有指令都在這個視窗中輸入。

開始安裝 Git、GitHub CLI 與 VS Code

這些工具要到「Git 與 GitHub 儲存庫」才會用到，各自的用途也在該節說明。由於下載需要一段時間，先在這裡開始安裝，安裝期間繼續進行下一節。

完成後，電腦上應有下列軟體：

進入練習資料夾

~ 代表使用者的家目錄（home directory），也就是以帳號命名的資料夾：C:\Users\帳號名稱/Users/帳號名稱。因此不論帳號名稱為何，這行指令都適用。

執行成功時，提示字元的結尾會變成 week04-lab>week04-lab %。接著執行 ls，應列出 README.txt、data、notes 三項。若出現 Cannot find pathno such file or directory，表示資料夾不在「下載」中或名稱不同，請回到「檔案與資料夾」檢查解壓縮的結果。

第一次在「下載」資料夾中執行指令時，macOS 可能詢問「終端機」是否可取用「下載項目」檔案夾，請選擇「好」。若已選擇不允許，執行指令時會出現 Operation not permitted；可到「系統設定 → 隱私權與安全性 → 檔案與檔案夾 → 終端機」開啟「下載項目」。

若 week04-lab 不在「下載」資料夾中，可先輸入 cd 與一個空白，再將 week04-lab 資料夾從檔案總管 Finder 拖曳到終端機視窗，路徑會自動填入，然後按 Enter。

絕對路徑與相對路徑

路徑（path）是描述檔案或資料夾位置的寫法，分為兩種：

• 絕對路徑（absolute path）從最上層開始寫起，不論目前的工作目錄在哪裡，都指向同一個位置，例如 C:\Users\帳號名稱\Downloads\week04-lab\data。Windows 的絕對路徑以磁碟代號（如 C:\）開頭/Users/帳號名稱/Downloads/week04-lab/data。macOS 與 Linux 的絕對路徑以 / 開頭。pwd 輸出的就是絕對路徑。
• 相對路徑（relative path）從目前的工作目錄開始寫起，因此同一個相對路徑在不同的位置會指向不同的地方。data、practice/ 與 ../notes 都是相對路徑；. 代表目前的資料夾，.. 代表上一層資料夾。

以 ~ 開頭的路徑以家目錄為起點，因此與絕對路徑相同，在任何位置都指向同一處。下表比較同一個指令在不同位置執行的結果：

下方的練習用終端機也接受絕對路徑（其中的帳號名稱固定為 you；在自己的電腦上請換成 pwd 顯示的帳號名稱），例如 cd C:\Users\you\Downloads\week04-lab\notescd /Users/you/Downloads/week04-lab/notes。

在自己的終端機執行 動手做

在自己的終端機中，從 week04-lab 開始依序執行下列指令，並對照上方的結果。之後的「練習：自行移動」會用到這裡建立的 practice。

常用指令

下表列出本次使用的指令，範例皆以 week04-lab 為工作目錄。每一個指令都可以在上方的練習用終端機中嘗試。

練習：自行移動 動手做

從練習用終端機左側的樹狀圖中任選一個資料夾，例如 notes 或 practice，在終端機中移動到該處，並以 pwd 與 ls 確認位置。接著嘗試只用一個 cd 指令抵達，例如由 data 執行 cd ../notes。

檢核：能說明分別從 data 與 practice 執行 cd .. 之後所在的位置。

1. 確認安裝

Git 與 GitHub CLI 已在「終端機」一節開始安裝。GitHub CLI（gh）用來在終端機中登入 GitHub；Visual Studio Code（簡稱 VS Code）是文字與程式編輯器，之後的課程也會使用。確認三者都已安裝完成：

三行都顯示版本號即完成。若出現 is not recognizedcommand not found，表示尚未安裝完成，或終端機尚未重新開啟。

2. 以 VS Code 編輯檔案

本次實作一律從終端機開啟檔案，例如 code about-me.txt。若檔案不存在，VS Code 會開啟一個空白的分頁，按 Ctrl⌘ + S 存檔時，檔案就會建立在目前的工作目錄中，不必在存檔視窗中尋找位置。第一次開啟資料夾時，VS Code 可能詢問是否信任該資料夾的作者，選擇信任即可。

若 code 指令無法使用，可改用系統內建的編輯器：Windows 執行 notepad about-me.txt，記事本詢問是否建立新檔案時選擇「是」。macOS 先執行 touch about-me.txt 建立空白檔案，再以 open -e about-me.txt 用「文字編輯」開啟。

檔案總管預設隱藏副檔名，可在「檢視 → 顯示 → 副檔名」開啟顯示。

3. 註冊 GitHub 帳號

至 github.com/signup 註冊帳號，並開啟驗證信完成電子郵件驗證。未驗證的帳號可能無法建立儲存庫。

4. 建立儲存庫

1. 登入 github.com，點選右上角的 + → New repository。
2. 在 Repository name 輸入 command-line-lab。
3. 選擇 Public，並開啟 Add README（部分版面為勾選 Add a README file）。
4. 點選 Create repository。

5. 以 GitHub CLI 登入

執行後，程式會依序提出四個問題（不同版本的用字可能略有差異）。第一、二、四題以方向鍵選擇，按 Enter 確認；第三題輸入 Y 再按 Enter：

接著畫面會顯示一組一次性驗證碼（First copy your one-time code: XXXX-XXXX）。按 Enter 開啟瀏覽器，在頁面上輸入這組驗證碼並點選 Authorize；若瀏覽器沒有自動開啟，請手動前往 github.com/login/device。終端機顯示 Logged in as 帳號名稱，即表示登入完成。

6. 設定使用者名稱與電子郵件

Git 會把這兩項資訊記錄在每一次 commit 中。每台電腦只需設定一次。將引號內的你的名字、你的信箱換成自己的資料後再執行：

由於儲存庫是公開的，這個電子郵件會出現在 commit 紀錄中。若不希望公開，可到 github.com/settings/emails 取得 GitHub 提供的代用信箱（結尾為 users.noreply.github.com）。

1. 將儲存庫複製到本機（clone）

在儲存庫頁面點選綠色的 Code 按鈕，選擇 HTTPS，並點選右側的複製圖示。網址的格式為 https://github.com/帳號名稱/command-line-lab.git。

git clone 會把 GitHub 上的儲存庫完整複製一份到本機，包含所有的修改紀錄。先回到「下載」資料夾，再輸入 git clone 與一個空白，然後貼上剛才複製的網址（在 PowerShell 中按 Ctrl + V 或按右鍵按 ⌘ + V）：

此時「下載」資料夾中有兩個資料夾：

Downloads/
├── week04-lab/          練習移動用的普通資料夾
└── command-line-lab/    剛才 clone 的儲存庫

week04-lab 不是儲存庫；以下所有 Git 操作都在 command-line-lab 中進行。

為什麼分成四個區域

Git 把一次修改從編輯到分享分成三個步驟，每一步都由使用者決定：

• git add：選擇哪些修改要納入下一次 commit。例如修改了三個檔案，但只有其中兩個屬於同一件事，就只 add 這兩個，第三個留到下一次。
• git commit：將暫存區的內容記錄為一個版本，之後可以隨時比較或回復。commit 只存在本機，不需要網路，因此可以先累積幾次 commit 再分享。
• git push：將本機的 commit 上傳到 GitHub，供他人檢視，也作為備份。上傳會影響共用同一個儲存庫的人，所以與 commit 分開進行。

另外兩個指令不會移動任何內容，只用來查看：git status 顯示每個檔案目前位於哪一個區域，是最常使用的指令；git log --oneline 列出本機歷史中的 commit。

四個區域因此分別對應：尚未決定的修改（工作資料夾）、準備記錄的修改（暫存區）、已經記錄的版本（本機歷史），以及已經分享的版本（GitHub）。

2. 新增 about-me.txt

在 command-line-lab 中，從終端機建立並開啟 about-me.txt：

寫入一句話說明想研究的題目，存檔後關閉分頁。回到終端機執行 ls，應可看到 README.md 與 about-me.txt。

執行 code . 則會以 VS Code 開啟整個資料夾，左側會列出其中的檔案。

3. 暫存、提交與上傳

逐行執行下列指令。每一步的預期結果列在指令下方，可對照上方「Git 的四個區域」的模擬。

重新整理 GitHub 上的儲存庫頁面，應可看到 about-me.txt。

4. 第二次修改 動手做

以 code about-me.txt 開啟檔案，修改內容並存檔，執行 git status 與 git diff 觀察輸出。git diff 會顯示尚未 add 的修改，例如：

@@ -1 +1 @@-我想研究台語的聲調。+我想研究台語和客語的聲調。

接著不參照上方的指令，依照四個區域的順序自行完成 add、commit 與 push。commit 訊息可以自訂，例如 "Update about-me"。完成後重新整理 GitHub 頁面，確認內容已更新。

5. 衝突 動手做

同一個檔案的同一處若在兩個地方分別被修改，Git 無法判斷應保留哪一個版本，這種情形稱為衝突（conflict）。多人協作時，衝突通常發生在兩人修改了同一段文字；一個人使用時，也可能因為在 GitHub 網頁與本機分別修改而發生。以下刻意製造一次衝突，再加以解決。

1. 在 GitHub 的儲存庫頁面點選 about-me.txt，再點選右上角的鉛筆圖示（Edit this file）。修改句子後，點選 Commit changes，並在跳出的對話框中再按一次 Commit changes。頁面上顯示修改後的句子即完成。

2. 不執行 git pull，直接在本機以編輯器把同一行改成另一個句子，存檔後執行：

   git add about-me.txt

   git commit -m "Update about-me again"

   git push

   GitHub 上有一個本機沒有的 commit，因此 push 會被拒絕：

    ! [rejected]        main -> main (fetch first)
   error: failed to push some refs to 'https://github.com/帳號名稱/command-line-lab.git'
   hint: Updates were rejected because the remote contains work that you do not
   hint: have locally. ...

3. 取得 GitHub 上的修改，並與本機的修改合併：

   git pull --no-rebase

   --no-rebase 指定以合併（merge）的方式整合兩邊的修改：保留兩條歷史，再以一個合併的 commit 連接。另一種方式是 rebase，它把本機新增的 commit 暫時移開，接在 GitHub 最新的 commit 之後重新套用一次，歷史因此成為一直線；本次實作不使用 rebase。若只執行 git pull，新版 Git 會先要求選擇整合方式，並顯示 fatal: Need to specify how to reconcile divergent branches. 後停止。

   由於兩邊修改了同一行，合併無法自動完成：

   Auto-merging about-me.txt
   CONFLICT (content): Merge conflict in about-me.txt
   Automatic merge failed; fix conflicts and then commit the result.

4. 以 code about-me.txt 開啟檔案，可以看到 Git 加入的衝突標記。VS Code 會以顏色區分兩個版本，並在上方提供「Accept Current Change」（保留本機）、「Accept Incoming Change」（保留 GitHub）與「Accept Both Changes」（兩者都保留）等選項；也可以直接手動編輯。若使用其他編輯器且檔案原本已開啟，請先關閉再重新開啟。

   <<<<<<< HEAD
   我想研究台語的語法。
   =======
   我想研究客語的聲調。
   >>>>>>> 2b55f62e69575191df2490cf5129a012b2badb75

   <<<<<<< HEAD 與 ======= 之間是本機的版本，======= 與 >>>>>>> 之間是 GitHub 上的版本。HEAD 指本機目前的版本；最後一行的長字串是 GitHub 上那個 commit 的編號。將內容改成最後要保留的文字，刪除三行標記，然後存檔。存檔後，檔案中不應再有 <<<<<<<、======= 或 >>>>>>>。

   整理的方式有幾種，例如兩邊都保留（即「Accept Both Changes」的結果）：

   我想研究台語的語法。
   我想研究客語的聲調。

   或把兩邊合併成一句：

   我想研究台語的語法與客語的聲調。

   只保留其中一邊也可以。重點是三行標記都已刪除，檔案中只剩最後要保留的文字。

5. 完成合併並上傳：

   git add about-me.txt

   git commit -m "Resolve conflict in about-me.txt"

   git push

   此處執行 git add，是告知 Git 衝突已經解決。執行 git log --oneline --graph，可以看到兩條分開的歷史在合併的 commit 匯合。

6. commit 的圖形表示

Learn Git Branching 以圖形呈現 commit 歷史。開啟後會直接進入「基礎篇」第一關〈介紹 git commit〉。閱讀說明並關閉視窗後，依指示執行兩次 git commit，圖中會新增兩個節點。

圖中的每一個節點，對應 git log --oneline 輸出中的一行。第 5 步的 git pull 已經產生過一次合併；建立分支與 rebase 的操作則不在本次實作範圍內。

Git 的使用情境

凡是會反覆修改、需要保留修改過程的檔案，都適合以 Git 管理。常見的情境如下：

個人寫作

以 LaTeX 或 Markdown 撰寫論文、講義時，每完成一段就 commit。git diff 可以逐行顯示兩個版本之間的差異，比人工對照兩份文件清楚得多（圖一）。

撰寫程式

在程式可以正常執行時 commit。之後若程式出錯，可以查看改了哪些地方，或回到先前可以執行的版本。

重大修改之前

先建立分支（branch），在分支上嘗試新的寫法。確定可行後再合併（merge）回主線；不可行就捨棄分支，主線不受影響。重要的版本可以加上標籤（tag），例如投稿版或 v1.0，日後可以直接回到該版本（圖二、圖五）。

與他人協作

每個人在各自的分支上工作，透過 GitHub 的 pull request 檢視彼此的修改，再決定是否合併（圖三）。

與 AI 代理人協作

讓代理人在獨立的分支上修改，先以 git diff 檢視它改了什麼，再決定是否合併；結果不理想時，捨棄該分支即可。多個代理人同時開發不同的功能時，各自使用一個分支（或以 git worktree 建立各自的工作資料夾），彼此不會覆蓋對方的修改。代理人完成的 commit 也會記錄在歷史中（圖四）。

diff --git a/paper.tex b/paper.tex--- a/paper.tex+++ b/paper.tex@@ -1,3 +1,3 @@11 \section{研究方法}2-本研究使用 BPE 切分台語語料。2+本研究比較 BPE 與 Unigram LM 兩種方法切分台語語料。33 語料來源為教育部臺灣台語常用詞辭典。

1\section{研究方法}2[-本研究使用-]{+本研究比較+} BPE [-切分台語語料。-]{+與 Unigram LM 兩種方法切分台語語料。+}3語料來源為教育部臺灣台語常用詞辭典。

以下三張圖取自 Hugging Face 的 transformers 儲存庫。這是許多語言模型程式使用的開放原始碼套件，自 2018 年起以 Git 共同維護。截至 2026 年 9 月 30 日，它的規模如下：

commit

約 24,000

貢獻者

約 4,100

已合併的 pull request

約 20,600

檢視中的 pull request

約 1,600

分支

約 1,600

版本標籤

289

若沒有版本控制，數千人只能輪流傳遞同一份檔案：一次只有一個人可以修改，其他人都必須等待，就像一次只允許一個人通過的號誌。Git 讓每個人在自己的分支上同時工作，修改完成後再經過檢視與合併，因此上千個修改可以同時進行。

相關指令：git switch -c experiment 建立並切換到新分支，git switch main 回到主線，git merge experiment 將分支合併回目前的分支，git tag v1.0 為目前的 commit 加上標籤，git log --oneline --graph --all 顯示所有分支的圖。本次實作只使用 main 分支；分支的練習見「延伸閱讀」中的 Learn Git Branching。

1. 準備 RegExr

開啟本課準備的 RegExr 練習頁。畫面中央標示 Text 的大框中已有下列四行聯絡資料：

上方 Expression 區的兩條斜線之間有一條範例正規式 [A-Z]，先將它刪除，之後的正規式都寫在這兩條斜線之間。若練習頁無法開啟，可改開 RegExr 首頁，把 Text 框中原有的文字換成上面四行。

2. 基本符號

正規式中的大多數字元代表字元本身，例如 Lin 就是比對 Lin 這三個字母。下列符號則有特殊意義，更完整的說明見正規式 ELI5：

3. 練習 動手做

1. 使每一個數字各自成為一個比對結果。

   提示

   表示「任一數字」的寫法以反斜線開頭，共兩個字元。

2. 使連續的數字成為一個比對結果。

   提示

   在上一題的寫法之後，加上表示「一個以上」的符號，並觀察 0912-345-678 被分成幾段及其原因。

3. 只比對三組手機號碼，不包含辦公室號碼 02-2345-6789。

   提示 1

   手機號碼都以 09 開頭，可直接照字面寫出。

   提示 2

   {3} 表示恰好三個。連字號 - 也照字面寫出。

4. 比對 Alice 或 Bob。

   提示

   「或」以直線 | 表示。完成後，觀察信箱中的 alice、bob 是否被比對，並思考原因。

4. 行首 動手做

將 Text 替換為下列內容：

先點選 Expression 右上角的 Flags，勾選 multiline。預設情況下，^ 只比對整段文字的開頭；啟用 multiline 後，^ 才會比對每一行的開頭。

練習：比對 S001 與 S002，但不包含 X003。完成後取消 multiline，觀察哪一行不再被比對。

5. 更多符號 動手做

下列符號與第 2 小節的符號可以任意組合：

將 Text 換回第 1 小節的四行聯絡資料（重新開啟練習頁亦可），並保持 multiline 為勾選狀態。

1. 比對每一行的第一個單字。

   提示

   行首加上表示「一個以上的英文字母或數字」的寫法。

2. 比對每一行最後一組數字。

   提示

   以 $ 表示行尾。

3. 比對全部四個電子郵件地址。

   提示

   信箱由英文字母、數字與句點組成，中間有一個 @。[\w.] 表示「\w 或句點」；在方括號中，句點只代表句點本身。

4. 只比對以 .com 結尾的電子郵件地址。

   提示

   在方括號以外，句點代表任一字元，因此 .com 的句點須寫成 \.。

6. 群組與反向參照 動手做

以圓括號 ( ) 括起的部分稱為群組（group）。群組有兩種用途：一是把多個字元視為一個整體，例如 (ha)+ 比對 ha、haha、hahaha；二是記住該部分實際符合的內容，稱為擷取（capture）。由左至右，第一個群組擷取的內容以 \1 表示，第二個以 \2 表示，依此類推。在正規式中寫 \1 稱為反向參照（backreference），表示「與第一個群組擷取的內容相同」。只需要整體、不需要擷取時，可以寫成 (?:ha)+。

取代。擷取的內容也可以用於取代。點選 RegExr 畫面下方 Tools 區的 Replace，在其中輸入取代後的格式，$1 代表第一個群組擷取的內容，$2 代表第二個。以四行聯絡資料為例：

1. 以 Expression ^(\w+) (\w+) 與 Replace $2, $1，把 Alice Chen 改寫成 Chen, Alice。觀察 Office 那一行為何沒有改變。

   提示

   比較 Office 之後與 Alice 之後的字元。

疊字。將 Text 換成下列內容：

2. 比對所有連續兩個相同的字，例如 天天。

   提示

   以 (.) 擷取任一個字，再以 \1 要求下一個字與它相同。

3. 比對 AABB 式的疊字，例如 高高興興。

   提示

   需要兩個群組，分別以 \1 與 \2 參照。

4. 比對 ABAB 式的疊字，例如 研究研究。

   提示

   先擷取兩個字，再依相同的順序重複一次。

7. 萬用字元與正規式

終端機中的檔名也可以用樣式表示，這種樣式稱為萬用字元（wildcard，又稱 glob）。例如 ls data/*.csv 會列出 data 中所有以 .csv 結尾的檔案。在 macOS 的終端機中，萬用字元由 shell 在執行指令之前展開成符合的檔名清單。在 PowerShell 中，萬用字元由各個指令自行處理，結果相同。

萬用字元與正規式使用部分相同的符號，但意義不同：

兩者是不同的表示法，萬用字元並不是正規式的一部分：

• 萬用字元必須符合整個檔名，相當於正規式前後加上 ^ 與 $；正規式則會在文字中的任何位置尋找符合的部分。
• 萬用字元中的 . 只代表句點；正規式中的 . 代表任意一個字元。
• 萬用字元沒有 +、{3}、|、\d 等寫法，能描述的樣式少得多。

下列指令須在 week04-lab 中執行，可使用「在資料夾之間移動」的練習用終端機，或在自己的終端機中先執行 cd ~\Downloads\week04-labcd ~/Downloads/week04-lab。第三行須先建立 practice。

8. 以正規式切分詞元 頁面練習

語言模型處理文字之前，先由 tokenizer 把文字切成一個個詞元（token），模型所認得的全部詞元稱為詞彙表（vocabulary）。tokenizer 先清理與統一文字（normalization，見本節開頭的表），接著進行 pre-tokenization，通常以一條正規式把文字切成小段（詳見 Lecture 03）。正規式在此有兩種用法：「切開」以符合的部分作為分界，丟掉分界，保留分界之間的文字；「挑出」只保留符合的部分，丟掉其餘的文字。規則描述的是分界時用「切開」，描述的是詞元本身時用「挑出」。以 I don't know. 為例：

• 以 \s+ 切開：得到 I、don't、know.。空白是分界，標點仍連在字上。
• 以 \w+ 挑出：得到 I、don、t、know。撇號與句點不符合 \w，因此被丟掉。

「切開」與「挑出」分別相當於 Python 的 re.split 與 re.findall。GPT-2 的規則與本節開頭表格的最後一步都屬於「挑出」。

討論

1. 以 \s+ 切開英文句子時，don't 與 words; 的結果為何？
2. 以同一條規則切開中文句子，會得到幾個詞元？原因為何？
3. 選擇「\w+ 挑中文」範例：為什麼 \w+ 無法比對任何中文字？
4. GPT-2 的規則把空白歸到哪一側？這對詞彙表有什麼影響？

pre-tokenization 的詳細說明見 pre-tokenization ELI5。Hugging Face 的 tokenizers 文件說明完整的流程：normalization、pre-tokenization、模型切分與後處理（post-processing），其中前兩個步驟都可以用正規式設定（normalizers.Replace 與 pre_tokenizers.Split）。

9. LLM 的 tokenizer

本頁的工具只做到 pre-tokenization，也就是以一條規則把文字切成小段。實際的 LLM tokenizer 還會再把每一小段切成詞彙表中的單位，並把每個詞元換成一個編號（ID），模型處理的就是這串編號。與正規式相比，主要有三點不同：

• 切分方式由資料決定。詞彙表由 BPE 等演算法從大量語料中統計常見的字元組合而得，而不是由人撰寫規則。常見的詞成為一個詞元，少見的詞則拆成幾段，例如 GPT-2 把 unbelievably 切成 un、bel、iev、ably（詳見 BPE ELI5）。
• 以位元組為最小單位。GPT 系列的 tokenizer 先把文字轉為 UTF-8 位元組，因此任何文字都能表示。詞彙表中沒有的字會拆成位元組：「詞」的 UTF-8 編碼是 e8 a9 9e 三個位元組，在 GPT-2 中就成為三個詞元。
• 不同模型的切法不同。詞彙表的大小與內容依模型而異。下表比較 GPT-2（詞彙表 50,257 個詞元）與 GPT-4o（約 200,000 個）對同樣兩句話的切分，灰色方塊是無法單獨顯示為文字的位元組：

同一句中文，GPT-2 需要 23 個詞元，GPT-4o 只需要 9 個。詞元數決定了模型能讀入的文字長度與使用 API 的費用，因此詞彙表涵蓋哪些語言，會直接影響該語言的使用成本。各模型的切分結果可在 Tiktokenizer 中比較。

10. 正規式的限制

正規式適合描述局部、固定的字串樣式，但有下列限制：

• 只處理形式，不處理意義。(.)\1 能找出 天天、慢慢，(.)(.)\1\2 能找出 研究研究，但無法判斷這些疊字分別屬於名詞、形容詞或動詞，也無法判斷多音字「行」在句中讀作 xíng 或 háng。
• 無法切分中文詞。「研究生命起源」可以切成「研究／生命／起源」，也可以切成「研究生／命／起源」。正規式只能依字元的種類切分，判斷哪一種切法正確則需要詞典或統計模型。這也是 tokenizer 以 BPE 等方法從資料中學習詞元的原因之一。
• 無法處理任意深度的巢狀結構。例如成對的括號 ((()))、層層包覆的 HTML 標籤，或英文的中心嵌入句 The rat the cat the dog chased bit died。這類結構需要記住「開了幾層」，而正規式沒有計數的能力。在形式語言理論中，正規式描述的是正規語言（regular language），位於喬姆斯基階層（Chomsky hierarchy）的最低一層；巢狀結構屬於上一層的上下文無關語言（context-free language），須以剖析器（parser）處理。反向參照雖然使實際的正規式超出正規語言的範圍，例如 ^(.+)\1$ 可比對「同一字串重複兩次」，但 JavaScript 與 Python 的 re 仍無法處理任意深度的巢狀結構。
• 不易閱讀與維護。上方 GPT-2 的規則已不易一眼看懂。規則越長，越難確認它涵蓋了所有情況，也越難修改。某些寫法在特定輸入下還會因反覆回溯（backtracking）而執行得極慢，例如以 (a+)+$ 比對一長串 a 之後接一個 b 的文字。
• 不處理字元的編碼差異。外觀相同的字元可能有不同的編碼，例如全形與半形的標點，或以組合字元表示的帶調字母。比對之前須先統一文字，即本節開頭表格中的 normalization。

因此，需要結構、意義或統計的工作，通常交給剖析器、詞典或語言模型處理，正規式則負責前後的清理與擷取。

完成後的儲存庫

command-line-lab/
├── README.md
├── about-me.txt
├── participants.txt
└── answers.txt

此外，應能對照 Git 的四個區域，說明下列四種狀態的差異：已修改但尚未 add、已 add 但尚未 commit、已 commit 但尚未 push，以及已上傳到 GitHub。

延伸閱讀

• GitHub Skills: Introduction to Git：GitHub 官方的互動課程。將練習儲存庫複製到自己的帳號後，依指示逐步完成，內容包含 commit、歷史紀錄與分支；課程使用 VS Code。
• Gitualize：各個 Git 指令的說明與動畫示範，包含本次未詳細說明的 pull、branch 與 merge。
• Learn Git Branching：分支與合併的互動練習。
• RegexOne：正規式分題練習。
• Software Carpentry: The Unix Shell：命令列入門教材。教材使用 Unix 的選項，其中部分在 PowerShell 中不適用。