Free

Memory nên ghi gì? Tôi audit 5 mục của mình từng cái một

Bài trước lập luận CLAUDE.md chỉ để chứa bất biến. Vậy memory thì ghi gì? Tôi mở cả 5 file memory đang chạy trên dự án này và audit từng cái một—cái nào nên giữ, cái nào nên xóa, và ranh giới thật giữa CLAUDE.md với memory nằm ở đâu.


Bài trước lập luận rằng CLAUDE.md chỉ nên chứa những gì Claude không thể thấy khi đọc code. Một độc giả hỏi ngay: thế còn memory? Memory cũng là ngữ cảnh — khác biệt thực sự nằm ở đâu?

Nhiều người dùng riết rồi coi memory như "phần mở rộng dự phòng" của CLAUDE.md — nghĩ ra gì thì nhét vào. Lâu dần memory phình to, Claude đọc lại mỗi phiên, và quyết định được đưa ra dựa trên thông tin đã cũ.

Bài này bỏ qua định nghĩa trừu tượng. Tôi mở cả 5 file memory đang sống trong dự án này và audit từng cái một — cái nào ở lại, cái nào đi, cái nào đáng lẽ chưa bao giờ nên viết. Trên đường đi, câu hỏi CLAUDE.md vs memory tự trả lời.

Khác biệt trong một câu

  • CLAUDE.md vào system prompt mỗi phiên. Tĩnh. Dành cho bất biến.
  • memory được chính Claude đọc và cập nhật. Động. Dành cho sự thật thay đổi, hoặc sự kiện đơn lẻ đáng giữ.

Câu hỏi hữu ích không phải "cái này để đâu" — mà là "thông tin này sống được bao lâu, và ai cập nhật."

5 file memory của tôi

feedback_commits               — đợi tôi nói "commit" rồi mới commit
feedback_article_authenticity  — bài thực chiến không được bịa
project_i18n_strategy          — quyết định "ra tất cả ngôn ngữ cùng lúc"
project_howdev_plan            — kế hoạch how2claude.dev còn dang dở
project_article_workflow       — pipeline xuất bản bài viết

Nhóm theo loại.

Loại A: Một lần sửa thành quy tắc vĩnh viễn (feedback_commits)

Nội dung ngắn: "don't auto-commit, wait for user to confirm."

Đây là loại memory có ROI cao nhất. Một lần sửa → vĩnh viễn ở mọi phiên tương lai.

Tại sao không để trong CLAUDE.md? Vì nó không phải quy tắc dự án — đó là thói quen làm việc cá nhân của tôi. Nếu cộng tác viên khác tham gia, họ không nhất thiết phải theo cùng quy tắc. CLAUDE.md là cấp độ đội. Memory là "giữa tôi và Claude."

Tại sao không nhắc lại ở đầu mỗi cuộc trò chuyện? Vì memory tồn tại xuyên phiên. Tuần sau Claude giúp tôi, nó vẫn nhớ.

Kích hoạt rõ ràng: tôi đã sửa một lần và muốn lần sửa đó tồn tại mãi.

Loại B: Hồ sơ sự cố có ngày tháng (feedback_article_authenticity)

Nội dung memory này cụ thể khác thường:

Vào 2026-04-16, khi viết bài khép lại series multi-agent, tôi bịa ra câu chuyện "ba Agent xây tính năng webhook"... toàn bộ là hư cấu. Người dùng hỏi "cái này thật hay bịa" — đây là chuẩn mực khác với hai bài trước (về phương pháp luận)...

Điểm mấu chốt: trường Why không phải nguyên tắc trừu tượng — mà là sự kiện cụ thể + ngày + chuyện gì đã xảy ra.

Tại sao viết như thế? Sáu tháng sau, nhìn "bài thực chiến cần chất liệu thật" như một quy tắc trừu tượng sẽ làm tôi bối rối — khi nào đặt ra cái này, vì sao? Nhưng "4-16, tôi bịa chuyện agent bị bắt" kích hoạt ký ức ngay lập tức, và cho tôi phán đoán tại chỗ xem quy tắc còn áp dụng không.

Đây là mục "nặng" nhất trong 5 của tôi. Không chỉ là quy tắc — mà là hồ sơ sự cố mà cả Claude lẫn tôi đều có thể tra.

Loại C: Bối cảnh quyết định chiến lược (project_i18n_strategy)

Nội dung: vì sao dự án này mạnh dạn ra tất cả ngôn ngữ cùng lúc — chi phí dịch qua Claude ~$0, tài liệu chính thức chỉ có tiếng Anh là cửa sổ cơ hội trung tâm.

Bạn không thấy điều này từ code. Code chỉ cho thấy 19 file locale. Tại sao 19, tại sao cùng lúc, tại sao Nhật và Hàn ưu tiên cao — tất cả ở trong đầu tôi.

Memory đọng "quyết định trong đầu" đó thành cái gì đó bền, để khi Claude đề xuất tính năng sau này, nó có thể tự hỏi: cái này có xung đột với chiến lược i18n không?

Không phải quy tắc vận hành (không vào CLAUDE.md). Là nền chiến lược (vào memory).

Loại D: Bàn giao giữa các phiên (project_howdev_plan)

Tạm thời nhất trong số này: một kế hoạch triển khai 9 file cho trang developer how2claude.dev, kết thúc bằng "để lại cho phiên sau."

Đây là loại memory nguy hiểm nhất — dễ trở thành memory xác sống. Làm xong rồi quên xóa; lần sau Claude vẫn coi là còn hiệu lực và tư vấn theo kế hoạch đã cũ ("bạn chưa xong step 3").

Memory kiểu này cần cơ chế rút lui rõ ràng: khoảnh khắc how2claude.dev ra mắt, tôi phải xóa thủ công mục này.

Loại E: Cái nên xóa (project_article_workflow)

Mục này có mật độ thông tin cao nhất. Ban đầu tôi tưởng là hữu ích nhất — cho đến khi đọc kỹ:

  • Sự tồn tại của /write-article/publish-article → nhìn .claude/commands/, xong
  • Cấu trúc thư mục draft (meta.json + lang.md) → docs/drafts/ đã rõ
  • API URL → có trong .claude/publish-config.json
  • Danh sách slug category/series → có trong file seed

Claude có thể suy ra tất cả từ việc đọc code.

Thứ duy nhất memory thực sự cung cấp là khối cuối: "Accounts (production): zh → @how2claude, en → @howtoclaude" — và cái này đã cũ. Phiên trước cho thấy production thực ra là zh=@howtoclaude. Memory chụp ảnh từ vài ngày trước; nó đã lệch.

Kết luận: 90% memory này nên đi. Phần đáng giữ ("dùng kamal để truy vấn tài khoản thời gian thực") hợp với CLAUDE.md hơn — hoặc tốt hơn là không đâu cả, vì tài khoản hardcode trong memory rồi sẽ lại lệch.

Bốn bài học

1. Công việc thật sự của memory là mở những căn phòng Claude không vào được.

  • Không vào được đầu tôi → chiến lược, sở thích, lý do
  • Không vào được phiên tuần trước → tôi đã sửa gì cho bạn
  • Không vào được thất bại ba tháng trước → sự kiện cụ thể + ngày tháng

2. Nếu Claude có thể đọc từ code, đừng đưa vào memory.

Cùng nguyên tắc với bài CLAUDE.md trước. Đường dẫn file, URL API, cấu trúc thư mục — tất cả đều có thể trả lời bằng code. Nhét vào memory vì lười grep một lần là đặt cược rằng thông tin sẽ không bao giờ thay đổi.

3. Memory phân rã.

project_article_workflow là bằng chứng — viết cách đây vài ngày, thông tin tài khoản đã sai. Memory càng cũ càng khó tin. Audit đều đặn > thêm vô tận.

4. Trường Why là thứ cứu bạn.

So sánh hai feedback của tôi:

  • Why của feedback_article_authenticity: "4-16, tôi bịa câu chuyện trong bài multi-agent" → sáu tháng sau tôi có thể phán đoán ngay liệu có còn áp dụng không.
  • Why của feedback_commits: chỉ có "user wants to review" — sáu tháng sau, tôi không chắc cú sửa cụ thể nào đã sinh ra nó.

Cái sau yếu hơn nhiều. Nguyên tắc trừu tượng không sống sót — chẳng ai nhớ vì sao nó bị áp đặt.

Cây quyết định: CLAUDE.md vs memory vs không viết

Khi thông tin mới xuất hiện, đặt ba câu hỏi:

  1. Claude có thể suy ra từ code không? Có → đừng viết gì cả.
  2. Mọi cộng tác viên đều phải tuân theo không? Có → CLAUDE.md.
  3. Nó có thay đổi theo thời gian không? Có → memory (kèm Why cụ thể + How to apply).

Câu thứ ba là bẫy. Phần lớn những thứ "không đổi" mà bạn muốn ghi thật ra có thể suy ra từ code — bạn chỉ không muốn Claude grep lần nữa.

Điều tôi thấy sau khi audit

Rà qua một lượt, vài điểm nổi lên:

  • 90% project_article_workflow có thể suy ra từ code. Cái này cần phẫu thuật nhất.
  • project_howdev_plan là bàn giao tạm thời — về lý thuyết phải có cơ chế rút lui.
  • project_i18n_strategy là quyết định chiến lược — đáng xem lại vài tháng nữa.
  • Why của feedback_commits yếu; gắn thêm sự kiện cụ thể sẽ vững hơn.

Quan sát bên lề: phân bố loại của tôi là feedback×2 + project×3, không có loại user hay reference nào. Nghĩa là tôi chưa nói với Claude "tôi là ai" hay "tôi đọc trạng thái từ hệ thống ngoài nào." Có lẽ là mẻ tiếp theo cần viết.

Kết

Cái bẫy lớn nhất của memory không phải "cái tôi lẽ ra nên viết mà không viết." Mà là "cái tôi đã viết nay đã cũ." Với 5 mục, chỉ cần một mục lệch là đủ — Claude âm thầm dùng thông tin cũ để quyết định, và nó sẽ không báo cho bạn về sự lệch đó.

Trong 5 của tôi, tôi đã thấy vài thứ đáng động đến. Còn của bạn thì sao?