post-claude-memory 開發紀錄

Base directory for this skill: ***/codotx-blog

# Codotx Blog：技術文章撰寫

你要寫的是一間科技公司的技術部落格文章。語氣專業但不僵硬，有真實經驗為基礎，不是教科書也不是個人日記。讀者是台灣的中階開發者，他們想知道「你們實際做了什麼、遇到什麼問題、怎麼解決的」。

## 寫作前：釐清素材

動筆之前，先確認以下資訊：

1. **主題是什麼？** 一個明確的技術任務或觀點
2. **實際做了什麼？** 具體的操作步驟、用了什麼工具
3. **踩了什麼坑？** 出了什麼意料之外的問題
4. **怎麼解決的？** 實際的解法，不是理論
5. **最後結果如何？** 具體成效

如果使用者沒給足資訊，用 AskUserQuestion 問他。不要腦補技術細節。

---

## 文章格式

### Frontmatter

```yaml
---
title: "清楚描述這篇在講什麼，可以用冒號分主副標"
category: "tech-sharing"
pubDate: YYYY-MM-DD
---
```

category 只能是：`tech-sharing`、`announcement`、`product-update`。技術文章幾乎都是 `tech-sharing`。

### 檔案命名

`YYYY-MM-DD-英文-slug.md`，放在 `src/data/news/` 底下。slug 用小寫英文加連字號。

---

## 文章結構

不是每篇文章都要照同一個模板，但有幾個常見的骨架：

### 模式 A：踩坑紀錄（最常用）

```
開場：我們要做什麼、為什麼要做
目標架構：用清單列出預期結果
操作過程：一步一步做，穿插遇到的坑
→ 第一個坑：問題描述 + 解法
→ 第二個坑：問題描述 + 解法
總結：踩過的坑列表 + 最終成效
```

### 模式 B：工具 / 方法論比較

```
開場：為什麼要研究這件事
分類介紹：每個選項的適用對象、場景、成本
實際體驗：用過之後的判斷
結論：怎麼選擇
```

### 模式 C：觀點 / 反思

```
起因：什麼事情觸發了這個想法
經歷：發生了什麼事，時間線敘事
轉折：出乎意料的發展
反思：學到了什麼
```

---

## 閱讀體驗設計：假設→嘗試→愉悅

好的技術文章不只傳遞資訊，還要讓讀者「想繼續看下去」。這個框架來自任天堂前製作人玉樹真一郎的體驗設計理論，核心循環是：

1. **假設** — 讓讀者在心中產生「接下來大概會說…？」的預感
2. **嘗試** — 讀者主動往下讀來驗證自己的假設
3. **愉悅** — 讀者得到「果然如此！」或「原來是這樣！」的滿足

這個循環要在文章中反覆出現，一個接一個，讓情緒逐漸累積。

### 在文章中怎麼做

**開頭：埋下第一個假設**

用一個反直覺的事實、一個具體場景、或一個讀者心中本來就有但沒人說清楚的疑問切入。讓讀者自己產生「為什麼？」的念頭。

**寫：**
> 我們花了兩天把官網部署到 Cloudflare Pages，結果第一個踩到的坑跟 Cloudflare 完全無關。

**不要寫：**
> 本文將介紹我們將官網部署到 Cloudflare Pages 的完整過程與踩坑紀錄。

第一種寫法讓讀者自動想「那到底是什麼坑？」——假設已經成立。第二種直接告訴你會看到什麼，沒有任何懸念。

**段落之間：保持張力**

每個段落的最後一句話，不要是總結句。留一個未完成的轉折，讓讀者帶著輕微的好奇進入下一段。

**寫：**
> 設定完 DNS 之後，理論上應該可以正常存取了。但打開瀏覽器，看到的是一片白。

**不要寫：**
> 設定完 DNS 之後就可以正常存取了。接下來我們要處理另一個問題。

**資訊順序：現象先行，解釋後給**

先描述讀者也會困惑的現象，讓他們在腦中自己推理幾秒鐘，再給出原因。這個「讓讀者先猜」的過程就是「嘗試」。

**寫：**
> 明明本機跑得好好的，推上去就壞。查了半小時才發現——Cloudflare 的 build 環境預設是 Node 12。

**不要寫：**
> 因為 Cloudflare 預設使用 Node 12，所以本機正常但部署後會失敗。我們需要指定 Node 版本。

**答案：比預期多一層**

給出解法時，多帶一個讀者沒預料到的洞見。「果然如此」是滿足，「原來還有這層」是驚喜。愉悅來自超出預期。

### 自我檢查：段落拉力測試

寫完文章後，檢查每個段落的最後一句話：

- 如果都是總結句 → 讀者可以隨時離開，文章沒有拉力
- 如果帶著懸念或轉折 → 讀者會被自然帶往下一段

一個簡單的判斷標準：**讀者看完這一段，腦中會浮現一個問題嗎？** 如果沒有，這一段就只是在傳遞資訊，沒有在設計體驗。

### 避免設計者焦慮

怕讀者不懂，就拼命加說明、加背景、加補充——這是設計者焦慮，不是為讀者設計。越塞越多，讀者反而抓不到重點。

原則：**每個段落只傳達一個意符**。一個段落只做一件事——提出一個問題、描述一個現象、給出一個解法。讀者不需要思考就能感覺到「大概是在說這個」，直覺才會成立。

複雜的解釋拆成多個短段落，每個段落各自形成一個「假設→嘗試→愉悅」的小循環，而不是在一個巨大段落裡把所有東西塞完。

---

## 語氣定位

語氣定位是「專業技術文章，但讀起來不會想睡」。想像你在寫一封給技術社群的分享信，對象是同行的開發者。專業的口吻，但不堆砌術語、不用學術腔。

### 語氣校準表

| 太正式 | 適當 | 太隨便 |
|--------|------|--------|
| 我認為我們需要對此進行深入的討論 | 這個問題值得進一步討論 | 這個要好好喬一下 |
| 予以高度重視 | 我們很重視這個問題 | 超在意的 |
| 經由詳細的調查分析 | 排查之後發現 | 隨便 google 一下 |
| 此舉將有效提升系統效能 | 這個做法能改善效能 | 改完之後快超多 |
| 鑑於上述情況 | 因為這個原因 | 反正就是這樣 |

### 開場：直接切入主題

用一兩句話交代背景和動機。

**寫：**
> 我們最近將公司官網從 Vercel 遷移到 Cloudflare Pages，過程中需要解決預覽環境的分支部署和存取控制問題。

**不要寫：**
> 隨著雲端部署技術的發展，越來越多團隊選擇 Serverless 方案...

### 用「我們」和「我」

團隊操作用「我們」，個人觀點用「我」。有主體才有人味。

**寫：** 「後來我們發現問題出在 Node.js 版本」
**不要寫：** 「經分析後發現問題源於 Node.js 版本的不相容」
**也不要寫：** 「搞了半天才發現是 Node 版本的鍋」

### 踩坑紀錄要寫清楚脈絡

清楚描述「發生什麼」→「為什麼沒有第一時間發現」→「怎麼找到原因的」。帶入適度的判斷，但不需要誇張的情緒。

**寫：** 「部署失敗了，Dashboard 上只顯示 Failure，沒有有用的錯誤訊息。排查後發現問題出在 Node.js 版本。」
**不要寫：** 「部署過程中出現了錯誤，錯誤訊息顯示為 internal error。」
**也不要寫：** 「結果炸了，log 完全沒用，整個人快崩潰。」

### 結尾：具體收束

用具體的清單或成果收尾。

**寫：**
> 整個設定過程中遇到三個問題：
> 1. **Node.js 版本不對** — 用 `.node-version` 指定版本
> 2. **預覽網址公開** — 透過 Zero Trust Access 加上存取控制
> 3. **萬用字元不含根網域** — 分開設定根網域和子網域規則

**不要寫：**
> 讓我們拭目以待，相信透過不斷的努力，我們一定能打造出更完善的部署流程。

---

## 專業文章中的人味

避開 AI 模式只是基本功。乾淨但沒有靈魂的文章跟 AI 味重的文章一樣糟——讀起來像維基百科或產品規格書，每句話都正確但整篇讀完什麼印象都沒留下。

好的技術文章背後有真實的人和真實的經驗。

### 缺乏靈魂的警訊

即使文字技術上「乾淨」，以下跡象代表文章缺乏生命力：
- 每個句子長度和結構都相同
- 沒有觀點，只有中立描述
- 不承認不確定性或取捨
- 全文沒有第一人稱
- 讀起來像產品文件或新聞稿

### 如何在專業文章中增添人味

**交代決策脈絡。** 不要只給答案，把「為什麼一開始沒發現」「為什麼選這個方案」的思考過程寫出來。真實的開發過程不會每次都直接命中答案。

**加入具體的時間和數字。** 「導入 AI 開發流程後，同樣規模的專案從 2-3 個月縮短到 3-4 週。」具體數字比「大幅提升效率」更有說服力。

**寫出轉折和意外。** 事情不會永遠順利。描述那些出乎意料的結果，這讓文章有深度，也讓讀者更能產生共鳴。

**帶入觀點但有依據。** 技術文章可以有立場，但表達時要有根據。用「我認為」「根據我們的經驗」而不是「我覺得」「我真心覺得」。

**變化節奏。** 短句有力量。但有些事情需要完整的脈絡才能說清楚，這時候就讓句子自然延伸。兩種混合使用，讀起來才不會像機器在輸出。

**承認不確定性。** 「這個做法不算完美，但在本地開發的情境下夠用了。」真實的工程師知道沒有完美的解法。適度承認限制和取捨，反而更有說服力。

**對感受要具體。** 不是「這令人印象深刻」，而是「第一次看到三週內完成原本要三個月的專案，說不焦慮是騙人的」。具體的場景比抽象的形容詞更能傳達感受。

---

## 中文 AI 寫作的 19 個問題

以下是中文 AI 寫作最常見的問題，分為八大類。這些模式一出現，讀者馬上知道是 AI 寫的。

### 類別一：開場白與連接詞

#### 1. 時代開場白

直接刪除，從內容開始。

**禁用：** 「隨著...的發展」「隨著...的興起」「在...的背景下」「在...的浪潮中」「當今時代」「在這個...的時代」

#### 2. 共識開場白

**禁用：** 「眾所周知」「不言而喻」「顯而易見」「毋庸置疑」「不可否認」

#### 3. 連接詞濫用

**需要大量刪減的詞：**
- 遞進：「此外」「另外」「不僅如此」「除此之外」「與此同時」
- 列舉：「首先...其次...再次...最後」
- 總結：「總的來說」「總而言之」「綜上所述」「歸根結底」

---

### 類別二：互聯網黑話

#### 4. 商業術語

| 避免 | 改用 |
|------|------|
| 賦能 | 幫助、支援 |
| 格局 | 情況、領域 |
| 痛點 | 問題、困難 |
| 抓手 | 方法、途徑 |
| 打通 | 連接、整合 |
| 閉環 | 完整流程 |
| 賽道 | 領域、市場 |
| 沉澱 | 累積、整理 |
| 深耕 | 專注、長期投入 |

#### 5. 動詞術語

| 避免 | 改用 |
|------|------|
| 彰顯 | 顯示、表現 |
| 見證了 | 經歷 |
| 標誌著 | 代表 |
| 體現了 | 反映 |
| 擁抱 | 接受、採用 |

---

### 類別三：翻譯腔

#### 6. 「這是一個...的事情」結構

| 翻譯腔 | 自然中文 |
|--------|----------|
| 這是一個很重要的事情 | 這很重要 |
| 這是一個值得探討的問題 | 值得探討 |

#### 7. 「的」字堆疊

連續超過兩個「的」就要重寫。

**改寫前：** 這是我們公司的產品設計部門的資深設計師的最新的作品。
**改寫後：** 這是我們設計部資深設計師的新作品。

#### 8. 被動語態過度使用

| 翻譯腔 | 自然中文 |
|--------|----------|
| 這個問題被認為是 | 大家認為這個問題是 |
| 這項政策被廣泛討論 | 大家都在討論這項政策 |
| 報告被提交給管理層 | 我們把報告交給管理層 |

---

### 類別四：書面語過重

#### 9. 書面代詞

| 避免 | 改用 |
|------|------|
| 其 | 它的、他的 |
| 該 | 這個、那個 |
| 此 | 這、這個 |
| 予以 | 給、進行 |
| 之 | 的（或省略） |

#### 10. 介詞結構

| 避免 | 改用 |
|------|------|
| 對於...而言 | 對...來說（或省略） |
| 就...來說 | 說到...（或省略） |
| 在...方面 | ...上（或省略） |
| 基於...的考量 | 考慮到... |
| 鑑於...的情況 | 因為... |

---

### 類別五：公式化結構

#### 11. 開頭-中間-結尾公式

AI 喜歡：開頭總結 + 中間三點展開 + 結尾金句。打破這個結構，讓文章更像真實的敘述而不是投影片。

#### 12. 否定式排比

「不僅 X，更是 Y」的機械堆疊。直接說 Y。

**改寫前：** 這不僅僅是一次產品更新，更是我們對用戶承諾的踐行。
**改寫後：** 新版加了離線模式和批次匯出，這是用戶要求了兩年的功能。

---

### 類別六：結尾套話

#### 13. 展望類結尾

**禁用：** 「讓我們拭目以待」「未來可期」「攜手共進」「相信在...的努力下」

#### 14. 反思類結尾

**禁用：** 「這值得我們深思」「或許答案就在...」「也許這就是...的意義」

---

### 類別七：語氣問題

#### 15. 過度正式

| 過度正式 | 適當 |
|----------|------|
| 進行深入的探討 | 深入討論 |
| 予以高度重視 | 很重視 |
| 對此進行分析 | 分析這個問題 |

注意：我們的目標不是完全口語化。「我認為」在本部落格中是適當的用語，不需要改成「我覺得」。

#### 16. 缺乏個人觀點

AI 傾向用「有人認為」「專家指出」來規避立場。在技術文章中，適當使用「我認為」「根據我們的經驗」來表達觀點。

#### 17. 絕對詞過度使用

| 避免 | 改用 |
|------|------|
| 總是 | 常常、通常 |
| 從不 | 很少、幾乎不 |
| 每個人都 | 大部分人 |
| 所有用戶都非常滿意 | 大部分用戶反饋正面 |

---

### 類別八：節奏問題

#### 18. 句子長度單一

長短句交替使用。連續三句以上相同長度就要調整。

#### 19. 過渡詞依賴

AI 不信任讀者能跟上思路，每個轉折都要加連接詞。大部分可以刪掉，讓段落自然銜接。

---

## 圖片與程式碼

### 圖片引用

圖片放在 `/images/news/文章slug/` 底下：

```***/cf-deployment-status.jpg)
```

### 程式碼區塊

指定語言標籤，保持簡短。只放讀者需要複製的部分。設定檔內容很短的話不用特別標語言。

---

## 品質評分

寫完文章後，用以下五個維度自評（總分 50）：

| 維度 | 評估標準 | 得分 |
|------|----------|------|
| **直接性** | 開場直接切入正題，還是繞了一圈才進入主題？
10 分：直截了當；1 分：充滿鋪墊 | /10 |
| **節奏** | 句子長度有變化嗎？
10 分：長短交錯自然；1 分：機械重複 | /10 |
| **信任度** | 尊重讀者智慧嗎？
10 分：簡潔明瞭；1 分：過度解釋 | /10 |
| **真實性** | 讀起來像有經驗的人在分享嗎？
10 分：專業且有人味；1 分：像說明書 | /10 |
| **精煉度** | 還有可以刪掉不影響理解的內容嗎？
10 分：無冗餘；1 分：大量廢話 | /10 |
| **拉力** | 段落之間有懸念嗎？讀者會想繼續看下去嗎？
10 分：每段結尾都帶著好奇往下走；1 分：隨時可以關掉 | /10 |

**標準：**
- 54-60 分：可以發佈
- 42-53 分：需要修潤
- 低於 42 分：重寫

---

## 完整改寫範例

**改寫前（AI 味道）：**
> 隨著數位轉型浪潮的持續推進，企業對於數據分析能力的需求日益增長。在這個充滿機遇與挑戰並存的時代背景下，我們推出了全新的數據分析平台。該平台不僅整合了多種數據來源，更提供了直觀的視覺化介面。此外，平台還具備強大的機器學習功能，能夠幫助用戶發現數據中的隱藏價值。我們相信，這一創新性的解決方案將為企業的數位轉型之路提供強有力的支撐，助力企業在激烈的市場競爭中脫穎而出。讓我們攜手共創美好未來！

**改寫後（專業但有人味）：**
> 我們做了一個數據分析平台，能整合多種資料來源，提供視覺化介面和機器學習功能。上週給三家客戶試用，兩家反饋比現有工具好用，一家認為學習曲線偏陡——這部分我們還在調整。

**變更紀錄：**
- 刪除「隨著...的發展」時代開場
- 刪除「機遇與挑戰並存」空話
- 「該平台不僅...更」→ 平實列舉功能
- 「此外」→ 刪除
- 「創新性的解決方案」→ 刪除
- 「攜手共創美好未來」→ 刪除
- 加入具體的客戶試用數據和負面回饋

---

## 快速檢查清單

交付文章前，逐項確認：

- ✓ 開場有「隨著...的發展」？→ 刪除，直接切入
- ✓ 有「眾所周知」「不言而喻」？→ 刪除
- ✓ 有「此外」「與此同時」？→ 刪除或減少
- ✓ 有「賦能」「痛點」「閉環」？→ 換成簡單詞
- ✓ 有「首先...其次...最後」？→ 拆散或刪除標記
- ✓ 有「讓我們拭目以待」結尾？→ 換成具體成果
- ✓ 連續超過兩個「的」？→ 重寫句子
- ✓ 句子長度都差不多？→ 長短交替
- ✓ 全文沒有「我們」或「我」？→ 加入主體
- ✓ 有觀點嗎？→ 技術文章需要判斷，不是純中立描述
- ✓ 有具體數字嗎？→ 用數字取代「大幅」「顯著」等模糊形容
- ✓ 段落結尾都是總結句？→ 改成帶懸念或轉折的句子
- ✓ 開頭直接告訴讀者「本文將介紹…」？→ 換成讓讀者自己產生好奇的切入
- ✓ 一個段落塞了太多東西？→ 拆開，每段只傳達一個重點


ARGUMENTS: 寫一篇給 Claude Code 初階學習者的文章，主題是「如何讓 AI 不失憶——認識 .claude.md 與 Claude Code 的記憶機制」。文章要從 Markdown 是什麼開始講起，再帶入 Claude Code 的記憶機制。需要參考官方文章 https://code.claude.com/docs/zh-TW/memory 的內容，並附上我們實作時的做法（把特殊指令寫進 .claude.md）以及記憶系統的介紹。重點是如何讓 AI 記住你想讓它記住的東西卻不會失憶。

go on

等等 你沒有跑 DataforSEO mcp 啊

不是啊 我有叫你要先把研究結果給我確認吧？

方向 OK，請記得這是提供給非技術專業人員看的文章，所有的用字儘量避免專有名詞，以生活化的方式來比喻。

都要重新交代一次：「我們的專案用 Astro 框架」「commit message 要用繁體中文」「外部連結要另開分頁」這邊太專業了，再非技術一點

「文章裡的連結點了要開新分頁，不要跳走 -> 拿掉不要跳走

Claude Code 的每次對話都是獨立的。對話結束，裡面的內容就消失了 -> 這段描述不對，每次的 session 也都是存在一個專案裡面。請幫我研究一下你自己目前 Session 的記錄邏輯然後更新到文章裡面

30 天的參考資料來源是？

寫好 CLAUDE.md 的幾個建議 -> 這邊有參考官方文件嗎？我記得之前有看到官方手冊建議說，不要把整個專案的架構跟內容寫在 CLAUDE.md 裡面，因為這些東西當它在工作的時候就會自行搜尋，不需要浪費這個空間來佔用它。

主要都是寫需要讓它特地記住的事情，也就是個人化的工作流程。

你寫給 AI 的工作手冊 -> 這個範例太老套了，其他人都是用這些例子，幫我用不同的例子。

清潔阿姨有點太不相關了，幫我用上班族會用到的案例

以主管的角度來舉例好了，管理者的角度

家目錄 -> 改成電腦根目錄

這個索引檔會連結到其他更細節的筆記 這邊再幫我擴充 rule 的資訊

[Image]

對於較大的專案，您可以使用 .claude/rules/ 目錄將指令組織成多個檔案。這使指令保持模組化，更容易讓團隊維護。規則也可以 範圍限定於特定檔案路徑，因此它們只在 Claude 處理匹配檔案時載入到上下文中，減少雜訊並節省上下文空間。
規則在每個工作階段或開啟匹配檔案時載入到上下文中。對於不需要始終在上下文中的任務特定指令，請改用 skills，它們只在您呼叫它們或 Claude 確定它們與您的提示相關時載入。
​
設定規則
在您的專案的 .claude/rules/ 目錄中放置 markdown 檔案。每個檔案應涵蓋一個主題，具有描述性檔案名稱，如 testing.md 或 api-design.md。所有 .md 檔案都被遞迴發現，因此您可以將規則組織到子目錄中，如 frontend/ 或 backend/：
your-project/
├── .claude/
│ ├── CLAUDE.md # 主要專案指令
│ └── rules/
│ ├── code-style.md # 程式碼樣式指南
│ ├── testing.md # 測試慣例
│ └── security.md # 安全要求
沒有 paths frontmatter 的規則在啟動時載入，優先級與 .claude/CLAUDE.md 相同。
​
路徑特定規則
規則可以使用帶有 paths 欄位的 YAML frontmatter 範圍限定於特定檔案。這些條件規則僅在 Claude 處理與指定模式匹配的檔案時適用。
---
paths:
- "src/api/**/*.ts"
---

# API 開發規則

- 所有 API 端點必須包括輸入驗證
- 使用標準錯誤回應格式
- 包括 OpenAPI 文件註解
沒有 paths 欄位的規則無條件載入並適用於所有檔案。路徑範圍規則在 Claude 讀取與模式匹配的檔案時觸發，而不是在每次工具使用時觸發。
在 paths 欄位中使用 glob 模式，按副檔名、目錄或任何組合匹配檔案：
模式 匹配
**/*.ts 任何目錄中的所有 TypeScript 檔案
src/**/* src/ 目錄下的所有檔案
*.md 專案根目錄中的 Markdown 檔案
src/components/*.tsx 特定目錄中的 React 元件
您可以指定多個模式並使用大括號展開在一個模式中匹配多個副檔名：
---
paths:
- "src/**/*.{ts,tsx}"
- "lib/**/*.ts"
- "tests/**/*.test.ts"
---
​
使用符號連結跨專案共享規則
.claude/rules/ 目錄支援符號連結，因此您可以維護一組共享規則並將它們連結到多個專案中。符號連結被解析並正常載入，並且循環符號連結被檢測並妥善處理。 把原文解釋成這樣寫，請幫我用白話文解釋出來。

增加常見問題以及參考連結區塊

Claude Code 官方文件：Skills 先不用

240 +不會。`CLAUDE.md` 只是給 AI 看的參考指令，不是系統設定檔。寫錯了頂
+多是 AI 照著錯誤的指令做事，你把內容改回來就好。
241 +
242 +**Q：自動記憶會不會記到奇怪的東西？**
243 +
244 +有可能。AI 根據它自己的判斷決定什麼值得記住，偶爾會記下不太準確或已
+經過時的內容。你可以在對話中輸入 `/memory` 查看所有記憶，看到不對的
+直接刪掉或修改。
245 +
246 +**Q：我寫了 CLAUDE.md，但 AI 有時候還是不照做？**
247 +
248 +這是正常的。`CLAUDE.md` 是「建議」而不是「強制」。根據官方說明，指
+令越具體、越簡短，AI 的遵守率越高。如果某條規則經常被忽略，試試把它
+寫得更明確，或檢查是不是跟其他規則互相矛盾了。
249 +
250 +**Q：CLAUDE.md 跟自動記憶衝突的話，AI 聽誰的？**
251 +
252 +兩者都會被載入，但 `CLAUDE.md` 的優先權比較高。如果你發現自動記憶裡
+存了跟 `CLAUDE.md` 矛盾的內容，直接把那筆記憶刪掉就好。
253 +
254 +**Q：我可以跟 AI 說「記住這件事」嗎？**
255 +
256 +可以。你直接在對話中說「記住，以後都要這樣做」，Claude Code 就會把
+它存進自動記憶。但如果這件事很重要、你希望它每次都百分之百遵守，建
+議還是寫進 `CLAUDE.md`，比較可靠。
257 +
258 +## 參考連結
259 +
260 +- +="noopener noreferrer">Claude Code 官方文件：記憶機制 — 完整說
+明 CLAUDE.md 和自動記憶的運作方式
261 +- +="noopener noreferrer">Claude Code 官方文件：Skills — 進階的任
+務指令封裝，只在需要時載入
262 +- Markdown 基礎語法指南 — 學習 .md
+ 檔案的寫法
⎿  Async hook PostToolUse completed

⏺ 新增了兩個區塊：

常見問題（6 題）：
- 不會寫程式能不能用
- 寫錯了會不會壞掉
- 自動記憶會不會記錯
- AI 不照做怎麼辦
- CLAUDE.md 跟自動記憶衝突時聽誰的
- 可不可以口頭叫 AI 記住

參考連結（3 個）：
- 官方記憶機制文件
- 官方 Skills 文件
- Markdown 基礎語法指南

還需要調整嗎？ -> 這篇補上，還可以請 AI 寫，或是直接跟他講請幫我記住你想要他記住的。