我見過三個不同的人搞砸同一個三十秒的畫面——也就是出現在你的提示與建構之間的那張規劃卡片——每個人付出的代價都不一樣。有人付出的代價是重建；有人付出的代價是白白打了一堆字；有人付出的代價是做出一個根本無法達成他們真正需求的產品。規劃卡片是整個流程裡最便宜的改變主意時機，但不知怎麼地，這也正是讓人容易一晃而過的原因。
錯誤一：直接蓋章通過
這是最常見的一種。骨架看起來沒問題，按下核准，繼續前進——我自己也這樣做了好幾週，直到吃了苦頭。最終讓我改掉這個習慣的那次建構，回來時是一個接上 Stripe 結帳功能的靜態網站，但這個網站根本沒有地方存放 Stripe 需要的帳戶狀態。規劃卡片其實白紙黑字寫著產品類型：靜態網站，就在卡片上，而我因為頁面列表看起來沒問題，又趕時間，就這樣掃過去了。
這種錯誤造成的破壞總是同一種形狀：計畫之後的一切,在該計畫的前提下都是正確的,所以失敗不會以錯誤的形式浮現,而是以「一個可運作但架構上完全錯誤的建置」的形式浮現。沒有人會標記出這個問題,因為表面上沒有東西壞掉——一個帶有結帳按鈕的靜態網站只是靜靜地做錯事,或者只在真正的使用者按下「付款」的那一刻才失敗。你會在審查時才發現,而那正是發現這種問題成本最高的地方。
錯誤二：過度詳述以避免第二輪修改
相反的失誤看起來比較負責任，但其實不然。有些人被錯誤一燙傷過一次之後，會矯枉過正，在規劃階段就寫出一整段精確的需求——精確的文案、間距偏好、哪些功能一定要有、哪些一定不能有，寫得像一份規格文件。我自己也這樣做過，出於一種模糊的焦慮：擔心這時候不寫詳細一點，就等於在之後的建構回合中「浪費」機會。
這其實是本末倒置，原因如下：不管你第一次寫得多仔細，一旦你看到實際的頁面，規劃還是會再被修改一次。而修改發生時，你拿到的不是「哪裡改了」的差異列表——你會得到一張已經整合你的修改的全新卡片，就這樣，沒有修改註記。所以你在第一輪寫下的精確度，並不會完整延續到第二輪；不管怎樣你都得重新讀一遍整份內容。花兩三輪「不，是這樣的」去修正，最終得到的結果會比一份鉅細靡遺的初稿更好、實際花費的時間也更短——即使寫那份詳細簡報的當下感覺效率比較高。
真正有效的一般語言修改指令都很簡短：
- 「拿掉部落格，加一個定價頁面」——乾淨俐落地調整頁面列表。
- 「改成雙人模式而不是單人模式」——比聽起來影響更大。它可能牽動資料模型，從追蹤一位參與者變成追蹤兩位，而修改後的規劃會如實呈現這種連鎖影響，而不是把它藏起來。
- 「這需要使用者帳戶」——如果目前的規劃是靜態網站，這句話會直接迫使產品類型的問題浮上檯面。
錯誤三：把產品類型當成可有可無的欄位
這是代價最高的一種錯誤，之所以代價高，是因為卡片上其他所有東西其實都能補救。頁面、推斷出的功能、大多數的問題分支——這些都可以在建構完成之後透過版本迭代修正。但產品類型不行。總共有四種類別：
| 產品類型 | 代表的意義 |
|---|---|
| 靜態網站 | 純粹，沒有伺服器端邏輯。 |
| 可安裝應用程式 | PWA 風格——支援離線使用、可加到主畫面，同樣沒有伺服器端邏輯。 |
| 框架建構 | React/Next 風格，具備更豐富的前端互動，但依然沒有持久性的後端。 |
| 伺服器支援應用程式 | 四種類別中唯一在背後具備真正資料庫與帳戶系統的類型。 |
核准一份靜態網站的規劃，三個版本之後才決定要有登入功能，那已經不是一次版本升級——而是要改用不同產品類型從頭重建，而且你會失去版本歷史為其他一切帶來的連貫性。
人們常在這件事上犯兩種錯誤。首先,他們沒有把自己的提示詞對照場景檢查——如果你的提示詞裡有「帳號」、「登入」、「儲存」、「會更新的儀表板」、「付款」,或「多個使用者同時編輯同一份東西」,而卡片上卻沒有標示伺服器支援,那就是你在核准前唯一值得修改的地方,沒有例外。其次,他們把可安裝應用程式與框架建構混為一談,因為在日常對話中兩者感覺都像「一個應用程式」。但它們並不能互換:可安裝應用程式適合所有狀態都存在使用者裝置上的工具——例如小費計算器、計時器。框架建構則意味著更多互動性與元件結構,但仍然沒有任何跨裝置、跨session持續存在於伺服器端的資料。兩者都不是那種擁有帳號、資料會跨裝置跟著你的「應用程式」——只有伺服器支援才算。而為了「以防萬一」就過度配置成伺服器支援,對於作品集網站或文件頁面來說也並非安全之選——之後要降級,和升級一樣都等於重新建構一次。
不再犯這三個錯誤之後，剩下該做的事
一旦你不再一晃而過地略讀產品類型那一行，不再在規劃階段就寫成規格文件，也不再把自己提示裡關於帳戶、資料、付款的字眼視為可有可無，剩下的就是一個快速又聚焦的檢查：
- 閱讀產品類型。
- 拿它跟你的提示互相對照。
- 瀏覽推斷出的功能列表，找出任何你一看就會否決的項目。
這份列表之所以存在，正是因為像「美髮沙龍的預約排程工具」這樣的提示，會連帶拉進一些你沒打進去的東西——行事曆檢視、簡訊提醒、客戶名單，其中一些是你原本就想要的，一些則是模型加進來的範疇擴張，因為這些功能在統計上經常一起出現。與其等它被建構完成之後才修剪，不如現在、就在這句話裡，先剪掉不屬於的部分。
其他一切——文案、間距、主題色要用哪個色調、按鈕要寫「立即開始」還是「免費試用」——完全不會出現在卡片上，這是刻意的安排。這些東西在一個可運作的成品上很容易看到、也很容易修改，所以卡片不會浪費你的注意力在這些事情上，你也不該浪費。這大概就是在讀完整張卡片所需的三十秒裡，真正需要用到判斷力的十五秒。
