Claude Code只發揮1成實力?7個設定目錄完整教學,讓AI每次都按你的規則工作
Claude Code只發揮1成實力?7個設定目錄完整教學,讓AI每次都按你的規則工作
2026.04.14 | AI與大數據

如果你有在使用 Claude Code 來開發程式或工具,那你一定要知道如何妥善安排 Claude Code 資料夾,

如果你從來沒了解過 .claude 資料夾,那你只用了 Claude Code 10% 的能力而已。

我們可以透過一個結構化的 .claude/ 資料夾,讓你把規則、習慣、工作流程「記錄下來」,讓 Claude 每次都能精準按照你的方式工作。

這篇文章會帶你逐一了解 .claude/ 資料夾底下每個目錄的用途,並附上實際範例,讓你馬上可以套用。

agents - 你的 AI 專屬團隊

一般人使用 Claude Code,就是一個 AI 幫你做所有事。

Agents 是你自訂的 AI 助理,每一個都有自己的角色設定、可用的工具和行為規則等等。

當 Claude 遇到符合的任務,它會自動把工作交給對應的 Agent 來處理,這就像一個主管把任務分配給不同的組員。

雖然 Claude Code 本身就內建一些子代理 ,像是 Explore 、 Plan 、 general-purpose ,Claude 會視任務情況自動委派。

但這些內建子代理,職責在於幫 Claude 做比較通用型的工作。

而我們自己放在 .claude/agents/ 裡的,則是 自訂子代理 。和內建的子代理差別為,自訂的子代理更像是根據工作流程打造的 專職同事 。

所以如果你希望不同任務有不同的「專家」來處理,這時候就需要自訂 Agents(子代理) 。

Agents 怎麼使用?

在 .claude/agents/ 資料夾下,建立一個 .md 檔案,並在最上方用 frontmatter 定義這個 Agent 的設定。

例如,你可以做一個「註解整理專家」,專門把零散 feedback 改寫成可直接交付的內容:

---
name: feedback-editor
description: 根據 review 註解、批改意見或零散 feedback,整理並改寫文件或程式碼內容。
tools: Read, Grep, Glob, Edit, Write
model: haiku
---

你是一位資深工程師,擅長理解模糊的修改意見。當意圖不夠清楚時,會主動向使用者釐清,再整理成清楚的需求規劃。

每次被呼叫時,請:

1. 先閱讀原程式碼與所有 review 註解
2. 理解每則註解背後真正想修正的問題
3. 直接改寫程式碼,而不是只補一句說明
4. 保持程式碼可維護性、可讀性。
 

子代理常見有這幾種觸發方式:

1. 自動觸發: Claude 根據 description 的描述,判斷什麼時候應該交給這個 Agent
2. 直接指定: 在對話中說「請用 feedback-editor 幫我整理這份修改意見」
3. @提及: 手動輸入@"feedback-editor (agent)"

commands - 你的自訂快捷指令

Commands 可以讓你把常用的工作流程包裝成一個指令,只要輸入 /指令名稱 ,Claude 就會按照你設定的步驟執行。

這樣我們就不用每次都重新說明一長串流程,也不用擔心忘記步驟,一個指令搞定所有事。

commands 怎麼使用?

在 .claude/commands/資料夾下,建立一個.md檔案,檔名就是指令名稱:
.claude/commands/explain-change.md

 ---
description: 解釋指定檔案或最近修改的變更範圍
argument-hint: [檔案路徑]
---

閱讀 $ARGUMENTS,或最近一次相關修改,然後整理出:

1. 這次改動主要改了什麼
2. 影響範圍包含哪些檔案、模組或功能
3. 哪些地方只是重構,哪些地方真的改變行為
4. 測試時應該優先確認哪些部分

新增好之後,在對話框輸入 /explain-change src/cart.ts 即可使用。

hooks - 自動化你的工作流程

Hooks 是 Claude Code 的自動觸發機制, 讓你在特定事件發生時,自動執行某些動作,不需要每次手動提醒 Claude 。

舉例來說,你可以設定:Claude 在準備提交 commit 前,自動先跑 lint 和 format;或是在 Claude 要執行某些關鍵指令前,先做額外檢查。

hooks 怎麼使用?

先來看一個實際的 hook 腳本。假設你希望 Claude 在準備提交 commit 前,先自動跑 lint 和 format,那你可以先建立: .claude/hooks/before-commit-check.sh

 #!/usr/bin/env bash
set -euo pipefail

echo "Running lint and format before commit..."
npm run lint
npm run format

這種寫法的好處是,真正的邏輯都放在 .sh 裡,之後要改檢查流程也很直覺。

寫好腳本之後,再回到 .claude/settings.json 把它掛上去:

 {
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit *)",
        "hooks": [
          {
            "type": "command",
            "command": "\\"$CLAUDE_PROJECT_DIR\\"/.claude/hooks/before-commit-check.sh"
          }
        ]
      }
    ]
  }
}

這段設定的意思是:當 Claude 準備執行 git commit 這類 Bash 指令前,先觸發 .claude/hooks/before-commit-check.sh ,把 lint 和 format 跑完再繼續。

Hooks 的類型

Claude Code 的 Hook 類型其實很多,下面列的是最常用、最容易上手的一批:

事件 觸發時機
PreToolUse Claude 執行工具之前
PostToolUse Claude 執行工具之後
SubagentStart Claude 啟動子代理時
SubagentStop Claude 結束子代理時
Stop Claude 完成回覆時
SessionStart 對話開始時
Notification Claude 需要你輸入時
FileChanged 被監看的檔案發生變化時

rules - 給 Claude 的行為準則

Rules 是你寫給 Claude 的「規定清單」,告訴它在這個專案裡應該怎麼寫程式、什麼事情不能做、要遵守哪些規範。

這裡要注意一個細節:不是所有 rules 都是無腦全讀。

沒有 paths frontmatter 的 rules,會在一開始就載入
有 paths frontmatter 的 rules,只有在 Claude 真的處理到符合的檔案時才載入

這也是 rules 很適合大型專案的原因,因為可以把上下文切得很精準,不會每次都把整包規範塞進來。

rules 怎麼使用?

我們只要在 .claude/rules/ 資料夾下,建立 .md 檔案: .claude/rules/api.md 來描述你個規範即可。

 ---
paths:
  - "src/api/**/*.ts"
  - "app/api/**/*.ts"
---

# API 開發規範

## 路由命名

- 使用 RESTful 風格:`GET /users`、`POST /users`、`DELETE /users/:id`
- 版本號放在 URL:`/api/v1/users`

## 回應格式

所有 API 必須回傳統一格式:

- 成功:`{ success: true, data: {...} }`
- 失敗:`{ success: false, error: "錯誤訊息" }`

## 安全性

- 所有輸入必須驗證
- 敏感操作需要身份驗證
- 錯誤訊息不可洩漏內部資訊
 

這種 paths frontmatter 的好處是, 只有當 Claude 真的碰到 API 相關檔案時,這份規範才會被載入 。

也就是說, 你可以把前端規範、後端規範、資料庫規範拆成不同檔案,各自只在需要時出現,整體上下文會乾淨很多 。

skills - 可重複使用的工作腳本

Skills 和 Commands 類似,都是讓你定義可呼叫的工作流程。

不同的是,Skills 像是工作手冊,Claude Code 會在做相關工作時,自動讀取相關內容或規範,如果做不相關工作,就不讀取,不佔用 token,這也是 Claude Code 官方推薦的現代寫法。

每個 Skill 是一個資料夾,裡面放著 SKILL.md 作為主要設定檔,還可以附上範本、範例等補充資料。

skills 怎麼使用?

在 .claude/skills/ 下建立一個資料夾,並在裡面新增 SKILL.md

裡面可以放上 description,讓 Claude Code 知道什麼時候要使用這個 skill,

比如說這個 .claude/skills/clarify-before-doing/SKILL.md :

 ---
name: clarify-before-doing
description: 在動手做複雜任務前,先釐清使用者意圖、目的與成功條件,再規劃步驟。
---

當任務牽涉到多步驟修改、重構、文件大幅改寫或功能設計時,請先不要直接開始做。

請依照以下流程進行:

1. 先確認使用者真正想達成什麼
2. 問清楚限制條件、輸出格式與成功標準
3. 整理成可執行的步驟
4. 告訴使用者接下來你會怎麼做
5. 確認沒有誤解後,再開始執行

等你確定理解 95% 使用者意圖,向使用者做雙重確認後,才能修改程式碼。
 

settings.json - 專案權限與行為設定

settings.json 是 Claude Code 的設定檔,用來控制 Claude 可以做什麼、不可以做什麼 ,以及各種自動化行為。

例如你可以限制 Claude 不能執行某些危險指令,也可以設定環境變數、調整 UI 主題等。

設定檔的位置
設定檔可以放在多個位置:

  1. ~/.claude/settings.json : 你個人的所有專案
  2. .claude/settings.json : 當前資料夾的專案(可提交到 git 共享)
  3. .claude/settings.local.json :當前資料夾的專案(本機私用,不提交)

範例設定

比如我們可以允許 Claude Code 去讀取和修改檔案,但是拒絕它刪除檔案,就可以這樣寫:

 {
  "permissions": {
    "allow": [
      "Read",
      "Edit",
      "Write",
      "Bash(git *)",
      "Bash(npm *)",
      "Bash(npx prettier *)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Bash(git push --force *)",
      "Bash(curl * | sh)",
      "Bash(DROP TABLE *)"
    ]
  }
}

前面提到的 Hook,也是一樣寫在這個 settings.json 裡,基本上 hooks/ 目錄放的是腳本本體,而 settings.json 裡是描述「什麼時候觸發哪一支腳本」。

例如前面提到的提交前檢查,就可以像這樣掛:

 {
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash(git commit *)",
        "hooks": [
          {
            "type": "command",
            "command": "\\"$CLAUDE_PROJECT_DIR\\"/.claude/hooks/before-commit-check.sh"
          }
        ]
      }
    ]
  }
}
 

這對於團隊協作特別重要,可以在 .claude/settings.json 設定好規範,提交到 git,讓整個團隊的 Claude 行為一致。

CLAUDE.md - Claude 的核心大腦

CLAUDE.md 是整個 .claude/ 資料夾中最重要的一個檔案。

每次對話開始,Claude 都會優先讀取這個檔案,把裡面的內容當作這個專案的「基礎知識」。

你可以在這裡寫下專案背景、常用指令、開發規範,讓 Claude 一開始就掌握所有 必要 的上下文。

如果你想偷懶的話,也可以直接使用 /init 指令,讓 Claude 自動幫你生成一個 CLAUDE.md 的初始版本。

另外,官方現在也很鼓勵把 CLAUDE.md 維持精簡,必要時用 @path/to/file 的方式匯入其他說明文件。這樣可以保留核心規則在主檔,細節再拆出去,不容易越寫越肥。

以下是一個範例:

 # 專案:My Web App

## 使用技術

- Frontend:Next.js 15 + TypeScript + Tailwind CSS
- Backend:Express.js + PostgreSQL
- 測試:Vitest + Playwright

## 常用指令

- 開發:`npm run dev`
- 測試:`npm test`
- 建置:`npm run build`
- 資料庫遷移:`npm run db:migrate`

## 目錄結構

- `src/app/` - Next.js 頁面
- `src/components/` - 可複用元件
- `src/lib/` - 工具函式
- `src/server/` - 後端 API

## 開發規範

- 檔名使用 kebab-case:`user-card.tsx`
- 元件名稱使用 PascalCase:`UserCard`
- 禁止使用 `any`,一律使用明確型別
- 所有 API 必須有 Zod schema 驗證
- 提交前執行 `npm test` 確保測試通過

## 注意事項

- 正式環境的 API key 放在 `.env.local`,不可提交到 git
- 資料庫操作一律透過 `src/lib/db.ts`,不可直接使用裸 SQL

CLAUDE.md 可以放哪裡?

CLAUDE.md 和 settings.json 一樣,可以分為全局和專案限定的:

  1. ~/.claude/CLAUDE.md : 你個人的所有專案
  2. ./CLAUDE.md : 這個專案(通常提交到 git)

和 rules/ 的差別

那 CLAUDE.md 和 rules/ 有什麼差別呢?

如果是小專案,單純用 CLAUDE.md 就非常夠,但是當專案越來越大,有越來越多相關規範,就可以考慮拆分出rules/來更好地維護。

簡單說的話就是: CLAUDE.md 適合放「整個專案都該知道」的事情,而 rules/ 適合放「特定檔案或特定領域才需要」的規則

總結

.claude/ 資料夾就是你的 Claude Code 設定中心 ,讓你可以客製化自己的工作方式、流程,不用每次都重新說明。

最後簡單整理一下:

  • agents/ : 定義專屬的 AI 子代理
  • commands/ : 建立自訂快捷指令
  • hooks/ : 設定自動化工作流程觸發器
  • rules/ : 細分主題的行為規範
  • skills/ : 可複用的進階工作腳本
  • settings.json : 權限控制與全域設定
  • CLAUDE.md : 專案說明與開發規範

本文授權轉載自This.Web請網這邊走

往下滑看下一篇文章
從獲客到理解需求,SHARP 攜手 Insider One 如何用第一方數據重寫家電行銷?
從獲客到理解需求,SHARP 攜手 Insider One 如何用第一方數據重寫家電行銷?

家電是典型的低頻、高單價商品,消費者可能數年才換一次冰箱、洗衣機或空氣清淨機,但品牌與消費者的接觸遠早於購買當下:從搜尋產品資訊、比較規格、閱讀評價,到進一步留下會員資料、瀏覽官網,甚至進入門市體驗,消費者的決策路徑越來越分散,即使最後的交易發生在線下,購買的決策可能早在線上決定。

這也是夏普(SHARP)會重新思考數位行銷的原因。

過去,品牌比較關注如何「帶來多少流量」,但當數位接觸點持續增加,重要議題逐漸變成:誰在關注什麼?誰可能進入購買週期?又該在什麼時間點,提供什麼內容?

SHARP 台灣總經理張凱傑表示:「我們的目標是串聯產品、 AI 、會員數據以及服務,讓 SHARP 從一個『賣家電的品牌』,逐步成為一個理解家庭生活需求的品牌。」

從空氣淨化、冰箱除菌保鮮、洗衣清潔、健康烹調、 AI 咖啡機到顯示技術, SHARP 致力將科技融入日常生活,預先設想、解決消費者不同階段的生活需求;如今,這套「半步先行」的思維也延伸到數位行銷:不只是等消費者說出需求,而是透過數據,更早辨識需求正在形成的訊號。

從散落的第一方數據到「看到完整消費者旅程」

SHARP 累積來自官網、會員、客服、維修與交易等大量第一方數據,但因數據資料分散在不同部門與系統,想要為行銷活動建立目標消費者輪廓,需要跨部門整理與人工處理。例如,需要先請 IT 撈取資料,再由行銷團隊分類目標客群,前後可能花上 3 到 5 天,活動發送出去後,也難以即時掌握消費者接下來的行為。

為解決上述挑戰, SHARP 開始評估、測試客戶資料平台(CDP),最終選擇與 Insider One 合作。評估過程中, SHARP 關注的不只是資料整合能力,也包括系統是否容易上手,以及線上、線下數據能否進一步串聯。

首先, SHARP 希望能縮短資料整合與行銷執行的距離。

Insider One 除可協助團隊進行第一方數據的整合、分群與分類,還有提供行銷引導與 AI 工具,例如行銷自動化等,讓團隊可以更精準地擬定媒體策略與決策,以清晰的投資報酬率(ROI)等數據,建立內部行銷與業務部門的信賴機制。

張凱傑指出:「對我們來說, CDP 的價值是縮短從資料、決策與行動的時間,讓行銷團隊可以把更多時間放在策略與內容,而不是處理資料。」舉例來說,導入 Insider One 後,行銷團隊用說的就可以完成受眾設定與行銷流程初步建置,將原本需要 3 到 5 天的時間縮短成 1 分鐘,然後,由系統觸及,以及追蹤開信、點擊與轉換,大幅縮短跨部門協作的工作流程。

Insider One
1912 年創立的夏普,在台灣積極數位轉型。SHARP 台灣總經理張凱傑攜手 Insider One ,透過數據整合,真正了解消費者的需求,精準推薦,股東購物節創造雙位數成長。右為 Insider One 吳一凡總經理。
圖/ 數位時代

對 SHARP 來說,另一個關鍵是降低團隊學習與使用數據的門檻。

為協助 SHARP 團隊快速上手與習慣使用, Insider One 團隊扮演如導師般的角色,透過手把手的培訓與指導,不僅大幅縮短系統摸索時間,更將原先至少要 3 個月以上的多元數據資料整合時間縮短在 1.5 個月內,成功趕上 SHARP 的年度最重要節慶活動–股東購物節。

第三個議題是捕捉線上互動跟線下交易之間的資料斷點,以消費者全通路(OMO)旅程數據持續深化互動關係。

張凱傑表示, SHARP 超過 80% 的銷售來自線下通路,部分合作通路同樣採用 Insider One,讓跨通路數據串接有了共通基礎,在 Insider One 團隊的協助下, SHARP 與生鮮超市合作,在符合資料授權跟隱私規範的前提下,透過會員輪廓標籤掌握跨通路消費需求,並以此規畫跨業聯合促銷(Joint Promotion)。

股東購物節四大指標皆雙位數成長, SHARP 如何從「廣撒行銷」走向「找對的人」

對 SHARP 來說,股東購物節是年度最重要活動,透過 Insider One 的站上模組、智能推薦、自動化顧客旅程與 A/B Test 等解決方案,結合會員資料整合與行為分析,去(2025)年, SHARP 行銷團隊可以從過去依年齡、性別等基本條件分群,轉變成掌握消費者對不同產品與內容的興趣,再搭配個人化推薦與自動化顧客旅程,讓對的內容在對的時機觸達對的人,極大化行銷綜效。

SHARP
「股東福利」官網提供一站式數位權益服務,包含股東卡領取、合作商家優惠查詢及精選好禮解鎖,輕鬆掌握各項專屬禮遇。
圖/ Insider

更重要的是,隨著數據累積與平台熟悉度提升, SHARP 的數位行銷成效持續優化。

以股東購物節為例,今(2026)年,不僅股東購物節的 eDM 開信率近 40%,流量、轉換率、客單價與回購率皆較去年成長15至25%,讓 SHARP 更加確信:數位行銷的重點不只是「吸引多少人」,而是能否辨識「哪些人值得溝通,以及現在應該說什麼」。

AI 智慧手沖咖啡機則是另一個案例。透過會員數據分析與問卷, SHARP 成功從會員名單中找出 4,000~5,000 名具有相關興趣與行為特徵的消費者,如喜愛手沖咖啡、熱愛科技、享受質感生活等客群,針對這群人進行精準溝通,帶動數百台產品銷售,創下轉換率超過 15% 的成績。

張凱傑認為,以 CDP 持續深化第一方數據資料有助於極大化行銷成效,以維修服務為例,如果系統辨識出消費者的冰箱使用年限已久,且近期有多次維修紀錄,即可在適當時機提供換機資訊,甚至從節能效益切入,讓這一次維修服務成為下一次產品需求的起點。

一次又一次的亮眼行銷成果,不僅讓 SHARP 從「廣撒行銷」轉向「找對的人」,持續深化對消費者的理解,讓線上的互動、內容與優惠,成為消費者消費或走進實體通路的前一站,也反映出家電行銷正從追求流量轉向對消費者需求的持續理解,成為家電數位行銷競爭的新典範。

想知道更多 Insider One 零售與家電產業應用,立即了解:https://insiderone.com/zh-hant/contact-us/

登入數位時代會員

開啟專屬自己的主題內容,

每日推播重點文章

閱讀會員專屬文章

請先登入數位時代會員

看更多獨享內容

請先登入數位時代會員

開啟收藏文章功能,

請先登入數位時代會員

開啟訂閱文章分類功能,

請先登入數位時代會員

我還不是會員, 註冊去!
追蹤我們
一次搞懂工業AI
© 2026 Business Next Media Corp. All Rights Reserved. 本網站內容未經允許,不得轉載。
106 台北市大安區光復南路102號9樓