Atoms
Project chat

提示詞指南

先想清楚再輸入、分段建構、使用真實內容,並把每個請求交給合適的智能體。這些習慣能把一行想法變成完成的成果。

先想清楚再輸入、分段建構、使用真實內容,並把每個請求交給合適的智能體。這些習慣能把一行想法變成完成的成果。

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

本指南整理了能持續幫助你的智能體團隊產出更好結果的技巧。這些技巧都不需要特殊能力。重點在於你說了什麼,而不是你如何排版。不論你是在撰寫第一個請求,還是在優化一個成熟的專案,同樣的原則都適用:想法清楚,結果就清楚。

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

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

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

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

步驟 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」這類有方向性的詞,而不是「make this better」,並把你喜歡的部分明確圈定保留。這種精準度,正是避免迭代變成倒退的關鍵。

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

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

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

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

比 UI 多想一步

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

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

常見問題

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

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

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

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

3. 需求與限制 — 清楚列出哪些應該修改,哪些必須保持不變。

4. 預期結果 — 定義成功的樣子(例如 UI 行為、錯誤處理、狀態持久化)。

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

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

如果是涉及多個功能的複雜請求,我該怎麼處理?

對於複雜請求,請把它拆成較小的任務:

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

2. 分別列出每個子任務(任務 1、任務 2、任務 3)。

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

4. 最後測試完整流程。

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

我要如何撰寫用來修復 bug 的提示詞?

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

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

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

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

提出頁面修改請求時,請包含:

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

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

3. 參考連結或截圖。

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

5. 驗收標準(例如必須同時支援桌面與行動裝置)。

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

如果智能體在修正後仍持續做出錯誤變更,我該怎麼辦?

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

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

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

3. 一次一個任務 — 先專注修正單一問題,再進到下一個。

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

這個頁面有幫助嗎?

相關文章