- ตอนเริ่มใช้ Claude Code ครั้งแรก ผู้เขียนเข้าหาด้วยวิธี สั่งผ่านพรอมป์ตและแก้ไขวนซ้ำ แบบง่าย ๆ แต่เมื่อเป็นงานซับซ้อนก็พบปัญหาเรื่อง การพึ่งพาประวัติการสนทนาและข้อจำกัดของคอนเท็กซ์
- เพื่อแก้ปัญหานี้ จึงให้เขา เขียนเอกสารแผน (plan document) ก่อนลงมือพัฒนาฟีเจอร์ และใช้เอกสารนี้เป็น แหล่งความจริงหนึ่งเดียว (SSOT) ของเซสชันใหม่
- เอกสารแผนประกอบด้วยการสรุปความต้องการใหม่ คำอธิบายรายละเอียดการพัฒนา คำสั่งสำหรับตรวจสอบคุณภาพโค้ด ฯลฯ และยังถูกอัปเดตต่อเนื่องเป็น เอกสารมีชีวิต (living document) แม้ระหว่างการพัฒนาด้วย
- วิธีนี้ช่วยแก้ปัญหา การสูญเสียบริบท และแม้จะเริ่มเซสชันใหม่ก็สามารถทำงานต่อในโปรเจ็กต์ได้ด้วยเอกสารเพียงฉบับเดียว
- ผลลัพธ์คือ AI ไม่ได้เป็นแค่เครื่องมือสำหรับลงมือทำ แต่ทำหน้าที่เป็น คู่หูด้านการออกแบบเชิงร่วมมือ ที่กระตุ้นให้นักพัฒนาคิดและบันทึกงานออกแบบได้ลึกขึ้น
มุมมองต่อปัญหา: ข้อจำกัดของวิธีสนทนาแบบตรงไปตรงมา
- เมื่อต้องทำงานกับ Claude Code แบบโต้ตอบกัน แม้จะเหมาะกับงานง่าย ๆ แต่เมื่อขนาดและความซับซ้อนของงานเพิ่มขึ้น ก็เกิด ข้อจำกัดสำคัญ หลายอย่าง
- บทสนทนากลายเป็นแหล่งความจริงเพียงหนึ่งเดียว ทำให้ข้อความใหม่สามารถเขียนทับคำสั่งก่อนหน้าได้ง่าย และยากจะรู้ได้ชัดว่าเกิดขึ้นตอนไหน
- เนื่องจาก AI มี ข้อจำกัดด้านขนาดคอนเท็กซ์ เมื่อบทสนทนายาวขึ้น ข้อมูลก่อนหน้าก็อาจหล่นหายไปได้
- แม้ Claude Code จะมีฟังก์ชันบีบอัดบทสนทนา แต่ก็ยังไม่สามารถแก้ข้อจำกัดนี้ได้ทั้งหมด
ทดลองใช้แนวทางที่ยึดเอกสารแผนเป็นศูนย์กลาง
- เพื่อแก้ปัญหาเหล่านี้ จึงลองใช้ แนวทางที่อิงเอกสารแผน
- ตอนเริ่มต้น จะอธิบายให้ Claude Code ฟังอย่างละเอียดที่สุดเท่าที่ทำได้เกี่ยวกับฟีเจอร์ที่จะพัฒนา หรือบั๊กที่ต้องแก้
- มีการอ้างถึงไฟล์ซอร์สที่มีอยู่แล้วหรือเอกสารแผนที่เคยเขียนไว้ก่อนหน้าเพื่อใช้เป็นข้อมูลอ้างอิงด้วย
- หลีกเลี่ยงการสั่งรายละเอียดการพัฒนาแบบเจาะจงเกินไป เพื่อเปิดโอกาสให้ AI ทำหน้าที่ เสนอแนวทางการออกแบบ
- เมื่อได้เอกสารแผนที่น่าพอใจเพียงพอแล้ว ก็ล้างประวัติการสนทนาและเริ่มใหม่โดยใช้แผนนั้นเป็นบริบทเพียงอย่างเดียว
- ในแผนจะมีสรุปฟังก์ชัน แผนการพัฒนา โค้ดและรหัสเทียม รวมถึงคำสั่งสำหรับ type/lint/test
กระบวนการออกแบบแบบร่วมมือ
- หากไม่ชอบแบบที่ AI เสนอ ก็จะให้ฟีดแบ็กอย่างเฉพาะเจาะจงเพื่อชี้นำไปสู่ แนวทางที่ปรับแก้แล้ว
- ระหว่างการพูดคุย บางครั้งก็พบว่าข้อเสนอแรกของ AI เหมาะสมกว่า และมีประสิทธิภาพกว่าการเขียนโค้ดโดยอาศัยการออกแบบของตัวเองล้วน ๆ
- บทสนทนาที่เป็นระบบให้ประสบการณ์คล้ายกับการคุยแผนกับเพื่อนร่วมทีมนักพัฒนา
- AI อาจไม่ได้เสนอแนวทางที่ต่างออกไปโดยสิ้นเชิงด้วยตัวเองเสมอไป แต่ถ้าถาม ก็สามารถเสนอทางเลือกอื่นได้เช่นกัน
วิธีทำงานแบบเอกสารมีชีวิต (Living Document)
- เอกสารแผนไม่ได้เขียนครั้งเดียวแล้วจบ แต่ถูก อัปเดตอย่างต่อเนื่องแม้ระหว่างการพัฒนาฟีเจอร์
- การเปลี่ยนแปลงที่พบระหว่างการพัฒนา การตรวจ type การ lint หรือการทดสอบ จะถูกสะท้อนกลับเข้าไปแบบเรียลไทม์
- สร้างนิสัยให้ตรวจสอบสถานะล่าสุดของแผนทุกครั้งที่คอมมิตโค้ด
- เมื่อแผนถูกดูแลให้ทันสมัยอยู่เสมอ แม้จะเปิดบทสนทนาเซสชันใหม่ ก็เพียงแนบแผนก็สามารถทำงานต่อได้โดยไม่สูญเสียบริบท
การรีวิวโค้ดและการเปลี่ยนแปลงของนิสัยการพัฒนา
- หลังเริ่มลงมือพัฒนาแล้ว จะคอยตรวจสอบการเปลี่ยนแปลงเป็นระยะ และหากพอใจกับผลลัพธ์ก็อาจเชื่อถือการทำงานของ AI มากขึ้น
- ตอนรีวิวโค้ดขั้นสุดท้าย เอกสารแผนที่อัปเดตแล้วช่วยให้เข้าใจ เหตุผลเบื้องหลังการตัดสินใจทางเทคนิค ได้ดี
- การวางแผนอย่างรอบคอบและบันทึกเป็นเอกสารล่วงหน้าทำให้ได้ประสบการณ์เติบโตเป็น นักพัฒนาที่ดีกว่าเดิม
- เพราะต้องอธิบายให้ AI เข้าใจ จึงช่วยให้ผู้พัฒนาจัดระเบียบกระบวนการตัดสินใจของตนเองได้ชัดเจนขึ้น
จากความวุ่นวายสู่ความเป็นระบบ
- วิธีนี้ทำให้เอกสารแผนกลายเป็น แหล่งความจริงเพียงหนึ่งเดียว ช่วยแก้ปัญหาการสูญเสียบริบท และส่งเสริมการคิดเชิงสถาปัตยกรรม
- เอกสารแผนมีทั้งสเปกและบันทึกการพัฒนา โดยไม่ได้บันทึกแค่ว่า “ทำอะไร” แต่รวมถึง “ทำไม” และ “อย่างไร” ด้วย
- ผลลัพธ์สุดท้ายคือกระบวนการพัฒนาที่มีการวางแผน มีเอกสารรองรับอย่างดี และเชื่อถือได้สูง
- AI จึงไม่ได้เป็นเพียงผู้ลงมือพัฒนา แต่กลายเป็น คู่หูด้านการออกแบบเชิงร่วมมือ อย่างแท้จริง
ยังไม่มีความคิดเห็น