บทความที่แล้วบอกว่า CLAUDE.md เก็บเฉพาะค่าคงที่ แล้ว memory ล่ะ? ผมเปิดไฟล์ memory ทั้ง 5 ไฟล์ที่ยังรันอยู่จริงในโปรเจกต์นี้ และตรวจสอบทีละไฟล์—อันไหนควรเก็บ อันไหนควรลบ และเส้นแบ่งจริงระหว่าง CLAUDE.md กับ memory อยู่ตรงไหน
บทความที่แล้วให้เหตุผลว่า CLAUDE.md ควรเก็บเฉพาะสิ่งที่ Claude มองไม่เห็นจากการอ่านโค้ด ผู้อ่านถามต่อทันทีว่า แล้ว memory ล่ะ? memory ก็เป็นบริบทเหมือนกัน—ความแตกต่างที่แท้จริงอยู่ตรงไหน?
หลายคนใช้ไปใช้มาก็เริ่มปฏิบัติต่อ memory เหมือน "ส่วนขยายสำรอง" ของ CLAUDE.md—นึกอะไรออกก็ยัดลงไป เมื่อเวลาผ่านไป memory บวม Claude อ่านมันทุกเซสชัน และการตัดสินใจก็ตั้งอยู่บนข้อมูลที่ล้าสมัย
บทความนี้ข้ามนิยามนามธรรมไป ผมเปิดไฟล์ memory ทั้ง 5 ไฟล์ที่ยังรันอยู่จริงในโปรเจกต์นี้และตรวจสอบทีละไฟล์—อันไหนอยู่ อันไหนไป อันไหนไม่ควรเขียนตั้งแต่แรก ระหว่างทางคำถาม CLAUDE.md กับ memory จะตอบตัวเอง
คำถามที่มีประโยชน์ไม่ใช่ "จะวางไว้ที่ไหน"—แต่เป็น "ข้อมูลนี้มีอายุเท่าไร และใครเป็นคนอัปเดต"
feedback_commits — รอให้ผมบอก "commit" ก่อนค่อย commit
feedback_article_authenticity — บทความภาคปฏิบัติห้ามแต่ง
project_i18n_strategy — การตัดสินใจ "ปล่อยทุกภาษาพร้อมกัน"
project_howdev_plan — แผนที่ยังไม่เสร็จสำหรับ how2claude.dev
project_article_workflow — ท่อการเผยแพร่บทความ
จัดกลุ่มตามประเภท
เนื้อหาสั้น: "don't auto-commit, wait for user to confirm."
นี่คือ memory ประเภทที่มี ROI สูงสุด การแก้ไขครั้งเดียว → ถาวรในทุกเซสชันต่อไป
ทำไมไม่อยู่ใน CLAUDE.md? เพราะไม่ใช่กฎของโปรเจกต์—เป็นนิสัยการทำงานส่วนตัวของผม ถ้าผู้ร่วมพัฒนาอีกคนเข้าร่วมโปรเจกต์ เขาไม่จำเป็นต้องปฏิบัติตามกฎเดียวกัน CLAUDE.md อยู่ระดับทีม memory เป็น "ระหว่างผมกับ Claude"
ทำไมไม่พูดซ้ำตอนเริ่มต้นทุกบทสนทนา? เพราะ memory คงอยู่ข้ามเซสชัน เมื่อ Claude ช่วยผมสัปดาห์หน้า เขายังคงจำได้
ทริกเกอร์ชัดเจน: ผมแก้ไขครั้งเดียวแล้ว และต้องการให้การแก้ไขคงอยู่ตลอดไป
เนื้อของ memory นี้เจาะจงผิดปกติ:
เมื่อ 2026-04-16 ขณะเขียนบทปิดซีรีส์ multi-agent ผมแต่งเรื่อง "Agent สามตัวสร้างฟีเจอร์ webhook"... ทั้งหมดเป็นเรื่องแต่ง ผู้ใช้ถามว่า "อันนี้จริงหรือแต่ง" — ซึ่งเป็นมาตรฐานที่ต่างจากบทความสองเรื่องก่อน (เชิงระเบียบวิธี)...
ประเด็น: ช่อง Why ไม่ใช่หลักการนามธรรม—เป็น เหตุการณ์เจาะจง + วันที่ + เกิดอะไรขึ้น
ทำไมเขียนแบบนี้? หกเดือนข้างหน้า "บทความภาคปฏิบัติต้องมีวัตถุดิบจริง" ในรูปกฎนามธรรมจะทำให้ผมงง—เมื่อไหร่ ที่ตั้งกฎนี้ ทำไม? แต่ "4-16 ผมแต่งเรื่องเกี่ยวกับ agent และถูกจับได้" ทำให้ความทรงจำกลับมาทันที และให้ผมตัดสินได้ทันทีว่ากฎยังใช้ได้อยู่ไหม
นี่คือรายการที่ "หนัก" ที่สุดใน 5 ของผม ไม่ใช่แค่กฎ—เป็น แฟ้มเหตุการณ์ ที่ทั้ง Claude และผมสามารถตรวจสอบได้
เนื้อหา: ทำไมโปรเจกต์นี้ปล่อยทุกภาษาพร้อมกันอย่างก้าวร้าว—ต้นทุนการแปลผ่าน Claude ใกล้ $0 และเอกสารทางการที่มีแต่ภาษาอังกฤษคือหน้าต่างโอกาสหลัก
มองไม่เห็นจากโค้ด โค้ดแสดงเพียง 19 ไฟล์ locale ทำไม 19 ทำไมพร้อมกัน ทำไมภาษาญี่ปุ่นและเกาหลีจึงได้รับลำดับความสำคัญสูง—ทั้งหมดอยู่ในหัวผม
memory กลั่น "การตัดสินใจในหัว" นั้นให้เป็นสิ่งที่ทนทาน เพื่อเวลา Claude เสนอฟีเจอร์ภายหลัง เขาถามได้ว่า: อันนี้ขัดกับกลยุทธ์ i18n หรือเปล่า?
ไม่ใช่กฎปฏิบัติการ (ไม่ต้องอยู่ใน CLAUDE.md) เป็นพื้นหลังเชิงกลยุทธ์ (อยู่ใน memory)
ชั่วคราวที่สุดในกลุ่ม: แผนดำเนินการ 9 ไฟล์สำหรับเว็บไซต์นักพัฒนา how2claude.dev จบด้วย "ต่อในเซสชันถัดไป"
ประเภท memory ที่อันตรายที่สุด—กลายเป็น memory ซอมบี้ ได้ง่าย เสร็จงานแล้วลืมลบ ครั้งถัดไป Claude ถือว่ายังใช้งานอยู่และให้คำแนะนำตามแผนที่ล้าสมัย ("คุณยังไม่ได้ทำ step 3")
memory แบบนี้ต้องการ กลไกทางออก ที่ชัดเจน: เมื่อ how2claude.dev เปิดตัว ผมต้องลบรายการนี้ด้วยตนเองทันที
มีความหนาแน่นของข้อมูลสูงสุด ตอนแรกผมคิดว่ามีประโยชน์ที่สุด—จนกระทั่งได้อ่านอย่างละเอียด:
/write-article และ /publish-article → ดูที่ .claude/commands/ จบdocs/drafts/ ทำให้เห็นชัด.claude/publish-config.jsonClaude สามารถอนุมานทั้งหมดนี้ได้จากการอ่านโค้ด
สิ่งเดียวที่ memory ให้จริง ๆ คือบล็อกสุดท้าย: "Accounts (production): zh → @how2claude, en → @howtoclaude" — และสิ่งนี้ ล้าสมัยไปแล้ว เซสชันล่าสุดแสดงว่าโปรดักชันจริง ๆ แล้วเป็น zh=@howtoclaude memory บันทึกภาพนิ่งจากไม่กี่วันก่อน และได้เบี่ยงเบนแล้ว
สรุป: 90% ของ memory นี้ควรไป ส่วนที่ควรเก็บไว้ ("ใช้ kamal เพื่อดึงข้อมูลบัญชีแบบเรียลไทม์") เหมาะกับ CLAUDE.md มากกว่า—หรือดีกว่านั้น ไม่ใส่ที่ไหนเลย เพราะบัญชีที่ฝังไว้ใน memory ก็จะเบี่ยงเบนอีก
1. งานจริงของ memory คือเปิดห้องที่ Claude เข้าไม่ได้
2. ถ้า Claude อ่านได้จากโค้ด อย่าใส่ใน memory
หลักการเดียวกับบทความก่อนหน้าเรื่อง CLAUDE.md เส้นทางไฟล์ URL ของ API โครงสร้างไดเรกทอรี—ล้วนเป็นคำถามที่โค้ดตอบได้ การยัดลง memory เพราะขี้เกียจรัน grep อีกครั้ง เท่ากับการพนันว่าข้อมูลจะไม่เปลี่ยนแปลงตลอดไป
3. memory เสื่อมลง
project_article_workflow คือหลักฐาน—เขียนเมื่อไม่กี่วันก่อน ข้อมูลบัญชีก็ผิดแล้ว ยิ่ง memory เก่ามาก ยิ่งไม่น่าเชื่อถือ ตรวจสอบเป็นระยะ > เพิ่มเรื่อย ๆ
4. ช่อง Why คือสิ่งที่ช่วยชีวิตคุณ
เปรียบเทียบ feedback สองรายการของผม:
feedback_article_authenticity: "4-16 ผมแต่งเรื่องในบทความ multi-agent" → หกเดือนต่อมาผมตัดสินได้ทันทีว่ายังใช้ได้ไหมfeedback_commits: มีเพียง "user wants to review" → หกเดือนต่อมาผมไม่แน่ใจว่าเกิดจากการแก้ครั้งไหนข้อหลังอ่อนกว่ามาก หลักการนามธรรมไม่รอด—ไม่มีใครจำได้ว่าทำไมถึงบังคับใช้
เมื่อข้อมูลใหม่ปรากฏขึ้น ถามสามคำถาม:
คำถามที่สามคือกับดัก ส่วนใหญ่ของเรื่อง "ไม่เปลี่ยนแปลง" ที่คุณอยากจดจริง ๆ แล้วอนุมานได้จากโค้ด—คุณแค่ไม่อยากให้ Claude รัน grep อีกครั้งเท่านั้น
เดินผ่านทีเดียวก็เห็นหลายอย่าง:
project_article_workflow อนุมานได้จากโค้ด อันนี้ต้องผ่าตัดหนักที่สุดproject_howdev_plan เป็นการส่งต่อชั่วคราว—ในทางทฤษฎีควรมีกลไกทางออกproject_i18n_strategy เป็นการตัดสินใจเชิงกลยุทธ์—ควรกลับมาทบทวนในอีกไม่กี่เดือนfeedback_commits อ่อน; การแนบเหตุการณ์เจาะจงจะทำให้แข็งแกร่งขึ้นข้อสังเกตเสริม: การกระจายประเภทของผมคือ feedback×2 + project×3 โดยไม่มีประเภท user หรือ reference เลย หมายความว่าผมยังไม่ได้บอก Claude ว่า "ผมเป็นใคร" หรือ "อ่านสถานะจากระบบภายนอกใดบ้าง" น่าจะเป็นชุดถัดไปที่ต้องเขียน
กับดักใหญ่ที่สุดของ memory ไม่ใช่ "สิ่งที่ควรเขียนแต่ไม่ได้เขียน" แต่เป็น "สิ่งที่เขียนไปแล้วและตอนนี้ล้าสมัย" ด้วย 5 รายการ แค่รายการเดียวเบี่ยงเบนก็พอ—Claude ใช้ข้อมูลเก่าเงียบ ๆ ในการตัดสินใจ และจะไม่บอกคุณเรื่องการเบี่ยงเบน
ใน 5 รายการของผม ผมเห็นหลายอย่างที่ควรขยับแล้ว แล้วของคุณล่ะ?