市面上談 Claude,多在講它能幫你做什麼。這系列想談的是:在一個有歷史包袱、有合規壓力、不容出錯的公部門專案裡,人跟 Claude 怎麼分工,才能讓 1+1 > 2。30 天全是第一手實戰——不是事後心得,是 AI 當場犯錯、被真實工具打臉、再一步步校正的現場:連錯四次的浮水印、長出兩千多層資料夾的設定意外、看似正確卻會壓垮資料庫的並行寫法,還有弱掃、GCB、稽核軌跡這些少有人從開發者視角寫的合規實戰。貫穿全系列只有一句:AI 負責生出答案,人負責讓它可信。AI 只會越來越強,但正因如此,人怎麼駕馭它只會越來越重要。若這 30 天能讓你多問一句「你這是查過的,還是猜的?」,就值得了。
Day 21:一套完整性監控,最容易死在「合法的變動」手上 延續合規落地的主題,今天談檔案完整性監控(FIM)——一個聽起來很正派、很容易寫進稽核報告的東西,但...
Day 22:從一張不合格的稽核表,到自建集中式 log server 會走到「自建一套集中式 log server」這一步,其實是兩條線在差不多的時間點交會的...
Day 23:用 Jenkins 把合規檢查焊進部署管線 把該做的掃描都焊進去 架構定案是把三種掃描焊進 Jenkins pipeline:SonarQube...
Day 24:我的「專案憲法」——每一條留得下來的規則,背後都有一次教訓 昨天資安篇收在一句話:把散落在一次次對話裡的判斷,沉澱成文件與規範。這份規範,我主要寫...
Day 25:我讓工具來審我的「專案憲法」,它信心最高的那筆,判斷錯了 昨天講怎麼寫一份「專案憲法」,今天講怎麼維護它。因為一份用了很久的規範,一定會長雜草——...
Day 26:AI 每一次都是一張白紙——所以我給它一塊跨專案的共用記憶 昨天結尾我埋了一個問題:CLAUDE.md 管得很好,但它只管「一個專案內」的事。可是...