Claude、Codex 滾動動畫提示詞:六個名詞如何寫成可驗收需求?

Claude、Codex 滾動動畫提示詞怎麼寫?本文解釋六種效果,附可改寫的頁面需求,涵蓋觸發範圍、手機、鍵盤、減少動畫與具體驗收。

Share
原作者 Gabriell 公開的原始展示畫面
原作者 Gabriell 公開的原始展示畫面;本文範例不代表本站實測。 圖片來源:原作者 Gabriell。

想讓 AI 做一個「往下滑很有設計感」的網頁,結果卻常出現亂跳、難閱讀或停不下來的動畫。

最近 X 上一份六種滾動效果的視覺示例受到關注,提供了更清楚的溝通起點:先說明動畫如何跟滾動互動,再指定畫面、範圍與手機行為。

原作者示例包含 Scroll-triggered、Scroll-linked、Parallax、Sticky、Scroll Snap 與 Horizontal Scroll。

本文依實際示例畫面與 MDN 文件,將這些詞整理成可交給 Claude 或 Codex 的需求。這是提示詞與驗收指南,沒有把社群展示當成大廠官方功能,也沒有實測某個模型的完成率。

原作者 Gabriell 公開的原始展示畫面
原作者 Gabriell 公開的原始展示畫面;本文範例不代表本站實測。 圖片來源:原作者 Gabriell。
0:00
/0:00
官方或原作者展示影片,用於理解操作與效果;未表示本站已完成相同實測。 影片來源:原作者 Gabriell。

先區分進入畫面後播放與跟著滾動變化

Scroll-triggered 可以理解為到達某個條件後觸發動畫,例如卡片進入畫面,再用短時間淡入。使用者停止滑動後,這段動畫仍可能按時間播放。

需求要說清楚觸發位置、播放多久,以及再次進入是否重播。

Scroll-linked 則讓動畫進度跟滾動位置一起變化。頂端閱讀進度條可以隨文章向下逐步增加。使用者往上回滑時,進度也會回退。這裡要指定控制它的是整頁還是某個容器,避免模型連到錯誤範圍。

這個區分很實用。如果你想要卡片進場一次,卻只寫「隨 scroll 動」,模型可能做成每次滑動都晃動。先說行為,再決定實作方式,比堆疊效果名稱更容易得到符合需求的結果。

Parallax 應說清楚哪一層移動

Parallax 常用不同的移動速度形成前後層次。需求中應指定前景、背景與文字各自怎麼動。例如背景緩慢移動,正文保持正常閱讀。只寫「加視差」,模型需要自行猜哪些元素能變化。

可以先限制在一個介紹區塊:背景圖沿垂直方向小幅移動,標題保持清楚,離開區塊後結束。移動距離是你設計的條件,應配合實際畫面調整。不能從社群短影片直接推論適合每種圖片的數值。

文字密集的區域通常先保留穩定閱讀。若動態會讓字一直飄,讀者可能更難找到重點。視差可以服務層次,但正文仍需要清楚的順序與足夠停留時間,不能用動態代替內容安排。

Sticky 是位置行為,先定義停留範圍

Sticky 讓元素在特定滾動範圍保持位置,例如章節標題或旁邊的示意圖。這與把整個頁面永久固定不同。需求應說明它從哪裡開始停留、距離視窗頂端多少,以及到哪個容器結束時離開。

MDN 的定位文件指出,sticky 會受滾動祖先與偏移設定影響。因此看到元素沒黏住時,應先檢查容器與位置條件,而不只是要求 AI 增加動畫。排版結構可能才是問題來源。

第一次可以讓一張步驟圖在桌面側欄停留,右側文字正常滾動。手機改為圖文依序排列,避免固定圖佔掉大半螢幕。將這兩種行為一起寫進需求,就能減少桌面做好、手機卻難讀的情況。

Scroll Snap 處理停留位置

Scroll Snap 的目的是讓滾動停在預定位置,例如橫向卡片靠齊容器。它不是影片分鏡,也不代表每個區塊都應強制佔滿全螢幕。先指出哪個容器、哪個方向與哪些卡片需要對齊。

對內容頁,可以先採用較溫和的設計要求:讀者滑動時自然接近卡片起點,仍能自由讀完文字。若強制停留會讓長卡片內容難以接觸,就要調整容器與對齊策略,而不是繼續增加吸附強度。

驗收時不要只試一次向前滑。回滑、短距離滑動、觸控與鍵盤操作都可能揭露不同問題。需求應讓讀者能到達每項內容,不能為了展示整齊,把真實文字留在看不到的位置。

Horizontal Scroll 先決定真正的操作方式

橫向內容可以在自己的容器內左右移動,也可以把一段頁面的垂直滾動轉成橫向移動。兩種設計對讀者的預期不同。提示詞應先說清楚你要哪一種,不要只要求「做橫向滾動」。

第一次較容易控制的需求,是讓三張案例卡在自己的容器內橫向滑動,整頁仍維持正常垂直閱讀。桌面保留清楚的操作入口,手機可左右滑,卡片中的連結仍能使用。這是本文示例安排,不是原作者提供的唯一做法。

如果確實要將垂直滾動轉為橫向動畫,先限定區塊與結束點。讀者離開後應能繼續往下,不應被困在同一個區域。長文、表單與主要導航通常需要特別檢查,確保效果不妨礙任務。

選一個工作情境,再組合少量效果

以課程介紹頁為例,讀者需要了解內容、比較適合對象,最後找到報名方式。可以用 Scroll-triggered 讓少量特色卡片進場,再用 Sticky 讓步驟圖與說明並排。

先把這兩個效果做好,不必一次使用六種。

動畫應在讀者需要的地方出現。特色卡的進場幫助辨認重點,步驟圖停留幫助對照文字。報名按鈕則保持穩定,容易找到。若每一段都以不同方式移動,讀者可能花更多時間追畫面。

先寫好沒有動畫也能完成任務的版面,再加入效果。這樣瀏覽器不支援某項功能、使用者偏好減少動畫,或手機需要簡化時,內容仍有完整閱讀路徑。

一份可直接改寫的需求示例

可以將以下需求交給程式助手:「這是三步驟課程介紹頁。保留目前文字與報名連結。桌面讓左側示意圖在步驟容器內 sticky,距頂端留出導覽列空間。右側三段文字正常滾動。

每張特色卡首次進入畫面時短暫淡入一次,回滑不重複播放。」

再補手機與完成條件:「窄螢幕改成圖文依序排列。減少動畫偏好下,所有內容直接可見。新增效果後,請檢查報名連結、導覽列與最後一段仍可到達,並說明這次修改了哪些元件。」

這份提示詞沒有指定新框架,適合讓助手先讀取現有專案再選實作。若你已有技術要求,可以明確補上。若沒有,就先要求使用現有依賴,避免為了簡單動態更換整個頁面架構。

如果需要滾動進度,就另外指定對映

比如閱讀進度條,可以說「以正文頂部到正文結尾為零到百分之百,來源區不計入」。這比要求「看起來像進度」更可檢查。正文範圍改變時,也能知道哪些條件需要重新確認。

區塊動畫也可以寫成開始、結束與中間狀態。元素進入某個視窗位置時開始,到另一個位置時完成。使用者回滑時按同一條規則恢復。數值應在實際版面中調整,不要把示例距離當成固定答案。

需要暫停或保持某個畫面時,說清楚它與滾動位置的關係。否則模型可能改成定時動畫,看起來相似,操作卻不同。需求的重點是互動行為,而不是隻指定一個外觀。

修改範圍先限制在受影響的元件

把頁面路徑、區塊名稱與需要保留的資料提供給助手。可以要求先檢查目前結構,再修改相關樣式與元件。小型動畫通常不需要重新整理所有檔案,尤其已有可用頁面時,先保留真實內容與操作。

若需要新增依賴,要求說明它解決哪個現有方式難以處理的問題。並不是所有滾動效果都需要專用動畫套件,實際選擇應看瀏覽器支援、現有架構與維護方式。本文不替未知專案指定通用最佳庫。

每輪只增加一種主要行為。先確認 sticky 的範圍,再加入卡片進場。發現問題時,就能比較是哪一次修改造成。若一次改排版、字型、動畫與資料,很難判斷結果為何偏離。

驗收先看人能否完成原本工作

開啟頁面從頭讀到尾,確認主要文字、按鈕與連結都能到達。再看動畫是否在指定範圍開始與結束。這個順序能避免只稱讚動態好看,卻漏掉報名按鈕被遮住的實際問題。

桌面與手機分別檢查。視窗高度不同,sticky 停留範圍與橫向卡片可見範圍也會變。用實際內容而非短占位文字,才能看出長標題、換行與圖片比例是否影響操作。

如果要交給同事,可以留下幾個可復現步驟:首次向下滑到卡片、回滑、使用連結,再從手機寬度讀到最後。完成條件越具體,同事越容易確認哪些行為已通過檢查,哪些還需要調整。

瀏覽器支援先按實際讀者條件選擇

MDN 的各項屬性頁有相應支援資訊,實作前讓助手核對專案需要的瀏覽器。新功能在某個桌面版本可用,不代表你的讀者全部能看到相同效果。應保留可閱讀的基本畫面,再把動畫當成增強體驗。

如果現有框架已有相應做法,先評估是否能滿足需求。需要回退時,說清楚無動畫版本仍要保留哪些內容與操作。這比為了模仿示例而引入多套處理方式更容易維護,也能讓同事知道功能不足時會呈現什麼。

瀏覽器差異的驗收可以聚焦在新增效果。基本版面已經穩定,就不需要為了一張卡片的淡入重新測所有頁面。發現新的遮擋或操作問題時,再擴大到受影響的範圍,讓檢查與實際變更相對應。

鍵盤與減少動畫模式保留完整路徑

如果橫向卡片包含按鈕,試著用鍵盤依序到達每個連結。焦點進入卡片時,重要內容應能看見。畫面位置改變後,也要知道焦點在哪裡,避免外觀滑得很順,使用者卻無法完成點選。

減少動畫模式可以直接呈現文字與圖卡,保留相同順序和連結。這是一項可以交給助手的具體完成條件:切換相關偏好後,原本藏在進場效果裡的內容仍然可讀。

它不需要再做另一個華麗效果,只需讓原本任務持續可完成。

常見失敗:動畫成功了,內容卻暫時消失

有些進場效果會先把元素設成不可見,再等觸發。如果程式初始化失敗,讀者可能始終看不到內容。需求可以要求保留合理退化方式,讓動畫能力不足或腳本未執行時仍能讀到正文。

另一種問題是固定區塊遮住下一段。先檢查停留範圍、容器高度與導覽列位置,確認元素在應結束的地方離開。不要只加更高層級,把遮擋問題轉移到其他元件。

橫向區塊也容易讓頁面整體溢位。檢查真正應滑動的容器與整頁寬度,確保其餘文字不需左右拖動才能看完。問題定位到容器後,再修改受影響樣式,不必把整頁內容縮小。

用具體回饋取代「再順一點」

回報「第三張卡進入太晚,文字已讀完才淡入」比「動畫怪怪的」更有幫助。也可以說「手機上示意圖佔滿畫面,第二段看不到」,讓助手理解是哪個條件失敗。

先記錄看到的結果,再描述希望的行為,最後給檢查方法。這種回饋能讓下一輪對應一個問題。修正後復跑受影響的區塊即可,沒有新改動時不需要反覆檢查無關頁面。

六個名詞的價值,是讓你把視覺想法說成可執行需求。先選定觀看情境、定義滾動關係,再確認文字與操作仍可用。

Claude 或 Codex 才能根據清楚的完成標準修改,而不是猜一個「很有科技感」的頁面。

資料來源