Case 03 / 09
กำกับ AI ให้สร้างแอปเดียวกันแบบเนทีฟทั้งบน iOS และ Android — แอปเก็บความทรงจำของคู่รักที่จับคู่ช่วงเวลาให้อัตโนมัติ
2026.05 – 2026.06 / คนเดียว (AI เป็นทีม) / iOS · Android
ผลลัพธ์
⚡ ไอเดีย→เปิดตัว
~7–8 สัปดาห์
2026-03-21
คำสั่งแรก
+45 days
2026-05-05
บิลด์แรกที่ใช้งานได้
+45 days
2026-06-19
เปิดตัวครั้งแรก · ล่าสุด
จากเริ่มพัฒนา (04-27) สู่ TestFlight ~7–8 สัปดาห์ (ทำงานจริง ~23 วัน) · ช่วงห่างระหว่างไอเดียกับการเริ่มพัฒนา ~5 สัปดาห์ (ทำโปรเจกต์อื่นคู่ขนาน)
01
คำสั่งแรก: "เวลาคู่รักอยู่ในที่ใกล้ ๆ กัน (ระยะคลาดเคลื่อน ~10m) แล้วคนใดคนหนึ่งถ่ายรูป ให้รวบรวมรูปนั้นพร้อมวันที่และสถานที่ให้อัตโนมัติ — ทำได้ไหม?" ต้นฉบับ (KO): "커플 둘이 비슷한 공간(오차 10m)에 같이 있을 때 한 명이 사진을 찍으면, 그 사진을 날짜·위치와 함께 자동으로 모아주기 — 할 수 있나?"
การบันทึกทุกช่วงเวลาร่วมกันด้วยมือเป็นเรื่องน่าเบื่อ ไอเดียนี้มาจากชีวิตประจำวัน: จะเป็นอย่างไรถ้าแอปรู้เองว่าสองคนอยู่ที่เดียวกันในเวลาเดียวกัน แล้วรวบรวมเป็นความทรงจำให้
02
03
Fig. momento-03
การกำกับ AI
01 คำสั่งแรก
สร้างฟีเจอร์เดียวกันบน iOS และ Android ตามแบบของแต่ละแพลตฟอร์ม
02 สิ่งที่ผมตรวจ
ผมรันบิลด์และหน้าจอ และพบจุดที่วันที่จากเซิร์ฟเวอร์ทำให้พัง และจุดที่บิลด์ Android ค้าง
03 การแก้ไข
ผมสั่งงานโดยชี้ไปที่สาเหตุ — "สร้าง decoder ที่รับรูปแบบวันที่หลากหลายจากเซิร์ฟเวอร์ได้อย่างยืดหยุ่น" "เครื่องมือ DI ของ Android ไม่เข้ากัน ให้เปลี่ยนไปใช้ singleton แบบเขียนเอง"
คำสั่งจริง (ตัดตอน)
04
Fig. momento-07
ย้ายการจับคู่ตำแหน่งจากอุปกรณ์ไปไว้บนเซิร์ฟเวอร์
Case 01
อาการ
วันที่จากเซิร์ฟเวอร์ decode บน iOS ไม่สำเร็จ ทำให้หน้าจอพัง
สิ่งที่ผมบอก AI
รูปแบบวันที่จากเซิร์ฟเวอร์ไม่สม่ำเสมอ การ parse จึงล้มเหลว" ในฐานะข้อเท็จจริงOriginal서버 날짜 형식이 일정치 않아 파싱이 실패한다"고 사실로 전달.
ความพยายามแรกของ AI
การแก้ที่สมมติว่ามีรูปแบบเดียว ล้มเหลวกับรูปแบบอื่น
จุดที่ผมจับได้
ต้องมี decoder ที่ยืดหยุ่นและรับได้หลายรูปแบบ
วิธีแก้
กำกับให้สร้าง decoder เฉพาะ (รับได้หลายรูปแบบ)
การป้องกันไม่ให้เกิดซ้ำ
ผมถือว่าค่าที่มาจากภายนอก "รูปแบบอาจเปลี่ยนได้" และ parse อย่างระมัดระวัง
Case 02
อาการ
บิลด์ Android ล้มเหลวจากความขัดกันระหว่างเครื่องมือ DI (Hilt) กับการตั้งค่าบิลด์เวอร์ชันล่าสุด
สิ่งที่ผมบอก AI
แชร์อาการพร้อม build logOriginal빌드 로그와 함께 증상 전달.
ความพยายามแรกของ AI
การเปลี่ยนเวอร์ชันอย่างเดียวแก้ไม่ได้
จุดที่ผมจับได้
การเลี่ยงไปใช้ singleton แบบเขียนเองแทน Hilt คือทางที่ถูก
วิธีแก้
กำกับให้เปลี่ยนไปใช้ singleton แบบเขียนเอง ทำให้บิลด์เสถียร
การป้องกันไม่ให้เกิดซ้ำ
ผมไม่ฝืนใช้เครื่องมือที่ไม่เข้ากัน — ชั่งน้ำหนักทางเลือกอื่นก่อน
05
06
การสั่งฟีเจอร์เดียวกันในสองแบบสอนผมว่ามันไม่ใช่การคัดลอกวาง — แต่ละแพลตฟอร์มมีการออกแบบที่เป็นธรรมชาติของตัวเอง และผมต้องแยกเรื่องนี้ให้ชัดในวิธีที่กำกับ AI ครั้งหน้าผมจะล็อกแบ็กเอนด์และกฎร่วมให้เสร็จก่อน แล้วค่อยต่อไคลเอนต์ทั้งสองฝั่ง
(01) Review
ถ้านักพัฒนาเป็นคนสร้าง
ขอบเขตฟีเจอร์ — iOS 24 โมดูลฟีเจอร์ อยู่บน TestFlight
การจับคู่บัญชีคู่รัก การจับคู่ตำแหน่ง ไทม์ไลน์ แผนที่ ไดอารี่ วันครบรอบ การซื้อในแอป โฆษณา วิดเจ็ต การกู้คืนบัญชี · TestFlight บิลด์ที่ 12
ความเร็วและต้นทุน — ~29K บรรทัด แอปเนทีฟ 2 ตัว ใน ~7 สัปดาห์
iOS (SwiftUI) และ Android (Compose) สร้างแยกกันบนแบ็กเอนด์เดียว พร้อม migration ฐานข้อมูล 14 ชุด
การรองรับหลายภาษา — 4 ภาษา คีย์ ~220 ชุดเดียวกันทั้งสองแพลตฟอร์ม
อังกฤษ เกาหลี ญี่ปุ่น ไทย เหมือนกันทั้ง iOS และ Android
สถาปัตยกรรม — แบ่งตามฟีเจอร์ ใช้แพตเทิร์นมาตรฐานของแต่ละแพลตฟอร์ม
โฟลเดอร์แยกตามฟีเจอร์ @Observable + view model 13 ตัว หน้าจอส่วนใหญ่ยาว 300–500 บรรทัด และมี helper ฝั่งแบ็กเอนด์ใช้ร่วมกัน
ความสะอาดของโค้ด — สะอาด
แทบไม่มี force-unwrap หรือการ cast ที่เสี่ยงแครช และไม่มีไฟล์ใดยาวเกิน 1,000 บรรทัด
ประสิทธิภาพ — ระบบตำแหน่งที่คำนึงถึงแบตเตอรี่
ตัวกรองการเคลื่อนที่ 100m บน iOS งานเบื้องหลังทุก 15 นาทีบน Android และ spatial index ในฐานข้อมูล
ความปลอดภัยพื้นฐาน — มีกฎการเข้าถึงทุกตาราง
กฎการเข้าถึงระดับแถว (row-level) ครบทั้ง 22 ตาราง (47 policy) และเก็บคีย์ไว้ฝั่งเซิร์ฟเวอร์
การทดสอบและระบบอัตโนมัติ — มีการทดสอบเฉพาะเอนจินจับคู่
มีการทดสอบแบ็กเอนด์ 8 ชุดสำหรับการจับคู่ ไม่มีสำหรับตัวแอป และไม่มี CI
วางแผน → ทดสอบ flow การจับคู่บัญชี การจับคู่ช่วงเวลา และการซื้อ พร้อม CI สำหรับทั้งสองแอป
การเปิดตัวและการดูแลระบบ — ฐานข้อมูลจริงไม่ตรงกับ repository
repo ของแบ็กเอนด์หยุดอัปเดตตั้งแต่ต้นเดือนพฤษภาคม ขณะที่ฐานข้อมูลจริงยังเปลี่ยนต่อเนื่อง
วางแผน → ดึง schema จริงออกมาเป็นไฟล์ migration คอมมิตเข้า repo และเลิกแก้ผ่านแดชบอร์ดอย่างเดียว
ความปลอดภัย — เสริมความแข็งแรงก่อนเปิดตัวบนสโตร์
จะเพิ่มการตรวจสอบการซื้อฝั่งเซิร์ฟเวอร์อีกชั้นก่อนเปิดตัวบนสโตร์ และจะแสดงข้อผิดพลาดออกมาแทนการกลบไว้
วางแผน → ตรวจสอบการซื้อฝั่งเซิร์ฟเวอร์ และรายงานข้อผิดพลาดอย่างเหมาะสม
ความสมบูรณ์ของ Android — Android ตามหลัง iOS
ผมทำ iOS เสร็จก่อน Android กำลังพัฒนาอยู่
วางแผน → ทำ Android ให้เท่า iOS โดยใช้รายการฟีเจอร์ของ iOS เป็นหลัก — ไม่ใช่คัดลอกโค้ด
การเข้าถึง (Accessibility) — มี label เฉพาะหน้าจอหลัก
label สำหรับโปรแกรมอ่านหน้าจอ 23 จุดบน iOS และราว 10 จุดบน Android
วางแผน → label และการปรับขนาดตัวอักษรจะเป็นรายการในเช็กลิสต์ก่อนเปิดตัว
โปรเจกต์ถัดไป →
AttenNFC
ดีไซน์ของนักวางแผน สร้างด้วย AI — ระบบลงเวลาทำงานด้วย NFC + GPS พร้อมคำนวณเงินเดือนอัตโนมัติ สำหรับธุรกิจขนาดเล็กในไทย