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 本身就內建一些子代理 ,像是 ExplorePlangeneral-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請網這邊走

關鍵字: #AI工具
往下滑看下一篇文章
不只是共享辦公室,更是企業孵化器!韻驊如何運用空間與資源,加速企業成長?
不只是共享辦公室,更是企業孵化器!韻驊如何運用空間與資源,加速企業成長?
2026.03.26 |

走進去的那一刻,就知道這裡不一樣

走進位於信義區核心地段的 T3CO 韻驊共享辦公室,首先映入眼簾的,是一座靜謐的生態魚缸。光影在空間中靜靜變化,讓人不自覺放慢步調,也讓原本緊湊的城市節奏,在這裡稍微緩了下來。再往內走,另一側設置了一座開放式生態魚缸,與辦公區自然銜接,成為場域中一處刻意保留的緩衝節點。人在這裡,可以短暫停下來,讓視線與思緒稍作停留,再回到工作的節奏之中。

在一個連每一坪都被精算為收益的產業裡,這樣的安排或許不以最大化營收為優先,卻也正是韻驊最關鍵的選擇——不是讓空間被填滿,而是讓人找到屬於自己的工作節奏。

「我不是在做辦公室生意。」
「我希望這裡是一個你可以待一整天都很舒服的地方。」
台驊控股集團創辦人顏益財說。

長年深耕國際物流、見證無數企業在全球市場競逐的他,很清楚一件事:企業的競爭,不只在市場端,很多時候,其實早就從每天工作的環境開始了。
在他看來,一家企業的運作節奏,往往從日常工作的場域開始被形塑——團隊是否能專注、是否容易協作,甚至能否長時間維持穩定狀態,都與所處的環境密切相關。

也因此,韻驊從一開始就沒有把自己侷限於共享辦公室,而是試圖打造一個能讓企業在日常運作中持續累積競爭力的工作平台。它不只是空間,而是一個被設計過的環境——讓人能專注、讓團隊能協作,也讓企業在看不見的地方,逐步拉開差距。

從固定成本到成長動力:共享辦公室如何構築企業「隱形競爭力」?

隨著遠距與混合辦公逐漸成為新常態,企業對辦公室的定義已悄然改變——它不只是工作場所,更逐漸成為影響企業競爭力的重要一環。

顏益財認為,一個舒適且具設計感的工作環境,有助於形塑專業且穩定的企業形象,不僅能提升客戶與合作夥伴的信賴感、加速合作促成,也能強化企業在人才市場中的吸引力與留任力。同時,良好的空間規劃亦能降低干擾、促進協作,讓團隊更容易進入專注狀態,進一步提升整體工作效能。

然而,若企業從零開始打造這樣的環境,往往需投入大量資金與時間成本。從空間取得、設計裝修,到網路建置與日常管理,對多數企業而言,都是一筆沉重負擔。共享辦公室原本應該解決這些問題——但多數業者仍停留在「提供空間」,而非真正「支援企業成長」。

韻驊T3CO(1) 20260324.jpg
台驊控股集團創辦人顏益財
圖/ T3CO共享辦公室

不只是工作場域,而是推動企業成長的商務平台

看準這樣的轉變,台驊控股集團成立 T3CO 韻驊共享辦公室,從空間出發,進一步延伸為企業成長的平台。顏益財觀察,目前市場主要存在兩大缺口:一是空間設計過度追求坪效,導致環境壓迫;二是服務停留在場地租賃,缺乏對企業實際商務需求的整合與支援。

因此,韻驊重新定義共享辦公室的角色——不只是提供空間,而是支撐企業長期發展的營運平台。

「T3CO韻驊」這個名稱,本身就承載著這樣的定位。顏益財進一步說明,「T3CO」延續了台驊集團長期以來的核心精神,也就是 Trust、Total Solution 和 Technology;「韻」象徵旋律與生活美學,「驊」代表前進與創新的力量。三者結合,其實就是把物流產業中強調效率與整合的服務能力,延伸到企業的日常工作場域中,打造一個兼具效率、品質與舒適度的工作環境,協助企業在高壓競爭的商業環境中,依然能穩定前行。

核心訴求一:以使用體驗為前提,打造高質感空間

在空間規劃上,韻驊特別重視採光、視野與動線設計,維持整體環境的明亮與通透,降低長時間工作的壓迫感。

場域內設置兩座生態魚缸,一座位於入口,另一座為開放式設計,融入辦公區域之中,透過水族造景讓使用者在工作之餘能適時放鬆視線與節奏。

此外,空間亦規劃接待區、多功能會議室、電話亭、淋浴間、哺乳室與開放式水吧廚房等多元機能空間,滿足不同工作情境需求。在硬體設備上,全區配置人體工學椅、電動升降桌與個人收納邊櫃,並建置高速穩定的網路環境,確保長時間工作的舒適性與效率。
同時,韻驊也提供商業登記、信件收發與訪客接待等基礎商務服務,讓企業在進駐初期即可快速啟動營運。

韻驊T3CO(2) 20260324.jpg
透過通透採光與開闊動線細膩揉合生態魚缸的減壓設計,韻驊在多元機能空間中注入人文關懷,為工作者打造一處能平衡身心、觸發高效專注的純粹辦公境地。
圖/ T3CO共享辦公室

核心訴求二:導入集團資源,打造企業孵化型平台

在高質感空間之上,韻驊進一步導入台驊控股集團的全球資源。
顏益財指出,台驊控股集團深耕倉儲物流領域多年,旗下涵蓋台驊國際物流、台空國際物流、聯宇達方物流、耀驊國際物流、賽澳遞物流與中產保理等子公司,提供橫跨陸、海、空的整合物流服務,協助企業從內銷配送到跨境出口,逐步串接全球市場。
不僅如此,集團至今已累積超過五萬家客戶,橫跨不同產業別。這些長期沉澱的商業連結,也讓韻驊具備更進一步的角色——在企業不同成長階段,提供相應的資源對接與合作機會。

「企業在不同階段所需要的資源不同,我們希望這個平台能讓它們更容易被連結起來,」顏益財說。透過這樣的整合,韻驊讓共享辦公室從單純的空間服務,升級為企業營運的支援平台。

一個正在形成的企業生態系

除了商務資源,韻驊亦整合集團資訊技術能力,提供穩定的 IT 基礎建設與網路管理支援,讓企業能在安全且高效的數位環境中運作。
當不同產業的團隊在同一個場域中互動,交流與合作也會自然發生。
這讓韻驊逐漸從一個空間,發展為一個具備連結能力的系統——一個正在形成的企業生態系。

韻驊T3CO(3) 20260324.jpg
韻驊結合台驊集團全球物流資源與五萬家產業客戶鏈結,打造具備「企業孵化」功能的商務平台,助進駐企業精準媒合資源並快速接軌國際市場
圖/ T3CO共享辦公室

從台北出發,連結更大的市場

隨著營運模式逐步成熟,韻驊也計畫將這套模式複製至海外市場。
對顏益財而言,這不只是據點的擴張,而是平台能力的延伸。
他的想像很直接:讓企業從進入這個空間的那一刻起,就更接近國際市場。

這不只是辦公室,而是一個起點

當辦公空間從成本轉變為能力,它所承載的意義也隨之改變。
韻驊所打造的,不只是工作場域,而是一個能陪伴企業從起步、成長,到邁向國際的長期夥伴。
在這裡,空間不只是讓你工作——
而是讓你,有機會走得更遠一點。

登入數位時代會員

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

每日推播重點文章

閱讀會員專屬文章

請先登入數位時代會員

看更多獨享內容

請先登入數位時代會員

開啟收藏文章功能,

請先登入數位時代會員

開啟訂閱文章分類功能,

請先登入數位時代會員

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