การทำงานร่วมกับ Claude Fable 5 สอนบทเรียนเก่าแก่ให้ฉันซ้ำแล้วซ้ำเล่า: แผนที่ไม่ใช่พื้นที่จริง
แผนที่ ซึ่งเป็นตัวแทนของงานที่ต้องทำ คือพรอมต์ ทักษะ และบริบทของฉัน สิ่งที่ฉันให้ Claude ส่วนพื้นที่จริงคือที่ที่งานต้องเกิดขึ้น ได้แก่ โค้ดเบส โลกแห่งความจริง และข้อจำกัดที่แท้จริง
ความแตกต่างระหว่างแผนที่กับพื้นที่จริงคือสิ่งที่ฉันเรียกว่า สิ่งที่ไม่รู้ (unknowns) เมื่อ Claude เจอสิ่งที่ไม่รู้ มันต้องตัดสินใจโดยอาศัยการเดาที่ดีที่สุดว่าฉันต้องการอะไร ยิ่งมีงานมากเท่าไหร่ Claude ก็อาจเจอสิ่งที่ไม่รู้มากขึ้นเท่านั้น
Fable เป็นโมเดลแรกที่ฉันพบว่าคุณภาพของงานถูกจำกัดด้วยความสามารถของฉันในการชี้แจงสิ่งที่ไม่รู้ของมัน
ที่สำคัญ การวางแผนล่วงหน้าอย่างเดียวไม่เพียงพอเสมอไป คุณอาจพบสิ่งที่ไม่รู้ในระหว่างการดำเนินการ หรือสิ่งที่ไม่รู้ของคุณอาจชี้ให้เห็นว่าคุณควรแก้ปัญหาด้วยวิธีที่แตกต่างไปโดยสิ้นเชิง
ฉันพบว่าการทำงานกับ Fable เป็นกระบวนการวนซ้ำในการค้นพบสิ่งที่ไม่รู้ของฉัน ก่อน ระหว่าง และหลังการดำเนินการ
ฉันได้สร้าง ตัวอย่างอาร์ติแฟกต์สำหรับค้นหาสิ่งที่ไม่รู้ที่นี่ แต่ต้องกลับมาอ่านเพื่อสร้างสัญชาตญาณว่าเมื่อใดควรใช้มัน
การรู้จักสิ่งที่ไม่รู้ของคุณ
สิ่งที่ไม่รู้ของคุณคืออะไร? เมื่อฉันมาหา Claude พร้อมกับปัญหา ฉันมักจะแบ่งมันออกเป็น 4 วิธี:
- สิ่งที่รู้แล้วว่ารู้: โดยพื้นฐานแล้วนี่คือสิ่งที่อยู่ในพรอมต์ของฉัน ฉันบอกเอเจนต์ว่าฉันต้องการอะไร?
- สิ่งที่รู้ว่าไม่รู้: สิ่งที่ฉันยังไม่เข้าใจ แต่ฉันรู้ตัวว่ายังไม่เข้าใจ?
- สิ่งที่ไม่รู้ว่ารู้: สิ่งที่ชัดเจนมากจนฉันไม่เคยเขียนลงไป แต่จะจำได้เมื่อเห็น?
- สิ่งที่ไม่รู้ว่าไม่รู้: สิ่งที่ฉันไม่เคยพิจารณาเลย? ความรู้อะไรที่ฉันไม่รู้ว่ามี? ฉันรู้หรือไม่ว่าบางสิ่งสามารถดีได้แค่ไหน?
นักเขียนโค้ดแบบเอเจนติกที่ดีที่สุดมักมีสิ่งที่ไม่รู้น้อย เมื่อดูคนอย่าง Boris หรือ Jarred สร้างพรอมต์ มันชัดเจนสำหรับฉันว่าพวกเขารู้ว่าต้องการอะไรอย่างละเอียด พวกเขาเข้าใจทั้งโค้ดเบสและพฤติกรรมของโมเดลอย่างลึกซึ้ง
แต่พวกเขาก็สันนิษฐานว่ามีสิ่งที่ไม่รู้ด้วยเช่นกัน ในหลายแง่มุม การลดและวางแผนสำหรับสิ่งที่ไม่รู้คือ ทักษะ ของการเขียนโค้ดแบบเอเจนติก แต่โชคดีที่นี่คือทักษะที่คุณสามารถพัฒนาได้โดยการทำงานร่วมกับ Claude
ช่วย Claude ช่วยคุณ
การสั่ง Claude เป็นความสมดุลที่ละเอียดอ่อน ถ้าคุณเจาะจงเกินไป Claude จะทำตามคำสั่งของคุณแม้ว่าการเปลี่ยนทิศทางอาจเหมาะสมกว่า ถ้าคุณคลุมเครือเกินไป Claude มักจะตัดสินใจและสันนิษฐานตามแนวทางปฏิบัติที่ดีที่สุดในอุตสาหกรรม ซึ่งอาจไม่เหมาะกับงานของคุณ
เมื่อคุณไม่คำนึงถึงสิ่งที่ไม่รู้ คุณจะล้มเหลวทั้งสองทาง คุณไม่รู้ว่าเมื่อไหร่เส้นทางจะเต็มไปด้วยอุปสรรค และคุณไม่รู้ว่าเมื่อไหร่เส้นทางจะโล่ง แต่คุณยังคงอยากให้ Claude เบี่ยงเบน
Claude สามารถช่วยคุณค้นพบสิ่งที่ไม่รู้ได้เร็วขึ้น มันสามารถค้นหาโค้ดเบสและอินเทอร์เน็ตได้อย่างรวดเร็ว และมันรู้เรื่องทั่วไปมากกว่าคุณมาก มันยังสามารถวนซ้ำจากความล้มเหลวได้เร็วขึ้นด้วย
ส่วนที่สำคัญที่สุดของกระบวนการนี้คือการให้บริบทแก่ Claude เกี่ยวกับจุดเริ่มต้นของคุณ ตัวอย่างเช่น บอกมันว่าคุณอยู่ในขั้นตอนไหนของกระบวนการคิด เปิดเผยประสบการณ์ของคุณกับปัญหาและโค้ดเบส และปล่อยให้มันทำงานร่วมกับคุณเหมือนคู่คิด
ฉันเคยเขียนเกี่ยวกับการใช้ HTML กับ Claude ในเกือบทุกกรณีเหล่านี้ อาร์ติแฟกต์ HTML เป็นวิธีที่ดีที่สุดในการแสดงภาพและนำเสนอ
ในบทความนี้ ฉันลงรายละเอียดเกี่ยวกับรูปแบบบางอย่างที่ฉันใช้เพื่อเปิดเผยสิ่งที่ไม่รู้เหล่านี้ ฉันไม่ได้ใช้ทุกเทคนิคทุกครั้ง แต่มันเป็นชุดเทคนิคที่มีประโยชน์ที่ควรมี
ก่อนการดำเนินการ (Pre-implementation)
การตรวจหาจุดบอด (Blind Spot Pass)
เมื่อเริ่มทำงาน สิ่งที่มีประโยชน์มากที่สุดอย่างหนึ่งที่คุณทำได้คือการเข้าใจจุดบอดของคุณ ตัวอย่างเช่น ถ้าคุณกำลังเขียนฟีเจอร์ในส่วนใหม่ของโค้ดเบส หรือใช้ Claude ช่วยคุณทำงานที่ไม่คุ้นเคย เช่น การปรับปรุงดีไซน์ซ้ำๆ คุณมีแนวโน้มที่จะมี สิ่งที่ไม่รู้ว่าไม่รู้ มากมาย
คุณอาจไม่รู้ว่าควรถามคำถามอะไร สิ่งที่ดีเป็นอย่างไร มีงานอะไรที่เคยทำมาก่อน หรือควรหลีกเลี่ยงหลุมพรางอะไร
ในการทำเช่นนี้ คุณสามารถขอให้ Claude ช่วยค้นหาสิ่งที่ไม่รู้ว่าไม่รู้ของคุณและอธิบายให้คุณฟัง ฉันชอบใช้คำว่า "blindspot pass" และ "unknown unknowns" ตามตัวอักษร การให้บริบทว่าคุณเป็นใครและรู้อะไรนั้นมักจะสำคัญสำหรับ
ตัวอย่างพรอมต์:
- “ฉันกำลังทำงานเพิ่ม provider การยืนยันตัวตนใหม่ แต่ฉันไม่รู้อะไรเลยเกี่ยวกับโมดูล auth ในโค้ดเบสนี้ คุณช่วยทำ blindspot pass เพื่อช่วยฉันหาสิ่งที่ไม่รู้ว่าไม่รู้ที่เกี่ยวข้อง และช่วยฉันสร้างพรอมต์ให้คุณดีขึ้นได้ไหม”
- “ฉันไม่รู้ว่าการปรับสี (color grading) คืออะไร แต่ฉันต้องปรับสีวิดีโอนี้ คุณช่วยสอนให้ฉันเข้าใจสิ่งที่ไม่รู้ว่าไม่รู้เกี่ยวกับการปรับสี เพื่อที่ฉันจะได้สร้างพรอมต์ได้ดีขึ้นได้ไหม”
การระดมความคิดและต้นแบบ (Brainstorms and prototypes)
เมื่อฉันทำงานในพื้นที่ที่มี สิ่งที่ไม่รู้ว่ารู้ มากมาย ซึ่งเกี่ยวข้องกับเกณฑ์ที่ฉันรู้จักเฉพาะเมื่อเห็น ฉันชอบขอให้ Claude ระดมความคิดและสร้างต้นแบบร่วมกับฉัน
การระบุและพูดถึงสิ่งที่ไม่รู้ว่ารู้ในช่วงต้นของการสร้างต้นแบบนั้นมีค่าอย่างยิ่ง เพราะการค้นพบมันระหว่างการดำเนินการอาจมีต้นทุนสูง (ค่อนข้าง) การเปลี่ยนแปลงเล็กน้อยในฟีเจอร์หรือสเปคอาจทำให้การนำไปใช้งานในโค้ดแตกต่างกันอย่างมาก และอาจทำให้เอเจนต์ของคุณย้อนกลับการเปลี่ยนแปลงก่อนหน้านี้ได้ยากขึ้น
ตัวอย่างเช่น คุณอาจแค่อยากเห็นว่าปุ่มที่เพิ่มเข้าไปในเฟรมดูเป็นอย่างไร โดยไม่ต้องเชื่อมต่อเส้นทางแบ็กเอนด์หรือรักษาสถานะเพิ่มเติมในฟรอนต์เอนด์
การออกแบบภาพเป็นสิ่งที่ฉันอธิบายได้ยาก แต่ฉันรู้ว่าต้องการอะไรเมื่อเห็น ในกรณีเหล่านี้ ฉันจะขอแนวทางการออกแบบหลายๆ แบบสำหรับอาร์ติแฟกต์
ฉันยังเริ่มเซสชันการเขียนโค้ดเกือบทุกครั้งด้วยขั้นตอนการสำรวจหรือระดมความคิด ซึ่งช่วยให้ฉันเริ่มต้นด้วยความตั้งใจที่จะกำหนดขอบเขตของโปรเจกต์ Claude มักจะพบแนวทางที่มีคุณค่าสูงที่ฉันอาจพลาดไป และบางครั้งก็พลาดภาพรวมเพราะโฟกัสที่รายละเอียด การระดมความคิดช่วยป้องกันไม่ให้ฉันกำหนดขอบเขตแคบหรือกว้างเกินไป
ตัวอย่างพรอมต์:
- "ฉันต้องการแดชบอร์ดสำหรับข้อมูลนี้ แต่ฉันไม่มีรสนิยมทางภาพและไม่รู้ว่าอะไรเป็นไปได้ ช่วยสร้างหน้า HTML ที่มีทิศทางการออกแบบที่แตกต่างกันสุดขั้ว 4 แบบ เพื่อให้ฉันสามารถตอบสนองต่อมันได้"
- “ก่อนที่จะเชื่อมต่ออะไรเลย ช่วยสร้างไฟล์ HTML ไฟล์เดียวที่จำลองแถบเครื่องมือแก้ไขใหม่ด้วยข้อมูลจำลอง ฉันต้องการตอบสนองต่อเลย์เอาต์ก่อนที่คุณจะแตะแอปจริง"
- "นี่คือปัญหาโดยคร่าวของฉัน: ผู้ใช้เลิกใช้หลังจากออนบอร์ดดิง ค้นหาในโค้ดเบสและระดมความคิด 10 จุดที่เราสามารถแทรกแซงได้ ตั้งแต่ถูกที่สุดไปจนถึงทะเยอทะยานที่สุด ฉันจะบอกคุณว่าอันไหนที่โดนใจ"
การสัมภาษณ์ (Interviews)
เมื่อฉันระดมความคิดอย่างเพียงพอแล้ว ฉันมักจะยังมีสิ่งที่ไม่รู้
ในกรณีนี้ ฉันขอให้ Claude สัมภาษณ์ฉันเกี่ยวกับสิ่งที่ไม่รู้หรือความคลุมเครือใดๆ เมื่อขอให้ Claude สัมภาษณ์คุณ พยายามให้บริบทเกี่ยวกับปัญหาของคุณเพื่อแนะนำคำถามของมัน นี่คือตัวอย่างบางส่วน
ตัวอย่างพรอมต์:
- "สัมภาษณ์ฉันทีละคำถามเกี่ยวกับอะไรก็ตามที่คลุมเครือ ให้ความสำคัญกับคำถามที่คำตอบของฉันจะเปลี่ยนสถาปัตยกรรม"
การอ้างอิง (References)
บางครั้งคุณไม่สามารถอธิบายสิ่งที่คุณต้องการอย่างละเอียดได้ ตัวอย่างเช่น คุณอาจไม่มีคำศัพท์ หรือมันอาจซับซ้อนมากจนต้องใช้เวลาค่อนข้างนาน
ในกรณีนี้ คำตอบที่ดีที่สุดคือการอ้างอิง แม้ว่าคุณจะรวมไดอะแกรม เอกสาร หรือรูปภาพได้ แต่การอ้างอิงที่ดีที่สุดคือ ซอร์สโค้ด
ถ้าคุณมีไลบรารีที่ใช้งานบางอย่างในลักษณะหนึ่ง หรือส่วนประกอบดีไซน์ที่คุณชอบจริงๆ เพียงชี้ Fable ไปที่โฟลเดอร์และบอกมันว่าต้องมองหาอะไร แม้ว่ามันจะอยู่ในภาษาที่แตกต่างกัน
นี่คือวิธีที่ Claude Design ทำงานเช่นกัน คุณไม่จำเป็นต้องยื่นไฟล์ให้มัน (แม้ว่าคุณจะทำอย่างนั้นได้เช่นกัน) คุณสามารถชี้ไปที่โมดูลบนเว็บไซต์ที่คุณชอบ แล้วมันจะอ่านโค้ดเบื้องหลัง ไม่ใช่แค่ภาพหน้าจอ ซึ่งให้รายละเอียดที่สมบูรณ์ยิ่งขึ้นเกี่ยวกับมาร์กอัป โครงสร้าง และวิธีที่คอมโพเนนต์ถูกสร้างขึ้นจริง
ตัวอย่างพรอมต์:
- ครีต Rust ใน vendor/rate-limiter นี้ใช้พฤติกรรม backoff ที่ฉันต้องการพอดี อ่านมันและนำความหมายเดียวกันมาใช้ใหม่ในไคลเอนต์ TypeScript API ของเรา
แผนการดำเนินการ (Implementation Plans)
เมื่อฉันคิดว่าพร้อมที่จะดำเนินการ ฉันมักจะขอให้ Claude รวบรวมแผนการดำเนินการให้ฉันตรวจสอบ โดยเน้นที่ส่วนที่อาจเปลี่ยนแปลงมากที่สุด เช่น การตรวจสอบโมเดลข้อมูล อินเทอร์เฟซประเภท หรือโฟลว์ UX ซึ่งช่วยให้ Claude แสดงสิ่งที่ฉันอาจต้องเปลี่ยนแปลงจริงๆ
ตัวอย่างพรอมต์:
- เขียนแผนการดำเนินการเป็น HTML แต่นำด้วยการตัดสินใจที่ฉันมีแนวโน้มจะปรับเปลี่ยนมากที่สุด: การเปลี่ยนแปลงโมเดลข้อมูล อินเทอร์เฟซประเภทใหม่ และอะไรก็ตามที่ผู้ใช้เห็น ฝังการรีแฟกเตอร์เชิงกลไว้ด้านล่าง ฉันเชื่อใจคุณในส่วนนั้น"
ระหว่างการดำเนินการ (During implementation)
บันทึกการดำเนินการ (Implementation notes)
เมื่อฉันพอใจกับแผนของฉันแล้ว ฉันจะสร้างเซสชันใหม่และส่งอาร์ติแฟกต์ใดๆ ไปยังพรอมต์ ตัวอย่างเช่น ฉันอาจส่งไฟล์สเปคและต้นแบบ และขอให้เอเจนต์ดำเนินการ
แต่ความจริงคือ ไม่ว่าคุณจะวางแผนมากแค่ไหน ก็มักจะมีสิ่งที่ไม่รู้ว่าไม่รู้ซ่อนอยู่เสมอ เอเจนต์อาจพบระหว่างการทำงานว่ามันต้องเปลี่ยนแนวทางเนื่องจากกรณีขอบที่มันพบในโค้ด
ฉันขอให้ Claude Code เก็บไฟล์ 'implementation-notes.md' (หรือ .html) ชั่วคราว ซึ่งมันจะบันทึกการตัดสินใจที่ทำไว้เพื่อให้เราเรียนรู้จากความพยายามครั้งต่อไป
ตัวอย่างพรอมต์:
- "เก็บบันทึกไฟล์ implementation-notes.md ไว้ ถ้าคุณเจอกรณีขอบที่บังคับให้คุณเบี่ยงเบนจากแผน ให้เลือกตัวเลือกที่อนุรักษ์นิยม บันทึกไว้ภายใต้ 'Deviations' และดำเนินการต่อ"
หลังการดำเนินการ (Post implementation)
การนำเสนอและคำอธิบาย (Pitches and explainers)
ส่วนที่สำคัญที่สุดอย่างหนึ่งในการส่งมอบสิ่งใดสิ่งหนึ่งคือการได้รับความเห็นชอบและการอนุมัติ การสร้างอาร์ติแฟกต์การนำเสนอและคำอธิบายในเอกสารสุดท้ายช่วย:
- เร่งความเข้าใจเมื่อผู้ตรวจทานเริ่มต้นด้วยสิ่งที่ไม่รู้แบบเดียวกับคุณ
- เร่งการอนุมัติเมื่อผู้เชี่ยวชาญต้องการเห็นว่าคุณได้คำนึงถึงสิ่งที่ไม่รู้และจุดล้มเหลวทั่วไปที่พวกเขาคาดการณ์ไว้
ตัวอย่างพรอมต์:
- "แพ็กเกจต้นแบบ สเปค และบันทึกการดำเนินการเป็นเอกสารเดียวที่ฉันสามารถวางใน Slack เพื่อขอความเห็นชอบ นำด้วย GIF สาธิต"
แบบทดสอบ (Quizzes)
หลังจากเซสชันการทำงานที่ยาวนาน Claude อาจทำสำเร็จมากกว่าที่ฉันคิดมาก การอ่าน diff ของโค้ดสามารถให้ความเข้าใจคร่าวๆ เกี่ยวกับสิ่งที่เกิดขึ้นเท่านั้น เนื่องจากพฤติกรรมส่วนใหญ่จะขึ้นอยู่กับเส้นทางโค้ดที่มีอยู่
การขอให้ Claude ทดสอบฉันเกี่ยวกับการเปลี่ยนแปลงหลังจากให้บริบทมากมายช่วยให้ฉันเข้าใจสิ่งที่เกิดขึ้น ฉันจะรวมโค้ดก็ต่อเมื่อผ่านแบบทดสอบอย่างสมบูรณ์แบบเท่านั้น
ตัวอย่างพรอมต์:
- “ฉันต้องการให้แน่ใจว่าฉันเข้าใจทุกอย่างที่เกิดขึ้นในการเปลี่ยนแปลงนี้ ช่วยให้ฉันรายงาน HTML เกี่ยวกับการเปลี่ยนแปลงเพื่อให้ฉันอ่านและเข้าใจพร้อมบริบท สัญชาตญาณ สิ่งที่ทำไป ฯลฯ และแบบทดสอบที่ด้านล่างเกี่ยวกับการเปลี่ยนแปลงที่ฉันต้องผ่าน”
สิ่งเหล่านี้รวมกันเป็นหนึ่ง: การเปิดตัว Fable
วิดีโอเปิดตัว Fable ถูกตัดต่อโดย Claude Code ทั้งหมด นี่เป็นโดเมนใหม่สำหรับฉัน และฉันไม่ใช่ผู้เชี่ยวชาญแต่อย่างใด
ดังนั้นฉันจึงเริ่มด้วยสิ่งที่ฉันรู้ ฉันรู้ว่า Claude สามารถใช้โค้ดในการตัดต่อวิดีโอและถอดเสียงได้ แต่ฉันไม่แน่ใจว่ามันแม่นยำพอหรือไม่ จากนั้นฉันขอให้ Claude อธิบายว่าการถอดเสียงอย่าง Whisper ทำงานอย่างไร และฉันจะสามารถตัดสิ่งต่างๆ เช่น คำอุทานหรือการหยุดยาวโดยใช้ ffmpeg ได้อย่างแม่นยำหรือไม่
ฉันต้องการให้ Claude สร้าง UI ที่สอดคล้องกับคำพูดของฉัน แต่ไม่แน่ใจว่ามันจะทำได้หรือไม่ ดังนั้นฉันจึงขอให้ Claude สร้างวิดีโอต้นแบบโดยใช้ Remotion และการถอดเสียงเพื่อดูว่ามันจะใช้งานได้หรือไม่
สุดท้าย ตัววิดีโอดูหม่นเล็กน้อย ซึ่งฉันรู้ว่าเป็นผลมาจากการปรับสี แต่ฉันไม่รู้จริงๆ ว่าการปรับสีคืออะไร ความพยายามครั้งแรกของฉันคือให้ Claude ทำการปรับแต่งสองสามแบบให้เลือก แต่ฉันตระหนักว่าฉันไม่รู้ว่าสิ่งที่ "ดี" เป็นอย่างไรเมื่อพูดถึงการปรับสี ดังนั้นฉันจึงขอให้ Claude สอนฉันเกี่ยวกับการปรับสีเพื่อค้นพบสิ่งที่ไม่รู้ของฉัน
คุณสามารถชม คำอธิบายเชิงลึกเพิ่มเติมเกี่ยวกับเรื่องนั้น [ได้ที่นี่](https://x.com/trq212/status/2064826394589442448/video/1)
การจับคู่แผนที่และพื้นที่จริง (Matching the Map and Territory)
ยิ่งโมเดลดีขึ้นเท่าไหร่ คุณก็ยิ่งบรรลุผลได้มากขึ้นด้วยแนวทางที่ถูกต้อง เมื่องานระยะยาวกลับมาผิดพลาด มีแนวโน้มว่าคุณต้องใช้เวลาเพิ่มเติมในการกำหนดสิ่งที่ไม่รู้ หรือสร้างแผนการดำเนินการที่ให้ Claude สามารถแก้ไขเฉพาะหน้าได้
ทุกคำอธิบาย การระดมความคิด การสัมภาษณ์ ต้นแบบ และการอ้างอิง เป็นวิธีต้นทุนต่ำในการค้นหาสิ่งที่คุณไม่รู้ ก่อนที่มันจะแพงในการแก้ไข
ดังนั้น เริ่มโปรเจกต์ถัดไปของคุณด้วยการขอให้ Claude ช่วยค้นหาสิ่งที่ไม่รู้ของคุณ
