ต้องทำอย่างไรเมื่อแอปที่สร้างด้วย AI พังตอนตีสอง (และคุณก็ไม่ใช่นักพัฒนา)

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

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

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

ก่อนอื่น: อย่ารีดีพลอย

มีปุ่มอยู่ที่ไหนสักแห่งใน AI app builder ของคุณที่เขียนว่าประมาณว่า “republish”, “redeploy”, หรือ “ship” คุณกำลังจะอยากกดมัน อย่าเพิ่ง

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

ก้าวแรกคือมองก่อน ไม่ใช่ลงมือทำเสมอ คุณยังไม่ได้ยืนยันด้วยซ้ำว่าอะไรพังกันแน่

ขั้นที่ 1 — ลองทำให้ปัญหาเกิดซ้ำด้วยตัวเอง

เปิดแอปในหน้าต่างเบราว์เซอร์ใหม่ — โหมดไม่ระบุตัวตน (incognito) หรือโหมดส่วนตัวดีที่สุด เพราะมันตัดล็อกอินเก่าหรือแคชที่อาจทำให้แอปแสดงผลกับคุณต่างจากผู้ใช้ของคุณออกไป

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

คุณกำลังมองหาหนึ่งในสามอย่างนี้:

1. มันพังสำหรับทุกคน คุณเจอปัญหาเดียวกัน ที่จริงนี่เป็นแบบที่แก้ง่ายที่สุด เพราะมันเกิดขึ้นสม่ำเสมอ
2. มันใช้งานได้สำหรับคุณ นี่คือสถานการณ์ที่ยากที่สุด เพราะมีบางอย่างเกี่ยวกับสถานการณ์เฉพาะของผู้ใช้คนนั้น (เบราว์เซอร์ของเขา บัญชีของเขา ข้อมูลของเขา) ที่เป็นปัญหา
3. มันเป็นๆ หายๆ ครั้งหนึ่งใช้ได้ ครั้งต่อมาพัง นี่คือแบบที่เครียดที่สุด แต่ก็ให้ข้อมูลมากที่สุดเช่นกัน — มันมักหมายความว่ามีบางอย่างหมดเวลา (timeout) หรือทรัพยากรกำลังจะหมด

จดไว้ว่าคุณเจอแบบไหนในสามแบบนี้ คุณจะต้องใช้มันตอนขอความช่วยเหลือ

ขั้นที่ 2 — ตรวจสิ่งภายนอกที่ชัดเจนก่อนจะโทษแอปของตัวเอง

ช่วงเวลา “แอปของฉันพัง” จำนวนมากอย่างน่าประหลาดใจไม่ได้เกิดจากแอปคุณ ก่อนจะมุดเข้าไปขุดใน AI builder ของคุณ ให้ตรวจสอบ:

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

ประมาณหนึ่งในห้าครั้ง คำตอบคือ “มันไม่ใช่แอปของฉันจริงๆ” และคุณก็กลับไปนอนต่อได้

ขั้นที่ 3 — ดูข้อความแสดงข้อผิดพลาด แม้มันจะดูน่ากลัว

ถ้าแอปของคุณแสดงหน้าจอที่มีข้อความบนนั้น — แม้จะเป็นข้อความที่ดูเหมือนตัวอักษรมั่วๆ — ก็อ่านมัน ถ่ายภาพหน้าจอเก็บไว้ โดยเฉพาะถ้ามีสตริงตัวอักษรและตัวเลขยาวๆ (คนเรียกมันว่า “stack trace” มันดูเหมือนซุปตัวอักษร แต่เป็นสิ่งที่มีประโยชน์ที่สุดที่คุณจะมีได้ตอนขอความช่วยเหลือ)

AI app builder ส่วนใหญ่ยังมีที่ให้ดูข้อผิดพลาดที่เพิ่งเกิดขึ้นด้วย มันอาจชื่อว่า Logs, Activity, Errors, หรือ Console เปิดมันขึ้นมา คุณไม่จำเป็นต้องเข้าใจสิ่งที่เห็นส่วนใหญ่ — คุณแค่มองหาข้อความสีแดงล่าสุดหรือข้อผิดพลาดล่าสุด และเวลาที่มันเกิดขึ้น เวลาสำคัญ: ข้อผิดพลาดจากเมื่อเช้าวานนี้น่าจะไม่ใช่เหตุผลที่ผู้ใช้ของคุณสมัครสมาชิกไม่ได้เมื่อกี้นี้

คัดลอกข้อผิดพลาดนั้นไว้ อีกสักครู่คุณจะเอาไปวางในที่ที่ช่วยได้

ขั้นที่ 4 — ถาม AI builder ว่ามีอะไรเปลี่ยนไป

นี่คือวิธีที่นักสร้างที่ไม่ใช่สายเทคนิคใช้น้อยเกินไปมากที่สุด เปิดแชทกับ AI builder ของคุณแล้วพูดด้วยภาษาธรรมดา:

“แอปของฉันพัง ผู้ใช้สมัครสมาชิกไม่ได้ — กดปุ่มแล้วไม่มีอะไรเกิดขึ้น นี่คือข้อผิดพลาดจาก logs: [วางมันตรงนี้] ในช่วง 24 ชั่วโมงที่ผ่านมามีอะไรเปลี่ยนไปบ้าง และอะไรอาจเป็นสาเหตุของเรื่องนี้?”

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

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

ขั้นที่ 5 — ตัดสินใจว่าจะย้อนกลับไหม

AI app builder แทบทุกตัวให้คุณย้อนกลับไปยังแอปเวอร์ชันก่อนหน้าได้ บางทีมันเรียกว่า “history”, “versions”, “checkpoints”, หรือ “rollback”

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

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

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

ขั้นที่ 6 — ถ้าคุณต้องปล่อยให้ AI builder แก้

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

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

ทดสอบการแก้ในวิธีที่น่าเบื่อที่สุดเท่าที่จะทำได้ อย่าแค่ถามว่า “แก้แล้วใช่ไหม?” แล้วเชื่อคำตอบ ให้ไปที่แอปด้วยตัวเองในหน้าต่าง incognito แล้วทำสิ่งที่เคยพังจริงๆ ถ้าการแก้ได้ผล สิ่งที่เคยพังก็จะใช้งานได้แล้วตอนนี้ ถ้ามันยังไม่ได้ผล อย่ายอมรับการเปลี่ยนแปลงเพียงเพราะ AI builder บอกว่ามันใช้งานได้

ขั้นที่ 7 — ตอบผู้ใช้กลับไป แม้คุณจะยังแก้ไม่ได้

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

“ขอบคุณที่แจ้งนะครับ — ผมกำลังดูอยู่ตอนนี้เลย พอมันกลับมาใช้งานได้ผมจะส่งข่าวไปบอกทันที”

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

บทเรียนที่ใหญ่กว่า: สร้างแอปของคุณเหมือนกับว่ามันอาจพังได้

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

• คุณจะเพิ่มการตรวจสอบสถานะ หน้าง่ายๆ ที่บอกคุณว่าส่วนสำคัญๆ ของแอปยังทำงานอยู่ไหม คุณจะได้ไม่ต้องล็อกอินเข้าไปดูเอง
• คุณจะเก็บสำรองข้อมูลผู้ใช้ไว้ AI builder ส่วนใหญ่ส่งออกข้อมูลให้คุณได้เมื่อร้องขอ ทำแบบนี้สัปดาห์ละครั้งใช้เวลา 30 วินาที และช่วยคุณได้ในสถานการณ์เลวร้ายที่สุด
• คุณจะจดไว้ว่าแอปของคุณพึ่งพาอะไรบ้าง รายการสั้นๆ ของเครื่องมือที่เชื่อมต่อไว้ทุกตัว (การชำระเงิน อีเมล ฐานข้อมูล ที่จัดเก็บ) เพื่อว่าเมื่อมีอะไรพังตอนตีสอง คุณจะมีเช็กลิสต์แทนการเดา
• คุณจะเปลี่ยนทีละอย่าง เมื่อคุณเปลี่ยน 10 อย่างพร้อมกันแล้วแอปพัง คุณจะไม่มีทางรู้เลยว่าการเปลี่ยนไหนเป็นต้นเหตุ เมื่อคุณเปลี่ยนทีละอย่าง คุณจะรู้

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

ข่าวดี: ทุกครั้งที่มันเกิดขึ้น มันจะน่ากลัวน้อยลง พอครั้งที่สาม มันจะกลายเป็นเรื่องน่ารำคาญแทนที่จะน่ากลัว พอครั้งที่สิบ มันก็แค่วันอังคารธรรมดาๆ วันหนึ่ง