เมื่อ Prompt ไม่พอ: ทำไม Prototype จึงจำเป็น

เบื่อไหม? สั่งงาน AI อย่างละเอียด แต่ไม่ได้ผลลัพธ์ที่ต้องการ

คุยกันดิบดี คิดว่าเข้าใจตรงกันแล้วแท้ๆ แต่ก็ทำไม่ถูกอีก

ทั้งเสียเวลา เปลือง token เปล่าๆ แถม ติด limit ฟรีๆ

ปัญหาไม่ใช่ “คุยกัน” ไม่มากพอ ❌

ปัญหาคือ “ทดลอง” น้อยเกินไปต่างหาก 😲

ในยุคที่เราสามารถสร้างซอฟต์แวร์ ด้วยการพิมพ์หรือพูด เราไม่จำเป็นต้อง “จำกัด” ตัวเองด้วยการ prompt เพียงอย่างเดียว

“จุดเชื่อม” ที่ขาดหายไป ระหว่างการ prompt และโค้ดที่ใช้งานได้จริงคืออะไร

วันนี้ฮงจะมาเล่าให้ฟังกันครับ ถ้าพร้อมแล้วเรามาลุยกันครับ 🥳

(ฮงฟังวิดีโอล่าสุดของ Matt Pocock เลยอยากมาแชร์สิ่งที่ตกตะกอนให้ฟังครับ)

Outline

• ปัญหาของการ prompt เพียงอย่างเดียว
• validate ความเข้าใจผ่านการสร้างตัวต้นแบบ
• ระดับขั้นของ Fidelity
• เมื่อไรถึงควรสร้าง prototype
• /prototype skill ใหม่ของ Matt และวิธีติดตั้ง
• #สรุปโดยหัวหน้าฮง

ปัญหาของการ prompt เพียงอย่างเดียว

ความเชื่อที่ว่า “หากเราคุยกันมากพอ เราจะเข้าใจกัน” นั้นไม่เป็นความจริงทุกครั้ง ❌

เราคุยกับ AI การป้อนข้อมูลต่างๆ เพื่อให้มันเข้าใจ context ของงานที่จะทำ

📒 ข้อความ: prompt ที่เราคุย เนื้อหาต่างๆจากไฟล์โค้ด หรือไฟล์เอกสาร

🏞️ ภาพ: ภาพตัวอย่าง ภาพอ้างอิง

เราคุยกัน AI ถามโต้ตอบกันไปมา เคลียร์ความเข้าใจกันดิบดี

ทุกอย่างเหมือนจะไปได้สวย พอสั่งให้ลงมือทำ กลับได้ผลลัพธ์ไม่ตรงตามที่หวัง 😞

เรื่องนี้ไม่ใช่เรื่องแปลกใหม่ที่พึ่งมาเกิดในยุค AI เรื่องนี้มีมานานแล้ว…

การคุยกันเพียงอย่างเดียวไม่สามารถทำให้เข้าใจ หรือเห็นภาพเดียวกันได้ 100%

เพราะมันมี “Hidden Context” บางอย่างที่ซ่อนอยู่ ที่เราไม่ได้สื่อสารออกไป ต่างฝ่ายต่างเข้าใจในมุมของตัวเอง พอทำจริงมันเลยออกมาไม่ตรงกัน 😲

จะแก้ปัญหานี้ได้ต้อง “ตรวจสอบความเข้าใจ” ผ่านการสร้างตัวต้นแบบ หรือ การทำ prototype 💪

validate ความเข้าใจผ่านการสร้างตัวต้นแบบ

หากคุณอยากทำ “แบรนด์กางเกง” ของตัวเอง เจอโรงงานที่ใช้ คุยรายละเอียดเรียบร้อย

คุณจะสั่งผลิตล้อตแรก 1000 ตัวก่อนเลย หรือจะผลิต “ตัวต้นแบบ” ขึ้นมาก่อน

การสร้าง “ตัวต้นแบบ” ช่วยเรื่อง:

✅ ตรวจสอบความถูกต้อง ก่อนลงมือจริงได้

✅ ค่าใช้จ่ายในการทำถูกมาก เมื่อเทียบกับความเสียหายของการทำผิด spec

ในการเขียนโค้ด ทำซอฟต์แวร์เอง ก็ได้นำ concept เรื่องนี้มาใช้

ไม่ว่า Developer เก่งแค่ไหน อ่านเอกสารอย่างเดียว ก็ไม่มีทางเข้าใจ ได้ว่า user interface ที่ต้องสร้างจะเป็นแบบไหน

สิ่งที่ช่วยเรื่องนี้ได้คือการทำ “ตัวต้นแบบ” ขึ้นมาเพื่อใช้สื่อสาร แบบนี้ถูกต้องไหม ปุ่มนี้อยู่ตรงไหน ใช้สีอะไร

ซึ่งการทำตัวต้นแบบนี้ก็สามารถนำมาใช้กับการพัฒนาซอฟต์แวร์ด้วย AI เช่นกัน 💪

ระดับขั้นของ Fidelity

Fidelity หรือความละเอียดของงาน สามารถมองได้แบบที่ low -> high หรือน้อยไปมาก

1️⃣ Discussion การคุยกัน

คุยกันที่ Concept ล้วนๆ รวบรวมความต้องการ เขียน spec ซึ่งเป็นนามธรรมค่อนข้างมาก แะการคุย prompt กับ AI อยู่ในขั้นนี้

2️⃣ Wireframes แผนภาพเส้น

แสดง concept ออกมาเป็นภาพอย่างง่าย ช่วยทำให้เห็นภาพมากขึ้นว่าอะไรอยู่ตรงไหน โดยไม่ลงรายละเอียดจริง เช่น สี หรือข้อมูลจริง

3️⃣ Prototype สร้างตัวต้นแบบ

ต้นแบบที่เหมือนของจริงที่สุด เหมือนจริงแต่ไม่ใช่ของจริง เหมาะกับการตอบคำถามว่า “ถ้าทำออกมาแล้วจะมีหน้าตาอย่างไร”

4️⃣ Production-Ready Code โค้ดจริง

โค้ดของจริงที่พร้อมใช้งาน และพร้อมส่งมอบให้กับผู้ใช้แล้ว

ระดับขั้นของ Fidelity ไม่ได้บอกว่าอะไรดีกว่ากัน แต่ขึ้นอยู่การบริบทของการนำไปใช้งาน ยิ่ง High Fidelity มาก ก็ยิ่งมี Cost ในการทำสูงขึ้น

หากคุยกันอย่างเดียวยังไม่เห็นภาพ ให้เลื่อนระดับไปขึ้นที่สูงขึ้น อย่า skip ไปยัง Production-Ready Code ทันที เพราะถ้าทำไม่ถูก ต้องเหนื่อยแก้ แถมเปลือง token อีก 😲

เมื่อไรถึงควรสร้าง prototype

การทำ Prototype สำหรับการเขียนโค้ด คือการทำ​โค้ดใช้แล้วทิ้ง เพื่อตอบคำถามว่า “ถ้าทำออกมาแล้ว จะมีหน้าตาเป็นอย่างไร”

ซึ่งมันเหมาะมากๆๆๆ ในการทำ UI design เช่น ถ้าเพิ่มฟังก์ชันค้นหา หรือ filter ข้อมูล จะมีอะไรเปลี่ยนไปบ้าง

ซึ่งเห็นตัวอย่างและกดปุ่มได้ เห็นผลลัพธ์ได้ มันย่อมเห็นภาพตรงกันได้ง่ายกว่าการนั่งอ่านเอกสารเป็นไหนๆ

ดังที่ประโยคสุดคลาสสิก ได้พูดไว้ว่า “A picture is worth a thousand words” 🏞️

หนึ่งภาพ แทนคำพูดนับพัน

ซึ่งมันก็จริงตรงตามคำพูดนี้เลยครับ

/prototype skill ใหม่ของ Matt และวิธีติดตั้ง

Matt Pocock เจ้าของช่อง AI ชื่อดัง ก็ได้เห็นปัญหาเรื่องนี้เช่นกัน ซึ่งเป็นแรงบันดาลใจหลักในการเขียนบทความนี้

Matt บอกว่าปัญหาที่คนส่วนใหญ่เจอจากการพิมพ์คุยยาวๆ คุยละเอียดๆ แล้วไม่ได้ผลลัพธ์ เพราะขาดการทำ prototype นั่นเอง

ซึ่ง Matt ได้สร้าง /prototype skill 🚀 และปรับ workflow หลักของเขาให้ใช้สกิลนี้ด้วย

Build a throwaway prototype to answer a design question. Use when the user wants to sanity-check whether a state model or logic feels right, or explore what a UI should look like.

สร้างโค้ดใช้แล้วทิ้ง เพื่อตอบคำถามการออกแบบ ใช้เมื่อต้องการตรวจสอบความเข้าใจของ logic การทำงาน และสำรวจว่า UI จะมีหน้าตาเป็นอย่างไร

ไม่มีอะไรที่ชัดเจนไปมากกว่าการลงมือทำจริง ถ้า AI ได้ลองทำ และเราเห็นภาพจริง AI รู้แล้วว่าถ้าทำจริงต้องทำอะไรบ้าง ไม่มั่ว เราเองก็เห็นว่าผลลัพธ์เป็นอย่างไรและ feedback ได้ ✅

แม้ว่าการทำ prototype จะเขียนโค้ดเหมือนกับการทำจริง แต่ต่างกันตรงที่ ไม่ลงรายละเอียดมากจนเกินไป ทำให้ได้ผลลัพธ์ที่จับต้องได้ และไม่เสียเวลา และไม่เปลือง token

วิธีติดตั้ง

npx skills add https://github.com/mattpocock/skills --skill prototype

(ลบ space ด้วยนะครับ)

#สรุปโดยหัวหน้าฮง

การทำ Prototype ช่วยทดสอบความเข้าใจได้เป็นอย่างดี ช่วยลดความผิดพลาดในการทำงานจริง ซึ่งเราคงไม่อยากปล่อยให้ AI ทำงานหลาย ชม. แล้วได้ผลลัพธ์ไม่ถูกต้อง

ต้นทุนในการทำตัวต้นแบบ (Prototype) ในยุคนี้ถูกมาก ลดจากการทำหลายชม จนถึงหลายวัน -> จนเป็นไม่กี่นาที ทำให้เราทดสอบความถูกต้องได้โดยง่ายขึ้นเยอะมากกกก

แม้ว่าการทำ prototype จะมีข้อดี แต่ก็ไม่ได้แปลว่าเราต้องใช้มันทุกครั้ง อ้าวว?

เราต้องเลือกใช้ tool ที่เหมาะกับงาน ถ้างานนั้นมันชัดเจนมากพอ มีความเสี่ยงต่อความผิดพลาดที่ต่ำ ก็ไม่ต้องทำ prototype ก็ได้ แต่ถ้าไม่ใช่ แนะนำให้ทำ prototype ครับ

ขอให้บทความนี้เป็นประโยชน์นะครับ ขอบคุณครับ

ปล. หัวหน้าฮงกลับมาแล้ว หลังจากหายไปเพราะยุ่งมาก ตอนนี้กลับมาแล้วครับ เย้ 🥳🚀