แผนที่ไม่ใช่พื้นที่จริง
เวลาทำงานกับ Claude Code ผู้เขียนมักนึกถึงความแตกต่างระหว่าง “แผนที่” กับ “พื้นที่จริง”
แผนที่คือภาพแทนของงานที่ต้องทำ ประกอบด้วย Prompt, Skills, Context และข้อมูลทั้งหมดที่เราส่งให้ Claude
ส่วนพื้นที่จริงคือสถานที่ที่งานต้องเกิดขึ้นจริง เช่น Codebase ระบบเดิม สภาพแวดล้อมการทำงาน ความต้องการของผู้ใช้ และข้อจำกัดที่มีอยู่จริง
ช่องว่างระหว่างแผนที่กับพื้นที่จริงคือสิ่งที่ผู้เขียนเรียกว่า “Unknowns” หรือสิ่งที่ยังไม่รู้และยังไม่ได้กำหนดให้ชัดเจน
เมื่อ Claude พบ Unknown มันต้องตัดสินใจจากการคาดเดาที่ดีที่สุดว่าเราน่าจะต้องการอะไร ยิ่งมอบหมายงานขนาดใหญ่หรือให้งานดำเนินต่อเนื่องเป็นเวลานาน Claude ก็ยิ่งมีโอกาสพบจุดที่ต้องตัดสินใจเองมากขึ้น
สำหรับผู้เขียน Claude Fable เป็นโมเดลแรกที่ทำให้เขารู้สึกว่า คุณภาพของผลงานไม่ได้ติดขัดเพราะความสามารถของโมเดลอีกต่อไป แต่ติดขัดเพราะความสามารถของมนุษย์ในการอธิบายและทำให้ Unknowns ชัดเจน
อย่างไรก็ตาม การวางแผนล่วงหน้าเพียงอย่างเดียวไม่เพียงพอเสมอไป เพราะ Unknowns บางอย่างจะปรากฏขึ้นเมื่อเริ่มลงมือพัฒนาจริง หรือบางครั้งสิ่งที่ค้นพบอาจบอกว่า เราไม่ควรแก้ปัญหาด้วยแนวทางเดิมตั้งแต่แรก
การทำงานกับ Fable จึงไม่ใช่กระบวนการสั่งงานครั้งเดียวแล้วรอรับผลลัพธ์ แต่เป็นกระบวนการค้นหา Unknowns ซ้ำไปมา ทั้งก่อนลงมือ ระหว่างดำเนินงาน และหลังจากงานเสร็จ
ทำความรู้จัก Unknowns ของตัวเอง
เมื่อผู้เขียนนำปัญหามาทำงานร่วมกับ Claude เขาจะแบ่งความรู้และความไม่รู้ออกเป็นสี่ประเภท
1. Known Knowns: สิ่งที่เรารู้ว่าเรารู้
นี่คือข้อมูลที่อยู่ใน Prompt หรือคำสั่งโดยตรง เช่น
- เราต้องการสร้างอะไร
- ผลลัพธ์ควรทำหน้าที่อะไร
- กลุ่มผู้ใช้คือใคร
- มีเงื่อนไขอะไรบ้าง
- ต้องใช้เทคโนโลยีหรือรูปแบบใด
Known Knowns คือสิ่งที่เราสามารถบอก Claude ได้อย่างชัดเจนตั้งแต่ต้น
2. Known Unknowns: สิ่งที่เรารู้ว่ายังไม่รู้
เป็นเรื่องที่เรายังไม่มีคำตอบ แต่รู้ตัวว่าต้องหาคำตอบ เช่น
- ยังไม่รู้ว่าจะใช้ฐานข้อมูลแบบใด
- ยังตัดสินใจไม่ได้ว่าจะใช้หน้าจอรูปแบบใด
- ยังไม่ทราบว่า API รองรับปริมาณงานเท่าใด
- ยังไม่แน่ใจว่าผู้ใช้ต้องการขั้นตอนการใช้งานแบบไหน
แม้จะยังไม่มีคำตอบ แต่เราสามารถระบุเรื่องเหล่านี้ไว้ในแผน และให้ Claude ช่วยค้นคว้า ทดลอง หรือเสนอทางเลือกได้
3. Unknown Knowns: สิ่งที่เรารู้โดยไม่รู้ตัว
เป็นความรู้ที่อยู่ในประสบการณ์หรือความรู้สึกของเรา แต่เราไม่เคยเขียนออกมาอย่างชัดเจน
บางเรื่องดูชัดเจนจนเราไม่คิดว่าจำเป็นต้องบอก Claude แต่ถ้าเห็นสิ่งที่ไม่ถูกต้อง เราจะรู้ทันทีว่า “ไม่ใช่แบบนี้”
ตัวอย่างเช่น
- เราบอกไม่ได้ว่าหน้าจอที่ดีควรเป็นอย่างไร แต่รู้ทันทีเมื่อเห็นหน้าจอที่ดูไม่ดี
- เราอธิบายสไตล์การเขียนไม่ได้ละเอียด แต่รู้ว่าข้อความใดไม่ใช่น้ำเสียงของแบรนด์
- เราไม่ได้กำหนดกฎบางอย่าง เพราะคนในทีมเข้าใจร่วมกันอยู่แล้ว
- เรารู้ว่ากระบวนการหนึ่งไม่ควรทำแบบนั้นจากประสบการณ์ แต่ไม่เคยบันทึกเป็นเอกสาร
Unknown Knowns มักปรากฏขึ้นเมื่อเราเห็น Prototype ตัวอย่าง หรือผลงานที่ Claude สร้างขึ้น
4. Unknown Unknowns: สิ่งที่เราไม่รู้ด้วยซ้ำว่าเราไม่รู้
นี่คือส่วนที่อันตรายที่สุด เพราะเราไม่เคยนึกถึงเรื่องนั้นมาก่อน จึงไม่รู้ว่าจะต้องถามอะไร
ตัวอย่างเช่น
- ไม่รู้ว่ามีข้อจำกัดทางเทคนิคบางอย่าง
- ไม่รู้ว่าระบบเดิมมีประวัติหรือเหตุผลเบื้องหลังอย่างไร
- ไม่รู้ว่ามี Edge Case ที่อาจทำให้ระบบล้มเหลว
- ไม่รู้ว่ามีแนวทางที่ดีกว่าวิธีที่เรากำลังคิด
- ไม่รู้ว่ามาตรฐานของผลงานที่ดีจริง ๆ สามารถไปได้ไกลเพียงใด
นักพัฒนาที่ใช้ Agentic Coding ได้ดีมักมี Unknowns ค่อนข้างน้อย พวกเขารู้รายละเอียดว่าต้องการอะไร เข้าใจ Codebase และเข้าใจพฤติกรรมของโมเดล แต่ในขณะเดียวกัน พวกเขาก็ไม่ได้คิดว่าตัวเองรู้ทุกอย่าง พวกเขาคาดไว้ตั้งแต่ต้นว่าจะต้องมี Unknowns เกิดขึ้น
ดังนั้น ทักษะสำคัญของ Agentic Coding คือความสามารถในการลด Unknowns และวางระบบรองรับสิ่งที่ยังไม่รู้
ข่าวดีคือทักษะนี้สามารถฝึกฝนได้ผ่านการทำงานร่วมกับ Claude
ช่วยให้ Claude ช่วยคุณได้ดีขึ้น
การเขียนคำสั่งให้ Claude ต้องรักษาสมดุลระหว่างความละเอียดกับความยืดหยุ่น
ถ้าคำสั่งละเอียดเกินไป Claude อาจปฏิบัติตามทุกข้อ แม้ว่าระหว่างทางจะพบว่าแนวทางอื่นเหมาะสมกว่า
ถ้าคำสั่งกว้างเกินไป Claude จะต้องตัดสินใจและตั้งสมมติฐานเอง โดยมักอ้างอิงแนวปฏิบัติทั่วไปของอุตสาหกรรม ซึ่งอาจไม่เหมาะกับงานหรือองค์กรของคุณ
เมื่อไม่ได้คำนึงถึง Unknowns เราอาจพลาดได้ทั้งสองทาง
เราอาจไม่รู้ว่าเส้นทางที่กำหนดไว้เต็มไปด้วยอุปสรรค และ Claude ควรเปลี่ยนเส้นทาง หรือในทางกลับกัน เส้นทางเดิมอาจไม่มีปัญหา แต่คำสั่งที่เปิดกว้างเกินไปทำให้ Claude เปลี่ยนแนวทางโดยไม่จำเป็น
Claude สามารถช่วยค้นหา Unknowns ได้รวดเร็ว เพราะสามารถสำรวจ Codebase ค้นข้อมูล และเรียนรู้จากความล้มเหลวผ่านการทดลองซ้ำได้เร็วกว่ามนุษย์
สิ่งสำคัญคือการบอก Claude ว่าเราเริ่มต้นจากจุดใด เช่น
- ตอนนี้เราคิดเรื่องนี้ไปถึงไหนแล้ว
- เรามีประสบการณ์กับปัญหานี้มากน้อยเพียงใด
- เรารู้จัก Codebase หรือระบบเดิมแค่ไหน
- เรากำลังไม่แน่ใจเรื่องอะไร
- เราต้องการให้ Claude ช่วยคิดในฐานะผู้ร่วมแก้ปัญหาอย่างไร
แทนที่จะทำตัวเหมือนรู้ทุกอย่างแล้วออกคำสั่งอย่างมั่นใจ เราควรเปิดเผยระดับความรู้และความไม่รู้ของตัวเองให้ Claude เห็น
รูปแบบการทำงานเพื่อค้นหา Unknowns
ผู้เขียนแบ่งกระบวนการออกเป็นสามช่วง
ก่อนลงมือพัฒนา
- ตรวจสอบจุดบอด
- ระดมความคิดและทำต้นแบบ
- ให้ Claude สัมภาษณ์เรา
- ใช้ผลงานอ้างอิง
- จัดทำแผนการพัฒนา
ระหว่างการพัฒนา
- บันทึกการตัดสินใจและสิ่งที่เบี่ยงเบนจากแผน
หลังพัฒนาเสร็จ
- จัดทำเอกสารนำเสนอและคำอธิบาย
- ให้ Claude ทดสอบความเข้าใจของเราด้วยแบบทดสอบ
ก่อนลงมือพัฒนา
การตรวจสอบจุดบอด หรือ Blind Spot Pass
เมื่อเริ่มทำงาน สิ่งที่มีประโยชน์มากคือการค้นหาจุดบอดของตัวเอง
สถานการณ์ที่มี Unknown Unknowns จำนวนมากมักเกิดขึ้นเมื่อ
- ต้องสร้างฟีเจอร์ในส่วนของ Codebase ที่ไม่คุ้นเคย
- ต้องทำงานในสาขาที่ไม่มีประสบการณ์
- ใช้ Claude ช่วยออกแบบงานที่ไม่รู้มาตรฐาน
- ไม่รู้ว่าคำถามที่ถูกต้องควรถามว่าอะไร
- ไม่รู้ว่าผลงานที่ดีควรมีหน้าตาอย่างไร
- ไม่รู้ว่าทีมเคยทดลองหรือแก้ปัญหาเรื่องนี้อย่างไร
- ไม่รู้ว่ามีหลุมพรางอะไรที่ควรหลีกเลี่ยง
ในสถานการณ์เหล่านี้ เราสามารถขอให้ Claude ช่วยค้นหา Unknown Unknowns และอธิบายให้เราเข้าใจ
ผู้เขียนแนะนำให้ใช้คำว่า “blind spot pass” และ “unknown unknowns” อย่างตรงไปตรงมา พร้อมบอกบริบทว่าเราเป็นใคร มีประสบการณ์เพียงใด และรู้อะไรเกี่ยวกับปัญหานี้แล้วบ้าง
ตัวอย่าง Prompt:
“ผมกำลังเพิ่มผู้ให้บริการ Authentication รายใหม่ แต่ไม่รู้อะไรเกี่ยวกับ Auth Modules ใน Codebase นี้เลย ช่วยทำ Blind Spot Pass เพื่อค้นหา Unknown Unknowns ที่เกี่ยวข้อง และช่วยให้ผมเขียน Prompt เพื่อทำงานกับคุณได้ดีขึ้น”
อีกตัวอย่างหนึ่ง:
“ผมไม่รู้ว่า Color Grading คืออะไร แต่ต้องปรับสีวิดีโอนี้ ช่วยสอนให้ผมเข้าใจ Unknown Unknowns เกี่ยวกับ Color Grading เพื่อให้ผมสั่งงานคุณได้ดีขึ้น”
หัวใจสำคัญไม่ใช่การถาม Claude ให้ลงมือทำทันที แต่ให้ Claude ช่วยเราค้นหาว่า ก่อนเริ่มทำงานเราควรรู้อะไรบ้าง
การระดมความคิดและสร้างต้นแบบ
เมื่อต้องทำงานกับ Unknown Knowns หรือสิ่งที่เรารู้เมื่อเห็น แต่ยังอธิบายไม่ได้ ผู้เขียนจะให้ Claude ช่วยระดมความคิดและสร้าง Prototype หลายรูปแบบ
การค้นหาและพูดสิ่งเหล่านี้ออกมาให้เร็วมีคุณค่ามาก เพราะหากเพิ่งค้นพบความต้องการที่แท้จริงในช่วงลงมือพัฒนา การเปลี่ยนแปลงอาจมีต้นทุนสูง
การแก้ไขข้อกำหนดเพียงเล็กน้อยอาจทำให้โครงสร้างการพัฒนาต่างออกไปมาก และเมื่อ Agent แก้ไข Codebase ไปแล้ว การย้อนกลับอาจไม่ง่าย
ตัวอย่างเช่น หากต้องการดูว่าปุ่มใหม่ควรอยู่ตรงไหน เราไม่จำเป็นต้องเชื่อม Backend Route หรือสร้าง State จริงทั้งหมดก่อน ควรให้ Claude ทำหน้าจอจำลองเพื่อดูและแสดงความคิดเห็นกับรูปแบบก่อน
งานออกแบบภาพเป็นตัวอย่างที่ชัดเจน ผู้เขียนอาจอธิบายสิ่งที่ต้องการไม่ได้ แต่เมื่อเห็นตัวเลือกหลายแบบ เขาจะบอกได้ว่าแบบใดใกล้เคียงหรือไม่ตรงใจ
ผู้เขียนจึงเริ่มการเขียนโค้ดเกือบทุกครั้งด้วยช่วงสำรวจหรือระดมความคิด เพื่อกำหนดขอบเขตของโครงการจากเจตนาที่แท้จริง
Claude อาจเสนอแนวทางที่มีคุณค่าและผู้เขียนไม่เคยนึกถึง แต่บางครั้ง Claude ก็อาจจดจ่อกับรายละเอียดจนมองไม่เห็นภาพรวม การระดมความคิดก่อนเริ่มจึงช่วยป้องกันการกำหนดขอบเขตที่แคบหรือกว้างเกินไป
ตัวอย่าง Prompt:
“ผมต้องการ Dashboard สำหรับข้อมูลชุดนี้ แต่ไม่มีรสนิยมด้านการออกแบบ และไม่รู้ว่าสามารถทำอะไรได้บ้าง ช่วยสร้างหน้า HTML ที่มีแนวทางการออกแบบแตกต่างกันอย่างมากสี่แบบ เพื่อให้ผมดูแล้วแสดงความคิดเห็น”
“ก่อนเชื่อมระบบจริง ช่วยสร้างไฟล์ HTML เดียวที่จำลองแถบเครื่องมือของ Editor ใหม่ โดยใช้ข้อมูลสมมติ ผมต้องการดูและแสดงความคิดเห็นกับ Layout ก่อนที่คุณจะแก้ไขแอปจริง”
“ปัญหาคร่าว ๆ คือผู้ใช้เลิกใช้งานหลังผ่าน Onboarding ช่วยค้นใน Codebase และเสนอจุดที่เราสามารถเข้าไปแก้ปัญหาได้สิบจุด เรียงจากวิธีที่ต้นทุนต่ำที่สุดไปจนถึงแนวทางที่ทะเยอทะยานที่สุด แล้วผมจะบอกว่าวิธีใดตรงกับสิ่งที่ต้องการ”
ให้ Claude สัมภาษณ์เรา
หลังระดมความคิดแล้ว มักยังมี Unknowns เหลืออยู่
ผู้เขียนจะขอให้ Claude สัมภาษณ์เกี่ยวกับสิ่งที่คลุมเครือหรือยังไม่ได้ตัดสินใจ โดยให้บริบทของปัญหาเพื่อช่วยให้ Claude ตั้งคำถามได้ตรงประเด็น
ตัวอย่าง Prompt:
“สัมภาษณ์ผมทีละคำถามเกี่ยวกับทุกเรื่องที่ยังคลุมเครือ โดยให้ความสำคัญกับคำถามที่คำตอบของผมอาจทำให้สถาปัตยกรรมระบบเปลี่ยนไป”
คำว่า “ทีละคำถาม” มีความสำคัญ เพราะช่วยให้การสนทนามีสมาธิ เราสามารถตอบ ขยายความ และค้นพบความคิดของตัวเองได้ดีกว่าการได้รับคำถามยาว ๆ พร้อมกันหลายสิบข้อ
คำถามควรเรียงตามผลกระทบ ไม่ใช่ถามทุกเรื่องเท่ากัน โดยเฉพาะเรื่องที่อาจทำให้ต้องเปลี่ยน
- สถาปัตยกรรมระบบ
- โครงสร้างข้อมูล
- กระบวนการใช้งาน
- ขอบเขตงาน
- ความปลอดภัย
- สิทธิ์การเข้าถึง
- การเชื่อมต่อระบบภายนอก
ใช้ References แทนการอธิบายทั้งหมด
บางครั้งเราไม่สามารถอธิบายสิ่งที่ต้องการได้อย่างละเอียด เพราะไม่มีคำศัพท์เฉพาะ หรือสิ่งนั้นซับซ้อนจนต้องใช้เวลานานในการเขียนคำอธิบาย
วิธีที่ดีกว่าคือให้ Reference
Reference อาจเป็น
- แผนภาพ
- เอกสาร
- ภาพหน้าจอ
- รูปภาพ
- ระบบเดิม
- Component ที่ชอบ
- Library ที่มีพฤติกรรมใกล้เคียง
- Source Code ของโครงการอื่น
ผู้เขียนเห็นว่า Reference ที่ดีที่สุดคือ Source Code
ถ้ามี Library ที่ทำงานในรูปแบบที่ต้องการ หรือมี Design Component ที่ชอบ ให้ชี้ Claude ไปยัง Folder นั้น แล้วบอกว่าต้องการให้สังเกตอะไร แม้ Source Code จะเขียนด้วยภาษาโปรแกรมคนละภาษาก็ตาม
Source Code ให้รายละเอียดเกี่ยวกับโครงสร้าง Markup พฤติกรรม และตรรกะการทำงานได้มากกว่าภาพหน้าจอ
ตัวอย่าง Prompt:
“Rust Crate ใน vendor/rate-limiter ใช้พฤติกรรม Backoff แบบเดียวกับที่ผมต้องการ ช่วยอ่านโค้ดนั้น แล้วนำ Semantics แบบเดียวกันมาสร้างใหม่ใน TypeScript API Client ของเรา”
แนวคิดคือไม่จำเป็นต้องพยายามแปลงทุกอย่างในหัวให้เป็นคำพูด เมื่อมีหลักฐานหรือตัวอย่างที่ Claude สามารถศึกษาได้โดยตรง
จัดทำ Implementation Plan
เมื่อผู้เขียนรู้สึกว่าพร้อมเริ่มพัฒนา เขาจะให้ Claude จัดทำ Implementation Plan เพื่อให้ตรวจสอบก่อน
แผนควรเน้นส่วนที่มีโอกาสเปลี่ยนแปลงหรือมีผลต่อโครงสร้างมากที่สุด เช่น
- การเปลี่ยนแปลง Data Model
- Type Interfaces ใหม่
- UX Flow
- สิ่งที่ผู้ใช้จะเห็นหรือมีปฏิสัมพันธ์
- การตัดสินใจด้านสถาปัตยกรรม
- การเชื่อมต่อระบบ
- ข้อจำกัดหรือ Trade-off สำคัญ
สิ่งเหล่านี้ควรอยู่ด้านบนของแผน เพราะเป็นส่วนที่มนุษย์ควรตรวจสอบและตัดสินใจ
ส่วนงานเชิงกล เช่น การ Refactor ที่ตรงไปตรงมา อาจวางไว้ด้านล่าง เพราะผู้เขียนเชื่อถือให้ Claude จัดการรายละเอียดเหล่านั้นได้
ตัวอย่าง Prompt:
“เขียน Implementation Plan ในรูปแบบ HTML แต่ให้เริ่มด้วยการตัดสินใจที่ผมน่าจะต้องการแก้ไขมากที่สุด ได้แก่ การเปลี่ยน Data Model, Type Interfaces ใหม่ และทุกอย่างที่ผู้ใช้จะเห็น ส่วนงาน Refactoring เชิงกลให้นำไปไว้ด้านล่าง เพราะผมเชื่อใจให้คุณจัดการส่วนนั้น”
แผนการพัฒนาจึงไม่ใช่เอกสารพิธีการ แต่เป็นเครื่องมือสำหรับทำให้ Unknowns ปรากฏขึ้นก่อนเริ่มแก้ Codebase จริง
ระหว่างการพัฒนา
เก็บ Implementation Notes
เมื่อพอใจกับแผนแล้ว ผู้เขียนจะเปิด Session ใหม่ และส่งสิ่งที่ได้จากช่วงวางแผนเข้าไปเป็น Context เช่น
- Specification
- Prototype
- เอกสารประกอบ
- Reference
- Implementation Plan
การเปิด Session ใหม่ทำให้ Claude มี Context Window ที่สะอาด แต่ยังได้รับข้อมูลที่ผ่านการคิดและรวบรวมจากกระบวนการวางแผน
อย่างไรก็ตาม ไม่ว่าจะวางแผนละเอียดแค่ไหน Unknown Unknowns ก็ยังสามารถปรากฏขึ้นได้
ระหว่างทำงาน Agent อาจพบ Edge Case ใน Codebase ที่ทำให้ต้องเปลี่ยนแนวทาง หรือพบว่าบางสิ่งไม่สามารถทำตามแผนเดิมได้
ผู้เขียนจึงให้ Claude Code สร้างไฟล์ชั่วคราวชื่อ implementation-notes.md หรือ implementation-notes.html เพื่อบันทึกการตัดสินใจที่เกิดขึ้นระหว่างทำงาน
ตัวอย่าง Prompt:
“เก็บไฟล์ implementation-notes.md ไว้ หากพบ Edge Case ที่บังคับให้คุณต้องเบี่ยงเบนจากแผน ให้เลือกแนวทางที่ระมัดระวังที่สุด บันทึกเหตุผลไว้ในหัวข้อ Deviations แล้วทำงานต่อ”
แนวทางนี้เปิดโอกาสให้ Agent เดินหน้าต่อได้ โดยไม่ต้องหยุดถามทุกครั้ง แต่ยังรักษาร่องรอยของการตัดสินใจไว้ให้มนุษย์ตรวจสอบ
Implementation Notes ควรบันทึกอย่างน้อยว่า
- พบปัญหาอะไร
- จุดใดไม่เป็นไปตามแผน
- Claude เลือกแนวทางใด
- มีเหตุผลอะไร
- มีผลกระทบกับส่วนใด
- เรื่องใดต้องกลับมาตรวจสอบ
- สมมติฐานใดถูกสร้างขึ้นระหว่างทาง
ข้อมูลเหล่านี้ยังช่วยให้การทำงานรอบถัดไปดีขึ้น เพราะเราสามารถนำ Unknowns ที่ค้นพบไปปรับ Prompt, Specification และแผนในครั้งต่อไป
หลังการพัฒนา
สร้างเอกสาร Pitch และ Explainer
การสร้างบางสิ่งเสร็จทางเทคนิคไม่ได้หมายความว่างานจบแล้ว การส่งมอบงานมักต้องได้รับความเห็นชอบและการอนุมัติจากคนอื่น
ผู้ตรวจสอบอาจเริ่มต้นด้วย Unknowns แบบเดียวกับที่ผู้พัฒนาเคยมี เช่น
- ระบบนี้แก้ปัญหาอะไร
- ทำไมเลือกแนวทางนี้
- มีความเสี่ยงอะไร
- พิจารณาทางเลือกอื่นหรือยัง
- รองรับกรณีผิดพลาดหรือไม่
- มีข้อจำกัดอะไร
- การเปลี่ยนแปลงกระทบส่วนใด
การรวม Prototype, Specification และ Implementation Notes เป็นเอกสารอธิบายฉบับเดียว ช่วยให้ผู้ตรวจสอบเข้าใจงานได้เร็วขึ้น
นอกจากนี้ ยังช่วยเร่งการอนุมัติจากผู้เชี่ยวชาญ เพราะพวกเขาจะมองเห็นว่า ทีมได้พิจารณา Unknowns และจุดล้มเหลวที่มักเกิดขึ้นแล้ว
ตัวอย่าง Prompt:
“รวม Prototype, Specification และ Implementation Notes เป็นเอกสารเดียวที่ผมสามารถส่งใน Slack เพื่อขอความเห็นชอบได้ โดยเริ่มต้นด้วย GIF สาธิตการทำงาน”
เอกสารที่ดีจึงไม่ควรบอกเพียงว่าสร้างอะไร แต่ควรช่วยให้คนอื่นเดินผ่านกระบวนการทำความเข้าใจที่ทีมเคยผ่านมาก่อน
ให้ Claude ทำแบบทดสอบความเข้าใจ
หลังจากทำงานกับ Claude เป็นเวลานาน Claude อาจเปลี่ยนแปลงหรือสร้างสิ่งต่าง ๆ มากกว่าที่เรารับรู้
การอ่าน Code Diff อาจทำให้เข้าใจได้เพียงบางส่วน เพราะพฤติกรรมจริงของระบบอาจขึ้นอยู่กับ Code Path เดิม การตั้งค่า และความสัมพันธ์กับส่วนอื่นของระบบ
ผู้เขียนจึงให้ Claude สร้างรายงานอธิบายการเปลี่ยนแปลง แล้วทำแบบทดสอบท้ายรายงาน
เขาจะ Merge งานต่อเมื่อสามารถตอบแบบทดสอบได้ถูกต้องทั้งหมด
ตัวอย่าง Prompt:
“ผมต้องการมั่นใจว่าเข้าใจทุกอย่างที่เกิดขึ้นในการเปลี่ยนแปลงครั้งนี้ ช่วยสร้างรายงาน HTML อธิบายการเปลี่ยนแปลง โดยให้ทั้งบริบท แนวคิด เหตุผล และรายละเอียดว่าสิ่งใดถูกทำไปแล้ว จากนั้นใส่แบบทดสอบเกี่ยวกับการเปลี่ยนแปลงไว้ด้านล่าง ซึ่งผมต้องตอบให้ผ่าน”
แนวทางนี้เปลี่ยนบทบาทมนุษย์จากคนที่เพียงตรวจว่าโค้ดดูดีหรือไม่ ให้เป็นเจ้าของระบบที่ต้องเข้าใจสิ่งที่กำลังจะอนุมัติ
ตัวอย่างจริง: การสร้างวิดีโอเปิดตัว Fable
ผู้เขียนยกตัวอย่างการตัดต่อวิดีโอเปิดตัว Fable ซึ่งทำตั้งแต่ต้นจนจบโดยใช้ Claude Code
งานตัดต่อวิดีโอเป็นสาขาใหม่สำหรับเขา และเขาไม่ได้เป็นผู้เชี่ยวชาญ จึงเริ่มจากสิ่งที่รู้ก่อน
เขารู้ว่า Claude สามารถใช้โค้ดช่วยตัดต่อและถอดเสียงวิดีโอได้ แต่ยังไม่แน่ใจว่าความแม่นยำเพียงพอหรือไม่
เขาจึงให้ Claude อธิบายว่าเทคโนโลยีถอดเสียงอย่าง Whisper ทำงานอย่างไร และสามารถใช้ ffmpeg ตัดคำอุทาน เช่น “เอ่อ” หรือช่วงหยุดยาวออกได้แม่นยำเพียงใด
ต่อมา เขาต้องการสร้างส่วนติดต่อผู้ใช้ที่เคลื่อนไหวตรงกับคำพูดในวิดีโอ แต่ไม่รู้ว่าแนวคิดนี้ทำได้จริงหรือไม่ เขาจึงให้ Claude ใช้ Remotion และข้อมูลจากการถอดเสียงสร้างวิดีโอต้นแบบก่อน
การทำ Prototype ช่วยทดสอบความเป็นไปได้โดยไม่ต้องสร้างระบบเต็มรูปแบบ
สุดท้าย เขารู้สึกว่าสีของวิดีโอดูหม่น เขารู้ว่าปัญหาน่าจะเกี่ยวข้องกับ Color Grading แต่ไม่เข้าใจว่า Color Grading คืออะไร
ในตอนแรก เขาพยายามให้ Claude สร้างการปรับสีหลายแบบเพื่อเลือก แต่พบว่าปัญหาที่แท้จริงคือ เขาไม่รู้ว่าการปรับสีที่ “ดี” ควรเป็นอย่างไร
แทนที่จะสั่งให้ Claude สุ่มสร้างตัวเลือกเพิ่ม เขาจึงเปลี่ยนไปขอให้ Claude สอนเรื่อง Color Grading เพื่อช่วยค้นหา Unknowns ของตัวเองก่อน
ตัวอย่างนี้สะท้อนกระบวนการทั้งหมด ได้แก่
- เริ่มจากสิ่งที่รู้
- ระบุสิ่งที่รู้ว่ายังไม่รู้
- ขอให้ Claude อธิบายหลักการ
- สร้าง Prototype เพื่อทดสอบความเป็นไปได้
- ดูผลงานเพื่อค้นหา Unknown Knowns
- ยอมรับว่าไม่รู้มาตรฐานของงานที่ดี
- ขอให้ Claude ช่วยค้นหา Unknown Unknowns
- ใช้ความรู้ใหม่ปรับ Prompt และผลงาน
ทำให้แผนที่ตรงกับพื้นที่จริง
เมื่อโมเดลมีความสามารถมากขึ้น สิ่งที่มนุษย์สามารถทำได้ก็เพิ่มขึ้นตามไปด้วย แต่ความสำเร็จไม่ได้ขึ้นอยู่กับความสามารถของโมเดลเพียงอย่างเดียว
ถ้างานระยะยาวกลับมาผิดจากที่ต้องการ สาเหตุอาจไม่ใช่เพราะ Claude ทำงานไม่ได้ แต่อาจเป็นเพราะเราใช้เวลาน้อยเกินไปในการกำหนด Unknowns หรือไม่มี Implementation Plan ที่เปิดโอกาสให้มนุษย์กับ Claude ปรับตัวเมื่อพบข้อมูลใหม่
กิจกรรมต่าง ๆ เช่น
- การขอคำอธิบาย
- การระดมความคิด
- การสัมภาษณ์
- การสร้าง Prototype
- การให้ Reference
- การจัดทำแผน
- การบันทึกสิ่งที่เปลี่ยนแปลง
- การสร้างแบบทดสอบ
ล้วนเป็นวิธีต้นทุนต่ำในการค้นหาสิ่งที่เราไม่รู้ ก่อนที่สิ่งเหล่านั้นจะกลายเป็นปัญหาที่มีต้นทุนสูงในการแก้ไข
ดังนั้น ก่อนเริ่มโครงการครั้งต่อไป อย่าเริ่มต้นด้วยการสั่ง Claude ให้ลงมือทำทั้งหมดทันที แต่ให้เริ่มจากการขอให้ Claude ช่วยค้นหาว่า “เรายังไม่รู้อะไร”
แนวคิดสำคัญที่นำไปใช้ได้ทันที
บทความนี้เปลี่ยนแนวคิดเรื่อง Prompt Engineering จากการเขียนคำสั่งที่สมบูรณ์แบบ ไปเป็นการออกแบบกระบวนการเรียนรู้ร่วมกับ AI
เราไม่จำเป็นต้องรู้ทุกอย่างก่อนเริ่มต้น แต่ควรบอก AI อย่างซื่อสัตย์ว่าเรารู้อะไร ไม่รู้อะไร และยังไม่แน่ใจเรื่องใด
แทนที่จะใช้ Prompt เดียวสั่งงานทั้งหมด ควรแบ่งการทำงานออกเป็นหลายรอบ ได้แก่
- ให้ Claude สำรวจจุดบอด
- ให้ Claude เสนอแนวทางหลายแบบ
- สร้าง Prototype ขนาดเล็ก
- ให้ Claude สัมภาษณ์เพื่อปิดช่องว่าง
- ใช้ Reference แทนคำอธิบายที่ไม่ชัด
- ทำ Implementation Plan
- บันทึกการเบี่ยงเบนระหว่างลงมือ
- สร้างเอกสารอธิบายหลังงานเสร็จ
- ทดสอบว่ามนุษย์เข้าใจสิ่งที่ AI ทำหรือไม่
โมเดลที่เก่งขึ้นไม่ได้ทำให้มนุษย์หมดความสำคัญ แต่ย้ายบทบาทของมนุษย์จากผู้ลงมือทำรายละเอียดทุกอย่าง ไปเป็นผู้กำหนดเจตนา ค้นหาจุดที่ยังไม่ชัด ตัดสินใจเรื่องสำคัญ และรับผิดชอบต่อผลลัพธ์สุดท้าย
ที่มาบทความ : https://claude.com/blog/a-field-guide-to-claude-fable-finding-your-unknowns
