Cấu trúc kho lưu trữ và gỡ lỗi
Tổ chức một kho lưu trữ markdown như một bộ nhớ thứ hai có thể tìm kiếm. Phân loại bốn chế độ lỗi khi Claude làm điều gì đó bất ngờ.
STATE.md và MEMORY.md chứa những gì mọi phiên cần. Một kho lưu trữ markdown (Obsidian hoặc bất kỳ thư mục nào) chứa mọi thứ khác: ghi chú chiến lược, bản ghi cuộc họp, nhật ký dự án, nghiên cứu, phân tích cạnh tranh.
Kho lưu trữ phát triển thành bộ nhớ thể chế: các quyết định bạn đã đưa ra sáu tháng trước và lý do, tài liệu tham khảo cung cấp thông tin cho công việc hiện tại, các mẫu trải rộng trên các dự án. Kết nối nó qua một MCP Obsidian hoặc hệ thống tệp và Claude có thể tìm kiếm toàn bộ theo yêu cầu. Nếu không có kho lưu trữ, kiến thức này chỉ tồn tại trong đầu bạn hoặc bị chôn vùi trong các tài liệu cũ.
Tại sao markdown tốt hơn cơ sở dữ liệu: các tệp đơn giản có thể tìm kiếm được, phiên bản với git, mở trong bất kỳ trình chỉnh sửa nào và tồn tại qua mọi thay đổi công cụ. Một cấu trúc hoạt động:
~/notes/
├── STATE.md # Luôn được tải
├── MEMORY.md # Chỉ mục, luôn được tải
├── STRATEGY-DIGEST.md # Tóm tắt các tài liệu chiến lược
├── strategy/ # Tài liệu đầy đủ, đọc theo yêu cầu
├── projects/ # Ghi chú dự án có ngày tháng
├── resources/
└── reference/Chìa khóa mở rộng quy mô là mẫu tóm tắt: khi bạn viết một tài liệu chiến lược dài 1.000 từ, hãy viết một bản tóm tắt 3 câu bên cạnh nó và lập chỉ mục bản tóm tắt trong MEMORY.md. Claude đọc khoảng 50 mã thông báo khi bắt đầu phiên thay vì khoảng 1.500 mã thông báo của tài liệu đầy đủ. Với 25 tài liệu chiến lược, đó là 1.250 mã thông báo so với 37.500, và các phiên vẫn nhanh.
Khi Claude làm điều gì đó bất ngờ, hãy kiểm tra bốn chế độ lỗi theo thứ tự, từ phổ biến nhất đến ít phổ biến nhất:
Bộ nhớ lỗi thời: STATE.md nói một đằng, thực tế nói một nẻo. Claude đã làm theo hướng dẫn của bạn một cách hoàn hảo; hướng dẫn đã sai. Hãy hỏi "Hiển thị cho tôi STATE.md của bạn" trước, mỗi lần.
Thiếu ngữ cảnh: tệp liên quan không bao giờ được tải, vì vậy Claude đã đưa ra một phỏng đoán hợp lý. Tải tệp một cách rõ ràng và hỏi lại.
Công cụ không khả dụng: một MCP bị lỗi hoặc một hook đã chặn một lệnh, và Claude đã xử lý nó một cách tồi tệ. Kiểm tra tính khả dụng của công cụ trước khi đổ lỗi cho lý do.
Ảo giác: nguyên nhân hiếm nhất. Xác minh trước: tìm kiếm hàm, kiểm tra xem điểm cuối có tồn tại không. Hầu hết các "ảo giác" hóa ra là một trong ba nguyên nhân đầu tiên.
Một câu hỏi chẩn đoán cho mỗi chế độ lỗi:
Bộ nhớ lỗi thời: "STATE.md của bạn nói gì về [chủ đề]?" Nội dung từ ba phiên trước có nghĩa là trạng thái lỗi thời.
Thiếu ngữ cảnh: "Bạn có những tệp nào được tải về [chủ đề]?" Không có tệp liên quan có nghĩa là tải tệp đúng.
Công cụ không khả dụng: "Bạn có những công cụ nào có sẵn ngay bây giờ?"
Ảo giác: "Tìm kiếm [hàm/điểm cuối] và cho tôi biết bạn tìm thấy gì."
Trình tự này mất hai phút và tìm ra nguyên nhân gần như mọi lúc. Trực tiếp chuyển sang "Claude bị ảo giác" thường làm chậm việc sửa lỗi thực sự bằng cách viết lại mã không cần viết lại.
Phòng ngừa tốt hơn gỡ lỗi. Các thói quen:
Cập nhật STATE.md cuối phiên. Loại bỏ 80% các vấn đề bộ nhớ lỗi thời.
Lưu trữ các dự án đã hoàn thành vào các tệp project_* có ngày tháng.
Kiểm toán MEMORY.md hàng tháng: xác nhận mọi con trỏ vẫn trỏ đến một tệp hiện có.
Tóm tắt mọi tài liệu dài hơn 500 từ.
Viết quyết định tại thời điểm ra quyết định, không phải vào cuối tuần. Ghi lại sau đó sẽ mất đi lý do.
Trước khi lưu trữ ghi chú dự án, trích xuất các bài học bền vững vào các mục feedback_*. Dự án trở thành lịch sử; các bài học vẫn hoạt động.
Một kho lưu trữ với 10 tài liệu được duy trì tốt tốt hơn một kho lưu trữ với 200 tài liệu lỗi thời. Chất lượng và tính cập nhật tốt hơn số lượng.
Với một MCP Obsidian hoặc hệ thống tệp, kho lưu trữ trở thành một cơ sở kiến thức trực tiếp:
Khảo cổ học quyết định: "Tìm kiếm trong kho lưu trữ lý do chúng tôi chọn Postgres thay vì MySQL." Một cuộc tìm kiếm thủ công 10 phút trở thành 15 giây.
Phát hiện mẫu: "Tìm tất cả các đề cập về các vấn đề giới hạn tốc độ hoặc lỗi 429 trên các dự án." Claude đưa ra một nguyên nhân gốc rễ phổ biến trải rộng trên năm tệp dự án.
Tra cứu tham chiếu: "Tìm thông tin liên hệ trong ghi chú nhà cung cấp." Truy xuất tức thì từ các tệp không được lập chỉ mục.
Chất lượng tìm kiếm phụ thuộc vào tính nhất quán của tên: project_[name]_[date].md và feedback_[rule].md tốt hơn bất cứ điều gì cảm thấy tự nhiên vào thời điểm đó. Quy ước đặt tên là chỉ mục bạn xây dựng trước khi bạn cần nó.
Cả bốn chế độ đều sạch sẽ nhưng đầu ra vẫn sai? Hai nguyên nhân trông giống như ảo giác nhưng không phải.
Thứ tự ngữ cảnh: khi các tệp đã tải xung đột, nội dung được tải sau có xu hướng thắng thế. Nếu ghi chú dự án cũ mâu thuẫn với STATE.md, hãy gán quyền hạn một cách rõ ràng: "STATE.md là sự thật cơ bản hiện tại. Nó thay thế mọi thứ trong ghi chú dự án."
Xung đột ràng buộc: CLAUDE.md nói "tham số hóa tất cả SQL," vì vậy Claude viết lại SQL trong khi bạn chỉ muốn một refactor chỉ về kiểu dáng. Không phải lỗi; hãy xác định phạm vi rõ ràng: "Chỉ kiểu dáng, không thay đổi các mẫu SQL."
Chẩn đoán cho cả hai: "Bạn đang tuân theo hướng dẫn nào chi phối [quyết định này]? Liệt kê các quy tắc theo thứ tự ưu tiên." Bạn sẽ tìm thấy một nguồn cũ, một quy tắc mâu thuẫn hoặc một lỗ hổng CLAUDE.md. Tất cả đều có thể sửa được.
Một kho lưu trữ markdown với các tệp tóm tắt mở rộng bộ nhớ thứ hai của bạn; các tóm tắt giữ cho các phiên nhanh, tài liệu đầy đủ tải theo yêu cầu. Khi Claude hoạt động sai, hãy phân loại theo thứ tự: bộ nhớ cũ, thiếu ngữ cảnh, công cụ không khả dụng, ảo giác, và luôn bắt đầu với "hiển thị STATE.md của bạn." Cung cấp cho kho lưu trữ vào thời điểm quyết định và giá trị của nó sẽ tăng lên mỗi tuần.