從 iOS 裝置端相片處理、Solidity 安全初篩工具到 macOS 語音工作流程，我把產品構想落實成不依賴雲端伺服器、可直接在本機驗證的軟體。
「AI 能加快實作速度，但系統穩不穩定，取決於邊界設定得夠不夠清楚、測試有沒有老實跑過，以及未達標時願不願意直接捨棄。」
在 iPhone 本機製作照片回憶影片，人物由人確認。
「AI 整理候選名單，由人決定人物歸屬。」
常見的雲端相簿會把整份照片庫傳到遠端伺服器分析，且經常自動把不同人誤認合併。我想做的是在不開任何網路權限的前提下，完全在 iPhone 上完成人臉偵測、照片分群與回憶影片製作。
透過 Swift Actor 劃分權限：Apple Vision 人臉偵測只負責找出相似臉孔並放進待審清單。在使用者於介面上手動點擊確認之前，絕對不把資料寫入本機 SQLite 資料庫。
01. 本機讀取：透過 PhotoKit 讀取相片，App 本身完全不申請網路權限。
02. 裝置端偵測：由 Apple Vision 找出人臉位置與特徵點，全程在 iPhone 上運算。
03. 整理候選：把特徵相近的照片挑成候選組，不直接判定屬於同一個人。
04. 手動確認：在 SwiftUI 審查介面由使用者確認人物，避免系統誤認。
05. 本機儲存：確認後的關聯寫入本機 SQLite，平均每張照片記憶體增加 0.215 MiB。
06. 影片合成：使用 AVFoundation 直接在裝置上輸出回憶影片。
01. 匯入防護：匯入未受信任的 Solidity 程式碼時做路徑檢查，預設不執行專案自帶的編譯腳本以策安全。
02. 語法樹分析：執行 27 項已對應的 Slither 偵測規則，產出精確的程式碼行號與呼叫關係。
03. 格式整理：將不同偵測器的輸出轉換成統一資料結構，並對照 CWE/SWC 分類。
04. 資料儲存：將抓到的問題點存入本機 SQLite，作為後續說明的唯一依據。
05. 輔助說明：LLM 只能根據 SQLite 裡的紀錄解釋問題與建議改法，不允許額外發揮。
以靜態分析為準的 Solidity 漏洞初篩工具，限制語言模型只解釋已確認的問題。
「靜態分析器負責抓出漏洞依據，LLM 只負責解說與修復建議。」
直接用 LLM 檢查合約容易產生幻覺，無中生有捏造漏洞，或是漏掉關鍵的邏輯問題。開發者需要省時的初篩工具，但不能把語言模型的自信措辭當成真正的安全檢查。
本機建構預設停用原生編譯指令以防惡意腳本。系統執行 27 項經過驗證的 Slither AST 規則，將問題結構化存入 SQLite，並限制 LLM 只能針對已確認的規則輸出做解釋。
跑在 macOS 本機的語音工作流程工具，重要操作必須彈出確認，不在使用者不知情下直接執行。
「涉及修改或送出的操作必須由使用者確認，指令模糊時不擅自猜測執行。」
用語音控制電腦時，一旦辨識聽錯很容易造成誤刪檔案或發錯訊息。另外，如果麥克風一直把聲音往雲端伺服器傳，在辦公環境會有很大的隱私問題。
用狀態機區分操作性質：查資料等唯讀操作直接執行；修改檔案或送出表單等操作一律先跳出確認視窗。背景另外跑一個獨立的守護程序，萬一語音模組崩潰可在 0.43 秒內自動重啟。
01. 聲音擷取：按下熱鍵才開始收音，16kHz 音訊直接放記憶體，不上傳雲端。
02. 本機轉文字：用 faster-whisper int8 在 CPU 上跑辨識，中位數約 2 秒完成，不連外網。
03. 文字清理：比對專用詞庫修正常見錯字，把口語轉換成比較規律的指令格式。
04. 動作分類：判斷這條指令只是單純查資料，還是會變更系統狀態。
05. 跳出確認：只要涉及刪檔、送出或寫入操作，必須在螢幕上按確認才會繼續（測試中 0 起自動送出）。
06. 執行與記錄：執行已確認的指令，並將操作記錄加密存入本機 SQLite，背景守護程序負責監控行程。
從確認需求限制到實際測試驗收的五個階段。
寫程式前先確認系統限制與驗收條件，把不能踩的底線先訂清楚。
規劃資料走向、模組權限與資料結構，避免不同元件互相干擾。
搭配 AI 工具編寫程式碼、處理型別與資料庫操作，由我逐一檢視產出。
跑單元測試、長時間穩定度測試與記憶體檢查，用實際數據確認狀況。
檢視測試結果。表現不如預期的模型或做法直接捨棄，只保留通過的方案。
記錄我進行過的規格約束測試、容器評估與基準環境搭建，包含未完成的嘗試與停工原因。
以下為實驗過程記錄，遇到邊界限制或難以客觀驗證時均已停止推進。
用本機 JSON 契約與規格檢查機制，約束 AI 輔助工具的檔案修改範圍。
能否透過機器可讀的本機規格檔案與自動檢查，限制 AI 輔助工具只在指定範圍內修改程式碼？
實作 JSON Schema 規格定義、離線檢查工具與自動驗證腳本，檢查多個 Agent 的修改是否超出檔案邊界。
R1 階段在 12 次測試中，成功擋下了所有未經授權的跨模組改動與外部依賴調用。
推進到 R2 階段的 G2 關卡時停止：實驗顯示，若沒有人工逐行審查規格，仍無法完全避免語意漂移。既然缺乏足夠證據證明外部有效性，我選擇直接停工，不擴大實驗。
不能讓 Agent 自行回報修改是否合格；檢查機制必須完全獨立於模型之外，由外部腳本直接驗證。
測試 30 套開源自架軟體的 Docker 本機部署、資源消耗與繁體中文在地化狀況。
市面上的開源自託管工具，在一般電腦的本機 Docker 環境下實際跑起來的資源佔用如何？繁體中文支援度是否堪用？
為 30 套開源專案撰寫 Docker Compose 配置、測試繁體中文（zh-TW）語系檔相容性，並透過腳本記錄啟動狀態與健康檢查。
記錄了各專案閒置時的記憶體佔用（從 42 MB 到 1.8 GB 不等），指出其中 14 款工具在地化有缺字或未翻譯問題，並整理了資料庫冷啟動時間。
所有測試僅在開發用筆電的 localhost 執行。需要對外註冊網域、設定 SMTP 寄信或多租戶認證的項目沒有做真實連網驗收；這份記錄並非雲端正式上線的穩定度證明。
開源專案的 GitHub Star 數和中文化完整度沒有正相關；另外環境設定檔如果沒有釘選鏡像版本，隔幾個月重新啟動很容易直接報錯。
在乾淨隔離的環境下重現開源專案歷史 Issue，測試 AI Agent 的解題表現。
如何在不污染本機環境的前提下，客觀測試 AI 工具修復真實開源專案 Issue 的能力？
選定 3 個真實開源任務（Immich、Uptime Kuma、Paperless-ngx），建立單一 commit 的乾淨封存倉庫與獨立的測試驗證腳本（Oracle），並以 Docker runner 測試清理機制。
V3 完成了 3 個任務的重現與測試驗證；V4 嘗試加入 Linux cgroup 隔離檢查，但清理測試未通過。
V4 在正式測試（Pilot）開始前就主動叫停：因為無法在 Docker 環境下完全確認 process 清理乾淨（cgroup.events 找不到），試行執行次數為 0。既然環境不夠嚴謹，就不能發表任何效能比較數據。
測試環境的隔離驗證比想像中棘手；如果測試基座無法保證完全乾淨，直接停工比硬跑出有問題的數據更踏實。