開發工具

兩種帳單，兩種形狀 主機帳單是容量。你加 CPU、頻寬、儲存，指針跟著流量曲線走；看過一個月，下個月能猜到幾個百分點以內的誤差。 token 帳單是行為。兩個流量完全一樣的團隊，帳單可以差 20 倍——因為一個團隊每次請求帶 12,000 token 的檢索上下文，另一個只快取了 400 token 的系統提示、其餘什麼都不帶。同樣的使用者、同樣的功能，帳單天差地遠。 這不是定價的貓膩，而是計量方式決定的：你按 token 付費，而 token 數量是設計決策。 讓花費變跳的三個效應 1. 輸入通常遠多於輸出，兩者單價還不一樣。 在多數對話與檢索功能裡，輸入 token 是輸出的 5～20 倍，而輸出 token 的單價往往是輸入的幾倍。所以「我們只生成一小段回答」這句話，對成本沒有任何說明力。 2. 快取輸入是另一套費率。 供應商對重複出現的輸入給更便宜的價格——固定的系統提示、不變的長文件、大段指令。忽略快取，就等於每次請求都為同樣的 3,000 token 付全額。 3. 每次請求的上下文能差一個數量級。 一個每輪都追加對話歷史的摘要任務，等於每次都把整份紀錄重新送一遍。成本成長比輪數更快：第 20 輪很貴，是因為第 1 到 19 輪又在帳單上出現了一次。 重試與工具呼叫還會再加一個在任何用量圖表裡都看不見的乘數：一次失敗後重試的呼叫會計費兩次；每輪呼叫四個工具的 Agent，每輪計費五次。 槓桿，按收益排序 團隊的第一反應通常是去換模型。那很少是最大的槓桿。建議按這個順序試： 先砍上下文。 刪掉檢索到卻不影響答案的文件、限制回溯的歷史長度、把永遠不變的部分放進快取。這往往是單項收益最大的一步。 限制輸出長度。 直接要求形狀（「三條要點，不要前言」），而不是給一個寬鬆的 token 上限。模型生成的那 900 token 客套話，是你在付費。 不緊急的走批次。 夜間補數、回填、評測這類任務通常可以接受更慢但更便宜的路徑。 最後才換模型。 把摘要任務降級到更小的模型確實是省錢——但這是在前面三步已經壓小的那個數字上，再省一次。 上線前先估一遍 你需要每次請求的兩個數字：輸入 token 與輸出 token。功能已經上線，就直接從 API 回傳值讀，不要估。還沒上線，只能先猜： 每月成本 ≈ 每天請求數 × 30 × (輸入 ÷ 1M × 輸入單價 + 輸出 ÷ 1M × 輸出單價) 猜的時候有兩個坑：一是平均數會掩蓋最貴的那次請求（一份長文件的 p95 請求可能是中位數的 30 倍，而帳單正是它決定的）；二是多輪功能讓平均數失去意義，因為每一輪都拖著完整歷史。 ...

這是協作問題，不是技術問題 這個場景在各個團隊反覆上演：有人打開了 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 中有結構意義 保留（子分隔符） ! $ & ' ( ) * + , ; = 在查詢字串中有意義 其他 空白、"、<、>、%、{}、中文⋯ 必須編碼 保留字元不是「不能用」，而是「有意義」。關鍵問題永遠是：這個 & 是想表達結構，還是想表達資料？如果是資料，就編碼它。 ...

一串看不出意義的數字 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 值，但單位不能靠猜，看位數。 ...