Steve Test：這項工作值得存在嗎？

本週稍早，我處理了一項工作，而正確的決定其實是拒絕出貨。一條翻譯管線會把這個網站的內容寫入Cloudflare D1，供10個語言版本使用。3個翻譯工作同時撞上速率限制；備援機制悄悄把英文原文寫進D1，當成其中6個語言版本的「翻譯」，接著又把檢查點雜湊值更新成符合英文內容的狀態。從磁碟上看，一切成功。管線回報「完成」。指標顯示10個語言版本都已出貨。所有自動檢查全數通過。

德文讀者進到/de/guides/claude-code時，會先看到一段德文，下一段變成英文，再下一段又回到德文，還有一個英文段落標題。沒有任何標記說明這些切換。頁面看起來像是刻意如此，卻讓整個網站顯得不可信：像那種大概在其他任務上也會失手的產品。我已布設的每一層Jiro Test（這項工作是否正確？）都通過了。可是那個成果不值得存在。它長得像產品，行為卻像羞辱。

正確做法是停下來，稽核每一批英文備援結果，精準清除檢查點雜湊值，逐一執行翻譯管線，逐語言版本驗證，提交，推送。大約6小時的實際翻譯等待時間，再加上一個防止重演的防護補丁。磁碟上的成品全程都「可運作」。正式環境裡的成品，卻是我造成的傷害。

這種失敗的形狀，不只會出現在翻譯管線。註冊流程、功能開關、CSV匯出、行銷頁面，都可能如此。每個自動檢查都通過。真正落到使用者面前的東西，卻造成傷害。

產品裡的主導問題不是完成了嗎？，也不是能運作嗎？。真正的主導問題是：這項工作值得存在嗎？每個成品在出貨前都必須回答這個問題，並且另外通過正確性測試。只有正確、沒有值得，會製造庫存：能運作、能出貨，卻無法贏得信任。只有值得、沒有正確，會製造表演：感覺對了，實際會壞。兩項測試都必須通過。

我使用的簡稱是Steve Test。它和追求嚴謹與證據的Jiro Test並列。這是同一個判斷心智提出的兩個不同問題；任何一項沒通過，我都不出貨。

TL;DR

Steve Test是每個成品必須通過的第二項測試。Jiro問這項工作是否正確；Steve問這項工作是否值得作為您正在打造的整體的一部分而存在。這項測試很具體，不抽象。它以真實使用者在真實時刻的處境作為衡量基準，而它最穩定的輸出通常是拒絕。我會砍範圍。我會刪功能。留下來的東西必須配得上我的名字。兩項測試都必須通過。Jiro失敗，就停下來修。Steve失敗，就重做。誠實重做3次是上限；超過之後，問題通常在更上游的問題定義。

為什麼「完成了嗎？」問錯了問題

多數產品團隊最佳化的是可出貨。可衡量的輸出是提交、部署、速度圖表，以及正式環境中有了某個東西。失敗模式也很可預期：團隊穩定產出功能正確的成品，卻悄悄消耗使用者信任。新手導引完成了，第二次使用卻沒有發生。客服單集中在產品聲稱能處理的任務周圍。流失曲線一路趨近於零，而不是收斂成核心使用者群。

完成和值得是兩種不同的衡量。一個功能可以完成，卻不值得存在。一個頁面可以成功渲染，卻冒犯讀者。一份翻譯可以技術上存在，實際上卻等同謊言。判斷某件事是否完成，要看它是否執行了規格指定的行為。判斷某件事是否值得，要看真實使用者是否因為你出貨了它，而在某個真實時刻變得更好。

我在最低限度值得存在的產品中的主張是，MVP文化在實務上把兩個問題壓成了一個：快速學習退化成快速出貨，而出貨本身變成最重要的指標。⁷解法是雙重標準。「最低限度」削減範圍。「值得」則要求剩下的接觸面達到使用者能感受到的門檻。Steve Test就是在判斷剩下的接觸面是否過關時使用的工具。

主導問題

這項工作值得存在嗎？

我會逐字使用這個問題。當我完成一項工作，必須決定是否出貨時，我會把問題說出口。答案是一個判定，不是一種感覺。如果答案是肯定，這項工作才有出貨資格，下一個問題則是它是否也通過Jiro Test的正確性要求。如果答案是否定，這項工作需要重做或刪除。如果答案是還不行，但可在明確的修正動作內達成，那就繼續做。

這個問題只有在答案可以是不行時才有效。只會替眼前成果蓋章的Steve Test不是測試。真正有在執行這項測試的訊號，是有些工作會因此失敗。

使用者支點：值得從不抽象

Steve Test一旦變成對孤立作品的品味爭論，就已經失效。值得與否，必須放到特定使用者在特定時刻的處境中衡量。更完整的測試問題應該是：這項工作對這位使用者、在這個時刻，值得存在嗎？

對blakecrosley.com而言，使用者是從搜尋結果冷啟動進站、心中仍有關於Claude Code、Codex或基礎架構問題的讀者。時刻是頁面載入後的前5秒，在頁面尚未贏得任何信任之前。一個頁面如果載入快速、觀點清楚可讀，並且告訴讀者某件搜尋結果尚未回答的事，就通過門檻。若頁面用緩慢的套件、無法關閉的Cookie橫幅，以及一整面像是為SEO堆出的泛泛文字懲罰讀者，不管它在Jiro軸上的分數多高，都已失敗。

對ResumeGeni而言，使用者是在一個我視為脆弱時刻中的求職者。早期候補名單多數來自剛被裁員之後，或正在面試流程之中。⁶值得的版本會拒絕把他們當成轉換率指標。文案不閃躲。解析器不會謊稱自己找到了什麼。建議具體到他們可以立刻採取行動。流程不會因為我只出貨了快樂路徑，就在中途把他們拋下。

使用者支點讓Steve Test不會變成收藏我個人偏好的密室。如果我無法說出使用者是誰、他們所處的時刻是什麼，並解釋出貨的接觸面如何尊重並強化他們，那我並沒有套用這項測試。我只是宣稱自己套用了。

雙重測試：Jiro加Steve

完整原則需要兩項測試，而不是一項。¹任何一項沒通過，我都不出貨。

Jiro Test問的是：這件事做得正確嗎？它要求證據。邊界情境已處理。看不見的細節已完成。主張引用了具體證明。不能含糊：我相信不是證據。測試通過。沒有迴歸。證據門檻是我用來檢驗程式碼報告與代理輸出的Jiro Test版本，而Jiro品質哲學則是更深入的說明。

Steve Test問的是：這項工作值得存在嗎？它要求值得。與整體一致。有可見的觀點。能說出為了保持接觸面乾淨而拒絕或刪除了什麼。有讀者能辨認的愉悅或清晰機制，而不是空泛帶過。配得上掛上你的名字。

仲裁很簡單。如果Jiro失敗，停下來修。錯誤的工作不能出貨；Jiro的否決是絕對的。如果Jiro通過而Steve失敗，重做。正確但不值得的工作也不能出貨。如果兩者都失敗，問題在更上游，可能是任務定義、問題框定或範圍。只有兩者都通過的工作才有資格出貨。

多數出貨文化會悄悄只執行其中一項。工程主導的文化常有強Jiro、弱Steve：測試通過，產品就出貨，而值得與否變成別人的部門。設計主導的文化有時是強Steve、弱Jiro：看起來對了，產品就出貨，而正確性變成營運問題。兩種失敗模式都會產出一眼可辨的成品。漂亮的胡扯。正確但沒有靈魂的工作。你見過。你也可能出貨過。

兩項測試並列如下：

整體產品：你擁有完整體驗

Steve Test不會孤立審判成品。它審判的是使用者遭遇的完整體驗中的一部分。

開頭提到的翻譯事故，是最近最乾淨的例子，而具體失敗機制值得說清楚，因為它揭示了陷阱的形狀。當Claude子程序撞上速率限制時，管線的備援機制把英文原文寫進D1。D1寫入器接受了那些位元組，因為它們就是位元組。檢查點更新器對已儲存內容取雜湊，並將該雜湊寫入磁碟。由於儲存的「翻譯」與英文原文完全相同，雜湊也完全相同：相同位元組產生相同雜湊。下一次--update執行時，拿英文原文雜湊與已儲存雜湊比較，發現相等，就將該批次標記為未變更。每個元件孤立來看，都通過自己的Jiro Test。缺陷存在於組合之中。在有人打開其中一個頁面前，使用者已經看了好幾個小時的6個語言版本混雜文字。

「我們擁有整體產品」是規則。產品行為、UX流程、語言、資料真實性、支援系統、包裝、文件準確性、提示、規則、記憶、技能、鉤子、腳本、編排、輸出結構。是全部，不只是你最近出貨的那個成品。任何局部勝利，只要削弱整體完整性，都不可接受。當某個接觸面在局部通過、但整體使用者體驗沒有通過時，Steve Test就會啟動。

刪除：只會增加的Steve層是假的

Steve Test最有用的單一產物，是刪除。

一次審查如果沒有移除任何東西，其實沒有真正執行。面對具有真實複雜度的接觸面，提出這項工作值得存在嗎？，幾乎一定會找出至少一個無法替自身存在辯護的範圍、文案、功能或操作提示。若審查找不到任何這類東西，通常只是表演審查，而不是實踐審查。

Steve Test具體會尋找：

• 只是因為放進來感覺安全，而不是因為真正贏得位置的接觸面。
• 因為刪掉保留語氣就必須提出真實主張，所以選擇含糊的文案。
• 從前一版一路帶下來，卻已不再服務當前承諾的功能。
• 為了處理目前範圍內其實不會發生的邊界情境而加入的操作提示。
• 把製作者本該做出的決策外包給使用者的設定選項。
• 描述產品已不再具備之行為的文件。
• 覆蓋本該刪除之程式碼的測試。

刪除，是區分品味與堆積的行動。值得的接觸面，會比沒有人提出問題時你原本會出貨的版本更小。我從未後悔從已出貨產品中移除某個東西。我經常後悔自己留下了什麼。

拒絕是主要動作

與刪除相關，而且更強：Steve Test常常在任何東西被打造之前就啟動，而不是之後。品味的主要動作是拒絕：決定根本不要做那件事。

這裡重要的Steve Jobs那句話是：“I’m as proud of what we don’t do as I am of what we do,”，出自2006年BusinessWeek一篇關於Apple產品紀律的封面故事。⁵人們常引用這句話，因為它在一種具體技術意義上是真的。每個出貨產品周圍，都有一圈看不見的光暈，由你拒絕出貨的產品構成。那圈光暈才是真正的觀點。它證明做決定的是人，而不是待辦清單。

對blakecrosley.com而言，技術棧記錄了我修剪過什麼。我考慮過React，然後拒絕。我考慮過Tailwind，然後拒絕。重建前兩週，bundler一直擺在桌上，最後我把它砍掉。整個儲存庫任何地方都沒有node_modules/，這不是設計選擇；這是我長期頂住預設工具重力所維持的拒絕。這些拒絕比任何納入的東西更深地塑造了工作。它們定義了我願意堅守的標準。

對ResumeGeni而言，驗證結果很乾淨。340個電子郵件註冊、12個直接詢問、3個主動提出願意為早期存取付費的人。⁶這些需求浮現的待辦清單很大：範本、團隊協作、分析儀表板、LinkedIn整合、Indeed整合、版本歷程、多種匯出格式、行動App。第一個出貨版本中，我拒絕了全部。不能拒絕的是：準確解析、誠實的缺口評估、符合職缺描述的具體改寫、能在Word乾淨開啟的匯出，以及讓脆弱使用者感到安全的流程。被拒絕的東西不是永遠消失。它們在值得的第一個接觸面之後等待。

一個什麼都不拒絕的接觸面，就是沒有觀點的接觸面。如果團隊什麼都沒拒絕，範圍就是錯的。

及早拆穿胡扯，先從自己開始

拒絕與刪除要有效，測試就必須能在假成功出現時指認它。Steve Test必須拆穿胡扯，而且要很快，尤其是以下幾種：

• 假進度。看似前進，卻沒有產出任何東西的動作。
• 受污染的證據。因錯誤原因而通過的測試；只證明你想證明之事，而不證明真相的統計。
• 虛榮計數。提交數、已出貨成品數、速度圖表：全都有，也全都離題。
• 不一致的系統，孤立出貨時很乾淨，組合起來卻彼此削弱。前述翻譯事故就是其中之一。
• 「一切都在軌道上」的報告，用來掩蓋沒有人做出的決策。Steve Test正是這些報告的敵人。
• 低價值的機器活動。電腦因為做得到而做的工作，而不是因為輸出值得存在。

這條規則最難、也最穩定有用的版本是：先拆穿自己的輸出。本文開頭的翻譯事故正是如此。管線回報成功。記錄乾淨。我布設的每個指標都通過。那項工作是胡扯，而我必須在使用者之前先對自己說出來。對自己的工作保持反胡扯紀律，才能讓測試誠實。禮貌不是抵擋真相的盾牌；忙碌也不是價值的替代品。

接觸面梯度：校準通過門檻

Steve Test不是只有單一門檻的一次性通過。接觸面越難收回，通過標準就必須越嚴。²

測試問的是同一個問題。答案所需的嚴格程度，則隨影響半徑擴大。聊天回覆下一輪就能修正；不會因此出大事。一次未通過Steve Test的正式環境部署，會燒掉花了數月才取得的使用者信任，而修正成本比當初省下的出貨決策更高。

實務後果是，當接觸面越難逆轉，出貨節奏就應該放慢，而不是加速。若團隊面對可逆性差異極大的各種接觸面，仍維持一致速度出貨，等於在透露他們不認為測試需要變化。通常，他們已經停止執行這項測試。

品味不是脾氣

Steve Test還需要一個區分，因為這也是最常被遺失的部分。援引Steve，指的是他的品味，不是他的脾氣。

這套原則明確禁止以下行為：³

• 殘酷。
• 羞辱。
• 戲劇化的輕蔑。
• 扮演願景家。
• 用攻擊性取代判斷。
• 怨氣劇場。
• 把戲劇誤認為標準。

Steve層真正運作的訊號，是冷靜的拒絕。「不，這項工作還不值得存在。」這句話應作為判決提出，並接著說出具體修正動作。不是表演。不是羞辱做出不值得版本的人，那個人常常是你自己。不是對團隊表現可見的輕蔑。不是廣播自己有更高標準。工作要嘛過關，要嘛沒有。門檻不是嚴厲姿態的美學。

這個區分很重要，因為Steve Jobs的漫畫化版本常以脾氣為中心。任何曾被表演Steve的人管理過的人，都知道我在說什麼。殘酷不會讓工作變好。它會讓職場變差；而且因為它用表演取代判斷，也會讓出貨成果變差。

判斷你是在Steve的品味層，還是在扮演Steve脾氣的實作測試，是看測試輸出是否是一個具體技術動作。「這項工作不值得存在」不是結論；它是一個問題的開端。答案必須說出失敗軸線、修正動作，以及下一次測試。如果審查只停在「這項工作很糟」，卻說不出什麼會讓它值得，那場審查就是表演。

重做上限與反癱瘓條款

高標準若沒有停止規則，就會變成逃避。我對每一項非瑣碎工作套用的紀律，是3次誠實重做上限。

誠實嘗試的意思是：你辨認出失敗軸線，說出具體修正動作，實質改變做法，並重新用兩項測試評估工作。把同一輪潤飾重複3次，不算3次嘗試。那只算1次失敗嘗試重複了3遍。

如果3次誠實重做後仍無法產出值得的工作，問題幾乎從來不在工藝。問題活在更上游：問題框定、範圍、任務定義，或團隊組成。停止重做接觸面，回頭檢查前提。有時候，承諾太大，超過你能實際維持標準的範圍。有時候，驗證比你以為的更軟。有時候，這根本不是產品問題。

重做上限同時解決兩種相反的失敗模式。它拒絕替薄弱工作背書，也阻止精修變成躲藏。拒絕出貨本身並不高尚。為追求完美而無止境重做，是另一種失敗模式：有工藝，沒有勇氣。目標不是完美。目標是值得且已出貨。不是純粹但永遠待定。

如果你正在同一個接觸面上做第4次重做，你已經停止打造產品，開始把專案當成藏身處。

可觀察徵兆：測試真的執行了嗎？

Steve Test很容易宣稱，卻很難真正執行。紀律在於具體說出這項測試產生了什麼。

在我宣稱一項非瑣碎工作完成前，我會確認自己能回答以下所有問題：⁴

1. 使用者是誰？不是人物誌原型，而是真實情境中的真實人物。
2. 這個接觸面承載什麼觀點？如果說不出來，就沒有觀點，只有待辦清單。
3. 你拒絕或移除了什麼，才讓它保持乾淨？刪除就是測試確實執行的證據。
4. 它如何服務整體產品？這一塊必須與其他每一塊一致。會削弱整體的局部勝利，不是勝利。
5. 什麼證據證明它是可靠的？Jiro軸。驗證已執行；主張有支撐。
6. 它為什麼值得？直白說出來。如果答案含糊，測試就沒有執行。
7. 我是否能毫不退縮地署上自己的名字？品味的判斷器。當判斷不確定時，這是整個技術棧中的主導問題。

如果我無法用具體答案回答全部7題，就代表我只是宣稱這套原則，而沒有套用它。我會把工作退回去。

實例：用7個徵兆檢查真實接觸面

以下是把這些徵兆套用到翻譯事故後出貨的一個具體接觸面：我寫進翻譯管線的併發防護。大約100行Python，如果已有另一個翻譯程序正在執行，就拒絕啟動guide_bootstrap.py或blog_translate_batch.py。

1. 使用者是誰？兩週後要開始一次翻譯執行的我，那時我已經忘記燒掉6個語言版本的速率限制失敗模式細節。也包含未來工作階段中呼叫任一腳本的任何代理。
2. 這個接觸面承載什麼觀點？併發翻譯執行永遠不是正確工具。防護把這個判決寫進程式碼，讓下一個呼叫者不必記住。
3. 我拒絕或移除了什麼，才讓它保持乾淨？我拒絕把防護做成警告。我拒絕提供像--force這種簡短、方便的覆寫旗標。唯一覆寫方式是環境變數I18N_ALLOW_CONCURRENT=1，長到沒有人會不小心輸入。
4. 它如何服務整體產品？翻譯管線、D1寫入器與備援機制各自都是正確的。防護是防止它們組合成悄悄污染整體的那一塊。
5. 什麼證據證明它可靠？我用2個手動檢查驗證防護。第一，沒有其他翻譯工作執行時乾淨返回。第二，真實guide_bootstrap.py子程序存活時，以非零狀態結束。兩項檢查都針對實際腳本執行，不是模擬替身。
6. 它為什麼值得？只要防護存在，造成6個語言版本污染的同一種併發執行競態，就無法再產出混語言D1資料列。這不是防止所有情況；它是防止這套原則剛學到的特定失敗模式。
7. 我是否願意署名？是。一件事、清楚的覆寫語義，並寫進記憶備註，讓未來工作階段承接這個防護存在的理由。

這個實例的重點，是每個徵兆都有具體答案。當我無法產出答案時，測試就還沒有執行。

對照失敗時的樣子。當我草擬併發防護時，針對第3題的第一個答案是：“I refused to over-engineer it.”這句話聽起來沒問題，實際上什麼都沒說。拒絕過度工程，沒有說出我考慮並拒絕了哪個具體事物。那是姿態，不是拒絕。我強迫自己寫出真正的答案：我拒絕把防護做成警告；我拒絕方便的覆寫旗標名稱；我拒絕在防護無法列出程序時失敗開放的行為。那些才是決策。第一版只是原則劇場。

重點整理

給創辦人與獨立建造者： - 在稱任何接觸面值得之前，先說出真實時刻中的真實使用者。抽象的值得無法使用。 - 每個出貨接觸面都應至少有一個可見的拒絕。如果你什麼都沒移除，範圍就是錯的。 - 套用接觸面梯度。部署到正式環境需要比草稿更嚴格的通過；行銷主張需要最嚴格的通過。

給產品主管與PM： - 用每個發布週期中的拒絕與刪除數量，衡量Steve Test是否真的在執行。零，是異味。 - 在自己的審查清單中，把「能運作」和「值得存在」分開。把它們視為獨立軸線。 - 保護重做預算。3次誠實嘗試，然後升級。不要讓完美主義變成躲藏，也不要讓期限壓力殺死測試。

給工程主管： - 為團隊出貨的每個接觸面定義一個Jiro檢查門檻與一個Steve檢查門檻。兩者都必須通過。 - 投資看不見的細節。正確與值得之間的差異，通常藏在接合處。 - 拒絕脾氣。冷靜拒絕才是訊號。嚴厲表演才是失敗模式。

給設計師： - 觀點不是裝飾。它是讓產品可被辨認的機制。 - 值得的接觸面會可見地拒絕某些東西。你的工作包含說出你砍掉了什麼。 - 模糊時的實作測試：你是否能毫不退縮地替這個決策署名？

結語：我願意署上自己的名字嗎？

產品中的主導問題是：這項工作值得存在嗎？當判斷不確定時，整個技術棧中最簡單的主導問題是：

我是否願意毫不退縮地署上自己的名字？

如果答案是肯定，這項工作才有出貨資格。如果答案是「還不行，但可在3次誠實重做內達成」，那就繼續做。如果答案是否定，而且3次誠實嘗試後仍是否定，就重做任務定義，而不是接觸面。

我每次都執行這項測試。對程式碼。對文案。對提交訊息。對文件。對產品接觸面。對這篇文章。

這篇文章刪掉了我一開始以為需要的3個段落：一大段Jobs傳記、一段關於「dent in the universe」那句話的入門說明，以及一段為什麼這套原則使用真實人物名字而不是抽象概念的辯護。它們沒有服務我正在寫給的使用者：一位正在判斷某個自己不確定的接觸面是否該出貨的建造者。這些刪除讓文章更小，也更誠實。而開頭那次翻譯失敗，除了修復之外，也產生了一個永久成品：翻譯管線中的併發防護，現在若已有另一個翻譯工作正在執行，就會拒絕啟動。被拒絕的工作改變了規則。原則學到了東西。

Steve通過。Jiro通過。出貨。

FAQ

什麼是Steve Test？

Steve Test問的是，一項工作是否值得為真實使用者在真實時刻而存在。它和Jiro品質哲學並列：Jiro檢查正確性、證據與邊界情境；Steve檢查值得、一致性、拒絕與品味。

Steve Test和Jiro Test有什麼不同？

Jiro問這項工作是否做得正確。Steve問這項正確的工作到底應不應該出貨。一個功能可以通過測試，卻仍然辜負使用者、產品，或接觸面背後的觀點。

團隊應該何時執行Steve Test？

在不可輕易逆轉的接觸面出貨前執行：公開部署、行銷主張、新手導引流程、定價頁、文件，以及會形塑使用者信任的產品功能。輕量工作可以使用較軟的通過門檻，但公開接觸面需要嚴格門檻。

這項測試應該產生什麼？

測試應該產生具體決策：出貨、重做、刪除，或拒絕。真正的通過會說出使用者、時刻、觀點、證據，以及團隊為維護整體而移除的至少一件事。

Steve Test會變成完美主義嗎？

會。這就是為什麼原則需要重做上限。3次誠實重做已足夠；之後問題通常位於更上游的任務定義、範圍、團隊或前提。

審查範本

把這段複製到草稿區、PR描述、Notion頁面，或提交訊息最上方。在宣告非瑣碎工作完成前填寫。如果有任何一列無法用具體事物回答，測試就還沒有執行。

Steve Test：審查紀錄

使用者：      [真實情境中的真實人物，不是人物誌原型]
時刻：        [使用者遇到這項工作的具體時刻]
觀點：        [這個接觸面主張什麼；它拒絕做什麼]
拒絕：        [我考慮後砍掉了什麼，或從一開始就拒絕建造什麼]
整體產品：    [它如何與產品中相鄰的每一塊一致]
證據：        [Jiro軸：驗證已執行；主張有具體證明支撐]
值得判定：    [是 / 否 / 還不行，但可在N次明確重做內達成]
署名：        [我是否能毫不退縮地署上自己的名字？如果不能，就停下來]

這個範本只有一個工作：強迫測試者在每一列產生具體答案。含糊答案無法過關。「我拒絕過度工程」不是拒絕；「我拒絕方便的覆寫旗標與失敗開放路徑」才是。「它服務使用者」不是整體產品答案；「它補上造成上次事故的那個特定組合缺口」才是。當某一列抗拒具體化，工作就還沒準備好；那份抗拒，就是測試在告訴你重做該往哪裡去。

這個範本是本文的作業成品。此頁其他所有內容，都是在解釋為什麼這些列需要存在。

參考資料