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

คุณลุงชื่อ พึลึ ครับ

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

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

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

ทางหมู่บ้านกำหนดว่า นักท่องเที่ยว 10 คนต้องมีไกด์ท้องถิ่น 1 คน ตอนที่ผมไป ค่าไกด์อยู่ที่ 350 บาทต่อวัน ใครอยากให้ทิปเพิ่มก็แล้วแต่ความพอใจ และไกด์ไม่ได้แย่งกันรับลูกค้าครับ เขาจัดคิวเรียงกัน ใครถึงคิวก็ได้พานักท่องเที่ยวเข้าไป

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

ส่วนคนทำโฮมสเตย์ก็มีรายได้จากค่าที่พัก และต้องจัดรถไปรับนักท่องเที่ยวจากตัวอำเภออมก๋อยเข้ามาที่หมู่บ้านด้วย บางบ้านอาจแบ่งงานกันในครอบครัว คนหนึ่งดูแลโฮมสเตย์ อีกคนขับรถ อีกคนไปเป็นไกด์

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

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

หลังกลับจากทริป ผมลองไปหาข้อมูลต่อ ดูคลิปรีวิวหลายๆ คลิป รวมถึงคลิปของ Pigkaploy ที่ได้เข้าไปพูดคุยกับคุณลุงพึลึ แล้วเรื่องที่ไกด์เล่าระหว่างทางก็เริ่มชัดขึ้น

คุณลุงอยู่ในป่ามาราว 40 ปี ใช้ชีวิตอยู่คนเดียว เมื่อก่อนแกเลี้ยงแพะไว้ขาย แต่พอเลี้ยงไปนานๆ แพะกลายเป็นเพื่อน แกจึงไม่อยากขายแล้ว เปลี่ยนมาเลี้ยงไว้และเอามูลแพะไปทำปุ๋ย ปลูกต้นไม้ ทำเกษตรของแกต่อไป

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

น้ำตกห้วยน้ำเย็นก็คงเหมือนกัน

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

แล้วมีประโยคหนึ่งที่ผมฟังแล้วรู้สึกจุกอยู่ในใจ

“น้ำตกแห่งนี้ไม่ใช่ของผม แต่เป็นน้ำตกของคนไทยทุกคน”

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

แต่คุณลุงกลับคิดคนละแบบ

แกไม่ได้อยากเก็บน้ำตกไว้ดูคนเดียว ไม่ได้ทำทางเพื่อให้ตัวเองเป็นเจ้าของ และไม่ได้คิดเพียงว่าตัวเองจะมีรายได้เท่าไร แกคิดถึงคนในหมู่บ้าน และคิดไกลไปถึงคนทั้งอำเภออมก๋อยว่า ถ้ามีนักท่องเที่ยวเข้ามา ทุกคนน่าจะมีรายได้เพิ่มขึ้น

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

ซึ่งในคลิปของพลอยคือ 11 เดือนก่อนจากวันที่ผมไป (22 สิงหาคม 2569) ตอนนี้มีห้องน้ำ ลานพักตรงบ้านลุง ลานตรงน้ำตก สะพานบนน้ำตก มากขึ้นอย่างเห็นได้ชัด

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

สิ่งที่ผมเห็นด้วยตาตัวเองในทริป กับสิ่งที่ได้ฟังจากไกด์และจากบทสัมภาษณ์ มันค่อยๆ ต่อกันเป็นภาพเดียว

ทางเส้นหนึ่งที่คนคนเดียวเริ่มทำ กลายเป็นทางที่พารายได้เข้าไปหาคนอีกหลายครอบครัว

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

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

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

มันคือเรื่องของชายสูงวัยคนหนึ่งที่อยู่กลางป่ามาหลายสิบปี เลี้ยงแพะไว้เป็นเพื่อน ใช้มูลแพะทำปุ๋ย และใช้เวลาสิบปีเปิดทางให้คนที่ไม่เคยรู้จักกัน ได้เข้ามาเห็นสิ่งสวยงามที่แกเคยเห็นอยู่คนเดียว

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

ทั้งหมดเริ่มจากความคิดง่ายๆ ของคุณลุงว่า ของสวยๆ แบบนี้ ไม่ควรมีแกได้เห็นอยู่คนเดียว..

ผมชื่นชมและนับถือหัวใจคุณลุงมากครับ

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

น้ำตกห้วยน้ำเย็นสวยจริงครับ แต่สำหรับผม คนที่ทำให้พวกเราได้เข้าไปเห็นน้ำตก งดงามไม่แพ้กันเลย..

ข้อมูลเพิ่มเติม

• Pigkaploy: เปิดเส้นทางน้ำตกห้วยน้ำเย็น ใช้เวลาทำทางถึง 10 ปี
• ข่าวสด: ลุงใช้เวลาเกือบ 10 ปี ทำให้ทุกคนได้เห็นน้ำตกแห่งนี้
• ข้อมูลตำแหน่งและเส้นทางน้ำตกห้วยน้ำเย็น

ต่อให้เราพยายามทำดีกับทุกคนแค่ไหน สุดท้ายก็ยังมีใครบางคนไม่ชอบเรา เข้าใจเราผิด หรือจดจำเราในแบบที่เราไม่อยากให้เป็น เราอาจมองว่าตัวเองกำลังรักษาขอบเขต แต่อีกคนมองว่าเราเห็นแก่ตัว เราอาจพูดตรงเพราะหวังดี แต่อีกคนจำแค่ว่าเราเคยทำให้เขาเสียใจ

ตอนแรกประโยคนี้ฟังดูน่าหดหู่ แต่พอคิดต่อ ผมกลับรู้สึกว่ามันช่วยให้ชีวิตเบาลง เพราะเราไม่จำเป็นต้องใช้เวลาทั้งชีวิตไปกับการแก้บทของตัวเองในหนังสือที่คนอื่นเป็นผู้เขียน ต่อให้แก้เรื่องหนึ่งได้ เดี๋ยวก็มีเรื่องใหม่อีกอยู่ดี เหนื่อยนะครับ 555

เราไม่มีทางเป็นคนดีในทุกเรื่องเล่า

ทุกเหตุการณ์ เรามักเล่าเรื่องจากจุดที่เรายืน เรารู้ว่าตัวเองคิดอะไร ผ่านอะไรมาบ้าง และตัดสินใจเพราะอะไร ในเรื่องที่เราเล่า เราจึงมักเป็นคนที่มีเหตุผล หรืออย่างน้อยก็เป็นคนที่พยายามทำดีที่สุดแล้ว

แต่อีกฝ่ายก็ทำแบบเดียวกัน เขามีข้อมูล ความรู้สึกนึกคิด ความกลัว หรือเรื่องราวสะสมในอดีตของเขา สิ่งที่เรามองว่าเป็นการปกป้องตัวเอง เขาอาจมองว่าเป็นความเย็นชา สิ่งที่เราคิดว่าเป็นการพูดตรง เขาอาจรู้สึกว่าเราไม่ให้เกียรติ หรือวันที่เราต้องเลือกตัวเอง อาจเป็นวันที่เขาจำว่าเราเห็นแก่ตัวก็ได้

ความตั้งใจใดๆ ของเรา อาจไม่ได้สื่อความหมายที่เกิดขึ้นในใจของผู้อื่น

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

ทุกคนล้วนเป็นตัวเอกในชีวิตตนเอง

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

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

เราเป็นตัวเอกในเรื่องของเราได้ แต่ไม่มีทางเป็นตัวเอกในเรื่องของทุกคน

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

แต่คำว่า ช่างมัน ไม่ได้แปลว่าเราจะไม่รับผิดชอบ

แต่ๆ คำว่าใครจะมองเรายังไงก็ช่าง อาจฟังเหมือนการไม่สนใจใคร แต่ผมคิดว่าต้องแยกให้ออกระหว่าง การไม่ยอมให้คำตัดสินของคนอื่นกำหนดคุณค่าของเรา กับ การไม่รับผิดชอบต่อผลของการกระทำ

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

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

รับผิดชอบต่อสิ่งที่เราทำ แต่ไม่ต้องรับภาระในการควบคุมความคิดของทุกคน

เราอาจสับสนระหว่าง พยายามเอาใจทุกคนจนไม่เหลือตัวเอง หรือไม่สนใจความรู้สึกใครเลยแล้วเรียกมันว่าการรักตัวเอง ทั้งสองแบบในความคิดผมคือไม่ดีทั้งคู่ และไม่ใช่สิ่งที่ผมอยากจะเป็น

คุณค่าของเราไม่ควรขึ้นกับความคิดใคร

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

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

คำถามที่น่าถามจึงไม่ใช่ว่า วันนี้ทุกคนมองว่าเราเป็นคนดีหรือยัง แต่เป็นคำถามที่ตรงกว่า

• วันนี้เราทำในสิ่งที่เราเชื่อว่าดีแล้วหรือยัง
• เราซื่อสัตย์กับตัวเองและคนอื่นมากพอหรือยัง
• เมื่อทำผิด เรายอมรับและแก้ไขหรือมันเปล่า
• เรากำลังรักษาขอบเขต หรือแค่ทำร้ายคนอื่นแล้วหาคำอธิบายให้ตัวเอง

ยิ่งรู้จักตัวเอง ยิ่งไม่ต้องอธิบายตัวเองตลอดเวลา

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

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

สิ่งที่มีค่าที่สุด ไม่ใช่การทำให้ทุกคนเชื่อว่าเราเป็นคนดี แต่คือการที่เรารู้ว่าเรากำลังพยายามเป็นคนแบบไหน

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

มาถึงท้ายบทความ

ประโยค We are all bad in someone’s story ไม่ได้ทำให้ผมอยากเป็นคนที่ไม่แคร์ใคร ตรงกันข้าม มันเตือนให้ผมทำดีกับคนอื่นโดยไม่ต้องคาดหวังว่าจะได้รับบทคนดีเสมอในหนังสือเขาก็ได้ และฝึกรับผิดชอบเมื่อทำผิดจริงๆ โดยไม่พยายามไปควบคุมความคิดของทุกคน

เราอาจเป็นคนใจดีในเรื่องหนึ่ง เป็นคนเห็นแก่ตัวในอีกเรื่อง เป็นเพื่อนที่ดีของคนหนึ่ง และเป็นความผิดหวังของอีกคน ทั้งหมดนี้อาจเกิดขึ้นพร้อมกันได้ เพราะมนุษย์ไม่ได้มีตัวตนเพียงเวอร์ชันเดียวในสายตาคนทั้งโลก

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

ถ้าตอบคำถามเหล่านี้ได้ ต่อให้เราเป็นคนเลวในเรื่องราวของใครบางคน อย่างน้อยเราก็ยังไม่หลงออกจากเรื่องราวของตัวเอง..

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

14 สิงหาคม 2569 – ในห้องที่มีแมวส้มย่านอารีย์

นี่เป็นรูปแบบที่ผมคิดว่าน่าสนใจมากสำหรับคนที่ต้องเขียน requirement, product spec, technical spec หรือแม้แต่ working agreement ให้ AI ทำงานด้วย เพราะมันไม่ได้เขียนเป็น requirement แข็งๆ แบบที่เคยทำกันมา หรือแบบเอกสารราชการ แต่ก็ไม่ได้หลวมจน AI หรือคนต้องเดาเองทั้งหมด

บทความนี้เลยอยากลองแกะรูปแบบการเขียนของเอกสารชิ้นนี้ว่า ทำไมมันถึงอ่านง่ายสำหรับคน และยังทำหน้าที่เป็น context engineering สำหรับ AI ได้ดีในเวลาเดียวกัน

หมายเหตุ: บทความนี้เป็นงานเขียนร่วมกันระหว่างผมกับ AI agent โดยอิงจากมุมมองและโจทย์ที่ผมสนใจจริง ส่วนข้อมูลเชิงอ้างอิงนำมาประกอบจากเอกสาร LLM Wiki gist ของ Andrej Karpathy และแหล่งที่มาที่ลิงก์ไว้ท้ายบทความ

เอกสารนี้ไม่ได้บอกแค่ “ต้องทำอะไร” แต่บอกว่า “ทำไมต้องทำ”

จุดแรกที่ผมชอบคือเอกสารไม่ได้เปิดด้วย technical อย่างการบอกโครงสร้าง directory structure, schema, command หรือ implementation detail ทันที แต่เปิดด้วยปัญหาของวิธีเดิมก่อน

Karpathy เริ่มจากภาพที่คนส่วนใหญ่คุ้นเคย คือการใช้ LLM กับเอกสารแบบ RAG หรือการ upload file แล้วให้โมเดลดึง chunk มาตอบคำถาม จากนั้นค่อยชี้ให้เห็นข้อจำกัดว่า วิธีนี้ทำให้ LLM ต้อง rediscover knowledge ใหม่ทุกครั้ง ไม่มีการสะสม ไม่มีการ build up ของความรู้

พอวาง problem แบบนี้แล้ว เขาค่อยเสนอ idea ใหม่ว่า แทนที่จะ retrieve raw document ทุกครั้ง ให้ LLM ค่อยๆ สร้างและ maintain wiki ที่เป็น markdown files อยู่ระหว่างผู้ใช้กับ raw sources

นี่คือ pattern การเขียน requirement ที่ดีมาก คือเริ่มจาก pain ของโลกเดิม แล้วค่อยพาไปสู่ architecture ของโลกใหม่

สำหรับมนุษย์ วิธีนี้ทำให้อ่านแล้วเข้าใจเหตุผล ไม่ใช่แค่รับคำสั่ง ส่วนสำหรับ AI มันทำให้โมเดลเข้าใจ intent ของระบบ ไม่ใช่ทำตาม checklist แบบไม่รู้บริบท

โครงสร้างหลักของเอกสาร

ถ้าแกะเป็นโครง เอกสารนี้มีลำดับที่ค่อนข้างชัดครับ

สิ่งที่น่าสนใจคือมันไม่ได้เป็น spec แบบ sequence เดียวจาก requirement ไป design ไป implementation แต่เป็น “idea file” ที่ค่อยๆ เพิ่มระดับความชัดจาก concept ไปสู่ architecture และ operation

Pattern ใหญ่: Context ก่อน Requirement

ถ้าเขียน requirement แบบเดิม เราอาจเริ่มด้วยประโยคประมาณนี้

ระบบต้องสามารถ ingest เอกสาร, สร้าง wiki page, update index และตอบคำถามจาก wiki ได้

ประโยคนี้ไม่ได้ผิด แต่สำหรับ AI มันยังเปิดช่องให้เดาเยอะมาก เพราะยังไม่รู้ว่า ingest เพื่ออะไร, wiki ต่างจาก raw source อย่างไร, index สำคัญแค่ไหน, และใครเป็นเจ้าของ layer ไหน

เอกสารของ Karpathy ทำอีกแบบ คือให้ context ก่อน แล้ว requirement ค่อยโผล่ออกมาจาก context นั้น เช่นเมื่อเขาบอกว่า raw sources เป็น immutable และเป็น source of truth ส่วน wiki เป็น LLM-generated markdown ที่ LLM owns entirely เราจะเริ่มเข้าใจ rule ตามมาทันทีว่า AI อ่าน raw ได้แต่ไม่ควรแก้ raw, AI แก้ wiki ได้, schema เป็นตัวกำกับ behavior

นี่คือหัวใจของ context engineering ครับ ไม่ใช่ยัด requirement เยอะๆ แต่จัดบริบทให้ AI เห็น mental model ที่ถูกก่อน

โครงภาษาที่ทำให้มนุษย์อ่านง่าย

ในเชิงภาษาศาสตร์ เอกสารนี้มีหลายอย่างที่ทำให้อ่านง่ายมาก แม้จะเป็นเรื่องค่อนข้าง technical

1. ใช้ contrast ชัดเจน

เขาใช้คู่ตรงข้ามซ้ำๆ เช่น RAG แบบเดิมกับ wiki แบบใหม่, raw sources กับ wiki, human กับ LLM, index กับ log, required core กับ optional tools วิธีนี้ช่วยให้ผู้อ่านสร้างแผนที่ในหัวได้เร็ว

2. ใช้ sentence ที่มี thesis ชัด

หลายย่อหน้ามีประโยคแกนกลางที่จับใจความได้ทันที เช่น “the wiki is a persistent, compounding artifact” หรือ “Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.” ประโยคแบบนี้ทำให้ idea จำง่ายและ quote ได้

3. ใช้ metaphor ที่แม่น

การเปรียบ Obsidian เป็น IDE, LLM เป็น programmer และ wiki เป็น codebase ช่วยย้ายเรื่อง knowledge management ที่อาจ abstract ให้กลายเป็นภาพที่ developer เข้าใจทันที

4. ใช้ bullet เพื่อเปิดพื้นที่ของ domain

แทนที่จะอธิบาย use case ยาวๆ เขาใช้ bullet list เช่น personal, research, reading a book, business/team, competitive analysis วิธีนี้ทำให้คนอ่าน map เข้ากับชีวิตตัวเองได้เร็ว

5. ใช้คำกริยาเชิง operation

คำอย่าง ingest, query, lint, update, maintain, file back, append, cross-reference เป็นภาษาที่มนุษย์อ่านแล้วเห็น workflow และ AI อ่านแล้วแปลงเป็น action ได้ง่าย

โครงสร้างแบบ Requirement + Context Engineering

ถ้ามองในมุม requirement engineering เอกสารนี้มีองค์ประกอบที่ครบกว่าที่เห็นตอนอ่านผ่านๆ ครับ

สำหรับ AI นี่คือ context ที่ดีมาก เพราะไม่ได้บอกแค่ output ที่ต้องการ แต่บอก ontology ของระบบด้วยว่ามี object อะไรบ้าง, object แต่ละตัวสัมพันธ์กันอย่างไร, operation หลักคืออะไร, และอะไรเป็น optional

สิ่งที่ทำให้ AI เอาไป implement ได้

เอกสารนี้ไม่ได้ให้ code แต่ AI เอาไป implement ต่อได้ เพราะมันให้ constraint ที่สำคัญครบครับ

• มี layer ชัด raw sources, wiki, schema ทำให้ AI รู้ว่าจะสร้าง folder และไฟล์ประเภทไหน
• มี ownership ชัด raw immutable, wiki LLM-generated, schema co-evolved
• มี workflow verbs ingest, query, lint เอาไปแตกเป็น command หรือ task ได้
• มี artifact names index.md และ log.md ทำให้ implement ได้ทันที
• มี health check criteria contradictions, stale claims, orphan pages, missing cross-references
• มี adaptation boundary บอกว่า abstract และ modular จึงไม่บังคับ implementation เดียว

ถ้า AI อ่านเอกสารนี้แล้วต้องสร้างระบบ มันสามารถ infer ต่อได้ค่อนข้างดีว่าต้องมี directory เช่น raw, wiki, schema, index, log และ workflow สำหรับ ingest/query/lint แม้เอกสารจะไม่ได้ specify exact command ทุกอย่าง

สูตรการเขียนแบบนี้

ถ้าผมจะสรุปเป็นสูตรสำหรับเขียน requirement ที่คนอ่านเข้าใจและ AI เอาไปทำต่อได้ ผมจะใช้โครงนี้ครับ

# Title
One-line description

## Intent
เอกสารนี้ใช้เพื่ออะไร ใครเป็นผู้อ่าน มนุษย์หรือ AI หรือทั้งคู่

## The problem
โลกเดิมทำงานอย่างไร และติดปัญหาอะไร

## The core idea
แนวคิดใหม่คืออะไร ต่างจากเดิมอย่างไร

## Examples / use cases
ใช้กับสถานการณ์ไหนได้บ้าง

## Architecture
มี layer, object, actor, ownership อะไรบ้าง

## Operations
workflow หลักคืออะไร เช่น create, ingest, update, query, lint, approve

## Artifacts
ไฟล์ ตาราง log index หรือ output ที่ต้องมีคืออะไร

## Rules and constraints
อะไรทำได้ อะไรห้ามทำ อะไรต้องขอ approval

## Optional tools
อะไรเป็นตัวช่วย แต่ไม่ใช่ core requirement

## Why this works
ทำไมแนวทางนี้ถึงเหมาะ

## Adaptation note
อะไรต้องปรับตาม domain และอะไรควรคงไว้

โครงนี้ไม่จำเป็นต้องใช้ทุก section ทุกครั้ง แต่ถ้าเป็นงานที่ต้องให้ทั้งคนและ AI เข้าใจร่วมกัน ผมว่ามันเป็น template ที่ดีมาก

ตัวอย่าง rewrite requirement แบบเดิมให้เป็นสไตล์นี้

ลองดู requirement แบบสั้นที่ยังไม่ค่อยมี context ก่อน

ระบบต้องบันทึก requirement และสร้าง traceability ระหว่าง requirement, API, database และ test case

ถ้าเขียนแบบ context-first อาจเปลี่ยนเป็นประมาณนี้

ทีมเรามีปัญหาว่า requirement, API, database change และ test case กระจายอยู่คนละที่ เวลามี change ใหม่ เรามักไม่รู้ว่าต้องแก้ endpoint ไหน table ไหน และ test ไหนตามไปด้วย แนวคิดของระบบนี้คือสร้าง requirement knowledge graph ที่เก็บ change เป็นแกนกลาง แล้วเชื่อม requirement, UX, API, table, field, test และ approval เข้าด้วยกัน เพื่อให้ทั้งคนและ AI ตรวจ impact ได้ก่อนเริ่ม implement

แบบหลังยาวกว่า แต่ AI เข้าใจมากกว่าเยอะ เพราะมันเห็น problem, object, relation และ goal ของระบบพร้อมกัน ไม่ใช่แค่เห็น feature ที่ต้องทำ

Checklist ก่อนส่งเอกสารให้ AI implement

เวลาผมจะเขียนเอกสารแนวนี้ ผมน่าจะใช้ checklist นี้เช็กตัวเองครับ

• คนอ่านรู้ไหมว่าปัญหาเดิมคืออะไร
• มีประโยค core idea ที่จำได้ใน 1-2 บรรทัดไหม
• มี actor และ ownership ชัดไหม
• มี layer หรือ entity หลักครบไหม
• มี operation verbs ที่ AI แปลงเป็น task ได้ไหม
• มี artifact ชัดไหม เช่น file, index, log, schema, report
• มี rule ว่าอะไรห้ามแก้ หรืออะไรต้องขอ approval ไหม
• มีตัวอย่าง use case ให้มนุษย์เห็นภาพไหม
• มี note ว่าอะไร optional และอะไร core ไหม
• อ่านแล้วคนเข้าใจโดยไม่ต้องถามเพิ่ม และ AI มี context พอจะเริ่ม plan ได้ไหม

สรุป

สิ่งที่ผมชอบในเอกสาร LLM Wiki ของ Karpathy คือมันอยู่ตรงกลางระหว่าง essay กับ spec ครับ มันไม่ได้แข็งแบบ requirement document เต็มรูปแบบ แต่ก็ไม่ได้เป็นบทความเล่าไอเดียลอยๆ

มันเขียนให้มนุษย์เข้าใจผ่าน problem, contrast, metaphor และตัวอย่าง แต่ในขณะเดียวกันก็ใส่ architecture, operation, artifact และ constraint พอให้ AI agent เอาไป instantiate ต่อได้

ถ้าต้องเขียน requirement ในยุคที่ AI เป็นคนช่วย implement ผมว่าเราอาจต้องเขียนเอกสารแบบนี้มากขึ้น คือไม่ใช่แค่ “ระบบต้องทำอะไร” แต่ต้องเขียนให้เห็นว่า “โลกนี้ทำงานอย่างไร, ปัญหาอยู่ตรงไหน, object สำคัญคืออะไร, ใครเป็นเจ้าของอะไร, workflow ควรไหลอย่างไร, และอะไรคือกติกาที่ห้ามหลุด”

พูดอีกแบบคือ requirement ที่ดีสำหรับ AI ไม่ใช่ requirement ที่ละเอียดที่สุดเสมอไป แต่คือ requirement ที่จัด context ได้ถูกที่สุดครับ

แหล่งอ้างอิง

• Andrej Karpathy: LLM Wiki gist
• Raw text version of the LLM Wiki gist
• Hacker News discussion: Karpathy LLM Wiki gist

ช่วงแรกๆ ผมก็สั่งเป็นรอบๆ ไปเหมือนกันครับ วันนี้ให้ช่วยแก้ bug พรุ่งนี้ให้ช่วย refactor อีกวันให้ช่วยเขียน test แต่พอใช้ไปนานๆ จะเริ่มเห็น pattern ว่า หลายเรื่องเราสั่งซ้ำๆ อยู่ตลอด เช่น ก่อน push ต้อง test ก่อน, ถ้าตกลง plan แล้วให้ create task เป็น issue, ห้าม merge dev เอง ต้องขอ approve ก่อน

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

หมายเหตุ: บทความนี้เป็นงานเขียนร่วมกันระหว่างผมกับ AI agent โดยอิงจากประสบการณ์ใช้งานจริงของผมเอง ส่วนข้อมูลเชิงอ้างอิงนำมาประกอบจากเอกสารและแหล่งที่มาที่ลิงก์ไว้ท้ายบทความ

Working Agreement กับ AI คืออะไร

ถ้าแปลตรงตัว Working Agreement คือข้อตกลงในการทำงานร่วมกัน ในทีมคน เราอาจตกลงกันว่า pull request ต้องมี review, ต้องเขียน test, ห้าม push เข้า main ตรงๆ หรือถ้างานใหญ่ต้องแตก task ก่อนทำ

พอมาเป็น AI coding agent แนวคิดเดียวกันก็ใช้ได้ครับ เพียงแต่คู่สนทนาของเราเป็น AI ที่อ่าน instruction แล้วพยายามทำตาม ถ้าเราไม่เขียนกติกาไว้ให้ชัด มันก็จะใช้ default behavior ของตัวเอง หรือเดาจาก prompt รอบนั้นๆ

Working Agreement กับ AI คือการเปลี่ยนสิ่งที่เราต้องสั่งซ้ำทุกวัน ให้กลายเป็นกติกาประจำโปรเจกต์

สำหรับผม มันไม่ใช่เรื่องสวยหรูหรือ process หนักๆ แต่เป็น trick เล็กๆ ที่ช่วยลดการหลุด ลดการลืม และทำให้ AI ทำงานใกล้เคียงกับวิธีที่ทีมต้องการมากขึ้น

ทำไมสั่งเป็นรอบๆ แล้ว AI ถึงหลุดง่าย

AI เก่งขึ้นมากก็จริง แต่การคุยแบบ chat มีข้อจำกัดตามธรรมชาติอยู่ครับ เช่น context ยาวขึ้นเรื่อยๆ, session ถูกปิด, prompt รอบใหม่ไม่เหมือนรอบเดิม หรือบางคำสั่งถูกกลืนไปกับรายละเอียดอื่น

ถ้าเราบอกแค่รอบนี้ว่า “ช่วยแก้ให้แล้ว test ด้วยนะ” AI ก็อาจทำตามในรอบนี้ แต่ไม่ได้แปลว่ารอบหน้ามันจะจำได้ว่า project นี้ต้อง test ก่อน push เสมอ หรือห้าม merge เองทุกครั้ง

เอกสารของ Claude Code มีแนวคิดเรื่อง memory files เช่น CLAUDE.md ที่ใช้เก็บ project instructions และบอกด้วยว่าสามารถใช้คำสั่ง /init เพื่อสร้างไฟล์เริ่มต้นจาก project ได้ ส่วน OpenAI Codex ก็มีแนวทางใช้ AGENTS.md เพื่อให้ coding agent รู้กติกา repo เช่น setup, test และ convention ของโปรเจกต์

พอผมเห็นแนวทางนี้แล้ว มันทำให้คิดง่ายขึ้นว่า เราไม่ควรเอากติกาประจำโปรเจกต์ไปซ่อนอยู่ใน chat ชั่วคราว แต่ควรยกมันขึ้นมาเป็นไฟล์หรือ instruction ที่ AI อ่านซ้ำได้ทุกครั้ง

เริ่มง่ายสุด: init project แล้วเขียนกติกาไว้

วิธีที่ง่ายที่สุดสำหรับคนใช้ Claude Code คือเริ่มจาก /init เพื่อให้ Claude อ่าน repo แล้วสร้าง CLAUDE.md เป็น project memory ตั้งต้นก่อน จากนั้นค่อยเติม Working Agreement ของทีมลงไป

/init

สำหรับเครื่องมืออื่น แนวคิดเหมือนกันครับ เช่น Codex ใช้ AGENTS.md, บางทีมใช้ .cursorrules, บางทีมใช้ project instructions หรือ docs เฉพาะของตัวเอง ชื่อไฟล์อาจต่างกัน แต่หน้าที่คล้ายกัน คือบอก AI ว่า “โปรเจกต์นี้ทำงานกันแบบนี้นะ”

อย่าปล่อยให้ rule สำคัญอยู่ในหัวคน หรืออยู่ใน chat รอบเดียว ถ้ามันเป็นกติกาซ้ำๆ ให้เขียนลง project instruction

ควรเขียน Working Agreement อะไรไว้บ้าง

จากที่ผมใช้มา กติกาที่ควรเขียนไว้ไม่จำเป็นต้องเยอะมาก แต่ควรครอบคลุมจุดที่ถ้า AI หลุดแล้วจะกระทบ workflow หรือทำให้ทีมเสียเวลา

ตัวอย่าง CLAUDE.md / AGENTS.md แบบสั้น

ตัวอย่างนี้เป็นแนวทางที่ผมคิดว่าเริ่มใช้ได้ทันที แล้วค่อยปรับตามทีมครับ

# AI Working Agreement

## Goal
ช่วยพัฒนา project นี้แบบปลอดภัย ตรวจสอบได้ และไม่ทำ side effect โดยไม่ขออนุญาต

## Before coding
- ถ้างานเกิน 1 ไฟล์ ให้เสนอ plan สั้นๆ ก่อนแก้
- ถ้า scope ไม่ชัด ให้ถามก่อน ไม่เดาเองในจุดเสี่ยง
- หลังตกลง plan แล้ว ให้สร้างหรืออัปเดต issue/task เสมอ

## Coding rules
- แก้แบบ minimal diff
- ห้าม rewrite ทั้งไฟล์ถ้าไม่จำเป็น
- ทำตาม style เดิมของ repo
- ถ้าเปลี่ยน behavior ต้องเพิ่มหรือแก้ test ที่เกี่ยวข้อง

## Verification
- ก่อนเสนอว่าเสร็จ ต้องรัน targeted test ที่เกี่ยวข้อง
- ถ้าแก้หลายส่วน ให้รัน lint/typecheck ตามที่เหมาะสม
- final response ต้องบอก command ที่รันและผลจริง

## Git safety
- ห้าม merge dev/main/master อัตโนมัติ
- ห้าม push โดยไม่ขอ approve
- ห้ามลบไฟล์หรือ migration สำคัญโดยไม่ถามก่อน

## Output
- สรุป changed files
- สรุป tests ที่รัน
- บอก risk หรือสิ่งที่ยังไม่ได้ verify

แค่นี้ก็ช่วยได้เยอะแล้วครับ เพราะมันเปลี่ยนจากการสั่งซ้ำทุกครั้ง เป็นข้อตกลงที่ AI อ่านก่อนเริ่มงาน

Working Agreement ไม่ใช่ prompt ยาวๆ แต่คือ guardrail

จุดที่ต้องระวังคืออย่าเขียน instruction ยาวจนกลายเป็น manual ที่ไม่มีใครอ่าน ทั้งคนและ AI ควรเขียนให้สั้น ชัด และ actionable

• เขียนเป็น bullet
• แยกหมวดชัดเจน
• ระบุ command ที่ต้องใช้จริง
• แยกสิ่งที่ทำได้เอง กับสิ่งที่ต้องขอ approve
• มี verification rule ทุกงาน

ผมชอบคิดว่ามันคือ guardrail ไม่ใช่ prompt สวยๆ หน้าที่ของมันคือกันไม่ให้ AI หลุดออกจากวิธีทำงานที่ทีมตกลงกันไว้

แยกกติกาเป็น 3 ระดับ

ถ้าใช้จริงในทีม ผมแนะนำให้แยก rule เป็น 3 ระดับ จะดูแลง่ายกว่าเขียนทุกอย่างกองไว้ที่เดียว

การแยกแบบนี้ช่วยให้ rule ที่ถาวรไม่ปนกับรายละเอียดงานชั่วคราว และช่วยลดโอกาสที่ AI จะเอา instruction เฉพาะ task ไปใช้ผิดบริบทในงานอื่น

ตัวอย่าง rule ที่ผมว่าน่าใส่แทบทุก repo

ถ้าจะเริ่มแบบ practical ผมว่าสามารถ copy แนวนี้ไปปรับได้เลยครับ

• ต้อง search ก่อนอ่านไฟล์เยอะๆ เพื่อประหยัด token และลด noise
• ต้องอ่านไฟล์ที่เกี่ยวข้องจริงก่อน patch ห้ามเดา code จากชื่อไฟล์อย่างเดียว
• ต้องเสนอ plan ก่อนงานใหญ่ โดยเฉพาะงานที่แตะหลาย module
• ต้องทำ minimal diff ถ้าไม่ได้สั่ง refactor ใหญ่
• ต้องรัน test ก่อนบอกว่าเสร็จ และรายงาน output จริง
• ห้าม push/merge/delete/migrate โดยไม่ขอ approve
• ถ้า command fail ต้องรายงานตรงๆ ห้ามบอกว่าสำเร็จจากการเดา
• ถ้าเจอ requirement ใหม่ ให้บันทึกเป็น issue/task ไม่ปล่อยหายใน chat

AI ที่เก่งแต่ไม่มี working agreement จะทำงานเร็ว แต่ทีมอาจต้องเสียเวลาตามเก็บทีหลัง

ควรทบทวนกติกานี้เมื่อไร

Working Agreement ไม่ควรเขียนครั้งเดียวแล้วจบครับ เพราะวิธีทำงานของทีมเปลี่ยนได้ตลอด เครื่องมือ AI ก็เปลี่ยนเร็วมากเหมือนกัน

ผมคิดว่าน่าทบทวนเมื่อมีเหตุการณ์พวกนี้

• AI หลุด rule เดิมซ้ำๆ
• ทีมเริ่มใช้ AI agent หลายตัวพร้อมกัน
• มี incident จากการแก้ code โดยไม่ได้ verify
• เปลี่ยน test command หรือ build pipeline
• มีคนใหม่เข้าทีมแล้วใช้ AI ไม่เหมือนคนอื่น
• เริ่มใช้เครื่องมือใหม่ เช่น Claude Code, Codex, Cursor หรือ Gemini CLI

พูดง่ายๆ คือถ้าเป็นบทเรียนที่ไม่อยากให้เกิดซ้ำ ให้ย้ายมันเข้า Working Agreement ครับ

ข้อควรระวัง: อย่าเชื่อว่าเขียน rule แล้ว AI จะไม่พลาดอีกเลย

การมี Working Agreement ช่วยได้มาก แต่ไม่ได้ทำให้ AI กลายเป็นระบบ deterministic 100% ครับ เรายังต้องมี verification, test, review และ approval gate อยู่ดี

โดยเฉพาะ rule ที่มีผลกับ production หรือ source control เช่น merge, push, deploy, migration, delete data อันนี้ไม่ควรปล่อยให้ AI ตัดสินใจเองจาก prompt อย่างเดียว ต้องมี human approval หรือ branch protection ช่วยล็อกอีกชั้น

ผมมองว่า Working Agreement เป็นชั้นแรกที่ช่วยให้ AI ทำถูกทางมากขึ้น ส่วน test, CI, review และ approval เป็นชั้นถัดมาที่ช่วยจับความผิดพลาดก่อนกระทบของจริง

สรุป

หลังจากใช้ AI มาพักใหญ่ ผมเริ่มรู้สึกว่าเราไม่ควรมอง AI เป็นแค่ chatbot ที่สั่งทีละรอบ แต่ควรมองเป็นผู้ช่วยทำงานที่ต้องมี working agreement เหมือนสมาชิกทีมคนหนึ่ง

ถ้ามีเรื่องที่เราต้องสั่งซ้ำๆ เช่น test ก่อน push, create issue หลังตกลง plan, ห้าม merge dev เอง หรือรายงานผล verify ทุกครั้ง ก็ไม่ควรปล่อยให้มันอยู่ในความทรงจำชั่วคราวของ session ครับ เขียนมันลง project instruction ไปเลย

เริ่มจากเล็กๆ ก็พอ เช่นใช้ /init ใน Claude Code เพื่อสร้าง CLAUDE.md แล้วเติมกติกาของทีมลงไป หรือถ้าใช้ Codex ก็ทำ AGENTS.md ใน repo ให้ชัด แค่นี้ก็ช่วยลดการหลุด ลดการสั่งซ้ำ และทำให้ AI ทำงานเข้ากับทีมได้ดีขึ้นมากแล้วครับ

แหล่งอ้างอิง

• Claude Code Docs: How Claude remembers your project
• OpenAI Codex: Custom instructions with AGENTS.md
• AGENTS.md: open format for coding agent instructions
• Augment Code: AI Agent Pre-Merge Verification

คนนี้ว่างเสาร์ อีกคนว่างอาทิตย์ คนนั้นว่างแค่ช่วงเย็น แฟนอีกคนอ่านแล้วลืมตอบ สุดท้ายต้องมีใครสักคนรับบทเป็นเลขากลุ่ม ไล่ถาม ไถอ่าน คอยสรุป แล้วก็วนกลับมาถามซ้ำอีกทีว่า “ตกลงเอาวันไหนดี!” ฮ่าๆ

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

หากอยากลองเล่นเลย กดที่นี่ 👉 https://tamnud.com/

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

อ่ะ ใครอยากรู้รายละเอียดเพิ่มเติม ก็ไปอ่านกันต่อ…

เลือกได้ทั้งนัดเป็นวัน และนัดเป็นเวลา

จุดที่ผมอยากให้มีตั้งแต่แรกคือ ระบบไม่ควรจำกัดแค่การโหวต “วัน” อย่างเดียว เพราะในชีวิตจริง หลายครั้งวันเดียวกันแต่ว่างคนละช่วงเวลาก็มี

MaTamNud เลยมีประเภทนัดให้เลือก 2 แบบ

• นัดเป็นวัน เหมาะกับการเลือกวันแบบกว้างๆ เช่น เสาร์นี้ อาทิตย์หน้า หรือวันหยุดยาว
• นัดเป็นเวลา เหมาะกับนัดที่ต้องรู้ช่วงเวลาชัด เช่น 18:00, 19:30 หรือหลายช่วงเวลาในวันเดียวกัน

ในหน้า create นัด จะมีปฏิทินให้เลือกวัน และถ้าเลือกนัดเป็นเวลา ก็จะมีช่องเลือกเวลาเป็นชั่วโมงและนาที พร้อมปุ่มเพิ่มเวลาได้ ผมว่าอันนี้สำคัญ เพราะหลายงานไม่ได้ต้องการแค่ “วันไหนว่าง” แต่ต้องการรู้ว่า “ช่วงไหนที่ทุกคนชนกันน้อยที่สุด”

วิธีใช้งานแบบเร็วๆ

1. เข้าเว็บ tamnud.com
2. กด สร้างนัดหมาย
3. เลือกประเภทนัดว่าจะเป็นวันหรือเป็นเวลา
4. ใส่ชื่อนัด เช่น “กินข้าววันเกิด”, “ทริปเขาใหญ่”, “ดริ๊งที่อารีย์”
5. เลือกวันหรือช่วงเวลาที่อยากเสนอ
6. ตั้งค่าที่จำเป็น เช่น จำกัดจำนวนคน, ให้เพื่อนเสนอเวลาเองได้, กำหนดปิดโหวต หรือ timezone
7. แชร์ลิงก์หรือรหัสนัดหมายให้เพื่อน
8. ทุกคนเข้ามาโหวต แล้วผู้สร้างนัดค่อยเคาะวันที่ว่างตรงกันมากที่สุด

ฟีเจอร์เล็กๆ ที่ทำให้ใช้กับชีวิตจริงได้

จากที่ลองดูหน้าเว็บและ flow การสร้างนัด มีรายละเอียดบางอย่างที่ผมคิดว่าเหมาะกับการใช้งานจริงมาก

เหมาะกับใครบ้าง

ผมว่า MaTamNud เหมาะกับกลุ่มที่มีปัญหาแบบนี้ครับ

• กลุ่มเพื่อนที่นัดกินข้าวบ่อย ไม่ต้องไล่ถามทีละคนว่าวันไหนว่าง
• แก๊งเที่ยวหรือเดินทาง เลือกวันจัดทริปได้ง่ายขึ้น
• กลุ่มปาร์ตี้หรือสังสรรค์ เห็นวันว่างร่วมกันก่อนจองร้าน
• ทีมงานเล็กๆ ใช้หาช่วงประชุมแบบไม่ต้องเปิด calendar ซับซ้อน
• ครอบครัวหรือญาติๆ เวลานัดกินข้าว นัดรวมตัว หรือไปทำธุระด้วยกัน

โดยเฉพาะกลุ่มที่ไม่ได้อยู่ในระบบ calendar เดียวกัน เช่น เพื่อนคนละบริษัท ญาติคนละบ้าน หรือกลุ่มทริปที่มีคนใช้คนละ platform แบบนี้การส่งลิงก์โหวตง่ายๆ มัก practical กว่ามาก

ต่างจากการถามในแชตยังไง

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

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

สุดท้าย ในฐานะคนทำ

เหมือนตอนที่ผมทำ Kaiten Share Calculator เพื่อแก้ปัญหาแยกบิลซูชิสายพาน ตัวระบบไม่ได้ซับซ้อนมาก แต่ตอบโจทย์สถานการณ์ที่เจอบ่อยจริงๆ และสะท้อนออกมาจากเพื่อนๆใน Internet เข้ามามากกว่าวันละ 500 page views

MaTamNud ก็คล้ายกันครับ ผมไม่พยายามให้มันเป็น calendar หรือระบบ event ใหญ่โต อยากทำเล็กๆ ง่ายๆ แก้ปัญหาเฉพาะจุด คือ “ช่วยให้กลุ่มเห็นวันว่างร่วมกันเร็วขึ้น” ช่วยลดเวลาคุยวนๆ เรื่องวันนัด ซึ่งเป็นปัญหาที่หลายคนเจอแต่ปล่อยให้กลายเป็นความวุ่นวายประจำกลุ่ม

หนึ่งในแนวคิดที่น่าสนใจคือ Open Knowledge Format หรือ OKF จาก Google Cloud ที่เพิ่งเผยแพร่เป็นบทความเมื่อ 13 มิ.ย. ที่ผ่านมานี่เองครับ ซึ่งผมมองว่าแก่นของมันไม่ใช่การสร้าง LLM Wiki ตัวใหม่ แบบของ Karpathy แต่คือการเสนอ ฟอร์แมตกลางสำหรับชุด knowledge/context ให้ AI, agent, data catalog และเครื่องมืออื่นๆ อ่านร่วมกันได้

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพูช่วยกันเรียบเรียงจากเรื่อง Introducing the Open Knowledge Format ของ Google Cloud Blog ที่เล่าถึงหลักการและมุมมองการนำ OKF ไปใช้กับงาน AI / knowledge base

สรุปสั้นๆ ก่อน: OKF คืออะไร

OKF หรือ Open Knowledge Format คือ รูปแบบ specification ที่ Google Cloud เสนอให้ใช้จัดเก็บ “knowledge” ให้อยู่ในรูปที่ทั้งคนและ AI อ่านได้ง่าย โดยใช้หลักการง่ายๆ และวิธีง่ายๆ คือ:

• เก็บข้อมูลความรู้เป็น Markdown file
• กำหนดรูปแบบด้วย YAML frontmatter
• จัดการโครงสร้าง Directory structure
• จัดทำ Markdown links หาเรื่องที่เกี่ยวข้อง
• และมีไฟล์เสริมอย่าง index.md และ log.md เพื่อบันทึกการทำงาน

ถ้าอธิบายแบบบ้านๆ OKF คือการบอกว่า “ถ้าเราจะส่ง knowledge ก้อนหนึ่งให้ AI หรือระบบอื่นเอาไปอ่านต่อ เราควรแพ็กมันเป็นไฟล์แบบไหนดี”

และคำตอบของ Google คือ ไม่ต้องสร้างฐานข้อมูลใหม่ ไม่ต้องมี SDK เฉพาะ ไม่ต้องบีบอัดเป็น format แปลกๆ แต่ให้ใช้ markdown + YAML + link + folder แบบที่คนอ่านก็ได้ เครื่องอ่านก็ดี

ถ้าสังเกตให้ดี LLM Wiki ของ Karpathy ก็ใช้หลักการแบบนี้เช่นกัน แต่แค่มันไม่เคยมีใคร (แม้แต่ Andrej Karpathy) ออกมาบอกว่ามันเป็นสิ่งที่ดีหรือควรเป็นมาตรฐานนะ และคราวนี้ Google เลยออกมาบอกแทน ว่า เออ ทำแบบนี้ก็ดีแล้ว ง่ายๆ ได้ใจความ และขอเสนอเพิ่มเติมนิดหน่อยเพื่อให้มันดีขึ้น ประมาณนั้นครับ

จุดที่ต้องแยกให้ชัด: OKF กับ LLM Wiki ไม่ใช่สิ่งเดียวกัน

เพื่อความกระจ่างขึ้น ขอชี้แจงเพิ่มเติมอีกนิดว่า OKF กับ LLM Wiki มีหน้าตาคล้ายกันมาก เพราะทั้งคู่ใช้ markdown, มี link, มี index, มี log และให้ AI อ่านความรู้ที่คนหรือ agent รวบรวมไว้ แต่บทบาทของสองอย่างนี้ไม่เหมือนกัน

แต่พอคิดดีๆ แล้วมันคนละระดับกัน

LLM Wiki คือ แนวทางหรือระบบการสะสมความรู้ระยะยาว
OKF คือ ฟอร์แมตกลางสำหรับแลกเปลี่ยน knowledge/context บางชนิด

พูดอีกแบบคือ LLM Wiki เป็นเหมือน “คลังความรู้ที่ AI ช่วยดูแล” ส่วน OKF เป็นเหมือน “กล่องมาตรฐานสำหรับแพ็กความรู้บางส่วนให้ส่งต่อได้” และเอาจริงๆ ส่วนตัวผมคิดว่า Google เน้นให้ใช้ในเชิงการเก็บชุดข้อมูล (dateset) และความสัมพันธ์ด้วยซ้ำ เดี๋ยวลองดูจากตัวอย่างด้านล่างได้

ดังนั้น OKF ไม่ได้เกิดมาเพื่อแทน Notion, Obsidian, Wiki หรือ LLM Wiki ทั้งระบบ แต่มันเกิดมาเพื่อแก้ปัญหาว่า dateset หรือ knowledge ที่กระจัดกระจายอยู่ตาม data catalog, schema, runbook, doc, wiki, notebook หรือในหัว senior engineer จะถูกแพ็กให้อยู่ในรูปที่ AI ใช้ได้อย่างไร

ที่มาของ OKF: ปัญหาไม่ใช่ model ไม่เก่ง แต่ context กระจัดกระจาย

ในบทความ Google Cloud เขาเปิดด้วยประเด็นที่ผมเห็นด้วยมาก คือ foundation model เก่งขึ้นเรื่อยๆ แต่พอใช้งานจริง โดยเฉพาะงานแบบ agentic system ปัญหามักไม่ใช่ model ทำไม่ได้ แต่เป็น model ไม่มี context ที่ถูกต้องพอ

ตัวอย่างเช่น ถ้า AI agent ต้องตอบคำถามว่า “จะคำนวณ weekly active users จาก event stream ยังไง” มันไม่ได้ต้องการแค่ SQL syntax แต่มันต้องรู้หลายอย่างพร้อมกัน:

• table ไหนเก็บ event
• field ไหนคือ user id จริง
• business definition ของ active user คืออะไร
• join กับ table ไหนได้บ้าง
• metric นี้เคยเปลี่ยนนิยามหรือไม่
• มี runbook หรือ caveat อะไร
• ข้อมูลนี้ deprecated หรือยัง

ข้อมูลพวกนี้ในองค์กรจริงมักกระจายอยู่หลายที่มาก บางส่วนอยู่ใน data catalog บางส่วนอยู่ใน wiki บางส่วนอยู่ใน code comment บางส่วนอยู่ใน dashboard บางส่วนอยู่ใน ticket และบางส่วนอยู่ในหัวคน

OKF จึงพยายามเสนอ format กลางให้ knowledge เหล่านี้กลายเป็นก้อนที่ส่งต่อได้ อ่านได้ และเชื่อมโยงกันได้

ภาพที่เข้าใจง่าย: producer กับ consumer

ภาพที่เข้าใจง่ายคือ OKF คล้ายกับ NotebookLM, Notion หรือ Obsidian ที่ช่วงหลังเริ่มเชื่อม AI เข้ามาอ่านและสรุปเนื้อหา

ประเด็นสำคัญคือโลกเริ่มแยกเป็นสองฝั่ง:

• Producer คือ คนหรือระบบที่สร้างและเก็บ knowledge
• Consumer คือ AI, agent, app หรือเครื่องมือที่อ่าน knowledge นั้นไปใช้งานต่อ

ปัญหาคือแต่ละแอพมีวิธีเก็บของตัวเอง พอจะย้ายข้ามแอพหรือให้ agent คนละตัวอ่านร่วมกัน ก็ต้องแปลงไปแปลงมา ดังนั้น OKF จึงเข้ามาเสนอว่าอย่างน้อยเราควรมีฟอร์แมตไฟล์กลางที่ทุกฝ่ายเข้าใจร่วมกันได้

OKF หน้าตาเป็นอย่างไร

Google บอกว่า OKF v0.1 แทน knowledge เป็น directory ของ markdown files ที่มี YAML frontmatter กำกับรูปแบบการเก็บ และข้อมูลแต่ละไฟล์คือ concept document หนึ่งเรื่อง

ตัวอย่างแบบง่ายๆ อาจเป็นแบบนี้:

knowledge-bundle/
├── index.md
├── log.md
├── datasets/
│   └── ecommerce.md
├── tables/
│   ├── orders.md
│   └── customers.md
└── metrics/
    └── weekly-active-users.md

และในไฟล์หนึ่งอาจมี frontmatter ประมาณนี้:

---
type: table
title: orders
description: Orders table for ecommerce transactions
resource: bigquery://project.dataset.orders
tags: [ecommerce, transaction, order]
timestamp: 2026-06-13
---

# orders

ตารางนี้เก็บ order transaction ของลูกค้า

## Important fields

| Field | Meaning |
|---|---|
| order_id | unique order identifier |
| customer_id | reference to customers |
| status | order lifecycle status |

## Relationships

- Join with [customers](../tables/customers.md) by `customer_id`
- Used by [weekly-active-users](../metrics/weekly-active-users.md)

สิ่งที่น่าสนใจคือ OKF ไม่ได้บังคับ schema ลึกมาก เขาบังคับพื้นฐานน้อยมาก โดย Google บอกว่าทุก concept ต้องมีอย่างน้อย type ส่วน field อื่นๆ เช่น title, description, resource, tags, timestamp เป็นส่วนที่ช่วยให้ query และ consume ได้ง่ายขึ้น

จากตัวอย่าง ถ้าใครเป็นโปรแกรมเมอร์และทำเรื่อง database มาก่อน จะพอมองภาพออกได้ไม่ยาก

สามหลักการสำคัญของ OKF

1. Minimally opinionated

OKF ไม่ได้พยายามบอกว่าองค์กรต้องมี type อะไรบ้าง หรือแต่ละไฟล์ต้องมี section อะไรบ้าง มันบอกแค่ขอมูลขั้นต่ำที่ทำให้ระบบอื่นอ่านได้ นี่เป็นจุดสำคัญ เพราะถ้ากำหนดมาตรฐานเป๊ะจนเกินไป เราก็อาจจะใช้ยากมาก

2. Producer กับ Consumer แยกจากกัน

ความรู้ก้อนหนึ่งอาจถูกเขียนโดยคน, export จาก metadata catalog, generate จาก LLM, หรือสรุปจากเอกสารเดิม ส่วนคนอ่านอาจเป็น AI agent, search index, visualizer หรือระบบ catalog คนละตัวกัน OKF ทำหน้าที่เป็น contract ระหว่างสองฝั่งนี้

3. Format ไม่ใช่ platform

OKF ไม่ผูกกับ Google Cloud, database, model provider หรือ agent framework ใดๆ สิ่งนี้สำคัญมาก เพราะถ้าจะเป็นฟอร์แมตกลางจริง มันต้องอ่านเขียนได้โดยไม่ต้องมีบัญชีเฉพาะหรือ SDK เฉพาะ

แล้ว OKF เกี่ยวอะไรกับ LLM Wiki

ผมคิดว่า OKF เกี่ยวกับ LLM Wiki ในฐานะ “หยิบ pattern บางอย่างมา formalize” ไม่ใช่ “เอา LLM Wiki ทั้งระบบมาทำเป็นมาตรฐาน”

LLM Wiki ของ Karpathy เน้นแนวคิดว่าเราควรให้ LLM ช่วย build knowledge base แบบสะสมไปเรื่อยๆ จาก source ต่างๆ แล้วเชื่อมโยงเป็น wiki ที่ query ได้ ไม่ต้อง RAG จากศูนย์ทุกครั้ง ผมเคยเขียนเรื่องนี้ไว้ในบทความ LLM Wiki: คลังความรู้ส่วนตัว ตามแบบฉบับของ Karpathy

ส่วน OKF เอารูปแบบที่คล้ายกัน เช่น markdown, frontmatter, link, directory, index, log มาใช้เป็นฟอร์แมตกลางสำหรับ knowledge bundle โดยเฉพาะสำหรับเรื่อง metadata, data catalog, dataset context และความรู้ที่ต้องส่งต่อข้าม tool หรือข้าม agent

OKF เหมาะกับ knowledge แบบไหน

จากที่อ่าน ผมว่า use case ที่ตรงที่สุดของ OKF คือ knowledge ที่มีลักษณะ “เป็น context ให้ AI ใช้ reasoning ต่อ” โดยเฉพาะ knowledge ที่มาเป็นชุด data เช่น

• dataset description
• table schema
• field meaning
• business metric definition
• join path
• runbook
• API deprecation note
• data lineage
• usage guide ของ table หรือ report
• context สำหรับ agent ที่ต้องทำงานกับข้อมูล

ตัวอย่างที่ Google ปล่อยมาก็ไปทางนี้ชัดเจน เช่น enrichment agent ที่เดิน BigQuery dataset แล้วร่าง OKF concept document สำหรับ table และ view จากนั้นใช้ LLM อีกส่วน ไปหา documentation มา enrich ด้วย citation, schema และ join path

เขายังมี static HTML visualizer ที่เปลี่ยน OKF bundle เป็น graph view ได้ในไฟล์เดียว และมี sample bundle เช่น GA4 e-commerce, Stack Overflow, และ Bitcoin public datasets

ตัวอย่างการใช้ในองค์กร

สมมติองค์กรมี data warehouse และมี table ชื่อ orders, customers, events อยู่แล้ว ปัญหาคือคนรู้จริงว่า table ไหนใช้ทำอะไรอาจมีไม่กี่คน และนิยาม business metric อาจอยู่กระจัดกระจาย

ถ้าใช้แนว OKF เราอาจ export หรือเขียน knowledge bundle แบบนี้:

company-data-context/
├── index.md
├── log.md
├── datasets/
│   └── ecommerce.md
├── tables/
│   ├── orders.md
│   ├── customers.md
│   └── events.md
├── metrics/
│   ├── gross-merchandise-value.md
│   └── weekly-active-users.md
└── runbooks/
    └── data-quality-incident.md

พอ agent ต้องเขียน SQL, ตรวจ data quality, อธิบาย dashboard หรือช่วย analyst หา join path มันก็ไม่ได้อ่านแค่ schema ดิบ แต่ได้อ่าน business context ที่ curated แล้วด้วย

นี่คือจุดที่ผมคิดว่า OKF มีประโยชน์มาก เพราะมันไม่ได้พยายามเป็น app ใหม่ แต่มันเป็น format ที่อยู่ตรงกลางระหว่าง data source, documentation, catalog และ AI agent

ถ้าจะเอา OKF มาใช้กับ LLM Wiki ควรทำยังไง

ความเห็นผมตอนนี้คือ ไม่ควรเอา OKF ไปครอบ LLM Wiki ทั้งหมด แต่ควรใช้ OKF เป็น subset หรือ format สำหรับ knowledge บางกลุ่ม

ตัวอย่างเช่น LLM Wiki ส่วนตัวหรือของทีมอาจมีหลายเรื่องมาก:

• บทความที่อ่าน
• paper summary
• project notes
• decision log
• people/company/entity
• research synthesis
• requirement spec
• API/database/UX knowledge

ส่วนที่ควรทำให้ OKF-compatible อาจเป็นเฉพาะส่วนที่ต้องแลกเปลี่ยนกับระบบอื่น เช่น:

• dataset catalog
• API catalog
• data dictionary
• business metric glossary
• requirement knowledge graph
• runbook ที่ agent ต้องใช้ทำงาน

พูดง่ายๆ คือ LLM Wiki เป็นระบบใหญ่ ส่วน OKF เป็น format ที่ช่วยให้บางส่วนของระบบใหญ่ส่งต่อได้ง่ายขึ้น

แล้ว Requirement Spec Center ใช้แนวนี้ได้ไหม

ผมว่าตรงนี้น่าสนใจมาก เพราะช่วงนี้ผมกำลังคิดเรื่อง requirement/spec center ที่ให้ AI ช่วย maintain ความรู้ของระบบ เช่น product, change, API, database, table, field, UX/UI, test case, approval และ release

สำหรับงานแบบนี้ ผมไม่คิดว่า OKF คือคำตอบทั้งหมด แต่แนวคิด OKF เอามาใช้ได้เยอะมาก โดยเฉพาะการทำให้แต่ละ entity เป็น markdown file ที่มี frontmatter และ link ถึงกัน

เช่น change หนึ่งอาจเชื่อมไปหา API, table, field, UX screen, test case และ approval record:

product-change-kb/
├── changes/
│   └── HOME-25Q3-FEA-01.md
├── apis/
│   └── API-HOME-POST-BOOKINGS.md
├── databases/
│   └── HOME/tables/bookings.md
├── ux-ui/
│   └── HOME/booking-form.md
└── tests/
    └── HOME-25Q3-FEA-01-test-case.md

สิ่งนี้ไม่ใช่ OKF ตาม Google ตรงๆ ทั้งหมด แต่มันใช้แนวเดียวกัน คือ knowledge เป็น file, มี metadata, มี link, มี graph และ AI อ่านความสัมพันธ์ได้

และจากที่ผมเอา LLM Wiki มาดัดแปลงเพื่อลองทำ Requirement Spec Center ก็พบว่าคล้ายกับสิ่งที่ OKF กำหนดมาก แต่ก็ยังพบว่าต้องปรับอะไรอีกหลายอย่าง ถ้าจะใช้งานจริงๆ ซึ่ง OKF พอมาเสริมไอเดียได้

ความเห็นส่วนตัวของผม

สิ่งที่ทำให้ OKF น่าสนใจไม่ใช่เพราะมันมีเทคนิคซับซ้อน แต่เพราะมันเรียบง่ายมากจนมีโอกาสถูกใช้จริง

โลก AI ตอนนี้มีปัญหาใหญ่คือทุกคนพยายามสร้าง agent แต่ context ที่ agent ต้องใช้กลับกระจัดกระจายและไม่ portable เท่าไร ถ้าแต่ละองค์กรเริ่มมีวิธีแพ็ก context เป็น markdown bundle ที่มี metadata และ link ชัดเจน AI จะทำงานกับ knowledge ได้ดีขึ้นมาก

แต่ผมก็ยังคิดว่า OKF v0.1 ยังเป็นจุดเริ่มต้นมากๆ ต้องดูต่อว่าจะมี tool, producer, consumer และ adoption จริงแค่ไหน โดยเฉพาะนอก Google Cloud

สำหรับผม takeaway ที่สำคัญที่สุดคือ:

OKF ไม่ได้มาแทน LLM Wiki แต่มาช่วยให้ knowledge บางส่วนของ LLM Wiki หรือ data catalog ถูกแลกเปลี่ยนและใช้งานโดย AI ได้ง่ายขึ้น

ถ้าจะใช้จริง ผมจะเริ่มจาก use case ที่ชัดก่อน เช่น data dictionary, metric glossary, API catalog หรือ requirement traceability แล้วค่อยดูว่าควร เชื่อมโยงกันอย่างไร และนำไปปลั๊กกับ AI อย่างไรต่อ

แหล่งอ้างอิง

• Google Cloud: How the Open Knowledge Format can improve data sharing
• Blognone: กูเกิลเปิดตัว Open Knowledge Format (OKF)
• โพสต์อธิบาย OKF จาก AI กับ Peesamac
• บทความเดิมของผมเรื่อง LLM Wiki ของ Andrej Karpathy

ผมไปอ่านบทความของ Jaroslaw Wasowski เรื่อง How to write specs for AI แล้วรู้สึกว่าตรงกับสิ่งที่ผมทำอยู่ แต่ก็มีบางข้อน่าสนใจที่ผมต้องปรับเพิ่ม โดยเขาพูดตรงๆ ว่า หลายครั้งปัญหาไม่ได้อยู่ที่ model อย่างเดียว แต่อยู่ที่ spec ที่เราเขียนให้มันต่างหาก

เพราะ AI ไม่ได้อ่านใจเราออก ดังนั้นถ้าเราเขียน requirement แบบคลุมเครือ มันก็ไม่ได้หยุดแล้วถามเหมือน senior developer ที่นั่งข้างๆ แต่มันจะเดาต่อจาก pattern ที่มันเคยเห็นมาใน training data แล้วบางทีเดาได้เนียนมาก เนียนจนสรุปออกมา หรือ code ดูเหมือนจะถูกต้อง แต่การใช้งานผิด (เป็นเหตุผลว่าผมต้องมี skill ให้มันตั้งคำถามผมไปเรื่อยๆ นอกจากช่วยคิดแล้ว ผมใช้เพื่อคอยเช็กความเข้าใจของมัน)

หมายเหตุ: บทความนี้อ้างอิงจากประสบการณ์ฟิวส์กับเอเจ้นชมพู เพื่อเรียบเรียงและแปลจากต้นฉบับของ Jaroslaw Wasowski เรื่อง How to write specs for AI: 7 rules and a checklist for better code

ปัญหาไม่ใช่แค่ AI เขียนโค้ดผิด แต่คือมันไม่รู้ว่าอะไรห้ามเดา

ตั้งแต่ปีก่อนที่ vibe code มาใหม่ๆ จนถึงปัจจุบัน เรามักใส่ความต้องการของเราว่าอยากได้อะไร แต่ไม่ได้ใส่ว่ามันห้ามทำอะไร

ซึ่งประโยคที่ผมชอบที่สุดในบทความนี้คือ AI ไม่มีสถานะว่า “อันนี้ไม่แน่ใจ ขอถามเพิ่มก่อน” เวลา requirement ขาดอะไรไป มันจะไม่หยุด และมันจะเติมเอง

สิ่งที่ไม่อยู่ spec เราในตอนแรก แต่จู่ๆ มันก็โผล่มา เพราะ AI จะเอา pattern จาก training data มาเติมแทนเจตนาของเรา (ซึ่งอาจจะผิด)

นี่แหละครับที่น่ากลัว เพราะ code ที่ออกมาอาจ compile ผ่าน, test ผ่าน หน้าตาดูดี แต่จริงๆ มันกำลังทำระบบที่มีการใช้งานหรือ behavior คนละแบบกับที่เราต้องการ

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

Spec ที่ดีต้องปิด 5 เรื่อง ที่ AI ชอบเดาเอง

บทความนี้สรุป 5 เรื่องหลักๆ ซึ่งผมว่าตรงนี้เอาไปใช้กับ Jira ticket, GitHub/GitLab issue, Markdown spec หรือ prompt ตรงๆ ได้เลย

1. Outcome ต้องชัดว่าอยากได้พฤติกรรมอะไร

เริ่มจากบอกผลลัพธ์ที่ต้องการ ไม่ใช่บอกให้มันไปเขียน code แบบกว้างๆ เช่น แทนที่จะบอกว่า “ทำ endpoint export users เป็น CSV” ให้บอกว่า “endpoint นี้ต้องคืน active users เป็นไฟล์ CSV ที่ download ได้” และต้องมีเงื่อนไขความสำเร็จอะไรบ้าง (ภาษาเทคนิคจะเรียกว่า Acceptance Criteria)

จุดนี้ช่วยแยก what ออกจาก how ได้ดีมาก เพราะ AI จะได้ไม่รีบเลือก implementation pattern ที่มันคุ้น แต่เริ่มจาก behavior ที่เราต้องการก่อน

2. Scope กับ non-goals ต้องเขียนคู่กัน

อันนี้ผมว่าเป็นจุดที่หลายคนพลาด รวมถึงผมเองก็เคยและก็ยังพลาดบ่อย เราชอบเขียนว่า change นี้ต้องทำอะไร แต่ไม่ค่อยเขียนว่า change นี้ไม่ต้องทำอะไร

เช่น ถ้าให้ AI ทำ export users ก็ควรบอกไปเลยว่า export เฉพาะ active users เท่านั้น ไม่ export deleted accounts ไม่ export billing data และไม่แก้ database schema

เพราะถ้าไม่บอก มันอาจ “ใจดี” เพิ่ม feature ให้เอง ซึ่งฟังดูดี แต่ทำให้ diff บวม และบางทีไปแตะของที่ไม่ควรแตะ

จากประสบการณ์ผมเองที่สังเกต โมเดลฉลาดๆ อย่าง Claude Opus 4.8+ / ChatGPT 5.5+ มักจะบอกเลยว่า ผมจะทำสิ่งนี้ แต่ไม่ทำสิ่งนี้เพราะจะกระทบอะไรก็ว่าไป ซึ่งมันไม่เป็นกับบางโมเดลอื่นๆ ตรงนี้เราโดนพวก Frontier Model สปอยจนมองข้ามไป ฮ่าๆ

3. Constraints คือรั้วกัน AI หลุดโลก

AI ไม่ได้รู้จัดโค้ดทั้ง repo ของเราจริงๆ ถ้าเราไม่ได้ให้ context มันแต่แรก, มันไม่รู้ว่าใช้ framework เวอร์ชันไหน มี convention อะไร library ไหนห้ามใช้ response format ต้องเป็นแบบไหน หรือ performance limit คือเท่าไร (แต่ก็ได้ยินบ่อยจากคนรอบข้าง (ระดับมหาราชา/มหาราชินี) คือให้ AI อ่านโค้ดทั้ง repo ก่อนเลย)

ดังนั้น constraints ควรมีของพวกนี้:

• stack และ version ที่ใช้
• repo convention ที่ต้องตาม
• library ที่ใช้ได้หรือห้ามใช้
• output format เช่น UTF-8, JSON shape, CSV delimiter
• security หรือ performance limit
• integration boundary เช่นห้ามแก้ schema หรือห้ามกระทบ API เดิม

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

4. Acceptance criteria ต้องพิสูจน์ได้ ไม่ใช่แค่ฟังดูดี

คำว่า “ใช้งานได้ดี” หรือ “make it work nicely” เป็นประโยคที่น่ากลัวมากสำหรับ AI เพราะมันไม่มีทางรู้ว่า nicely ของเราคืออะไร ดังนั้นเราต้องบอกมันว่า เงื่อนไขการรับงาน (Acceptance criteria) ของเราคืออะไร

ซึ่ง Acceptance criteria ที่ดีควรเป็นแบบตรวจสอบได้ เช่น:

• ถ้ามี active users 3 คน ต้องได้ CSV 3 data rows และ header 1 แถว
• ถ้าไม่มี users ต้องได้ header อย่างเดียวและ status 200
• ถ้า user ไม่มี admin role ต้องได้ 403 และไม่ส่ง CSV body
• ถ้ามีข้อมูล 50,000 records ต้องใช้ streaming และ response ไม่เกินเวลาที่กำหนด

ถ้าไม่มีเกณฑ์ตรวจสอบได้ (ไม่ว่าจะมนุษย์ไม่เขียน หรือเอไอไม่ทำให้) ยังถือว่าเป็น Draft Requirement ไม่ใช่ Requirement จริง

เพราะการที่ Spec มี acceptance criteria มันจะเปลี่ยนจากคำอธิบายสวยๆ ให้กลายเป็น Goal ที่ AI ทำให้สำเร็จ และระบบเราจะใช้งานได้ตามที่ต้องการ

5. Edge case กับ failure path ต้องมีตั้งแต่ก่อนเขียน code

Happy path เป็นแค่ส่วนหนึ่งของ production เท่านั้น แต่ spec จำนวนมากเขียนเหมือนโลกมีแต่ happy path ฮาาา

อย่างน้อย spec ที่ส่งให้ AI ควรมี:

• error path 1 กรณี
• edge case 1 กรณี
• empty state หรือ permission case 1 กรณี

เพราะถ้าเราไม่เขียน มันจะเดาวิธี handle error จาก pattern ที่มันเห็นบ่อย ซึ่งอาจไม่ตรงกับระบบเราเลย

Checklist ก่อนโยนงานให้ AI coding agent

ผมลองเอาแนวคิดในบทความมาจัดเป็น checklist table แบบที่น่าจะใช้จริงกับงานประจำวันได้ประมาณนี้ครับ

checklist นี้ไม่ได้บอกให้เขียน spec ยาวเสมอไป แต่มันบอกให้ AI เขียน spec แบบเดาน้อยลง

Spec ไม่ได้ต้องยาว แต่ต้องมี signal พอ

บทความต้นฉบับใช้คำว่า signal redundancy matched to complexity ซึ่งผมแปลแบบบ้านๆ ว่า รายละเอียดต้องพอดีกับความเสี่ยงของงาน

ถ้าแค่แก้ margin หรือเปลี่ยน text เล็กๆ จะเขียน spec ยาว 3 หน้า ก็อาจเกินไป แต่ถ้างานแตะ authorization, payment, data integrity, migration, report export หรือ performance ตรงนี้ผมว่าไม่ควรประหยัด spec

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

Workflow ที่ผมคิดว่าเอาไปใช้ได้ทันที

ถ้าจะเอาเรื่องนี้ไปใช้กับทีม software จริงๆ ผมคิดว่าไม่ต้องเริ่มจาก process ใหญ่โต แต่เริ่มจากงานหนึ่งชิ้นก่อนก็พอ

1. เลือก feature หรือ change ที่มีขอบเขตงานและโค้ดชัดเจน (boundary)
2. เขียน spec ให้มี 5 เรื่องหลัก: outcome, scope, constraints, acceptance criteria, edge cases
3. review spec ก่อนให้ AI ลงมือ
4. ให้ AI implement พร้อม test
5. ถ้า test fail หรือ reviewer ต้องถามเพิ่ม ให้กลับไปแก้ spec ก่อน ไม่ใช่แค่สั่ง AI แก้ code ไปเรื่อยๆ

จุดนี้ผมว่ามันต่อกับแนวคิด Spec-Driven Development มาก คือ spec ไม่ใช่เอกสารประกอบงาน แต่เป็น contract ของงาน ถ้า code กับ spec ขัดกัน ต้องถามก่อนว่า spec ยังถูกไหม ไม่ใช่ปล่อยให้ code ที่ AI generate มาเป็นความจริงใหม่ของระบบ

ข้อสุดท้ายสำคัญมาก และทำให้ Spec มีการอัพเดทตลอดเวลา (หรือที่เรียกว่า Living documentation)

เรื่องที่ต้องระวัง อย่าเอา checklist ไปทำให้ทีมเหนื่อยกว่าเดิม

ถึงผมจะชอบ checklist นี้มาก แต่ก็ไม่คิดว่าต้องใช้เต็มรูปแบบกับทุกงานนะครับ

ถ้าเป็น bug fix เล็กๆ ที่ test เดียวพิสูจน์ได้ หรือ prototype ที่ตั้งใจ throw away อยู่แล้ว การเขียน spec ยาวอาจไม่คุ้ม

อีกอย่างคือ spec ที่ดีไม่ได้แก้ทุกปัญหา AI ยังพลาดได้จาก model limitation, context retrieval ไม่ครบ, repo ใหญ่เกินไป หรือระบบเดิมซับซ้อนจน spec อธิบายไม่หมด

ดังนั้นอย่าใช้ checklist นี้เป็นพิธีกรรมใหม่ของทีม แต่ใช้เป็นเครื่องมือถามตัวเองว่า “งานนี้มีอะไรที่ AI ไม่ควรเดาเองบ้าง”

สรุปแบบฟิวส์ๆ

สิ่งที่ผมได้จากบทความนี้คือ AI ไม่ได้ทำให้ requirement หายไป แต่มันทำให้ requirement ที่คลุมเครือส่งผลแรงขึ้นกว่าเดิม

เมื่อก่อนถ้า requirement คลุมเครือ senior developer อาจถามกลับ หรืออย่างน้อยก็รู้จาก context ของระบบว่าอะไรควรทำไม่ควรทำ แต่ AI coding agent ไม่ทำแบบนั้น ถ้าเราไม่บอก มันจะเดา

และบางครั้งมันเดาแบบมั่นใจมากด้วยว่าจะถูก!

ยิ่ง AI เขียน code เร็วเท่าไร เราก็ยิ่งต้องเขียนให้ชัดขึ้นเท่านั้นครับ

แหล่งอ้างอิง

• How to write specs for AI: 7 rules and a checklist for better code โดย Jaroslaw Wasowski, Level Up Coding

แนวคิดที่ Anthropic ยกมาคือ ให้ Sonnet 5 เป็น executor ทำงานหลักใน loop ปกติ แล้วให้ Fable 5 เป็น advisor ที่ถูกเรียกเฉพาะตอนต้องใช้ judgment สูง เช่น วางแผน ตัดสินใจ architecture แก้ทางเมื่อเริ่มหลุด หรือ review ก่อนจบงาน ผมว่ามันเป็น pattern ที่ practical มาก เพราะมันไม่ได้พยายามลดคุณภาพด้วยการใช้โมเดลเล็กอย่างเดียว แต่ใช้โมเดลฉลาดให้ถูกจังหวะมากกว่า

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพูช่วยกันเรียบเรียง โดยอิงจากโพสต์ของ ClaudeDevs บน X, เอกสาร Advisor tool ของ Anthropic และ Claude Cookbook แล้วนำมาตีความเป็นแนวทางใช้งานจริงสำหรับคนทำ AI agent / coding agent

ต้นทางของเรื่องนี้สรุปไว้สั้นมากว่า หนึ่งใน pattern ที่ Anthropic ใช้กับ Fable 5 คือ “ใช้ Fable 5 เป็น advisor” โดย executor อย่าง Sonnet 5 จะเรียก Fable 5 เพื่อขอคำแนะนำ ดังนั้นการทำงานส่วนใหญ่จะใช้ token ไปกับ executor ที่ Sonnet 5 ทำมากกว่า

ต้องเข้าใจก่อนว่า agent workload ไม่ต้องใช้โมเดลฉลาดทุกงาน

เวลาพูดถึง AI coding agent หรือ agent ที่ทำงานหลาย step ผมคิดว่าหลายคนมักติดกับดักว่า “ใช้โมเดลฉลาดสุดไปเลยจะได้จบ” ซึ่งจริงในบางงาน แต่ไม่จริงเสมอไป โดยเฉพาะงานยาวๆ ที่มี token จำนวนมากถูกใช้ไปกับงาน mechanical มากกว่า reasoning

ในงานหนึ่งๆ มักมี 2 ส่วนปนกัน:

• ส่วนที่ต้องคิดจริง: แตกโจทย์, ตีความ requirement, เลือก architecture, ประเมิน trade-off, หาทางออกตอนติดปัญหา
• ส่วนที่ต้องทำเยอะ: อ่านไฟล์, อ่านเว็บ, grep โค้ด, ดู log, แก้ไฟล์, รัน test, สรุป output จาก tool

ถ้าใช้โมเดลระดับ frontier ทำทั้งสองส่วนทั้งหมด ก็โครตจะเปลือง token เลยครับ เพราะถูกใช้ไปกับงานทั่วไปที่ไม่ต้องการ frontier reasoning ทุกบรรทัด เช่น อ่านหน้าเว็บยาวๆ หรือไล่ log หลายพันบรรทัด ตรงนี้เองที่ทำให้ค่าใช้จ่ายสูงโดยไม่จำเป็น

ผมขอเปรียบให้เห็นภาพง่ายๆ เหมือนเอา senior engineer ไปนั่งอ่าน log ทุกบรรทัดเอง ซึ่งงานเขาควรเข้ามาตอนวางทิศทาง ตรวจจุดเสี่ยง หรือช่วยตัดสินใจเรื่องที่ถ้าผิดแล้วจะเสียเวลาเยอะ ส่วนงานอ่าน/เก็บข้อมูล/ทำตามขั้นตอนให้คนที่เร็วกว่าและต้นทุนต่ำกว่าช่วยทำได้

หรือเทียบในงานก่อสร้าง ก็เหมือนเอาวิศะไปก่ออิฐฉาบปูนแทนคนงานก่อสร้าง แทนที่วิศวะจะออกแบบ วางแผน และคนงานจะเป็นคนทำ

เแนวคิด: Sonnet 5 เป็นคนทำงานหลัก ส่วน Fable 5 เป็นคนให้คำปรึกษา

จาก diagram ในโพสต์ของ ClaudeDevs โครงสร้างคือ Sonnet 5 ทำหน้าที่ executor และรัน main loop ทุก turn ส่วน Fable 5 เป็น advisor ที่ถูกเรียกผ่าน tool call เฉพาะเมื่อจำเป็น พูดง่ายๆ คือ Sonnet ทำงานหนัก แต่ Fable ช่วยคิดตอนที่ต้องคิดอย่างมีเหตุมีผล

เอกสาร Advisor tool ของ Anthropic อธิบายแนวคิดนี้ว่า executor model ที่เร็วกว่า/ต้นทุนต่ำกว่า สามารถ consult advisor model ที่ฉลาดกว่า mid-generation ได้ โดย advisor จะเห็น conversation transcript ทั้งหมด แล้วส่งคำแนะนำกลับมาให้ executor ทำงานต่อ

จุดที่ผมว่าสำคัญคือ advisor ไม่ได้มาแทน executor แต่เป็นเหมือน reviewer หรือ architect ที่ถูกเรียกในจังหวะที่ควรเรียก ทำให้เรายังได้คุณภาพจากโมเดลใหญ่ในการตัดสินใจสำคัญๆ แต่ไม่ต้องจ่ายราคาโมเดลใหญ่กับทุกการทำงานง่ายๆ หลายงาน

แล้ว Advisor tool ทำงานยังไง?

เมื่อเราเพิ่ม advisor tool เข้าไปใน tools array แล้ว ตัว executor จะตัดสินใจเองว่าจะเรียก advisor เมื่อไรเหมือน tool อื่นๆ แต่การ call นี้เกิดฝั่ง server ภายใน request เดียว ไม่ใช่ client ต้อง orchestration เองหลายรอบ

• executor สร้าง server_tool_use ชื่อ advisor
• server ส่ง transcript ทั้งหมดให้ advisor model
• advisor ส่งคำแนะนำกลับมาเป็น advisor_tool_result
• executor ใช้คำแนะนำนี้ทำงานต่อจนจบ

ตัวอย่างแบบย่อจากเอกสาร Anthropic:

client = anthropic.Anthropic()

response = client.beta.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=4096,
    betas=["advisor-tool-2026-03-01"],
    tools=[
        {
            "type": "advisor_20260301",
            "name": "advisor",
            "model": "claude-opus-4-8",
        }
    ],
    messages=[
        {
            "role": "user",
            "content": "Build a concurrent worker pool in Go with graceful shutdown.",
        }
    ],
)

ถ้านำ concept นี้มาเทียบกับโพสต์ Fable 5 ภาพในหัวจะประมาณนี้:

tools=[
    {
        "type": "advisor_20260301",
        "name": "advisor",
        "model": "claude-fable-5",
        "max_tokens": 2048,
        "max_uses": 2,
    }
]

ตรงนี้ max_tokens กับ max_uses สำคัญมาก เพราะถ้าเปิด advisor ไว้แบบไม่จำกัด มันอาจกลายเป็น “เรียกโมเดลแพงบ่อยขึ้น” แทนที่จะช่วยประหยัด token

วิธีใช้ให้ประหยัด token จริง

1. ให้ executor อ่านบริบทก่อน แล้วค่อยเรียก advisor

ผมคิดว่าเราไม่ควรเรียก Fable 5 ตั้งแต่ครั้งแรกที่ยังไม่รู้อะไรเลย เพราะคำแนะนำจะกว้างเกินไป วิธีที่ดีกว่าคือให้ Sonnet 5 อ่านทำความเข้าใจบริบทแรกของเราก่อน เช่น requirement, โครง repo, error log หรือไฟล์หลัก แล้วค่อยเรียก Fable 5 เพื่อช่วยวางแผน

2. ใช้ advisor ในจุดที่ตัดสินใจผิดแล้วแพง

จุดที่คุ้มจะเรียก advisor คือจุดที่ถ้าคิดผิดแล้วต้องแก้งานเยอะ เช่น:

• เลือก architecture หรือ migration strategy
• ตีความ requirement ที่กำกวม
• เจอ test fail ซ้ำๆ แล้วแนวทางเดิมแก้ไม่ได้ หรือไม่ครอบคลุม
• ก่อนจบงาน เพื่อ review ว่าหลุด security, edge case หรือ test อะไรไหม

3. จำกัดจำนวนครั้งด้วย max_uses

ถ้างานหนึ่งควรเรียก advisor แค่ 1–2 ครั้ง ก็ตั้ง max_uses ไว้เลย จะช่วยไม่ให้ executor เรียก advisor ถี่เกินไปใน request เดียว

4. จำกัดคำตอบของ advisor ด้วย max_tokens

เอกสาร Anthropic แนะนำจุดเริ่มต้นที่ max_tokens: 2048 สำหรับ advisor output cap โดยระบุว่าในการทดสอบของเขา การตั้ง cap นี้ลด output ของ advisor ได้มากเมื่อเทียบกับการไม่ตั้ง และยังไม่เห็นว่าคุณภาพลดลงเท่าไรอย่างชัดเจน (quality degradation) แต่ประโยคสำคัญคือ เราต้องตรวจสอบกับ workload ของตัวเองเสมอนะ เพื่อป้องกันความผิดพลาด เนื่องจากจำกัด token (ผมเคยเจอบ่อยว่า output งานออกมาได้ไม่ถูกต้อง หรือโค้ดไม่ครบ)

5. เปิด caching เฉพาะงานที่เรียก advisor หลายครั้ง

ใน docs ระบุว่า advisor-side caching จะเริ่มคุ้มเมื่อคาดว่าจะมี advisor call ประมาณ 3 ครั้งขึ้นไปใน conversation เดียว ถ้างานสั้นๆ เรียกครั้งเดียวหรือสองครั้ง การเปิด cache อาจไม่คุ้ม เพราะ cache write ก็มีต้นทุนของมันเอง

อีกแนวคิดที่คล้ายกัน คือ Plan big, execute small

ใน Claude Cookbook เรื่อง Coordinator pattern Anthropic อธิบายอีก pattern ที่คล้ายกันมาก คือให้โมเดลใหญ่เป็น coordinator สำหรับวางแผนและสังเคราะห์คำตอบ ส่วน worker model ที่ถูกกว่าเป็นคนอ่านเว็บหรือดึงข้อมูลจำนวนมากใน context ของตัวเอง

ในการทดลองที่ Anthropic ยกตัวอย่าง ทีมแบบ split ราคาจะถูกลงกว่าประมาณ 2.5x และทำงานเร็วขึ้นประมาณ 3x โดยจำนวน input token 84–98% ถูกคิดที่ worker ที่ใช้ราคา Token ถูกกว่า

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

แต่โครงสร้างวิธีการทำแบบนี้ก็ชัดเจนดี คือ งานอ่านเยอะๆ ให้ worker ทำ ส่วนโมเดลใหญ่แตะเฉพาะ planning/synthesis

จากที่อ่าน ถ้าผมจะใช้จริง จะวาง flow แบบนี้

1. เริ่มด้วย Sonnet 5: ให้ทำงานหลัก อ่านไฟล์ เรียก tool แก้โค้ด รัน test
2. Orientation: เก็บบริบทขั้นต่ำก่อน เช่น requirement, repo structure, error หลัก
3. Advisor call แรก: เรียก Fable 5 ให้ช่วยวางแผนและชี้ risk
4. Execute: ให้ Sonnet 5 ลงมือทำตาม plan โดยไม่เรียก advisor ทุกจุด
5. Replan เมื่อจำเป็น: ถ้า error วนหรือทางเดิมไม่ไปต่อ ค่อยเรียก Fable 5 อีกครั้ง
6. Review ก่อนจบ: เรียก advisor ช่วยดูว่าตกหล่น test, security, edge case หรือ assumption อะไรไหม
7. Finish: ให้ executor สรุปผลพร้อม evidence จาก test/diff/tool output

ต้องบอกว่า ผมยังแค่คิดนะ เพราะยังไม่มีโจทย์ซับซ้อนพอที่จะใช้ Fable ทำงาน และยังไม่อยากลองรันเทียบ เพราะต้องทำหลายครั้ง อาจจะเสีย Token เยอะ ฮาา, ไว้รอมีผลการทดสอบจากผู้กล้า หรือได้ลองจริงๆ แล้วจะเอามาเล่าให้ฟังอีกที หรือหากใครลองแล้วก็มาแชร์กันหน่อยครับ

ข้อควรระวัง

• งานเล็กมากอาจไม่คุ้ม: ถ้าเป็น single-turn Q&A หรือแก้ typo เล็กๆ advisor อาจเพิ่ม overhead มากกว่าประโยชน์
• ต้องวัดกับ workload จริง: ตัวเลขประหยัด token ไม่ใช่ค่าคงที่ ขึ้นกับชนิดงานและความยาวของ context
• อย่าแตกงานย่อยจนเกินพอดี: ใน cookbook เองก็เตือนว่าการแตก brief แคบเกินไปมี floor cost ของ worker thread (ขออธิบายเพิ่มเติมครับ: มันคือต้นทุนขั้นต่ำต่อ worker thread หมายถึง ทุกครั้งที่สร้าง worker หรือ sub-agent ใหม่ มันมี “ต้นทุนตั้งต้น” เสมอ ไม่ว่าจะงานเล็กหรือใหญ่ เช่น เปิด session ,รับ prompt, อ่าน context, เรียก Skill)
• advisor แก้โจทย์เท่าที่ได้รับจาก context: ถ้า executor ยังไม่ได้อ่านของสำคัญก่อนเรียก advisor คำแนะนำก็อาจกว้างหรือผิดทิศได้ เช่นเราใส่บริบทไม่ครบหรือไม่เข้าใจให้ advisor เองแต่แรก (นั่นคือเหตุผลของ Anthopic ว่าทำไมไม่ควรเอาตัวฉลาดมารับงานก่อน)
• ต้อง track cost แยก: usage ของ advisor อยู่ใน usage.iterations เป็น advisor_message เพราะถูก bill คนละ rate กับ executor

ผมขอขยายความข้อสุดท้ายนิดนึงคือ มันไม่สามารถคิด token cost แบบ usage.input_tokens + usage.output_tokens ทั่วไปนะ เพราะอาจจะเข้าใจผิดคิดว่าแพงทั้งหมด แต่ควรคิดจาก

total_cost = executor_tokens × ราคา Sonnet 5 + advisor_tokens × ราคา Fable 5

ดังนั้น ใน Anthropic API ที่ส่งค่า usage.iterations กลับมา เราต้องคิดราคาแยกตาม type ด้วย ว่าอะไรคือ executor (message) และอะไรคือ advisor (advisor_message)

สรุป

ผมคิดว่า “Fable 5 เป็น advisor” เป็นแนวทางที่น่าลองมากสำหรับ agent workflow ที่เราจะให้มันทำงานยากๆ หรือต้องใช้การตัดสินใจอย่างมีเหตุมีผลสูงมาก ส่วนงานง่ายๆ อย่างการ อ่าน/ทำ/ตรวจซ้ำ ก็ให้ใช้โมเดลรองๆ ลงมา ทำก็คิดว่าเพียงพอแล้ว (อย่างน้องชมพูที่ผมให้แชต ก็ใช้แค่ ChatGPT mini แต่หาข้อมูลและเขียนบทความ ผมจะใช้ ChatGPT ปกติ

อ้างอิง

• ClaudeDevs on X — Fable 5 as advisor pattern
• Anthropic Claude Platform Docs — Advisor tool
• Anthropic Claude Cookbooks — Coordinator pattern: big models for planning, small models for execution

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

ผมเลยอยากเอาบทความนี้มาเล่าในมุมที่นำไปต่อยอดได้จริง โดยเฉพาะสำหรับคนที่กำลังสนใจเรื่อง AI Agent, coding agent, workflow automation หรือระบบที่ให้ AI ทำงานต่อเนื่องแทนการ prompt ทีละครั้ง

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงและต่อยอดจากบทความต้นฉบับของ Anthropic Engineering เรื่อง Harness design for long-running application development เขียนโดย Prithvi Rajasekaran

Harness คืออะไรในบริบทของ AI Agent

ถ้าแปลแบบง่ายๆ harness คือชุดเครื่องมือที่หุ้ม AI Agent อีกทีเพื่อให้มันทำงานได้เป็นระบบ ไม่ใช่แค่โยน prompt ให้ model แล้วหวังว่ามันจะทำทุกอย่างถูกต้องเอง

ซึ่งในโลกของการเขียนโปรแกรม เรามักคุ้นกับ test harness หรือ automation harness อยู่แล้ว คือชุดเครื่องมือที่ช่วยรัน ทดสอบ ตรวจผล และคุมการทำงานบางอย่างให้เป็นระบบ พอมาอยู่ในโลกของ AI Agent แนวคิดก็คล้ายกัน แต่ขยายใหญ่กว่าเดิม

Harness ของ AI Agent อาจรวมหลายอย่าง เช่น

• วิธีแตกงานใหญ่ให้เล็กลง
• วิธีให้ agent วางแผนก่อนลงมือทำ
• วิธีเก็บ state ของงานไว้นอก context window
• วิธีส่งต่องานระหว่าง agent หรือ session
• วิธีตรวจคุณภาพของงานที่ทำเสร็จ
• วิธีบังคับให้ agent แก้ไขงานตาม feedback
• วิธีหยุดงานเมื่อถึงเงื่อนไขบางอย่าง

พูดอีกแบบคือ ถ้า model คือสมอง harness ก็คือระบบการทำงานรอบสมองนั้น

และผมคิดว่านี่แหละคือประเด็นสำคัญมาก เพราะช่วงแรกๆ เรามักคิดกันว่า AI จะเก่งขึ้นเพราะ model ฉลาดขึ้นอย่างเดียว แต่พอเริ่มใช้งานจริงจะเห็นว่า model ที่เก่งมากๆ ถ้าไม่มีระบบคุมงานที่ดี ก็ยังหลุด ยังลืม ยังทำงานซ้ำ ยังประเมินตัวเองผิด และยังจบงานแบบไม่ครบได้เหมือนกัน

จริงๆ ลองทดสอบได้ง่ายๆ ครับ ถ้าเอา prompt ใส่ใน Claude Web ตั้งโมเดลเป็น Opus 4.8 กับใส่ในระบบแชตแจกฟรีเช่น Langflow โดยต่อโมเดล Opus 4.8 ผ่าน Claude API, คำตอบที่ได้ออกมาจะไม่เหมือนกัน แม้ว่าใช้สมอง Opus 4.8 เหมือนกัน (เรื่องนี้ 9arm ก็มีเล่าให้ฟังตอนทำ 9arm AI Passport)

ปัญหาของ Agent ที่ให้ทำงานยาวๆ

บทความนี้เริ่มจากโจทย์ที่ Anthropic ทดลองอยู่ 2 เรื่อง คือทำให้ Claude สร้าง frontend design ที่มีคุณภาพสูงขึ้น และทำให้ Claude สร้าง application เต็มรูปแบบได้โดยไม่ต้องมีมนุษย์เข้าไปช่วยระหว่างทาง

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

1. Context เต็มแล้วเริ่มหลุด

งานที่ยาวหลายชั่วโมงจะมีข้อมูลสะสมเยอะมาก ตั้งแต่ requirement, decision, bug, code, test result, feedback ไปจนถึงสิ่งที่ลองแล้วไม่เวิร์ก ถ้าทุกอย่างถูกกองอยู่ใน context window เดียว สุดท้าย agent จะเริ่มจับประเด็นไม่ครบ

Anthropic ยังพูดถึงอาการที่น่าสนใจชื่อว่า context anxiety คือ model เริ่มเหมือนรู้ตัวว่าบริบทใกล้เต็ม แล้วพยายามรีบ wrap up งานก่อนเวลา ทั้งที่งานจริงยังไม่เสร็จดี

ปัญหานี้ผมว่าคนที่ใช้ coding agent น่าจะเจอบ่อย บางทีมันทำงานดีมาตลอด แต่พอท้ายๆ เริ่มสรุปเองว่าทุกอย่างเรียบร้อย ทั้งที่ test ยังไม่ครบ หรือยังมี TODO ค้างอยู่

2. Agent มักตรวจงานตัวเองใจดีเกินไป

อีกปัญหาหนึ่งที่ตรงมากคือ self-evaluation

เวลาถาม agent ว่างานที่ตัวเองทำดีไหม มันมักตอบว่าดี ใช้ได้ พร้อมแล้ว หรือใกล้เสร็จแล้ว ทั้งที่ถ้ามนุษย์ลองใช้งานจริงอาจเห็นเลยว่ามีหลายจุดยังไม่ดีพอ

งาน coding ยังพอมี test ช่วยจับได้บ้าง แต่งานอย่าง design, UX, product completeness หรือบทความนี่ตรวจยากกว่าเยอะ เพราะไม่มีคำตอบแบบ pass/fail ชัดเจน

Anthropic เลยใช้แนวทางแยก agent ที่สร้างงาน ออกจาก agent ที่ตรวจงาน ซึ่งผมคิดว่าเป็น pattern ที่ควรใช้จริงในระบบ agent ที่ต้องการคุณภาพ

แนวคิดหลัก: Planner, Generator, Evaluator

โครงสร้างที่บทความนี้พูดถึงคือการแบ่ง agent ออกเป็น 3 บทบาทหลัก

ถ้ามองในเชิงทีมซอฟต์แวร์ มันก็คล้ายๆ การแยก role ในทีมจริง

• Planner ทำหน้าที่คล้าย product/tech lead
• Generator ทำหน้าที่คล้าย developer
• Evaluator ทำหน้าที่คล้าย QA, reviewer และ product tester

ข้อดีคือเราไม่ต้องหวังให้ agent ตัวเดียวทำทุกอย่างเก่งหมด เพราะในความเป็นจริง มนุษย์เองก็ยังไม่ค่อยทำงานแบบนั้น เรามีคนคิด คนทำ คนตรวจ และ feedback loop ที่ทำให้งานดีขึ้น

ทำเรื่อง subjective ให้ตรวจได้

ส่วนที่ผมชอบมากในบทความคือการทดลองกับ frontend design เพราะ design เป็นเรื่องที่วัดยาก

Anthropic พบว่า Claude มักสร้าง UI ที่ technically ใช้งานได้ แต่ดู generic มาก เช่น layout ปลอดภัย card เยอะๆ gradient เดิมๆ หรือหน้าตาที่ดูเหมือน AI สร้างแบบไม่มี character

เขาเลยสร้าง evaluator ที่มี criteria ชัดเจน เช่น

• Design quality งานดูเป็นภาพรวมเดียวกันไหม
• Originality มีความคิดสร้างสรรค์จริงไหม หรือเป็น template
• Craft typography, spacing, contrast, color harmony ดีไหม
• Functionality ผู้ใช้เข้าใจและใช้งานได้จริงไหม

จุดสำคัญคือเขาไม่ได้ถามกว้างๆ ว่า “สวยไหม” แต่แตกคำว่าสวยให้กลายเป็น rubric ที่ตรวจได้

ผมว่านี่เอาไปใช้กับงานอื่นได้เยอะมาก เช่นบทความดีไหม requirement ชัดไหม dashboard ใช้งานง่ายไหม หรือแม้แต่ระบบ automation ที่ agent สร้างขึ้นมามี failure mode อะไรบ้าง ถ้าเราไม่มี rubric evaluator ก็จะตอบกว้างๆ และหลุดง่าย

Context Reset ไม่ใช่แค่ล้างแชท แต่ต้องมี Handoff

อีกเรื่องที่สำคัญมากคือ structured handoff

ถ้า agent ทำงานยาวจนต้องเริ่ม session ใหม่ หรือให้ agent ตัวใหม่มารับช่วงต่อ เราไม่ควรส่งต่อด้วย chat history ยาวๆ อย่างเดียว แต่ควรมี artifact ที่สรุปสถานะงานอย่างเป็นระบบ

handoff ที่ดีควรบอกอย่างน้อยว่า

• เป้าหมายของงานคืออะไร
• ทำอะไรเสร็จแล้ว
• ไฟล์ไหนถูกแก้
• คำสั่งไหนรันแล้ว
• ผลลัพธ์จริงคืออะไร
• ยังเหลือปัญหาอะไร
• next step คืออะไร

ถ้าเป็นงาน coding ก็ควรมี test result, git diff, known issue และคำอธิบาย decision ที่สำคัญด้วย

ในมุมผม นี่คือจุดที่ทำให้ agent system เริ่มจริงจังขึ้นมาก เพราะเราเริ่มย้าย source of truth จาก “บทสนทนา” ไปอยู่ใน “artifact” ที่อ่านซ้ำได้ ตรวจได้ และส่งต่อได้

Sprint Contract: ก่อนทำ ต้องรู้ก่อนว่า Done คืออะไร

อีกไอเดียที่น่าสนใจคือก่อนแต่ละ sprint ให้ Generator และ Evaluator ตกลงกันก่อนว่า sprint นี้จะทำอะไร และจะตรวจยังไงถึงเรียกว่าสำเร็จ

ผมมองว่านี่คือ acceptance criteria สำหรับ agent โดยเฉพาะ

ถ้าให้ agent “สร้างระบบ task management” เฉยๆ มันอาจทำหน้าจอสวย แต่ข้อมูลไม่ persist หรือ filter ใช้ไม่ได้ แต่ถ้ามี sprint contract เช่น

• สร้าง task ได้
• แก้สถานะ task ได้
• filter ตาม status ได้
• refresh แล้วข้อมูลยังอยู่
• Evaluator ต้องทดสอบผ่าน browser จริง

แบบนี้งานจะตรวจได้ชัดขึ้นมาก และลดโอกาสที่ agent จะทำ feature แบบดูเหมือนเสร็จ แต่ใช้งานจริงไม่ได้

ผลลัพธ์ที่ Anthropic เจอ

บทความยกตัวอย่างให้ Claude สร้าง 2D retro game maker แล้วเทียบระหว่าง solo agent กับ full harness

full harness แพงกว่ามาก แต่คุณภาพต่างกันชัดเจน solo agent ทำหน้าตาได้บางส่วน แต่เกมเล่นจริงไม่ได้ดีนัก ส่วน full harness ทำ feature ได้ลึกกว่า polished กว่า และ play mode ใช้งานได้จริงกว่า

นี่เป็น trade-off ที่ต้องจำไว้ ไม่ใช่ว่าเราควรใช้ harness หนักๆ กับทุกงาน เพราะบางงาน single agent ก็พอ แต่ถ้างานสำคัญ งานซับซ้อน หรืองานที่ต้องการคุณภาพสูงมาก harness แบบนี้อาจคุ้ม

เมื่อ Model เก่งขึ้น Harness ก็ต้องเปลี่ยน

อีกประเด็นที่ผมชอบคือ Anthropic บอกว่าเมื่อ model รุ่นใหม่เก่งขึ้น บางส่วนของ harness ที่เคยจำเป็นอาจไม่จำเป็นอีกต่อไป

นี่เป็นความจริงที่สำคัญมาก ทุก component ใน harness คือสมมติฐานบางอย่างว่า model ยังทำเองได้ไม่ดีพอ เช่น ยังวางแผนไม่ดีพอ ยัง review ตัวเองไม่ดีพอ ยังทำงานยาวไม่ได้พอ หรือยังต้องแตกงานเป็น sprint เล็กๆ

แต่เมื่อ model ดีขึ้น สมมติฐานเหล่านี้อาจหมดอายุ

ดังนั้น harness ที่ดีไม่ควรเป็น pipeline แข็งๆ แต่ควรเป็นระบบที่ปรับได้ เช่น

• เปิดหรือปิด planner ได้
• เลือก evaluator แบบเบาหรือหนักได้
• ปรับจำนวนรอบ iteration ได้
• เลือกใช้ context reset หรือ compaction ได้
• ถอด component ที่ไม่ load-bearing ออกได้

ผมคิดว่านี่คือแนวคิดที่ดีมากสำหรับคนทำ agent platform เพราะเราไม่ได้ออกแบบระบบเพื่อ model รุ่นเดียว แต่ต้องออกแบบให้ evolve ตาม model ได้

ถ้าจะเอามาพัฒนาต่อ ผมจะเริ่มจากอะไร

ถ้าเอาแนวคิดนี้มาใช้กับระบบ agent ที่ผมกำลังทำอยู่ ผมคิดว่าสิ่งที่ควรเริ่มมีคือ 5 เรื่องนี้

1. Artifact-first workflow

อย่าให้ chat เป็นที่เก็บ state หลักของงาน แต่ให้ agent ทำงานผ่านไฟล์หรือ object ที่ชัดเจน เช่น

• SPEC.md
• PLAN.md
• TASKS.md
• STATE.md
• EVAL.md
• HANDOFF.md

ไฟล์เหล่านี้ทำให้ agent ตัวถัดไปอ่านต่อได้ และมนุษย์ก็ตรวจได้ด้วย

ซึ่งหากใครใช้ skill พวกทำ Spec Driven มันจะสร้างเอกสาร spec/plan/adr ให้อัตโนมัติ คอนเซ็ปประมาณนี้เลย

2. Maker กับ Checker ต้องแยกกัน

งานสำคัญไม่ควรให้ agent ตัวเดียวสร้างและรับรองงานตัวเอง ควรมี reviewer หรือ evaluator แยกออกมาเสมอ โดยเฉพาะงานที่ต้อง publish, deploy หรือกระทบข้อมูลจริง

3. Evaluator ต้องมี Rubric

rubric คือชุดเกณฑ์การให้คะแนน หรือเครื่องมือประเมินผลที่อธิบายระดับคุณภาพของชิ้นงาน

ดังนั้น Evaluator ที่ไม่มี rubric จะตรวจแบบลอยๆ และมักใจดีเกินไป rubric ที่ดีควรบอกว่าอะไรคือ pass, อะไรคือ fail, ต้องลอง edge case ไหน และอะไรที่ห้ามมองข้าม

4. Context Reset ต้องเป็น Feature ไม่ใช่ปล่อยให้แก้ตอนเต็ม

ถ้างานยาวพอ เราควรออกแบบไว้เลยว่า agent จะ reset ตอนไหน ส่งต่ออะไร และ agent ตัวใหม่ต้องอ่านอะไรบ้าง ไม่ใช่รอให้ context เต็มแล้วค่อยหาทางรอด

5. ต้องมี Stop Condition

Agent ที่ทำงานเองได้ต้องรู้ด้วยว่าเมื่อไรควรหยุด ถ้าไม่มี stop condition มันอาจวนแก้ไปเรื่อยๆ ใช้ token ใช้เวลา แต่คุณภาพไม่ได้ดีขึ้นตามสัดส่วน

ข้อควรระวัง

แนวทางนี้น่าสนใจมาก แต่ก็มีข้อควรระวังเยอะเหมือนกัน

• Cost สูงขึ้น เพราะใช้หลาย agent ทำงานหลายรอบ และต้องมี evaluation loop
• สร้างงานได้ช้าขึ้น เพราะงานบางอย่างต้องรอ browser test, QA หรือ iteration
• ซับซ้อนขึ้น เพราะต้องดูแล state, artifact, prompt, rubric และ orchestration
• Evaluator ก็พลาดได้ ถ้า rubric ไม่ดีหรือทดสอบไม่ลึกพอ
• Handoff ที่ไม่ดีอันตรายมาก เพราะ agent รุ่นถัดไปอาจสานต่อจากข้อมูลผิด

ดังนั้นผมคิดว่าควรใช้ harness หนักๆ เฉพาะงานที่คุ้มจริง เช่นงานที่มีผลลัพธ์สำคัญ งานที่ต้องใช้ซ้ำ หรืองานที่ถ้าพลาดแล้วเสียเวลามาก

สรุป

บทความนี้ทำให้ผมยิ่งเชื่อว่าอนาคตของ AI Agent ไม่ได้อยู่ที่ prompt อย่างเดียว แต่อยู่ที่การออกแบบ harness รอบๆ model ให้ดีพอ

Agent ที่ทำงานยาวได้จริงต้องมี plan ต้องมี state ต้องมี handoff ต้องมี evaluator ต้องมี rubric และต้องมีวิธีรู้ว่าเมื่อไรควรทำต่อหรือหยุด

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

สำหรับผม นี่เป็นทิศทางที่น่าทดลองมาก และน่าจะเป็นแกนสำคัญของระบบ agent รุ่นถัดไปที่ไม่ได้แค่ “ตอบเก่ง” แต่ “ทำงานเป็นระบบ” ได้จริง

สำหรับโพสต์นี้ เอาใจสาย Spec Driven Development หน่อย คือผมไปเจออีกวิธีที่น่าสนใจดี ที่ใช้ในการทำ Spec ค่อนข้างละเอียดเลย แต่พอนึกดีๆ แล้ว หลายครั้งผมก็เขียนแบบนี้โดยไม่รู้ตัว

เพราะความไม่ต้องการให้ AI เดาเอง และไม่อยากอารมณ์เสียเมื่อรอมันรันนานแต่ผลลัพธ์ที่ได้ไม่ตรงใจ ผมจึงมักจะระบุว่าใคร ทำอะไร อย่างไร ที่ไหน เมื่อไร อะไรควรทำ ไม่ควรทำ

ซึ่งเครื่องมือในโพสต์นี้เป็นประมาณนั้นเลยครับ เผื่อใครจะเอาไปเป็นไอเดียเสริมสไตล์การเขียน Prompt/Spec ให้กับผู้อ่านได้

หมายเหตุ: บทความนี้ฟิวส์กับเอเจ้นชมพู ได้เรียบเรียงและแปลจากต้นฉบับของ Vishal Mysore เรื่อง ZeeSpec- Spec Driven Development for Greenfield vs Brownfield Projects

AI มันไม่กลัว requirement ที่ไม่ชัด แต่มันจะเดาแทนเราเลย

บทความต้นฉบับพูดถึงเครื่องมือชื่อ ZeeSpec ซึ่งเป็นแนวคิดการทำ spec แบบบังคับให้เราตอบคำถามให้ครบก่อนเริ่มให้ AI สร้างระบบ

คำสำคัญของ ZeeSpec คือ มันไม่ได้เป็น documentation เฉยๆ แต่มันเป็น constraint system หรือระบบกรอบข้อจำกัดที่บอก AI ว่าอะไรทำได้ อะไรทำไม่ได้ อะไรห้ามเดา

ถ้าเราไม่ตอบ AI จะตอบแทนเรา และคำตอบนั้นอาจดูดีมากจนเราไม่ทันระวัง

ฟังดูเหมือนเรื่องเล็กนะครับ แต่คนทำ software น่าจะเคยเจออาการนี้กันบ่อยมาก เช่น บอกให้เพิ่ม feature นิดเดียว แต่ AI ดัน refactor service เดิมให้ด้วย หรือบอกให้เพิ่ม field ในตาราง แต่มัน generate migration ที่กระทบข้อมูลเดิมแบบชวนเสียวหลัง

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

ZeeSpec ใช้ 5W1H มาบีบให้เราคิดครบ

ZeeSpec วางอยู่บนแนวคิด Zachman Framework ซึ่งเป็นกรอบคิดด้าน enterprise architecture และโมเดล 5W1H ที่ประกอบด้วย What, Where, When, Who, Why, How

ในบทความบอกว่า ZeeSpec มีคำถาม 60 ข้อ แบ่งเป็น 6 มิติ มิติละ 10 ข้อ เป้าหมายไม่ได้อยู่ที่การเขียนเอกสารให้ยาว แต่อยู่ที่การบังคับให้ decision สำคัญถูกพูดออกมาก่อน AI จะลงมือเขียนโค้ด

ผมชอบตรงที่มันไม่ได้ถามแค่ว่า “อยากได้ feature อะไร” แต่มันถามด้วยว่า “อะไรห้ามเกิดขึ้น” ซึ่งปกติเราไม่ค่อยเขียนลง requirement กัน ทั้งที่ในโลกจริง สิ่งที่ห้ามเกิดขึ้นนี่สำคัญมาก

Greenfield คือพื้นที่ว่างที่อันตรายกว่าที่คิด

Greenfield project คือโปรเจกต์ที่เริ่มใหม่แทบทั้งหมด ไม่มี schema เดิม ไม่มี API เดิม ไม่มี legacy ให้ต้องเกรงใจ

ข้อดีคือเราออกแบบใหม่ได้เต็มที่ แต่ข้อเสียคือไม่มีอะไรคอยขัด AI เลย ถ้าเรา spec ไม่ครบ มันจะเติมโลกทั้งใบให้เราเอง

Greenfield ไม่ได้เสี่ยงเพราะไม่มีของเดิม แต่มันเสี่ยงเพราะไม่มีแรงต้านเวลา AI เดา

ในบทความเสนอว่า สำหรับ greenfield ต้องตอบให้ครบทุกมิติ โดยเฉพาะคำถามที่คนมักข้าม เช่น

• ระบบนี้ทำอะไร และไม่ทำอะไร
• entity ไหนมีจริง entity ไหนห้ามมี
• ข้อมูลอะไรห้ามเก็บเด็ดขาด เช่น PII, payment data, secret
• ใครเห็นข้อมูลอะไรได้บ้าง
• เมื่อเกิด error ระบบควร fail แบบไหน
• ถ้าเจอข้อมูลไม่ครบ ระบบควรหยุดหรือเดา

ถ้าเขียนแบบนี้ก่อนให้ AI ทำงาน โอกาสที่มันจะสร้าง table ประหลาดๆ หรือ flow ที่ดูสมเหตุสมผลแต่ผิด business rule จะน้อยลงมาก

Brownfield ต้องล็อกของเดิมก่อนค่อยสั่งของใหม่

Brownfield project คือระบบที่มีอยู่แล้ว อาจมี database จริง มี user ใช้งานจริง มี API consumer ภายนอก มี technical debt ที่ทุกคนรู้ว่าไม่สวย แต่แตะมั่วไม่ได้

ตรงนี้บทความให้แนวคิดที่ผมว่าโดนมาก คือ brownfield ไม่ควร spec ทั้งระบบใหม่ แต่ควร spec เฉพาะ delta หรือส่วนที่เปลี่ยน

Greenfield คือเติมทุกมิติ ส่วน brownfield คือ lock สิ่งที่มีอยู่ แล้วระบุเฉพาะสิ่งที่จะเปลี่ยน

นี่เป็นจุดที่หลายทีมพลาด รวมถึงผมเองก็เคยพลาดครับ เวลาใช้ AI กับระบบเดิม เรามักคิดว่าให้ context เยอะๆ แล้วมันจะเข้าใจ แต่ถ้าเราไม่บอกว่า “ห้ามแตะอะไร” มันอาจช่วยเกินหน้าที่

ตัวอย่างง่ายๆ เช่น เราขอเพิ่ม endpoint ใหม่สำหรับ export report แต่ถ้าไม่ได้ lock authentication pattern เดิมไว้ AI อาจ generate middleware แบบใหม่ หรือแก้ permission model ให้ดูสะอาดขึ้น ซึ่งดูดีใน diff แต่พังกับระบบจริง

ก่อน spec ระบบเก่า ต้องป้อน context ของระบบเก่าก่อน

สำหรับ brownfield บทความแนะนำให้เริ่มด้วย Step 0 คือป้อน context ของระบบเดิมก่อนตอบ ZeeSpec

• schema ปัจจุบัน แม้จะเป็น version ย่อก็ยังดีกว่าไม่มี
• API pattern ที่ใช้อยู่ เช่น naming, response shape, error format
• tech stack และ infrastructure ที่เปลี่ยนไม่ได้
• constraint ที่เป็น non-negotiable เช่น ต้องใช้ PostgreSQL 14 หรือห้าม breaking change กับ client เดิม

ผมว่าข้อนี้ practical มาก เพราะ AI ที่ไม่เห็น schema จะออกแบบรอบ schema ไม่ได้ มันจะออกแบบ schema ใหม่ให้เราแทน ซึ่งใน brownfield นี่คือความเจ็บปวดล้วนๆ

วิธีคิดต่างกันระหว่าง greenfield กับ brownfield

ถ้าเอามาแปลงเป็นภาษาคนทำงานจริง ผมจะสรุปแบบนี้ครับ

Conflict ใน spec ไม่ใช่ edge case แต่มันคือ bug ตั้งแต่ยังไม่เขียนโค้ด

อีกประเด็นที่ผมชอบคือ เวลาคำตอบใน spec ขัดกัน ZeeSpec ไม่ควรปล่อยผ่าน

เช่น ในมิติ WHO เราบอกว่าเฉพาะ Admin เท่านั้นที่ลบ user ได้ แต่ในมิติ WHEN เราบอกว่า unverified account จะถูกลบอัตโนมัติหลัง 30 วัน แบบนี้มันมี conflict อยู่แล้ว

ถ้าเราไม่ resolve ตอน spec AI อาจ resolve ให้เองแบบเงียบๆ และเราอาจไม่รู้ด้วยว่ามันเลือกทางไหน

Spec ที่ขัดกัน คือ bug ที่ยังไม่ได้ compile

ผมชอบประโยคนี้มาก เพราะมันทำให้เราเปลี่ยนมุมมองจาก “เดี๋ยวค่อยดูตอน implementation” เป็น “ต้องเคลียร์ก่อนให้ AI ลงมือ”

เอาไปใช้กับงานจริงได้ยังไง

ถ้าจะเอาแนวคิดนี้ไปใช้กับทีม software development ผมคิดว่าไม่จำเป็นต้องเริ่มด้วย 60 ข้อแบบเต็มทันที เพราะเดี๋ยวทีมจะรู้สึกว่าเอกสารกลับมาฆ่าเราอีกแล้ว 555

เริ่มแบบเบากว่านั้นก็ได้ เช่น ก่อนให้ AI ทำ feature ใดๆ ให้ตอบ 6 ช่องนี้ให้ได้ก่อน

• WHAT จะเพิ่มหรือเปลี่ยนอะไร และอะไรไม่อยู่ใน scope
• WHERE ต้องแตะ file, service, database, integration ไหนบ้าง และอะไรห้ามแตะ
• WHEN flow ใหม่เกิดตอนไหน กระทบ trigger เดิมไหม
• WHO role ไหนใช้ได้ role ไหนห้ามใช้
• WHY business rule สำคัญคืออะไร ทำไมต้องเป็นแบบนี้
• HOW migration, rollback, error, test ต้องเป็นอย่างไร

สำหรับ greenfield ให้ช่องพวกนี้เป็นการออกแบบระบบ สำหรับ brownfield ให้ช่องพวกนี้เป็นรั้วกัน AI ไม่ให้ไปช่วยแก้สิ่งที่ไม่ควรแก้

Prompt แบบย่อสำหรับ greenfield

อันนี้ผมเรียบเรียงเป็น template สั้นๆ เอาไว้ใช้ได้เลย

System: [ชื่อระบบ]
Assumption: เริ่มใหม่ ไม่มี infrastructure เดิม

WHAT: entity, relationship, boundary, สิ่งที่ห้ามมี, ข้อมูลที่ห้ามเก็บ
WHERE: infrastructure, data flow, integration, system boundary
WHEN: trigger ของ create/update/delete, expiry, blocking condition
WHO: role, permission, visibility, approval
WHY: business rule, intent, validation, เหตุผลของข้อจำกัด
HOW: error handling, recovery, consistency, idempotency, test

Generate a system spec with no unstated assumptions. If information is missing, ask before generating code.

Prompt แบบย่อสำหรับ brownfield

ส่วน brownfield ผมจะเน้นคำว่า unchanged และ delta ให้ชัด เพราะนี่คือหัวใจของระบบเดิม

Existing system context: [paste schema / API pattern / tech stack / non-negotiable constraints]

New feature: [ชื่อ feature] 

WHAT: delta only, new entity, changed field, สิ่งที่ exclude ชัดเจน 
WHERE: existing infrastructure unchanged, list what must not change 
WHEN: new trigger, conflict with existing trigger, blocking rule เดิมที่ยังต้องใช้ WHO: permission ใหม่อิง role เดิม, role ที่ห้าม access 
WHY: เหตุผลของ feature และเหตุผลที่ constraint เดิมยัง valid 
HOW: migration path, backward compatibility, rollback, tests Generate only the delta. 

Do not refactor existing components unless explicitly requested.

สิ่งที่ผมได้จากบทความนี้

ผมว่าประเด็นของ ZeeSpec ไม่ใช่แค่ “เขียน spec ให้ละเอียดขึ้น” แต่คือ “เปลี่ยนหน้าที่ของ spec”

เมื่อก่อน spec มักเป็นเอกสารอธิบายให้คนอ่าน แต่ในยุค AI coding spec กลายเป็นรั้วกั้นพฤติกรรมของเครื่องมือ ถ้ารั้วหลวม AI ก็เดินออกนอกเขต ถ้ารั้วไม่บอกตำแหน่งท่อ มันก็อาจขุดโดนท่อ

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

และยิ่ง AI เขียนโค้ดได้เร็วขึ้นเท่าไร spec ยิ่งสำคัญขึ้นเท่านั้น

เพราะความเร็วไม่ได้ช่วยอะไร ถ้าเอไอลากเราวิ่งหลงทาง ผ่าม!

แหล่งที่มา

• ZeeSpec- Spec Driven Development for Greenfield vs Brownfield Projects โดย Vishal Mysore
• Spec Driven Development with ZeeSpec : greenfield vs brownfield บน DEV Community