Case 02 / 09
นักวางแผนที่กำกับ AI สร้างคนเดียว: คอมเมิร์ซแฟชั่นสำหรับคนไทย + ลองเสื้อผ้าเสมือนจริงด้วย AI ใช้งานจริงแล้วที่ mechoose.store
2026.02 – 2026.07 (ใช้งานจริง) / คนเดียว (AI เป็นทีม) / Web · iOS · Android
ผลลัพธ์
⚡ ไอเดีย→เปิดตัว
เว็บใช้งานจริง ~1 สัปดาห์ · App Store ~6 สัปดาห์
2026-02-03
คำสั่งแรก · บิลด์แรกที่ใช้งานได้
+6 days
2026-02-09
เว็บใช้งานจริง (mechoose.store)
+36 days
2026-03-17
ได้รับอนุมัติบน App Store
+120 days
2026-07-15
คอมมิตล่าสุด
จากไอเดียสู่เว็บที่ใช้งานจริง ~1 สัปดาห์ · ได้รับอนุมัติและเปิดตัวบน App Store ~6 สัปดาห์ (2026-03-17) · มีบน Google Play ด้วย · ทำงานจริง ~33 วันตามคอมมิตใน git
01
คำสั่งแรก: "ผมไม่มีพื้นฐานการเขียนโค้ด เลยสร้างแอปคอมเมิร์ซด้วย Figma Make AI กับ GPT — แต่หน้า My Page ขึ้น error ตลอดจนผมติด ช่วยได้ไหม?" ต้นฉบับ (KO): "기술이 없어서 Figma Make랑 GPT로 커머스를 만들고 있는데, 마이페이지에서 에러가 자꾸 나 막혀요 — 도와줄래요?"
ผมอยากได้บริการช้อปปิ้งแฟชั่นสำหรับผู้บริโภคชาวไทย ที่เลือกเสื้อผ้า ลองสวมแบบเสมือน และสั่งซื้อได้ทันที นอกจากพื้นฐานของคอมเมิร์ซ (แคตตาล็อก การชำระเงิน คำสั่งซื้อ แอดมิน) เป้าหมายคือให้บริการลองเสื้อผ้าเสมือนจริงด้วย AI และการปรึกษาสไตลิสต์ไว้ในที่เดียว
02
03
Fig. mechoose-direction
การกำกับ AI
01 คำสั่งแรก
สร้างหน้าแคตตาล็อก ตะกร้า และ My Page พร้อม API บน edge function
02 สิ่งที่ผมตรวจ
ผมสั่งซื้อจริงบนเว็บไซต์ที่ใช้งานจริง และพบจุดที่การชำระเงินค้าง และจุดที่การกรอกที่อยู่ทำให้พิมพ์ผิดหรือตกหล่น
03 การแก้ไข
ผมแปลงปัญหาของผู้ใช้เป็นคำสั่งฟีเจอร์ — "ให้การชำระเงินที่ค้างกลับมาทำต่อได้" "ให้ที่อยู่เติมอัตโนมัติและใส่รหัสไปรษณีย์ให้เอง"
คำสั่งจริง (ตัดตอน)
Fig. mechoose-03
เปลี่ยนปัญหาเป็นฟีเจอร์ ด้วยคำสั่งที่เป็นคำพูด
Before
คำสั่งของผม (ตัดตอน)
ให้ผู้ใช้กลับมาชำระคำสั่งซื้อที่ถูกขัดจังหวะต่อได้
Original결제가 끊긴 주문을 다시 이어서 결제하게 해 줘After
04
Case 01
อาการ
คำสั่งซื้อที่การชำระเงินถูกขัดจังหวะถูกปล่อยค้างไว้และไม่เกิดยอดขาย
สิ่งที่ผมบอก AI
ผมอยากให้ผู้ใช้กลับมาชำระเงินที่ค้างไว้ต่อได้" โดยอธิบายเป็น flowOriginal결제가 끊긴 주문을 사용자가 다시 이어서 결제하게 하고 싶다"고 플로우로 전달.
ความพยายามแรกของ AI
ป้ายสถานะธรรมดาไม่ช่วยให้ผู้ใช้หาจุดที่ค้างไว้เจอ
จุดที่ผมจับได้
สถานะ "รอชำระเงิน" ต้องเด่นทั้งในแบนเนอร์และใน My Page และต้องชำระต่อจากจุดที่หยุดได้
วิธีแก้
เพิ่ม flow กลับเข้ามาชำระต่อ ลดการหลุดออกกลางทาง
การป้องกันไม่ให้เกิดซ้ำ
สำหรับ flow ที่อาจถูกขัดจังหวะ ผมออกแบบสถานะ "หยุด–ทำต่อ" ไว้ตั้งแต่ต้น
05
Fig. mechoose-08
โค้ดเว็บชุดเดียว → เว็บ, iOS, Android และแบ็กเอนด์ serverless
06
ฟีเจอร์เพิ่มได้เร็วเมื่อผมสั่งงานด้วยเสียง แต่โครงสร้างหน้าจอช่วงแรกถูกอัดไว้ในไฟล์เดียวจนแก้ไขยากขึ้น ครั้งหน้าผมจะตั้งมาตรฐานตั้งแต่ต้นให้แยกหน้าจอและการจัดการ state เป็นชิ้นเล็กตามหน้าที่
หน้าจอเพิ่มเติม · 3 ภาพ
UI shown in English for portfolio; product data is the live Thai catalog (seller photos blurred).
(01) Review
ถ้านักพัฒนาเป็นคนสร้าง
ขอบเขตฟีเจอร์ — บริการคอมเมิร์ซครบวงจรที่ใช้งานจริง
ร้านค้า ตะกร้า รายการโปรด การชำระเงินด้วยบัตรจริงและการคืนเงิน การเคลมและคืนสินค้า สต็อก รีวิว แอปสไตลิสต์ แผงแอดมิน ล็อกอินโซเชียล 4 แบบ พุชและการแจ้งเตือนทาง LINE — ใช้งานจริงบนเว็บ App Store และ Google Play
ประสิทธิภาพ — main bundle ลดจาก 1.6MB → 454KB
แยกโค้ด vendor เป็น 5 chunk โหลดแอปแอดมินเฉพาะเมื่อจำเป็น (ย้ายออกไป 664KB) แคชข้อมูล 5 นาที และ lazy-load รูปภาพ
ความเร็วและต้นทุน — เว็บใช้งานจริงใน ~1 สัปดาห์ App Store ใน ~6 สัปดาห์
พัฒนาจริง ~8 สัปดาห์ ~51K บรรทัด คอมมิตของผมเอง 100 ครั้ง
ความปลอดภัยพื้นฐาน — เทียบเท่าทีมเล็ก
ตรวจสิทธิ์แอดมินทุกเส้นทางของแอดมิน ตรวจยอดชำระซ้ำบนเซิร์ฟเวอร์ จำกัด origin ที่อนุญาต จำกัดอัตราการเรียก (rate limiting) มี security header และไม่ส่งคีย์ฝั่งเซิร์ฟเวอร์ไปกับแอป
การเปิดตัวและการดูแลระบบ — เว็บ + แอปสโตร์ 2 แห่งจากโค้ดเบสเดียว
Vercel สำหรับเว็บ Capacitor สำหรับ iOS/Android มี deep link, PWA และหน้าจอข้อผิดพลาดที่แสดงรหัสอ้างอิง
การรองรับหลายภาษา — ตลาดเดียว เน้นภาษาไทยเป็นหลัก
คีย์แปล 245 คีย์ ยังมีข้อความฮาร์ดโค้ดเหลืออยู่บางส่วน
เอกสาร — บันทึกสถาปัตยกรรมและการตัดสินใจไว้
ตัวเลขบางส่วนในเอกสารคลาดเคลื่อนจากโค้ด
การทดสอบและระบบอัตโนมัติ — ยังไม่มีการทดสอบ CI lint หรือการตรวจ type
ทุกการปล่อยเวอร์ชันตรวจด้วยมือบน flow การซื้อจริง
วางแผน → เริ่มจากตรรกะการชำระเงินและคำสั่งซื้อ: unit test 10–20 ชุด จากนั้นบิลด์ + ตรวจ type + ทดสอบทุกคอมมิต
สถาปัตยกรรม — แบ็กเอนด์โตเป็นไฟล์เดียว 6,299 บรรทัด บน key-value store ตัวเดียว
เส้นทาง API 137 เส้นอยู่ในไฟล์เดียว และข้อมูลอยู่ใน store แบบทั่วไปตัวเดียว ฐานข้อมูลจึงบังคับความสัมพันธ์ของข้อมูลไม่ได้
วางแผน → แยกตามโดเมน (คำสั่งซื้อ → การชำระเงิน → แอดมิน) และย้ายคำสั่งซื้อกับการชำระเงินไปตารางที่เหมาะสมพร้อม migration
ความสม่ำเสมอของโค้ด — type หลวม และมีไฟล์สำเนาค้างอยู่
มีจุดที่ไม่ระบุ type (`any`) 940 จุด การพัฒนาอย่างรวดเร็วทำให้มีโค้ดเซิร์ฟเวอร์ค้างอยู่ 3 สำเนาและไฟล์สำรอง
วางแผน → ใช้การตรวจ type แบบเข้มงวดเป็นด่านก่อนปล่อยเวอร์ชัน เริ่มลบ `any` จากส่วนชำระเงิน และลบสำเนาที่ไม่ใช้แล้ว
ประวัติและการมอนิเตอร์ — คอมมิตตามรอยยาก ไม่มีระบบแจ้งเตือน
141 จาก 241 คอมมิตเป็นการซิงก์อัตโนมัติจากเครื่องมือออกแบบ ข้อผิดพลาดมีรหัสอ้างอิง แต่ยังไม่มีอะไรแจ้งเตือนผมอัตโนมัติ
วางแผน → แยกคอมมิตฟีเจอร์ที่มีข้อความชัดเจนออกจากการซิงก์ดีไซน์ และเพิ่มการติดตามข้อผิดพลาดกับการสำรองข้อมูลตามรอบเข้าไปในขั้นตอนดีพลอย
โปรเจกต์ถัดไป →
Momento
กำกับ AI ให้สร้างแอปเดียวกันแบบเนทีฟทั้งบน iOS และ Android — แอปเก็บความทรงจำของคู่รักที่จับคู่ช่วงเวลาให้อัตโนมัติ
