把網站截圖交給 AI，再說一句「幫我改好看一點」，很容易得到一份看似完整、卻不知道該貼到哪裡的程式碼。等到真的套進網站，又可能發現其他頁面的按鈕也跟著變了。
請 AI 修改網站前，先提供要改的頁面、目前問題、使用環境、相關原始碼，以及完成後的判斷方式。如果還沒確定修改位置，可以先請它分析與列出缺少的資料，把確認需求與實際寫入分成兩步。
下面用一個假設的 WordPress 首頁按鈕案例，整理一份可以複製改寫的需求表。這是需求撰寫示例，示例中的版面與尺寸不是所有網站都適用的標準。
先把「改好看」換成看得見的問題
「手機版很亂」「速度太慢」「幫我優化 SEO」都能表達不滿意，但還不能讓接手者知道要從哪裡改。先挑出一個會影響訪客的問題，描述發生位置、操作與結果。
例如，把「首頁按鈕不好看」改成：「首頁服務介紹下方的聯絡按鈕，在 390 像素寬的手機畫面中分成兩行；我想讓文字保持一行，按鈕仍留在原本的內容區域內。」如果只在某個瀏覽器或登入狀態出現，也要一起寫上。
這樣的描述讓你和 AI 有同一個檢查目標。若結果只把字縮小到難以閱讀，就算文字變成一行，也還沒有解決問題。
GitHub 的 Copilot 提示指引建議先交代目標，再補具體要求、相關情境與示例，並把複雜工作拆小。用在改站需求上，可以先處理這一個按鈕，再談整頁配色與排版。
請 AI 改站前，準備這六類資料
| 資料 | 要提供甚麼 | 常見漏項 |
|---|---|---|
| 目標頁面 | 頁面網址、區塊名稱、操作步驟 | 只說首頁，沒有指出哪個按鈕 |
| 目前問題 | 實際畫面、預期畫面、出現條件 | 只有截圖，沒有說哪裡不對 |
| 網站環境 | 系統、佈景、編輯器、相關版本 | 把頁面編輯器當成網站系統 |
| 相關內容 | 必要的 HTML、CSS、錯誤訊息 | 省略上層容器或既有樣式 |
| 修改範圍 | 允許調整的位置、要保留的功能 | 沒有說明其他頁面要維持原樣 |
| 完成條件 | 要檢查的畫面、操作、還原方式 | 只要求產生程式碼，沒有檢查方法 |
截圖要和操作條件一起給
截圖能說明結果，但看不出所有原因。按鈕換行可能與文字、字體、容器寬度或既有樣式有關；只提供一張圖片，AI 無法確認是哪一項造成。
可以各附一張桌面與手機畫面，標出要調整的位置，並說明瀏覽器視窗寬度、是否登入，以及是否要先展開選單才會發生。若手上只有截圖，就明說尚未提供原始碼，請 AI 先列出需要核對的項目。
環境名稱要寫到會影響修改位置的程度
「網站用 WordPress」還不夠。再補上佈景主題、使用原生編輯器還是頁面編輯器，以及這個區塊是單頁內容、共用範本或外掛產生的。
知道版本就附版本；不知道就標示待查，不猜一個看起來合理的數字。若你不能直接修改佈景檔，也應說明目前能使用哪些後台設定或由誰協助部署。
可以直接改寫的 AI 改站需求表
把下列欄位填成自己的情況即可。網址可先用測試站或代稱；真正需要定位頁面時，再提供合適的資料。
網站與目標
系統／版本：
佈景主題／頁面編輯器：
目標頁面與區塊：
希望解決的一個問題：
目前情況
操作步驟：
實際結果：
預期結果：
瀏覽器、畫面寬度、登入狀態：
相關截圖、HTML／CSS 或錯誤訊息：
範圍與交付
允許修改的位置：
必須保留的頁面、功能與內容：
請先說明原因、定位方式與缺少的資料。
資料不足時不要猜選擇器或直接改檔。
提出方案時列出修改位置、變更與還原方法。
完成後怎樣檢查
要核對的桌面／手機畫面：
要實際操作的連結、表單或按鈕：
要一起檢查的其他頁面：需求表不用一次填得很長。若只是修一個換行問題，相關區塊與樣式通常比全站檔案更有幫助。若 AI 已能讀取專案，也可以直接指出檔案與元件，讓它確認現有結構後再提方案。
示例：只改首頁的聯絡按鈕
以下是假設情境，示範怎樣把需求縮到可以檢查的範圍：
我的網站使用 WordPress，首頁由頁面編輯器製作。我想調整服務介紹下方的「聯絡我們」按鈕。桌面看起來正常，但在 390 像素寬、未登入的手機畫面中，文字會換成兩行。
請先根據附上的區塊 HTML、現有 CSS 與兩張截圖，確認原因及可限定首頁這個區塊的修改位置。維持原本字級、按鈕文字、連結與桌面外觀，不改其他頁面的按鈕。
若需要補上層容器或其他樣式，先指出缺甚麼。確認方案後，再提供必要的變更與還原方法。完成時檢查桌面、手機、另一篇文章的按鈕，以及實際連結是否仍指向原位置。
這份需求沒有指定一個尚未查證的 CSS 選擇器，也沒有一開始就要求全站新增覆蓋規則。接手者能先找原因，你也能用同一組條件確認結果。
若你希望 AI 直接操作檔案，還要說明允許它寫入的目錄、是否為測試環境，以及哪些步驟由你操作。能提供建議與能直接修改正式站，是不同的授權範圍。
給相關資料就好，先移除秘密與個資
不要為了讓 AI「了解完整環境」，直接貼上整份設定檔、資料庫匯出或客戶訂單。先擷取與問題有關的片段，移除密碼、API 金鑰、連線字串、Cookie 與私人聯絡資料。
假設錯誤與表單欄位有關，可以用虛構姓名與測試資料重現，保留欄位結構和錯誤條件。遮掉的地方也要註明，例如「此處已移除金鑰」，避免讓接手者把替代文字當成原始設定。
不同 AI 服務的資料處理方式與帳戶設定可能不同，提交前應查看你正在使用的服務說明；這份需求表不需要任何管理員密碼或登入憑證。
修改前約好還原方式，修改後照原需求檢查
拿到修改方案時，先看它準備改哪裡、為何能限定範圍，以及失敗後怎麼還原。對較大的變動，可以先在與正式站分開的測試站驗證。Elementor 將 staging site 說明為可供測試與評估變更的網站副本；是否有這項服務，仍要看你的主機與方案。
若要備份 WordPress，則要分清檔案與資料庫。官方文件指出，一般網站的完整還原需要這兩部分。若只調整一小段設定，也應另外保留該位置的修改前內容，讓維護者知道怎麼撤回這次變更。
完成後，重新走一次需求表中的操作，逐項核對：
- 原本的問題是否已解決，文字、連結與功能是否仍正確。
- 桌面與手機是否都能正常閱讀及操作。
- 共用同類元件的其他頁面，有沒有受到影響。
- 修改位置、原因與還原方式是否已記錄，方便下次維護。
如果這次的目標只是按鈕不換行，就先完成這件事。配色、動畫與內容改寫可以另外列需求，避免幾種變動混在一起，出了問題卻不知道從哪裡查。
還在選擇建站工具，可以先看AI 建站平台與 WordPress 的選擇比較，確認未來由誰改站與維護，再把需求表交給實際接手的人。
