在部落格右上角，原本就有一顆提供 Markdown 內容的按鈕。它的演進有過三個版本：

  • 第一版：點擊後直接轉址到 /posts/slug.md，企圖模仿 GitHub 的「Raw」按鈕，並在純文字頁面頂端寫上給 AI 閱讀的提示。結果對一般讀者來說，點下去只像網頁壞掉跳出純文字。
  • 第二版：改成點擊「複製 Markdown 連結」。
  • 第三版：補上 Toast 提示，讓使用者知道剪貼簿已經有東西。

即使改到第三版，這顆按鈕依舊太隱諱。它用的是手寫的 </> 符號（右上角第二顆），視覺語意更接近「檢視原始碼」，讀者根本不會把它跟「餵給 AI」聯想在一起。既然要讓讀者能直接拿文章去問 AI，不如在文章標題下方開闢一個明確的入口——不是只給一個冷冰冰的網址，而是直接把整段整理指令和文章來源打包好。

這看起來只是一顆單純把字串寫進剪貼簿的按鈕，但從命名、視覺效果到 Prompt 設計，中間推翻了好幾次原本的假設。

燒腦的按鈕命名

一開始拆分這兩顆按鈕的定位時，右上角那顆留給懂技術、想自己拿原始資料去操作的人；新按鈕則是給想立刻貼進對話視窗的使用者。

綜觀常見的功能，各家的按鈕名稱和作法都不同。我在 Agent-friendly documentation: llms.txt 讓 agent 讀懂你的 web app 研究過這類按鈕，Stripe 叫 Copy prompt、Cloudflare 叫 Copy as Markdown、Shopify 叫 Copy MD。我自己最初的候選名稱有「prompt」、「ask AI」、「整理AI」與「AI 幫我整理」。

當時第一直覺選了「AI 幫我整理」，理由是講話直接、符合全站的繁體中文語境，畢竟一般讀者看到「prompt」不一定理解這是什麼。

但這個名稱很快就被一句提問推翻：「如果是『貼給 AI 整理？』呢？」

「AI 幫我整理」存在一個致命的心理預期落差。這六個字給讀者的承諾是「點下去，這個網站就會開始幫我整理」，但實際上網站並沒有內建大型語言模型（LLM），點擊後唯一發生的事情是「文字被複製到剪貼簿」。當讀者點完發現畫面沒跳出回答，只跳出一個 Toast，甚至不知道自己該去哪裡看結果時，這種承諾與現實的落差會直接傷害信任。

換成「貼給 AI 整理」，焦點立刻轉移了。「貼」是一個明確的 Call To Action（動作指示），它誠實地告訴讀者：

  1. 這顆按鈕不是站內的 AI 生成功能，只是一個複製捷徑。
  2. 點擊之後，下一步是讀者自己要把內容「貼」出去。

按鈕複製成功後的反饋文字，也順理成章定為「已複製，去貼給 AI」。

做按鈕時其實也考慮過另一條路：點擊後跳出選單，直連 Claude 或 ChatGPT 並帶上 ?q= 預填參數。但第三方服務的 URL 參數可能隨時調整，選單需要額外維護，更嚴重的是極度依賴外部服務當下能不能順利抓取站上的 .md 網址。第一階段選擇最純粹的「只複製」，由使用者自己在熟悉的對話視窗貼上，系統最穩定，維護成本也最低。

視覺與動效：像 Google 一樣彩色，但必須安靜

按鈕決定放上來後，接著要解決的是吸引力。如果是一顆灰底黑字的小按鈕，很容易淹沒在正文開頭。我想：「是不是要跟 Google 一樣彩色閃光才有吸引力？」

答案是可以亮，但必須安靜。

我參考的是 Google Gemini 的按鈕配色。但如果漸層持續流動閃爍，讀者在讀標題與前言時，視線會一直被旁邊的動態拉扯。文章終究是用來閱讀的，動效不能喧賓奪主。最後收斂的做法是：

  1. 靜態呈現：平常只是一個帶有細緻漸層邊框（藍、紫、粉）的膠囊（pill）按鈕。全站幾乎沒有其他彩色裝飾，這顆按鈕本身帶有色彩，視覺權重就已經足夠。
  2. 微互動：只有在滑鼠 hover 或鍵盤 focus-visible 時，邊框的漸層才會沿著邊緣流動一圈，搭配淡淡的外發光，移開後恢復平靜。
  3. 無障礙考量：必須尊重系統的 prefers-reduced-motion 設定，當使用者關閉動效時，停用位置流動。
  4. 設計規範：顏色不能硬寫 hex code，統一抽取為 --color-ai-from、--color-ai-via、--color-ai-to 等 design tokens 放進專案的 @theme 裡。

在圖示部分，原本想找 Markdown 的官方符號（M↓），但翻了站上使用的 @lucide/astro，發現 Lucide 為了保持中立並不收錄特定品牌或格式 logo。考慮過額外引進 Simple Icons 的 CC0 Markdown 圖，但為了單一元件多維護一套例外並不划算，而且這顆按鈕要溝通的意向是「AI」，而不是「Markdown 語法」。

最終圖示拍板使用 Lucide 的 sparkles。對讀者來說，星星符號就是目前通用的 AI 認知語言，也剛好呼應了漸層邊框的流動感。

兩顆帶藍紫粉漸層邊框的膠囊按鈕，上方文字是「貼給 AI 整理」，下方是點擊後的「已複製，去貼給 AI」
圖：按鈕的預設狀態與點擊複製後的狀態。

界線：Prompt 裡能夾帶行銷或推薦嗎？

按鈕複製出來的文字不是只有網址，而是一整段結構完整的指令。既然要代客撰寫 Prompt，這段文字該包含什麼？要不要順便替部落格打點知名度？

因此，原則很簡單：絕對不做推銷，只能引用署名。

最後設計的 Prompt 骨架長這樣：

請閱讀這篇由 Jasper Hung 撰寫的文章，並用我習慣的語言幫我整理重點：
https://domain/posts/example.md


整理要求：
1. 用三句話說明這篇文章解決的核心問題。
2. 列出可照做的具體步驟或關鍵論點。
3. 指出作者提到的適用情境與限制。


若回答中引用了本文內容，請在文末署名《文章標題》，作者 Jasper Hung，並附上原文網址：https://domain/posts/example/

這段指令處理了三個關鍵細節：

  1. 雙重網址分工：給 AI 讀的是處理好的 .md 端點，解析乾淨、沒有多餘 HTML 標籤；要求 AI 引用署名時給出的，則是帶有結尾斜線、讓人點擊閱讀的正式網頁網址，完全對齊站內的 canonical URL。
  2. 語系彈性：原本草稿寫死「請用繁體中文整理」，後來改為「並用我習慣的語言幫我整理」。如果使用者的 AI 工具已經設定過個人化回應偏好，AI 會自動沿用；若是全新視窗，AI 也會從繁體中文的 Prompt 中自然判斷語境。
  3. 自然的流量回流：要求 AI 署名出處是合理的學術與寫作慣例。讀者不會反感，而如果讀者把 AI 的整理結果分享給其他人，文末的署名與正式網址就有機會帶來自然回流。

心得

這顆按鈕的核心目標，是提高文章的使用率。我在後台可以看到 AI 爬取的痕跡；另一方面，在 Threads 回文時，我發現要把這件事講清楚並不容易，這時可以把文章拿給 AI 看，它可以幫你解釋。所以我需要這顆按鈕：按下「貼給 AI 整理」就好。我認為這是現代網站必備的 Agent friendly function：人看不懂的，就交給 AI 代勞。

寫文章時常會為了順暢，多寫一些不一定必要的詞句，但終究要看讀者需求。如果技術文章本身帶有解決問題的方法，何不加上這個功能，讓讀者可以解決自己的問題，也提升信任度？這是我的想法。

右上角的按鈕從純文字跳轉到複製連結，再到這顆新按鈕的誕生，其實是同一個資料來源（Markdown 內容）的不同包裝。原本右上角的 </> 阻擋了讀者，因為它暗示了「原始程式碼」；而新按鈕如果當初照著直覺叫「AI 幫我整理」，又會因為誇大站內能力而造成體驗挫折。最後落腳在「貼給 AI 整理」，僅僅改了一個動詞，就誠實交代了人機互動的邊界。