• 每一個想法在被允許算作真正想法之前，都會先經過一個單句測試

  • 大部分想法都是因為三個特定原因而被淘汰，而不是模糊的缺乏熱情

  • 只有在接觸到真實且重複發生的問題後，一個想法才能獲得開發時段

  • 我刻意保留「也許之後」清單，但檢查頻率遠比大家以為的低

在任何東西成為想法之前，我會先執行單句測試

我收到的想法多到永遠做不完。這不是在炫耀，而是如果不管理，這會變成一種負擔，因為每一個想法大概都會讓我興奮二十分鐘，而興奮是篩選「實際值得用夜晚時間做的事」的糟糕指標。所以在一個想法被允許出現在任何清單上之前，它必須通過一個測試：我能不能用單一句子描述它的最小可用版本，中間不能有「和」。

這聽起來很簡單，但它比流程中任何其他步驟都殺掉更多想法。「一個追蹤我 Claude 使用量、還能顯示分析、還要有社群功能的工具」無法通過。「一個在我達到使用上限前警告我的工具」可以通過。第一句是為一個平台做的提案。第二句是為一個週二晚上做的提案。我想要第二種，因為第二種是我真正能完成的那一種。

我並不是一開始就這樣做。早期，只要一個想法聽起來有趣，它就能在我的清單上佔有一席之地，而我的清單最後變成了一座半描述計畫的墳場，那些計畫都需要一段話來解釋。段落現在是警告訊號，而不是特色。如果我需要超過一句話來描述最小版本能做什麼，那個想法其實還沒有成形，它只是獲得了熱情，而這兩者是不同的事。

這個測試也強迫我在投入任何實際時間之前，就誠實面對範圍。一個需要「和」的想法通常是兩個或三個想法穿著風衣，當它們還在句子階段時就把它們拆開，遠比在開始開發三週後才發現範圍蔓延時再拆開便宜得多。我在〈為什麼我持續發佈小型工具而不是一個大產品〉中寫過不早點這樣做的代價，而誠實的答案是，大部分這種紀律其實從這裡開始，在句子階段，遠在任何程式碼存在之前。

在我打開編輯器之前就被淘汰的想法的原因

通過句子測試的想法仍然不斷被淘汰，而它們幾乎都是因為三個特定原因失敗，而不是模糊的「不夠好」的感覺。

第一個原因是這個想法聽起來好只是因為它是新的。新穎性是最廉價的興奮，而且消退得很快。我對此的檢查很簡單，我會讓一個句子至少靜置幾天再做任何決定。如果在最初的火花消退後，它仍然聽起來值得開發，那就是真正的訊號。如果它只在我想到的那天晚上聽起來好，那通常是夜晚在說話，而不是想法本身。

第二個原因是它複製了我已經發佈的東西，即使包裝不同。每一個新想法都會與工作室現有的產品進行誠實比較：Git Dojo、OhNine、Statusline Builder、Claude Blueprint、RAXXO Studio，以及周邊商品。如果誠實的答案是「這基本上就是 OhNine 換了個名字」，它不會被當作新東西開發，而是會被折疊成改進 OhNine 的筆記。兩次追逐同一個底層問題卻用兩個不同的名字，浪費了本來可以充分用在任一版本上的注意力。

第三個原因是，我無法想像一個特定的人遇到它所解決的特定問題。不是人口統計學，而是實際的時刻。以 Git Dojo 為例，那個時刻很清楚：有人第一次輸入 rebase -i 然後僵住，因為這裡的錯誤感覺很昂貴。當我無法具體想像那個時刻時，那個想法通常會永遠保持抽象，這是強烈的跡象，顯示它是在解決一種感覺而不是一個問題。

這樣淘汰想法曾經感覺很浪費，好像我在丟掉潛力。我後來開始認為這恰恰相反。每一個我早早淘汰的想法，都是我可以拿去完成其他東西的時間，而不是開始第四個未完成的事。關於保持不同產品分開的結構面，而不是出於罪惡感把淘汰的想法合併回現有工具，我在〈如何為多個產品建構單體儲存庫〉中討論過，而這兩種紀律互相強化：前期狠心淘汰，保留下來的東西之後保持乾淨分離。

什麼才能讓一個想法獲得開發時段

通過淘汰是必要的，但還不夠。一個想法只有在通過另一個門檻後才能獲得實際的開發時段：我需要自己遇到過底層問題，而且不只一次，而且具體到我能精確描述修正會是什麼樣子。

這個規則存在是因為我不信任自己對其他人需求的猜測。我信任的是我親自反覆遇到的問題，因為重複是區分真正反覆發生的問題與我永遠不會再想起的一次性困擾的關鍵。Statusline Builder 存在是因為我一直手動編輯同一種 statusline 的 JSON 設定，而且手動做時一直犯同樣的小錯誤。那不是對開發者可能想要什麼的直覺，而是一個我親自反覆遇到、多次到讓我覺得建立修正不再是可選的困擾。

具體性要求與重複性同樣重要。「我想要更好的開發者工具」不夠具體到能用來開發，那是一種心情。「我想要在一個錯誤不造成任何代價的儲存庫上練習 rebase」具體到足以讓我當天坐下來開始。當一個想法自行達到這種細節層級，而不需要我強迫它到那裡時，那通常是我擁有的最清楚的訊號，顯示它準備好了。

在這兩者之下還有一個更安靜的檢查：我能不能想像用一句話向某人解釋完成後的東西，也就是一開始那個測試，只是第二次應用在結果而不是提案上。如果完成的版本仍然需要一段話來解釋它實際上做了什麼，那麼在開發過程中有東西偏移了，而這值得在發佈前而不是發佈後發現。我之前寫過我在把任何東西稱為已發佈之前都會執行的審查流程，而這個句子層級的檢查其實是同一習慣的最早版本，只是應用在想法而不是完成產品上。

這一切都不保證一個想法會有好結果。它保證的是，獲得開發時段的想法至少是從真實的東西開始的：一個反覆發生的、具體的、可描述的問題，而不是一個晚上感覺像問題的情緒。

我刻意忽略的「也許之後」清單

不是每一個被淘汰的想法都會被刪除。很多都會進入一個我稱為「也許之後」的獨立清單，而刻意的部分在於我實際上有意打開那個清單的頻率有多低。

任何待辦清單的誘惑都是把它當作需要不斷照顧的活物：重新排序優先順序、重讀舊條目、確保沒有東西被遺忘。我以前確實這樣做，而它悄悄變成了一種拖延形式：審查我沒有在開發的東西清單，而不是開發眼前的事。現在「也許之後」清單只在特定時刻打開，主要是當我在建置之間，而且真的有空間做新東西時，而不是當我想瀏覽舊想法來獲得多巴胺的時候。

那個清單上大部分條目永遠不會畢業。一個想法在那裡待了幾個月而我的情況沒有任何改變，通常表示那個想法從一開始就不是那麼強，它只是當時避免被直接淘汰。那些確實畢業的想法幾乎總是因為某些具體的事情改變了：我在其他地方又遇到同樣的問題，或者我已經發佈的工具顯示了一個缺口，而舊想法恰好能精確填補。

我也學會讓想法在清單上安靜地消失而不舉行儀式。不是每一個想法都需要正式的拒絕，有些只是隨著工作室實際產品的形狀改變而不再相關，而修剪一個過時的想法代價為零，相比之下每隔幾週出於模糊的義務感重新考慮它的代價。

結論

這個篩選機制在紙面上很簡單：一句話、沒有「和」、經過幾天不再感覺令人興奮、不複製已經發佈的東西，並且可以追溯到我實際遇到過不只一次的具體問題。讓它有效的關鍵是當一個想法感覺緊急時，拒絕跳過步驟，因為緊急正是那種曾經說服我去開發我從未完成的事物的感覺。

這一切都不讓我免於做出錯誤的決定，而我仍然會在某些週淘汰一些可能值得更多耐心的想法。但是另一個選擇——建置任何當下感覺令人興奮的東西——是這個工作室永遠不會發佈任何超越草稿版本的版本。這個篩選機制不是為了讓想法完美。它是為了確保任何通過它的東西確實會被完成。

如果在這一切之下有一個值得單獨命名的習慣，那就是對淘汰的耐心。每一個我在句子階段、或在重複性檢查、或在「也許之後」清單上安靜地讓它消失的想法，都是重新投入到完成已經獲得位置的東西的時間。這種交易並不光鮮，在一個聽起來不錯的想法被淘汰的那一刻也不像進展。它在後來看起來像進展，在那些實際發佈的東西清單中。