假設你替一間小型工作室做預約服務。你向 AI 描述需要的功能：選擇時段、填寫資料、寄出通知，再提供一個讓店主查看行程的後台。當這些要求能夠逐步變成可操作的畫面，原本看似遙遠的產品，開始有了輪廓。
但店主看完之後，可能只問一句：「客人臨時改時間，我還需要在三個地方各改一次嗎？」
這個問題讓產品回到現場。畫面已經能動，工作卻可能沒有變輕鬆。以下的工作室是用來推演的假設情境；我想藉它討論，當 AI 讓部分實作變容易，產品應該如何重新說明自己存在的理由。
程式碼退到幕後，誰的注意力改變了？
對大多數使用者來說，程式碼一直在幕後。他們原本就在意能否完成預約、找到資料、把事情辦妥。這些需求早於生成式 AI，也不會因為工具更新就自動改變。
新的變化發生在創作者這一側。對部分任務而言，過去必須逐段翻譯成程式的要求，現在可以先用自然語言描述，再透過執行結果、畫面與回饋逐步修正。注意力因此有機會從每一步怎麼寫，移向要做什麼、結果是否符合期待，以及哪裡仍需介入。
我用「AI 遮住程式碼」形容這個轉移。被遮住的是部分實作過程，底下的資料結構、執行條件與錯誤依然存在。當結果偏離預期，創作者仍需要判斷問題出在哪一層，也需要有能力打開那層抽象。
這種轉移有一個容易忽略的前提：你得知道怎樣才算完成。描述「做一套預約系統」很容易；說清楚兩人同時搶最後一個時段時該發生什麼，才開始碰到產品的邊界。需求中的空白，終究會由某個人或某段系統行為補上。
實作加速也讓這些空白更快變成具體行為。畫面越完整，團隊越容易把預設選擇當成已經討論過的決策。因此，看見可用的成果時，仍值得回頭問：哪些規則來自真實需求，哪些只是生成過程替我們做了決定？
做得出來之後，差異從哪裡來？
如果一類功能更容易被做出來，擁有這項功能所能形成的差異，就值得重新檢查。預約表單、通知範本與管理列表都很有用，但當相近的組合更容易出現，使用者就有更多理由比較：哪一套符合自己的流程？搬過去要花多少力氣？出問題時找得到人嗎？
我的判斷是，AI 會讓某些靠實作門檻維持的差異承受更大壓力。這個判斷有範圍：容易描述、容易驗證、已有成熟模式的功能，與需要特殊演算法或深厚領域知識的系統，面對的條件並不相同。
產品的價值本來就應該從使用者出發。改變的是投入資源的理由。當多做一個功能所需的成本下降，團隊更容易沿著「還能加什麼」一路擴張；可是使用者理解功能、設定規則、遷移資料的成本，未必跟著下降。對店主而言，多一個選項也可能多一個必須做的決定。
因此，實作能力增加之後，取捨會變得更具體。你願不願意只服務某一種工作室？願不願意為了清楚的流程，放棄少數看似通用的功能？越容易製作，越需要確認每個新增項目究竟替誰減少了什麼負擔。
METR 在 2026 年的技術工作者調查中，刻意區分做事的速度與產出帶來的價值，也提醒讀者：自陳的提升不等於客觀驗證過的成效。這份調查沒有回答哪種產品會成功，但它提出的測量區分很有用。更快完成一個沒人需要的後台，仍可能只是更快消耗了注意力。
這也影響值得累積的資產。對工作室的理解，可以逐步變成合理的預設、恰當的例外處理與容易採用的流程。競爭者即使複製了畫面，也未必知道每個選擇背後的原因。這種理解需要持續與現場核對；一旦只剩下團隊內部的想像，它同樣可能成為包袱。
從預約功能，走到預約成立
回到那間工作室。假設它只有一位主理人，白天接待客人，晚上回覆訊息。客人的需求散落在通訊軟體、日曆與紙本紀錄裡。主理人想減少來回確認，也希望保留處理熟客與特殊需求的彈性。
一個可以送出表單的頁面，解決了資料收集。但要讓預約成立，還有許多判斷：服務前後是否需要準備時間？客人選到的時段是否仍然可用？改期後，舊時段何時釋出？通知沒有送達時，誰會知道這件事尚未完成？
這些細節會改變產品如何運作。假如日曆同步有延遲，系統就不應只憑一份過期資料宣布預約成功。假如主理人必須先確認特殊需求，介面就需要清楚區分「已收到申請」與「已確認預約」。兩句文案之間，隔著使用者接下來要不要出門的決定。
定位開始變得清楚，是因為我們知道要改善哪一段工作。功能仍然重要，只是需要和承諾、證據接在一起。
| 功能 | 對使用者的承諾 | 可以怎麼驗證 |
|---|---|---|
| 時段選擇 | 客人選到確實可以提供服務的時間 | 檢查衝突與重複預約，追蹤需要人工修正的比例 |
| 改期處理 | 調整一次就能讓相關紀錄一致 | 觀察一次改期需要多少操作與來回訊息 |
| 通知與提醒 | 雙方知道目前狀態與下一步 | 檢查送達情況、狀態誤解與人工補通知次數 |
表格裡沒有預設漂亮的成果數字。真正導入時，應先觀察原本的流程，再看使用後的差異，並把設定、核對與補救的時間一起算進去。若少回了幾則訊息，卻增加每天檢查 AI 是否做錯的負擔，省下的時間可能又以另一種形式回來。
承諾也要落在產品能影響的範圍內。提醒可以幫助客人記住時間，卻無法保證每個人都準時出現。比較負責任的做法，是把可觀察的狀態呈現清楚，讓店主及早知道哪些預約仍待確認，並保留聯絡與調整的空間。把成效說得精確，會直接影響使用者建立什麼期待。
理解現場也會影響競爭對象。這套服務可能是在和店主已經熟悉的通訊軟體加紙本日曆競爭。新的系統必須好到值得換掉既有習慣。功能相同與否，只是比較中的一部分。
接受委派之後，介面要讓人看見什麼？
當店主可以直接說「把週五下午的預約移到下週」，產品就開始承接委派。這句話省略了許多操作，也省略了許多條件：是全部移動嗎？客人同意了嗎？下一週有沒有足夠時段？
好的互動需要把這些條件帶回可判斷的畫面。系統可以先列出受影響的預約、提供可行時段，讓店主檢查後再通知客人。對暫時無法安排的項目，保留明確狀態與接手入口。使用者能知道進行到哪裡，才有條件放心把工作交出去。
這也說明了聊天框的限度。自然語言適合表達意圖與補充情境；一週的空檔放在日曆上，通常更容易比較。多筆改期的前後差異放在表格裡，也更方便檢查。介面可以依任務切換表達方式，讓描述、比較與確認各自有合適的地方。
系統用來判斷的依據也應該能被檢查。例如「下午有空」究竟來自最新行程，還是店主上週說過的一句話？產品不必展示全部推理過程，但需要在影響安排的地方，提供可核對的資料與限制。使用者才知道要修正哪個條件，讓後續處理回到正軌。
控制感還包括改變心意的能力。通知尚未寄出時能否取消？寄出後能否補發更正？自動處理的範圍是否清楚？這些問題應該在設計流程時就被回答，因為它們決定使用者願意委派到什麼程度。
如果每一步都要使用者重新核對，委派的價值會被吃掉；如果每一步都默默完成，使用者又可能失去必要的判斷機會。產品需要找出真正值得停下來的節點，並讓其餘步驟的狀態保持可見。這是一項與情境有關的設計工作，很難用「自動化越多越好」取代。
看不見的工程，仍然決定體驗
簡潔的介面會把更多責任留給底下的系統。兩個人同時預約，資料必須保持一致；通知重試，不能讓客人收到互相矛盾的訊息；系統中斷後，接手的人需要知道哪些動作已經完成。
這些工作可能不容易在展示影片裡被看見，卻會在日常使用中反覆決定信任。尤其當產品替使用者執行動作，錯誤會離開螢幕，影響別人的安排。工程品質於是直接成為產品承諾的一部分。
Anthropic 在 2026 年介紹 Managed Agents 的工程文章中，描述了將持久事件紀錄與執行環境分離的設計，使執行元件失敗後仍能恢復工作。這個案例提供了一個具體提醒：讓使用介面更簡單，背後仍需要安排狀態保存與故障恢復。它並不表示每個預約服務都需要同樣的架構。
工程也仍可能是產品最重要的差異。極低延遲、特殊資料處理、離線能力或難以複製的整合，都可能直接決定某個需求能否被滿足。認為所有程式碼都會變成廉價零件，會錯過這些具體限制。
我更在意的是，團隊能否說清楚每一項技術投入如何改善結果。對這間工作室，可靠地防止重複預約，可能比多一種生成訊息的語氣更值得先做。選擇用固定規則處理已知流程，也可能比讓模型每次重新判斷更合適。知道何處需要 AI，何處需要確定性，本身就是產品能力。
重新寫下產品的承諾
如果要替這個假設中的產品寫一句介紹，「具備 AI 排程、自動通知與智慧管理的預約平台」能交代功能，卻仍讓店主自己猜它和現況有什麼關係。
我會試著寫得更具體：「協助獨立工作室集中處理預約與改期，減少反覆確認，讓主理人在需要判斷的地方接手。」這句話不是已被證明的成果，而是一個需要透過設計與使用驗證的承諾。它選擇了服務對象，也讓團隊知道哪些事情應該優先。
範圍縮小也讓第一步容易驗證。可以先把單人工作室的一次改期做完整，確認舊時段釋出、紀錄更新與通知都能銜接，再考慮多人排班。這樣的順序讓團隊有機會從真實使用中學習，避免拿功能數量替代對問題的理解。
接下來有四個問題必須回答：我們服務的是誰，他原本怎麼完成工作？我們希望改善哪個可觀察的結果？要用什麼證據判斷改善真的發生？當系統做不到時，誰接手、怎麼補救？
這四個問題可以用來檢查每一次新增功能。如果一項功能只讓產品看起來更聰明，卻無法連回任何一個答案，就值得延後。省下的實作時間，可以拿去觀察真實流程、簡化設定，或把失敗時的體驗做完整。
對設計師與開發者而言，這也讓工作之間的連結更緊密。問題定義需要理解技術邊界，技術選擇需要知道使用者在意的結果；設計則要讓這些選擇成為人能理解、操作與信任的流程。誰負責把這條線接起來，誰就有機會創造難以用功能清單衡量的價值。
當 AI 讓部分實作變容易，我希望得到的是更大的餘裕：更早驗證一個值得做的問題，更有耐心處理那些不容易展示、卻每天都會發生的例外。
程式碼可以退到幕後。當那位店主再次遇到臨時改期，知道只要處理一次，而且能看見事情確實完成，產品才有了被繼續選擇的理由。