安安～我是ChiYu～

昨天，表單終於能把人從錯誤帶回完成。接著輪到活動內容，AI 很自然地提出一份「功能完整」的升級方案：六格驗證碼、標籤膠囊、色盤，外加一整排編輯工具。

回頭看需求，這扇門確實是我自己打開的：

幫我做一個功能完整的內容編輯與標籤設定畫面，驗證碼要有六格，顏色要能自己選。

下面是依這句 Prompt 還原的第一版：

圖 1：六格 OTP、四顆標籤、完整色盤和十二顆編輯工具同時上線，採用理由仍是空白。

畫面很熱鬧。連一段活動公告，都有一種準備在瀏覽器裡排版雜誌的氣勢。

在 Vibe Coding 裡，「功能完整」很容易被翻譯成「能放的控制都放上去」。第一眼像成熟產品，真的操作後才會發現，有些元件沒有替人省事，只是替驗收多開幾張考卷。

所以我不先問還能加什麼，而是反過來做一個測試：把進階元件拿掉，工作有沒有真的變難？

我把這組比較放在 進階輸入元件完整比較頁：

圖 2：先看固定結構、重複操作與內容交接，再決定進階元件是否值得保留。

拿掉元件測試：工作沒變難，就換回簡單輸入

進階元件會一起帶來狀態、鍵盤操作、手機版處理與錯誤規則。採用前，我先讓簡單版本上場：

這張表不是要把進階元件全部淘汰，而是要求它們先證明自己的工作。拿掉後沒有差，複雜度就沒有留下的理由。

固定結構與重複編輯：OTP、Tag Input 值得留下嗎？

OTP 可以分六格，資料仍是一筆驗證碼

OTP／PIN Input｜一次性密碼輸入欄 適合固定長度、短時間有效的驗證碼。使用者可能逐格輸入，也可能從簡訊或驗證器直接貼上完整代碼。

畫面可以切成六格，但對表單來說，它仍是一筆六位數驗證碼，不是六題小考。

MDN 的範例使用一個 <input> 搭配 autocomplete="one-time-code"、inputmode="numeric" 與六碼長度限制，讓瀏覽器和裝置有機會協助填入完整代碼。MDN：One-time passwords

若真的拆成六個獨立 Input，就要另外處理整段貼上、自動填入、方向鍵、Backspace、跨格焦點與螢幕閱讀器朗讀。只把 autocomplete 放在第一格，剩下五格交給運氣，還不能叫做完成。

圖 3：貼上 482916 後，一筆六碼值顯示在六個視覺位置；畫面仍等待使用者按下驗證。

我按下「貼上範例」後，代碼 482916 被正確分配到六格，狀態顯示「已輸入 6／6 碼」。流程沒有擅自送出，直到我按下「驗證代碼」，才出現已收到代碼的結果。

這就是 OTP 留下來的理由：整段貼上、逐位修正與長度提示確實替使用者省事。六碼輸入完成也不等於同意送出；帳號可能切錯，驗證碼也可能過期，確認按鈕仍有存在的理由。

如果產品只是收分機、電話或一般數字，回到 Text Field 或 Number Input 就好。六格外觀不會讓資料突然變安全。

Tag Input 要能新增、去重與個別移除

Tag Input｜標籤輸入欄 適合文章標籤、收件人或關鍵字。每個標籤都是獨立資料，系統還要處理重複、上限與單一移除。

圖 4：每個標籤都能個別新增與移除；重複及數量上限另有回饋。

我把它換成逗號分隔文字後，新增看起來還算簡單；要刪掉第三個標籤、避免重複，或限制最多五個時，就開始麻煩。只要標籤需要反覆編輯，獨立資料單位就比一整串文字好處理。

LumenDesk 這次允許建立「表單」「Vibe Coding」等新標籤，所以使用 Tag Input。若資料只能選既有部門、角色或專案，應改用不允許新值的 Multi-select 或 Combobox。不要讓欄位看起來能新增，送出時才告訴使用者這個值不算數。

Prompt 還要寫清楚：Enter 或逗號如何新增、最多幾個、空白和重複怎麼處理。每個移除按鈕也要帶上標籤名稱；只有一排叉叉，使用者與輔助科技都得自己猜會刪掉誰。

Tag Input 若另外提供既有標籤建議，也要把「建立新值」和「從建議中選值」分清楚。W3C WAI：Combobox Pattern

顏色需要被挑選、預覽與交接，Color Picker 才真的省事

Color Picker｜顏色選擇器 適合品牌主色、圖表系列色或海報背景色。這些情境裡，顏色不是裝飾，而是一筆要被儲存與交接的資料。

圖 5：色票、即時預覽與 HEX 欄位同步，畫面看得到顏色，也拿得到可交接的值。

如果管理員本來就拿得到 #RRGGBB，普通色碼欄位可能已經夠用。只有需要邊挑邊看、從色票選值，或使用者不熟色碼時，Color Picker 才真的省事。

<input type="color"> 會使用平台自己的選色介面，不同瀏覽器或裝置可能長得不一樣。開工前要先決定產品只收 HEX，還是連透明度、P3 色域、色票歷史與調色盤都要支援。MDN：<input type="color">

對多數內部系統，我會停在「原生選色入口＋即時色票＋可貼上的 #RRGGBB」。格式錯誤時保留原值並說明修法，不要默默改成黑色，好像使用者剛才選的品牌色從來沒存在過。

顏色若代表成功、警告或分類，畫面仍要搭配文字、圖示或可讀名稱。Color Picker 解決怎麼選顏色，不負責替顏色補上語意。

內容編輯只選一套：Rich Text 或 Markdown

Rich Text Editor 給不熟語法的編輯者

Rich Text Editor｜富文字編輯器 適合不想記標記語法的內容編輯者。行政人員發布活動公告，通常只需要標題、粗體、斜體和項目清單。

圖 6：工具列只保留公告需要的有限格式，不把字型、表格與貼圖全部塞進來。

我先換回普通 Textarea。純文字公告仍然能寫；直到非技術使用者真的需要標題、粗體與清單，Textarea 才開始不夠用。因此我保留 Rich Text Editor，但只留下工作會用到的格式。

每多一顆工具列按鈕，都要處理焦點、選取狀態、輸出格式與儲存規則。幾個 Icon 排得很整齊，還不能算編輯器完成。W3C WAI：Toolbar Example

Markdown Editor 保留純文字來源與安全預覽

Markdown Editor｜Markdown 編輯器 適合熟悉標記語法、需要版本控制，或希望內容維持純文字的寫作者。來源與預覽要分清楚：一邊寫 Markdown，另一邊看渲染結果。

圖 7：來源維持純文字，預覽只處理 Demo 支援的標題、粗體與項目清單。

正式產品要先定義允許的語法，拒絕或跳脫未允許的原始 HTML，再交給經過檢查的渲染與清理流程。不能把輸入內容原封不動塞進頁面，然後祈禱大家都很善良。

contenteditable 只代表元素可以編輯，不等於完整 Editor。MDN 也指出 contenteditable="true" 與 plaintext-only 的貼上結果不同；產品仍要決定允許格式、輸出清理與測試範圍。MDN：contenteditable

我不會在同一個欄位同時塞 Rich Text 與 Markdown 兩種模式。行政人員用有限的 Rich Text Editor，技術寫作者使用 Markdown Editor。產品若只服務其中一種人，就只留一套。

改寫 Prompt：先寫採用門檻，再要求進階元件

為內容管理後台建立四個分開的輸入情境，不要把它們堆進同一個萬用欄位。

1. 登入驗證使用六位數 OTP／PIN Input，把六碼視為一筆表單值。優先使用單一語意輸入欄，設定 autocomplete="one-time-code"、inputmode="numeric" 與六碼長度限制；外觀可以分成六個位置。若拆成六個 Input，必須另外驗收自動填入、直接貼上、方向鍵、Backspace、跨格焦點與螢幕閱讀器朗讀。少於六碼時顯示還差幾碼；完成輸入後不要自動送出，保留「驗證代碼」與「重新取得驗證碼」。

2. 文章標籤使用 Tag Input，而且產品允許建立新標籤。輸入後按 Enter 或逗號新增，預設已有「活動」與「Vibe Coding」，最多 5 個。拒絕空白和重複標籤並用文字說明；每個標籤都有「移除標籤〈名稱〉」按鈕。若資料只能選既有分類，改用不允許新值的 Multi-select。

3. 公告編輯只選一套。技術寫作者使用 Markdown Editor：左側保留原始文字，右側顯示安全預覽；Demo 只支援標題、粗體與項目清單，未允許的 HTML 必須跳脫或清理。不熟 Markdown 的編輯者則改用只含粗體、斜體與項目清單的 Rich Text Editor。

4. 品牌主色只有在顏色會被儲存或交接時才使用 Color Picker。使用原生 color input、即時色票與可編輯的 HEX 欄位；HEX 只接受 #RRGGBB，格式錯誤時保留原值並顯示修正說明。

做完後，我會實際貼上六位數、加入重複標籤、輸入錯誤色碼，再確認目標編輯者能不能完成公告。哪個地方讓人停下來猜，就回去減少規則，或換回普通欄位。

最後留下的元件更少，維護成本反而更合理

OTP 保留，因為固定六碼、整段貼上與逐格修正都有實際需求。Tag Input 也留下來，文章標籤確實需要新增、去重與個別移除。

Color Picker 改成條件式採用：品牌色需要挑選、儲存或交接時才出現；只要貼入固定色碼，用 Text Field 就夠了。公告編輯則依使用者選 Rich Text 或 Markdown，不讓同一個人每天先決定今天想維護哪一套來源格式。

複雜度只有在替使用者省下工作時，才值得被我們和 AI 一起維護。

接著我把畫面縮到 360px。桌面 Sidebar 很堅持，別人都在縮，它依然站得筆直。

圖 8：桌機 Sidebar 原封不動搬進手機，選單名稱先被截斷，正文接著被擠到只剩一條窄欄。

畫面確實有 Header、有 Sidebar，也確實塞進了手機寬度。問題是使用者看不清楚選單，內容也沒剩多少位置，還找不到能把導覽關起來的按鈕。

明天，問題會從欄位裡走到全站導覽：Header、Sidebar 與手機高頻入口，到底該怎麼重新分工？

延伸閱讀

• MDN：One-time passwords
• W3C WAI：Combobox Pattern
• MDN：<input type="color">
• W3C WAI：Toolbar Example
• MDN：contenteditable

資料查閱：2026-08-07。