先看成品：它真的已經存在
Lukas Lab 實驗室 是一頁已經公開的靜態網站。它沒有會員、資料庫、後台或複雜互動，只用來展示一件事：Lukas 怎麼跟 AI 一起做系統、做工具，也把中間的翻車與修正留下來。
這一頁的程式本身不複雜。AI 很快就能產生 HTML 與 CSS，做出一個看起來像網站的原型。真正拉開距離的，是原型之後發生的事：範圍被縮小、責任被拆開、交付文件被退件、檢查器被證明不可靠，最後才形成可部署、可回滾、可封存的 v1.0。
一頁靜態網站本身不難；真正有價值的是，人與 AI 如何在七個版本裡，慢慢建立一套不靠印象交付的制度。
這裡說的七個版本，是原型與施工交付包從 v0.1 到 v0.7 的七個版號；正式通過後，才另外以 Git tag v1.0 封存。版本數、退件輪次與翻車事件數，不是同一件事。
原型很快，交付為什麼不能跟著快？
AI 擅長在條件還不完整時先做出一個「很像答案」的東西。這對原型很有用，因為人可以立刻看見方向、指出不對的地方，再決定要留下什麼。
但公開網站不只是一張畫面。至少還要回答：
- 內容是否真的是核准版本？
- 原始檔有沒有在自動修正時被破壞？
- 網址、部署平台與回滾方式是否符合現場？
- 是否含有帳號、憑證、私人資料或未授權內容？
- 誰有權決定部署？誰負責最後驗收？
這些問題不會因為畫面漂亮就自動消失。原型回答「做不做得到」；交付還要回答「能不能負責任地公開」。
七個版本，實際改了什麼？
v0.1：網站有了，交付還沒有
初版完成公開頁面的基本方向，也確立「一頁、一個實驗、先看成品」的原則。但施工文件缺少版本、驗收、回滾與問題回報等必要項目，中文標點也沒有通過精確檢查。
v0.2：把施工文件補齊，部署假設仍未對表
交付包補上必要欄位，卻仍把 GitHub Pages 或 Vercel 寫成可能的部署方式。問題不是這些平台不能用，而是它們並不是現場正在使用的系統。
v0.3：開始按現場說話
這一版改以實際環境為準，加入職位治理、命令效力與部署責任區，也刪除沒有存在的 CI/CD 假設。但它仍只是送驗版本，沒有因為在對話裡被提到，就自動成為 Repo 正本。
v0.4：檢查器進步了，替換器又叛變了
為了修正中文標點，工具開始保護網址與程式碼區段，再處理其他文字。新的檢查邏輯抓到更多錯誤，替換邏輯卻在巢狀格式中還原失敗，把六處內容位置破壞成 NUL 控制字元。
更麻煩的是，原本的自我檢查只驗標點，沒有檢查檔案是否被自己的工具弄壞。因此損壞檔一度通過了檢查。
v0.5：修好檔案，報告裡的數字仍不精確
這一版清除 12 個 NUL，處理六處損壞位置，其中五處恢復為網址，另一處改寫成精確的差異說明；安全查核也新增控制字元掃描。
但交付文字仍沿用事故現場的數字，把「六處損壞」寫成「六個網址」。技術修好了，描述卻沒有重新按修復後的現況計數，因此再次退件。
v0.6：技術查核通過，文字終裁仍能擋下來
計數與檢查用語修正後，技術與安全查核通過。然而文字終裁又發現兩個問題：搜尋摘要裡還藏著半形冒號；文件宣稱「內容檔沒有寫死網域」，實檔卻在頁首與頁尾寫有主站的絕對網址。
v0.7：最後兩粒沙，也要留下證據
最終版只修正搜尋摘要的一個標點，並把網域說明改成符合實檔的精確描述。這兩處不影響肉眼看到的主畫面，卻會影響搜尋摘要與未來接手者的判斷。
完成主官實機確認、文字定稿與安全查核後，核准原始碼才提交、部署，並以 v1.0 封存。
哪些翻車真的改變了制度？
帳目不能憑印象
施工包的項目數曾在對話裡被記錯。這件事看似只是數學失誤，最後形成的規則卻很重要：版號、項目數與完成狀態都不能靠聊天室印象判定，必須回到 Repo 實檔與正式驗收紀錄。
檢查器不能只檢查它想看的東西
標點檢查器通過，不代表檔案完整。從 NUL 事故之後，驗收增加了控制字元、網址、核准差異與輸出內容的交叉檢查。
修好之後，數字要重算
事故有六處損壞，不代表修復結果仍有六個網址。報告只能描述當下真正驗得到的狀態，不能沿用前一輪方便的數字。
<head> 也是公開內容
Meta Description 不一定出現在正文，卻可能被搜尋或分享預覽使用。讀者看不到的地方，仍然屬於公開交付的一部分。
人在哪裡裁決？
AI 可以提出原型、檢查檔案、整理版本，甚至指出另一個 AI 的錯誤；但本次有幾個決定不能由 AI 自行跨過：
- 縮小範圍。 原本可能長成多頁網站與完整內容系統，最後只保留一頁與一件實驗。
- 分開兩道命令。 原型開工只允許本機施工；正式上線必須重新取得授權。
- 設置三關驗收。 主官實機、文字定稿與安全查核缺一不可。
- 決定索引現況。 是否調整搜尋引擎設定，不因網站已完成就順便處理。
- 決定哪些過程能公開。 私人對話、帳號環境與未授權資料不因「實驗透明」而失去邊界。
一句話是：AI 可以把成果送到城門口，但只有人可以決定要不要開門。
讀者可以帶走的五個方法
1. 先做可逆原型，再處理不可逆動作
本機產出與正式部署使用不同命令。即使 AI 搶跑，最遠也只能跑到可回收的位置。
2. 施工者不能同輪自己驗收
寫程式、審文字、管部署與最終裁決分成不同職位。現任可以更換，但責任與交接點不能模糊。
3. 證據有優先順序
本次採用的順序是：Repo 實檔與 Git 紀錄、正式部署版本與前台輸出、核准交付包，最後才是聊天室中的說法。
4. 每次改版都重跑安全查核
前一版通過，不代表下一版沿用。只改一個標點，也要確認沒有順便改壞網址、編碼或公開邊界。
5. 把結果封存成可以接手的資產
正式成果不只存在於線上頁面，還包含 Git tag、部署版本、離線原始碼、檢查碼與施工紀錄。網站可以回滾，方法也能被下一位接手者理解。
這次結果的限制
- 「十分鐘」是用來對比 AI 原型速度與可靠交付成本的說法，不是本次經過碼表驗證的精確工時。
- 這是單頁、無資料庫的靜態網站案例，不能直接代表所有軟體專案都需要七個版本。
- v0.1 到 v0.7 是版號，不等於七次退件，也不等於七次獨立翻車。
- 中間版本並非全部保留在正式 Repo；版本沿革以核准交付包與最終封存資料重建。
- 本文只公開能由實檔支持的工作方法，不公開私人對話原文、帳號資訊或平台內部識別。
最後留下的，不只是一頁網站
AI 的速度沒有因為這些規則而失去價值。相反地，快速原型讓人更早看見問題；真正需要補上的，是速度之後的責任。
這次封存的不只是一頁網站，而是一套能讓 AI 動手、讓制度煞車、最後仍由人負責開門的工作方法。