修改區塊有兩種方式，一種是右側欄改屬性，另一種是直接在區塊內就地打字，兩種不同的使用模式會決定了同事或客戶接手這個網站時，是覺得順手還是想罵人。今天專門聊這個取捨。

右邊欄模式

之前完成的 service-card 區塊，它的 edit.js 是這樣的結構：畫面中央用 ServerSideRender 顯示卡片的實際樣子，所有可改的欄位（number、title、text、linkText、url）都放在右側的 InspectorControls 面板裡，用 TextControl 一格一格填。

<InspectorControls>
  <PanelBody title={ __( 'Content', 'block-theme' ) }>
    <TextControl label="title" value={ attributes.title }
      onChange={ ( v ) => setAttributes( { title: v } ) } />
    <TextareaControl label="text" value={ attributes.text }
      onChange={ ( v ) => setAttributes( { text: v } ) } />
  </PanelBody>
</InspectorControls>
<div { ...blockProps }>
  <ServerSideRender block={ metadata.name } attributes={ attributes } />
</div>

這是「右側欄」路線。另一條是前面提過的 RichText，讓使用者直接點在標題上就能改字，所見即所得，同樣一張卡片，兩種做法給使用者的感覺完全不同。

右側欄（InspectorControls）的好處是結構清楚。每個欄位有明確的標籤，使用者照著填，不太可能把版面弄壞，因為他碰不到 markup，只能改值。這對「欄位固定、不希望被亂動」的區塊很合適，像 service-card 這種設計系統的一部分。

代價是距離感。使用者改右側欄的 title，眼睛要在「右邊輸入框」和「中間預覽」之間來回跳，尤其用 ServerSideRender 時，每改一次還要等伺服器回傳重會有輕微延遲。內容多的時候這個來回會讓人累。

就地編輯：直覺，但容易失控

RichText 的就地編輯剛好相反。使用者點在標題上直接改，游標在哪字就進哪，零距離、零延遲，這是最接近 Word 那種直覺的體驗。做「內容為主、排版單純」的區塊，像一段標語、一個引言，就地編輯明顯更舒服。

它的代價是可控性變低。當你允許就地編輯，使用者可能連你不希望他碰的地方也一起改了，例如把整段標題刪光、貼進一段帶格式的文字。而且就地編輯多半走靜態區塊的儲存方式，又要面對改了 save 的輸出結構（多包一層 div、換個 class），編輯器會跳「此區塊包含非預期或無效的內容」的問題。

一張表幫你選

要採取哪種方式的判斷準則為這個區塊是「設計系統的零件」還是「內容的容器」？零件（service-card、badge）用右側欄，把結構鎖好；內容容器（標題、內文）用就地編輯，讓維護的人舒服，或是也可以混用，標題就地編輯、進階設定收進右側欄，很多核心區塊就是這樣做的。

這個決策，AI 幫不了你

編輯體驗這件事是少數 AI 幫不上太多忙的地方，因為 AI 不知道你的客戶需求，你可以叫 AI 「把 title 改成就地編輯」，它會照做，但「該不該就地編輯」這個判斷你要自己下，這也提醒我們 AI 開發不是把腦袋外包，真正的設計決策還是握在你手上。

編輯體驗定案後，區塊的內容和互動都齊了，但我們的區塊到現在都只有 PHP 和 CSS，還沒真正加過前台的 JavaScript，下一篇用 @wordpress/scripts 建置，並用傳統主題 enqueue 的角度，理解區塊的資源到底是怎麼註冊進來的。

文章目錄：https://oberonlai.blog/category/2026-ithome/