Day 08 · W2 · AI 線 · 難度 ★★☆☆☆

本系列由 AI 協作撰寫。 內容、技術判斷、程式碼由 light-design 數位顧問團隊與 Claude 共同產出，最終由作者驗證後 publish。完整協作模式與把關方式見 Day 01。

第二週開始，攤開實作。第一件事我想先講清楚：這個專案裡的 Python，沒有一行是我打出來的。

寫這篇之前我想給你一個數字，證明 AI 到底寫了多少。於是我去翻 git。

commit 總數                      78
標了 Co-Authored-By: Claude      42   （54%）
這些 commit 佔 Python 新增行數        63%

我原本以為這就是答案，數字漂亮又客觀。結果去看標記怎麼來的，才發現這個數字不能用。

一句話主軸：能量化的是產出，量不出來的那部分才是人做的事。

那個 63% 為什麼是假的

如果標記是「有 AI 參與就加、沒有就不加」，63% 就有意義。我去看了標記的分布：

日期      有標記   未標記
04-30       1       7
05-04       4       0
05-07       0       5
05-08       6      17     ← 同一天，兩種都有
05-12       4       0
06-18      21       1

05-08 那天，六個 commit 標了，十七個沒標。 同一天、同一台電腦、同一個人在做同一批事。

所以那行 Co-Authored-By 量到的不是「AI 有沒有參與」，是「當下有沒有順手加那行字」。整個專案我沒有一天是自己寫 Python 的，但 git 上有 36 個 commit 看起來像是我獨力完成。

兩種顏色從頭到尾交錯。如果標記是可靠的，應該會看到一段連續的未標記，然後切換。

這件事本身就是這篇的第一個結論：AI 協作的貢獻度，用版本控制量不出來。 不是工具不好，是那個維度根本沒被記錄。

那我到底在做什麼

四件事。

一、決定架構。 一個規則一個檔案、自動掛載、規則之間不互相 import —— 這些是我定的，理由是要讓 AI 加規則的時候不必同時改兩個地方。Day 3 講過這個取捨的代價。

二、決定取捨。 掃描要不要拆成兩種安裝（Day 4 那兩條路線）、閾值該設多少（Day 7 那六個魔術數字）、哪些規則先做哪些延後。

三、畫紅線。 有些東西 AI 不會知道不能碰，因為那不在程式碼裡。專案的對外定位、哪些用語有風險、哪些比較不能做，這些只存在於人的判斷。我把能寫的部分寫進給 agent 讀的專案說明，但寫得再細也有漏，因為紅線的本質是「情況出現才知道要不要踩」，列不完。

四、驗收。 跑掃描、看結果、判斷這條報得對不對。

前三件是判斷，第四件是勞力。AI 可以幫你寫程式，但決定不了那些數字該是幾。

這聽起來很像場面話，所以講具體一點。那六個魔術數字，AI 不會主動問我「這裡要幾」，它會自己填一個看起來合理的值然後繼續往下寫。等我發現的時候，那個寫法已經在幾十條規則裡形成慣例了。不是它擅自決定，是我沒說，而它總得填一個。

所以真正的工作不是事後 review，是在它動手之前，把該我決定的東西先決定完。

什麼時候我會推翻它

不是「AI 寫錯了所以要改」——那叫除錯。我說的是它寫出一個能跑、也合理、但我不要的東西。

第一類最值得說。Day 6 那次碼表對帳，自動配對是很誘人的做法：兩邊都標了 WCAG 準則，配起來又快又整齊。

但準則相同不等於檢查相同。 這件事程式看不出來，要讀完兩條規則的實際邏輯才知道。那個「不要相信看起來對齊的東西」的直覺，是這四類裡最難交出去的一件。

review 的重點變了

以前 review 別人的程式碼，看的是「這樣對不對、有沒有 bug」。

現在多了一個問題：下一個 agent 接手的時候，會不會被這段程式碼帶偏。

具體看三件事：

import 深度    寫錯不會報錯，那條規則會靜默消失（Day 3 講過）
命名一致       新規則會照舊規則的樣子長，一個歪的會傳染
docstring      AI 讀它來理解意圖，寫錯比不寫更糟

第三點最反直覺。一段沒有註解的程式碼，AI 會去讀邏輯；一段註解寫錯的程式碼，AI 會相信註解。錯的說明比沒有說明危險。

這也是為什麼我不太在意「這段能不能再短一點」。可讀性在這個工作流裡的定義變了：不是給人讀得順，是給下一輪的模型讀得不會誤解。

一個真的架構決定

舉一個完全是人做的決定。

工具做到 0.3.0 的時候，我想讓 AI 寫程式前先查規則。當時的做法是把規則知識寫成一份給 AI 讀的說明文件 「散文形式，一條一條列出來」。

那份文件有兩個問題。第一，它跟程式碼是兩份來源，規則改了文件不會跟著改；第二，AI 只能整份讀進去，沒辦法問「表單相關的 AA 規則有哪些」。

於是改成把規則做成可以查詢的指令：

a11y-moda rules search "label"
a11y-moda rules show HM1130103C
a11y-moda rules list --level AA --topic forms

說明文件不再存規則細節，只教 AI「規則細節要去哪裡查」。

差別在於，現在支援五種整合方式（Claude Code、Cursor、Copilot、Aider、通用 agent），五個前端共用同一份規則來源。加一條新規則，五邊同時生效，不用改任何一份說明文件。

兩種都可行，取捨在「知識會不會變」。規則會一直長，所以選右邊。

這個決定 AI 提不出來。 不是它想不到技術做法，是它不知道我打算支援幾個 IDE、也不知道規則會長多快。那是產品判斷，不是程式問題。

而且這個決定有代價：規則細節從說明文件搬進指令之後，AI 要多跑一次查詢才拿得到資訊，不像整份讀進去那麼直接。換來的是不會有兩份不同步的來源。這種取捨沒有標準答案，只有你賭知識會不會變。規範每幾年換一次版，Day 6 那次就一口氣動了 42 個碼，所以我賭會變。

我做錯的時候，它會非常有信心地跟著錯

Day 2 提過一條規則方向寫反：檢查邏輯完整、命名正確、跑起來很順，只有一件事不對 —— 它檢查的是相反的情況。

那不是 AI 亂寫，是我給的題目描述有歧義，而它挑了一個合理但錯誤的解讀，然後把它做得很完整。

這是這個工作流最危險的失敗模式：錯的東西看起來比對的東西還完整。 因為它沒有猶豫，不會在註解裡寫「這裡我不太確定」。

我後來的做法很土：規則寫完之後，先不看程式碼，直接拿真的網站去掃，看報出來的東西合不合理。用結果反推題目有沒有講清楚，比讀程式碼快得多。

這招也解釋了為什麼這個系列每一篇都在跑真的網站。掃描結果是我唯一能用來檢驗「我有沒有把題目說清楚」的東西：程式碼我讀得懂邏輯，但讀不出它有沒有理解我的意思。

今天的重點

• AI 協作的貢獻度，git 量不出來。 78 個 commit 有 42 個標了 AI，但同一天既有標的也有沒標的
• 人做的四件事：架構、取捨、紅線、驗收。前三件是判斷，只有第四件是勞力
• review 的問題換了：不是「這樣對不對」，是「下一個 agent 會不會被帶偏」
• 錯的註解比沒有註解危險，因為 AI 會相信它
• 最危險的失敗模式是「錯得很完整」 —— 題目有歧義時，它會挑一個解讀然後做到底

明天 Day 9：Day 4 說過 146 條規則裡有 50 條 lint 跑得到。那 50 條不是同一份程式碼跑兩次，是另外寫的 50 個檔。