kojenchieh

AI 時代下最值得投資的 UI 自動化:30 天用 Claude Code 學會寫 Playwright

回歸測試一輪一輪重點,職缺清單上的「自動化經驗」越來越刺眼,而你買過的程式課,還停在第三章。 先說一個好消息:門檻搬家了。AI coding 工具出現後,學 UI 自動化卡的關卡從「會不會寫程式」變成「會不會描述需求、判斷得了對錯」——這兩件事,恰好是測試人員練了多年的本行。 這個系列用 30 天,帶不太寫程式的你,以 Claude Code 為結對夥伴學會 Playwright。

a093448086

生活中的 AI 應用：我在家用 NAS 養了一隻 Agent，幫我看盤、顧家、盯備考——30 天自架實錄

半年前，我在家裡的 NAS 上架起一套 AI Agent 系統。它每天清晨整理美股收盤、早上把投資晨報送到我手機、白天照看家裡的溫濕度，夜裡再把當天發生的事消化成長期記憶。 這 30 天，我把它從頭拆給你看：容器怎麼切、Agent 的人格檔案怎麼寫、記憶怎麼分層與遺忘、排程怎麼編排，以及成本與品質怎麼治理。 但這不是教學文，比較像一本除錯日記。有一半的篇幅在講我做錯了什麼——那些監控全綠、系統卻正在安靜出錯的時刻，才是自架最真實的部分。 我也會誠實交代這套系統的邊界：它遠沒有想像中聰明，而那正是它能長期跑下去的原因。每篇結尾附一排關鍵字，讓想動手的人可以直接接上。

archong

Karpenter 大木匠用精準刀法切爛你的雲端成本

你是不是也遇過這些 Kubernetes Over-provisioning 的經典日常： 為了偶發的 Pod，不得不常駐一群預備用的 Node Group，錢就這樣默默流掉... 傳統 Cluster Autoscaler 擴展太慢，等 Node Ready 好了，流量高峰早就過了... 用 Spot Instance 省錢，但管理多種 Instance Types 和異構架構（Arm/x86）搞得像在踩雷... 再拿傳統的 Node Group 砍柴了，你需要的是動態裁切的精準刀法！

ksz54213

量化交易入門：從 K 線到可組合的交易策略引擎

Hi 我是James, 後端軟體工程師，量化交易零基礎。這 30 天不是我來教什麼，是我們從頭學一遍，把過程紀錄下來。 切入點是把量化交易當成一條資料 pipeline：資料進來、算出特徵、判斷條件、產生訊號、決定部位、下單、記錄。 前段先弄懂免費資料源怎麼抓、K 線在講什麼、自己實作的指標算得對不對；中段試著從逐筆成交與掛單簿挖特徵；後段把策略拆成能用設定檔組合的積木，學怎麼回測、怎麼算真實成本、怎麼判斷結果是不是自己騙自己；最後讓它在 testnet 上跑起來。

newton

諸神也搖頭的 Legacy Code： 30天 .NET 工程師生存之道

這個系列會分享工程師每天面對 Legacy Code 時，該怎麼更有策略性的面對，前半段會從 Legacy Code 的定義開始，聊聊為什麼程式明明能跑，大家卻不敢改，並整理出一套面對舊程式時可以反覆使用的處理方式，中間會處理各種常見困境，例如需求正在催、問題必須馬上修、規則沒人說得清楚，或改一個地方影響的程度，後半段則會討論龐大程式碼的整理、新舊系統如何逐步交接，以及團隊快撐不住時該怎麼做，希望走完 30 天後，大家不一定會愛上 Legacy Code，但至少不會太過害怕。

雷N

賢者大叔的觀測結界：讓 agent 推理得動的 30 天

我有一隻查得動 Prometheus 的 AIOps agent。丟進真實系統跑 RCA benchmark，九項只拿兩分——猜錯 label、寫錯 TraceQL，最後編出一個不存在的 trace ID。 這 30 天從這份成績單倒著往回挖：agent 架構錯在哪、上下文錯在哪（用 OpenTelemetry Weaver 把 schema 變成機器可讀的約束）、再把散落的訊號收斂成 Signal Plane 讓資料可推斷；接著用評估證明修好了，最後才敢上線（授權邊界、執行護欄、人在迴圈核准）。 終點是告警燒起來、agent 能協助調查、將結論回到 Grafana。

Zion Wu

AI 時代下，如何建立真正可持續的軟體交付能力

AI 讓軟體開發變得更快，也讓團隊更容易看見原本被速度掩蓋的問題。當程式、測試與文件都能被快速生成，真正影響交付能力的，會回到團隊是否理解需求、是否看得懂系統、是否能安全修改，以及是否能在風險擴大前取得回饋。這個系列想討論的，是 AI 進入開發流程後，團隊該如何重新建立判斷、協作、驗證與調整能力，讓速度不只停留在個人產出，而能轉成長期穩定的交付能力。

Pod042A

遠古聖遺物改造工程：遺留系統全面重構實務指南

許多長期運作的系統仍提供重要功能，卻因文件不足、缺少測試、相依關係混亂或技術停止支援，逐漸難以理解、修改與交付。這類系統通常稱為遺留系統（Legacy System）。 本系列以「重新設計並建置目標系統，最終替換遺留系統」為主線，內容涵蓋需求與範圍確認、舊系統分析、目標設計、功能重新實作、測試、正式切換及舊系統退場。 系列不預設特定框架或架構，適合正在維護長期運作系統、準備替換既有系統，或希望建立完整重構流程的開發與維護人員閱讀。

dandanisgood

買錯保險的血淚教訓：我用 Python + AI Agent 重構人生財務防禦系統

買保險總是遇到人情壓力？條款動輒幾十頁根本看不懂？ 曾經我也踩過不少保險血淚坑，直到我發現：許多財務決策，其實可以透過程式與資料結構來釐清。 這系列帶你用 AI 守護自己的現金流，手把手帶你從零建構的 AI Agent 實戰指南。 三大核心： 🔍 財務健檢與保單斷捨離：用 JSON Schema 進行狀態抽取，精準分析條款缺口。 🌌 30 年平行宇宙人生模擬：用有限狀態機 (FSM) 結合歷史股市引擎，模擬真實財務黑天鵝。 ✉️ 60 歲未來復盤信：手刻極簡 RAG 引擎，透過 Prompt 限制生成具備理財價值觀的感性回信。 打造真正適合你的個人財務防波堤！

dawish

中文系MIS的Claude協作嘗試：我們如何保存自己的思考脈絡？

我是中文系出身的MIS，工作經歷約3年，大約從工作第2年開始慢慢地將AI工具整合進工作流程中。 我主要用 Claude Cowork 處理工作中的判斷與紀錄。 這個系列預期會是一個非典型背景、非程式工作者的AI摸索整理筆記──關於我如何試著在與 Claude 協作的過程裡，找到讓思考脈絡不隨對話消失、讓判斷依據事後可追問的做法。 這 30 天主要會著墨在人與 AI 協作的流程設計，不是開箱即用的工具或skill包(當然還是會有)，而是 30+個可以自己試驗的小概念。 希望從橫亙人文與資訊工作的角度，呈現我自己對於人與 AI 協作的理解。