01 / 27
序2026-10-10 → 10-17 · 衝刺紀錄

積木人生
八日衝刺

一個人加一群 AI 工程師,用 8 天把自用 App 從「能用」打磨到「經得起嚴格審查」——27 個版本、95 條審查發現全數處理,記帳 0 筆遺失。

積木人生 3.3 → 3.29Mac · iPad · iPhone 同一套程式碼後台:Mac mini製作:Claude(Opus 5.5)
SCROLL ↓
鉤最關鍵的一個數字
95

條嚴格審查發現,
分 4 批全部落地。

2.4 萬行程式碼,7 組審查 + 7 組對抗式驗證,留下的 95 條問題,在 5 天內修完並上線。而且三件最在乎的事,結果都是零:

0筆帳遺失
本機=mini:32 筆、1,945 元
0Mac 外觀變動
12 頁 × 淺深色逐像素比對
0critical 等級問題
(high 5 條已修)
要一頁看完

四個數字,看懂這 8 天

版本
27個

3.3 → 3.29,每個版本都有更新紀錄與 git 標籤,可隨時退回。

審查
95條

96 條發現中推翻 1 條;high 5、medium 37、low 53。

最大提速
×593

流鑫重推 4,590 筆:主執行緒 1,364ms → 2.3ms。

AI 協作
56個 agent

平行審查、實作、挑錯、驗收;主控親自審關鍵資料路徑。

×593 = 1,364 ÷ 2.3。agent 數=3.24 總檢 6+Code Review 21+第 1 批 9+第 2~4 批 20(照片功能 2 個未計,尚未完成)。

卷一 · 背景
Ⅰ背景

積木人生是什麼?

重然自用的生活 App。口述的碎片每天由 Mac mini 寫成日記,再加上金句、團膳訂單、記帳,全部收在同一個地方。Mac、iPad、iPhone 共用一套 SwiftUI 程式碼。

日記

碎片 → 日記

Typeless 口述 → iCloud → mini 21:00/03:30 兩班,用「柯黑穆肯」人格寫成 Notion 日記;App 以月曆呈現。

工作

訂單 · 趨勢 · 預知

團膳訂單即時查詢(本機累積 6 個月)、老闆儀表板、天氣與系統監測。

錢

流鑫 · 鑫留

記帳系統併入:「流鑫」看帳、「鑫留」記帳;跟 mini 伺服器每分鐘同步。

❦

審查當天的資料量(實測):日記 65 篇、碎片 318 則、金句 730 句、本機訂單庫 2,018 筆/41 家/96 天。

Ⅱ目標

三個要回答的問題

ACT 1 · 10/10–11

能用嗎?

把團膳查詢、儀表板、記帳系統搬進 App,Mac 先做、手機跟上。

→
ACT 2 · 10/11–12

好用嗎?

手機上一句話送不出去、相機掃不到收據、會不會閃退——把日常用法磨順。

→
ACT 3 · 10/13–17

經得起審查嗎?

開始記真的錢之後,用最嚴格的標準檢查一次,有問題就修到底。

轉折點在 10/12:重然開始用它記真實的帳。從那天起,「資料會不會掉」比「功能多不多」更重要。
Ⅲ節奏

27 個版本,怎麼分布在 8 天裡

每日發布版本數

前兩天衝功能(21 版),後面版本變少、但每一版都更大、更深。
10
11
3
1
0
0
0
2
10/1010/1110/1210/1310/1410/1510/1610/17
10/13 只出 1 版,卻是最重的一版:Code Review 第 1 批改的是記帳同步的核心邏輯,10/14–16 用來驗收與做斷片日記,10/17 一次上第 2~4 批。
卷二 · 長功能
Ⅳ第一幕 · 能用

把散在各處的工具,收進同一個 App

3.3 – 3.6 · 10/10

訂單:團膳查詢原生版

直連 Apps Script;月曆點日期選餐別;雙欄工作台;本機累積 6 個月訂單庫。

3.7 – 3.12 · 10/10

趨勢儀表板 · 三種外觀

老闆儀表板+每月彙總永久保存;訂單/趨勢/預知各自可選「晨霧玻璃/便當紙/原生精修」;金句 1–5 星評分。

3.13 – 3.17 · 10/11

流鑫記帳併入 · 上 iPad/iPhone

記帳系統整包編進來;手機版金鑰內建、首次設定改輸入序號;窄螢幕版面全面檢查。

3.18 – 3.19 · 10/11

手機細節

金句月曆不再疊字;頂端黑帶改成跟著每一頁的底色。

Ⅴ第二幕 · 好用

記帳只剩三個動作

重然的用法很明確:對著一個輸入框用 Typeless 說完 → 讓 AI 分析 → 按確定。於是另開一個專門記帳的頁籤「鑫留」,整頁只做這件事。

01

說一句

大輸入框,打開就有游標。多行清單也放得下。

→
02

AI 分析

mini 拆出商家、品項、金額、分類,出確認卡。

→
03

確認入帳

同一顆主按鈕;入帳後自動清空,可以接著記。

3.21

手機送不出去

多行輸入框按 return 只會換行 → 加一顆箭頭送出鈕。

3.23

打錯字怎麼改

「最近 20 筆」點一下就地展開編輯,商家「全臉」改回「全聯」只要三步。

3.26

序號卡住自己

安裝檔沒有簽名別人裝不了 → 首次開啟只剩選資料夾一步(開關保留)。

Ⅵ第二幕 · 發現盲點

相機掃描,其實從來沒送出過任何一張

查 mini 伺服器紀錄:發票解析請求 0 次。原因是相機只認發票上的兩個 QR,收據和傳統發票根本沒有 QR,讀不到時畫面也沒有任何提示。

照片

相機/相簿/截圖

8 秒讀不到 QR 就提示,並給「拍下來交給 AI 讀」。

→
先試

找發票 QR

有 QR 就用 QR,金額最準。

→
沒有就

手機上辨識文字

照片不上傳,只送文字;同一列品名+金額併成一行。

→
最後

AI 拆品項

商家、時間、品項、分類;卡片提醒「金額看一眼」。

實測 · 模擬全聯收據
445元

4 個品項全對(玉米 92、藍莓 65、鮮乳 89、衛生紙 199),小計、現金、找零、載具都正確略過。

順帶抓到

Mac 一按相機就閃退

App 缺相機權限說明,系統直接結束程式。3.24 補上。

Ⅶ里程碑 · 3.24

第一次總檢:6 組平行掃描

開始記真的錢之後,第一件事是確保「任何一個功能出錯,都不能讓 App 閃退或弄丟帳」。

流鑫本機快取

4,581 筆早期測試資料的刪除紀錄,每記一筆就要整包重寫。
清理前清理後
檔案大小
3.7MB → 57KB
每次存檔
65ms → 1.5ms
統計重算
55ms → 1.6ms
修掉
9類閃退

例:0 元帳讓趨勢圖閃退、視窗太窄時海景閃退、邊打字邊刪品項閃退。

修掉
6種掉資料

最嚴重:試算表一列年份打錯,本機好幾個月的訂單會被整段刪掉。

對帳:清理前後,真實帳 5 筆、671 元,本機與 mini 完全一致。清理前另存了 3.7MB 的備份。
卷三 · 經得起審查
Ⅷ第三幕 · 方法

Code Review:先找、再推翻、才落地

一個 AI 自己檢查自己,很容易「看起來合理」就放過。所以每一條發現,都要經過另一個 agent 實際對照程式碼、試著推翻。

STEP A · 找

7 組平行審查

依檔案分組,從四個面向檢查:渲染效能、併發安全、資料與快取、跨平台版面,再加 AI token 成本。每條都要附現有程式碼、觸發情境、量化影響、重構程式碼。

STEP B · 推翻

7 組對抗式驗證

每組審查配一個驗證者:程式碼真的在嗎?情境真的會發生嗎?修法能不能編譯、會不會引入新問題?推翻 1 條、64 條調整嚴重度或修法。

STEP C · 落地

重然決定 → 分 4 批

把需要取捨的地方整理成 8 個選擇題(A–H)一次回答,再照「資料正確 → 卡頓 → 手機版面 → token」分批,每批做完驗收才進下一批。

Ⅸ審查結果

95 條,沒有一條是「會直接毀掉資料」的

嚴重度分布

critical 0。high 的 5 條裡,有 4 條是同一個根本原因。
95 條
  • 5high · 使用者感受得到
  • 37medium · 資料長大 10 倍才痛
  • 53low · 衛生問題

驗證漏斗

每一條都被另一個 agent 試著推翻過。
審查發現96
驗證後保留95
其中調整過64
原樣成立31

報告 32.6 萬字元、101 段重構程式碼;存在 docs/code-review-2026-10-13.md。

Ⅹ人做的決定

8 個選擇題,一次回答

AI 負責把選項、代價、建議整理好;取捨由重然決定,而且他兩次沒照建議走。

題問題重然的選擇照建議?
A待確認的帳怎麼處理3:入帳=確認分類+「全部照 AI 的確認」是
BCode Review 做幾批3:4 批全做,依序驗收是
C同步衝突怎麼修1:逐欄合併(App+伺服器都改)是
D日記人格檔要不要精簡2:不精簡,維持完整人格否
E同一份碎片要不要沿用結果1:沿用,不重跑 Opus是
F金句分類改用 Sonnet2:維持 Opus否
G清伺服器測試資料1:清(先備份)是
H鑫留顯示今天+昨天合計1:改是

D、F 沒照建議:品質優先於省 token。之後所有實作都照這兩個決定避開,審查者也逐條核對沒有違反。

Ⅺ第 1 批 · 資料正確性

最重要的一條:兩台裝置會互相覆蓋

App 每次都把「整筆帳」推上去,伺服器只比「誰比較新」就整筆蓋掉。用真的伺服器程式重現了這些情境:

S2

分類被蓋回 AI 的

Mac 親手確認分類,iPhone 拿舊資料改備註 → 分類回到 AI 的、又跑回待確認。

S3

刪掉的帳復活

Mac 刪掉重複帳,iPhone 離線補備註 → 帳回來了,實測 180 元被重新算進支出。

R

改的金額消失

iPhone 離線改金額,Mac 舊資料先推上去 → iPhone 的修改被判定「不夠新」而丟掉。

修法 1

只送改過的欄位

App 記下這次改了哪幾欄(changed_fields)。

→
修法 2

伺服器逐欄比時間

每一欄各自記最後寫入時間,誰新用誰。

→
硬規則

兩條鐵律

刪除是單向的;親手選的分類只能被親手改掉。

Ⅻ第 1 批 · 成果

先寫會失敗的測試,再修到它通過

伺服器自動測試

新增的測試在舊程式上都重現了 bug,在新程式上全過。
24
36
修之前修之後

伺服器資料庫(G1:清測試資料)

刪 4,579 筆測試帳+141 張發票+927 個品項+97 個商家。
清理前清理後
ledger.db
2,828KB → 196KB
真實資料 17 筆(有效 12 筆、851 元)一筆未動;動手前留了 3 份備份。

另外 3 位審查者對第 1 批挑出 9 個問題(例:被拒收的帳在某些時機會消失),全部修完才部署。

ⅩⅢ第 2 批 · 主執行緒卡頓

每一項都量過「改前 vs 改後」

改前改後(M4 Pro 微基準)
流鑫重推 4,590 筆主執行緒卡住時間
1,364 → 2.3ms×593
記一筆帳存檔
67 → 0.8ms×84
月曆每次互動滑鼠、點擊、打字
0.923 → 0.0094ms×98
客戶區間表1,100 列首次排版
≈425 → 18ms×24
流鑫首頁第一次統計
209 → 13ms×16
洞察頁「全部」期間
65.1 → 11.1ms×5.9
iPhone 星空底圖
65 → 7.7ms×8.4
星座插畫記憶體
36 → 15MB
快不能換來錯:時間解析 213,793 個字串對拍 0 差異、月曆 116 組「今天」對拍 0 差異、關鍵詞輸出逐字相同。
ⅩⅣ第 3 批 · iPhone 版面

手機是最常用、螢幕卻最小的地方

iPhone 17 可用寬約 402pt。問題都一樣:寫死寬度、沒有窄螢幕版、或判斷依據用錯。原則:只改窄螢幕,Mac 與 iPad 寬版外觀不動。

原本不能用

4 個功能救回來

名稱與分類(「完成」在畫面外)、雷達雲圖(左右各切 239pt)、心情圖示設定(溢出 435pt)、流鑫商家頁(5 欄只剩 1 欄)。

模擬器驗收再修

6 個小毛病

檢視頁標題被按鈕蓋住、洞察數字斷行、星河年份被裁、⌘J 框關不掉、流鑫子頁籤被擋、明細頁頂端按鈕不見。

3.29

頂端頁籤列好滑了

分段選擇器會攔下拖動 → 改成外觀一樣的按鈕,整排任意處都能滑,輕點才切頁。

驗收方式:iPhone 17 與 iPad Pro 13 吋模擬器逐頁截圖;260/326/342/402pt 各寬度實際量測版面。
ⅩⅤ第 4 批 · token 成本

同一份碎片,不再讓 Opus 寫三次

日記一天有三次機會被產生:即時日記、21:00、03:30。碎片沒變時,三次的輸入一字不差——現在直接沿用上一次的結果。

日記送給 Opus 的字數(每月)

依實測「7 天 15 次裡 4 次輸入相同」推估。
改前改後
每月輸入推估值
≈294 萬 → 211 萬字−28%

若照報告再精簡人格檔可到 −58%,但 D2 決定不精簡;品質優先。

不沿用的情況

Codex 代筆版、降級到其他模型的版本、本機備援版、排版失敗的結果——寧可重跑,不鎖住次級品。

金句分類

分不出類的句子不再每 30 分鐘重送:改成 1 天 → 7 天 → 30 天退避。模型與參數照 F2 不動。

ⅩⅥ驗證

「做完」的定義:四道關卡都要過

關卡 1

編譯+自動測試

Mac、iPhone 都編得過;日記系統 112 個測試、伺服器 36 個測試全過。

→
關卡 2

3 角度挑錯

資料安全、狀態與執行緒、版面與決定,各一個審查 agent。

→
關卡 3

實機截圖

iPhone/iPad 模擬器逐頁看;Mac 11 頁打開不閃退。

→
關卡 4

外觀+帳本

新舊版逐像素比對;本機與 mini 對帳。

Mac 外觀比對
24組一致

12 頁 × 淺色/深色;差異都是本來就會動的內容(動畫、隨機句、同步時間)。

帳本對帳(每次動到資料都做)

5 筆 671 元(10/12)→ 12 筆 851 元(10/13)→ 32 筆 1,945 元(10/17):每一次本機與 mini 完全一致。

卷四 · 後台
ⅩⅦ後台 · 日記系統

看不見的地方,也修了四件事

補產

漏產的兩天補回來

模擬 Claude 額度用完,交給 Codex 備援補產 10/1(348 字)與 7/16(308 字);確認整份人格檔(46,201 字)都有送進去。

誤判

用量明明 23%,卻被當成 98%

官方中途把週用量歸零,監控卻死守舊的最高點 → 日記被誤送給 Codex。改成「同週期掉 15 點以上就採新值」。

版本

以為是 Opus 5.5,其實是 Opus 5

mini 的 CLI 舊版把「opus」對到舊模型;更新到 2.1.296 後實測才是 Opus 5.5。

透明

每篇日記最後一行署名

人格版本|實際模型與版本|努力程度|產生時間。誰寫的、怎麼寫的,一眼看得到。

ⅩⅧ新功能 · 斷片日記

工作上預期外的事,當下說、事後修

初衷:突發狀況多、事後難回想。當下記下來,才能事後修正,讓同類問題越來越少。

說

開頭說關鍵字

斷片/短片/斷篇/臨時發生/臨時(共 5 個,Typeless 常聽錯的也算)。

→
拆

每件事五欄

發生什麼、影響、當下處理、可能原因、下次預防;AI 推測的標「推測:」。

→
數

同類本月第幾次

7 個類別:配送、廚房、人員、供應商、客戶、設備、其他。

實測:「配送車爆胎」與「客戶來電抱怨」被正確合併成同一件事。碎片日記照常也收(重然選的「雙寫」),不套人格檔、條理清楚就好。
ⅩⅨ做法 · AI 團隊

主控不寫大部分程式,而是派工與把關

各階段派出的 agent 數

原則:每個 agent 只改自己負責的檔案,避免互相覆蓋;動到真實資料的地方由主控親自審。
6
21
9
20
3.24 總檢Code Review第 1 批第 2~4 批
平行

同時最多 5 個 agent 在跑;重然說「不想等」時就加開。

對抗

實作的 agent 和挑錯的 agent 永遠不是同一個。

主控

部署、清資料、對帳、最後一次編譯,只由主控執行。

ⅩⅩ遇到的問題與解法

踩過的坑,與怎麼爬出來

問題原因解法
以為 mini 的 Claude 登出了從 SSH 讀不到鑰匙圈,顯示「Not logged in」下一則就更正、不叫重然重登;寫進記憶避免重犯
流鑫.app 與積木人生同時開兩個 App 各自握一份待上傳清單,會互相蓋掉移除獨立的流鑫.app,只留積木人生
「待確認」一直不消失學習期設計:確認滿 30 筆才自動放行按「確認入帳」就算確認+一鍵全部確認
「今天才 120 元?」過了午夜,今天只算新的一天同時顯示今天與昨天合計
審查報告只剩結尾彙整 agent 最後只回傳了附錄改成 6 個撰稿者分段寫檔,再檢查 95 條全數收錄
中途資料被系統清掉暫存區(scratchpad)跨工作階段會被清空從審查原始紀錄重建 95 條,改存進專案 docs/
iPhone 模擬器停用CoreSimulator 版本跟 Xcode 不一致重新啟動模擬器服務,不需要管理員密碼
照片標記說得像要唸出來先講了內部格式,沒先講使用者的操作道歉並改成「先講你看到、你按的,再講背後」
ⅩⅪ學到的事

三個值得帶走的做法

01

先量,再改,再對拍

每一項效能修改都有前後數字;每一項邏輯修改都跟舊版逐筆比對結果一致,才算數。

02

動到錢之前,先留退路

清資料前備份、部署前備份、每版 App 另存一份;每次動完都對帳。

03

取捨交給人,選項交給 AI

把 8 個決定整理成選擇題一次問完,人只花幾分鐘,卻決定了接下來 5 天的方向。

ⅩⅫ結論

從「能用」到「經得起審查」

8 天、27 個版本:功能先長出來,接著把每天用的流程磨順,最後用嚴格審查把它修到「記真的錢也放心」。

可靠

同步不再互相覆蓋;壞檔先備份不覆蓋;9 類閃退修掉。

順

最卡的操作快了 16~593 倍,而且結果對拍一致。

省

日記重複呼叫 Opus 減少約 28%(推估),品質不打折。

ⅩⅩⅢ下一步

已排好的順序

進行中 · 3.30

照片功能 開發中

「說一句」可附最多 4 張照片 → mini 上傳到 Notion「今天的照片」區塊;AI 不看圖。另外保留重然自己在 Notion 貼的照片(文字沒改就只換文字、照片放最下方)。App 與 mini 兩端已開工,尚未完成驗證。

隨 3.30 · 已改好

系統監測新增 2 項

Time Machine備份、災難還原提示詞;回報 ERROR 時直接亮紅燈。

之後

消費地圖

流鑫新增「地圖」頁:平面圓點(大小=金額、深淺=次數)+2.5D 柱狀切換,用 Apple 內建 MapKit。目前 15 筆主交易中 10 筆帶座標。

待補

實機耗電量測 待補

動畫限幀與看不見就暫停的實際省電效果,要用 Instruments 在 iPad 實機量。

❦

謝謝閱讀

完整審查報告:碎片月曆/docs/code-review-2026-10-13.md
每一版的更新紀錄:碎片月曆/CHANGELOG.md

❦