มีช่วงหนึ่งในการทำงานเอ้เริ่มเบื่อกับคำถามที่ว่า “เอกสารเรื่องนี้อยู่ไหน” ซึ่งเอ้คิดว่าทุกคนน่าจะเจอเหมือนกันคือ เอกสารจะกระจายไปอยู่แต่ละที่ ตามความถนัดการใช้ Tools ของแต่ละคน หรือแล้วแต่ทีม บางเอกสารอาจไปอยู่ใน Notion บางไฟล์อยู่ใน Google Doc บางอันเป็นเอกสารในเครื่องเราที่โหลดมานานแล้วจนลืมไปแล้วว่าสำคัญ (ซึ่งปกติจะไม่สำคัญ 🤣) และในการทำโปรเจกต์ใหญ่ ๆ บางครั้ง เอกสารก็จะอยู่ที่ลูกค้าเอง ต้องเข้าไปดู หรือโหลดลงมาเก็บในเครื่องเรา
วิเคราะห์ปัญหาให้ถูกจุด ก่อนเริ่มหาเครื่องมือ
ตอนแรกเอ้ก็พยายามแก้ด้วยวิธีแบบปกติ คือพยายามรวบรวมไฟล์โยนลงไปใน Folder หรือ Google Drive แต่สุดท้ายก็พบว่าไม่ได้ช่วยให้อะไรดีขึ้น เพราะ ถ้าไฟล์อยู่รวมกัน สุดท้าย เราก็ต้องมานั่งค้นหาไฟล์อยู่ดี ปัญหาที่แท้จริงไม่ใช่แค่เรื่อง “เก็บไว้ที่ไหน” แต่คือ “โครงสร้างเนื้อหาและบริบทที่ไม่เคยตรงกัน”
จุดที่เอ้ให้ AI เข้ามาช่วยจริง ๆ
จากปัญหาที่เล่ามา จึงเป็นที่มาว่าทำไมเอ้ถึงเอา AI เข้ามาช่วยจัดการเอกสาร
สมมติฐานแรก: ให้ AI อ่านและสรุปเอกสารให้ตรง ๆ เลย แนวคิดแรกที่แวบเข้ามา (และเชื่อว่าหลายคนก็คิดเหมือนกัน) คือ “ในเมื่อมี AI อยู่แล้ว ก็โยนไฟล์ให้มันอ่านแล้วสรุปออกมาเลยสิ” แต่พอลองทำจริงในโปรเจกต์ขนาดใหญ่ เอกสารความต้องการของลูกค้า (PRD/Spec) มักเป็นไฟล์ Word หรือ Excel ความยาว 100–200 หน้า การส่งไฟล์พวกนี้ให้ AI อ่านตรง ๆ ใช้ทั้งเวลาและกิน Token มหาศาล แถม AI ยังวิเคราะห์ไฟล์โครงสร้างซับซ้อนอย่าง Excel ได้ไม่ดีเท่าที่ควร วิธีนี้เลยปัดตกไป
สมมติฐานที่สอง: งั้นให้ทุกคนเขียนเอกสารเป็น Markdown ตั้งแต่แรก? ในเมื่อ AI ประมวลผลไฟล์ Markdown ได้ดีและประหยัด Token กว่าไฟล์ Word/Excel มาก งั้นบังคับให้ทีมและลูกค้าเขียน Markdown ตั้งแต่แรกเลยได้ไหม? คำตอบคือ เป็นไปไม่ได้ในความเป็นจริง เพราะคงไม่มี User หรือ Stakeholder ทั่วไปคนไหนถนัดมานั่งพิมพ์ Syntax ข้อความบริสุทธิ์แบบ Markdown
โซลูชันที่จบลงตัว: ให้ AI อ่านครั้งเดียว แล้วแปลงเป็น Markdown เพื่อใช้ยาว ๆ ข้อสรุปเลยมาจบที่การบาลานซ์ความคุ้มค่า คือยอมเสีย Token ในการอ่านเอกสารก้อนใหญ่ทั้งหมด เพียงครั้งเดียว เพื่อให้ AI เรียบเรียงและแปลงออกมาเป็นไฟล์ Markdown เก็บไว้เป็นศูนย์กลาง
ข้อดีของวิธีนี้คือ Markdown เป็นเพียงไฟล์ Text ที่เบามาก หลังจากนี้ ไม่ว่าเราจะใช้ AI มาอ่าน สรุป หรือดึง Context ไปใช้งานต่อในอนาคตก็จะใช้ Token น้อยลงมหาศาล และรวดเร็วกว่าการสั่งให้ AI ไปงมไฟล์ Word หรือ Excel ตรง ๆ ทุกครั้ง
นอกจากเรื่องความเบาและประหยัด Token แล้ว สิ่งที่ทำให้ Markdown ยืดหยุ่นมาก ๆ คือการที่ตัวมันรองรับการใส่โค้ด HTML หรือใช้ร่วมกับ MDX ได้ในตัว ซึ่งนำไปประยุกต์ใช้กับเอกสารได้อีกเยอะมาก เช่น:
- ใส่ Custom UI & Callout: สามารถแทรกกล่องแจ้งเตือน (Alert), สถานะ Badge หรือปุ่ม Interactive ต่าง ๆ เข้าไปในเอกสารได้ทันที
- Embed Media และไฟล์ภายนอก: แทรกคลิปวิดีโอสาธิตการใช้งาน, สไลด์พรีเซนต์ หรือไฟล์ Figma Mockup ให้แสดงผลในหน้าเอกสารตรง ๆ
- ดึง Components มาใช้ซ้ำ: ยิ่งทำงานร่วมกับ Astro เราสามารถสร้าง UI Components สวย ๆ เตรียมไว้ แล้วดึงมาแปะในไฟล์ Markdown ได้ง่าย ๆ ช่วยเปลี่ยนเอกสารข้อความแห้ง ๆ ให้กลายเป็น Interactive Documentation ที่น่าอ่านยิ่งขึ้น
ยกตัวอย่างเช่น ถ้าอยากแทรกกล่องแจ้งเตือนเตือนทีมว่าเอกสารส่วนนี้ Deprecated แล้ว
แค่แปะ HTML ธรรมดาแทรกเข้าไปในไฟล์ .md ได้เลย โดยไม่ต้องเปลี่ยนไปเขียนไฟล์ประเภทอื่น:
<div style="border-left: 4px solid #f39c12; padding: 0.75rem 1rem; background: #fff8e6;">
⚠️ <strong>หมายเหตุ:</strong> API เวอร์ชันนี้ Deprecated แล้ว ให้ดูเอกสาร v2 แทน
</div>หรือถ้าอยากดึง Component ของ Astro มาใช้ในเอกสารเลยก็ทำได้ทันที (ต้องเปลี่ยนนามสกุลไฟล์เป็น
.mdx) เช่น:
import Badge from '../../components/Badge.astro';
สถานะปัจจุบัน: <Badge status="in-progress" /> คาดว่าจะเสร็จภายในสัปดาห์นี้ผลลัพธ์ที่ได้คือ Component ตัวเดียวกับที่ใช้ในเว็บจริง ไม่ใช่แค่โค้ดตัวอย่าง เช่น 3 สถานะที่ Badge รองรับ:
รอดำเนินการ กำลังทำ เสร็จแล้ว
หรือจะทำให้กดสลับสถานะได้เลยก็ได้ แค่ห่อ <Badge /> ด้วย component เล็ก ๆ ที่มีปุ่มกับ
<script> สลับ Class ในตัว (ไม่ต้องพึ่ง Framework ฝั่ง Client เลย):
ที่โชว์ให้กดเล่นได้จริงตรงนี้ เพราะบล็อกนี้เองก็เขียนด้วย Astro พอ Build ออกมาเป็นเว็บ
HTML กับ <script> ที่ฝังในบทความเลยทำงานได้เหมือนหน้าเว็บทั่วไป ไม่ใช่แค่ตัวอย่างในเอกสารเฉย ๆ
แล้วถ้าเอกสารไม่อัปเดตตามระบบล่ะ?
มาถึงจุดนี้ หลายคนคงเริ่มสงสัยว่า “แล้วถ้าเอกสารไม่อัปเดตจะทำยังไง?”
เพราะในความเป็นจริง เวลาที่เราประชุมกับลูกค้าหรือ Demo งานเสร็จ แน่นอนว่าต้องมีการปรับเปลี่ยน Requirement อยู่เรื่อย ๆ และสิ่งที่ถูกแก้ไขก่อนเสมอคือ โค้ด ส่วนเอกสารมักจะเป็นสิ่งสุดท้ายที่โดนอัปเดต (หรือบางทีก็ถูกลืมไปเลย) จนทำให้เอกสารไม่ตรงกับระบบจริง
คำถามคือ เราต้องมานั่งไล่แก้เอกสารตามทุกครั้งไหม?
จุดนี้คือความน่าทึ่งอีกอย่างหนึ่งของ AI เพราะนอกจากเราจะให้ AI อ่านเอกสารแล้วสรุปเป็น Markdown ได้แล้ว เรายังสามารถสั่งให้ AI เข้าไปอ่านโค้ดใน Repository ที่เพิ่งอัปเดตใหม่ตรง ๆ ได้ด้วย แล้วให้มันช่วยสรุป Logic หรือ Flow การทำงานของฟีเจอร์นั้น ๆ ออกมาเป็นไฟล์ Markdown ฉบับปัจจุบันให้เราทันที
วิธีนี้เข้ามาช่วยปลดล็อก Pain Point สุดท้ายได้อย่างหมดจด ต่อให้เอกสารฝั่ง Text จะไม่อัปเดต เราก็ยังมี AI ที่ช่วยดึงความจริงจากโค้ด (Source of Truth) กลับมาทำเป็นเอกสารที่ตรงกับระบบปัจจุบันได้เสมอ
ทำไมสุดท้ายเอ้ถึงเลือก Astro
พอดึง AI มาช่วยแปลงเอกสาร บทสรุปที่เราได้คือไฟล์ Markdown จำนวน 10–20 ไฟล์ ปัญหาถัดมาคือ จะส่งต่อให้ทีมอ่านยังไง?
การจะให้คนในทีมหรือลูกค้ามานั่งเปิดไฟล์ Markdown ผ่าน VS Code หรือ Markdown Editor มันดูแปลก ๆ และไม่เป็นมิตรกับผู้ใช้อย่างแรง จึงเป็นที่มาที่เราต้องหา Web Framework เข้ามาเปลี่ยนไฟล์พวกนี้ให้กลายเป็นเว็บไซต์
ในรอบนี้มีตัวเต็งที่คิดจะเอามาใช้คือ Docusaurus ซึ่งเป็นตัวยอดฮิตสำหรับสายทำเว็บเอกสารโดยเฉพาะ กับอีกตัวที่ตีตื้นขึ้นมาคือ Astro
เหตุผลหลักที่ใช้ Framework พวกนี้ เพราะมันรองรับไฟล์ Markdown อยู่แล้ว ไม่ต้องเสียเวลาเขียนระบบใหม่เอง แค่โยนไฟล์ลงไปก็ได้หน้าเว็บทันที
แต่ถามว่าทำไมสุดท้ายถึงจบที่ Astro? เหตุผลจริง ๆ แบบไม่ซับซ้อนเลยคือ เพราะหน้าเว็บ Official ของ Astro มันสวยมาก! พอเห็นดีไซน์และโทนของเว็บเขาแล้วรู้สึกอยากใช้ขึ้นมาทันที พอได้ลองจับจริงก็พบว่ามันปรับแต่งง่าย ได้หน้าเว็บที่เบา โหลดเร็ว และไม่ดูเป็นเว็บเอกสารแข็ง ๆ จนเกินไป กลายเป็นศูนย์กลางข้อมูลที่น่าเข้าไปอ่านจริง ๆ
ผลลัพธ์จริงที่ได้
พูดมาเยอะแล้ว ขอเอาของจริงมาเทียบให้ดูกันชัด ๆ นี่คือหน้าแรกของ qa-docs ที่ใช้ตัวของ Framework
Astro Starlight มาช่วยทำเป็นเว็บไซต์รวบรวมเอกสารคู่มือต่างๆ
หลังย้ายมาใช้ Astro ทุกอย่างจัดกลุ่มเป็นหมวดชัดเจน (QA Team Internal / สำหรับลูกค้า / Handover) sidebar อ่านง่าย และหน้าแรกมีการ์ดสรุปแต่ละโปรเจกต์ให้กดเข้าไปได้ทันที นี่คือ “ศูนย์กลาง” ที่เอ้พูดถึงตั้งแต่ต้นบทความ
สิ่งที่เอ้ได้เรียนรู้จากรอบนี้
มาถึงตรงนี้ สิ่งที่เอ้อยากส่งต่อไม่ใช่เรื่องเทคนิคหรือ Prompts ในการสั่ง AI แต่มันคือ วิธีคิดในการนำ AI มาแก้ปัญหาการทำงานจริง
AI เป็นตัวช่วยที่เก่งมากในงาน “อ่าน สรุป และสกัดบริบท” ช่วยลดความซับซ้อน และประหยัดเวลาเราไปได้เยอะมาก แต่สุดท้าย งานตัดสินใจว่าอะไรคือความจริงของระบบ (Single Source of Truth) เราก็ยังต้องเป็นคนเคาะเองอยู่ดี และถ้าเราไม่ปรับพฤติกรรมการทำงานหรือตั้งมาตรฐานการลงข้อมูลร่วมกัน ต่อให้ย้ายไปใช้ Framework ที่ดีแค่ไหน สุดท้ายทุกคนก็กลับไปสร้างเอกสารกระจัดกระจายแบบเดิมอยู่ดี
ถ้าใครกำลังเจอปัญหาเอกสารกระจายไปคนละทิศคนละทาง ลองเริ่มจากถามตัวเองก่อนว่า “อะไรคือศูนย์กลางและบริบทที่เราต้องการจริง ๆ” มองโครงสร้างปัญหาให้ออกก่อน แล้วค่อยเอา AI หรือ Tools เข้ามาช่วย