你跳過的規劃,就是你之後要除錯的故障
軟體工程界的每個框架都告訴你要快速前進、儘早發布、在生產環境中迭代。但對於 AI 生成的網站來說,這恰恰相反。這裡的建構器拒絕直接把你的提示串流成程式碼——它會先停下來、寫一份計畫,等你檢視過後才繼續——而這個拒絕正是整條流程其他一切設計的核心。前期慢一點,之後處處省成本。這筆交易我每次都願意做,而且我認為多數主張相反做法的人,根本沒真正見識過猜錯一次在後續要付出多大代價。
這正是計畫存在要防止的失敗模式。你輸入「幫我的工作室做一個預約網站」然後按下執行。系統必須猜測「預約」的意思——是一個日曆小工具、第三方嵌入式服務,還是一個具備衝突檢查的真正預約系統——而且它必須在還沒寫任何東西之前就猜,因為沒有其他順序可以做這件事。在計畫階段猜錯,修正只要一句話、五秒鐘,搞定。在生成的程式碼裡猜錯,你要改的就不再是一句話了,而是要拆解十個已經依賴著錯誤假設的檔案。這兩種情況我都親眼見過。計畫階段的修正只是一次來回對話。生成之後對同一個模糊點的轉向,則是整個丟棄重來。
而且這份計畫不只是待辦清單,這也是大家容易忽略的地方。它是一份契約,系統會堅守到底:一個負責一致性檢查的驗證代理,是必須在建構發布前簽核放行的代理之一,會拿完成的網站跟你核准過的計畫做逐項比對。每個規劃好的頁面都建好了嗎?功能清單跟實際上線的一致嗎?這裡的「完成」不是憑感覺——而是相對於一份寫下來的承諾,可以逐行檢查的。這比「程式碼能跑」更強的保證,而你之所以能得到這個保證,正是因為有一份文件可以拿來對照。拿掉計畫,你就拿掉了這把量尺。
這件事實際上在哪裡最值得
身為主導建構的人,你的影響力是前置的,不論你有沒有去運用它。如果你在意資訊架構、頁面結構、哪些功能該進 v1 還是 v2——那份挑剔在計畫審閱階段的價值,是生成第一版之後的十倍。多花四分鐘重讀一次計畫,勝過來回修正一個已經跑偏的建構。
最明顯的例子是產品類型——純靜態網站、可安裝應用程式、框架建構、具備真正持久化資料的伺服器支援應用程式。它看起來像個下拉選單。其實不是。它是整個流程中最具結構性的選擇,因為它會默默決定十幾件跟網站外觀毫無關係的事。
| 產品類型 | 預覽 | 發佈 | 帳號/資料庫 |
|---|---|---|---|
| 純靜態網站 | 即時,因為只是靜態檔案 | 靜態輸出可以乾淨地直接複製 | 不可能——要求登入功能,等於要求這個類型在結構上根本做不到的事 |
| 框架建構 | 先編譯;編譯失敗會顯示為「無預覽」,而不是「頁面損壞」 | 編譯完成後,同樣走乾淨的靜態複製路徑 | 不可能 |
| 伺服器支援應用程式 | — | 需要真正能運行程序的環境,故障方式也不同——是程序當機,而不是檔案遺失 | 唯一存在帳號與資料庫功能的類型 |
而且你事後無法輕易升級產品類型。從純靜態網站改成伺服器支援應用程式並非一個設定切換——幾乎等於重做一次建構,因為計畫的一半假設(頁面如何載入、資料存放在哪裡、「發布」代表什麼)都是針對舊類型做的。所以就算只有一半把握,也要在規劃階段就講出來:「我有可能需要帳號功能。」規劃了伺服器支援應用程式卻只用到靜態部分,不會有任何成本。事後才發現需要的話,代價就是重建。
評論者說對了的地方
這一切都不是免費的,我也不打算假裝如此。獨立的每次運行工作區意味著你的知識檔案會被重新複製進去,沒有任何東西會回傳到你的機器——如果你的筆電在建構過程中壞掉,這對你有好處,但對延遲不利,因為佈建一個工作區,以及對框架建構而言,在容器邊界內執行真正的依賴安裝,都需要真實的時間。之所以有這個容器邊界,是因為框架建構會執行 `npm install` 以及任意的建構腳本——這些是你沒寫過的程式碼,卻擁有建構時期的權限——如果在沒有隔離的共用主機上這麼做,只需一次依賴混淆攻擊就能碰到另一個租戶的資料。快而不安全的做法是存在的選項,只是不值得這麼取捨。
驗證也是同樣的道理。一個完成的建構不是在生成停止時離開流程;而是在一組獨立的驗證者不再發現值得阻擋的問題時,才算離開:
- 程式碼審查
- 安全性
- 連結與 SEO
- 無障礙
- 符合性
- 一次實際的瀏覽器內執行
這不是一次性通過,而是標記—修正—複查,反覆進行直到沒有人再有意見為止,因為單一次的檢查可能會漏掉自己的修正所引入的迴歸問題。在同一頁面修好一個失效連結,卻不小心破壞了標題階層,正是單次檢查會漏掉、而複查會抓到的那種問題。這個循環誠實的代價是,偶爾建構會在最後多花一分鐘,看起來沒有明顯理由。使用者會注意到那一分鐘,卻不會注意到剛剛為了他們的網站爭論完的六個代理。這是對體驗的合理抱怨——我只是不認為這能成為在爭論根本沒發生的情況下就直接發布的好理由。
