Claude Code 的一些使用心得及推薦 Plug-in、Skills 等
- 推薦必備 Plug-in:
- /grill-me /grill-with-docs 確認需求再開工
- 大學長教你別寫廢 Code
- GitNexus
- code-review-graph
- 避免 GitNexus 與 code-review-graph 互相衝突
- 程式運作本身不會衝突，但 Agent 可能會在調用過程中自己跟自己產生矛盾與衝突)
- 我整理了處理方式並提供自動設定腳本 (Windows + VSCode + Claude Code Extension)，請參考:
- 請 AI 說人話的 Output Style:
ASD-STE100 Output Style (Simplified Technical English)
https://gist.github.com/starise/470f53dbd16149dcd168fa45bff17d1f
- 改 C:\Users\{UserName}\.claude\settings.json
加 "outputStyle": "ASD-STE100" - 改 C:\{Repo Name}\.claude\settings.local.json
加 "outputStyle": "ASD-STE100"
- 把我當五歲小孩: Google Keyword: Lydia Hallie ELI5
- 觸發 Session Rolling 5-hour Time Window 的 Schedule
如果 08:00 或 09:00 上班才開始使用，則下一次 Window 得在 13:00 或 14:00 觸發
那上班時間只有 2 個 Time Window 可以使用。
如果在上班時間前兩小時就開始，設定四個排程觸發 Time Window 的話，
比如 05:00、10:00、15:00 (根據上班時間調整)
上班時間就可以有 3 個 Time Window 可以使用。
Schedule 用最省錢的 Haiku Prompt:
This is a test, DO NOT RESPONSE.
即可，這樣可以得到簡短回應類似:
I acknowledge the instruction. No response will be sent.
不須耗費太多 Token
- 試過一陣子之後沒有很推薦的: 省話一哥 caveman (穴居人)
https://github.com/juliusbrussee/caveman
原因是品質可能會下降，這些文章有討論:
https://vocus.cc/article/6a10254ffd897800017eaac1
https://www.bnext.com.tw/article/90550/claude-caveman-prompt-token-saver
- 用 Fable 5 作為主導
- 將任務拆階段
- 分階段派工給最適合的模型 (Opus、Sonnet、Haiku) 執行
- 重要階段完成後必須再派兩個不同視角的 Opus 做對抗式審核
- 完成後再由 Fable 5 審核一次
- 或是使用 advisor (顧問) 功能 (但每次呼叫 advisor 都要重讀一次 context，若頻繁呼叫會消耗大量 token)
- Effort: Ultracode 在 CLAUD.md 指定平行作業或派子代理前都必須要清楚列出
- 有哪幾個階段
- 每個階段派幾個什麼模型的代理
- 各階段做哪些事情
- 由擁有者 (Owner) 審核過後才可以開始
- 每一個階段完成後都要停下來等擁有者 (Owner) 確認後才能再派下一階段 (避免一派工 Token 就爆)
- 小技巧
- 變更帳號: /Switch account
- Agent 執行中如果有問題想問，不用直接打擾他，可以用 /btw 開一個 Side question 視窗來問，這樣不會干擾主線運作。
- 這是一個相當好用的功能，你可以在 Side question 問主線上看到的對話訊息中不明白的部分，但不會因為你的發問而使主線改變作法或走歪。
- 在這個視窗裡面 Agent 只能回答妳問題，沒有權限去動程式或檔案，也不會影響主線的思考與行為。
- 對於不需要留在 context 中的快速問題使用 /btw，答案出現在可關閉的覆蓋層中，永遠不會進入對話歷史記錄，所以您可以檢查詳細信息而不會增加 context。
- No Tool Access: It cannot read new files, run tests, or execute bash commands; it only answers based on the existing conversation context.
- Isolated History: Your question and Claude's reply do not get appended to your primary thread history, keeping your main context window clean.
- Cost-Efficient: It leverages your current prompt cache, minimizing extra token overhead.
- 語言的選擇:
- Agent 對英文和正體中文的理解度
- 基本上沒有顯著差異。Agent 對兩者的語言理解能力相近，都能抓住邏輯和含義。
- 但實務上英文更「安全」的原因
- 術語一致性
- 英文技術文檔用的詞是「標準的」（RFC、論文、官方 API 文件都這樣寫）
- 中文有「服務」vs「服務程式」、「流程」vs「工作流」、「實例」vs「執行個體」的問題——同一個東西不同人寫不同詞，Agent 要重新推論
- Agent 在「中文術語邊界模糊」時出錯率會高一點
- 混合語言的邊界問題
- 設計文件如果一段英文一段中文，Agent 有時會誤判「這句的主詞是什麼」
- CLAUDE.md 規定的「英文檔案 + 中文註解」其實是最安全的（界線清楚）
- 工具鏈的假設
- git grep、Markdown 渲染、代碼生成工具都假設英文
- 中文在正規化、排序、分詞上有額外的複雜性
- 如果是Agent 寫文件
- 語言選擇不會改變Agent 寫的邏輯正確性，但會改變：
- 你們讀起來的成本（混合語言 = 上下文切換）
- 未來維護的成本（誰能改？誰能快速搜尋？）
- 一致性（你們的其他技術文件用什麼語言）
- 所以 CLAUDE.md 要求文件用英文撰寫，不是因為 Agent 對英文的理解更好，而是工具鏈 + 術語 + 長期維護成本 加起來，英文是更好的選擇。
- 要求同時寫英文與中文會消耗雙倍 Token 嗎?
- 不完全是，但接近。
- 實際 token 成本
- 如果是「完整雙語」（英文版 + 中文版都完整）
- 不是 2 倍，大概 1.5～1.8 倍
- 原因：結構和邏輯框架只計算一次，翻譯只是「換詞」，不是「重新思考」
- 如果是「混合版本」（英文為主 + 中文註解）
- 如果是這個專案的現況（對話中文 + 文件英文）
- 基本上是加法，不是乘法
- Agent 對你講話（中文）→ output token
- Agent 寫文件（英文）→ 不同的 output token
- 兩個是分開的，不會互相乘。
- 在專案的實際影響
- 如果設定：
- Agent 和你對話 = 中文（這消耗 token）
- Agent 寫設計文件、md = 英文（這也消耗 token）
- 但不會因為「既要和你中文溝通，又要寫英文文件」就支付 1.5 倍
- 會發生雙倍的情況：
- Agent 寫完一份英文設計文件
- 然後再寫一份完全相同的中文版本
- 那才是接近雙倍
- 所以 CLAUDE.md 中設定只要求英文文件，沒要求中文翻譯版的規則從 token 角度看也是省成本的。
沒有留言:
張貼留言