CLAUDE.md 的內容會在 system prompt 之後以 user message 傳送，而不是 system prompt 的一部分。Claude 會閱讀並試著遵守，但無法保證會嚴格遵從。
— Anthropic，code.claude.com/docs/en/memory
換句話說，嚴格來說，CLAUDE.md 並不是「system prompt」，而是 Claude 看到的第一則 user message。因此，裡面的規則只是強烈建議，而非法律。若規則需要強制執行，應為涵蓋的事件使用經測試的 hook，更廣泛的存取邊界則靠權限或環境隔離。hook 自動執行不代表檢查已涵蓋所有情況。下文會說明 `hooks` 和 `CLAUDE.md` 的界線。
## 如何在 5 分鐘內撰寫精簡版 CLAUDE.md（可直接使用的範本）？
重要重點
複製範本、替換方括號中的欄位，然後以 `CLAUDE.md` 為檔名存到專案根目錄。這樣就足以避免 Claude 每次工作階段都從頭開始。你可以依照「代理程式每犯一次錯，就新增一行」的規則逐步擴充。
以下是我在數十個專案中測試過的範本。它會讓檔案維持在約 80-120 行，符合 Anthropic 建議以少於 200 行為目標的做法。使用這個範本時，代理程式能給出最合理的結果。
```markdown
# [PROJECT NAME] - project navigation
This document is the project map. Read it at the start of every session
to understand where things are and how to work with them.
## What this project is
**[NAME]** - [one sentence: what it is and who it’s for].
[1-2 sentences: what problem it solves and how].
Details are in `business/INDEX.md`.
## Reading order at the start of every session
1. `about-me/INDEX.md` - who I am and how I think
2. `business/INDEX.md` - what we do (product, audience, economics)
3. `CLAUDE.md` (this file) - repo rules, tools, navigation
4. Task area: the relevant file from `business/`, `plans/`,
`mastery/` or the feature folder in the code
Principle: layer 1 (about me) comes before layer 2 (business) for a reason.
First, **who** is thinking, then **about what**.
## Repository structure
[NAME]/
├── CLAUDE.md ← this file, navigation
├── about-me/ ← digital projection of you (how you think, what you value)
│ └── INDEX.md
├── business/ ← the business’s second brain
│ ├── INDEX.md
│ ├── audience/ ← customer profile
│ ├── products/ ← products, prices
│ ├── goals/ ← goals, metrics
│ └── economics/ ← unit economics, revenue
├── plans/ ← technical plans (one plan = one feature)
├── retrospectives/ ← reflections after each session
└── (project code)
### Where to find things
| What you need | Where to look |
|---|---|
| Why we’re building the project, and for whom | `business/INDEX.md` |
| Target customer, pains, desires | `business/audience/` |
| Product, plans, prices | `business/products/` |
| Goals and metrics | `business/goals/` |
| Economics | `business/economics/` |
| Technical plans | `plans/` |
## Tools
[INSERT TOOLS - for example: Next.js 14, TypeScript, Tailwind CSS, Prisma + PostgreSQL].
## Repo rules
1. Never hardcode dynamic data (prices, dates, figures) -
get everything from files in `business/` and the LIVE marker.
2. Don’t publish without my explicit command.
3. Before `git push`, run `npm run build` and check that it
builds without errors or warnings.
4. Add files by name with `git add`. Never use `git add .` or `git add -A`.
5. Don’t read `.env` in full. To check a variable, use
`grep "^VAR=" .env`.
## Big features = a plan in `plans/`
Any task lasting more than an hour must be written up as a plan in the `plans/` folder:
1. Filename: `YYYY-MM-DD-feature-name.md`.
2. Divide the plan into phases. Mark each phase `[ ]` or `[x]`.
3. At the end of the plan, add a summary: whether it was fully implemented and what remains.
## End-of-feature cycle
After each feature is complete, go through these 5 steps:
1. Find errors → prove them with an example → fix them.
2. What was missed (edge cases, input validation, error handling).
3. Is this a real problem in our project? Check `business/` and `plans/`.
4. Take a fresh look: reread the diff as if you’re seeing it for the first time.
5. Security review. Especially: personal data and third-party materials.
## End-of-session reflection
In `retrospectives/YYYY-MM-DD_short-name.md`, record:
1. What the task was.
2. How it was solved.
3. Whether it was solved - yes / no / partially.
4. What could have been done better.
5. What was learned about the user or project.
## Language
Always respond in the user’s preferred language. Use hyphens only, not em dashes.
```
若要讓 Claude 自動為你的專案填寫這份範本，請把以下提示詞交給它。它會讀取上下文並填入方括號中的欄位：
提示詞：替我的專案填寫 CLAUDE.md
```
Create a CLAUDE.md file at the project root using this template:
[INSERT THE ENTIRE TEMPLATE FROM ABOVE]
Proceed as follows:
Read about-me/INDEX.md and business/INDEX.md to understand the project context and me as the author.
Fill in all the square-bracketed fields in the template based on what you find in those folders.
If some information is missing, ask me clarifying questions one at a time, with 3-4 answer options.
以少於 200 行為目標。若更長，請檢查重複內容並將詳細流程移至連結文件；保留必要的規劃、回顧與儲存庫規則，再用代表性任務測試。
Show me the final file and ask what should be revised.
Always respond in the user’s preferred language.
```
提示詞：對 CLAUDE.md 進行壓力測試
```
I have a CLAUDE.md. Tomorrow I’ll be building a feature based on it.
Your task is to stress-test it. Find 10 reasons we could potentially fail:
where CLAUDE.md is ambiguous and you, as an agent, might misunderstand it
where there are gaps that would force you to make things up
where rules contradict one another
where I overestimate how much can be done in one day
where I underestimate things (this is even worse)
Don’t hold back. Criticize it harshly. I want to find these issues now, not in production.
At the end, give me a list of specific changes: what to change and how, so these problems don’t happen.
```
我的 CLAUDE.md 有一個簡短的章節：
```markdown
## Self-learning
At the end of every session, check:
- Have I learned anything new about the user or how to work with them?
- Did I break any rule that should now be recorded?
If so, create or update a file in `about-me/feedback/` in this format:
Rule (one-line rule) → Why (why it was added)
→ How to apply (when it applies).
I don’t write the rules by hand - I say, “not like that, because this is how,”
and you put it into a file.
```
把這個章節加入 CLAUDE.md 後，Claude 開始在每個工作階段結束時問：「有沒有值得記錄的新內容？」如果有，它就會提出一條規則草稿；我補充說明後，再建立檔案。
用這種方式合作兩個月後，我在 `about-me/feedback/` 裡累積了二十多個檔案，都是從特定錯誤中學到的規則。每個檔案都是以「規則 → 原因 → 如何套用」格式撰寫的一頁內容。這個資料夾成了記錄我個人偏好與禁忌的「第二記憶」。
每個錯誤都會成為規則，因此不會重複犯錯；規則也會累積並彼此強化。六個月後，Claude 對我專案的了解，會比我休息一個月後回來時記得的還多。
## 如何在 CLAUDE.md 中加入法律、行銷和營運規則？
提示詞：依照檢查清單稽核 CLAUDE.md
```
Read my CLAUDE.md and compare it with the checklist below. For each item, say: yes / no / partly, and what specifically to fix.
Checklist:
保持精簡以適合任務；接近 200 行時審查，不把它視為硬性上限
Project description in the first 5 lines
Tools listed explicitly
Repository structure diagram included
“Question → file” table included
Principles section with rules included
Every rule is specific and verifiable
“Update at the end of the session” rule included
“Reflect at the end of the session” rule included
Critical prohibitions included in .claude/settings.json
No duplicates of the same rule in different sections
No dangling links to files that no longer exist
After the audit, give me a list of specific changes that will make the file living.
```
## CLAUDE.md 之後該使用 Plan Mode、Skills，還是 sub-agents？
重要重點
CLAUDE.md 是基礎。它運作良好後，就能使用下一層機制：Plan Mode（先讓 Claude 規劃，再採取行動）、Skills（把不常用的知識從 CLAUDE.md 移到獨立檔案），以及 sub-agents（在各自獨立的上下文中處理任務）。