AI copilots เพียงพอแล้ว ตอนนี้เราต้องการ AI HUD

 (geoffreylitt.com)
1 คะแนน โดย GN⁺ 2025-07-28 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • คำวิจารณ์ของ Mark Weiser ต่ออุปมา AI 'copilot' ที่เผยแพร่ในปี 1992 ยังคงใช้ได้มาจนถึงทุกวันนี้
  • Weiser เสนอ อินเทอร์เฟซที่กลมกลืนไปกับประสบการณ์ผู้ใช้อย่างเป็นธรรมชาติ แทนที่จะเป็น 'ผู้ช่วย'
  • แนวคิด HUD (Head-Up Display) ของเครื่องบินสมัยใหม่แสดงให้เห็นปรัชญานี้ได้อย่างชัดเจน
  • กรณีศึกษาหลายแบบชี้ให้เห็นคุณค่าของ UI สไตล์ HUD ที่ขยายการรับรู้ของผู้ใช้ แทน automation หรือ agent UI
  • Copilot มีประสิทธิภาพกับงานประจำวัน แต่ใน สถานการณ์สร้างสรรค์หรือไม่เป็นแบบแผน HUD จะเสริมความสามารถของมนุษย์ได้มากกว่า

คำวิจารณ์ copilot ของ Mark Weiser ในปี 1992

  • ในปี 1992 Mark Weiser ได้วิจารณ์ มุมมองที่เปรียบ AI เป็น 'copilot' ในงานเกี่ยวกับ 'interface agents' ของ MIT Media Lab
  • ประเด็นอย่างการรับรู้บริบทและ automation ซึ่งยังสำคัญในปัจจุบัน ก็ถูกถกเถียงกันตั้งแต่ตอนนั้นแล้ว
  • Weiser สนับสนุนระบบที่ทำให้ผู้ใช้รับรู้ข้อมูลได้อย่างเป็นธรรมชาติ แทน 'copilot' (AI ที่ทำหน้าที่ช่วยนักบินราวกับเป็นมนุษย์เสมือน)
  • อุดมคติของเขาคือ 'คอมพิวเตอร์ที่ไม่สะดุดตา' ซึ่งเป็นสภาพแวดล้อมที่ต่อขยายอย่างเป็นธรรมชาติเหมือนเป็นส่วนหนึ่งของร่างกายผู้ใช้

HUD (Head-Up Display) กับปรัชญาของ Weiser

  • HUD (HUD, Head-Up Display) ของเครื่องบินสมัยใหม่จะแสดงข้อมูลสำคัญ เช่น เส้นขอบฟ้า/ระดับความสูง ซ้อนบนจอโปร่งใส เพื่อให้ผู้ใช้รับรู้ได้อย่างเป็นธรรมชาติภายในสายตาของนักบิน
  • HUD ต่างจาก copilot ตรงที่ไม่ต้องมีการสนทนา และ ช่วยขยายความสามารถในการรับรู้อย่างเป็นธรรมชาติ
  • แนวคิด HUD ลักษณะนี้สอดคล้องกับการใช้งานที่ Weiser เสนอไว้

การทำให้ HUD เกิดขึ้นจริงในซอฟต์แวร์

  • ระบบตรวจตัวสะกดทำงานโดย ไม่สนทนาแบบ 'ผู้ร่วมงาน AI' แต่ขีดเส้นใต้สีแดงใต้คำสะกดผิดโดยอัตโนมัติ
  • การให้ข้อมูลแบบ ฉับไวและมองเห็นได้ทันที เช่นนี้ เป็นตัวอย่างหนึ่งของ HUD ที่สร้างการรับรู้รูปแบบใหม่ให้ผู้ใช้
  • custom debugger UI ที่ใช้ AI ก็ช่วยแสดงภาพการทำงานของโปรแกรมอย่างเป็นสัญชาตญาณ ทำให้ผู้ใช้ตรวจพบและเข้าใจปัญหาได้ด้วยตนเอง
  • แนวทางนี้แตกต่างจาก automation แบบดั้งเดิมหรือ UI แบบ 'ผู้ช่วยเสมือน' และเป็นการขยายประสาทรับรู้ของมนุษย์โดยตรง

Trade-off ระหว่าง HUD กับ copilot

  • ผู้เขียนอธิบายว่า ไม่ได้มองว่า HUD ดีกว่า copilot เสมอไป และทั้งสองแบบต่างก็มีข้อดีข้อเสียของตัวเอง
  • สำหรับ งานที่เป็นกิจวัตรและคาดการณ์ได้ (เช่น การบินตรง) แนวทางแบบ copilot มีประสิทธิภาพ
  • สำหรับ ปัญหาที่ไม่เป็นแบบแผนและต้องใช้ความคิดสร้างสรรค์ (เช่น การรับรู้สถานการณ์ระหว่างลงจอดฉุกเฉิน) เครื่องมือที่ช่วยการรับรู้ของมนุษย์แบบ HUD จะทรงพลังมาก
  • ผู้ออกแบบ AI ควรพิจารณา UI แบบขยายประสาทรับรู้ของมนุษย์ เช่น HUD ไม่ใช่ยึดอยู่กับแนวคิด 'assistant' เท่านั้น

บทสรุป

  • ในการออกแบบ AI แห่งอนาคต จำเป็นต้องตระหนักถึง คุณค่าและ trade-off ของทั้งแนวทาง copilot และ HUD
  • ปล่อยให้ automation ทั่วไปเป็นหน้าที่ของผู้ช่วยเสมือน และหากต้องการผลลัพธ์ที่เหนือกว่า วิธีที่อาจทรงพลังที่สุดคือมอบ 'พลังพิเศษใหม่' ให้ผู้เชี่ยวชาญมนุษย์เหมือน HUD

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-07-28
ความคิดเห็นจาก Hacker News
  • ฉันสงสัยมากว่าฟังก์ชันสลับเปิดปิด heatmap ที่แสดงว่าแต่ละโทเค็นในไฟล์ซอร์สนั้นทำให้โมเดลประหลาดใจแค่ไหนจะมีประโยชน์หรือไม่ โทเค็นสีแดงมีโอกาสสูงว่าจะเป็นข้อผิดพลาด, การตั้งชื่อที่ไม่ดี, หรือคอมเมนต์ที่ไม่ถูกต้อง
    • บางครั้งโค้ดที่คาดเดาไม่ได้ก็เกิดจากอัลกอริทึมที่แปลกใหม่ แต่ในกรณีแบบนั้นยิ่งจำเป็นต้องมีเอกสารที่ดีกว่าเดิม ถ้าอธิบายโค้ดไว้ดี มันก็จะ "น่าประหลาดใจ" น้อยลงในตัวเอง กล่าวคือ เราสามารถจัดโครงสร้างบางส่วนของซอร์สให้ไม่น่าประหลาดใจได้ และนั่นอาจเป็นแนวปฏิบัติทางวิศวกรรมที่ดี ด้วย LLM ตอนนี้ทุกคนเริ่มใส่ใจกับความสำคัญของเอกสารที่ดี ไม่ใช่แค่เพื่อคนอื่น แต่ยิ่งจำเป็นขึ้นอีกถ้าต้องการให้ AI อ่านและเข้าใจระบบ
    • ฉันคิดว่าไอเดียนี้เจ๋งมาก ในทางกลับกัน ถ้าทำ heatmap ให้กับข้อเสนอของ AI ตามระดับความน่าเชื่อถือได้ด้วยก็น่าจะมีประโยชน์มาก
    • ฉันอยากให้มีฟังก์ชันแบบนี้ในเอดิเตอร์ด้วย เหมาะมากสำหรับดูว่างานเขียนนั้นคาดเดาได้เกินไปหรือเชยเกินไปไหม การคำนวณ perplexity ก็ไม่ได้ยาก แค่รวมเข้ากับ UI ของเอดิเตอร์ก็พอ
    • น่าสนใจ ฉันมักรู้สึกว่าเรายังใช้ประโยชน์จาก "ผลไม้ต่ำมือ" ที่เกิดขึ้นตั้งแต่กระแส LLM ยุคแรกได้ไม่เต็มที่ และนี่แหละคือตัวอย่างของไอเดียแบบนั้น
    • ฉันคิดว่าเป็นไอเดียที่ยอดเยี่ยมจริงๆ
  • ราว 10 ปีก่อน Bret Victor เคยบอกว่าการลดความหน่วงของ feedback ให้ต่ำที่สุดควรเป็นหลักการใช้ชีวิตของเรา เขาบอกว่าวงจรการทำซ้ำที่รวดเร็วไม่เพียงทำให้เขียนโค้ดได้ดีขึ้น แต่ยังช่วยให้เกิด insight เชิงสร้างสรรค์ด้วย เขาสร้างโปรแกรมตัวอย่างหลายแบบเพื่อแสดงทางเลือกต่างๆ และกรณี HUD ที่ OP พูดถึงก็คล้ายมากกับเดโมของเขาเรื่อง “ย้อนเวลาเพื่อทำความเข้าใจโค้ด” วิดีโอที่เกี่ยวข้อง
  • ฉันชอบไอเดียนี้ เลยลองคิดว่ามันจะนำไปใช้กับการเขียนโค้ดโดยรวมได้อย่างไร ลองนึกภาพว่า: ขณะเขียนโค้ด LLM สร้างเทสต์ให้ แล้ว IDE ก็รันเทสต์เหล่านั้นแบบเรียลไทม์ ทุกครั้งที่กดแป้นจะมีเทสต์ 10~100 รายการรันภายใน <1ms และแสดงผลแบบไม่รบกวนสายตา เทสต์อยู่ในพาเนลแยกข้างโค้ด โดยมีจุดสีแดง/เขียวบอกผ่าน/ไม่ผ่านของการรันล่าสุด แค่ดูว่ามีเทสต์อะไร ไม่มีอะไร และสถานะเป็นอย่างไร ก็พอจะรู้แล้วว่าโค้ดที่กำลังเขียนทำอะไรจาก “ภายนอก” ถ้าคิดว่าจำเป็นต้องมีเทสต์ที่ LLM ไม่ได้เขียน นั่นอาจเป็นสัญญาณว่า prompt ผิด หรือโค้ดไม่ตรงกับเจตนา คุณสมบัติแบบเรียลไทม์ช่วยขัดเกลาโค้ดได้มาก ถ้าอยากทำแบบ TDD ดั้งเดิม ก็ให้ผู้ใช้เขียนเทสต์ แล้ว LLM เขียนโค้ดให้ผ่านเทสต์ก็ได้
    • วิธีที่ให้คนเขียนเทสต์ก่อนแล้ว LLM ค่อยสร้างโค้ดนั้นดีกว่ามาก เพราะเทสต์คือ "ความจริง" และ "เจตนา" ของโค้ด ถ้าคุณยอมปล่อยอำนาจในการกำหนด input กับ output ไป นักพัฒนาก็ไม่ได้เป็นคนขับอีกต่อไป
    • สำหรับโค้ดเบส C++ แบบจริงจัง วิธีนี้ทำไม่ได้เลย แค่เวลา compile ก็ทำให้เป็นไปไม่ได้แล้ว และการให้ LLM เดาเทสต์ก็ยากมากถ้ายังไม่ได้เขียนโค้ดทั้งก้อน เช่น ถ้าคุณกำลังสร้าง data structure ใหม่ LLM จะไปรู้ได้อย่างไร
    • การให้ LLM สร้างเทสต์ระหว่างเขียนโค้ดแล้วให้ IDE รันทุกครั้งไม่ใช่วิธีที่ดี เทสต์คือโค้ดที่ใช้รับประกัน invariants ดังนั้นปล่อยให้ LLM มาแก้มั่วๆ ไม่ได้ เทสต์ควรถูกเปลี่ยนเฉพาะเมื่อผู้ใช้ตั้งใจเปลี่ยนอย่างชัดเจน และควรเปลี่ยนแค่ตัวมันเองเท่านั้น ภายใต้ข้อจำกัดแบบนี้ มันก็เป็น workflow ปกติในชีวิตประจำวันอยู่แล้ว เหมือน watch mode ของเฟรมเวิร์กทดสอบ JavaScript นักพัฒนาทำแบบนี้กันมาตั้งแต่ 10 ปีก่อนแล้ว
    • แล้วไม่จำเป็นต้องมีเทสต์ไว้ทดสอบด้วยหรือว่าเทสต์ถูกเขียนมาถูกต้องไหม? ไม่อย่างนั้น LLM ก็แค่ทำให้มันผ่านแม้ตัวเทสต์จะผิด หรืออาจเขียนโค้ดเพื่อหลอกระบบก็ได้ สุดท้ายแล้วสภาพแวดล้อมที่ดีคือมนุษย์กับ LLM ต้องข้ามเส้นแบ่งหน้าที่ของกันและกันได้อย่างอิสระ การเขียนแค่ข้อกำหนดที่ชัดเจน แล้วให้ AI จัดการทั้งสองฝั่งเป็นส่วนใหญ่ น่าจะ productive และ streamlined กว่ามาก
    • การรันเทสต์ทั้งชุดทุกครั้งที่มี input ใหม่ให้ ROI ต่ำเกินไป การกดแป้นส่วนใหญ่เกิดขึ้นตอนโปรแกรมยัง "ไม่เสร็จ" ดังนั้นต้องเลือกจังหวะรันเทสต์ให้ฉลาดกว่านี้ถึงจะสมดุลได้
  • สุดท้ายทุกอย่างก็ย้อนกลับไปสู่คำถามว่า "อินเทอร์เฟซในอุดมคติสำหรับมนุษย์ในการจัดการข้อมูลดิจิทัลคืออะไร?" ทุกวันเรารับข้อมูลมากขึ้นเรื่อยๆ และเพราะ AI ปริมาณนั้นก็ไม่ได้ลดลง มีแต่จะเพิ่มขึ้น ถ้ามันช่วยสรุปข้อมูลที่ซับซ้อนและเฉพาะทางได้ด้วย (เช่น error log) ก็จะเปิดทางใหม่ให้คนที่ก่อนหน้านี้เข้าไม่ถึงข้อมูลเหล่านั้น แล้วเราควรจัดการข้อมูลมหาศาลนี้อย่างมีประสิทธิภาพอย่างไร? ตอนนี้เรามีอินเทอร์เฟซ, เว็บไซต์, แดชบอร์ด, อีเมล, แชตสารพัด แต่ก็สงสัยว่าอีก 10 ปีข้างหน้าเราจะยังต้องใช้ทั้งหมดนั้นอยู่ไหม ถ้าฉันรับข้อมูลทั้งหมดผ่านอินเทอร์เฟซแชตเดียวได้ ฉันยังจำเป็นต้องเข้าเว็บไซต์อยู่หรือเปล่า? ตอนนี้ให้ AI มาสร้างเว็บไซต์, แอป, เว็บ UI แทนเรามันเริ่มรู้สึกว่า...ซ้ำซ้อนอยู่บ้าง
    • เว็บไซต์คือช่องทางสำหรับรับข้อมูล "ทางการ" จากแหล่งที่เชื่อถือได้อย่างบริษัทหรือ Wikipedia ความน่าเชื่อถือนี้ทรงพลังมาก จึงมีทั้ง "line of death", ไอคอนแม่กุญแจ, มาตรการป้องกันฟิชชิง, การรับมือกับการโจมตีด้วยอักขระหน้าตาเหมือนกัน ทุกอย่างตั้งอยู่บนสมมติฐานว่าเว็บนี้คือแหล่งข้อมูลทางการที่เชื่อถือได้ ในโลกที่ทุกคนพึ่งพา LLM อย่างไม่วิจารณ์ ความหมายของคำว่า "ความน่าเชื่อถือ" ชวนให้สับสนมาก ต่อให้ LLM มักจะถูกต้อง เราจะเชื่อมันได้จริงในช่วงเวลาที่สำคัญมากๆ ไหม?
    • นักออกแบบเครื่องบินขับไล่ยุคที่ 6 ก็เจอปัญหาเดียวกัน ห้องนักบินคืออินเทอร์เฟซระหว่างเครื่องกับนักบิน แต่บทบาทของมันลดลงเรื่อยๆ พอถึงยุคที่ 7 ก็ไม่แน่ใจแล้วว่ามนุษย์จะยังมีบทบาทที่มีคุณค่าได้ไหม (ถึงอย่างนั้น ถ้ายังต้องมีมนุษย์เกี่ยวข้องด้วยเหตุผลอย่างกฎหมายระหว่างประเทศหรือการจัดการความเสี่ยงแบบ Skynet ก็อาจยังคงอยู่) อินเทอร์เฟซในทุกสาขาอาจวิวัฒน์ไปทางนี้เหมือนกัน ความซับซ้อนจะลดลงเรื่อยๆ และมนุษย์ก็แค่บอกระบบว่าต้องการอะไรในระดับแนวคิดสูง ไม่จำเป็นต้องเป็นภาษาธรรมชาติเสมอไป ถ้าต้องการสเปกที่แม่นยำก็อาจใช้อินเทอร์เฟซที่เหมาะกับสิ่งนั้น
    • เพราะแต่ละคนต่างกัน อินเทอร์เฟซไม่ควรถูกทำให้เป็นแบบเดียว แต่ควรถูกปรับแต่งแบบไดนามิกเฉพาะหน้า
    • ยังยากจะบอกว่าสมาร์ตโฟนนั้นสมบูรณ์แบบจริงหรือถูกใช้อย่างเต็มศักยภาพแล้ว สำหรับฉันมันยังเป็นสิ่งที่ชอบที่สุด
  • ฉันคิดว่าความสามารถที่ AI สร้าง visualization ที่ซับซ้อนแบบเรียลไทม์ได้นั้นมีประโยชน์มาก เช่น เวลาดีบัก memory leak ใน code path บางเส้น AI อาจช่วยสร้างภาพการ allocate/free หน่วยความจำในเส้นทางนั้นเพื่อให้มองเห็นปัญหาได้ชัดขึ้น ดูเหมือนเรากำลังเข้าสู่ยุคที่ AI จะสร้างเครื่องมือ visualization ที่เหมาะกับปัญหาเฉพาะแต่ละอย่างได้เอง ทอล์กล่าสุดของ Jonathan Blow ที่ LambdaConf เชื่อมกับไอเดียนี้โดยตรง เขาแสดงเครื่องมือที่ใช้ทำ visualization ของโปรแกรมในหลายรูปแบบเพื่อค้นหาปัญหาที่อาจซ่อนอยู่ AI น่าจะสร้างเครื่องมือแบบนั้นได้ดี ดูวิดีโอเต็ม
  • ฉันอยากเห็น HUD ที่แสดงการเปลี่ยนแปลงที่เชื่อมกับ TODO item ของ Claude Code ได้ทันที ฉันไม่ต้องการคอมเมนต์ inline เพราะสุดท้ายมันสะสมและ LLM ก็จัดระเบียบมันได้ไม่ดีนัก
  • หนึ่งในเหตุผลใหญ่ที่ HUD ยังไม่แพร่หลายสู่กระแสหลักคือข้อจำกัดของสื่อแสดงผลที่ใช้อยู่ตอนนี้ มอนิเตอร์หรืออุปกรณ์พกพาไม่เก่งในการให้ข้อมูลรอบข้างที่ไม่แทรกแซงมากนัก เวลา AI agent แก้บั๊กหรือจัดการงานซับซ้อน เรามักมีช่วงรอผลที่ชวนอึดอัด มันสั้นเกินกว่าจะไปทำอย่างอื่น แต่ก็แปลกที่จะนั่งจ้องหน้าจออย่างเดียว ถ้ามี HUD เราจะมี feedback loop ที่สั้นกว่ามาก สามารถเหลือบดูว่า AI กำลังทำอะไรและแทรกแซงได้ทันที หรือจะปล่อยไว้แล้วทำอย่างอื่นต่อก็ได้ ประเด็นสำคัญคือเราไม่จำเป็นต้องเลือกสุดโต่งระหว่างจดจ่อทั้งหมดกับปล่อยทิ้งทั้งหมด แต่สามารถเลือกระดับการแทรกแซงได้ตามสถานการณ์ภายใต้การรับรู้แบบ ambient ด้วยเหตุนี้ฉันจึงคิดว่า VR/AR อาจเป็น killer app หลักของ AI HUD spatial computing ทำให้เราได้รับความช่วยเหลือจาก AI โดยไม่ต้องละสายตาจากจอ 2D และแนวทางนี้น่าจะมีประโยชน์มากเป็นพิเศษกับงานกายภาพอย่างการทำอาหารหรือซ่อมจักรยาน
    • ฉันใช้งานแบบนี้อยู่แล้วด้วยการจับคู่จอ ultrawide กับหน้าจอแล็ปท็อป ระหว่างเล่นเกมหรือทำงานอื่น ฉันเปิด Claude ไว้ในหน้าต่าง tmux มุมหนึ่ง แล้วคอยเช็กทันทีเมื่อมีขั้นตอนถัดไปหรือการเปลี่ยนแปลงสำคัญ
  • ฉันคิดว่าอินเทอร์เฟซการเขียนโค้ดแบบ HUD โดยพื้นฐานแล้วก็คือ AREPL มันเหมาะกับการดีบัก แต่ฉันรู้สึกว่าหน้าต่างแชตหรือ inline Q&A ใช้งานได้หลากหลายกว่ามาก โดยรวมฉันเห็นด้วยกับเหตุผลเรื่องอินเทอร์เฟซทางเลือกนอกเหนือจากแชต แต่ในความเป็นจริงแชตคืออินเทอร์เฟซที่ครองสมาร์ตโฟนไปแล้ว HUD น่าจะเหมาะกับ HUD จริงอย่างแว่น AR มากกว่า
  • ฉันคิดว่าโมเดล AI ที่ทำงานอัตโนมัติอยู่เบื้องหลังเป็นเวลานานและ "push" ข้อมูลมาเมื่อจำเป็นก็เป็นไปได้ มันจะตรวจจับบริบทอย่างชาญฉลาด กรองข้อมูล สรุปสาระ ส่งต่อ และถ้าจำเป็นก็ให้คำแนะนำด้วย โดยเฉพาะในงานธุรกิจที่ต้องเฝ้าดูลูกค้าหลายรายในสถานการณ์นับร้อยแบบ วิธีนี้ดูเป็นธรรมชาติกว่ามาก
    • จริงๆ แล้วส่วนที่ยากที่สุดคือการนิยามบริบทและเก็บข้อมูลที่เกี่ยวข้อง ปัญหาที่ให้ระบบอัตโนมัติทำสิ่งนั้นเองได้นั้นในเชิงเทคนิคถูกแก้ไปนานแล้ว
  • ฉันเห็นด้วยกับข้ออ้างที่ว่า "ถ้าจะออกแบบเพื่อ AI อย่างจริงจัง เราต้องคิดให้ไกลกว่าคำว่า copilot ไปสู่รูปแบบที่ขยายโลกภายในของมนุษย์" ที่จริง auto-complete ก็ทำหน้าที่นั้นอยู่แล้ว เราสามารถคุยกับ LLM ได้จริง แต่ก็สั่งงานง่ายๆ หรือใช้แค่การเติมคำอัตโนมัติก็ได้ สิ่งที่ผู้เขียนพยายามเน้นคร่าวๆ คือ AI ควรทำงานเคียงข้างเรา มองไปในทิศทางเดียวกับเรา ไม่ใช่เป็น copilot แบบ "มนุษย์เสมือน" ที่นั่งถกเถียงอยู่ฝั่งตรงข้ามโต๊ะ แต่ควรเป็นผู้ร่วมงานจริงที่ทำสิ่งที่เราสั่งได้ทันที
    • ผู้เขียนเอง ใช่เลย UI การเติมคำอัตโนมัติของ GitHub Copilot เป็นตัวอย่าง HUD ที่ดีมากอย่างน่าประหลาดใจ การกดแท็บเพื่อเติมคำเหมือนมันซึมเข้าไปเป็นส่วนหนึ่งของสมอง แต่ช่วงหลังสภาพแวดล้อมการเขียนโค้ดกำลังขยับไปทาง chat agent เราจึงต้องลองจินตนาการว่าที่ระดับ abstraction สูงกว่านั้น UI แบบ “tab auto-complete” จะหน้าตาเป็นอย่างไร มันอาจกลายเป็นวิธีออกแบบโค้ดที่ให้ความรู้สึกตรงไปตรงมาจริงๆ โดยไม่ถูกฉุดรั้งด้วยรายละเอียดปลีกย่อย