Claude

當 Claude 額度燒太快，我決定自己寫 Python

把 AI 當程式碼在跑 此為深度內容 — 這篇文章深度分析 Claude 額度快速耗損現象，探討如何透過程式碼固化 AI 邏輯以降低 token 成本，並反思 AI 時代的正確分工。 大概從今年初開始，我認真用 Claude Code 處理日常的工程雜事。掃描資料夾、整理 PDF、批次重新命名——這些事情以前要寫腳本，現在直接叫 Claude 做就好。

半夜 Claude Code 跑到一半 token 斷了？這個方法讓它自己醒來繼續

睡覺前把電鍋設定好，隔天早上起床就有熱騰騰的飯可以吃了。 用 Claude Code 跑長時間任務也可以這樣——睡前設好 /loop，token 斷了它會一直等，reset 之後自己繼續，早上醒來結果已經在那裡了。 筆者平常晚上 10 點睡覺，但有時候一個重要任務偏偏要等到半夜 12 點 token 才 reset。盯著螢幕撐兩個小時，那種賣肝熬夜的噩夢感覺又回來了——明明是 AI 時代，結果還是要熬夜。這篇文章就是為了解決這個問題。 詳細說明怎麼做，包含各種情境模擬、最佳 prompt 寫法，以及這樣做到底違不違反 Anthropic TOS。

五個 AI 工具實測：誰能寫出 Production-Ready 的後端服務？

同樣一份規格文件，丟給五個不同的 AI 工具，讓它們各自從零實作一個 FastAPI 後端服務。結果差距大到出乎意料——從 95 分到 63 分，有的直接服務啟動即壞，有的則交出幾乎 production-ready 的程式碼。 此為深度內容 — 這篇文章實測五個 AI 工具的後端程式碼生成能力，量化評估 completion quality 與 production readiness 差異

對印度工程師 R 的一段對話，真正暴露的是 AI Agent 時代的認知轉換

帶一個工程師用 AI，最難的不是教他用工具，而是判斷一件更根本的事： 要幫他修補舊框架，還是挑戰舊框架？ 這兩個選擇表面上差不多，長期效果完全不同。前者讓對方更舒服地待在原地；後者讓對方有機會真正移動。 最近和一位印度工程師 R 的一段對話，讓這個判斷變得很清晰。