論述基礎與限制

一篇 Flutter「畫面落後邏輯狀態」的 work-log 文章，把解法段框成「正規解優先、心跳擺最後」——監聽 controller / scheduleFrame 排在前、定時強制排 frame（心跳）被標為「最後手段」。這個序列剛好複製了作者自己的解題歷程：原本用心跳解，後來才換成監聽的寫法。讀者指出教學該介紹多種做法、心跳也是一種可試的方法，修法是把解法段改成情境並列（依訊號斷點與可改動範圍選），心跳定位為並列解法之一。適用範圍是「同一問題有多個成立解法」的教學內容；只有單一正解的主題不受此原則約束（正解就是正解，沒有情境並列的空間）。

核心原則

教學文章介紹多種解法時，排序的依據是「各解法在什麼情境成立」，不是「作者依什麼順序採用它們」。當作者把自己的解題歷程直接寫進文章，容易把「時序上的後來」誤植成「價值上的更優」——後來換的解法排在前、先前用的解法被貶為墊底或最後手段。

這個誤植會抹掉先前解法原本成立的情境。作者換解法通常是因為在「自己這個情境」發現更直接的路徑，但那不代表先前的解法在「所有情境」都較差。讀者的情境可能剛好是先前解法成立的那一種（在這篇案例裡：改不動出問題的 plugin），這時被標為「最後手段」的解法反而是他的首選。教學把作者的個人路徑當成通則序列，就讓這類讀者誤以為自己選了較差的路。

這次的情境

畫面落後有幾種解法：監聽 controller（ValueNotifier + addListener）、Ticker 每幀刷新、定時強制排 frame（心跳）。這幾種不是優劣關係，是適用不同訊號斷點——controller 暴露的狀態值落後就監聽、改不動來源就定時強制刷新。

原稿的問題出在框架而非內容。三種解法都寫到了，但用「正規解 vs 後備」的序列包裝，把心跳貶到「最後手段」。這個序列不是從情境推導出來的，是從作者「原本用心跳、後來換監聽」的時間線抄過來的。對「能改到 controller」的讀者，監聽確實較直接；但對「改不動 plugin」的讀者，心跳才是成立的解，卻被文章標記成退而求其次。

修法是把序列換成並列：解法段改為「依訊號斷點與可改動範圍選」，每一種解法先說「它是什麼、在什麼情境成立」，再讓讀者按自己的情境挑。心跳的小節標題從「最後手段」式的命名改成「定時強制排 frame（重繪心跳）」，導入改成原則先行（這個解法是什麼）加情境（適合改不動來源時），不再用時序排出的價值高低。

理想做法

寫多解法教學時，把作者的解題歷程和文章的解法排序分開處理：

1. 排序依情境，不依時間線。每個解法先回答「在什麼訊號 / 條件下它成立」，讓讀者用自己的情境對號入座。作者「原本用 A、後來換 B」是個人經歷，不是解法的價值序列。

2. 避免把採用時序寫成價值詞。「先試正規解」「最後手段」「退而求其次」這類詞會傳遞價值高低。如果高低是從情境推出來的（例如「多數情況訊號可以直接接回」有數據或機制支撐），可以保留；如果只是複製作者的採用順序，改成中性的情境並列。

3. 測試反向情境。問一句：「換一個情境，這個被我排到最後的解法會不會反而是首選？」如果會，它就不是價值序列裡的墊底選項，是情境並列裡的一支，序列框架要拆掉。

跟其他原則的關係

• #152 設計選擇要框成選擇、不是必然：#152 處理的是把「有條件的設計選擇」講成自然法則（去掉條件性）；本卡處理的是把「作者的採用時序」講成價值序列（去掉情境性）。兩者都在抹掉「這是有條件的選擇」，一個靠必然框架、一個靠時序排序，讀者都會誤以為沒有其他成立的選項。
• #210 壓縮結論剝奪推導路徑：作者已經走完 A→B 的推導，文章卻只輸出「B 較優、A 是墊底」的結論序列，丟掉「當初為什麼選 A、A 在什麼情境成立」的推導。本卡是 #210 在「多解法排序」情境的具體表現——被壓縮掉的正是各解法的適用情境。
• #151 教材給技術理由、不替方案下品質評價：「後備」「最後手段」帶價值評價味，跟 #151 的自評誇飾同屬「用評價頂替理由」的大類。差別是 #151 評的是方案品質（教科書級 / 完美），本卡評的是方案在序列裡的位階（正規 / 後備），而位階又來自作者的採用順序。

判讀徵兆

文章出現「先試 X、Y 擺最後」「最後手段是 Y」這種解法序列時，比對這個序列是不是剛好對應作者「原本用 / 後來換」的時間線。如果對應得上，多半是把採用時序寫成了價值序列。接著測反向情境：在某個成立的情境裡，這個被排到最後的解法會不會是首選？會的話就拆掉序列、改成情境並列。附帶一提，這次修稿也順手換掉了一個簡中高頻、繁中少用的詞，但那是地區用語問題，跟本卡的框架問題是兩回事。