Jimmy Chen
跟 Claude Code 協作，真的很像跟老婆相處：
這不是在開玩笑，這是 AI 的真實特性。
某個平凡的早上 11 點——
Gitea 被 OOM Killer 砍了。
連帶 supervisord 也被 systemctl 終止。 SSH 連不上，服務中斷。
我打開 Claude Code：
我：老婆，git-server 被 OOM killed 了，幫我查原因。 她：好，讓我 SSH 連進去... 連不上，SSH timeout 了。 建議透過 AWS Console 重啟。
AI 很想幫忙，但機器連不上也沒辦法。
這時候人類要先處理基礎設施問題。
最厲害的 AI 給的建議，有時候跟 IT 部門的萬年 SOP 一樣： 「Have you tried turning it off and on again?」
我們這次用的是 Level 2：Human-in-the-Loop
沒有最好的模式，只有最適合的模式
「我很好騙 對愛太渴望變成死穴 / 所有防備 全都防不了孤單侵略」
這首歌描述的是：純靠意志力的脆弱狀態。
關鍵：不是二選一，而是用法治來支撐人治。
← 弱法治 強法治 → 高人治 ↑ 低人治 ↓
遷移路徑： → →
OOM 問題出現後，老婆第一個建議：
老婆：加 2GB Swap 我： 等等，AWS EC2 不是不建議開 swap 嗎？ 老婆：對，EBS 的 I/O 延遲太高。那我們用其他方法。
AI 會給通用建議，但人類要判斷是否適合自己的環境。
這就像問老婆「晚餐吃什麼」，她說「吃火鍋」—— 但如果你正在減肥，你得自己判斷。
設定 OOMScoreAdjust=-500 保護 supervisord 後...
OOMScoreAdjust=-500
supervisord: -500 gitea: -500 ← 為什麼？ caddy: -500 gitea-runner: -500
所有子進程都繼承了父進程的 oom_score_adj！
原本想保護 supervisord，結果連 OOM 元凶 gitea 也被保護了。
理論上可行 ≠ 實際上可行
老婆：改成 -900 保護 supervisord，各子進程分別設定。 我： 等等，壓低 application 的 OOM score， 可能讓 kernel 去砍更底層的 sshd？ 老婆：對，風險更高。 我： 那我們換個思路——拉高 gitea 讓它更容易被砍？ 老婆：對！這是更合理的做法。
用 Terraform 加一個 40GB EBS...
Terraform plan 顯示：instance must be replaced
# 錯誤：會替換 instance ebs: - volume_type: gp3 # 正確：獨立的 volume attachment ebs_volumes: - resource_name: backup
「我們之前怎麼做的？」這句話可以避免很多災難。
我： 用 tag-based lifecycle rule，這是我們的慣例。 老婆：好，讓我設定... 我： 等等，s5cmd 有支援設定 tag 嗎？ 老婆：...不支援。
只能改用 prefix-based lifecycle。
即使是人類指定的做法，也要確認工具是否支援。
老婆：備份排程設 0 18 * * * 我： gitea health check 也是 18:00，會撞車！ 老婆：對欸！我改成 20:00。
協作心法 #13：跨系統衝突需要人類把關
我： 等等，group_vars 裡面有 token，應該從一開始就移掉。 老婆：好，我用 filter-branch 重寫歷史。
協作心法 #14：AI 不會主動檢查是否 commit 了敏感資訊
心理學家 Ellen Langer 發現：自己選彩票號碼時，會對中獎更有信心——即使機率完全一樣。
安全性來自「指令正確 + 有審核機制」，不是「誰按 Enter」。
這一天我總共中斷了 AI 58 次。
0 次因為 AI 要執行「危險操作」 0 次因為 AI「完全搞錯方向」 0 次造成「實際損害」
風險的真正來源不是「AI 會亂來」，而是「人類是否保持關注」。
相處方式學老婆：耐心溝通、適時糾正 但別忘了：她說的要驗證、出事你要扛、她不記得上次聊什麼
如果 AI 是人類，這大概是會讓她想離職的一天。 但她不是，所以她只是說：「好的，我來修改。」
HITL 不是因為我們不信任 AI，而是因為：
「明天見，老婆。」
Demo: jimc1682000.github.io/a-day-with-my-ai-wife
正經版說法：這是一份 HITL AI 協作模式的實戰案例分析