> For the complete documentation index, see [llms.txt](https://weekly-essay.mikey.wang/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://weekly-essay.mikey.wang/zh-hant/2026/w41-personal-ai-practice-tools-engineering-and-runtime-environments.md).

# W41-Side Project 總結：工具、工程與本機和雲端的取捨

2026 年 10 月 10 日 · 10 月 13 日修訂

中秋國慶長假去了金山嶺阿那亞，挺適合家庭出行。回來後還有幾天空閒，節後第一週工作也不算特別忙，正好把一些想做的事情往前推了推。

回頭看，上週做的事情還不少。治理 AI 的運行環境，繼續做家庭財務工程，替換用了多年的訂閱管理軟件，治理網絡代理的可靠性，再跑一下自媒體的自動化流程。這些項目放在一起，也讓我重新看了一遍這一年使用 AI 的方式。

之前寫過把個人的事情工程化。當這些工程開始裝進真實數據、接上真實賬號，並且需要連續運行時，很多原來沒怎麼在意的問題就冒出來了。

## AI 運行環境維護

我的 Mac Studio 放在公司。平時下班回家或到了週末，我就會遠程讓它做些事情。國慶長假出發前，我想試試，這臺機器能不能在十幾天裡持續保持可用，讓我人在外面，也能隨時調用它，做自己想做的事。

結果過了兩三天就不太行了。期間 Claude 和 OpenAI 的模型有更新，部分客戶端需要手動升級；一些登錄態超時，要重新授權；機器上還有依賴 Chrome 自動化的任務，內存也需要清理。這些問題拆開看都不大，但人在外面時，只要一個環節卡住，後面的事情就沒法繼續。

所以回來第一天，我花了不少時間清理環境，順便補上假期裡的模型進展。

**機器通著電、網絡連著，並不足以保證這套工作環境隨時可用。**

這次之後，我給 AI runtime 增加了日常治理任務。一個方向是檢查各個工具配置的模型，跟進同系列模型的更新；另一個方向是檢查 Codex、Claude Code、Gemini 等運行時的版本，減少配置和工具版本逐漸脫節的問題。

這些事情以前往往是出了問題再處理。現在自己同時依賴的 AI 工具越來越多，維護它們也開始成為一項固定工作。尤其遠程使用時，本地順手點一下就能解決的授權和升級，都會放大成真正的阻塞。

## 家庭財務數據工程

家庭財務工程之前就提過，也已經起了一個基礎。這次花了四五天，主要用 Claude 集中把它往前推進。大概完成了八成，花的時間明顯超過最初的預期。

我想做的是把整個家庭財務情況放進一套可以持續維護的工程裡，後面能夠分析、監控、給出復盤依據，也能按需要生成不同的圖表。真正動手之後，發現圖表和分析只是其中一部分，底下的數據和規則才是大頭。

比如隱私，最開始容易想到的是把金額藏好。後來細分下來，份額也不能隨便公開，因為份額乘上公開淨值就能反推出市值；一些比例和其他信息放在一起，也會暴露原本不打算公開的內容。只看單個字段，很容易覺得它沒什麼敏感的，組合起來就完全不同了。

再比如數據準確性。一條數據是什麼時候發生的，什麼時候錄進去的，是實際觀察到的、計算出來的，還是估算的，需要分開記錄。修正一條舊記錄，也要保留修正關係，而不是直接把原來的內容覆蓋掉。來源抓取失敗時，不能順手生成一個看起來完整的結果；數據缺失也不能用零補上。

這些約束最後要落到程序裡。現在工程在提交前會檢查即將進入倉庫的內容，還會識別文件本身的格式，避免只是改了後綴，就把不應該進入倉庫的原始表格提交進去。提示詞裡的要求需要有程序配合，否則每次執行都只能指望模型記得足夠牢。

這個過程裡，有些問題是我一開始沒想到的，是和 Claude 反覆審查時逐漸暴露出來的。後半程花了很多時間去找邊界、補校驗、再做審查。一個個人項目，只要涉及真實的家庭數據，也不能因為使用人數少，就省掉這些工作。

我對這套工程後續的期待很具體：每個季度更新數據時少做重複勞動，能夠解釋這次和上次為什麼不同，也能知道一個結論到底來自哪裡。

**把事實維護好，分析和可視化可以隨時重做。**

## 跨端訂閱管理工具

相比之下，訂閱管理軟件做得很快。這次我想試的是，能不能用很低的成本，做出一個按自己習慣高度定製、跨平臺使用，而且體驗接近原生應用的小工具。

我先把舊軟件裡的訂閱信息錄了屏，讓 ChatGPT 提取遷移數據。這一步也有細節：只保留我實際點開、展示過詳情，而且仍在進行的訂閱。幣種也要核對，Google One 記的是新臺幣，電信記的是澳門幣。如果這些基礎字段錯了，後面算得再漂亮也沒有意義。

接著做界面、同步和部署。這個工具放在 ChatGPT Sites 上，使用它提供的數據庫能力，在手機、PC 和 Mac 上都能打開。我在 iOS 上把它作為 Web App 使用，實際體驗比預想好不少。

整個迭代過程也很直接。界面有哪裡不符合預期，我就標註出來，做一點測試，再補充需求，繼續調整。對這種只需要服務自己、功能邊界比較清楚的小工具來說，這樣的交付方式挺合適。

我用了很多年的舊訂閱軟件，就這樣被替換掉了。以前買現成軟件，總要接受一些自己並不喜歡的組織方式。現在可以按自己的習慣來做，修改成本也低。它未必需要成為一個面向所有人的產品，只要能把我的這件事處理好，就已經有價值。

**這也讓我重新看了一眼 Web App 這種形式。對於輕量級的工具和效率產品，網頁、託管和數據存儲組合起來，已經能提供相當完整的體驗。再配合 Scriptable 這樣的應用，還可以用腳本補上系統提醒和桌面小組件，把網頁裡的數據帶到手機的日常使用入口裡。**

對於訂閱管理這種場景，Web App 加上一點原生能力補充，已經可以用很低的成本做出高度定製、接近原生的體驗。沒有必要為了一個個人工具，就先給自己安排幾套客戶端的開發和維護工作。

## 網絡代理可靠性優化

還有一兩天，我主要花在網絡代理的可靠性上。

現在很多工作和生產力工具都依賴國際互聯網。只要供應商間歇性不可用，開發、查資料、調用模型都會一起受影響。被卡過幾次以後，我覺得這件事需要認真處理一下。

我繼續迭代代理配置工程，把自建臺灣節點放在第一優先級，商業線路 A 的臺灣節點作為第一備份，商業線路 B 的臺灣節點作為最後候選。AI 流量只走臺灣，國內、公司和私網流量仍按原來的規則直連。這樣既把備用路徑明確下來，也避免為了某個工具能用，就把整臺機器的流量都改走同一條線路。

故障切換交給代理核心處理。現在每 30 秒主動測活，單次超時 3 秒。自建線路不可用時，後續連接轉到備用線路；恢復後，再重新優先使用自建。已經建立的流式連接不能搬到另一臺服務器上繼續，所以切換仍然需要應用重試。這一層解決的是下一次連接能不能繼續工作。

這次還做了 468 輪 HTTPS 測活。自建線路成功 465 輪，商業線路 A 成功 459 輪，兩條線路至少有一條成功的輪次是 468/468。兩條線路的故障在這組樣本裡確實形成了互補。

如果假定兩條線路的故障彼此獨立，並用這次採樣的失敗率估算組合可用率，結果約為 99.9877%。

**按這個假設粗估，組合可用率達到 4N 水平。**

這是基於短期樣本和獨立故障假設的粗估，尚未計入共同網絡故障、故障檢測與切換空檔，也不代表全年實測的可用率。

驗收也需要貼近實際工作。能打開網頁，或者某個接口返回成功，並不說明模型在長時間生成內容時也穩定。我分別驗證了自建線路和備用線路上的真實模型輸出，接近兩分鐘的持續流式都通過了；也用隔離環境模擬自建失效和恢復，檢查備用接管以及恢復後的優先級。測試時沒有關閉實際運行的服務器。

我又把自建節點接入了固定訂閱。節點的連接參數通過 Cloudflare 分發，實際代理流量仍連接自建服務器。Mac 已經接入，手機和 Apple TV 也有對應的訂閱格式，設備端的導入和刷新還需要分別驗收。以後節點參數變化，不用給每臺設備重新發一份配置。訂閱下載本身走商業備用線路，避免自建節點壞了以後，連更新參數也拿不到。

隨後又補上了雙 Mac 的協調管理。兩臺機器通過加密狀態同步管理記錄，同一時間只允許一臺執行管理操作，避免同時改訂閱或重複提交請求。

自建節點以後，我也考慮過通過非工作日釋放、工作日重建來節省成本。真正往下做，又碰到了新服務器的可信身份、創建請求超時後的對賬、狀態恢復和多設備同步。後來我取消了這套週期釋放重建方案，保留現有實例持續運行，繼續讓線路自動切換。

**為了節省一部分實例運行時間，把整個系統做複雜，未必是當下最划算的選擇。**

## 自媒體工作流實踐

另外一個試驗是“AI有圖說”。我想面向大眾做一些 AI 主題的圖文內容，先看看這種方式能走到哪一步。

我用 Multica 組織了一個多 Agent 小隊，把選題、原文核對、編輯、配圖、檢查、人工確認和發佈串起來。目前已經有正式發表的內容，流程不再只停留在草稿階段。其中公眾號仍然保留了我的手機確認，發佈後再核對正式結果。

整個過程裡會遇到不少小問題：選題是不是重複了，文章是不是只轉述了一遍發佈公告，圖片和文字是否一致，平臺到底保存成功了沒有。單獨看都不算很大的技術問題，但要把一次交付做完，就得逐個處理。

流程跑通後，內容本身還很早期。主題不多，選題也還比較生硬，現在談曝光和點贊沒有什麼依據。我更想觀察的是，後面能不能把執行記錄和內容表現接起來，復盤什麼值得寫、怎麼表達讀者才願意看，再影響下一輪選題。

這裡還有不少需要調整的地方。我希望先保持調度方式，把這件事本身做順。把它當成一個小試驗，繼續觀察，會比很快給它下結論更有意思。

## 本機與雲端的運行邊界

這幾件事做下來，我也更在意個人數字助理到底運行在哪裡。現在這類應用越來越多，一個助理可以在雲端接收任務、調用工具、替我執行。但完全雲端的執行環境，與自己擁有一臺本地主機相比，能不能等價地完成生產任務，還要看幾個很具體的條件。

首先是憑證安全。助理要做真實的事情，就需要登錄態、憑證和 Token。這些東西交給雲端以後，存在哪裡，誰能讀取，能授予多大的權限，又能不能撤銷，都需要明確。本地主機上的憑證也需要保護，但我能直接管理它們的保存位置和使用範圍。到了雲端，我需要平臺提供同樣清楚的邊界。

其次是存儲可靠性。個人項目會留下代碼、文件、執行記錄和長期狀態。這些東西能不能持久保存，執行資源被回收以後還在不在，下次任務能不能接著上次的結果繼續，都會影響助理是否真正可用。一次執行完成以後把結果發回來，與長期替我維護一個工程，是兩種不同的要求。

再一個是網絡訪問。雲端執行環境的網絡出口可能限制某些網站或服務。在我的本機上，有些訪問問題可以通過已有的代理配置解決；搬到雲端後，能不能訪問同樣的目標，保持同樣的登錄態，還需要逐項驗證。助理能訪問互聯網，並不等於它能訪問完成這項任務所需的全部資源。

最後是開發和測試環境。以 iOS 應用為例，我目前使用的雲端執行環境是 Linux，不能直接運行 Xcode 和 iOS 模擬器。如果助理能寫代碼，卻沒有對應的工具鏈和模擬器，它能完成的驗收就會受到限制。涉及這些測試時，我仍然需要 Mac，或者一個能提供同等 macOS 工具鏈的執行環境。

**個人數字助理在生產端能走多遠，也取決於憑證、存儲、網絡和工具鏈能否持續支撐它的工作。**

我希望這類應用繼續補齊這些能力。文件能留下來，權限能夠控制，目標資源可以訪問，寫完的程序能夠實際運行和測試，才有條件把一個長期項目交給它。

目前我的訂閱管理工具放在雲端，手機和電腦直接打開就能用；依賴本地憑證、網絡配置和 Mac 工具鏈的任務，繼續在本機上做。