เจาะประเด็น
AI / Workflow
เปลี่ยน AI เขียนโค้ดกลางโปรเจกต์ จะเอาอะไรติดตัวไปบ้าง ไม่ใช่ทิ้งแชททั้งก้อนใส่เครื่องใหม่
คำถามที่นักพัฒนาส่วนใหญ่ไม่คิดให้ลึก แต่เป็นตัวชี้วัดว่าโปรเจกต์จะรอดหรือพังหลังย้ายบ้าน
ทีมข่าว เอไอไทย.com
⏱ อ่าน 4 นาที
ถ้าเธอคิดว่า "ก็กด export แชททั้งหมดไปวาง" คือคำตอบ แสดงว่ายังไม่เคยเจอโปรเจกต์ใหญ่พอที่จะทำให้ AI งงกับขยะที่ตัวเองพิมพ์เอง
สมมติว่าเมื่อวานเธอนั่งคุยกับ Claude หรือ ChatGPT อยู่สามชั่วโมง ปั้นฟีเจอร์หนึ่งจนเสร็จ โค้ดรันได้ เทสต์ผ่าน อัปเดตแล้วอัปเดตอีก ทุกอย่างอยู่ในแชทเดียวจบเป๊ะ พอวันนี้เปิดโปรเจกต์ต่อ รู้สึกว่า AI ตัวเดิมเริ่มเอื่อย ไม่เข้าใจบริบท หรือเธอแค่อยากลองตัวใหม่ที่เพื่อนร่วมทีมบอกว่ามันโคตรฉลาด คำถามคือเธอจะเอาอะไร "ติดตัว" ไปกับโปรเจกต์บ้าง?
กระทู้ใน Reddit r/ClaudeAI ตั้งคำถามนี้ได้ตรงเป๊ะ: "What do you carry forward when switching coding agents mid-project?" — อะไรคือบริบทที่สำคัญจริงๆ ระหว่าง "การตัดสินใจ" "ข้อจำกัด" "แนวทางที่ลองแล้วไม่เวิร์ก" "งานที่ค้างอยู่" หรืออย่างอื่น? แล้วเธอจะย้ายมันไปโดยไม่ต้องเทแชททั้งประวัติศาสตร์ลงไปให้ AI ตัวใหม่จมกับขยะ?
ฟังดูเป็นคำถามเทคนิคแห้งๆ แต่จริงๆ มันคือปมใหญ่ของชีวิตนักพัฒนา AI ในยุคนี้ เพราะถ้าเธอใช้ AI เขียนโค้ดจริงจังไม่ใช่แค่เล่นๆ เธอจะรู้ว่า "ประวัติแชท" ไม่ใช่ความรู้ มันคือบันทึกความเวิ่นเว้อของเราที่ผสมกับโค้ดดีๆ คนละเรื่องกันโดยสิ้นเชิง
เจ้าของกระทู้ (u/delimitdev) กำลังเจอสถานการณ์คลาสสิก: โปรเจกต์เริ่มใหญ่ขึ้นเรื่อยๆ บทสนทนากับ AI ยาวขึ้นเรื่อยๆ จนถึงจุดที่ AI เริ่ม "หลงทาง" ในบริบทของตัวเอง — มันจำได้ว่าตอนแรกเราคุยอะไรกัน แต่จำไม่ได้ว่าตกลงกันตรงกลางว่าอะไรสำคัญกว่ากัน นี่คือปัญหาที่ทุกคนที่ใช้ AI เขียนโค้ดจริงจะต้องเจอสักวัน ไม่วันใดก็วันหนึ่ง
คำถามของเขาจึงไม่ใช่ "จะย้ายยังไง" แต่เป็น "จะย้ายอะไร" ต่างหาก — เพราะถ้ารู้ว่าอะไรคือของมีค่าจริงๆ วิธีการย้ายก็เป็นแค่รายละเอียดปลีกย่อย
ในฐานะคนที่ใช้ AI เขียนโค้ดทุกวัน ขอบอกตรงๆ ว่าคำตอบที่ถูกต้องไม่ใช่ "ทุกอย่าง" และไม่ใช่ "แค่ไฟล์ README" แต่คือสี่อย่างนี้:
1. การตัดสินใจ (Decisions)
อันนี้คือของแพงที่สุดในโปรเจกต์ — ทำไมเลือกใช้ database ตัวนี้ ทำไมไม่ใช้ ORM นั้น ทำไมโครงสร้างไฟล์เป็นแบบนี้ AI ตัวใหม่ไม่รู้ที่มาที่ไป มันจะมองโค้ดเธอเป็นแค่ "โค้ดที่เขียนแปลกๆ" แทนที่จะเห็นว่าเป็นการตัดสินใจที่มีเหตุผลรองรับ
2. ข้อจำกัด (Constraints)
ไม่ใช่แค่เรื่องเทคนิคอย่าง "deploy บน server นี่เท่านั้น" แต่รวมถึงข้อจำกัดที่ไม่เป็นทางการ เช่น "ลูกค้าคนนี้ไม่ชอบ UI แบบนี้" หรือ "ทีมเราไม่ถนัดภาษา X" — ถ้าไม่บอก AI ตัวใหม่ มันจะเสนอทางเลือกที่ "ถูกต้องตามทฤษฎี" แต่ "ใช้งานจริงไม่ได้"
3. แนวทางที่ลองแล้วไม่เวิร์ก (Failed approaches)
อันนี้คนมักมองข้าม แต่สำคัญโคตรๆ เพราะการบอก AI ว่า "อย่าทำแบบนี้ มันไม่เวิร์กเพราะ..." ช่วยประหยัดเวลาเป็นชั่วโมงๆ ไม่งั้น AI ตัวใหม่จะเดินเข้าหลุมเดิมที่ตัวเก่าเดินไปแล้ว และเธอก็ต้องนั่งอธิบายใหม่ทั้งหมด
4. งานที่ค้างอยู่ (Open tasks)
อันนี้ตรงไปตรงมาที่สุด แต่ก็อันตรายที่สุด เพราะถ้าเธอแค่บอกว่า "ยังทำ X ไม่เสร็จ" โดยไม่บอกบริบทว่า "ใกล้เสร็จแค่ไหน ทำอะไรไปแล้วบ้าง" AI ตัวใหม่จะเริ่มจากศูนย์โดยไม่รู้ว่ามีโค้ดครึ่งๆ กลางๆ รออยู่ที่ไหนบ้าง
ส่วนที่เหลือ — บทสนทนาจับกลุ่ม ไอเดียที่คิดแล้วทิ้ง คำถามโง่ๆ ที่ถามไปแล้วได้คำตอบ — ปล่อยมันไปเถอะ มันคือ "ภาระ" ไม่ใช่ "ความรู้" การเททุกอย่างให้ AI ตัวใหม่ฟังเหมือนการย้ายบ้านโดยไม่ทิ้งของ — เธอจะอยู่กับกล่องลังทั้งบ้านที่เปิดไม่รู้เรื่อง และ AI ก็จะงงกับข้อมูลขยะที่เธอป้อนให้มันเอง
วิธีที่ผมใช้จริงคือการเขียน "ไฟล์บริบท" (context file) แยกต่างหาก — เป็นไฟล์ Markdown สั้นๆ ที่บอก AI ตัวใหม่ว่า "โปรเจกต์นี้คืออะไร ตัดสินใจอะไรไปแล้วบ้าง มีอะไรที่ลองแล้วไม่เวิร์ก งานไหนค้างอยู่" แล้วก็ชี้ให้มันไปอ่านโค้ดส่วนที่เกี่ยวข้อง แค่นั้นเอง ไม่ต้องเทแชท ไม่ต้อง export ประวัติ
ข้อดีคือไฟล์นี้เธอใช้กับมนุษย์ด้วยกันได้ด้วย — เพื่อนร่วมทีมใหม่จะเข้าใจโปรเจกต์ได้เร็วขึ้นสิบเท่า แถมตอนที่เธอกลับมาดูโปรเจกต์เองหลังจากไม่ได้แตะสามเดือน ไฟล์นี้คือ "บันทึกความทรงจำ" ที่ช่วยให้เธอไม่ต้องมานั่งไล่อ่าน git log ไล่ดูว่า "กูทำอะไรไว้ตอนนั้นวะ"
การเปลี่ยน AI เขียนโค้ดกลางคันไม่ใช่เรื่องของ "เครื่องมือไหนดีกว่า" แต่คือเรื่องของ "เธอรู้ไหมว่าอะไรสำคัญในโปรเจกต์ตัวเอง" — ถ้าตอบไม่ได้แม้แต่กับตัวเอง ต่อให้ใช้ AI ตัวไหนก็พังเหมือนกัน เพราะปัญหามันไม่ได้อยู่ที่ AI มันอยู่ที่ความเข้าใจของเธอต่างหาก
ที่มา: Reddit r/ClaudeAI — อ่านต้นฉบับ
ความคิดเห็น 4
กำลังโหลดความคิดเห็น...