คู่มือภาคสนาม Fable: ค้นหา Unknowns ของฉัน

• แก่นของการทำงานกับ Claude Fable 5 คือการค้นหาและลดช่องว่างระหว่าง แผนที่ (map: พรอมป์ต์·สกิล·คอนเท็กซ์) ที่ผู้ใช้ให้มา กับ อาณาเขต (territory: โค้ดเบส·ความเป็นจริง·ข้อจำกัด) ที่งานเกิดขึ้นจริง หรือก็คือ สิ่งที่ยังไม่รู้ (unknowns)
• Fable เป็นโมเดลแรกที่คุณภาพงานขึ้นอยู่กับ ความสามารถของผู้ใช้ในการทำให้ unknowns ชัดเจน และยิ่งงานมีปริมาณมาก unknowns ที่ต้องเจอก็ยิ่งเพิ่มขึ้น
• unknowns แบ่งได้เป็น 4 ประเภท ได้แก่ Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns และหัวใจของ agentic coding คือการลดและเตรียมรับมือกับ unknowns
• ค้นพบ unknowns ด้วยเทคนิคแบบวนซ้ำตลอดช่วง ก่อน·ระหว่าง·หลัง การอิมพลีเมนต์ เช่น blindspot pass, brainstorming, interview, reference, implementation plan, implementation notes และ quiz
• คำอธิบาย·brainstorming·interview·prototype·reference คือวิธีค้นพบ unknowns อย่างประหยัด ก่อนที่ปัญหาจะแพงขึ้น และสิ่งสำคัญคือเริ่มโปรเจกต์ถัดไปด้วยการขอให้ Claude ช่วยหา unknowns

---

แผนที่ อาณาเขต และ Unknowns

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

รู้จัก unknowns ของคุณ (Knowing your unknowns)

• แยกปัญหาออกเป็น 4 ประเภท
  • Known Knowns: สิ่งที่อยู่ในพรอมป์ต์ สิ่งที่คุณบอกเอเจนต์ว่าต้องการ
  • Known Unknowns: สิ่งที่ยังไม่เข้าใจ แต่ตระหนักว่าตัวเองยังไม่เข้าใจ
  • Unknown Knowns: สิ่งที่ชัดเจนเกินไปจนไม่ได้จดไว้ แต่พอเห็นแล้วก็รู้ทันที
  • Unknown Unknowns: สิ่งที่ไม่ได้พิจารณาเลย ความรู้ที่ยังไม่ตระหนักว่าขาดอยู่ หรือไม่รู้ว่าสิ่งนั้นสามารถดีขึ้นได้มากแค่ไหน
• agentic coder ที่เก่งจะมี unknowns ค่อนข้างน้อย และ ซิงก์เชิงลึก (in-sync) กับโค้ดเบสและพฤติกรรมของโมเดล ทำให้รู้รายละเอียดของสิ่งที่ต้องการ
• การลดและเตรียมรับมือ unknowns คือ ทักษะที่พัฒนาได้ผ่านการทำงานกับ Claude

ช่วยให้ Claude ช่วยคุณได้ดีขึ้น (Help Claude help you)

• คำสั่งต้องสมดุล หากเฉพาะเจาะจงเกินไป โมเดลจะทำตามแม้ในสถานการณ์ที่ควรเปลี่ยนทิศทาง แต่หากกำกวมเกินไป ก็จะเลือกตาม best practices ของวงการที่อาจไม่เหมาะกับงาน
• หากไม่คำนึงถึง unknowns ก็จะล้มเหลวทั้งสองด้าน และคุณจะคาดหวังให้ Claude เปลี่ยนทิศทางโดยไม่รู้ว่าเส้นทางตันหรือไปต่อได้เมื่อใด
• Claude ช่วยเร่งการค้นหา unknowns ได้ เพราะค้นโค้ดเบส·อินเทอร์เน็ตได้เร็ว รู้หัวข้อทั่วไปมากกว่า และ วนซ้ำจากความล้มเหลวได้เร็ว
• สิ่งสำคัญที่สุดคือ ให้คอนเท็กซ์เกี่ยวกับจุดเริ่มต้น โดยบอกว่าคุณอยู่ตรงไหนในกระบวนการคิด มีประสบการณ์กับปัญหาและโค้ดเบสแค่ไหน และร่วมงานกับมันเหมือนเป็นคู่คิด
• เคยเขียนเกี่ยวกับ การใช้ HTML ใน Claude มาก่อน ซึ่งโดยมาก HTML artifact เหมาะที่สุดสำหรับการทำ visualization และการนำเสนอ

ก่อนอิมพลีเมนต์ (Pre-implementation)

• Blind Spot Pass

  • ในงานที่ไม่คุ้นเคย เช่น การเขียนฟีเจอร์ในพื้นที่ใหม่หรือการวนปรับดีไซน์ จะมี unknown unknowns จำนวนมาก และคุณอาจไม่รู้ว่าควรถามอะไร อะไรคือสิ่งที่ดี งานก่อนหน้าเป็นอย่างไร หรือหลุมพรางที่ควรหลีกเลี่ยงคืออะไร
  • ขอให้ Claude ค้นหาและอธิบาย unknown unknowns โดยใช้คำว่า "blindspot pass" และ "unknown unknowns" ตามนั้น และสิ่งสำคัญคือให้คอนเท็กซ์ว่าคุณเป็นใครและรู้อะไรอยู่แล้ว
  • ตัวอย่างพรอมป์ต์
    • "กำลังเพิ่ม auth provider ใหม่ แต่ไม่รู้จักโมดูล auth ของโค้ดเบสนี้เลย ช่วยทำ blindspot pass เพื่อระบุ unknown unknowns ที่เกี่ยวข้อง และช่วยให้ฉันเขียนพรอมป์ต์ได้ดีขึ้น"
    • "ฉันไม่รู้ว่า color grading คืออะไร แต่ต้อง grade วิดีโอนี้ ช่วยสอนให้เข้าใจ unknown unknowns ของ color grading เพื่อให้พรอมป์ต์ได้ดีขึ้น"

• Brainstorming และ Prototype (Brainstorms and prototypes)

  • ในพื้นที่ที่มี unknown knowns มาก หรือมีเกณฑ์จำนวนมากที่พอเห็นแล้วรู้ แต่กำหนดล่วงหน้าได้ยาก ให้ทำ brainstorming และ prototype กับ Claude
  • การระบุและทำให้ unknown knowns กลายเป็นภาษาตั้งแต่ ช่วงต้นของการทำ prototype แทนที่จะรอระหว่างอิมพลีเมนต์นั้นมีคุณค่า เพราะการเปลี่ยนสเปกเพียงเล็กน้อยอาจทำให้โค้ดที่อิมพลีเมนต์เปลี่ยนไปมาก และการย้อนการเปลี่ยนแปลงก่อนหน้าอาจทำได้ยาก
    • เช่น เมื่อต้องการแค่ดูว่าการเพิ่มปุ่มในเฟรมจะเป็นอย่างไร โดยยังไม่ต้องมี backend route หรือ frontend state
  • งานออกแบบเชิงภาพเป็นพื้นที่ที่อธิบายให้ชัดเจนได้ยาก แต่เมื่อเห็นแล้วรู้ว่าต้องการอะไร จึงควรขอแนวทางดีไซน์หลายแบบ
  • แทบทุกเซสชันเขียนโค้ดควร เริ่มด้วยช่วงสำรวจ·brainstorming เพื่อกำหนดขอบเขตอย่างมีเจตนา ซึ่งช่วยป้องกันไม่ให้ขอบเขตแคบหรือกว้างเกินไป
  • ตัวอย่างพรอมป์ต์
    • "ฉันอยากได้แดชบอร์ดสำหรับข้อมูลนี้ แต่ไม่มีเซนส์ด้านภาพและไม่รู้ว่าอะไรทำได้บ้าง ช่วยสร้างหน้า HTML ที่มีทิศทางดีไซน์แตกต่างกันสิ้นเชิง 4 แบบ เพื่อให้ฉันตอบสนองต่อสิ่งที่เห็นได้"
    • "ก่อนทำงานเชื่อมต่อ ช่วยทำไฟล์ HTML เดี่ยวที่ mockup toolbar ของ editor ใหม่ด้วยข้อมูลปลอม ฉันอยากตอบสนองต่อเลย์เอาต์ก่อนแตะแอปจริง"
    • "ปัญหาโดยคร่าวคือผู้ใช้หลุดหลัง onboarding ช่วยค้นโค้ดเบสและ brainstorm จุดที่แทรกแซงได้ 10 จุด ตั้งแต่ถูกที่สุดไปจนถึงทะเยอทะยานที่สุด"

• Interview

  • หากยังมี unknowns เหลือหลัง brainstorming เพียงพอแล้ว ให้ขอให้ Claude สัมภาษณ์ เกี่ยวกับ unknowns และความกำกวม โดยให้คอนเท็กซ์ของปัญหาเพื่อชี้นำคำถาม
  • ตัวอย่างพรอมป์ต์
    • "ถามส่วนที่กำกวมทีละคำถาม และให้ความสำคัญกับคำถามที่คำตอบของฉันจะเปลี่ยนสถาปัตยกรรมก่อน"

• Reference

  • เมื่อไม่สามารถบรรยายสิ่งที่ต้องการได้อย่างละเอียด คำตอบที่ดีที่สุดคือ reference ซึ่งอาจเป็นไดอะแกรม เอกสาร หรือภาพก็ได้ แต่ ซอร์สโค้ดคือ reference ที่ดีที่สุดอย่างเด็ดขาด
  • หากมีไลบรารีที่อิมพลีเมนต์ในแนวทางเฉพาะ หรือคอมโพเนนต์ดีไซน์ที่ชอบ ให้ชี้ไปที่โฟลเดอร์นั้น แม้จะเป็นภาษาอื่น และสั่งให้ค้นหา
  • Claude Design ก็ใช้วิธีเดียวกัน หากชี้ไปยังโมดูลของเว็บไซต์ที่ชอบ มันจะอ่าน โค้ดพื้นฐาน ไม่ใช่สกรีนช็อต และให้ข้อมูลมากมายเกี่ยวกับมาร์กอัป โครงสร้าง และวิธีอิมพลีเมนต์จริง
  • ตัวอย่างพรอมป์ต์
    • "Rust crate ตัวนี้ใน vendor/rate-limiter อิมพลีเมนต์พฤติกรรม backoff ที่ต้องการได้ตรงเป๊ะ อ่านแล้วนำความหมายเดียวกันมาอิมพลีเมนต์ใหม่ใน TypeScript API client ของเรา"

• Implementation Plans

  • เมื่อพร้อมอิมพลีเมนต์ ให้ขอ implementation plan สำหรับรีวิว โดยโฟกัสที่ ส่วนที่มีแนวโน้มเปลี่ยนมากที่สุด (data model, type interface, UX flow) เพื่อทำให้จุดที่ต้องแก้ไขปรากฏขึ้นมา
  • ตัวอย่างพรอมป์ต์
    • "เขียน implementation plan เป็น HTML โดยนำการตัดสินใจที่ฉันน่าจะแก้มากที่สุด (การเปลี่ยน data model, type interface ใหม่, องค์ประกอบที่ผู้ใช้เห็น) ไว้ด้านหน้า และย้าย mechanical refactoring ไปไว้ท้ายสุด"

ระหว่างอิมพลีเมนต์ (During implementation)

• Implementation notes

  • เมื่อพอใจกับแผนแล้ว ให้สร้างเซสชันใหม่ ส่ง artifact เช่นไฟล์สเปก·prototype เข้าไปในพรอมป์ต์ และขอให้เอเจนต์อิมพลีเมนต์
  • ต่อให้วางแผนอย่างไร unknown unknowns ก็ยังซ่อนอยู่เสมอ และเอเจนต์อาจพบ edge case ระหว่างทำงานที่ทำให้ต้องเลือกแนวทางอื่น
  • ให้ Claude Code บันทึกการตัดสินใจลงในไฟล์ชั่วคราว implementation-notes.md (หรือ .html) เพื่อให้ความพยายามครั้งถัดไปได้เรียนรู้
  • ตัวอย่างพรอมป์ต์
    • "ดูแลไฟล์ implementation-notes.md ไว้ หากเจอ edge case ที่ทำให้ต้องออกนอกแผน ให้เลือกแบบ conservative แล้วบันทึกไว้ใน 'Deviations' จากนั้นทำต่อ"

หลังอิมพลีเมนต์ (Post implementation)

• Pitch และเอกสารอธิบาย (Pitches and explainers)

  • หนึ่งในส่วนสำคัญที่สุดของการปล่อยสิ่งใดสิ่งหนึ่งคือ การได้ความเห็นชอบและการอนุมัติ ซึ่งการทำ pitch และ artifact อธิบายในเอกสารสุดท้ายช่วยได้
    • เมื่อ reviewer เริ่มจาก unknowns เดียวกับคุณ จะช่วย เร่งความเข้าใจ
    • เมื่อผู้เชี่ยวชาญต้องการตรวจว่าคุณได้พิจารณา unknowns และจุดล้มเหลวที่พบบ่อยหรือไม่ จะช่วย เร่งการอนุมัติ
  • ตัวอย่างพรอมป์ต์
    • "รวม prototype·spec·implementation notes เป็นเอกสารเดียวสำหรับโพสต์ใน Slack เพื่อขอความเห็นชอบ โดยนำ demo GIF ไว้ด้านหน้า"

• Quiz

  • หลังเซสชันงานยาว Claude อาจทำได้มากกว่าที่คาดไว้ และการดูแค่ code diff ทำให้เข้าใจพฤติกรรมที่พึ่งพาเส้นทางโค้ดเดิมได้เพียงผิวเผิน
  • หลังให้คอนเท็กซ์แล้ว ให้ขอให้ Claude ออก quiz เกี่ยวกับการเปลี่ยนแปลงเพื่อยืนยันความเข้าใจ และ merge ก็ต่อเมื่อผ่าน quiz ได้สมบูรณ์เท่านั้น
  • ตัวอย่างพรอมป์ต์
    • "ฉันอยากเข้าใจทุกสิ่งที่เกิดขึ้นในการเปลี่ยนแปลงนี้ ช่วยทำ HTML report ที่มีคอนเท็กซ์·intuition·สิ่งที่ทำไป ฯลฯ และใส่ quiz ที่ต้องผ่านไว้ด้านล่าง"

ภาพรวมจากกรณีเปิดตัว Fable (How this comes together)

• วิดีโอเปิดตัว Fableถูกตัดต่อทั้งหมดด้วย Claude Code และเป็นพื้นที่ใหม่ที่ไม่ใช่ความเชี่ยวชาญเฉพาะของผู้เขียน
• เริ่มจากสิ่งที่รู้ คือรู้ว่า Claude สามารถตัดต่อวิดีโอและถอดเสียงด้วยโค้ดได้ แต่ไม่มั่นใจเรื่องความแม่นยำ จึงขอคำอธิบายเกี่ยวกับ หลักการถอดเสียงแบบ Whisper และว่า ffmpeg สามารถตัด ums กับช่วงเงียบยาวได้อย่างแม่นยำหรือไม่
• ต้องการ UI ที่ซิงก์กับคำพูดและเวลา แต่ไม่แน่ใจว่าจะทำได้หรือไม่ จึงตรวจสอบด้วยการทำวิดีโอ prototype โดยใช้ Remotion และ transcript
• รู้ว่าวิดีโอดูค่อนข้าง muted เพราะ color grading แต่ไม่รู้ว่าสิ่งนั้นคืออะไร จึงไม่ได้เลือกจากหลายรูปแบบ แต่ ขอให้สอน color grading เพื่อค้นพบ unknowns

ทำให้แผนที่และอาณาเขตตรงกัน (Matching the Map and Territory)

• ยิ่งโมเดลดีขึ้น ก็ยิ่งทำได้มากขึ้นด้วยแนวทางที่ถูกต้อง และเมื่อ task ระยะยาวได้ผลกลับมาผิดทิศทาง มักหมายความว่าควรใช้เวลากับ การนิยาม unknowns หรือ implementation plan ที่เปิดทางให้ Claude รับมือเฉพาะหน้าได้มากขึ้น
• คำอธิบาย·brainstorming·interview·prototype·reference ทั้งหมดคือวิธีค้นพบ unknowns อย่างประหยัด ก่อนที่ปัญหาจะแพงขึ้น
• หัวใจสำคัญคือเริ่มโปรเจกต์ถัดไปด้วยการขอให้ Claude ช่วยค้นหา unknowns