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

ในการทำงานร่วมกับ AI ความทรงจำไม่ควรอยู่ในแชต แต่ควรอยู่ในรีโพซิทอรี

ในช่วงหลายเดือนที่ผ่านมา ผมทำงานพัฒนาโดยสลับใช้โมเดล AI หลายตัว เช่น GPT-5 ตระกูลต่าง ๆ, Claude, Copilot, Gemini อยู่บ่อยครั้ง แต่ก่อนการใช้เครื่องมือเพียงตัวเดียวก็เพียงพอแล้ว ทว่าตอนนี้การเลือกโมเดลที่เหมาะกับประเภทของงานแต่ละแบบกลายเป็นแนวทางที่เป็นธรรมชาติไปแล้ว

ตัวอย่างเช่น การออกแบบโครงสร้างมักเสถียรกว่าหากใช้โมเดลขนาดใหญ่อย่าง GPT-5.4 ขณะที่การเขียนโค้ด บางครั้งตระกูล Claude Sonnet / Opus ให้ความแม่นยำมากกว่า และในงานออกแบบฟรอนต์เอนด์หรือการสำรวจไอเดีย การใช้โมเดลอื่นก็อาจมีประสิทธิภาพกว่า นอกจากนี้ ความเร็วในการอัปเดตของโมเดลยังสูงมาก จึงทำให้แทนที่จะยึดติดกับเครื่องมือใดเครื่องมือหนึ่ง เรามักเปลี่ยนตัวเลือกไปตามสถานการณ์อยู่เสมอ

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

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

"สำหรับการทำงานร่วมกับ AI ความทรงจำควรอยู่ในแชต หรือโปรเจ็กต์เองควรเป็นผู้เก็บความทรงจำกันแน่?"

ปัญหาที่ Prompt Engineering แก้ไม่ได้

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

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

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

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

ไม่ใช่แชต แต่รีโพซิทอรีต้องเป็นผู้เก็บความทรงจำ

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

ผมสร้างโฟลเดอร์ชื่อ .cowork/ และให้มันทำหน้าที่บันทึกสถานะของโปรเจ็กต์ เช่น requirements, architecture decision record, รายการ task, บันทึกการทดสอบ, บันทึกการรีลีส, session log เป็นต้น

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

กฎ Plan → Approve → Execute

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

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

Artifact is Memory

หลักการสำคัญที่สุดของเฟรมเวิร์กนี้ สรุปได้ด้วยประโยคว่า 'Artifact is Memory' ความทรงจำไม่ควรอยู่ในแชต แต่ควรอยู่ในผลลัพธ์ของโปรเจ็กต์

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

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

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

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

ปัญหาที่เกิดขึ้นเมื่อทำงานโดยสลับใช้หลายโมเดล

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

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

สิ่งที่ทำขึ้น: cowork-context-framework

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

• GitHub: https://github.com/lim8603/cowork-context-framework

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

อยากรู้ว่ามีใครเคยลองแนวทางคล้ายกันไหม

• คนที่เคยมีประสบการณ์ใช้ AI หลายโมเดลร่วมกัน
• คนที่เคยต้องอธิบายเรื่องเดิมซ้ำเพราะเซสชันขาดตอน
• คนที่เคยสร้างโครงสร้างอย่าง agent / workflow / harness
• คนที่เคยจัดการบริบทของโปรเจ็กต์แยกต่างหาก

หากมีประสบการณ์คล้ายกัน ผมอยากฟังความคิดเห็นของคุณ