Day 5｜輸入文字也有分工：Text Field、Textarea、Password 與 Search

請 AI 做一張表單時，很容易得到一排整齊、外觀幾乎一樣的輸入框：帳號一格、密碼一格、搜尋一格、備註一格。

問題不在於它們長得像，而是這四格要幫人完成的事情不同。帳號要收資料、密碼要保護內容、搜尋要立即縮小範圍、備註則需要容納一段完整說明。如果需求只寫「做四個漂亮的 input」，AI 當然會把它們當成同一種元件。

今天先用 UI 元件百科的實際頁面，把這四種輸入元件拆開來看。重點不是背英文名稱，而是下次你能對 AI 說清楚：這個框拿來做什麼、使用者輸入後會發生什麼事，以及畫面要怎麼回應。

先做一個反向檢查：若把這四格全換成同一種 Text Field，密碼無法安全確認、搜尋不會回應範圍縮小，備註也失去多行閱讀空間。這就是今天要拆開的責任。

問題現場：四個元件外觀都像輸入框；比較頁先用資料長度、敏感性與「是否在既有資料裡找東西」把責任拆開。

四格看起來像，實際上要完成四件事

把新增成員畫面當成一次表單診斷。四個欄位同時存在，卻不應共用同一份規格。

後面的元件介紹不是四次重複定義，而是替這張診斷表補足各自的狀態、限制與修正方式。

以 LumenDesk 的成員管理畫面為例，管理員可能要輸入工作區帳號、設定初始密碼、找出既有成員，最後補一段邀請備註。先把任務說出來，元件就比較不會選錯。

我實際操作兩個最像的欄位，差異不在框線

我先打開 Password Field，輸入 Aurora2026，再按「顯示密碼」。內容沒有被清空，按鈕名稱改成「隱藏密碼」，畫面也提醒「密碼目前顯示中，請留意周遭環境」。

接著到 Search Field 輸入「設計」。原本的成員清單縮成一筆「陳怡安｜設計組」，結果文字顯示找到 1 位成員，旁邊出現清除控制。

兩個欄位外觀都像一個長方形輸入框，操作結果卻完全不同：

這次操作後，我不再用「都是輸入框」理解它們。Text Field 和 Textarea 的差異也一樣，不在邊框，而在一個保存短資料，另一個要讓人閱讀、修改並保留一段內容。

Text Field：收一段短而明確的資料

圖 1：Text Field 收一段短資料。Label、字數規則、目前值與錯誤回饋都要留在欄位附近。

Text Field 適合姓名、Email、代碼與短名稱。它不是只要能輸入就完成：Label 必須一直可見，必填或格式錯誤要靠近欄位，修正後也要回到正常狀態。要寫一段背景說明、會議摘要或申請原因時，改用 Textarea，不要硬把高度拉高。

Password Field：讓人輸入，也讓人安全地檢查

圖 2：Password Field 預設遮蔽內容；顯示或隱藏控制用來檢查輸入，不是一般文字欄位的裝飾按鈕。

Password Field 用在不應直接顯示的秘密值。預設遮蔽內容，提供可辨識的顯示／隱藏控制；切換時不可清空文字或讓焦點跳走。它不適合拿來遮蔽一般私人資料，例如姓名或 Email，因為使用者需要校對那些內容。

Search Field：從既有資料裡縮小範圍

圖 3：在元件百科輸入「設計」後，Search Field 會提供結果數量、符合項目與清除控制；這比只有搜尋圖示更容易驗收。

Search Field 的結果是找出既有資料，而不是儲存一段新文字。它需要交代查詢時機、搜尋中、找到幾筆、沒有結果與清除後回到什麼畫面。若輸入即搜尋，還要避免每打一個字就讓結果區不停跳動。需要使用者自由輸入一段資料時，回到 Text Field 或 Textarea。

搜尋結果改變了，才算真的搜尋

剛才輸入「設計」後，清單、結果數量與清除控制一起改變。若只有框裡多了文字，資料仍完全沒動，那只是外觀像 Search Field。

因此 Vibe Coding 的需求若只寫「上面放一個輸入框」，AI 無法知道輸入後該保存還是該搜尋。我會補上觸發時機、結果數量、無結果與清除後的行為，讓它生成的是搜尋流程，不只是有放大鏡的 Text Field。

Textarea：容納需要閱讀與修改的段落

圖 4：Textarea 處理段落內容。它需要可閱讀的輸入空間、字數提示，以及提交失敗後仍保留內容的規則。

Textarea 適合備註、說明與原因。字數接近上限時先提醒，超過時說明規則；送出失敗後，剛寫的內容仍要留在欄位裡。只要收一個短名稱或代碼時，Textarea 會讓畫面過重，也增加掃讀成本。

這四個畫面都可在元件百科直接操作：

• Text Field｜文字輸入框
• Textarea｜多行輸入框
• Password Field｜密碼輸入框
• Search Field｜搜尋欄位
• 四種輸入元件的完整比較

所有欄位都需要的周邊訊息

輸入框常被做得只剩 Placeholder。這會讓人一開始看似知道要填什麼，但輸入後提示就消失；出錯時，也很難知道問題在哪裡。

圖 5：Label、輔助說明、目前值與錯誤訊息應分工合作，不能全部交給 Placeholder。

• Label：一直留在欄位旁，告訴人這是「工作區帳號」還是「邀請備註」。
• Helper Text：先說規則，例如「至少 8 個字元」或「最多 200 字」。
• 目前值：人輸入過什麼，就要看得到什麼；不能因為驗證失敗而清空。
• Error Message：說明下一步怎麼修，例如「Email 格式不正確」，而不是只畫紅框。
• Clear：搜尋欄的清除控制要有可辨識名稱，清除後也要讓結果回到可理解的狀態。

選擇流程：先看資料性質，再挑輸入方式

1. 是要從既有資料中找出項目嗎？使用 Search Field。
2. 內容需要遮蔽嗎？使用 Password Field。
3. 使用者要寫成一段完整說明嗎？使用 Textarea。
4. 其餘短文字、代碼或格式化資料，使用 Text Field。

交給 AI 的，是一張欄位責任表

下面這段 Prompt 的重點不在關鍵字多，而是把「資料規則、畫面回饋、可驗收條件」一起說出來：

為 LumenDesk 的新增成員表單設計四種輸入元件：
1. 工作區帳號使用 Text Field，保留可見 Label，必填與格式錯誤要顯示在欄位附近。
2. 初始密碼使用 Password Field，預設遮蔽，提供有文字說明的顯示／隱藏按鈕；切換時不可清空內容。
3. 成員搜尋使用 Search Field；輸入「設計」後顯示符合人數與清除控制，並提供搜尋中與無結果狀態。
4. 邀請備註使用 Textarea，最多 200 字，顯示目前字數與超過上限的錯誤訊息。
所有欄位在 360px 寬度下都要看得見 Label、訊息與操作控制。

交付前，不妨自己走一次：填錯帳號後能否知道怎麼改？切換密碼顯示後內容還在嗎？搜尋沒有結果時有沒有下一步？Textarea 超過字數後內容是否仍保留？這些問題都比「框框看起來夠不夠現代」更接近使用者真正會遇到的情況。

延伸閱讀

• W3C WAI：Labeling Controls
• MDN：<input type="search">
• MDN：<textarea>

資料查閱：2026-07-31。