有位 V2EX 網友（iswalterwu）分享了自己打磨的開發工作流「Dev-circuit-ultra」，主打比 OpenSpec 這類規格驅動工具更少的上下文維護、更快的交付節奏。這是一則分享創作類的貼文，截至目前還沒有其他留言討論，數據都來自作者自行測試。
這份 A/B 到底測了什麼
作者用同一個 records CLI 的開放任務，讓兩種工作流各跑一個會話，最後對交付成果做盲評。數字上，Dev-circuit-ultra 相比 OpenSpec：模型成本從 $0.1060 降到 $0.0743（約 −29.9%）、輸入加輸出的 token 從 113,337 降到 72,308（−36.2%）、快取讀取量下降約 48.6%、留在倉庫裡的文件從 3 個檔案 273 行縮到 2 個檔案 132 行（−51.6%），盲評滿分 30 分則是 27 對 26。
先把證據強度說清楚：這是單一任務、單一會話的自測 A/B，屬於個案經驗層次，不是大型研究或多人重複驗證的結果。作者自己也只在貼文裡放了這一輪對照，方向有參考價值，但換個任務類型、換個模型，數字未必一樣。把它當成「值得自己試試看的方法」比當成「結論」更合適。
工作流本身的核心想法
這套流程是五步循環：設計釐清與意圖卡、挑一個可獨立驗收的端到端切片、實作與驗證、獨立審核、驗收合併。比較特別的是它把「決策歷史」和「開發現場」完全分開，倉庫裡只留現行設計，改了就覆蓋、收尾就刪卡，被否決的方案寫進專案外的私有 git 帳本。作者也誠實標明了隔離強度：只有容器級的檔案系統隔離才叫「保證」，prompt 層面的約定不算。
從健康角度，這類「更少上下文、更少維護」的工作流，真正省到的不只是一家 AI 服務的帳單。文件維護量少一半，代表你要反覆開檔案、來回比對舊設計的次數也變少，眼睛的近距離對焦負擔和腦子的切換成本都跟著下降。這點在 追技術更新到半夜的工程師照顧眼睛與睡眠 那篇也提過：真正傷人的往往是大任務本身，而是反覆切換與無止盡的核對。
想自己試的話，先設一條停損線
這種「自己打磨工作流」的過程有個常見陷阱：優化本身會變成另一個熬夜的理由。貼文作者寫著「這兩天優化了自己在用的開發工作流」，如果你也打算趁晚上把自己的流程調一輪，可以先替自己設幾個界線：
- 先用一個小任務試跑一輪，別直接拿進行中的正式專案當實驗場。
- 給優化本身設時限，例如一個晚上、一個週末，時間到就回到原本能交付的流程。
- A/B 只跑一輪時，把結果記下來就好，別當成定論急著全面換軌。
幾個值得留意的身體訊號
調整工作流的過程常伴隨長時間盯著 agent 的輸出、反覆跑測試，久坐和用眼會先反映出來。如果你在這幾天出現眼睛乾澀刺痛、肩頸僵硬到頭痛、或躺上牀腦子還在跑「剛才那個流程哪裡可以再省」，這些是該休息的訊號，起來走動、閉眼幾分鐘、把螢幕調暗都比硬撐劃算。若眼睛不適持續好幾天或視力出現變化，就值得掛個眼科檢查，別自己歸因成「太累」而已。
效率工具的討論在工程師社羣永遠不退流行，這篇分享可貴的地方在於作者把隔離強度與測試條件都寫得算透明。至於要不要跟進，你的眼睛、肩膀和睡眠會比任何 token 統計更早告訴你答案。如果你也常在深夜為了「再調一下」而捨不得睡，可以看看先前聊過的 依賴 AI 編程工作流程時的工作節奏照顧，裡面有幾個把自己排回優先序的做法。
例外處理
若引擎要求必須附上 2 至 3 張文內圖，請以正文中兩行