แทนที่จะให้ AI คอยควานหาเอกสารดิบใหม่ทุกรอบที่พิมพ์ถาม อีกแนวคิดหนึ่งที่เวิร์กกว่ามากคือการให้ Claude ค่อยๆ สรุปความเข้าใจของตัวเองบันทึกเป็นไฟล์ Markdown เก็บไว้ในโฟลเดอร์ธรรมดา แล้วปล่อยให้มันดูแลคลังความรู้นี้ต่อเนื่องไปเรื่อยๆ

เสน่ห์ของระบบนี้คือยิ่งใช้ยิ่งฉลาดขึ้น ความรู้จะทับถมและต่อยอดได้เองโดยไม่ต้องเริ่มนับหนึ่งใหม่ทุกคำถาม

ไอเดียนี้ฟังดูเรียบง่ายจนเหมือนใครๆ ก็น่าจะทำกัน แต่ในความเป็นจริง คนที่เซ็ตระบบจนอยู่ตัวและใช้ได้จริงกลับมีน้อยมาก ปัญหาไม่ได้อยู่ที่ความซับซ้อนของแนวคิด แต่อยู่ที่ส่วนที่น่าเบื่อที่สุดของการทำ knowledge base นั่นคืองานดูแลรักษา ทั้งการจัดหมวดหมู่ การวางลิงก์เชื่อมโยงหัวข้อที่เกี่ยวข้องกัน และการคอยอัปเดตเมื่อมีข้อมูลใหม่เข้ามาหักล้างของเดิม ภาระงานพวกนี้มักจะโตเร็วกว่าประโยชน์ที่ได้รับ คนส่วนใหญ่เลยถอดใจทิ้ง wiki ไปกลางคัน

แต่จุดเปลี่ยนสำคัญอยู่ตรงนี้ งานดูแลที่คนเบื่อจนเลิกทำ คืองานที่ LLM ถนัดและทำได้ทั้งวันโดยไม่มีเหนื่อย พอย้ายภาระจัดระเบียบจากเราไปให้ Claude รับผิดชอบ สมการก็เปลี่ยนทันที เราจะได้คลังความรู้ส่วนตัวที่ค่อยๆ เติบโตขึ้นเอง โดยไม่ต้องมานั่งจัดบ้านใหม่ทุกสัปดาห์ และที่สำคัญ แนวคิดนี้ต่างจากระบบ RAG ทั่วไปคนละขั้ว

RAG เริ่มใหม่ทุกครั้ง ส่วน wiki สะสมต่อเนื่อง

วิธีที่นิยมกันอย่าง RAG (Retrieval-Augmented Generation) คือการหั่นเอกสารออกเป็นชิ้นเล็กๆ เก็บไว้ พอเราถามอะไร ระบบก็จะไปดึงชิ้นส่วนที่เกี่ยวข้องมาให้ AI อ่านสดๆ ปัญหาคือทุกคำถาม AI ต้องกลับไปไล่อ่านเอกสารต้นทางใหม่ทั้งหมด แล้วค่อยปะติดปะต่อความเข้าใจขึ้นมาใหม่จากศูนย์ ความเชื่อมโยงที่เคยคิดได้เมื่อวานหายไปหมด พรุ่งนี้ถามซ้ำก็ต้องมานั่งประมวลผลใหม่

วิธี Knowledge Base เปลี่ยนมุมคิดตรงนี้ แทนที่จะดึงเอกสารต้นทางมาอ่านใหม่ทุกครั้ง เราให้ Claude เขียนสังเคราะห์ความเข้าใจออกมาเก็บไว้เป็นไฟล์ ทุกครั้งที่มีข้อมูลใหม่เข้ามา มันจะผสานข้อมูลนั้นเข้ากับ wiki เดิมแบบถาวร พร้อมโยงกับเรื่องที่เกี่ยวข้อง บันทึกจุดที่ขัดแย้ง และสรุปภาพรวมไว้ล่วงหน้า

พอเราถามคำถามในครั้งต่อไป ทั้งคำตอบ ลิงก์เชื่อมโยง และข้อสังเกตต่างๆ ก็พร้อมอยู่ในไฟล์เรียบร้อยแล้วโดยไม่ต้องคิดซ้ำ นี่คือพลังของการสะสมความรู้แบบทบต้น (compounding) เหมือนดอกเบี้ย วันแรกที่เริ่มใช้อาจดูบางตาและธรรมดามาก แต่พอผ่านไปสักร้อยวัน คลังนี้จะกลายเป็นสินทรัพย์ทางปัญญาที่มีมูลค่าและหาจากที่อื่นไม่ได้

โครงสร้างมีสามชั้น

สิ่งที่ช่วยให้ Claude ดูแล wiki ได้อย่างเป็นระเบียบโดยไม่หลงทิศ คือการแบ่งชั้นข้อมูลออกเป็น 3 เลเยอร์ชัดเจน

• Raw: ต้นฉบับดิบทั้งหมดที่เราโยนเข้าไป ไม่ว่าจะเป็นบทความ โน้ตสั้น ภาพแคปหน้าจอ transcript ไฟล์ PDF หรือรูปภาพ ชั้นนี้เก็บไว้เป็นหลักฐานอ้างอิงต้นทางโดยห้ามแก้ไข
• Wiki: ชั้นที่ Claude เป็นคนดูแลและเขียนขึ้นเอง จัดเก็บเป็นไฟล์ Markdown หนึ่งไฟล์ต่อหนึ่งหัวข้อใหญ่ พร้อมใส่ลิงก์เชื่อมโยงถึงกัน
• Schema: ไฟล์ CLAUDE.md ที่กำหนดกฎเกณฑ์ทั้งหมด ว่า wiki มีโครงสร้างอย่างไร ใช้รูปแบบการตั้งชื่อแบบไหน และมีขั้นตอนการทำงานอย่างไรบ้าง

ในชั้น Wiki จะมี 2 ไฟล์หลักที่เป็นหัวใจสำคัญ ไฟล์แรกคือ index.md ทำหน้าที่เป็นสารบัญเชิงโครงสร้างเนื้อหา ไฟล์ที่สองคือ log.md สำหรับบันทึกความเปลี่ยนแปลงตามลำดับเวลาแบบต่อท้ายอย่างเดียว (append-only) ไม่มีการลบของเก่า

ส่วนประกอบที่หลายคนเข้าใจว่าต้องมี แต่ความจริงไม่จำเป็นเลย คือ Vector Database, การทำ Embedding หรือแอปจัดการโน้ตอย่าง Obsidian หรือ Notion แค่โฟลเดอร์บนเครื่องกับไฟล์ข้อความธรรมดาก็เพียงพอแล้ว

ตั้งระบบจริงใน 45 นาที

ระบบทั้งหมดนี้สามารถประกอบร่างเสร็จได้ภายในช่วงบ่ายวันหยุด ไม่ใช่งานใหญ่ระดับเดือน ขั้นตอนมีเพียงเท่านี้

ขั้นแรก สร้างโฟลเดอร์หลัก knowledge-base/ ภายในประกอบด้วยไฟล์ CLAUDE.md และ 3 โฟลเดอร์ย่อย ได้แก่ raw/, wiki/, และ outputs/ จากนั้นเขียนข้อกำหนดใน CLAUDE.md เพื่อบอกโครงสร้าง wiki ที่เราต้องการ

ขั้นที่สอง โยนไฟล์ต้นฉบับทั้งหมดลงในโฟลเดอร์ raw/ โดยไม่ต้องจัดระเบียบล่วงหน้า จะลากทั้งโฟลเดอร์ แปะผ่านแชต หรือเซฟหน้าเว็บเข้ามาก็ได้ ขั้นตอนนี้ใช้เวลาราวสิบนาที

ขั้นที่สาม รันคำสั่งเดียว (Single Prompt) เช่น "อ่านข้อมูลทั้งหมดใน raw แล้วสรุปเรียบเรียงเป็น wiki ในโฟลเดอร์ wiki ตามกฎที่ระบุไว้ใน CLAUDE.md โดยสร้างไฟล์ index.md ก่อน จากนั้นสร้างไฟล์แยกตามหัวข้อ พร้อมใส่ลิงก์เชื่อมโยงหากัน" แล้วปล่อยให้ Claude ประมวลผลประมาณครึ่งชั่วโมง ผลลัพธ์ที่ได้คือ index.md ไฟล์เนื้อหาแยกตามหัวข้อ และลิงก์เชื่อมโยงที่พร้อมใช้งาน รวมเวลาทั้งหมดประมาณ 45 นาที

วงจรที่ยิ่งใช้ยิ่งฉลาด

หัวใจที่ทำให้ระบบนี้แตกต่างจากการจดโน้ตทั่วไปอยู่ที่ขั้นตอนการสืบค้นและต่อยอด เวลาเราถามคำถาม Claude จะเปิดดู index.md ก่อน แล้วเจาะลึกไปยังหน้าที่เกี่ยวข้องเพื่อนำมาเรียบเรียงคำตอบ

จุดสำคัญคือ ระบบจะบันทึกคำตอบที่มีคุณภาพกลับเข้าสู่ raw/ หรือ wiki/ และเก็บรายงานสรุปไว้ใน outputs/ เสมอ ผลลัพธ์จากการทำงานในวันนี้จึงกลายเป็นวัตถุดิบตั้งต้นของวันพรุ่งนี้ คลังความรู้จึงฉลาดขึ้นจากการใช้งานจริง ไม่ใช่โตจากเอกสารที่เราป้อนเพิ่มเพียงอย่างเดียว

เพื่อให้เห็นภาพความลึกของการประมวลผล เอกสารต้นฉบับเพียงชิ้นเดียวที่เพิ่มเข้าไป อาจส่งผลกระทบและอัปเดตหน้า wiki ได้ถึง 10 ถึง 15 หน้า เพราะระบบต้องตามไปผูกโยงกับข้อมูลเดิมที่กระจายอยู่ตามจุดต่างๆ นี่คืองานที่มนุษย์ทำเองได้ยากและใช้พลังงานสูง แต่กลับเป็นสิ่งที่ช่วยให้คลังความรู้เกาะเกี่ยวกันแน่นแฟ้นขึ้นทุกครั้ง

ให้ wiki ตรวจสุขภาพตัวเองทุกเดือน

ส่วนขยายที่ช่วยให้ระบบคงความสดใหม่อยู่เสมอคือการทำ Health Check รายเดือน โดยตั้งเป็น Scheduled Task ให้ Claude ทบทวน wiki ทั้งหมด แล้วจัดทำรายงานสรุปปัญหา เช่น ข้อมูลที่ขัดแย้งกัน ลิงก์ที่เสีย แหล่งอ้างอิงที่หาต้นทางไม่เจอ บทความที่ไม่ได้อัปเดตนานเกิน 90 วัน รวมถึงหัวข้อใหม่ที่ยังตกหล่น

การตรวจเช็กแบบเต็มรอบใช้เวลาราว 12 นาที และใช้ทรัพยากรการประมวลผลพอสมควร (กินเครดิตราว 45% ของ Session บนแพ็กเกจระดับบน) หากใช้แพลนเริ่มต้น อาจจำเป็นต้องแบ่งการสร้าง wiki หรือการตรวจสุขภาพออกเป็นรอบย่อยๆ นี่คือต้นทุนที่ควรนำมาคำนวณล่วงหน้า

ทว่าเมื่อเทียบกับเวลาที่ต้องลงแรงตรวจเอง ตัวเลขนี้ถือว่าคุ้มค่ามาก เพราะผลลัพธ์คือคลังความรู้ที่ไม่เสื่อมสภาพตามกาลเวลา ต่างจาก wiki ทั่วไปที่มักจะรก ล้าสมัย จนสุดท้ายไม่มีใครอยากเปิดใช้งาน

ข้อดีที่แถมมากับการเป็นแค่ไฟล์

เนื่องจาก wiki ทั้งหมดจัดเก็บเป็นไฟล์ Markdown ธรรมดา เราจึงสามารถเปลี่ยนมันเป็น Git Repository ได้ทันที ทำให้ได้ระบบ Version History สำหรับย้อนดูประวัติการแก้ไข รวมถึงการทำ Branching เพื่อทำงานร่วมกันเป็นทีมโดยไม่ต้องติดตั้งซอฟต์แวร์เฉพาะทาง หากต้องการแยกคลังความรู้ตามเรื่อง ก็เพียงแค่สร้างโฟลเดอร์แยกที่มี CLAUDE.md กำกับของตัวเอง

เทคนิคที่นำไปใช้ได้ทันทีคือ นำบทความ Wikipedia หรือไกด์ไลน์ที่พูดถึงลักษณะงานเขียนที่ดูเป็น AI เกินไปมาป้อนให้ Claude แล้วสั่งว่า "นำข้อสังเกตเหล่านี้ไปสร้างเป็นกฎสำหรับตัวเอง เพื่อไม่ให้เขียนเนื้อหาในลักษณะนี้" เพียงเท่านี้ ภาษาใน wiki ก็จะมีความเป็นธรรมชาติและอ่านลื่นหูเหมือนมนุษย์เขียน

แนวทางนี้อาจไม่ใช่ยาวิเศษที่แก้ได้ทุกโจทย์ ยังคงต้องใช้ทรัพยากร ต้องออกแบบกฎเกณฑ์ให้รัดกุมตั้งแต่แรก และยังต้องอาศัยเราป้อนข้อมูลคุณภาพเข้าไป แต่สิ่งที่ระบบนี้ปลดล็อกได้สำเร็จคือคำถามคลาสสิกที่ว่า "ใครจะเป็นคนดูแลรักษาคลังความรู้" ซึ่งเป็นคอขวดของการจัดการข้อมูลมาทุกยุคสมัย

คลังความรู้ที่มีคุณค่า ไม่ได้วัดกันที่ปริมาณข้อมูลในวันแรก แต่วัดกันที่ว่าเมื่อเวลาผ่านไปร้อยวัน ระบบยังสามารถเติบโตและต่อยอดความรู้ต่อไปได้เองหรือไม่