ทำ prototype ด้วย AI ไปเสนอหัวหน้าหรือลูกค้าได้ไหม? ทำแค่ไหนถึงพอ และเมื่อไรควรต่อยอดเป็นระบบจริง

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

ทุกวันนี้คนทำงานในองค์กร ครู เจ้าหน้าที่รัฐ หรือฟรีแลนซ์ที่รับงานลูกค้า ใช้ Claude Code, Codex หรือ Cursor ทำต้นแบบกันเยอะขึ้นมาก จากผลงานกว่า 2,441 รายการบนแอปเทพ มีหลายชิ้นที่เจ้าของเขียนไว้ตรง ๆ ว่ายังเป็นต้นแบบ และเลือกทำจริงเฉพาะบางส่วน บทความนี้จะพาดูว่าต้นแบบที่ดีควรมีอะไร ตัดอะไรออกได้ และสัญญาณไหนที่บอกว่าถึงเวลาทำเป็นระบบจริงแล้ว

prototype กับ MVP ต่างกันยังไง

สองคำนี้มักถูกใช้ปนกัน แต่จุดประสงค์ไม่เหมือนกัน ถ้าแยกให้ชัดตั้งแต่ต้น จะรู้ว่าต้องลงแรงแค่ไหน

ปัญหาที่เจอบ่อยคือคนทำ prototype แต่ไปทุ่มแรงแบบระบบจริง เช่น ใช้เวลาเป็นอาทิตย์ทำระบบสมาชิกก่อนจะรู้ว่าหัวหน้าอยากได้ไหม หรือกลับกัน คือเอา prototype ที่เก็บข้อมูลไว้ในเครื่องไปให้คนทั้งแผนกใช้ทันที แล้วข้อมูลหายในสัปดาห์แรก

ตัวอย่างต้นแบบจริงจากผลงานคนไทย

ใช้ข้อมูลจำลองเกือบทั้งหมด แต่ทำจริงในจุดที่สำคัญ

AI-DSRP เป็นต้นแบบรับรายงานและติดตามโรคสำหรับเจ้าหน้าที่สาธารณสุข วางขั้นตอนรับ ตรวจสอบ และติดตามรายงานโรค พร้อมแนวทางใช้ OCR และ AI ลดการกรอกข้อมูล เจ้าของเขียนไว้ชัดว่าส่วนใหญ่ยังใช้ข้อมูลจำลอง แต่ส่วนเข้าสู่ระบบและการบันทึกยืนยัน รง.506 เชื่อมฐานข้อมูลจริงแล้ว

นี่คือรูปแบบที่น่าเอาไปใช้ เพราะเลือกทำจริงเฉพาะจุดที่คนใช้งานจะถามว่า "ใช้กับงานเราได้จริงไหม" ส่วนที่เหลือใช้ข้อมูลจำลองไปก่อน คนที่ได้ลองจึงเห็นทั้งภาพรวมของขั้นตอน และรู้ว่าส่วนสำคัญทำงานได้จริง

ให้คนทำแทน AI ไปก่อน

Playground Intelligence Zone Alert ส่งแจ้งเตือนเหตุในพื้นที่โรงเรียนให้ครูเวรรับทราบและปิดเรื่อง โดยเป้าหมายคือให้ AI วิเคราะห์ภาพ CCTV ของโรงเรียน แต่รุ่นนี้ให้ผู้ดูแลสร้างแจ้งเตือนแทน AI ไปก่อน

วิธีนี้ฉลาดมาก ส่วนที่ยากที่สุดคือการวิเคราะห์ภาพ ซึ่งต้องใช้เวลา ข้อมูล และค่าใช้จ่ายสูง แต่สิ่งที่โรงเรียนต้องตัดสินใจก่อนคือขั้นตอนหลังได้รับแจ้งเตือนใช้ได้ไหม ครูเวรรับทราบทันไหม ปิดเรื่องยังไง ถ้าขั้นตอนนี้ยังไม่ลงตัว ต่อให้ AI ตรวจจับเก่งแค่ไหนก็ไม่มีประโยชน์

เก็บข้อมูลไว้ในเครื่องก่อน

Personal Secretary Dashboard MVP รวมงานค้าง งานเร่ง กำหนดส่ง และช่องสั่งงานผู้ช่วย AI ผู้ใช้เพิ่ม แก้ไข เปลี่ยนสถานะ และลบงานได้ โดยต้นแบบเก็บข้อมูลใน localStorage เฉพาะเครื่องและ browser ที่ใช้งาน

localStorage เหมาะกับต้นแบบมาก เพราะไม่ต้องตั้ง database ไม่มีค่าใช้จ่าย และ deploy ขึ้น Vercel หรือ GitHub Pages ได้ทันที ข้อจำกัดคือเปลี่ยนเครื่องแล้วข้อมูลไม่ตามไป และถ้าล้าง browser ข้อมูลก็หาย การบอกข้อจำกัดนี้ไว้ตรง ๆ แบบที่เจ้าของผลงานทำ ช่วยให้คนลองใช้ไม่เข้าใจผิดว่าเป็นระบบที่เก็บงานจริงได้

ใช้เครื่องมือที่องค์กรมีอยู่แล้ว

Job Summary App บันทึกงานประจำวันร่วมกับ Google Sheets แสดงสถานะงานแบบ Kanban ให้ AI ตั้งชื่องานและเรียบเรียงบันทึกย่อเป็นรายงานภาษาไทยหรืออังกฤษ และแนบภาพผ่าน Google Drive ได้

ถ้าที่ทำงานใช้ Google Workspace อยู่แล้ว การใช้ Google Sheets เป็นที่เก็บข้อมูลช่วยให้ต้นแบบขยับไปเป็น MVP ได้ง่าย เพราะหัวหน้าเปิดดูข้อมูลในชีทได้เลยโดยไม่ต้องรอใครทำหน้าแอดมิน

ให้ผลลัพธ์เป็นสิ่งที่คนส่งต่อได้

SAR for Academic Research Paper ใช้ AI 3 บทบาทประเมินงานวิจัยตามเกณฑ์ 8 หัวข้อ พร้อมคำแนะนำและแผนพัฒนา เจ้าของระบุว่าใช้ประเมินปิดโครงการ สวพ.ทบ. ระบบรองรับผู้ให้บริการ AI หลายราย และส่งออกรายงาน HTML ได้

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

ต้นแบบที่ดีควรมีอะไรบ้าง

ก่อนเปิด Claude Code หรือ Cursor ให้ตอบคำถามนี้ก่อนว่า "คนที่จะดูต้นแบบนี้ ต้องตัดสินใจเรื่องอะไร" แล้วทำเฉพาะสิ่งที่ช่วยให้เขาตัดสินใจเรื่องนั้นได้

ส่วนที่ควรมี

1. เส้นทางหลัก 1 เส้นที่กดได้ตั้งแต่ต้นจนจบ เช่น กรอกรายงาน ส่ง แล้วเห็นสถานะเปลี่ยน
2. ข้อมูลจำลองที่หน้าตาเหมือนของจริง ใช้ชื่อหน่วยงาน ชื่อสินค้า หรือรูปแบบเอกสารที่คนดูคุ้นเคย
3. หน้าจอที่ใช้บนมือถือได้ เพราะคนส่วนใหญ่จะเปิดลิงก์จาก LINE
4. ป้ายบอกชัด ๆ ว่าส่วนไหนเป็นข้อมูลจำลอง ส่วนไหนทำงานจริง
5. ลิงก์ที่เปิดได้ทันทีโดยไม่ต้องติดตั้งอะไร

ส่วนที่ตัดออกได้

1. ระบบสมาชิกและการแยกสิทธิ์ ถ้ายังไม่ใช่หัวใจของงาน
2. หน้าตั้งค่า หน้าแอดมิน และหน้ารายงานย่อย
3. การเชื่อม API ภายนอกที่ต้องขออนุญาตหรือเสียเงิน ให้ใช้ข้อมูลตัวอย่างแทน
4. การรองรับคนจำนวนมากพร้อมกัน

ตอนสั่ง AI ให้บอกตั้งแต่ต้นว่า "นี่คือ prototype สำหรับนำเสนอ ใช้ mock data ไม่ต้องมี backend" AI จะไม่สร้างโครงสร้างใหญ่เกินจำเป็น และพอถึงวันที่ต้องทำจริงก็ค่อยสั่งเพิ่มทีละส่วน

สัญญาณว่าถึงเวลาต่อยอดเป็นระบบจริง

ต้นแบบมีหน้าที่ช่วยให้ได้คำตอบ เมื่อได้คำตอบแล้วก็ถึงเวลาเปลี่ยนเป็นของจริง สัญญาณที่ควรสังเกตมีดังนี้

ตัวอย่างปลายทางที่ชัดคือ TopInsure ที่รวมข้อมูลลูกค้า กรมธรรม์ งานติดตาม การคำนวณเบี้ยและค่าคอมมิชชั่น รวมถึงเอกสารไว้ในที่เดียว เพื่อให้ทีม Insurance Broker ลดงาน Manual และข้อมูลซ้ำซ้อน งานแบบนี้มีหลายคนใช้ข้อมูลชุดเดียวกันทุกวัน จึงต้องเป็นระบบจริงตั้งแต่โครงสร้าง ไม่ใช่ต้นแบบที่เก็บข้อมูลในเครื่องใครคนหนึ่ง

ข้อควรระวังตอนนำเสนอ

ต้นแบบที่ AI ทำมักดูสวยและลื่นจนคนดูเข้าใจว่าระบบเสร็จแล้ว ความเข้าใจผิดแบบนี้ทำให้เกิดปัญหาตามมาหลายเรื่อง

ข้อแรก อย่าใส่ข้อมูลจริงของคนลงในต้นแบบที่ deploy เป็นลิงก์สาธารณะ โดยเฉพาะข้อมูลผู้ป่วย นักเรียน หรือลูกค้า ใช้ข้อมูลที่แต่งขึ้นเท่านั้น

ข้อสอง บอกเวลาและงานที่เหลือให้ชัด เช่น "หน้าตาและขั้นตอนพร้อมแล้ว แต่ยังต้องทำระบบ login, database และการสำรองข้อมูล" หัวหน้าจะได้ไม่คาดหวังว่าพรุ่งนี้เปิดใช้ได้ทันที

ข้อสาม เก็บผลตอบรับเป็นข้อ ๆ ระหว่างให้คนลอง ว่ากดตรงไหนแล้วงง ขั้นตอนไหนไม่ตรงกับงานจริง แล้วเอาไปเป็น prompt รอบถัดไป วิธีนี้ทำให้รอบแก้แต่ละครั้งสั้นลงมาก

ข้อสี่ ถ้าในต้นแบบมีส่วนที่ AI ยังทำไม่ได้จริงแบบ Zone Alert ให้บอกตรง ๆ ว่าตอนนี้คนทำแทนอยู่ การบอกตรง ๆ ทำให้คนดูเชื่อถือมากกว่าการทำให้ดูเหมือนเสร็จหมดแล้ว

สรุป

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