提示詞指南

從專案聊天開始。 開啟你想修改的專案聊天，然後選擇或指派與該工作角色相符的智能體。如果你不確定哪個智能體適合，請先請團隊釐清，再開始建構。

本指南整理了能持續從你的智能體團隊獲得更好成果的技巧。這些技巧都不需要特殊能力。重點在於你說了什麼，而不是你如何排版。無論你是在撰寫第一個請求，還是在優化一個成熟專案，同樣的原則都適用：輸入清晰的思路，輸出清晰的結果。

先讓團隊提問，再開始建構

想得到更好結果，最有效的方法之一是：當請求很大或很模糊時，主動邀請提問，而不是期待團隊猜對。先說明你想要什麼，然後在最後加上一行：

在你開始之前，請先問我任何你需要知道、才能完全理解我需求的問題。

你通常會收到一些你自己未必想得到要先回答的問題，無論是關於邊界情況、目標受眾，還是取捨。先花一分鐘把這些問題釐清；等到建構完成後才發現，代價就是重做。這樣一來，第一次產出的結果就會更接近你的原意。

第 1 步：在輸入前先做決定

先知道你要建構什麼

一開始先花幾分鐘思考，之後往往能省下大量反覆重下提示詞的時間。在開始之前，請確認你能回答四個簡單問題：你要建構什麼、是為誰而做、他們為什麼會使用，以及你希望他們採取的主要行動是什麼。

這個主要行動通常稱為 CTA，也就是 call to action（行動呼籲）的縮寫。它是你最希望使用者點選的按鈕、連結或下一步，例如 Sign Up、Book a Demo、Start Free 或 Buy Now。

你不需要寫出完整規格。目標只是為專案提供清楚的方向。你的起點越具體，就越容易產出符合你想法的結果。

為一款面向自由工作者的預算管理 app 建立一個單頁網站。主要 CTA 是「Start Saving Smarter」。使用大膽、有表現力的風格，搭配大型字體與鮮明色彩。

規劃的是旅程，不只是畫面

好的設計不只存在於單一畫面上，也存在於畫面與畫面之間。走一遍使用者的路徑：他們第一眼會看到什麼、什麼能建立信任、什麼能讓他們更有信心採取行動，而那個行動又會把他們帶到哪裡？即使只是三段式草圖，例如主視覺、證明、行動呼籲，也能讓你的請求有效許多，因為現在每個區塊都有存在的理由，也有引導到下一步的理由。

及早設定視覺方向

風格比起事後補救，更容易在一開始就建立好。先選定一個方向：平靜且優雅、大膽且顛覆、高級且俐落，並在第一個請求中用團隊可執行的語氣詞說明，例如極簡、活潑、電影感、面向開發者。這些詞不只是裝飾：它們會從第一個元件開始影響字體、間距、色彩、陰影與圓角半徑。在後續請求中重複使用同一條風格描述，能讓整體保持一致。

使用平靜、受健康療癒啟發的設計：柔和漸層、低飽和大地色、圓角、寬鬆留白。整體語氣溫和且令人安心。

第 2 步：寫出真正有效的請求

描述成果，不是實作方式

描述你想要的結果，而不是建構它的步驟。例如，「加入一個有三種方案的價格區塊，並讓中間那個特別突出」就比詳細說明頁面該如何組成更有幫助。把重點放在應該出現什麼，以及它為什麼重要；至於怎麼建構，團隊可以自行決定。

以區塊為單位，不要一次做整頁

把請求範圍限定在單一元件上——像是主視覺、功能卡片區、推薦語列、價格表——能讓你更清楚，也更容易掌控。如果某個區塊不理想，你只需要調整那個區塊，而不是把周圍所有內容一起重生。先建一個區塊、檢查、微調，再進到下一個。整頁請求會產生雜訊；元件請求會產生明確訊號。

建立一個功能區塊：置中的標題，下方並排三張卡片，每張都有圖示、標題和一行描述。使用柔和陰影，滑過時略微上浮。

使用真實文字

佔位文字會掩蓋問題；真實文案會揭露問題。真實標題可能需要兩行；真實 CTA 可能用動詞效果更好。請寫出使用者實際會讀到的內容，即使還只是草稿也沒關係——當內容是真實的，版面、間距與設計決策都會更好。

主視覺標題：「Design Calmly。」副文：「Turn stress into structure。」CTA：「Start Building Free。」以文案為中心的版面，搭配寬鬆的垂直間距。

指出真實元素

用清楚、具體的詞描述你希望頁面上出現的內容。你不需要懂設計術語——只要說出使用者應該看到或互動的項目，例如個人資料卡、按鈕或表單。

具體的請求比籠統的請求更容易建構。先從你需要的基本元素開始，再一次加入一個細節。

建立一張個人資料卡，包含照片、姓名和追蹤按鈕。在姓名旁加上一個小型「Verified」標籤，並在有人滑過時顯示簡短說明。

第 3 步：精準地修改

為每次修改界定範圍：哪些要變，哪些不變

調整既有內容時，請明確說出兩件事：哪些要改，哪些絕對不能改。使用像是「replace」、「update」和「adjust」這類方向明確的詞，而不是「把這個做得更好」，並把你喜歡的部分圈定保留。這種精準度，正是避免迭代變成退步的關鍵。

把 CTA 文字改成「Get Started」，並增加它的水平內距。保留目前的顏色、字體，以及此區塊中的其他所有內容不變。

一次只做一個有意義的修改

先更新文案，再更新版面，接著更新互動，並在進行下一個請求前檢查每次結果。小而有意識的步驟會累積成精緻的產品；一則訊息裡塞十個修改，只會累積模糊性，而且一旦出錯，你也不會知道是哪個修改造成的。

進行中的任務修正請在聊天中處理。 當你的聊天中可使用 Prompt Queue，且智能體工作正在進行時，後續訊息會排入目前執行工作的後方。請先確認你的訊息已出現在佇列中，再傳送另一份相同內容。如果看不到佇列控制項，請不要重送：等待目前工作完成，或使用你的聊天中提供的中斷控制，然後在傳送後續訊息前確認任務狀態。詳情請參閱 專案聊天。

比 UI 多想一步

如果你的專案不只是要看起來精緻，還需要具備實際行為，請在定義外觀的同時也定義行為。請說明使用者在登入與未登入時會看到什麼、動態內容從哪裡來，以及介面如何處理空狀態、載入中與錯誤狀態。你不需要有可運作的後端才能針對這些情境設計——及早規劃它們，有助於避免之後大幅重做 UI。

如果使用者已登入，在右上角顯示他們的頭像與姓名。如果沒有登入，則顯示一個會導向驗證畫面的「Log In」按鈕。

常見問題

我要如何為 AI 智能體撰寫有效的提示詞？

請用以下關鍵元素來組織你的提示詞：

1. Context — 交代背景。說明你正在建構什麼，以及目前進展到哪裡。

2. Goal — 明確說明你想要的具體結果或功能。

3. Requirements & Constraints — 清楚列出哪些應該修改，哪些必須維持不變。

4. Expected Result — 定義成功的樣子（例如 UI 行為、錯誤處理、狀態持久化）。

5. References — 盡可能附上截圖、連結、流程步驟或程式碼範例。分享前請移除密碼、驗證碼、API 金鑰、cookies、個人資料與付款資訊。

範例：「我正在建構一個帶有側邊欄的儀表板。在側邊欄底部加入一個登出按鈕。它應該清除 session 並重新導向到 /login。不要更動側邊欄版面或導覽連結。點擊後，使用者應在 1 秒內看到登入頁面。」

我該如何處理涉及多個功能的複雜請求？

對於複雜請求，請把它拆成較小的任務：

1. 說明目前的問題與最終目標。

2. 分別列出每個子任務（task 1、task 2、task 3）。

3. 在進入下一個任務前，先驗證每個任務。

4. 最後測試完整流程。

這種做法能降低一次要求智能體做太多事而造成的意外變更。每個提示詞都應聚焦於單一且可驗證的結果。

我要如何撰寫修復 bug 的提示詞？

一個實用的 bug 修復提示詞應包含：

• 頁面、功能、環境，以及受影響的使用者
• 可精確重現問題的步驟
• 實際行為與預期行為
• 完整的錯誤文字，以及錯誤發生的時間點
• 相關截圖或日誌，並已移除密碼、tokens、cookies、個人資料與付款資訊
• 哪些內容必須維持不變
• 如何驗證修復，以及需要執行哪些回歸檢查

範例：「在 Preview 的結帳頁面中，選擇 Submit 會回傳 500 錯誤。預期結果：訂單被確認，且使用者會進入感謝頁面。重現方式：[steps]。請在不更動購物車總額或付款流程的前提下修復原因，然後驗證一個付款成功案例與一個付款遭拒案例。我已從附加日誌中移除所有機密值。」

我要如何撰寫修改頁面版面或樣式的提示詞？

提出頁面修改需求時，請包含：

1. 要修改的具體頁面、模組與元素。

2. 目前狀態與目標結果。

3. 參考連結或截圖。

4. 必須維持不變的功能。

5. 驗收標準（例如桌面版與手機版都必須正常運作）。

範例：「在 /pricing 頁面上，將方案卡片網格在桌面版從 2 欄改為 3 欄。手機版維持單欄版面。參考這張截圖 [attach]。不要更動卡片內容或按鈕樣式。」

如果智能體即使經過修正，還是不斷做出錯誤的修改，我該怎麼辦？

當智能體一再偏離需求時，加入更多指示有時反而會造成更多混亂。請改用以下方式：

1. 保留目前狀態 — 停止傳送彼此重疊的修正。如果你的聊天中顯示 Revert 控制項，請先閱讀其確認文字再使用，記下任何之後需要保留的變更，並在之後驗證專案。如果範圍不清楚，請不要繼續；請參考 Project chat 指引，或附上已遮蔽敏感資訊的 Chat Link 與截圖聯絡 Support。

2. 清除雜訊 — 不要在原有內容上繼續疊加額外指示，而是從頭清楚重述核心問題。

3. 一次處理一個任務 — 先專注修正單一問題，再移動到下一個。

退一步，並以漸進方式處理變更，通常會比試圖在一個提示詞中修復多個彼此重疊的問題，更快解決狀況。