ผมสร้าง "สมองที่สอง" ด้วย Obsidian ที่ AI Agent อ่านได้ โดยไม่ต้องสร้าง Custom RAG Pipeline

เชื่อม Obsidian, Git และ AI Agent เข้าด้วยกันด้วย Markdown ธรรมดา ปรัชญา Seamless Integration by Design จาก NEXT4I

#เอไอ #สมองที่สอง #เครื่องมือ เอไอ AI ช่วยหาข้อมูล AI ช่วยหาข้อมูลในบริษัท #ระบบจัดการความรู้ด้วย AI

---

เคยเจอแบบนี้ไหมครับ ? คุณเขียน technical spec ไว้อย่างละเอียดเมื่อสามเดือนก่อน แล้ววันนี้มีคนถามว่า "เราออกแบบ module นี้ไว้ยังไงนะ ?" คุณต้องใช้เวลา 20 นาทีกด Cmd+F หาไปทั่ว Google Docs, Trello, และ README.md ที่กระจัดกระจายอยู่คนละ repo หรือบางทีก็ไม่มีเขียนไว้ที่ไหนเลย มีแต่ในโค้ดซึ่งต้องมานั่งไล่เปิด code และ debug ด้วยสายตา

TLDR; ผมสร้างระบบ knowledge base สำหรับ NEXT4I โดยใช้ Obsidian (plain Markdown) ร่วมกับ Git และ VS Code AI Agent โดยไม่ต้องเขียน custom integration ซักบรรทัดเดียว หัวใจของระบบคือการเลือกเครื่องมือที่ "พูดภาษาเดียวกัน" ตั้งแต่แรก (plain text, open formats) ทำให้ AI อ่าน knowledge base ของเราได้ฟรีๆ แต่ไม่ฟรี โดยไม่ต้องสร้าง RAG pipeline

---

Pain Point: ความรู้และเอกสาร requirement กระจัดกระจาย ทำให้ค้นหายากและข้อมูลไม่ sync กัน

ก่อนมีระบบนี้ ความรู้ทั้งหมดของ NEXT4I กระจัดกระจายอยู่หลายที่: สมุดโน้ต, Apple Notes, Google Docs, Google Sheet, Trello, ไฟล์ README.md หรือบางทีแย่กว่านั้นคือไม่มีเอกสารเลย มีแค่ในโค้ดเท่านั้น กระจายอยู่ในหลาย repo ที่แต่ละอันก็เขียนกันคนละภาษา ทั้ง frontend และ backend

นี่ไม่ใช่แค่ปัญหาความไม่สะดวกครับ แต่มันทำให้ค้นหายากมาก บางทีต้องกด Cmd+F แล้วภาวนาว่าจะเจอ และที่แย่กว่านั้น: AI coding agent ของผมอ่านโค้ดเบสได้ทั้งหมด แต่ มองไม่เห็นเหตุผลเบื้องหลังโค้ดเลย เพราะมันกระจัดกระจายอยู่ในที่ที่ AI access ไม่ถึง

---

Design Constraints: 3 ข้อที่ห้าม compromise

ก่อนเลือก tool ผมตั้งกฎไว้ 3 ข้อ:

1. ราคาต้องประหยัดไม่แพง หรือถ้าฟรีด้วยจะดีมาก
2. สามารถเปิดดูได้เสมอ online บนโทรศัพท์ และยังสามารถทำงานแบบ offline ได้ด้วย
3. Plain text, zero lock-in. ถ้า tool หายไปพรุ่งนี้ ไฟล์ต้องอ่านได้ ใช้ได้ทันที
4. Local-first, Git-friendly. ต้องเป็นโฟลเดอร์ธรรมดา git init แล้ว track ได้เลย
5. AI-readable โดยไม่ต้องสร้าง infrastructure เพิ่ม. AI agent ผมอยู่บน VS Code อยู่แล้ว knowledge base ต้องอยู่ใน workspace โดยไม่ต้องสร้าง pipeline เพิ่ม

Obsidian ผ่านหมด เพราะหัวใจของ Obsidian vault คือ folder ของ .md ไฟล์

---

Architecture: โครงสร้าง Vault

vault/
├── Ideas/ # Raw concepts, brainstorming
├── Manifesto/ # วิสัยทัศน์, mission, นโยบายหลัก
├── Principles/ # กฎออกแบบ, engineering guidelines
├── Infrastructure/ # deployment topology, IaC specs
├── Platform/ # Domain model, API contracts
├── Script/ # Utility scripts, automation, runbooks
├── Skill/ # patterns, checklists, องค์ความรู้ reusable
└── Appendix/ # Domain glossary, citations

ทุกไฟล์คือ .md ธรรมดา ใช้ [[wiki-link]] ในการเชื่อมโยง Metadata อยู่ใน YAML frontmatter ส่วน Graph View ก็แสดงความสัมพันธ์เป็น dependency graph ที่มองเห็นได้

Version control ก็แค่ git init ใน vault folder แล้ว commit ทุกการเปลี่ยนแปลงพร้อมเหตุผล git log -- "Infrastructure/sharding-strategy.md" ก็จะเห็นประวัติการตัดสินใจทั้งหมดของเรื่องนั้น push ขึ้น private GitHub repo แล้วก็ได้ backup, audit trail, และ branching สำหรับแก้ไขหลักการใหญ่ๆ ไปในตัว

---

Key Insight: AI Access โดยไม่ต้องสร้างอะไรเลย

ตรงนี้แหล่ะครับที่เปลี่ยนทุกอย่าง

Obsidian vault = folder ของ .md ไฟล์ VS Code = เปิด folder ไหนเป็น workspace ก็ได้ AI coding agent (ที่รันเป็น VS Code extension) = อ่านไฟล์ใน workspace ได้ทุกไฟล์

ดังนั้น "integration" ที่ว่านี่คือ: เปิด vault folder ใน VS Code

จบครับ ไม่มี API, ไม่มี embedding pipeline, ไม่มี vector database, ไม่มี chunking strategy มีแต่ไฟล์ Markdown ธรรมดาๆ ที่ AI agent อ่านได้แบบ native

---

Prompt Patterns ที่ใช้จริง

ค้นหาแบบ contextual + reasoning:

ค้นหาเอกสารทั้งหมดที่พูดถึง sharding strategy ของเรา
สรุป trade-off ทั้งหมดที่เราเคยพิจารณา 
และบอกว่าเราสรุปเลือกแนวทางไหนเพราะอะไร

Gap analysis:

ดูทุกอย่างในโฟลเดอร์ Infrastructure/
แล้วบอกว่ามี decision ทางสถาปัตยกรรมอะไรบ้างที่ยังไม่มีเอกสาร ?
เทียบกับ template ใน Skill/

Draft จาก conventions ไม่ใช่จากไฟล์เปล่า:

จาก patterns ใน Skill/go-backend/ และ domain model ใน Platform/core/
ร่าง design doc สำหรับ message consumer ตัวใหม่
โดยทำตาม conventions ที่เรากำหนดไว้แล้ว

Impact analysis ผ่าน link traversal:

ถ้าผมเปลี่ยน authentication rule ใน Principles/auth.md
ไล่ดูว่ามีไฟล์ไหนใน Platform/ และ Skill/ ที่ลิงก์มาหาไฟล์นี้ผ่าน [[links]]
แล้วบอกว่าต้องอัปเดตอะไรบ้าง

AI อ่านข้ามหลายไฟล์, ไล่ตาม [[wiki-links]], เข้าใจความสัมพันธ์, และสังเคราะห์คำตอบ โดยผมไม่ต้องเขียน integration code ซักบรรทัด

---

Philosophy: Seamless Integration by Design

Pattern ของระบบนี้ไม่ใช่ "integrate 3 tools" ครับ แต่มันคือ เลือก components ที่พูดภาษาเดียวกันอยู่แล้ว

Obsidian เลือก Markdown format ที่อ่านได้ universal ที่สุดในโลกคอมพิวเตอร์ แทนที่จะใช้ proprietary database Git ใช้กับ plain text อะไรก็ได้ AI agents อ่านไฟล์ใน VS Code workspace ได้อยู่แล้ว

ผมไม่ได้ สร้าง integration ครับ ผม เลือก integration โดยการเลือก tools ที่เคารพ open format ธรรมดาๆ "งาน" ที่ทำคือ discipline ในการเก็บทุกอย่างให้เรียบง่าย ไม่ใช่การเขียนโค้ดมาเชื่อมมันเข้าด้วยกัน

นี่คือ philosophy เดียวกับที่ผมใช้กับ backend services หรือระบบของNEXT4I: เมื่อทุก components พูดภาษาเดียวกัน ทุกอย่างก็ลื่นไหล โดยที่ไม่ต้องพยายาม

---

Bonus: Obsidian Canvas เป็น Visual Layer

Canvas ของ Obsidian เป็น whiteboard ไม่มีที่สิ้นสุด วางการ์ดเอกสาร, ข้อความ, media แล้วลากเส้นเชื่อม

ผมใช้ Canvas สำหรับ:

• System architecture sketch: แต่ละ service เป็นการ์ด, ลาก data flow, ฝัง spec จริงบนกระดาน
• Decision tree: "ถ้าเลือก X, Y กับ Z จะกระทบ" พร้อม linked evidence
• Plan Stagey & Flow: สำหรับ การวางแผน แผนการทำงาน ลำดับการทำงาน flow การทำงานต่างๆ ของ NEXT4I

Canvas file ก็คือ Markdown เหมือนกัน (โครงสร้าง JSON-like) เลยถูก Git version และ AI อ่านได้ด้วย วางไฟล์ .canvas ใน VS Code workspace แล้วถาม AI ให้วิเคราะห์หา circular dependency หรือ single point of failure ได้เลย

---

สิ่งที่ผมเรียนรู้

สิ่งที่ทำให้ระบบนี้เวิร์คไม่ใช่เทคโนโลยีครับ แต่มันคือสิ่งที่ผม ไม่ได้สร้าง ต่างหาก ไม่มี middleware, ไม่มี proprietary pipeline, ไม่มี vendor lock-in

Discipline ของ plain text + Git + open format คือ feature ไม่ใช่ limitation

ถ้าคุณเป็น dev หรือทีมเล็กๆ ที่จมอยู่ในเอกสารกระจัดกระจาย ลองวิธีนี้ก่อนกระโดดไปหา platform จัดการความรู้ที่หนักๆ ดูครับ Markdown ธรรมดากับ folder structure ดีๆ นี่แหล่ะ พาคุณไปไกลกว่าที่คิด

---

ขอบคุณทุกท่านที่อ่านมาจนถึงตรงนี้ และผมจะพยายามทำบทความดีๆ ขึ้นมาเรื่อยๆ นะครับ

---