คุยกับ Claude Code ให้มากขึ้น งานจะตรงใจกว่าการโยน prompt บรรทัดเดียว

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

Will Jones นักพัฒนาที่ใช้ Claude Code ทุกวันมาเกือบปีบนโปรเจกต์ฐานข้อมูลชื่อ Lance สรุปบทเรียนที่มีค่าที่สุดของเขาไว้สั้นๆ ว่า สิ่งที่ควรทำให้มากขึ้นคือ "คุย" กับ agent ไม่ใช่ "อ่าน" ผลลัพธ์ที่มันพ่นออกมา เพราะ AI ตัวนี้ไม่ใช่หมอดู มันอ่านใจไม่ได้ ยิ่งโยน prompt สั้นๆ ให้มันวิ่งเอง ยิ่งได้งานที่ต้องมานั่งรื้อทีหลัง ทางที่ได้ผลกว่าคือใช้เวลาช่วงต้นคุยให้เข้าใจตรงกันก่อน แล้วงานที่ออกมาจะตรงขึ้นและแก้น้อยลง

ปัญหาไม่ได้อยู่ที่ AI ไม่เก่ง แต่อยู่ที่มันไม่รู้ว่าเราคิดอะไร

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

Claude Code ก็เหมือนกันเป๊ะ ความรู้เรื่องโค้ดของมันอาจจะแน่นกว่าเราด้วยซ้ำ แต่มันไม่รู้ว่าเป้าหมายจริงๆ ของงานนี้คืออะไร มีอะไรที่ห้ามแตะ หรือมีข้อจำกัดอะไรซ่อนอยู่ พอข้อมูลพวกนี้ไม่ครบ มันก็เดา และการเดาของมันมักจะดูดีในตอนแรก จนเราเผลอกดตามไปแล้วค่อยมารู้ทีหลังว่าผิดทิศ

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

workflow ห้าจังหวะ ลงแรงตรงต้นกับท้าย

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

1. คุยก่อน อย่าเพิ่งสั่งทำ — เอาบริบทของปัญหาให้ครบ ไม่ว่าจะเป็นรายละเอียดของบั๊ก ข้อความที่ทีมคุยกันค้างไว้ หรือไอเดียในหัวเรา แล้วเปิดบทสนทนา ไม่ใช่สั่งให้ทำทันที
2. ให้ agent สรุปบทสนทนาเป็นแผน — พอคุยจนเข้าใจตรงกันแล้ว ให้มันสรุปสิ่งที่คุยกันเป็นแผน ถ้าเป็นงานชิ้นเดียวก็เก็บเป็นไฟล์โน้ตชั่วคราว ถ้ามีหลายชิ้นก็ให้มันแยกเป็นรายการงานทีละชิ้นบน GitHub ซึ่งเป็นเว็บที่ทีมพัฒนาใช้เก็บโค้ดและจดรายการงานร่วมกัน
3. เปิด agent ตัวใหม่มาลงมือ — พอมีแผนชัดแล้ว เปิดหน้าต่างใช้งานใหม่สดๆ มารับงานไป ถ้ามีหลายงานก็เปิดหลายตัวทำขนานกัน แยกพื้นที่ทำงานของใครของมันไม่ให้ชนกัน
4. ให้ร่างโค้ดที่แก้แล้วขัดให้เรียบ — ให้ agent ร่างโค้ดที่แก้เป็นก้อนพร้อมรีวิว แล้วใช้สกิลขัดงานรอบสุดท้าย เก็บโค้ดที่ไม่ได้ใช้ เช็กว่าเทสต์ครอบคลุมไหม ทำให้อ่านง่ายขึ้น
5. รีวิวเหมือนรีวิวงานเพื่อน — อ่านโค้ดที่แก้แล้วคอมเมนต์ลงไปตรงจุด เหมือนรีวิวงานของเพื่อนร่วมทีมคนหนึ่ง จากนั้นบอก agent ให้ไปแก้ตามคอมเมนต์ ถ้างานที่ต้องแก้ยังใหญ่พอ ก็ค่อยวนกลับไปจังหวะที่สี่

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

ทำไมเขาเลิกใช้ plan mode

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

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

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

รากของปัญหาคือคำว่า "เข้าใจตรงกัน" พอพุ่งเข้า plan mode ทันที สองฝ่ายยังไม่ทันเข้าใจร่วมกันเลย agent ก็เลยวางแผนแก้ปัญหาตามตัวอักษรใน prompt แรกเป๊ะๆ ทั้งที่แผนที่ดีต้องผ่านการโยนไอเดียไปมาหลายรอบ เพราะทั้งคนทั้ง agent ต่างมีของดีคนละอย่างมาแลกกัน

คุยกันแล้วได้อะไรที่สั่งเดี่ยวๆ ไม่มีวันได้

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

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

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

เริ่มวันนี้ด้วยการเปลี่ยน prompt แรกแค่ประโยคเดียว

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

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

ถ้าอยากให้ agent จี้เราหนักกว่านั้น มีสกิลสำเร็จรูปชื่อ grill-me ที่สั่งให้มันสัมภาษณ์เราแบบไล่ถามไม่ปล่อยจนกว่าจะเข้าใจตรงกันทุกแง่มุมของแผน ซึ่งเป็นแนวทางที่ Anthropic ผู้สร้าง Claude Code เองก็แนะนำไว้ใน คู่มือใช้งานอย่างเป็นทางการ เหมือนกัน เครื่องมือนี้แค่ทำให้นิสัย "คุยให้มากขึ้น" เป็นระบบขึ้น ไม่ใช่ของที่ต้องมีก่อนถึงจะเริ่มได้

ของแถมที่ต้องบอกตามตรง

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

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

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

ยิ่งสั่งสั้น ไม่ได้แปลว่ายิ่งเร็ว

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

---

ที่มา: บทความ Talk more to your coding agents โดย Will Jones