บทความ
เพดานของการใช้ AI คือความทะเยอทะยานของคุณ: สี่มิติ ได้แก่ ความเร็ว ความสูง ความลึก และความกว้าง
Felix Rieseberg หัวหน้าวิศวกรของ Anthropic แยก "ความทะเยอทะยานในการใช้ AI" ออกเป็นสี่มิติ คือ ความเร็ว ความสูง ความลึก และความกว้าง บทความนี้สรุปวิธีและตัวอย่างของเขา พร้อมบันทึกการนำไปใช้จริงของผมเอง: สั่งงานแบบมุ่งเป้าหมาย แล้วจัดทีมผู้เชี่ยวชาญด้วย Multi-AI Agents มาตรวจทานไขว้จากหลายมุมมอง เพื่อยกระดับคุณภาพของงาน
· อ่าน 1 นาที
Felix Rieseberg หัวหน้าวิศวกรของ Anthropic เขียนไว้ในบทความ "How to be more ambitious: A tutorial for humans with models" ว่า เมื่อเห็นคนอื่นใช้ AI ทำผลลัพธ์ที่น่าทึ่งได้ เขากับคนรอบตัวมักมีปฏิกิริยาเดียวกันว่า "เรายังทะเยอทะยานไม่พอ"
ผมตีความว่า เพดานของการใช้ AI ของมนุษย์มักติดอยู่ที่ความทะเยอทะยานและจินตนาการของตัวเอง ไม่ใช่ที่โมเดล
เขาแยก "ความทะเยอทะยาน" ออกเป็นสี่มิติ:
- ความเร็ว (Speed): งานเดิมแต่ทำเสร็จในเวลาที่สั้นลง
- ความสูง (Altitude): ยกระดับนามธรรมให้สูงขึ้น มองที่ผลลัพธ์สุดท้าย ไม่ใช่งานเดี่ยวๆ ชิ้นเดียว
- ความลึก (Depth): ทำงานด้วยมาตรฐาน เครื่องมือ และวิธีการของผู้เชี่ยวชาญชั้นนำในสาขานั้น
- ความกว้าง (Range): ก้าวออกจากสาขาเดียว แล้วหาทางออกข้ามศาสตร์
สรุปไว้ก่อน: สั่งงานแบบมุ่งเป้าหมายให้แม่นยำ แล้วจัดทีมผู้เชี่ยวชาญด้วย Multi-AI Agents ให้ทำงานร่วมกันและตรวจทานไขว้จากหลายมุมมอง คุณภาพของงานโดยรวมจึงจะยกระดับขึ้น
หนึ่ง: ความเร็ว พื้นฐานที่สุดและติดขัดน้อยที่สุด#
งานเดิมแต่ทำเสร็จในเวลาที่สั้นลง Felix มองว่าทุกคนคุ้นเคยเรื่องนี้ดีอยู่แล้ว จึงข้ามไปในบทความเลย
มุมมองของผม: ความเร็วเป็นคุณค่าของ AI ที่เห็นได้ตรงที่สุด แต่ถ้าไล่ตามแค่ความเร็ว วิธีทำงานร่วมกันก็ไม่เปลี่ยนมากนัก สามมิติถัดไปต่างหากที่ทำให้เกิดความแตกต่างจริงๆ
สอง: ความสูง ถามถึง "เป้าหมายเบื้องหลังเป้าหมาย"#
คำถามหลัก: ผลลัพธ์ถัดไปที่ฉันต้องการจริงๆ คืออะไร เป้าหมายเบื้องหลังเป้าหมายนี้คืออะไร
ตัวอย่างของ Felix:
- จากการแก้ Crash หนึ่งจุด สู่การทำให้ App ไม่ Crash อีก เดิมเขาให้ Claude แก้ Crash แค่จุดเดียว ต่อมาเปลี่ยนเป็นขอให้ App คง Crash เป็นศูนย์ เพื่อให้เรื่องนี้ทำงานต่อเนื่องแบบอัตโนมัติได้ เขาต้องปรับกระบวนการของตัวเองก่อน คือทำให้ได้รายงาน Crash ง่าย จับคู่เวอร์ชันของ App กับ Git Commit และให้ Claude ใช้เครื่อง Windows, macOS และ Linux เพื่อทำซ้ำและตรวจสอบการแก้ไข
- การยกระดับการทบทวนธุรกิจรายไตรมาส (QBR) สามขั้น:
- ใช้ข้อมูลดิบให้มากที่สุดเท่าที่ทำได้ เพื่ออธิบายว่าไตรมาสนี้อะไรเปลี่ยนไป ทำไม และควรทำอะไรต่อ
- หา 3 การตัดสินใจที่เร่งด่วนที่สุด แล้วเขียนข้อโต้แย้งทั้งด้านเห็นด้วยและไม่เห็นด้วยของแต่ละข้อ
- ออกแบบกลไกทางเลือกที่ตรวจพบปัญหาได้เร็วกว่าสไลด์รายไตรมาส ทดสอบด้วยข้อมูลย้อนหลัง และรันคู่ขนานกับกระบวนการปัจจุบันหนึ่งไตรมาส
เขายังเตือนเรื่องขอบเขตด้วยว่า ในปี 2026 เป้าหมายคลุมเครืออย่าง "Claude ไปหาเงินมาให้ฉันที" ยังใช้ไม่ได้ แต่เขาคาดว่าระดับนามธรรมที่โมเดลรับมือได้จะสูงขึ้นเรื่อยๆ
สาม: ความลึก ตามมาตรฐานของผู้เชี่ยวชาญชั้นนำในสาขานั้น#
วิธีของ Felix:
- ใช้เครื่องมือที่อุตสาหกรรมนั้นใช้จริง โมเดลมักเปลี่ยนแค่ถ้อยคำ ไม่ได้เปลี่ยนวิธีทำ แล้วโยนตาราง Markdown มาให้พอเป็นพิธี ให้ยืนกรานใช้เครื่องมือวิเคราะห์จริง เช่น ฐานข้อมูลและโมเดลทางสถิติ
- ตั้งเป้าหมายที่ฟังดูไม่สมเหตุสมผล และบอกโมเดลว่าแก้ได้ ตัวอย่างของเขาคือ หลังลดเวลาโหลดเว็บไซต์จาก 10 วินาทีเหลือ 5 วินาที ก็ขอ 200 มิลลิวินาที เมื่อโมเดลถอย ให้ยืนยันว่าทำได้
- ท้าทายสมมติฐานที่ตัวเองเชื่อ ให้ข้อมูลดิบแก่โมเดลแล้วให้ตรวจจากมุมมองเชิงโต้แย้ง เช่น "เราคิดว่าสาเหตุที่ผู้ใช้เลิกใช้คือขั้นตอน onboarding ลองสร้างข้อสรุปนี้ขึ้นมาใหม่จากข้อมูลดิบ"
- สร้างความรู้ใหม่ สร้างแบบจำลองจาก Logs หาสัญญาณแรกสุดของการเลิกใช้ที่คุณยังไม่รู้ แล้วตรวจสอบด้วยข้อมูลที่ยังไม่เคยเห็น
- หาผู้ตัดสินจากภายนอก (Outside Judge) อย่าให้โมเดลตรวจงานตัวเอง ที่ดีที่สุดคือเชื่อมเครื่องมือที่โมเดลรันได้เองและได้ผลตอบกลับทันที
หลักการเขียน Prompt ของเขาคือ สิ่งที่ขอคือ "ฉบับที่ลึกกว่า" ไม่ใช่ "ฉบับที่ใหญ่กว่า" ให้โมเดลบอกว่ามืออาชีพระดับสูงสุดจะทำอะไรเพิ่ม ข้อมูลต้นทางที่ดิบที่สุดอยู่ที่ไหน จะใช้วิธีและเครื่องมืออะไร และนอกจากโมเดลหรือวิจารณญาณของคุณแล้ว มีอะไรอีกที่พิสูจน์ได้ว่าผลลัพธ์ถูกต้อง
สี่: ความกว้าง ใช้กริยาแทนคำนาม และตั้งทีมผู้เชี่ยวชาญ#
- ใช้กริยาแทนคำนาม แนวคิดนี้ Felix อ้างมาจากหนังสือ The Art of Innovation QBR ไม่ใช่ "สไลด์หนึ่งชุด" แต่คือ "ภายใน 30 นาที ช่วยให้คนที่ยุ่งเข้าใจเหตุและผล และตัดสินใจท่ามกลางความไม่แน่นอนได้" เมื่อนิยามเป้าหมายด้วยกริยา ก็จะมองเห็นว่าต้องใช้ความสามารถจากสาขาไหนบ้าง
- ตั้งทีม ถ้าจะทำสไลด์ที่ดี ให้หานักวิเคราะห์ นักข่าว และบรรณาธิการ ถ้าจะนำเสนอบนเวที เพิ่มนักออกแบบโมชันและเสียง ถ้าจะทำการตรวจทานเชิงโต้แย้ง ให้หานักวิจัยจากบริษัทขายชอร์ตและนักบัญชีนิติเวช
- อย่าสวมบทบาทแบบไร้ความหมาย ไม่ใช่สั่งโมเดลว่า "เขียนด้วยน้ำเสียงของบริษัทขายชอร์ต" แต่ให้ลงมือทำตามวิธีวิจัยของบริษัทขายชอร์ตในส่วนหนึ่งของงานจริงๆ เปลี่ยนแค่น้ำเสียง ผลลัพธ์ก็ไม่ดีขึ้น
เงื่อนไขคือ โมเดลต้องมีคอมพิวเตอร์ที่ติดตั้งซอฟต์แวร์ได้ และเข้าถึงข้อมูลที่เกี่ยวข้องได้ เช่น ผ่านตัวเชื่อมต่อ MCP
ห้า: บันทึกการนำไปใช้ของผม จาก "การส่งผ่านข้อมูล" สู่ "การบรรลุเจตนา"#
ส่วนด้านล่างเป็นส่วนต่อยอดของผมเองที่ผสมสถาปัตยกรรมซอฟต์แวร์เข้ากับการปฏิบัติจริงทางวิศวกรรม ไม่ใช่เนื้อหาในต้นฉบับ
1. Jobs to be Done และ Intent-Based#
- อย่าถามว่า "ทำอะไร" ให้ถามว่า "บรรลุอะไร" การออกแบบไม่ควรหยุดแค่ไปป์ไลน์ส่งผ่านข้อมูลแบบเฉื่อยๆ อย่าง
generate_deck_pdf() แต่ควรยกระดับเป็นเจตนาของการเปลี่ยนสถานะ อย่าง resolve_leadership_uncertainty_and_commit_budget()
- นิยาม loss function ที่แท้จริง ถ้าขอแค่ชิ้นงาน โมเดลจะสร้างข้อความกลวงที่ดูสมบูรณ์แบบ แต่ถ้าขอให้แก้ความไม่แน่นอนของการตัดสินใจ โมเดลและ Sub-agent จึงจะเติมช่องโหว่ทางตรรกะและขอบเขตความเสี่ยงให้เอง
2. ตอนสำรวจให้กระจาย ตอนตรวจรับให้บรรจบ#
- ตอนสำรวจ กระจายหาความเป็นไปได้ก่อน แล้วค่อยบรรจบ
- ตอนตรวจรับ อย่ากระจายอีก หลีกเลี่ยงคำถามไร้ขอบเขตอย่าง "เรื่องนี้ทำอย่างอื่นได้อีกไหม" เพราะจะได้แต่คำตอบกว้างๆ ทั่วไป
- เขียนขอบเขตเป้าหมาย ข้อจำกัด และเครื่องมือตรวจสอบเชิงวัตถุวิสัยให้ชัด (สคริปต์ทดสอบเฉพาะ เกณฑ์ตัวชี้วัดทางธุรกิจ) เพื่อให้ทีม Multi-Agent ทำ stress test ภายในกรอบที่โฟกัสและส่งมอบผลงานคุณภาพสูง
สรุปบันทึก#
- มุ่งเป้าหมาย: ใช้กริยาแทนคำนาม ส่งมอบผลลัพธ์ที่แก้ปัญหาได้ ไม่ใช่ชิ้นงานที่ทำแค่ให้พ้นหน้าที่
- สำรวจและบรรจบ: ตอนสำรวจกระจายหาความเป็นไปได้ ตอนตรวจรับบรรจบอย่างเข้มงวดเพื่อตรวจขอบเขต
- โฟกัสที่นามธรรม: เริ่มจากคำถามหลัก แล้วรื้อสร้างกระบวนการทำงานทั้งชุดใหม่
- ความลึกแบบผู้เชี่ยวชาญ: ไม่ใช่แค่เลียนน้ำเสียงผู้เชี่ยวชาญ แต่บังคับให้โมเดลแก้ปัญหาด้วยเครื่องมือและวิธีการของผู้เชี่ยวชาญชั้นนำ
ต้นฉบับ: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)