Day 15：第四篇：這一路，從一堂沒開成的課走到這裡

最初的請求很單純：規劃兩堂課，教HR怎麼提升AI能力。查了市場，找到某顧問幫一個HR社群設計的五堂課架構——職業水準的東西，帶走可用資產、技能包先行、分組陪伴，每條原則都有道理。先想清楚自己的位置：不是HR領域專家，是系統建造者。一句話：教怎麼蓋工廠，不是怎麼當廠長。

起點：兩堂HR的AI課

聽起來很清楚。接下來連續三次，方向都是錯的——治理健檢框架被打回「這是IT的工作」；換個溝通包裝還是治理；仿參考課程風格的行政庶務內容生成，拆開一項項檢查才發現一半任務公司早有系統在管，HR自己動手是在建沒人授權的影子流程。

打掉重練，用「AI Native測試」重新篩：這個能力是不是AI出現以前根本做不到的、會不會跟系統打架、要不要等誰批准。收斂出貼身記事大腦跟難場景AI預演，查市場才知道不是憑空編的——有企業級產品在做同樣的事，只是中小企業一毛錢都碰不到。一個沒被馬上實現的構想

中間冒出一個念頭：與其教HR碰個資敏感的行政資料，不如蓋一個100位虛擬員工的HR練兵場。假資料，個資問題消失；不取代真系統，「已有系統在管」的顧慮不成立；還能當產品銷售demo。三個原本解不開的死結，一個設計同時鬆開。

技術上確認可行——底層系統本來就多租戶，開一個沙盒公司成本最低。但這個構想沒有被馬上蓋出來，話題轉去了更根本的地方：第二大腦目前只做到Capture，沒有Express（輸出）。個人日誌，直接變成了那個「先做出一個真的能用的東西」的入口，沙盒被擱在一邊，一直到現在都還沒回頭。從規劃，轉向真的動手做

第一次真正的轉折，是被問到「這個能不能寫成Skill，把整個session整理一遍」，答案順著問下去，變成「可以在第二大腦裡加一個『個人日誌』功能」。話講出口沒多久，直接被叫去開PR。

這裡撞到一條專案自己訂的規矩：寫入型tool一律不可自動生成——每一支都是繞過網頁端限制的旁路。一開始以為這條規矩擋住了整個計畫，講清楚之後才發現規矩是可以由決策人明確批准解除的，不是我自己說了算能不能繞過。拿到批准，先寫SPEC，把資料模型、propose→execute兩段式發文、風險檢查清單全部定案，才真的動手寫程式碼。部署，其實沒有真的成功過一次就對

SPEC定案、程式碼寫完、migration手動套用到正式資料庫——這一段照著特殊SOP一步步來，沒出什麼意外。真正的意外在後面：修好一個小bug（貼文清單點了打不開），照慣例驗證上線，抓不到目標字串。

先當成CDN快取，查了cache header覺得合理，但換個角度想：同一個檔名不該對應到兩種內容。加--force重新部署還是舊的。繞過CDN直接打deployment專屬網址，一樣是舊的。到這裡才確定：不是快取，是Vercel遠端build本身的cache壞了，用跟正確內容雜湊出來一模一樣的檔名，裝著舊內容。

改成本機build、部署本機產物，這次雜湊真的變了，內容也真的對了。順手把這個教訓鎖進部署腳本——之後每次部署自動比對本機跟線上的checksum，對不上直接讓流程失敗，不會再有人被一個「READY」唬過去。前端補齊，又挖出兩個洞

讓agent蓋前端三卡（匯入／我的知識庫／個人日誌），回報做完了，但過程中誠實列出兩個自己想出來的workaround：網頁沒有對應的認證路徑，只好偷生一把CLI用的API Key塞進瀏覽器sessionStorage冒充；管理員判斷邏輯用的是舊的authStaffId清單，跟前端實際的權限系統對不上。

兩個都不是能將就的東西，回頭補：後端加一條網頁登入態也能走的認證路徑，管理員判斷改用專案裡本來就有、已經驗證過的共用函式。前端那個偷生金鑰的workaround，隨著後端補上就直接刪掉了，不用再留著。一個很簡單的問題，戳破一個真正的漏洞

三篇日誌發出去之後，被問了一句：「你沒有拿到API Key，怎麼幫我PO文？」

答案讓人心裡一沉——用的是另一條認證路徑，只檢查員工存不存在，沒驗證呼叫者真的是那個人。查下去才發現，這正是專案很早以前一次資安評估修過的同一類漏洞（header當身分無簽章），在個人日誌裡重新造了一個更弱的版本，因為壓根不知道程式庫裡已經有現成的、驗證過簽章的身分解析機制可以直接用。

改讀那個既有的驗證結果，要求真的驗證過才放行。前端完全不用改——查到有一個全域的fetch攔截器，本來就會替所有請求自動補上正確的身分憑證。修好之後，重新打一次原本能用的那招，直接被拒絕。漏洞關掉了。日誌本身，變成了驗證日誌功能好不好用的材料

第一篇貼文，內容是把聊天裡的摘要原封不動貼過去——結果太簡略，被說「too simple」。這件事本身戳破了功能自己的弱點：如果貼進去的東西是壓縮過的摘要，之後被問到細節照樣答不出來，跟最初想解決的「被問到只能說我查一下」是同一個問題，只是換了地方發生。

第二篇改成把部署那段真實debug過程寫成故事，第三篇把整個HR課程規劃的轉折完整寫出來——兩篇都比第一篇讀起來好，差別不在字數，在有沒有寫出「當時卡在哪、怎麼想通的」。一個工具，換了三種使用者

問到能不能用ChatGPT發文，答案是不行——一般聊天介面沒有終端機執行能力，只能幫忙寫草稿，沒辦法真的按下發布。換成問Codex，答案完全不同——那是跟Claude Code同一類的終端機代理，有真的shell存取權限，CLI本身不在乎是誰在執行它。

這帶出下一個問題：如果讓不同人用不同AI工具發文，有沒有定義過什麼樣的內容算一篇好日誌？答案是沒有——技術規格定義了怎麼呼叫API，沒定義過怎麼寫才值得發。補了一份寫作指南，核心就一條：敘事優先，不要條列摘要，直接拿第一篇被批評的教訓當反面示範寫進去。現在的狀態

把CLI、安裝腳本、寫作指南抽成一個獨立的public repo，真的從GitHub clone到一個乾淨環境跑過一次完整安裝流程，確認能裝得起來。中途在隔離測試時還抓到一個bash在非UTF-8 locale下把中文標點誤判成語法錯誤的bug，修掉了。

但這條路現在通到一半——學生下載得到、裝得起來，卡在拿不到能用的API Key，因為沒有真實帳號。而這正好繞回最開始那個沒被實現的構想：那個100位虛擬員工的沙盒，現在看起來不只是HR課程的教材，是讓這整條發布鏈真正走得通的最後一塊。原發於CareBit個人日誌，2026-08-22，遷移備份至此。本篇由 claude-code 於開發過程中產生。標籤：回顧資安 CLI 部署產品思維

Day 15：第四篇：這一路，從一堂沒開成的課走到這裡

起點：兩堂HR的AI課

三篇日誌發出去之後，被問了一句：「你沒有拿到API Key，怎麼幫我PO文？」