แนวทางการเขียนและ anti-patterns

แนวทางเหล่านี้ซ้อนอยู่บนสเปก (ที่บังคับแค่ type) เพื่อให้ทั้งคนและ agent ใช้ wiki ได้อย่างเชื่อถือได้

กฎทอง

1. หนึ่ง concept ต่อไฟล์ — อย่ายัด 3 เรื่องลงไฟล์เดียว
2. เขียน description เพื่อ agent — เป็นบรรทัดเดียวที่ agent อ่านเพื่อตัดสินใจโหลดไฟล์ เขียนให้เจาะจง
3. โครงสร้างชนะย่อหน้า — heading, bullet (**key** — value), ตาราง โมเดลดึงข้อมูลจาก Markdown ที่มีโครงสร้างได้แม่นกว่า
4. identity = path — ตั้งชื่อไฟล์นิ่ง ๆ kebab-case การเปลี่ยนชื่อทำลายลิงก์ที่ชี้เข้ามา
5. type สม่ำเสมอ — ใช้ controlled vocabulary
6. อ้างอิงแหล่งเสมอ — ทุก claim ที่สังเคราะห์ควรสืบกลับไปไฟล์ใน raw/ ได้ ใส่ใต้ # Citations

ตาราง anti-patterns

สเปกหลัก vs แนวปฏิบัติของชุมชน

แยกให้ออก:

• สเปก OKF v0.1 (เล็กมาก): บังคับแค่ type + กฎ index/log + กฎ conformance
• แนวปฏิบัติที่ดี (ในเล่มนี้): ส่วนใหญ่มาจากชุมชน LLM-wiki และ reference implementation ของ Google เช่น confidence decay, hybrid search, การจัดกลุ่ม references/ — ถือเป็น pattern เสริม ไม่ใช่ข้อบังคับ

ประเด็นที่แหล่งข้อมูลเห็นไม่ตรงกัน

• "RAG ตายแล้ว" — วิศวกรส่วนใหญ่บอกว่า wiki = Layer 1, RAG = Layer 2 fallback ไม่ใช่เลือกอย่างใดอย่างหนึ่ง
• ลิงก์ absolute vs relative — สเปกแนะนำ absolute แต่ implementation ใช้ relative (เราตาม implementation)
• freshness scoring 4 มิติ — เป็นแนวทางที่ vendor (Atlan) โปรโมต ไม่ใช่ส่วนของสเปก

ต่อไปเข้าสู่ระดับองค์กร → ภาพรวมสถาปัตยกรรม