ลอง Vibe coding สร้างแอปทำอาหารขนาด 35,000 บรรทัด

 (recipeninja.ai)
18 คะแนน โดย GN⁺ 2025-04-03 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • แอปทำอาหารที่นักลงทุนซึ่งเคยเป็นผู้ก่อตั้งสตาร์ทอัปพัฒนาด้วยการทำงานแบบ Vibe coding ภายใน 20 ชั่วโมง
  • ฟีเจอร์หลักคือ ผู้ช่วยเสียง ที่สั่งงานได้โดยไม่ต้องใช้มือระหว่างทำอาหาร
  • แบ็กเอนด์ Rails 8 API + ฟรอนต์เอนด์ React + Realtime Voice API ของ OpenAI
  • ใช้ความสามารถ function calling ของ OpenAI เพื่อให้สำรวจภายในเว็บไซต์ได้แบบเรียลไทม์
  • ใช้ Claude Code และ Gemini 2.5 Pro เพื่อเสริมฟีเจอร์ที่ซับซ้อน
  • ขนาดโค้ดรวมประมาณ 35,000 บรรทัด
  • ผู้ใช้สามารถค้นหาสูตรอาหารหลากหลายแบบผ่านคำสั่งเสียงได้โดยไม่ต้องจับหน้าจอเอง
  • มอบอินเทอร์เฟซแบบสนทนาที่เป็นธรรมชาติ
  • แม้จะเริ่มจากโปรเจกต์งานอดิเรก แต่ผลลัพธ์ออกมาอยู่ในระดับสูง ทั้งด้านฟังก์ชันและประสบการณ์ผู้ใช้

สร้างแอปทำอาหารเสร็จด้วย Vibecoding

  • แอปทำอาหาร recipeninja.ai ที่เจ้าตัววางแผนและสร้างเองภายในเวลาเพียง 20 ชั่วโมง
  • ผู้เขียนเคยเป็นผู้ก่อตั้งสตาร์ทอัป ปัจจุบันเป็นนักลงทุนที่ Y Combinator และแทบไม่ได้ใช้ Ruby เลยตั้งแต่ปี 2015 จนกลายเป็น "นักพัฒนาที่ขึ้นสนิม"
  • เป็นคนชอบทำอาหาร และเก็บไอเดีย “แอปทำอาหารแบบแฮนด์ฟรี” ไว้มานาน
  • มองว่าเว็บไซต์สูตรอาหารเดิม ๆ เน้น SEO, แอปต่าง ๆ ก็มี UX ที่ล้าสมัย และแอปอย่าง Paprika ก็ยังให้ความรู้สึกเหมือนปี 2009

การเลือกเครื่องมือและเริ่มต้นโปรเจกต์

  • ช่วงแรกลองใช้ Lovable ทำแอปเกมคำศัพท์ แต่เจอข้อจำกัด
  • จากนั้นเปลี่ยนมาใช้ Windsurf เพื่อจัดสถาปัตยกรรมเป็นแบ็กเอนด์ Rails 8 API + ฟรอนต์เอนด์ React
  • ตั้งแต่ Homebrew, npm, การตั้งค่าเวอร์ชัน Ruby, SSH key ไปจนถึงการตั้งค่า Heroku ถูกทำให้อัตโนมัติ
  • แม้แต่ Rails migration ก็ถูกจัดการให้อัตโนมัติตามแนวทางมาตรฐาน

การพัฒนาฟังก์ชันพื้นฐาน

  • ป้อนคำง่าย ๆ อย่าง “Lasagne” ก็สร้างสูตรอาหารทั้งชุดได้
  • ใช้ OpenAI สร้างข้อความสูตรอาหาร และใช้ ElevenLabs สร้างเสียง
  • มีทั้งฟังก์ชันแนะนำด้วยเสียงทีละขั้นตอนและการแสดงภาพ
  • อีกจุดที่น่าประทับใจคือ Windsurf ตรวจจับความเสี่ยงด้านความปลอดภัยและเตือนอย่างเข้มงวดไม่ให้ API key หลุด

การขยายฟีเจอร์และวงจรพัฒนาแบบทำซ้ำ

  • ฟีเจอร์ “นำเข้าสูตรอาหารขั้นสูง” จากรูปภาพถูกทำเสร็จภายในไม่กี่นาที
  • แค่คัดลอกวาง console log หรือข้อความ error, Windsurf ก็แก้ให้โดยอัตโนมัติ
  • ตอนเชื่อม Google OAuth เพียงวางภาพหน้าจอการตั้งค่า ก็ช่วยจับจุดที่ตั้งค่าผิดได้ทันที
  • ฟีเจอร์อย่างการบันทึกสูตรอาหารรายผู้ใช้ และการตั้งค่า public/private ก็แทบถูกเพิ่มให้อัตโนมัติ

การดีพลอยและการตั้งค่า DNS

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

ประสบการณ์ใช้งาน Windsurf ในฐานะเครื่องมือ AI

  • บางฟีเจอร์ยังต้องทดสอบเองด้วยการยิง curl หรือดู web preview
  • Git commit และการดีพลอยไป Heroku ก็จัดการให้อัตโนมัติผ่านเทอร์มินัลที่ฝังมา
  • แต่ถ้าเป็นการเปลี่ยนแปลงขนาดใหญ่เกินไปหรือ commit โดยไม่ตรวจสอบ ก็ยังต้องมีผู้ใช้เข้ามาควบคุม
  • เช่นเมื่อขอเพิ่มระบบวิเคราะห์ข้อมูล กลับใส่ event มาเกิน 100 รายการแบบมากเกินจำเป็น

จุดที่น่าเสียดายและสิ่งที่ต้องปรับปรุง

  • ไม่มีระบบทดสอบอัตโนมัติ จึงต้องทดสอบเองทุกครั้งหลังเปลี่ยนโค้ด
  • ไม่มีฟีเจอร์ tail log ทำให้ต้องคัดลอก log มาใส่เองถึงจะตรวจจับปัญหาอย่าง N+1 query ได้
  • การรีแฟกเตอร์โค้ดซ้ำยังทำได้ไม่ดี — หากต้องการแยกโค้ดเป็นโมดูลโดยคงฟังก์ชันเดิมไว้ ต้องสั่งอย่างละเอียด
  • รูปแบบ API response เปลี่ยนบ่อยจนทำให้ฟรอนต์เอนด์พัง
  • การใส่ระบบวิเคราะห์ Posthog ล้มเหลว และยังมีปัญหาที่คำสั่งเสียงชนกับเสียงเดิม

การปรับประสิทธิภาพและลดต้นทุน

  • ปัญหารูปภาพความละเอียดสูง → สร้าง thumbnail และเวอร์ชันความละเอียดกลางให้อัตโนมัติ
  • แก้ปัญหา N+1 ให้อัตโนมัติ
  • ย้าย ElevenLabs API key ไปไว้ฝั่งแบ็กเอนด์และเพิ่มระบบแคชเสียงเพื่อลดค่าใช้จ่าย

ผลผลิตที่เพิ่มขึ้นอย่างก้าวกระโดด

  • ในแต่ละเซสชันสามารถลิสต์ไอเดียฟีเจอร์ได้ 10–15 อย่าง และทำเสร็จทั้งหมดภายใน 30 นาที
  • งานที่ปกติอาจใช้เวลาหลายชั่วโมง ถูกทำเสร็จได้ภายใน 1–2 นาที
  • แม้แต่การปรับดีไซน์ก็เพียงสั่งผ่านภาพหน้าจอ ก็ได้ UI ที่ดูสมบูรณ์และสวยงาม
  • อ้างอิงคารูเซลของแอป DoorDash แล้วสร้างดีไซน์คล้ายกันขึ้นมา — และยังมีคนมองว่าดูดีกว่าด้วยซ้ำ

งานเก็บรายละเอียดช่วงท้ายและประเด็นด้านความปลอดภัย

  • การตั้งค่า Favicon ก็ทำให้อัตโนมัติด้วย Bash script
  • หลังโพสต์ลง Twitter มีผู้ใช้หลายร้อยคนเข้าใช้งาน และมีการสร้างสูตรอาหารราว 1,000 รายการ
  • แต่ก็โดนผู้ใช้เชิง abuse ทำให้เกิดค่าใช้จ่าย OpenAI สูงถึง $700
  • Windsurf เสนอมาตรการป้องกันมา 15 วิธี และสามารถนำส่วนใหญ่ไปใช้พร้อมแก้ปัญหาได้ภายใน 10 นาที

แผนต่อไปและมุมมองทางเทคนิค

  • มีแผนเพิ่มฟีเจอร์ สร้างสูตรอาหารแบบสตรีมมิง บนพื้นฐาน WebSocket
    • เช่น สั่งว่า “เพิ่มถั่วให้หน่อย”, “เปลี่ยนเป็น 8 ที่”, “แปลงเป็นหน่วยเมตริก” แล้วให้ระบบสะท้อนผลแบบเรียลไทม์
  • ยังมีแผนสร้างอินเทอร์เฟซ voice agent เพื่อถามระหว่างทำอาหารได้โดยไม่ต้องแตะหน้าจอ
    • เช่น “ไม่มีผักชี มีวัตถุดิบอะไรใช้แทนได้บ้าง?”, “ตั้ง timer 30 นาทีให้หน่อย”
  • สำหรับผู้ใช้ที่มีพื้นฐานทางเทคนิค เครื่องมือ AI คือพลังพิเศษ
  • ขณะเดียวกันก็พัฒนาไปในทิศทางที่คนไม่ใช่นักพัฒนาก็ใช้ได้ เช่น log tailing, automated testing และการรวมระบบ version control
  • มีการมองว่าในอนาคตอันใกล้ เราอาจเข้าสู่ยุคที่ 95% ของการเขียนโค้ดเกิดจาก AI

สรุปฟีเจอร์หลักของ RecipeNinja

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

ฟีเจอร์ฝั่งแบ็กเอนด์ (อิง Rails API)

  • การยืนยันตัวตนและการจัดการสิทธิ์

    • รองรับการล็อกอินผ่าน Google OAuth
    • จัดการบัญชีผู้ใช้ด้วยความปลอดภัยที่เข้มขึ้น
    • ผู้ใช้เข้าถึงได้เฉพาะสูตรอาหาร private ของตนเอง และแชร์ให้ผู้อื่นได้เฉพาะสูตรที่เป็น public

  • ฟีเจอร์จัดการสูตรอาหาร

    • โครงสร้างโมเดลสูตรอาหาร
      • กำหนด public ID แบบไม่ซ้ำเพื่อความปลอดภัย (รูปแบบ: r_ + สตริงสุ่ม 14 หลัก)
      • ระบุความเป็นเจ้าของของผู้ใช้ให้ชัดเจน (user_id, มีข้อกำหนด NOT NULL)
      • สลับสถานะ public/private ของสูตรอาหารได้ (ค่าเริ่มต้น: private)
      • เก็บข้อมูลได้หลากหลาย เช่น ชื่อ, วัตถุดิบ, ขั้นตอนทำอาหาร, เวลาในการปรุง
      • รองรับการอัปโหลดรูปภาพด้วย Active Storage และ S3
    • ระบบแท็ก
      • ออกแบบความสัมพันธ์แบบ many-to-many (M:N) ระหว่างสูตรอาหารกับแท็ก
      • แท็กถูกแยกเป็นอีกโมเดลหนึ่งที่มีชื่อไม่ซ้ำ
      • ใช้โมเดลกลาง (RecipeTag) สำหรับเชื่อมสูตรอาหารกับแท็ก
      • มี helper method สำหรับเพิ่มและลบแท็ก
    • API endpoint ของสูตรอาหาร
      • รองรับงาน CRUD
      • รองรับ pagination พร้อม metadata (เช่น current_page, per_page)
      • การเรียงลำดับเริ่มต้นคือใหม่สุดก่อนตามวันสร้าง (created_at DESC)
      • รองรับการกรองตามแท็ก
      • แยก serializer ระหว่างรายการและรายละเอียด (RecipeSummarySerializer, RecipeSerializer)

  • ฟีเจอร์สร้างเสียง

    • ระบบบันทึกเสียง
      • สร้างคำแนะนำเสียงสำหรับแต่ละขั้นตอนของสูตรอาหาร
      • เชื่อมต่อ Eleven Labs API เพื่อแปลงข้อความเป็นเสียง
      • ไฟล์เสียงถูกแคชไว้บน S3 เพื่อลดค่า API เมื่อมีการเรียกซ้ำ
      • สร้างตัวระบุไม่ซ้ำโดยรวม recipe ID, step ID และ voice ID
      • รองรับการบังคับสร้างไฟล์เสียงใหม่
    • การประมวลผลเสียง
      • ใช้ gem streamio-ffmpeg เพื่อวิเคราะห์ไฟล์เสียง
      • จัดการไฟล์เสียงด้วย Active Storage
      • ในสภาพแวดล้อมโปรดักชัน ใช้วิธีจัดเก็บผ่าน S3

  • การนำเข้าและสร้างสูตรอาหาร

    • บริการ RecipeImporter
      • เชื่อมต่อ OpenAI เพื่อสร้างสูตรอาหารอัตโนมัติ
      • แปลงข้อความสูตรอาหารให้เป็นโครงสร้างข้อมูล
      • ทำ normalization และ parsing ของวัตถุดิบกับขั้นตอน
      • มีฟีเจอร์นำเข้าสูตรอาหารจากรูปภาพ

ฟีเจอร์ฝั่งฟรอนต์เอนด์ (อิง React)

  • องค์ประกอบของส่วนติดต่อผู้ใช้

    • การเลือกและสำรวจสูตรอาหาร
      • ดูรายการสูตรอาหารแบบแบ่งหน้า
      • อัปเดตแบบเรียลไทม์ทุก 10 วินาที
      • รองรับการกรองตามแท็ก
      • มีการ์ดสูตรอาหารที่แสดงข้อมูลสรุปโดยไม่ต้องมีรูปภาพ
      • แต่ละสูตรมีปุ่ม “ดูรายละเอียด” และ “เริ่มทำอาหาร”

  • หน้ารายละเอียดสูตรอาหาร

    • แสดงข้อมูลสูตรอาหารทั้งหมด
    • แสดงรูปภาพของสูตรอาหาร
    • มีรายการแท็กที่กดได้
    • เริ่มทำอาหารจากหน้านี้ได้ทันที

  • อินเทอร์เฟซระหว่างทำอาหาร

    • มีคู่มือทำอาหารทีละขั้นตอน
    • รองรับคำแนะนำด้วยเสียงในแต่ละขั้นตอน
    • รองรับคีย์ลัดสำหรับการใช้งานแบบแฮนด์ฟรี:
      • ปุ่มลูกศร (←/→): เปลี่ยนขั้นตอน
      • ปุ่ม Space: เล่น/หยุดเสียงชั่วคราว
      • ปุ่ม ESC: กลับไปยังรายการสูตรอาหาร
    • ติดตามขั้นตอนผ่าน URL path ได้ (เช่น /recipe/r_xlxG4bcTLs9jbM/classic-lasagna/steps/1)

การจัดการสถานะและการไหลของข้อมูล

  • Recipe Service

    • ดึงข้อมูลสูตรอาหารผ่าน API
    • รองรับพารามิเตอร์ pagination
    • รองรับการกรองตามแท็ก
    • ใช้กลไกแคชข้อมูลสูตรอาหาร
    • มีฟังก์ชันจัดการ image URL สำหรับหน้า detail

  • ขั้นตอนการยืนยันตัวตน

    • เชื่อม Google OAuth ด้วย environment variables
    • จัดการ user session
    • จัดการ authentication header ให้อัตโนมัติเมื่อเรียก API

ฟีเจอร์ PWA (Progressive Web App)

  • ให้บริการในรูปแบบ PWA ที่ติดตั้งได้บนอุปกรณ์หลากหลาย
  • ใช้ดีไซน์ responsive รองรับทุกขนาดหน้าจอ
  • รองรับ Favicon และ app icon

สถาปัตยกรรมการดีพลอย

  • โครงสร้างแบบสองแอป

    • cook-voice-api: Rails backend ที่ดีพลอยบน Heroku
    • cook-voice-wizard: React frontend และ PWA ที่ดีพลอยบน Heroku

  • โครงสร้างพื้นฐานฝั่งแบ็กเอนด์

    • ใช้ Ruby เวอร์ชัน 3.2.2
    • ใช้ฐานข้อมูลผ่าน Heroku PostgreSQL add-on
    • ใช้ Amazon S3 สำหรับจัดเก็บไฟล์
    • จัดการการตั้งค่าด้วย environment variables

  • โครงสร้างพื้นฐานฝั่งฟรอนต์เอนด์

    • แอปพลิเคชันที่พัฒนาด้วย React
    • จัดการข้อมูลอ่อนไหวอย่าง API key ผ่านการตั้งค่า environment variables
    • ใช้ static buildpack ของ Heroku
    • ใช้การ routing แบบ SPA (Single Page Application)

  • มาตรการด้านความปลอดภัย

    • บังคับใช้ HTTPS
    • ใช้ระบบ Rails Credentials
    • แยกข้อมูลอ่อนไหวออกไปไว้ใน environment variables
    • ใช้ Public ID แทน DB ID เพื่อปกป้องโครงสร้างภายใน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-04-03
ความเห็นจาก Hacker News

  • น่าประทับใจมาก 35 kLOC ถือว่าเยอะพอสมควร อยากรู้ว่าแอปนี้ใช้งานได้เข้าใจง่ายและดูแลรักษาง่ายแค่ไหน คงต้องไปดูซอร์ส โค้ด Rails ที่ดีมักกระชับ แต่ฝั่งฟรอนต์เอนด์อาจใหญ่โตมากได้

    • ความเห็นที่ว่าถ้ามี automated tests และ native version control ก็จะทำได้ภายในไม่กี่เดือนนั้นค่อนข้างมองโลกในแง่ดีไปหน่อย แต่สุดท้ายก็น่าจะทำได้ทั้งหมด
    • สำหรับความเห็นที่ว่านี่เป็นเครื่องมือทรงพลังที่ช่วยให้คนที่ไม่ใช่สายเทคนิคเขียนแอประดับ production quality ได้ มองว่าคนที่ไม่ใช่สายเทคนิคไม่มีเหตุผลต้องมาคิดเรื่องการ tail logs หรือ version control AI ต้องไม่ใช่แค่โค้ดเดอร์ที่เก่ง แต่ต้องเป็นสถาปนิกที่เก่งและ senior SWE ที่สามารถแปลภาษาของการจัดการผลิตภัณฑ์ให้เป็นภาษาของการพัฒนาซอฟต์แวร์ได้ด้วย ซึ่งนี่จะเป็นความท้าทายใหญ่หากต้องการให้มีความน่าเชื่อถือใกล้เคียงกับทีมมนุษย์

  • มีความเห็นว่าลองทำสูตร Diarrhea Walnuts แต่ตัวเองแพ้วอลนัตเลยเกิดปัญหา จะดำเนินคดีแน่นอน

  • มีความเห็นว่า Claude Code มีประโยชน์ แต่คิดว่า o1 Pro เก่งเรื่องดีบักมากกว่า

    • Claude Code แก้ปัญหาได้เมื่อเวลาผ่านไป แต่สุดท้ายกลับใช้ o1 Pro บ่อยกว่า
    • เมื่อเทียบ o1 Pro กับ Claude Code แล้ว o1 Pro แก้ปัญหาได้เร็วกว่า แต่ก็ commit การเปลี่ยนแปลงจาก Claude Code ไปแล้ว และใช้ฟีดแบ็กจาก o1 แก้ปัญหาที่ Claude มองไม่เห็น

  • มีความเห็นว่าดูเหมือน Jian Yang กับ Big Head กำลังสร้างแอปใหม่กันอยู่

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

    • เคยได้รับคำขอให้ทำงานชิ้นหนึ่ง แต่ปรากฏว่าวิศวกรอีกคนเขียนโค้ดส่วนใหญ่ไว้แล้ว เลยทำเสร็จได้ภายในวันเดียว
    • เห็นด้วยกับการทดลองขนาดใหญ่แบบนี้และรู้สึกขอบคุณ อยากรู้ว่าระบบอย่าง Cursor จะจัดการอย่างไรเมื่อมีโค้ดจำนวนมากที่แทบไม่ได้ถูกใช้งาน สงสัยว่าถ้ามี 3k LOC ที่ซ้ำกันโดยไม่ตั้งใจ ระบบอัตโนมัติจะเข้าใจและแก้ไขมันได้หรือไม่

  • สำหรับการตอบกลับด้วยเสียงโดยใช้ Realtime API ของ OpenAI มีความกังวลว่าถ้าแอปได้รับความนิยมขึ้นมา อาจล้มละลายเพราะปัญหาต้นทุน มีแผนจะใช้ OpenAI audio API ในกรณีอื่นด้วย เลยอยากรู้ว่ามีกลยุทธ์เรื่องนี้อย่างไร

  • มีคำถามว่าสามารถสร้าง 'vibecode' ที่บอกได้จากเว็บไซต์ว่าจะหาวัตถุดิบจากที่ไหนได้หรือไม่ เพราะวัตถุดิบบางอย่างหายาก

  • มีความเห็นว่าสูตรอาหารดูสนุกดี แต่พอรู้ว่า AI เป็นคนสร้าง ความสร้างสรรค์นั้นก็หายไป ชอบ Comprehensive JavaScript Tutorial มากที่สุด

  • มีคำถามว่าฟีเจอร์หลักคือการควบคุมด้วยเสียงหรือไม่ และเมื่อเทียบกับเว็บไซต์สูตรอาหารยอดนิยมอื่น ๆ แล้ว เหตุผลที่จะเลือกแอปนี้คืออะไร สงสัยว่านี่เป็นเพียงแบบฝึกหัดสำหรับการทดสอบด้านวิศวกรรม/AI เป็นหลักหรือไม่

  • มีความเห็นว่าควรเพิ่ม NSFW ลงในชื่อเรื่อง เพราะหน้าแรกมีสูตรอาหาร NSFW มากกว่า 50%