โปรเจ็กต์ซอฟต์แวร์จำนวนมากไม่ได้มีปัญหาเพราะมองไม่เห็นโค้ด แต่มีปัญหาเพราะมองไม่เห็นบริบท

ใน repository อาจมี source code ครบ แต่เหตุผลเบื้องหลังการตัดสินใจกลับกระจายอยู่ในแชต โน้ต ภาพหน้าจอ หรืออยู่ในความทรงจำของใครบางคน พอเป็นแบบนี้ นักพัฒนาคนใหม่ต้องใช้เวลานานกว่าจะเข้าใจโปรเจ็กต์ และ AI agents ก็จะได้บริบทที่ไม่ครบ Obsidian ช่วยแก้ปัญหานี้ได้ด้วยการทำให้ความรู้ของโปรเจ็กต์กลายเป็น second brain ที่ค้นหาได้ เชื่อมโยงกันได้ และดูแลต่อได้ง่าย

แนวคิด second brain เป้นแนวคิดที่ดีโดยการเก็บโน้ตสำคัญของโปรเจ็กต์ไว้ใน repository และเขียนในรูปแบบที่ทั้งคนและ AI อ่านได้ โดยเฉพาะถ้าคุณต้องการให้ repo ไม่ได้เก็บเพียงแค่ source code โดยเก็บเอกสาร ข้อมูลที่สำคัญ ไอเดีย รวมถึงความรู้ที่ใช้ในการพัฒนาไว้ด้วย

จริงๆ แล้ว การเขียนเอกสารในโปรเจ็ค นิยมใช้ Markdown เพื่อบอกรายละเอียดของการตั้งค่าโปรเจ็ค หรือบอก History changes แต่ถ้าเราจะทำเอกสารของทั้งโปรเจ็ค Markdown อย่างเดียวคงจะยุ่งเหยิง โดย Obsidian มาช่วยสร้างให้เอกสาร Markdown เหล่านั้นสามารถเชื่อมโยงกันได้

ทำไมต้อง Obsidian

Obsidian เป็นระบบที่สามารถสร้างเอกสารแบบเชื่อมโยงกันได้ ซึ่งเหมาะกับงานพัฒนาซอฟต์แวร์ แต่ความสามารถของ Obsidian สามารถประยุกต์ใช้เป็นระบบ Knowlege Mangement รวมถึงการทำ Project management ได้อีกด้วย เนื่องจากมีปลั๊กอินมากมาย เช่น Calendar, timeline เป็นต้น

เมื่อเราเชื่อมโน้ตเรื่อง architecture, product decisions, APIs และ bugs เข้าด้วยกัน เราจะได้เอกสารของโปรเจ็กต์อย่างมีระบบ นักพัฒนาสามารถเปิดโน้ตหนึ่งแล้วกระโดดไปดูการตัดสินใจที่เกี่ยวข้องได้ทันที ส่วน AI agent ก็ทำแบบเดียวกันได้ ถ้าโน้ตเหล่านั้นอยู่ในรูปแบบ markdown ภายใน repo

ตัวอย่าง Folder Structure

docs/
    overview.md
    architecture.md
    decisions/
        2026-04-13-auth-flow.md
        2026-04-13-database-choice.md
    features/
        payments.md
        search.md
    meetings/
        2026-04-13-planning.md

โน้ตที่ดีควรตอบคำถามหนึ่งเรื่องให้ชัด

• overview.md: ระบบนี้คืออะไร และสร้างมาเพื่อใคร
• architecture.md: ส่วนประกอบหลักของระบบเชื่อมกันอย่างไร
• decisions/: ทำไมจึงตัดสินใจแบบนั้น และมี trade-off อะไร
• features/: แต่ละฟีเจอร์ทำอะไร และมีพฤติกรรมอย่างไร
• meetings/: มีการคุยอะไรกัน และมีอะไรเปลี่ยนแปลงบ้าง

Best practice:

• เก็บโน้ตเป็น markdown ไว้ใน repo หรือในโฟลเดอร์ docs ที่เชื่อมกันชัดเจน
• ให้แต่ละโน้ตโฟกัสเพียงเรื่องเดียว เช่น หัวข้อ การตัดสินใจ หรือฟีเจอร์หนึ่งอย่างถ้ามีรายละเอียด
• ถ้ามีการแก้ไขหรืออัพเดต source code เดิม ควรปรับปรุงโน้ต pull request เดียวกัน
• เชื่อมโยงโน้ตที่เกี่ยวข้องกัน เพื่อให้ obsidian สามารถสร้างการเชื่อมโยงแบบกราฟได้

โน้ตควรกระชับตาม concept TR;DR (Too long, Don’t read) และสร้างการเชื่อมโยงที่จำเป็น เช่น ถ้ามี decision ที่กระทบกับระบบ authentication ก็ควรลิงก์จาก architecture note และ feature note ที่เกี่ยวข้องด้วย จะช่วยทำให้ vault มีประโยชน์

การ Link Notes

ตัวอย่างเช่น:

# architecture

ระบบนี้ใช้ token-based login flow ตามที่อธิบายไว้ใน [[2026-04-13-auth-flow]].

ฟีเจอร์ search ถูกแยกเป็นอีกโมดูลหนึ่ง ดูรายละเอียดพฤติกรรมได้ที่ [[search]].

การตัดสินใจเรื่องฐานข้อมูลปัจจุบันถูกบันทึกไว้ใน [[2026-04-13-database-choice]].

และภายใน feature note:

# search

ฟีเจอร์ search รองรับการค้นหาสินค้า การกรอง และการจัดลำดับผลลัพธ์

โน้ตที่เกี่ยวข้อง:
- [[architecture]]
- [[2026-04-13-database-choice]]
- [[2026-04-13-planning]]

เมื่อใช้วิธีนี้ คนสามารถไล่ดูจาก architecture ไปยังฟีเจอร์ และต่อไปยังเอกสารการตัดสินใจได้ ส่วน AI agent ก็สามารถตามเส้นทางของ markdown ที่เชื่อมโยงกันนี้เพื่อทำความเข้าใจ repo ได้ดีขึ้นมากเช่นกัน

ประโยชน์ที่ได้รับของนักพัฒนา

สำหรับนักพัฒนา ประโยชน์หลักคือความเร็วและความชัดเจน

นักพัฒนาคนใหม่สามารถเปิด repo แล้วเข้าใจได้เร็วขึ้นว่าผลิตภัณฑ์คืออะไร architecture เป็นอย่างไร และมี trade-off สำคัญตรงไหนบ้าง วิศวกรอาวุโสสามารถทบทวน decision ได้โดยไม่ต้องถามหลายคนซ้ำๆ และ product owner ก็อ่านโน้ตชุดเดียวกันเพื่อเข้าใจว่าทำไมฟีเจอร์นี้ถึงมีอยู่

สิ่งนี้ช่วยลดการอธิบายซ้ำ และลดความเสี่ยงจากการแก้ของสำคัญโดยไม่รู้ว่าทำไมระบบจึงถูกออกแบบมาแบบนั้น

สำคัญคือการ contribute เอกสารอย่างสม่ำเสมอ กระชับ เชื่อมโยงได้เป็นสิ่งสำคัญ

AI Agents ได้ประโยชน์อย่างไร

ในยุคนี้นักพัฒนาต้องทำงานร่วมกับ AI Agents ดังนั้น AI agents จะทำงานได้ดีขึ้นมากเมื่อ context มีโครงสร้างที่ชัดเจน

ถ้าใน repository มีโน้ต markdown ที่ชัดเจน agent จะสามารถ:

• สรุป architecture ปัจจุบันได้
• อธิบายได้ว่าทำไมฟีเจอร์หนึ่งจึงมีอยู่
• ร่าง implementation plan ใหม่ได้
• เสนอการเปลี่ยนแปลงที่สอดคล้องกับ decision เดิมได้
• และชี้ให้เห็น documentation ที่ยังขาดอยู่ได้

นั่นหมายความว่า agent ไม่ได้อ่านจาก source code อย่างเดียว แต่กำลังอ่านความทรงจำของโปรเจ็กต์อยู่ด้วย ซึ่งจะทำให้ประหยัด Tokens

ในการเขียนโน้ตให้เขียนเหมือนที่เราเขียนโค้ด คือชัดเจน กระชับ และอัปเดตเมื่อความจริงเปลี่ยนไป

ถ้าโน้ตยาวเกินไปให้แยก ถ้า decision นั้นเลิกใช้แล้วก็ควรระบุให้ชัด ถ้าฟีเจอร์เปลี่ยน ควรอัปเดตโน้ตที่เกี่ยวข้องใน pull request เดียวกัน วิธีนี้จะทำให้ knowledge base ยังเชื่อถือได้เสมอ

Obsidian เป็นเครื่องมือทรงพลัง เมื่อเราไม่ได้ใช้มันเป็นไดอารีส่วนตัว แต่ใช้มันเป็น shared project memory

ดังนั้นเราสามารถสร้างความทรงจำของโปรเจ็คได้ ด้วยการใช้ obsidian เป็นมันสมองที่สอง (Second brain)

ความทรงจำนี้ช่วยให้คนทำงานได้เร็วขึ้น ช่วยให้ AI agents เข้าใจ codebase ดีขึ้น และช่วยให้ทีมมีบันทึกที่ชัดเจนว่า decision ต่างๆ เกิดขึ้นได้อย่างไร ผลลัพธ์คือการทำงานร่วมกันที่ลื่นขึ้น มี friction น้อยลง และทำให้ repo อ่านเข้าใจได้ง่าย แม้เวลาจะผ่านไปนานแล้วก็ตาม

ลองใช้ได้เลย https://obsidian.md/help/install