Posts

這是協作問題，不是技術問題 這個場景在各個團隊反覆上演：有人打開了 Agent，看著它做事，然後某一天發現唯讀開關不見了，或者在你還在看第一個 diff 的時候它還繼續在改。一小時後分支上有四十個改動，一半跟任務無關，沒人說得清 src/legacy/ 為什麼被動過。 接下來的抱怨總是同一句：我已經不認識這份程式碼了。 嚴格說，這不是 Agent 的 bug，而是一條從來沒被寫下來的規則，正在被一次次事故發現。 寫一段更長的提示詞沒有用 第一反應通常是寫更長的 prompt：「不要改無關檔案、不要刪測試、不要動部署設定」。它能撐過這個 session，然後就消失了。 提示詞是「每個 session、每個人」的；放在專案裡的檔案會被每一次 session、每一位同事、每一個你換用的 Agent 讀到——更關鍵的是，它可以像程式碼一樣被審查。團隊只需要在一個 PR 裡吵一次，而不是每次被 Agent 嚇到才吵。 四道護欄，按收益順序 1. 規則檔。 AGENTS.md（或 CLAUDE.md，或你的 Agent 從專案根目錄讀取的那個檔案）定義什麼叫「做完」：哪些指令才算驗證、哪些路徑不能碰、哪些事絕對不能自作主張。短到人也會願意讀。 2. 權限清單。 三份清單，結構比語法重要： 清單 放什麼 例子 allow 唯讀操作，加上專案本來就會跑的 test / lint / build Bash(pnpm test:*) ask 會改寫歷史、安裝套件、連網的行為 Bash(git push:*) deny 機密檔案、正式環境設定、部署流程、破壞性指令 Read(./.env) 沒有列到的一律回到「問人」。真正要避免的失敗模式是：權限寬到沒有人願意讀。 3. 保護路徑。 機密檔案、正式環境設定、資料庫 migration、CI 定義都要被明確點名，規則檔與 .gitignore 裡各寫一份。這一步把「判斷題」變成「機械檢查」——而只有機械檢查能扛得住截止日期。 4. 合併前的審查清單。 護欄判斷不了設計好壞，所以清單負責補位：diff 是不是超出這個任務該有的規模、有沒有刪掉或放寬測試、有沒有把錯誤悄悄吞掉、總結裡的數字是否都能對應到某次指令輸出。 護欄產生器 可以用一份短表單產出上面這四份檔案——指令、允許路徑、保護路徑、要強制的規則——並且跟著頁面語言切換中英文。 護欄做不到什麼 把邊界講清楚比誇大宣傳重要，因為誇大最容易讓團隊信錯東西： ...

一種沒人及時發現的失誤 請 AI 總結一條 CI pipeline，你會得到一段很整齊的話：lint 階段 42 秒、build 3.5 分鐘、整條 pipeline 16.4 分鐘、比上週快 18%。讀起來像一份報告。兩小時後才有人發現 build 從來沒花過 3.5 分鐘，而失敗率是從另一週抄來的。 這段話看起來沒有任何可疑之處。問題就在這裡：編造的數字和真實的數字，排版上完全一樣。 為什麼模型會這樣 AI 寫摘要時並不是在查你匯出檔裡的行，而是在生成「最像下一個詞」的內容——而「像」不等於「有出處」。兩種失誤最常見： 編造：那個位置需要一個數字，於是就生了一個。「失敗率 2.4%」會出現，是因為 pipeline 摘要裡通常有失敗率，而不是因為 2.4% 真的存在。 漂移：數字本身是真的，但在流轉中變了樣——被四捨五入兩次、秒與分鐘換算錯、從相鄰的行／週／專案串了行。 這兩種都能通過人工審閱，因為審閱看的是文字邏輯，不是算術。 五分鐘核驗流程 1. 留原始匯出，不要只留摘要。 把 CSV、日誌、SQL 查詢結果交給 AI。如果來源本身就是摘要，就沒有東西可以核對了。 2. 把每個數字都當成需要出處的斷言。 一條實用規則：沒有來源行號，就不進報告。 這跟新聞業要求引用出處是同一個道理，只是用在算術上。 3. 先對單位，再對數值。 1500 ms、1.5 s、0.025 min 是同一個時長。AI 摘要裡大量「看起來錯」的數字其實是單位或四捨五入造成的，而真正編造的數字就藏在這片雜訊裡。 4. 留出容差。 摘要裡保留三位有效數字的數值不可能和原始的 4183000 完全相等。設一個小的相對容差（1% 是合理預設值），超出容差的判定為「待核實」，而不是直接判錯。 5. 把「待核實」和「錯誤」分開。 待核實代表你貼的來源裡找不到它——它可能是對的，只是來自你還沒提供的資料；但在找到那個來源之前，它不能進報告。 AI 數字核驗器 把第 3～5 步自動化了：把 AI 回答和來源一起貼進去，它會抽出每個數字、正規化單位與倍數量詞、逐一比對，並把找不到出處的標紅，同時給出對應的來源行號作為證據。 標紅之後要做什麼 按影響從大到小處理，並替每個數字歸類： 現象 常見原因 處理方式 完全找不到，但量級合理 編造 刪掉，或要求提出出處 差幾個百分點 四捨五入、口徑不同、週期不同 確認統計週期再用 只在單位換算後才相符 摘要造成的偏差 可以用，但要寫清單位 對到相鄰但不同的行 串行 更正，並複查相鄰數字 這套方法的邊界 比宣傳更重要的是講清楚限制：核驗工具確認的是可追溯性，不是真實性。 ...

兩種編碼，兩個任務 Base64 和 URL 編碼都會把「不安全」的字元替換成安全字元。這種表面相似，正是它們經常被搞混的原因——要嘛該用一種卻用了兩種，要嘛乾脆用錯了。 一句話版本： Base64 讓二進位資料能通過只支援文字的通道 百分比編碼 讓文字能安全地放進 URL 各自到底做了什麼 Base64 用 64 個字元的字母表（A–Z a–z 0–9 + /，結尾用 = 補齊）重寫位元組。每 3 個位元組變成 4 個字元，體積因此增加約 33%。 Man → TWFu Hello → SGVsbG8= 百分比編碼把在 URL 裡不安全的字元替換成 % 加兩個十六進位數字（對應 UTF-8 位元組）。 a b → a%20b 書籤管理 → %E6%9B%B8%E7%B1%A4%E7%AE%A1%E7%90%86 a&b → a%26b 關鍵差別 Base64 百分比編碼 目的 讓二進位穿過文字通道 讓文字安全地待在 URL 裡 字元集 固定的 64 個字元 任意位元組，寫成 %XX 體積變化 +33% 變化很大 誰能還原 任何人 任何人 提供安全性 否 否 常見位置 JSON 欄位、data URI、郵件附件、JWT 查詢參數、路徑片段 什麼時候用 Base64 把小型圖片以 data URI 內嵌進 CSS 或 HTML 在 JSON 裡傳檔案、縮圖或簽章 透過 MIME 寄送郵件附件 構造 Authorization: Basic 請求標頭 JWT 的 header 與 payload 段 需要雙向轉換時，直接用 Base64 編解碼工具，不用裝任何東西。 ...

Base64 線上編解碼工具 Base64 要解決什麼問題 很多系統只傳「文字」：郵件協定為 7 位元 ASCII 設計，JSON 定義為文字，HTML 屬性裡放的是字串。但我們真正想傳輸的東西——圖片、PDF、金鑰、二進位協定資料——是位元組串流，裡面很容易混進控制字元、引號與換行。 把原始二進位直接塞進文字通道，遲早會出問題：換行被改寫、引號提前結束字串、代理伺服器吃掉一個位元組。Base64 的做法是：只用 64 個所有文字系統都認得的字元重新表示這些位元組。 A–Z a–z 0–9 + / 結尾的 = 只用於補齊。整個字母表就這些。 Base64 的原理 Base64 每處理 3 個位元組（24 位元），就把他們重寫成 4 個字元（4 × 6 位元）： 輸入 位元數 輸出 Man 24 位元 TWFu Ma 16 位元 + 補齊 TWE= M 8 位元 + 補齊 TQ== 由此直接得到兩個結論： 結果大約比原文大 33%（3 個位元組變成 4 個字元） = 的數量告訴解碼器最後一組缺了幾個位元組，一個或兩個 = 表示結尾不完整 Base64 是可逆的、完全公開的編碼，沒有金鑰，也沒有任何保密性。 日常開發中在哪裡遇到 Base64 Data URI：background-image: url(data:image/png;base64,...) 把小圖示直接內嵌進 CSS JSON 介面：在 JSON 欄位裡傳檔案、縮圖或簽章 郵件附件：MIME 用 Base64 編碼附件，讓它們能穿過只支援文字的郵件伺服器 HTTP Basic 認證：Authorization: Basic dXNlcjpwYXNz 就是 user:pass 的編碼結果 JWT：Token 的 header 與 payload 兩段都是 Base64URL 字串 Base64 不是加密 這是最重要的一點：Base64 不提供任何保密性。 ...

為什麼 JSON 總是難以閱讀 每個介面回傳、每份設定檔、每行日誌都是 JSON。壓縮後它是一整塊字元牆；格式化之後同樣的資料兩秒就能掃完。資料完全相同，差的只是空白——這也是「JSON 格式化」成為開發者最常用搜尋之一的原因。 格式化、壓縮、驗證的差別 操作 改變什麼 什麼時候用 格式化 加縮排與換行 閱讀、審查、排查問題 壓縮 去掉所有多餘空白 傳輸、儲存設定 驗證 不改內容，只報語法錯誤 送出請求或提交設定前 這三件事在 JSON 格式化工具 裡都只差一次點擊，而且全程在瀏覽器本機完成。 什麼才算合法的 JSON JSON 的語法非常小，而且比 JavaScript 嚴格得多： 鍵名必須用雙引號包起來 字串必須用雙引號，單引號不合法 不允許多餘的逗號 不允許註解（// 和 /* */ 都不行） 值只有這幾種：物件、陣列、字串、數字、true、false、null 數字不能有多餘的前導零，NaN／Infinity 也不是合法值 如果你寫過 JSON5、JSONC（VS Code 設定）或 JavaScript 物件實字，其中一些習慣在 JSON 裡是違法的。 最常踩的五個錯誤 1. 多了一個逗號 { "name": "NavShelf", "version": "1.0", } "1.0" 後面那個逗號，是 JSON 錯誤的第一大來源。 2. 用了單引號 { 'name': 'NavShelf' } JavaScript 合法，JSON 違法。 3. 鍵名沒加引號 { name: "NavShelf" } 同樣：JavaScript 合法，JSON 違法。 ...

一個典型的壞連結 你拼了一個搜尋連結，英文下一切正常，使用者一輸入中文就掛： https://example.com/search?q=書籤管理 & page=2 伺服器收到的 q 是 書籤管理 ，還多了一個叫 page 的參數——本來屬於查詢值的 & 被當成了分隔符。#、=、?、+ 和空白也有同樣的問題。 解決辦法是百分比編碼（URL 編碼）：把不安全的字元替換成 % 加兩個十六進位數字，表示它的 UTF-8 位元組。 書籤管理 → %E6%9B%B8%E7%B1%A4%E7%AE%A1%E7%90%86 & → %26 空白 → %20 哪些字元是安全的 RFC 3986 把字元分成「未保留」與「保留」兩類，只有未保留字元可以原樣出現： 類別 字元 說明 未保留 A–Z a–z 0–9 - _ . ~ 任何位置都安全 保留（結構類） : / ? # [ ] @ 在 URL 中有結構意義 保留（子分隔符） ! $ & ' ( ) * + , ; = 在查詢字串中有意義 其他 空白、"、<、>、%、{}、中文⋯ 必須編碼 保留字元不是「不能用」，而是「有意義」。關鍵問題永遠是：這個 & 是想表達結構，還是想表達資料？如果是資料，就編碼它。 ...

一個讓很多人意外的數字 貸款 100 萬，年利率 4.5%，30 年： 每月還款 5,066.85 還款總額 1,824,067 其中利息 824,067，相當於本金的 82% 更讓人意外的是前五年：五年一共還了 304,011，但其中只有 88,421 是本金，剩下 215,590 全是利息。還了五年，本金幾乎沒什麼動。 這不是陷阱，而是「餘額計息 + 長期年限」的必然結果。看懂這個形狀，你才是在有意識地選貸款，而不是只盯著月付。 你可以在貸款試算工具裡用自己的數字跟著算。 兩種攤還方式 本息平均攤還（等額本息）：每月還款金額固定不變。前期利息占大宗，後期本金占大宗。好規劃，但總利息較多。 本金平均攤還（等額本金）：每月償還的本金固定，所以利息逐月減少、月付也逐月減少。首月最高，末月最低，總利息較少。 計算公式 本息平均攤還：M = P × r × (1+r)^n / ((1+r)^n − 1) 本金平均攤還：每月本金 = P / n，利息 = 剩餘本金 × r 其中 P 是本金，r 是月利率（年利率 ÷ 12），n 是還款月數，M 是本息平均攤還的固定月付。 年限的影響比利率還大 同樣 100 萬、4.5%，只改年限： 年限 月付 總利息 還款總額 10 年 10,363.84 243,660.91 1,243,660.91 20 年 6,326.49 518,358.50 1,518,358.50 30 年 5,066.85 824,067.12 1,824,067.12 從 20 年拉到 30 年，月付只降了 20%，總利息卻多了 305,709。這就是多出來的那十年真正的價格。 ...

多數人真正想問的是反過來的問題 大多數計算機告訴你「你將來會有多少錢」。但真正的問題通常是另一個方向：「我想在某個時間點存到某個數字，每月該存多少？」 這是個能直接解出來的方程式，而且答案往往比想像中樂觀——因為報酬替你分擔了一部分。 你可以一邊看一邊用儲蓄目標計算機算自己的數字。 先看基準線：報酬率 0% 是什麼樣 目標 100 萬，已存 5 萬，期限 10 年。 如果完全沒有報酬，剩下的 95 萬要平攤到 120 個月： 950,000 ÷ 120 = 7,916.67 / 月 這是「純靠自律」的數字，後面每一點報酬都會把它往下壓。 報酬率承擔了比想像中更多的份額 同樣的目標、同樣的 10 年、同樣的起始金額，只改報酬率： 年化報酬率 每月需存 累計存入 報酬貢獻 0% 7,916.67 950,000.00 0.00 3% 6,673.27 800,792.49 149,207.51 5% 5,909.56 709,146.87 240,853.13 8% 4,859.45 583,134.58 366,865.42 按 5% 算，你只需要存入約 70.9 萬，而不是 95 萬——目標的四分之一由報酬完成。8% 時接近 40%。 但別把這幾行當成菜單。 更高的報酬率意味著更高的風險與更大的不確定性。穩妥的做法是用保守值（5% 甚至更低，扣掉費用與通膨），到時候比預期好是驚喜。 時間才是威力最大的槓桿 同樣的 100 萬目標、5 萬起始、5% 報酬： 期限 每月需存 累計存入 5 年 13,761.01 825,660.32 10 年 5,909.56 709,146.87 20 年 2,102.91 504,699.09 從 10 年拉到 20 年，每月需存從 5,910 降到 2,103，不到一半；而且累計存入反而更少，因為複利多了整整一倍的時間。 ...

資產成長只有兩股力量 你的資產成長永遠來自兩個來源：你投入的錢，和已經在那裡的錢所產生的報酬。前期幾乎全靠前者，越往後後者越占主導——長期財富主要來自這個轉折點之後。 單利是線性的：100 元按 7% 每年固定賺 7 元，永遠如此。複利是幾何的，因為每年的報酬是按「更大的基數」算出來的。差別就這一點，結果卻天差地遠。 計算機用的公式 年末資產 = 年初資產 × (1 + 年化報酬率) + 當年投入 有兩個假設需要說明，因為它們會直接影響結果： 報酬按「年初資產」計算——這正是複利的來源 當年投入按年末計入，從下一年才開始產生報酬——這是偏保守的假設。如果你是每月定期定額，實際結果會比預測略好 你可以用資產成長計算機自己跑一遍，全部在瀏覽器本機完成。 一個具體例子：10 + 每年 10，報酬 7% 初始 10（可以理解成 10 萬），每年再投入 10，年化報酬 7%。 年份 年初資產 當年報酬 當年投入 年末資產 1 10.00 0.70 10.00 20.70 2 20.70 1.45 10.00 32.15 3 32.15 2.25 10.00 44.40 4 44.40 3.11 10.00 57.51 5 57.51 4.03 10.00 71.53 6 71.53 5.01 10.00 86.54 7 86.54 6.06 10.00 102.60 8 102.60 7.18 10.00 119.78 9 119.78 8.38 10.00 138.16 10 138.16 9.67 10.00 157.84 十年下來你一共投入 100，最終拿到 157.84——其中 47.84 來自投資報酬，接近最終資產的三分之一。 ...

一串看不出意義的數字 1735689600 是一個合法時間，1735689600000 也是。兩者相差 1000 倍，肉眼看不出差別——這正是第一個最容易踩的坑。 它們都是 Unix 時間戳：從 1970-01-01T00:00:00Z（epoch，紀元時間）起算經過的時間。資料庫存它、API 回傳它、日誌裡全是它，但人腦讀不了它。 秒還是毫秒？ 知道規則之後就很簡單： 位數 單位 大致對應 10 位 秒 2001 → 2286 年 13 位 毫秒 同樣日期，數值 ×1000 JavaScript 的 Date.now() 回傳毫秒，多數後端語言與 Unix 指令回傳秒。這個不一致是經典 bug：毫秒值除以 1000 會得到 1970 年附近的日期，秒值當成毫秒用也一樣會落到 1970 年。 Unix 時間戳轉換工具 會自動判斷位數，兩種都顯示。 為什麼轉換出來「不對」：時區 時間戳本身沒有時區，它表示的是一個絕對時刻；是你的呈現方式帶了時區。 2026-01-01T00:00:00Z（UTC）在台北是 2026-01-01 08:00:00 在紐約是 2025-12-31 19:00:00 所以當時間戳「顯示成前一天」，問題幾乎總是：少了 Z、缺了時區位移，或者伺服器用本機時間格式化、而用戶端用 UTC 理解。 轉換工具會把 ISO 8601（UTC） 與本機時間兩行並排顯示，差異一眼可見。 實務上的幾個場景 資料庫：存 UTC，依使用者時區呈現。存本機時間是少數幾個很難挽回的日期決策之一。 日誌：請求旁邊那個 10 位數字，基本上就是秒級 epoch 時間。 API：看欄位名稱——created_at、createdAt、timestamp 常常是 epoch 值，但單位不能靠猜，看位數。 ...