AI作為外部化上下文——重獲個人開發動力

2026年5月12日·4分鐘閲讀·Patrick Schless

AI作為外部化上下文

個人項目曾因會話間隙而夭折。但當我停止試圖將所有上下文都裝入大腦後，情況發生了變化。

像大多數開發者一樣，我腦中總有一些有用的項目想法。在年輕（有孩子之前）的日子裏，我每週輕鬆花20到30小時擺弄個人項目、有趣的語言或新框架。隨着時間推移和個人時間的減少，這變成了零星的幾小時。個人開發項目難以保持動力，最終被完全放棄。有幾年，我打開一個項目，做一兩個週末，然後擱置一個月，再也不回來。原因不是缺乏興趣，而是數學問題。

舊數學

有了兩個年幼的孩子和一份需要專注的正職，副項目必須跨越一個隱含的門檻：“如果我今晚興奮地將所有內容加載到腦中，我是否真的會很快回到這段代碼？”通常誠實的答案是否定的。例如，GoalChasr是一個小型VueJS項目，銷售5美元的iFit相關磁鐵。我有一小羣回頭客和一些關於增長和粘性的想法。我很急切，但發現很難在更大的更改上取得進展。摩擦不在於“下一步要做什麼”，而是每次在幾天後打開項目時，都要重建心理模型，弄清楚代碼處於什麼狀態。在開始寫一行代碼之前，一半的會話時間已經耗盡。

所以我大多不開始事情。業餘愛好轉向更離散、自包含的活動：徒步、遊樂場、適合一個週六的Home Assistant自動化。

變化

我並不是一下子注意到變化的。它是悄悄潛入的。哄孩子睡覺後的一小時個人編碼曾經是30分鐘上下文加載和30分鐘實際流程。但某個時刻，它變成了一整小時的生產力，因為項目的狀態不再存在於我腦中。計劃文件就在那裏，寫着“我們上次在這裏停下，下一步是這個。”我完全跳過了重新熟悉的過程。這不是輕量級的vibe coding，而是“真正”的鍵盤開發工作，上下文基於事先的協議和計劃被餵給我。

對我而言，最有效的外部化形式是一次長時間的前期規劃對話，產生一個書面計劃，然後針對它進行小的實施單元。這種形式中的一個工作流程（不是我唯一使用的，但有代表性）是Matt Pocock的“grill-me”技能，Claude就一個特性對我進行盤問，直到設計具體化，然後是乒乓球式TDD（Claude編寫一個失敗測試，我手工使其通過）。盤問階段佔據了總時間的不小部分，需要專注，因為許多實施決策正是在這裏做出的。之後，路徑就鋪好了，分解成足夠小的部分，任何一個都能在一個晚上完成。

重獲動力

最近我在開發PushForward。它很有趣，雖然並不新穎：一個對話式AI健身教練，將我的Hevy（舉重）和Google Health（步數等）數據拉入一個持續的線程，讓模型瞭解我的訓練歷史。2026年有幾十個AI健身教練，其中一些已經做了跨追蹤器綜合，所以我不聲稱這個想法獨特。我構建它是因為我是用户，而且交付一個真正工作的端到端代理比閲讀關於它們的文章要好。

最近，我給代理添加了新的Google Health API集成。一個大的前期規劃會議涵蓋了架構、OAuth流程、新的代理工具（get_step_count、get_weight_history等），以及它如何融入現有的編排。這被分成了離散的單元，每個都有自己可以在一個或兩個晚上完成的小計劃。大計劃保持方向；小計劃則是我一週後回來時會發現的等待我的下一步。一年前，我不會開始這個。不是因為工作更難，而是因為會話間隙會殺死它。

延遲容忍度

我讀到的多數AI編程見解都是關於每小時產出、每天代碼行數、“10倍生產力”。這些只是程度上的差異，而非種類。對我來説，真正的變化是別的：延遲容忍度。我可以允許的會話間隙從“也許幾天”變成了“幾周沒問題”。這使得開發在這個人生階段重新成為一種可行的愛好，我懷疑相對於速度框架，這一點被低估了。大多數有小孩、要求高的正職或注意力分散的開發者都會認識到這個數學變化，就像他們認識到速度變化一樣。