ทำไมตัวสร้างแอปด้วย AI ถึงแสดงข้อมูลปลอมให้คุณก่อน (และทำไมนั่นคือสิ่งที่ถูกต้อง)

คุณอธิบายแอปให้ตัวสร้างแอปด้วย AI ฟัง อีกหนึ่งนาทีต่อมาคุณก็กำลังมองหน้าจอที่ใช้งานได้ — มีหน้าต่างๆ ปุ่มต่างๆ ตารางผู้ใช้ที่มีชื่ออย่าง “Alex Rivera” และ “Priya Shah” ราคาที่ไม่สมเหตุสมผล “Pro Plan” ที่คุณไม่ได้ขอ ไม่มีอะไรถูกบันทึก ถ้าคุณรีเฟรช ข้อมูลยังอยู่ตรงนั้น ถ้าคุณเพิ่มผู้ใช้ใหม่ มันก็หายไป

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

”ข้อมูลปลอมก่อน” หมายความว่าอย่างไรกันแน่

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

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

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

ทำไมลำดับนี้ถึงได้ผลดีกว่ากับ AI

เราลองสร้างฐานข้อมูลและหน้าจอไปพร้อมๆ กัน มันไม่ได้ผล นี่คือเหตุผลฉบับย่อ

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

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

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

สิ่งที่ต้องมองหาเมื่อข้อมูลปลอมขึ้นบนหน้าจอ

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

ตัวอย่างสองสามอย่างที่ต้องจับตา:

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

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

ทำไมลำดับถึงสำคัญต่อสิ่งที่จะตามมา

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

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

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

การทดสอบเล็กๆ ที่คุณลองได้

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

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

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