安安～我是ChiYu～
昨天，表單終於可以把人從錯誤帶回完成。接著輪到活動內容，AI 很自然地提出一份「功能完整」的升級方案：六格驗證碼、標籤膠囊、色盤，外加一整排編輯工具。
回頭看我的需求，確實是自己開的門：
幫我做一個功能完整的內容編輯與標籤設定畫面，驗證碼要有六格，顏色要能自己選。
昨天結尾留下的，是依照這句 Prompt 還原的第一版問題現場。
圖 1：和昨天結尾是同一張還原畫面。六格 OTP、四顆標籤、完整色盤和十二顆編輯工具同時上線，採用理由仍是空白。
畫面很熱鬧。連一段活動公告，都有一種準備在瀏覽器裡排版雜誌的氣勢。
在 Vibe Coding 裡，「功能完整」很容易被翻譯成「能放的控制都放上去」。第一眼像成熟產品，真的操作後才會發現，有些元件沒有替人省事，只是替驗收多開幾張考卷。
我沒有立刻叫 AI 刪工具列，而是先做一個拿掉元件的測試：把 Tag Input 換成逗號分隔文字、Color Picker 換成色碼欄位、Editor 換成普通 Textarea。如果工作沒有明顯變難，原本那個複雜元件就沒有足夠理由留下。
網站的 進階輸入元件完整比較 正好可以把五種控制放在一起看。
圖 2：先看固定結構、重複操作與內容交接，再決定進階元件是否值得保留。
進階元件會多出狀態、鍵盤操作、手機版處理與錯誤規則。採用前，我先看簡單版本到底少了什麼。
| 候選元件 | 先換成什麼 | 什麼情況下工作真的變難 |
|---|---|---|
| OTP／PIN Input | 一個可貼上數字的欄位 | 固定六碼、逐格修正與整段貼上都要成立。 |
| Tag Input | 逗號分隔文字 | 標籤要反覆新增、去重與個別移除。 |
| Color Picker | #RRGGBB 色碼欄位 |
顏色本身要被挑選、預覽、儲存或交接。 |
| Rich Text Editor | Textarea | 不熟語法的編輯者確實需要有限格式。 |
| Markdown Editor | Textarea | 寫作者需要純文字來源、版本控制與同步預覽。 |
這張表先讓簡單欄位上場。只有工作真的變難，才增加控制。
OTP／PIN Input｜一次性密碼輸入欄 適合固定長度、短時間有效的驗證碼。使用者可能逐格輸入，也可能從簡訊或驗證器直接貼上完整代碼。畫面可以切成六格，但對表單來說，它仍是一筆六位數驗證碼，不是六題小考。
MDN 的範例使用一個 <input> 搭配 autocomplete="one-time-code"、inputmode="numeric" 與六碼長度限制，讓瀏覽器和裝置有機會協助填入完整代碼。MDN：One-time passwords
因此，比較穩定的起點是保留一個語意完整的輸入值，再用視覺把六個位置分開。若元件真的拆成六個獨立 Input，就要另外處理整段貼上、自動填入、方向鍵、Backspace、焦點跨格與螢幕閱讀器朗讀。只把 autocomplete 放在第一格，剩下五格交給運氣，還不能叫做完成。
網站 Demo 保留六格外觀，也提供一次貼上與明確的「驗證代碼」按鈕。我先看它能不能把完整代碼分配正確。
圖 3：貼上 482916 後，一筆六碼值顯示在六個視覺位置；畫面仍等待使用者按下驗證。
482916 後，畫面沒有擅自送出我按下「貼上範例」後，代碼 482916 被正確分配到六格，狀態顯示「已輸入 6／6 碼」。此時流程仍停在畫面上，直到我自己按下「驗證代碼」，才出現「已收到六位數代碼 482916；正式流程會在這裡驗證。」
我保留 OTP Input，不是因為六個方格看起來比較像驗證，而是整段貼上、逐位修正與長度提示都有實際用途。六碼輸入完成也不等於同意送出；帳號可能切錯，驗證碼也可能過期，確認按鈕仍有存在的理由。
交給 AI 時，我還會補上方向鍵、Backspace、少於六碼時的剩餘數量，以及代碼錯誤或過期後的重新取得入口。如果產品只要輸入一般數字、分機或電話，回到 Number Input 或 Text Field 就好。六格外觀不會讓資料突然變安全。
Tag Input｜標籤輸入欄 適合文章標籤、收件人或關鍵字。使用者可以建立多個短值，系統則要處理重複、上限與單一移除。
圖 4：每個標籤都是獨立資料，可個別新增與移除；重複及數量上限另有回饋。
我把 Tag Input 換成逗號分隔文字後，新增看起來還算簡單，刪除第三個標籤、避免重複或限制最多五個就開始麻煩。只要標籤需要反覆編輯，獨立的資料單位會比一整串文字好處理。
在 LumenDesk 這次的資料規則裡，它和前幾天介紹的 Multi-select 不一樣：Multi-select 只從既有資料選多筆；Tag Input 則允許新增「表單」、「Vibe Coding」這類系統原本沒有的值。這是本案例刻意訂下的產品合約，不是所有設計系統對兩個名稱的唯一解釋。若資料只能選既有部門、角色或專案，直接使用限制新值的 Multi-select 或 Combobox，別讓輸入框看起來能新增，送出時才說不行。
Vibe Coding 時要說清楚按 Enter 或逗號如何新增、最多幾個、空白和重複怎麼處理。每個移除按鈕也要帶上標籤名稱；只有一排帶叉叉的膠囊，使用者與輔助科技都得自己猜會刪掉誰。
W3C 的 Combobox 指引把輸入框、建議清單與鍵盤操作拆得很清楚。Tag Input 若另外提供既有標籤建議，也要把「輸入新值」和「從建議中選值」的行為講明白，不要做成看似可輸入、實際卻不能送出的欄位。W3C WAI：Combobox Pattern
Color Picker｜顏色選擇器 適合品牌主色、圖表系列色或海報背景色。顏色在這些情境裡是資料，選完還要能儲存與交接。
圖 5：色票、即時預覽與 HEX 欄位同步，畫面看得到顏色，也拿得到可交接的值。
拿掉 Color Picker 後，如果管理員本來就拿得到 #RRGGBB，普通色碼欄位可能已經夠用。只有需要邊挑邊看、從色票選值，或使用者不熟色碼時，Color Picker 才真的省事。
<input type="color"> 會使用平台自己的選色介面，不同瀏覽器或裝置可能長得不一樣。做 Color Picker 前要先決定產品只收 HEX，還是連透明度、P3 色域、色票歷史與調色盤都要支援。MDN：<input type="color">
對多數內部系統，我會停在「原生選色入口＋即時色票＋可貼上的 #RRGGBB」。格式錯誤時保留原值並說明修法，不要默默改成黑色，好像使用者剛才選的品牌色從來沒存在過。
如果顏色代表成功、警告或分類，畫面仍要搭配文字、圖示或可讀名稱。Color Picker 解決怎麼選顏色，不負責替顏色補上語意。
Rich Text Editor｜富文字編輯器 適合不想記標記語法的內容編輯者。行政人員發布活動公告，通常只需要標題、粗體、斜體和項目清單。
圖 6：工具列只保留公告需要的有限格式，不把字型、表格與貼圖全部塞進來。
我把完整工具列換成 Textarea 後，純文字公告仍然能寫；一旦要讓非技術使用者加標題、粗體與清單，Textarea 才開始不夠用。因此我保留 Rich Text Editor，但只留下工作會用到的格式。
每多一顆工具列按鈕，都要處理焦點、選取狀態、輸出格式與儲存規則。W3C 的 Toolbar 範例也特別處理工具列名稱、焦點和按鈕狀態；幾個 Icon 排得很整齊，還不能算編輯器完成。W3C WAI：Toolbar Example
Markdown Editor｜Markdown 編輯器 適合熟悉標記語法、需要版本控制，或希望內容維持純文字的寫作者。它要把來源與預覽分清楚：一邊寫 Markdown，另一邊看渲染結果。
圖 7：來源維持純文字，預覽只處理 Demo 支援的標題、粗體與項目清單。
來源與預覽混在一起時，使用者很容易不知道自己正在改語法還是結果。Demo 因此只支援有限語法。正式產品則要先解析允許的 Markdown 語法，拒絕或跳脫未允許的原始 HTML，再交給經過檢查的渲染與清理流程；不能把輸入內容原封不動塞進頁面，然後祈禱大家都很善良。
contenteditable 可以讓元素進入可編輯狀態，但這只是起點。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：左側保留原始 Markdown 文字，右側顯示安全預覽。這個 Demo 只支援標題、粗體與項目清單；預覽時只解析允許的語法，跳脫未允許的原始 HTML，並使用經過檢查的渲染與內容清理方式，不把任意 HTML 直接插入頁面。公告若由不熟 Markdown 的人編輯，改用只含粗體、斜體與項目清單的 Rich Text Editor；不要同時提供兩套 Editor。
4. 品牌主色只有在顏色會被儲存或交接時才使用 Color Picker。使用原生 color input、即時色票與可編輯的 HEX 欄位；HEX 只接受 #RRGGBB，格式錯誤時保留原值並顯示修正說明。
做完後，我會實際貼上六位數、加入重複標籤、輸入錯誤色碼，再確認不熟 Markdown 的編輯者能否修改公告。哪個地方讓人停下來猜，就回去減少規則，或換回普通欄位。
OTP 保留，因為固定六碼、整段貼上與逐格修正都有實際需求。Tag Input 也留下來，文章標籤確實需要新增、去重與個別移除。
Color Picker 改成條件式採用：品牌色需要挑選、儲存或交接時才出現；只要貼入固定色碼的流程，用 Text Field 就夠了。公告編輯則依寫作者選 Rich Text 或 Markdown，不讓同一個人每天先決定今天想用哪套來源格式。
這次最後留下的元件反而更少。複雜度只有在替使用者省下工作時，才值得被我們和 AI 一起維護。
邀請成員與建立活動兩條輸入流程走完後，我想用手機回到活動列表，於是把瀏覽器縮到 360px。桌面 Sidebar 很堅持，別人都在縮，它依然站得筆直。
先講清楚：當天的原始截圖沒有留下來，下面這張是依同一份模糊 Prompt 還原的問題現場。錯誤可沒有因此比較客氣，選單和內容照樣一起搶空間。
圖 8：桌機 Sidebar 原封不動搬進手機，選單名稱先被截斷，正文接著被擠到只剩一條窄欄。
畫面確實有 Header、有 Sidebar，也確實塞進了手機寬度。問題是使用者看不清楚選單，內容也沒剩多少位置，還找不到能把導覽關起來的按鈕。
明天，問題會從欄位裡走到全站導覽：Header、Sidebar 與手機高頻入口，到底該怎麼重新分工？
<input type="color">
contenteditable
資料查閱：2026-08-07。
iThome鐵人賽
看影片追技術