前言 嗨嗨大家好呀～最近過得怎麼樣呢？ 不知道大家有沒有在用 Claude Code 呀？我猜應該大部分的人都是用 CLI 在跑吧？不過今天想跟大家分享一個小發現喔，就是它的 VSCode 擴充功能其實也很好用耶！想來偷偷推坑一下大家。 介面長這樣子 不知道從什麼時候開始，這個擴充功能變成左右兩邊都有面板的設計了。 右邊是平常（？）會用到的聊天欄，左邊則是過去 session 的列表，整個一目瞭然。 點一下左邊的「New session」之後，就會在中間的程式碼編輯器區域開一個聊天分頁出來喔。 如果手很癢狂點的話，是真的可以量產出超多個的呀！ 而且還可以把它們排成磚塊狀的版面，看起來超酷 der。 設定都可以用滑鼠點點點 模式啊、設定啊那些，全部都可以用滑鼠點選就搞定，超方便的對不對？ MCP 伺服器的設定也是圖形化介面，新手看了完全不會心慌，介面真的做得很貼心。 用 Plan 模式來做俄羅斯方塊 我這邊用 Plan 模式來嘗試做做看俄羅斯方塊喔！ 對了對了，
CLAUDE.md 一旦設計好，Claude Code 的生產力真的會差很多，我把自己實際在用的設定方式和工作流整理給你看: 剛開始用 Claude Code 的時候，真的很容易有一種「哇，也太神了吧」的感覺。你用自然語言跟它講，它就能幫你寫程式、跑測試，連重構都能一起做，整個很像多了一個很能幹的搭檔。 可是差不多用了一陣子之後，很多人都會開始卡住。像是： * 明明之前講過一樣的要求，它這次又用不同風格寫 * 每個專案的規則都要重講一次，講到有點煩 * 想用 sub-agent，卻不知道到底要怎麼拆、怎麼設計才合理 我自己後來很有感的一件事是，這些問題很多其實不是模型不夠強，而是 CLAUDE.md 沒有設計好。 我平常同時在跑本業、副業，還有一些自己的 side project，所以 Claude Code 幾乎已經變成我每天工作的固定夥伴。最一開始，我的 CLAUDE.md
前言 最近有在玩 Claude Code 的人應該越來越多了吧？老實說，它真的超強，寫 code、跑 terminal command、讀寫檔案幾乎都可以幫你處理，工作效率會直接拉起來。但也正因為它能力很大，如果安全設定沒先弄好，其實也很容易踩到風險。 所以這篇我想幫大家整理一下：到 2026 年 3 月為止，根據 Claude Code 官方文件，最值得立刻先設好的 10 個安全項目。如果你現在正開始用 Claude Code，這篇可以直接當成你的安全設定 checklist。 ① 先把 sandbox 打開 這個真的是最重要的一個，沒有之一。 只要把 sandbox 啟用，Claude Code 執行的 Bash 指令就會被隔離在 OS 層級的安全環境裡，
前言 各位有沒有試過讓 AI 寫的程式，再交給同一個 AI 來審查呢？ 老實說，我自己也這樣做了一陣子喔。讓 Claude Code 寫好實作，然後直接在同一個 session 裡跟它說「幫我 review 一下」。乍看之下沒什麼問題，它也會回我一些建議。可是某一天我突然有種感覺，覺得「這個 AI 是不是對自己寫的程式碼太寬容了啊」，這個疑慮就一直揮之不去。 就在這樣的時間點，2026 年 3 月 31 日，OpenAI 發佈了專門給 Anthropic 的 Claude Code 用的官方外掛 codex-plugin-cc。它能讓你在 Claude Code 的 session 裡呼叫 Codex，得到第三方視角的審查意見。
我自己實測過兩種版本的CLAUDE.md： * 一個是寫到100行，很完整很安心那種CLAUDE.md * 一個是砍到35行，剩下全部丟去 .claude/rules/ 結果你猜怎樣？ 35行那個，Claude表現直接比較好。而且是「很明顯」的那種好。 那為什麼會這樣？ CLAUDE.md，其實是「User Message」，不是System Prompt 也就是說，它不是什麼最高權限的設定，而是在系統prompt後面，被加進來的一段「使用者訊息」。 而且啟動的時候，還會一起塞一堆東西進去： * auto memory * MCP tool * skills * 各種context 所以問題來了， 你的CLAUDE.md，會被「淹沒」。而且不是單一原因，是4種機制一起打你。 ① 越後面越沒存在感（Recency Bias） LLM超現實的，它會比較重視「最近講的話」。 所以當你對話到第50輪的時候，
前言 嗨嗨大家好！想跟大家分享一個蠻實用的運用主題喔。 在 Claude Code 這類 AI 程式設計代理工具裡面，「Skills（技能）」已經成為日常運作的核心了。只要把提示詞、工作流程還有禁止事項整理寫進 SKILL.md，代理工具就會在需要的時機自動讀取，並且切換自己的行為模式，真的是蠻聰明的一個機制。 不過實際運用下來，有一個讓人頭痛的難題會浮現出來，那就是「Skills 在團隊內部到底要怎麼分享？」。越好用的 Skills 當然越想推薦給同事，但是硬把全部 Skills 推給所有人其實不是好辦法。畢竟有些 Skills 是依附在自己個人工作流程上面的，甚至有些會跟別人的環境八字不合。 這篇文章想以我自己在運用的 dotfiles 入門套件作為範例，來介紹一種不依賴中央集權的 Skills 分享設計。希望能給大家在思考 Skills 運用時一些參考喔。 「團隊共用 skills repository」會遇到的困擾 大家一開始最容易想到的方案應該是：「做一個團隊共用的 skills
This is 美國女科學家Kiki, a brand new site by Kiki that's just getting started. Things will be up and running here shortly, but you can subscribe in the meantime if you'd like to stay up to date and receive emails when new content is published!