AI 程式碼怎麼驗收：從本站建置流程看五層檢查

2026-09-16 修訂：原稿的「十倍」、特定 PR 檔案與測試數，以及「十次有兩次忘記」沒有附可回查紀錄，本次撤下。原稿也把建議採用的設定寫成本站已全面啟用；以下改以目前的設定檔與建置腳本說明哪些防線確實存在。

這個網站的文章有兩份呈現：React 頁面給使用者看，建置時產生的 HTML 給不執行 JavaScript 的讀取者看。只在瀏覽器看到新段落，還不能證明初始 HTML 也有內容。這是本站需要建置閘門的具體原因。

第一層：型別檢查，與它擋不住的事

本站 tsconfig.app.json 啟用了 strict、noUnusedLocals、noUnusedParameters、noFallthroughCasesInSwitch 與 noUncheckedSideEffectImports。它沒有啟用 noUncheckedIndexedAccess 或 exactOptionalPropertyTypes，不能把後兩項寫成已落實的措施。

{
  "strict": true,
  "noUnusedLocals": true,
  "noUnusedParameters": true,
  "noFallthroughCasesInSwitch": true,
  "noUncheckedSideEffectImports": true
}

如果想進一步檢查動態索引或可選屬性，可以評估後兩個選項；但既有專案應先看新增錯誤與遷移成本。型別檢查也不能證明資料正確：型別斷言可以繞過部分檢查，外部 JSON 仍需要執行期驗證。

第二層：區分有 Lint 設定，與發布時真的執行

本站 ESLint 使用 JavaScript、TypeScript、React Hooks 與 React Refresh 的推薦設定，另有 npm run lint 指令。目前 npm run build 沒有串接 lint。存在設定檔，不代表每次部署都已通過該檢查；本文不把 lint 描述成已強制執行的發布閘門。

要把規則變成團隊要求，還得讓執行流程確實呼叫它，決定警告是否阻擋，以及例外如何審查。直接宣告「所有 any 一律禁止」卻不確認規則、範圍與既有錯誤，無法交代實際狀態。

第三層：驗證讀者實際收到的 HTML

本站建置會先產生並驗證文章資料，再依序執行 TypeScript、Vite、語系入口與預渲染，最後檢查內容與發布範圍。check-prerendered-html.mjs 讀取生成後的檔案，檢查必要路由是否存在、主要內容是否為空殼，以及 H1 數量。它檢查的是輸出，不只是來源元件。

npm run articles:generate
npm run build
# build 的最後兩道檢查
node scripts/check-prerendered-html.mjs
node scripts/check-publisher-scope.mjs

內容長度在這裡只是攔截空殼頁的工程條件，不是文章品質評分，更不是 Google AdSense 的字數門檻。即使建置通過，讀者是否得到有用答案仍要人工檢查。

第四層：把跨頁面的限制寫成可失敗的檢查

check-publisher-scope.mjs 會比對 sitemap、canonical、noindex 與廣告腳本。文章預期載入一份 AdSense 腳本，其他頁不應載入；原始資料與工具頁的索引政策也要一致。這是本站採用的投放範圍，不是所有網站都必須採用的 Google 規則。

這種檢查要用一個反例驗證：在可丟棄的建置副本，把廣告腳本加入首頁，再執行檢查，應該得到非文章頁載入廣告的失敗訊息。這比只看正常情況通過，更能確認閘門真的會攔錯。下載包附有本站檢查腳本與操作說明；不要在正式站直接製造錯誤。

第五層：測試規則也需要審查

測試應來自需求或既有契約，不能只重述目前實作。例如除以零該拋錯還是回傳特殊值，要先由產品規格決定；把測試改成接受實作的任意結果，不會讓需求自動成立。這是說明測試設計的例子，不是前述 PR 的真實紀錄。

最後的人工審查仍要看失敗路徑、舊資料相容性、重複實作，以及測試有沒有偷偷改掉原本承諾。本站的 HTML 閘門可以找到廣告範圍錯誤，卻不能判斷一篇評論的證據是否足夠。兩件事都需要有人負責。