วิธีนำต้นแบบที่สร้างด้วย AI ขึ้นใช้งานจริง

ในการนำต้นแบบ AI ขึ้นใช้งานจริง คุณต้องปิดช่องว่างระหว่าง “มันทำงานเมื่อฉันลองใช้” กับ “มันยังทำงานต่อไปเมื่อคนอื่นใช้” ในทางปฏิบัติคือห้าเรื่อง: ทดสอบขั้นตอนหลักทุกครั้งที่เปลี่ยนแปลงอะไร ควบคุมให้ชัดว่าใครเห็นและเปลี่ยนอะไรได้บ้าง ให้แน่ใจว่าคุณรู้เรื่องข้อผิดพลาดก่อนที่ผู้ใช้จะมาบอก สำรองข้อมูลและพิสูจน์ว่ากู้คืนได้ และทำให้แอปเร็วพอบนโทรศัพท์ ไม่มีสิ่งใดต้องเขียนใหม่ทั้งหมด มันเป็นเช็กลิสต์ที่คุณทำไปพร้อมกับ AI ตัวเดียวกับที่สร้างต้นแบบนั่นเอง

ต้นแบบกับระบบใช้งานจริง: อะไรเปลี่ยนไปบ้าง

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

ส่วนที่เหลือของคู่มือนี้จะอธิบายทีละแถวของตารางนี้

ขั้นตอนที่ 1: กำหนดขอบเขตและจดขั้นตอนหลัก

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

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

ขั้นตอนที่ 2: ทดสอบเหมือนคนแปลกหน้า แล้วทำให้ทำซ้ำได้

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

• ข้อมูลนำเข้าที่ผิด: ช่องที่จำเป็นว่างเปล่า ชื่อยาว 5,000 ตัวอักษร อีเมลที่ไม่มี @ จำนวนติดลบ วันที่ในอดีต
• การรีเฟรชและปุ่มย้อนกลับ: รีโหลดกลางคันระหว่างชำระเงิน กดย้อนกลับหลังส่งฟอร์ม มีอะไรถูกสร้างซ้ำสองครั้งหรือไม่
• สองแท็บ สองผู้ใช้: ล็อกอินด้วยบัญชีต่างกันสองบัญชี แล้วลองเปิดหน้าของกันและกันโดยเปลี่ยน ID ใน URL
• ช้าและเล็ก: หน้าจอขนาดโทรศัพท์และการเชื่อมต่อที่จำกัดความเร็ว (เครื่องมือนักพัฒนาของเบราว์เซอร์จำลองได้)
• สถานะว่างเปล่า: บัญชีใหม่ที่ไม่มีข้อมูล ต้นแบบมักถูกสร้างด้วยข้อมูลตัวอย่าง และดูพังเมื่อไม่มีข้อมูลเหล่านั้น

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

เพิ่มการทดสอบ end-to-end อัตโนมัติสำหรับขั้นตอนเหล่านี้: สมัครสมาชิกด้วยอีเมล สร้างโปรเจกต์ เชิญผู้ใช้คนที่สอง และชำระเงินให้สำเร็จใน Stripe โหมดทดสอบ เพิ่มการทดสอบที่ยืนยันว่าผู้ใช้ไม่สามารถดูหรือแก้ไขโปรเจกต์ของผู้ใช้อื่นได้ด้วยการเปลี่ยน URL

การทดสอบที่พิสูจน์ว่าผู้ใช้ ไม่สามารถ ทำอะไรได้ เป็นสิ่งที่ต้นแบบมักขาดมากที่สุด

ขั้นตอนที่ 3: พื้นฐานความปลอดภัยที่ต้นแบบมักข้าม

ปัญหาความปลอดภัยส่วนใหญ่ในแอปที่สร้างด้วย AI ไม่ได้แปลกประหลาด แต่เป็นการตรวจสอบที่หายไป ไล่ดูรายการนี้ และดูเช็กลิสต์ความปลอดภัยฉบับเต็มสำหรับแอปที่สร้างด้วย AI ประกอบ:

• การอนุญาตในฝั่งเซิร์ฟเวอร์ การซ่อนปุ่มไม่ใช่ความปลอดภัย ทุกคำขอที่อ่านหรือเปลี่ยนข้อมูลต้องตรวจบนเซิร์ฟเวอร์ว่าผู้ใช้ที่ล็อกอินอยู่มีสิทธิ์ทำเช่นนั้น ถ้าแอปใช้ฐานข้อมูลที่มีกฎระดับแถว ให้ตรวจว่าเปิดใช้งานและทดสอบแล้ว
• ความลับต้องไม่ไปถึงเบราว์เซอร์ คีย์ API สำหรับการชำระเงิน อีเมล หรือผู้ให้บริการ AI ต้องอยู่ในตัวแปรสภาพแวดล้อมฝั่งเซิร์ฟเวอร์ ห้ามอยู่ในโค้ดฝั่งหน้าบ้านเด็ดขาด หากไม่แน่ใจว่าหมายถึงอะไร ให้อ่านตัวแปรสภาพแวดล้อมและความลับคืออะไร
• การตรวจข้อมูลนำเข้าในฝั่งเซิร์ฟเวอร์ เบราว์เซอร์สามารถข้ามได้ ดังนั้นให้ทำซ้ำการตรวจที่สำคัญทุกอย่างบนเซิร์ฟเวอร์
• การล็อกอินที่ทำอย่างถูกต้อง ใช้ไลบรารีหรือบริการยืนยันตัวตนที่ผ่านการทดสอบดีแล้ว แทนการเก็บรหัสผ่านเองที่เขียนขึ้นมาใหม่ คู่มือวิธีเพิ่มการล็อกอินในแอปของคุณ ครอบคลุมตัวเลือกต่างๆ
• การจำกัดอัตราคำขอ (rate limit) สำหรับการล็อกอิน การสมัครสมาชิก การรีเซ็ตรหัสผ่าน และทุกอย่างที่ส่งอีเมลหรือเรียก API ที่เสียเงิน
• ข้อความผิดพลาดที่เป็นมิตร ผู้ใช้ควรเห็นข้อความว่า “เกิดข้อผิดพลาด” ส่วนรายละเอียดต้องไปอยู่ในล็อกของคุณ ไม่ใช่หน้าจอ
• เปลี่ยนคีย์ทุกตัวที่เคยรั่ว หากคีย์จริงเคยถูกวางในแชต คอมมิต หรือภาพหน้าจอ ให้เปลี่ยนที่ผู้ให้บริการ

พรอมต์ที่ครอบคลุมหลายเรื่องพร้อมกัน:

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

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

ขั้นตอนที่ 4: รู้ว่าเมื่อไหร่แอปพัง ด้วยการบันทึกและการมอนิเตอร์

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

1. ล็อกของเซิร์ฟเวอร์ ตรวจให้แน่ใจว่าข้อผิดพลาดถูกบันทึกพร้อมบริบทเพียงพอที่จะทำซ้ำได้ เช่น route ไหน ID ของผู้ใช้ (ไม่ใช่รหัสผ่านหรือข้อมูลบัตร) และรูปแบบข้อมูลนำเข้า ขอให้ AI เพิ่มการบันทึกแบบมีโครงสร้างหากแอปพิมพ์ออกทางคอนโซลอย่างเดียว
2. การติดตามข้อผิดพลาด บริการอย่าง Sentry หรือเครื่องมือที่คล้ายกันจะจับข้อยกเว้นทั้งฝั่งหน้าบ้านและหลังบ้าน จัดกลุ่ม และส่งอีเมลถึงคุณ สำหรับแอปขนาดเล็ก แพ็กเกจฟรีของบริการเหล่านี้มักเพียงพอ ตรวจขีดจำกัดปัจจุบันบนเว็บไซต์ของพวกเขา
3. การตรวจสอบเวลาทำงาน (uptime) บริการภายนอกที่โหลดหน้าแรกและ API route สำคัญทุกไม่กี่นาที และแจ้งเตือนหากล้มเหลว ซึ่งจับปัญหาที่ทำให้แอปไม่สามารถบันทึกล็อกได้เลย

เพิ่มนิสัยอีกหนึ่งอย่าง: หลังทุกการเปิดตัว ให้เปิดแอปที่ใช้งานจริงและรันเช็กลิสต์ขั้นตอนหลักบน URL จริง ไม่ใช่แค่ในพรีวิว

ขั้นตอนที่ 5: การสำรองข้อมูลและทางกลับ

มีสองสิ่งที่ต้องปกป้อง และมักสับสนกันได้ง่าย

• โค้ด เก็บโปรเจกต์ไว้ในระบบควบคุมเวอร์ชัน เพื่อให้ย้อนการเปลี่ยนแปลงใดๆ ได้ เครื่องมือสร้างหลายตัวเก็บจุดตรวจ (checkpoint) ของไฟล์ไว้ และการซิงก์ไปยังรีโพซิทอรี Git ให้สำเนานอกเครื่องมือสร้างด้วย
• ข้อมูล การย้อนโค้ดกลับไม่ได้ย้อนฐานข้อมูลกลับ การย้ายข้อมูล (migration) ที่ผิดพลาดหรือปุ่มลบที่มีบั๊กอาจทำลายแถวที่ไม่มีจุดตรวจโค้ดใดนำกลับมาได้

สำหรับข้อมูล ตั้งการสำรองเป็นประจำที่เก็บไว้นอกโฮสติ้งของแอป สำหรับฐานข้อมูล Postgres วิธีที่นิยมคือตั้งเวลา pg_dump ไปยังที่เก็บแยกต่างหาก และผู้ให้บริการฐานข้อมูลหลายรายมีการสำรองอัตโนมัติหรือการกู้คืนตามจุดเวลา จากนั้นทำขั้นตอนที่คนส่วนใหญ่ข้าม: กู้คืนการสำรองไปยังฐานข้อมูลทดลองและตรวจว่าข้อมูลยังอยู่

นอกจากนี้ ขอให้ AI ทำให้การกระทำที่ทำลายข้อมูลปลอดภัยขึ้น เช่น ขั้นตอนยืนยันก่อนลบ และ “soft delete” (ทำเครื่องหมายแถวว่าถูกลบแทนการลบจริง) สำหรับสิ่งที่ผู้ใช้อาจอยากได้คืน

ขั้นตอนที่ 6: ประสิทธิภาพที่ใช้ได้บนโทรศัพท์

ต้นแบบดูเร็วเพราะคุณเป็นผู้ใช้เพียงคนเดียวและชุดข้อมูลเล็กมาก ก่อนเปิดตัว:

• โหลดข้อมูลขนาดจริง ขอให้ AI ใส่ข้อมูลหลายพันแถวและดูว่าหน้าไหนช้าลง รายการมักต้องมีการแบ่งหน้า (pagination) และฐานข้อมูลมักต้องมีดัชนี (index) บนคอลัมน์ที่คุณกรองและเรียงลำดับ
• ย่อขนาดรูปภาพ รูปที่ใหญ่เกินไปเป็นสาเหตุที่พบบ่อยที่สุดที่หน้าโหลดช้า ขอให้ปรับขนาดและบีบอัดรูป และโหลดแบบ lazy สำหรับส่วนที่อยู่ด้านล่างหน้าจอ
• วัดผล รัน Lighthouse ในเครื่องมือนักพัฒนาของ Chrome บน URL จริงในโหมดมือถือ เป้าหมายที่สมเหตุสมผลคือ Core Web Vitals ของ Google ได้แก่ Largest Contentful Paint ภายใน 2.5 วินาที Interaction to Next Paint ที่ 200 มิลลิวินาทีหรือน้อยกว่า และ Cumulative Layout Shift ที่ 0.1 หรือน้อยกว่า
• ระวังความหน่วงตอนปลุกระบบ โฮสติ้งที่หลับเมื่อไม่ได้ใช้งานช่วยประหยัดเงิน แต่ทำให้การเข้าชมครั้งแรกหลังช่วงเงียบช้าลง ซึ่งมักเป็นการแลกเปลี่ยนที่ยอมรับได้สำหรับแอปใหม่ แต่ควรรู้ว่ากำลังเกิดขึ้น

หน้าโปรเจกต์ช้าเมื่อมี 5,000 แถว เพิ่มการแบ่งหน้าฝั่งเซิร์ฟเวอร์ (25 รายการต่อหน้า) เพิ่มดัชนีฐานข้อมูลสำหรับคอลัมน์ที่เรากรองและเรียงลำดับ และแสดงสถานะกำลังโหลดระหว่างที่หน้าถัดไปโหลด

ขั้นตอนที่ 7: พื้นฐานการดำเนินงาน

สิ่งเล็กๆ ไม่กี่อย่างแยกแอปงานอดิเรกออกจากแอปที่ผู้คนไว้ใจ:

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

ขั้นตอนที่ 8: การส่งมอบงานที่เรียบร้อย

ไม่ช้าก็เร็วจะมีคนอื่นทำงานกับแอปนี้: ฟรีแลนซ์ ผู้ร่วมก่อตั้งคนใหม่ หรือตัวคุณเองในอีกหกเดือน ทำให้มันง่าย:

• README ที่บอกวิธีรันแอป ตัวแปรสภาพแวดล้อมที่ต้องใช้ (เฉพาะชื่อ ไม่ใช่ค่า) และวิธีนำขึ้นระบบ
• เช็กลิสต์ขั้นตอนหลัก และการทดสอบอัตโนมัติ
• บันทึกสถาปัตยกรรมสั้นๆ: front end, back end, ฐานข้อมูล บริการของบุคคลที่สาม และที่โฮสต์ของแต่ละส่วน
• รายการการเข้าถึง: ใครมีสิทธิ์แอดมินของโดเมน โฮสติ้ง ฐานข้อมูล บัญชีการชำระเงินและอีเมลบ้าง ให้บัญชีเหล่านี้อยู่ภายใต้อีเมลธุรกิจ ไม่ใช่อีเมลส่วนตัว
• โค้ดใน Git ควรซิงก์ไปยังรีโพซิทอรีที่คุณเป็นเจ้าของ หากคุณอาจย้ายโฮสติ้งในภายหลัง ให้อ่านวิธีส่งออกและโฮสต์แอปที่สร้างด้วย AI เอง

AI สามารถร่างส่วนใหญ่ของสิ่งเหล่านี้ให้คุณได้:

เขียน README สำหรับโปรเจกต์นี้ให้นักพัฒนาที่ไม่เคยเห็นมาก่อน: แอปทำอะไร tech stack วิธีรันบนเครื่อง ตัวแปรสภาพแวดล้อมทุกตัวที่อ่าน (เฉพาะชื่อและวัตถุประสงค์) โครงสร้างสคีมาฐานข้อมูล และวิธีนำขึ้นระบบ

เช็กลิสต์ความพร้อมก่อนใช้งานจริง

• บันทึกและทดสอบขั้นตอนหลักแล้ว รวมถึง “เข้าถึงข้อมูลของคนอื่นไม่ได้”
• การอนุญาตและการตรวจข้อมูลนำเข้าฝั่งเซิร์ฟเวอร์ในทุก route ที่เกี่ยวกับข้อมูล
• ไม่มีคีย์ลับในโค้ดฝั่งหน้าบ้าน และเปลี่ยนคีย์ที่รั่วไหลแล้ว
• การจำกัดอัตราคำขอสำหรับการยืนยันตัวตนและทุกอย่างที่มีค่าใช้จ่าย
• การติดตามข้อผิดพลาดและการแจ้งเตือนเวลาทำงานที่ส่งไปยังกล่องจดหมายที่คุณเปิดอ่าน
• การสำรองฐานข้อมูลอยู่นอกโฮสติ้งของแอป และทดสอบการกู้คืนสำเร็จอย่างน้อยหนึ่งครั้ง
• ตรวจการแบ่งหน้าและดัชนีด้วยข้อมูลที่สมจริงแล้ว
• โดเมนของตัวเอง โดเมนส่งอีเมลที่ยืนยันแล้ว และนโยบายความเป็นส่วนตัว
• README และรายการการเข้าถึงสำหรับผู้ที่จะมารับช่วงต่อ

ทำสิ่งนี้กับ Mythex

หากคุณสร้างต้นแบบใน Mythex ขั้นตอนส่วนใหญ่ของเรื่องนี้คือพรอมต์ในโปรเจกต์เดียวกัน พิมพ์ /test แล้ว Mythex จะคลิกผ่านพรีวิวสดเหมือนผู้ใช้และรายงานขั้นตอนที่พัง ดู การทดสอบแอป คีย์ใส่ในความลับของโปรเจกต์แทนการใส่ในแชต ทุกเทิร์นของเอเจนต์ที่สำเร็จจะบันทึกจุดตรวจของไฟล์ที่คุณย้อนกลับได้ และการเผยแพร่ให้ URL สดพร้อมโฮสติ้ง โดยฐานข้อมูลและโฮสติ้งหักจากยอดเครดิตเดียวกัน (ขีดจำกัดโฮสติ้ง อธิบายว่าแอปและฐานข้อมูลหลับและตื่นอย่างไร) จุดตรวจครอบคลุมไฟล์ ไม่ใช่แถวในฐานข้อมูล ดังนั้นยังต้องวางแผนการสำรองข้อมูลของคุณเอง ในแผน Pro คุณเชื่อมต่อโดเมนของตัวเองได้ และส่งออกโค้ดหรือซิงก์ไปยังรีโพซิทอรี GitHub ของคุณเองเพื่อส่งมอบงานได้

คำถาม