Solutions Choose your path
For individuals Build, learn, and create with simple usage-based access. For business Scale teams, billing, governance, and model workflows. More English 繁體中文 日本語 한국어 Français Deutsch Español Italiano Português Русский العربية ไทย Tiếng Việt Bahasa Indonesia Bahasa Melayu Türkçe Polski Nederlands Danish Norsk Қазақ اردو
เริ่มต้นฟรี เริ่มต้นฟรี
500+ AI Model API, All In One API.
Just In CometAPI © 2026 CometAPI · All rights reserved
Home Blog สร้างผู้ช่วย AI ด้วย Lovable และ CometAPI guide / งานวิจัย CometAPI
สร้างผู้ช่วย AI ด้วย Lovable และ CometAPI เรียนรู้ว่า Lovable สร้างเว็บแอปอย่างไร สำรวจฟีเจอร์หลักของ Lovable และเชื่อมต่อ CometAPI ผ่านแบ็กเอนด์ที่ปลอดภัย ด้วยบทช่วยสอนเชิงปฏิบัติสำหรับผู้ช่วยเขียน
Deon Goodwin ทีมวิจัยโมเดล AI และ API เรียนรู้ว่า Lovable สร้างเว็บแอปอย่างไร สำรวจฟีเจอร์หลักของ Lovable และเชื่อมต่อ CometAPI ผ่านแบ็กเอนด์ที่ปลอดภัย ด้วยบทช่วยสอนเชิงปฏิบัติสำหรับผู้ช่วยเขียน
ใช้สรุปนี้เพื่อดูคำตอบอย่างรวดเร็ว แล้วอ่านคู่มือเพื่อดูบริบท ตัวอย่าง และรายละเอียดการใช้งาน
from openai import OpenAI
client = OpenAI(
api_key="YOUR_COMETAPI_KEY",
base_url="https://api.cometapi.com/v1",
)
response = client.chat.completions.create(
model="gpt-5-mini",
messages=[{"role": "user", "content": "Build this workflow."}],
)
print(response.choices[0].message.content)TL;DR
Lovable คือแพลตฟอร์มพัฒนาที่ขับเคลื่อนด้วย AI ซึ่งแปลงคำสั่งภาษาธรรมชาติให้เป็นโค้ดแอปเว็บที่แก้ไขได้ ช่วยผู้ก่อตั้ง นักออกแบบ ทีมผลิตภัณฑ์ และนักพัฒนา สร้างอินเทอร์เฟซ เชื่อมต่อบริการแบ็กเอนด์ และเผยแพร่แอปพลิเคชันผ่านการสนทนาแบบวนซ้ำ คู่มือนี้อธิบายความสามารถ สถาปัตยกรรมโปรเจ็กต์ และตัวอย่างการผสาน CometAPI สำหรับผู้ช่วยการเขียน การผสานนี้เพิ่มการทำอนุมานโมเดลให้กับแอปที่คุณสร้าง ไม่ใช่วิธีการแทนที่เอเจนต์เขียนโค้ดของ Lovable เอง ผู้อ่านควรเข้าใจพื้นฐานคำขอ HTTP และ JavaScript และสามารถเข้าถึงโปรเจ็กต์ Lovable และบัญชี CometAPI ก่อนทำตามขั้นตอนการใช้งาน
Key Takeaways
การพัฒนาด้วย AI: สร้างและปรับแต่งแอปด้วยพรอมป์ต์ภาษาธรรมชาติ
ความสามารถแบบฟูลสแต็ก: สร้างส่วนหน้าและฟังก์ชันแบ็กเอนด์ ฐานข้อมูล การยืนยันตัวตน และโฮสติ้ง
สถาปัตยกรรมสมัยใหม่: โปรเจ็กต์ Lovable ใหม่ใช้ TanStack Start บน React และ SSR ตั้งแต่พฤษภาคม 2026
ความเข้ากันได้กับ CometAPI: เพิ่มการอนุมานโมเดลผ่านฟังก์ชันแบ็กเอนด์ที่ปลอดภัย
เรียนรู้ต่อ
เชื่อมโยงบทความนี้กับการตัดสินใจถัดไป ดูทุกหัวข้อ เผยแพร่เมื่อ Oct 30, 2026 ตรวจสอบความชัดเจน การอ้างอิงแหล่งที่มา และคำศัพท์ API ปัจจุบันแล้ว
กรณีใช้งานที่เหมาะ: MVP ผู้ช่วย AI เครื่องมือภายใน แอปคอนเทนต์ และพอร์ทัลลูกค้า
What Is Lovable and How Does It Work? Lovable (lovable.dev) คือแพลตฟอร์มที่ขับเคลื่อนด้วย AI สำหรับสร้างแอปเว็บแบบฟูลสแต็กระดับโปรดักชันด้วยภาษาธรรมชาติ เว็บไซต์ทางการ และ ภาพรวมผลิตภัณฑ์ เป็นจุดเริ่มต้นในการสำรวจแพลตฟอร์มนี้
คุณบรรยายสิ่งที่ต้องการในอินเทอร์เฟซแชต และแพลตฟอร์มจะสร้างแอปที่ใช้งานได้จริง โดยมี:
ส่วนหน้า (มักใช้ React, TypeScript, Tailwind CSS)
แบ็กเอนด์ ฐานข้อมูล การยืนยันตัวตน และที่เก็บข้อมูล (ผ่าน Lovable Cloud ที่จัดการโดย Supabase)
การผสานระบบ การดีพลอย และโค้ดที่แก้ไขได้ซึ่งเป็นของคุณเอง
รองรับวงจรชีวิตผลิตภัณฑ์ครบถ้วน ตั้งแต่สร้างต้นแบบจนถึงดีพลอย และสามารถซิงก์โค้ดไปยัง GitHub, GitLab หรือ Bitbucket มุ่งเป้าไปที่ผู้ก่อตั้ง ผู้จัดการผลิตภัณฑ์ ผู้ไม่มีพื้นฐานการพัฒนา และทีมงานที่ต้องการเดินหน้าอย่างรวดเร็วพร้อมคงความเป็นเจ้าของโค้ด โครงการนี้มีต้นกำเนิดจากโครงการโอเพนซอร์ส GPT Engineer (ก่อตั้งที่สตอกโฮล์มในปี 2023 โดย Anton Osika และ Fabian Hedin) และถูกรีแบรนด์/พาณิชย์เป็น Lovable
How Lovable Turns Prompts Into Applications
อธิบายผู้ใช้งานของแอป หน้า ฟีเจอร์ และกฎทางธุรกิจ
สร้างแอปเวอร์ชันแรกและตรวจสอบพรีวิว
เชื่อมต่อฐานข้อมูล ระบบลงชื่อเข้าใช้ การชำระเงิน หรือ API ภายนอก
ทดสอบพฤติกรรมและปรับแต่งโค้ด ดีไซน์ และเวิร์กโฟลว์
เผยแพร่หรือดูแลต่อเนื่องด้วยโค้ดแอปที่สามารถเอ็กซ์พอร์ตได้
บทความวิศวกรรมของ Lovable วันที่ 1 มิถุนายน 2026 (https://lovable.dev/blog/building-apps-using-tanstack-start ) อธิบายการย้ายไปใช้ TanStack Start บน React และการเรนเดอร์ฝั่งเซิร์ฟเวอร์สำหรับโปรเจ็กต์ใหม่ตั้งแต่ 13 พฤษภาคม 2026 โปรเจ็กต์ที่มีอยู่เดิมซึ่งใช้ React + Vite จะคงสถาปัตยกรรมเดิมไว้ โปรดตรวจสอบโปรเจ็กต์จริงก่อนเลือกใช้ server function หรือ Edge Function
Lovable Technical Specifications Category ตัวสร้างแอปเว็บที่ขับเคลื่อนด้วย AI Primary interaction การพิมพ์พรอมป์ต์ภาษาธรรมชาติ Framework for new projects React และ TanStack Start Rendering การเรนเดอร์ฝั่งเซิร์ฟเวอร์สำหรับโปรเจ็กต์ใหม่ Earlier architecture React + Vite Backend Lovable Cloud และการผสานที่รองรับ Authentication and database รองรับ External APIs คอนเนคเตอร์และคำขอ API แบบกำหนดเอง AI integration Lovable AI และ API โมเดลภายนอก Code access โค้ดที่สร้างและเวิร์กโฟลว์ GitHub Collaboration ฟีเจอร์ workspace และโปรเจ็กต์ Deployment ตัวเลือกในตัวและตัวเลือกภายนอกที่รองรับ
Lovable คือแพลตฟอร์มพัฒนาแอป ไม่ใช่ foundation model ดังนั้นพารามิเตอร์ ขนาดหน้าต่างบริบท อัตราการไหลของโทเคน และคะแนน MMLU ไม่ได้อธิบาย Lovable เอง สิ่งเหล่านี้เป็นของโมเดล AI ที่ใช้ในการพัฒนาหรือการอนุมานโดยเฉพาะ
ได้—ภายในแอปพลิเคชันที่สร้างด้วย Lovable CometAPI สามารถจัดการคำขอโมเดลจากฟังก์ชันแบ็กเอนด์ที่ได้รับการป้องกัน ซึ่งแตกต่างจากการเปลี่ยน LLM ที่ใช้ขับเคลื่อนเอเจนต์เขียนโค้ดของ Lovable เอง
คุณสามารถผสาน CometAPI เข้ากับแอปที่สร้างด้วย Lovable ได้ โดยขึ้นกับโมเดลและอินเทอร์เฟซที่รองรับ
สิ่งนี้ไม่ได้หมายความว่าคุณสามารถแทนที่โมเดลพร็อกซีสำหรับการพัฒนา ซึ่งถูกใช้งานโดย Lovable เอง ได้โดยตรง
หากเป้าหมายคือควบคุมว่าแอปของคุณเรียกโมเดลใด ควรกำหนดเส้นทางโมเดลภายในโค้ดฝั่งเซิร์ฟเวอร์ของคุณเอง
ฟีเจอร์ AI ในแอปที่สร้าง Yes คำขอ API ฝั่งเซิร์ฟเวอร์ที่ได้รับการป้องกัน แชตบอทหรือผู้ช่วยการเขียน Yes เรียก CometAPI chat models ที่รองรับ แอปหลายโมเดล Yes กำหนดค่า model ID ในการกำหนดเส้นทางแบ็กเอนด์ แทนที่โมเดลเขียนโค้ดภายในของ Lovable Not established as a standard setting การเลือกโมเดลของเอเจนต์ภายในเป็นอีกส่วนหนึ่ง บริการแบ็กเอนด์ผ่าน CometAPI Yes ผสานผ่าน HTTP แบบกำหนดเองหรือ server function Lovable workspace management API Separate ควบคุมทรัพยากรแพลตฟอร์ม ไม่ใช่การอนุมานโมเดล
คำอธิบายของ Lovable เกี่ยวกับการจัดออร์เชสตราโมเดลภายใน (https://lovable.dev/blog/the-model-picker-is-a-dead-end ) บอกถึงการจัดเส้นทางงานของเอเจนต์พัฒนา การผสาน CometAPI ด้านล่างนี้เกี่ยวข้องกับการอนุมานในแอป ไม่ได้อ้างว่ามีการตั้งค่า CometAPI ที่เป็นทางการสำหรับเอเจนต์ภายในนั้น
Lovable รองรับสิ่งนี้ในสองวิธีหลักสำหรับแอปที่คุณสร้าง:
Secrets (แนะนำสำหรับการใช้โดยตรง)
จัดเก็บคีย์ CometAPI ของคุณเป็นโปรเจ็กต์ซีเคร็ต (เช่น COMETAPI_KEY หรือ OPENAI_API_KEY) ขอให้ Lovable ในแชตของโปรเจ็กต์ผสาน API ผ่าน Edge Function ที่ปลอดภัย คีย์จะอยู่ฝั่งเซิร์ฟเวอร์และไม่ถูกเปิดเผยในเบราว์เซอร์
Custom connector
สร้างคอนเนคเตอร์แบบกำหนดเองในแคตตาล็อก Connectors ของ workspace กำหนดค่า base URL (https://api.cometapi.com/v1) การยืนยันตัวตน (โทเคน Bearer หรือเฮดเดอร์แบบกำหนดเอง) จากนั้นเพิ่มการเชื่อมต่อด้วยการวางคีย์ CometAPI ของคุณ คำขอจะผ่านเกตเวย์คอนเนคเตอร์ของ Lovable ทำให้ข้อมูลรับรองถูกเข้ารหัสและไม่อยู่ในโค้ดของคุณ
ฟีเจอร์ AI ในตัวของ Lovable สำหรับแอปใช้คีย์ที่ Lovable จัดการเองและหักเครดิตของ workspace คุณไม่สามารถสลับสิ่งเหล่านี้เป็นคีย์ CometAPI (หรือผู้ให้บริการอื่น)
สำหรับการเรียก AI ภายนอกภายในแอปของคุณเอง (เช่น แชตบอท การสร้างคอนเทนต์ ฯลฯ) วิธี secrets หรือ custom connector ใช้งานได้ และจะคิดค่าการใช้งานไปที่บัญชี CometAPI ของคุณแทนเครดิต Lovable
ณ เอกสารล่าสุดยังไม่มีหลักฐานว่ามีการรองรับ CometAPI แบบเนทีฟ/สำเร็จรูปในแคตตาล็อกคอนเนคเตอร์ของ Lovable; คุณจะต้องตั้งค่าเป็น OpenAI-compatible หรือการผสาน API แบบกำหนดเอง
โดยสรุป: Lovable เป็นตัวสร้างแอปจากพรอมป์ต์สู่ฟูลสแต็กที่แข็งแรง และใช่—คุณสามารถกำหนดค่าและใช้คีย์ CometAPI อย่างปลอดภัยสำหรับฟีเจอร์ AI ภายในแอปที่คุณสร้างด้วยมัน
เบราว์เซอร์ส่งอินพุตไปยังแบ็กเอนด์ของแอป แบ็กเอนด์อ่านซีเคร็ต เรียก CometAPI และส่งผลลัพธ์กลับมา อย่าวางคีย์ API ส่วนตัวไว้ในคอมโพเนนต์ React หรือโค้ดฝั่งไคลเอนต์อื่นใด
ตัวอย่างต่อไปนี้สร้าง SmartWrite ผู้ช่วยการเขียน AI ที่มีช่องกรอกข้อความ การเลือกโทน และคำขอ CometAPI ฝั่งเซิร์ฟเวอร์ เลือกแพตเทิร์น boundary ของ TanStack สำหรับโปรเจ็กต์ใหม่ หรือจุดเข้า Supabase Edge Function แบบสมบูรณ์สำหรับโปรเจ็กต์เก่า เลือกหนึ่งการติดตั้งแบ็กเอนด์ที่ตรงกับโปรเจ็กต์ของคุณ กำหนดค่า secrets และยืนยันโมเดลแชตที่รองรับในบัญชี CometAPI ของคุณ ก่อนเผยแพร่ ให้ทดสอบตัวอย่างด้วยซีเคร็ตโปรเจ็กต์ของคุณเองและโมเดลแชตที่พร้อมใช้งานในบัญชีของคุณ
Step 1: Create a Lovable Project Build a responsive AI writing assistant named SmartWrite.
Include a dashboard, a large prompt box, a tone selector
(Professional / Friendly / Concise), a Generate button,
and an output panel with Copy and Clear controls.
Use a clean responsive design with loading states and errors.
Implement AI generation only through a secure server function.
Never expose API credentials to the frontend.
Do not ship mock AI responses.
สร้างคีย์ในบัญชี CometAPI ของคุณและตรวจสอบ ID โมเดลแชตที่บัญชีของคุณสามารถใช้ได้ บทช่วยสอนนี้ใช้การผสานฝั่งแบ็กเอนด์โดยตรง โดยกำหนด COMETAPI_API_KEY และ COMETAPI_MODEL เป็นการกำหนดค่าฝั่งเซิร์ฟเวอร์ ทำตามกลไกเข้าถึงซีเคร็ตที่รองรับโดยแบ็กเอนด์ในโปรเจ็กต์ที่ถูกสร้างของคุณ
เพื่อเชื่อมต่อ CometAPI อย่างปลอดภัย ให้ขอให้ Lovable สร้างการผสานฝั่งเซิร์ฟเวอร์และขอคีย์ API ผ่านฟอร์มซีเคร็ตที่ปลอดภัย คุณยังสามารถจัดการซีเคร็ตของโปรเจ็กต์ได้ภายใต้ More → Settings → Secrets สำหรับแบ็กเอนด์ภายนอกที่เป็น Supabase ให้กำหนดซีเคร็ตใน Supabase แทน ดู คู่มือ Secrets ของ Lovable
ทำตามข้อกำหนดสี่ข้อดังนี้:
จัดเก็บและอ่านคีย์ API เฉพาะบนเซิร์ฟเวอร์ เพิ่ม COMETAPI_API_KEY ผ่านอินเทอร์เฟซ Secrets ที่ปลอดภัยของโปรเจ็กต์ อ่านเฉพาะจากซีเคร็ตฝั่งเซิร์ฟเวอร์หรือ runtime bindings อย่าใส่คีย์ไว้ในโค้ดฝั่งหน้าบ้าน ตัวแปรสภาพแวดล้อมที่เข้าถึงจากเบราว์เซอร์ ข้อความแชต หรือสกรีนช็อต
แยกการกำหนดค่า API ออกจากคำขอของฝั่งหน้าบ้าน กำหนด COMETAPI_MODEL บนเซิร์ฟเวอร์ด้วย ID โมเดลจาก CometAPI ที่ยืนยันแล้ว ฝั่งหน้าบ้านควรส่งเพียง prompt และ tone ตรวจสอบคำขอให้ตรงกับฟิลด์ที่อนุญาตและปฏิเสธพร็อพเพอร์ตี้ที่ไม่คาดหมาย รวมถึง config, apiKey และ model อย่าให้ไคลเอนต์ส่งคีย์ API แบบ任意หรือเขียนทับการกำหนดค่าของโมเดลที่ป้องกันไว้ได้
ใช้วิธีเข้าถึงซีเคร็ตที่ถูกต้องสำหรับ runtime การติดตั้งต้องตรงกับสภาพแวดล้อมแบ็กเอนด์ของโปรเจ็กต์ที่ใช้งาน การดีพลอยแบบ Worker ใช้ injected bindings ในขณะที่ Supabase Edge Functions สามารถเข้าถึงซีเคร็ตผ่าน Deno.env อย่าคิดว่า process.env, Deno.env และ Worker bindings สามารถใช้แทนกันได้ ตรวจสอบวิธีการ inject ซีเคร็ตก่อนติดตั้งตัวจัดการ API
ยืนยันการปกป้องซีเคร็ตหลังการเผยแพร่ ตรวจสอบบันเดิล JavaScript โปรดักชัน แผง Network ใน DevTools ของเบราว์เซอร์ และล็อกของแอป ยืนยันว่าคีย์ API ไม่ปรากฏในแอสเซ็ตฝั่งไคลเอนต์ เพย์โหลดคำขอ การตอบกลับ URL หรือบันทึก นอกจากนี้ยืนยันว่าคำขอ CometAPI ถูกดำเนินการบนเซิร์ฟเวอร์ และการเขียนทับการกำหนดค่าโดยไม่ได้รับอนุญาตถูกปฏิเสธ
การบันทึกซีเคร็ตไม่ได้แปลว่าอินทิเกรชันปลอดภัยหรือใช้งานได้โดยอัตโนมัติ อินทิเกรชันจะพร้อมก็ต่อเมื่อการเรียก API ฝั่งเซิร์ฟเวอร์ทำงานจริง คำขอจากฝั่งไคลเอนต์ไม่สามารถเขียนทับการตั้งค่าที่ป้องกันไว้ และการตรวจสอบในโปรดักชันยืนยันว่าข้อมูลรับรองยังคงเป็นความลับ
ใช้แผนภาพสถาปัตยกรรมต่อไปนี้เพื่อระบุขอบเขตระหว่างฝั่งหน้าบ้านและแบ็กเอนด์ และตำแหน่งของข้อมูลรับรองที่ได้รับการป้องกัน แผนภาพนี้เป็นแนวคิด ไม่ใช่ภาพหน้าจอของอินเทอร์เฟซการตั้งค่า Lovable
Prompt to give Lovable เชื่อมต่อ SmartWrite กับ CometAPI โดยตรงผ่านฟังก์ชันแบ็กเอนด์ที่ยืนยันตัวตน ขอ COMETAPI_API_KEY จากฉันในฟอร์มซีเคร็ตที่ปลอดภัยและใช้ COMETAPI_MODEL สำหรับ ID โมเดลที่ฉันให้ ส่งคำขอ POST ไปที่ https://api.cometapi.com/v1/chat/completions เฉพาะจากฝั่งเซิร์ฟเวอร์ รับ prompt และ tone ตรวจสอบความถูกต้อง บังคับใช้ลิมิตต่อผู้ใช้ และส่งคืนเฉพาะข้อความที่สร้างไปยังฝั่งหน้าบ้าน ใช้ runtime แบ็กเอนด์ที่มีอยู่ในโปรเจ็กต์นี้ ห้ามใส่ข้อมูลรับรองลงในแชต โค้ดฝั่งหน้าบ้าน หรือคำขอจากเบราว์เซอร์ ห้ามสร้างผลลัพธ์สำเร็จแบบปลอม อธิบายวิธีทดสอบอินทิเกรชันและแสดงข้อผิดพลาดที่ sanitized เมื่อเกิดความล้มเหลว
Lovable ยังรองรับ custom connectors ที่มีการจัดการอยู่แล้ว คำแนะนำที่นี่ตั้งใจใช้เส้นทางการผสานโดยตรงตามที่ระบุใน คู่มือการผสาน API เพื่อให้สอดคล้องกับตัวช่วยฝั่งเซิร์ฟเวอร์ด้านล่าง
จากเทอร์มินัล Bash ที่เชื่อถือได้ ตั้งค่า COMETAPI_API_KEY และ COMETAPI_MODEL ในเครื่อง จากนั้นทดสอบ POST https://api.cometapi.com/v1/chat/completions. คู่มือคำขออย่างเป็นทางการของ CometAPI อธิบาย base URL การยืนยันตัวตนแบบ Bearer และรูปแบบการตอบกลับแชต เลือกโมเดลที่รองรับเอ็นด์พอยต์นี้ ความเข้ากันได้ไม่ได้การันตีทุกฟีเจอร์หรือพารามิเตอร์ของผู้ให้บริการ
# Set COMETAPI_API_KEY securely in this terminal before running.
# Replace the model value with a chat model verified in your account.
export COMETAPI_MODEL="YOUR_VERIFIED_CHAT_MODEL_ID"
: "${COMETAPI_API_KEY:?Set COMETAPI_API_KEY first}"
curl --fail-with-body --max-time 45 \
https://api.cometapi.com/v1/chat/completions \
-H "Authorization: Bearer $COMETAPI_API_KEY" \
-H "Content-Type: application/json" \
--data "$(printf '{"model":"%s","messages":[{"role":"user","content":"Write a customer welcome email."}],"stream":false}' "$COMETAPI_MODEL")"
จุดตรวจ: การตอบกลับที่สำเร็จจะมี choices[0].message.content หากการยืนยันตัวตนล้มเหลือหรือโมเดลไม่พร้อมใช้งาน ให้แก้ไขให้ถูกต้องก่อนเชื่อมต่ออินเทอร์เฟซผู้ใช้ อย่าวางข้อมูลรับรองเต็มรูปแบบหรือพรอมป์ต์ส่วนตัวลงในภาพหน้าจอสำหรับการวินิจฉัย
Lovable รองรับสถาปัตยกรรมแบ็กเอนด์สองแบบ:
โปรเจ็กต์ใหม่ (TanStack Start): ใช้ createServerFn เพื่อจัดการคำขอ API บนเซิร์ฟเวอร์
โปรเจ็กต์ React + Vite รุ่นเก่า: ใช้ Supabase Edge Functions สำหรับคำขอ API ฝั่งเซิร์ฟเวอร์
เลือกการติดตั้งที่ตรงกับสถาปัตยกรรมโปรเจ็กต์ของคุณ
Option A: TanStack Start (New Projects)
สร้าง src/server/writing.functions.ts:
import { createServerFn } from "@tanstack/react-start";
export const generateWriting = createServerFn({ method: "POST" })
.handler(async ({ data }: { data: { prompt: string } }) => {
const { env } = await import("cloudflare:workers");
const res = await fetch(
"https://api.cometapi.com/v1/chat/completions",
{
method: "POST",
headers: {
Authorization: `Bearer ${env.COMETAPI_API_KEY}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
model: env.COMETAPI_MODEL,
messages: [{ role: "user", content: data.prompt }],
}),
}
);
if (!res.ok) throw new Error("Generation failed.");
const result = await res.json();
return { text: result.choices[0].message.content };
});
จัดเก็บ COMETAPI_API_KEY และ COMETAPI_MODEL เป็น Worker bindings ฝั่งเซิร์ฟเวอร์ หากการดีพลอยของคุณใช้ตัวแปลงอื่น ให้ใช้กลไกเข้าถึงซีเคร็ตที่รองรับของตัวนั้น
Option B: React + Vite (Older Projects)
สร้าง supabase/functions/generate-writing/index.ts:
import { serve } from "https://deno.land/std@0.224.0/http/server.ts";
serve(async (req) => {
try {
const { prompt } = await req.json();
if (typeof prompt !== "string" || !prompt.trim()) {
return Response.json({ error: "Invalid prompt" }, { status: 400 });
}
const res = await fetch(
"https://api.cometapi.com/v1/chat/completions",
{
method: "POST",
headers: {
Authorization: `Bearer ${Deno.env.get("COMETAPI_API_KEY")}`,
"Content-Type": "application/json",
},
body: JSON.stringify({
model: Deno.env.get("COMETAPI_MODEL"),
messages: [{ role: "user", content: prompt }],
}),
}
);
if (!res.ok) throw new Error("CometAPI request failed.");
const result = await res.json();
return Response.json({ text: result.choices[0].message.content });
} catch {
return Response.json({ error: "Generation failed." }, { status: 500 });
}
});
เพิ่ม COMETAPI_API_KEY และ COMETAPI_MODEL ไปยังซีเคร็ตของโปรเจ็กต์ Supabase จากนั้นดีพลอยฟังก์ชัน
ทั้งสองแนวทางนี้ ให้เก็บข้อมูลรับรอง API ไว้บนเซิร์ฟเวอร์ แอปโปรดักชันควรติดตั้งระบบยืนยันตัวตน การตรวจสอบอินพุต และลิมิตการใช้งานต่อผู้ใช้ด้วย
Step 5: Connect the Lovable Interface import { generate } from "./server/writing.functions";
const { text } = await generate({ data: { prompt, tone } });
// Render text as text content, not as trusted HTML.
// Use the existing, signed-in Supabase client generated for your project.
const { data, error } = await supabase.functions.invoke("generate-writing", {
body: { prompt, tone },
});
if (error) throw new Error("Generation failed. Please try again.");
const text = data.text;
ใช้ไคลเอนต์ที่ตรงกับสาขาที่เลือก TanStack ใช้เอ็นด์พอยต์ RPC ที่สร้างไว้ ส่วน Supabase ใช้ฟังก์ชัน generate-writing ที่ดีพลอยไว้ ทั้งสองอย่างไม่ต้องสร้างเส้นทาง /api/generate แยกต่างหาก เบราว์เซอร์อาจส่งโทเค็นเซสชันของแอปสำหรับการยืนยันตัวตน แต่ต้องไม่ส่งคีย์ CometAPI ส่วนตัวหรือออบเจ็กต์ config แสดงสถานะกำลังโหลด ความล้มเหลว และปุ่มลองใหม่ในอินเทอร์เฟซ
Step 6: Test and Publish the Application หลังจากเผยแพร่ ให้ทดสอบ URL ที่ใช้งานจริง แทนการพึ่งพาพรีวิวในเอดิเตอร์ ใช้ข้อมูลรับรองสำหรับทดสอบแบบส่วนตัว และหลีกเลี่ยงการแสดงความลับในสกรีนช็อตและหลักฐาน ทำเช็กลิสต์นี้ให้ครบก่อนเปิดให้ใช้งานกว้างขึ้น:
ตรวจสอบไฟล์ JavaScript ที่ถูกบันเดิลสำหรับเบราว์เซอร์ ซอร์สแม็พ และการกำหนดค่าสาธารณะ ว่ามีคีย์ CometAPI ส่วนตัวหรือไม่ ค้นหาในเครื่องโดยไม่พิมพ์คีย์ลงในเอาต์พุตเทอร์มินัลที่แชร์หรือบันทึกไว้ ชื่อแปรเพียงอย่างเดียวไม่ใช่หลักฐานการรั่วไหลของค่า
ตรวจสอบคำขอ Network ของเบราว์เซอร์ รวมถึงเพย์โหลด เฮดเดอร์ และการตอบกลับข้อผิดพลาด คำขอควรมีเพียงอินพุตการเขียนที่อนุญาตและข้อมูลยืนยันตัวตนของแอป เฮดเดอร์ Authorization ของ CometAPI ส่วนตัวต้องอยู่เฉพาะในคำขอจากเซิร์ฟเวอร์ไปยังผู้ให้บริการ
ทบทวนล็อกของฟังก์ชัน ล็อกของแอป การติดตามการมอนิเตอร์ และรายงานข้อผิดพลาด อย่าบันทึกคีย์ โทเค็น Bearer ออบเจ็กต์การกำหนดค่า หรือเนื้อหาข้อผิดพลาด upstream แบบเต็ม หากคีย์ถูกเปิดเผย ให้เพิกถอนและแทนที่ แล้วลบการเปิดเผยก่อนทดสอบใหม่
ทดลองคำขอขณะไม่ได้ลงชื่อเข้าใช้และเซสชันหมดอายุ ทั้งสองแบบต้องถูกปฏิเสธก่อนเรียกผู้ให้บริการ ส่ง apiKey, config หรือ model เป็นฟิลด์เพิ่มเติมและยืนยันว่าถูกปฏิเสธ ทดสอบพรอมป์ต์ว่างและเกินขนาด โทนที่ไม่ถูกต้อง ความล้มเหลวของผู้ให้บริการ และโควต้าต่อผู้ใช้ที่ดีพลอยของคุณ
ยืนยันว่าคำขอที่ลงชื่อเข้าใช้ถูกต้องจะสร้างข้อความด้วยโมเดลที่คุณเลือก บันทึกเวอร์ชันดีพลอยและผลลัพธ์แบบ sanitized ผ่าน/ไม่ผ่าน ตัวอย่างเหล่านี้ไม่ได้ระบุว่าการดีพลอยของคุณเองผ่านการตรวจเหล่านี้แล้ว
ผู้ช่วยการเขียน AI ร่างและเขียนใหม่เนื้อหา ตัวเลือกโทน เทมเพลต เอดิเตอร์ ตัวสรุปเอกสาร สรุปข้อความที่ดึงมา อัปโหลด ถามตอบเอกสาร ประเด็นสำคัญ ศูนย์บริการลูกค้า จัดหมวดและร่างคำตอบ คัดกรองทิคเก็ต ข้อเสนอแนะคำตอบ ผู้ช่วยวิเคราะห์ธุรกิจ อธิบายข้อมูลทางธุรกิจ แดชบอร์ด KPI อินไซต์ภาษาธรรมชาติ
พรอมป์ต์ปกติให้ผลลัพธ์ของโมเดลที่อ่านได้
พรอมป์ต์ว่างและเกินขนาดถูกปฏิเสธอย่างปลอดภัย
ข้อมูลรับรอง API ไม่ปรากฏในแผงเครือข่ายของเบราว์เซอร์
การหยุดให้บริการของโมเดลส่งคืนข้อความผิดพลาดที่ไม่เปิดเผยข้อมูลสำคัญ
ผู้ใช้ที่ยืนยันตัวตนมีลิมิตคำขอและการมอนิเตอร์กิจกรรม
เลย์เอาต์ทำงานถูกต้องทั้งเดสก์ท็อปและมือถือ
สิ่งเหล่านี้เป็นรูปแบบโปรเจ็กต์ที่แนะนำ ไม่ใช่การอ้างว่าเป็นดีพลอยที่เสร็จสมบูรณ์หรือผ่านการวัดผลโดยอิสระ
FAQ
แอปหลายผู้เช่าควรป้องกันไม่ให้บันทึกของลูกค้าหนึ่งไปโผล่ในคำตอบ AI ของลูกค้าอื่นอย่างไร? อนุมาน tenant และตัวตนผู้ใช้จากเซสชันฝั่งเซิร์ฟเวอร์ที่ยืนยันแล้ว จากนั้นจำกัดขอบเขตการค้นหาฐานข้อมูลทุกครั้งก่อนประกอบบริบทโมเดล อย่าเชื่อถือ tenant ID ที่เบราว์เซอร์ส่งมา หรือหวังพึ่งคำสั่งในพรอมป์ต์เพื่อบังคับการเข้าถึง ที่รองรับให้เพิ่มนโยบายระดับแถวของฐานข้อมูลและทดสอบด้วยบัญชีสองบัญชี ทดสอบ ID ระเบียน ผลการค้นหา ไฟล์ที่ส่งออก และประวัติการสนทนาเพื่อหาการเข้าถึงข้ามผู้เช่า นี่เป็นคำแนะนำด้านการออกแบบแอป โค้ดที่สร้างและการสแกนแพลตฟอร์มไม่ได้ยืนยันว่านโยบายถูกต้อง
เมื่อไหร่ที่ควรใช้ retrieval-augmented generation แทนการใส่เอกสารลงในทุกพรอมป์ต์โดยตรง? ใช้ retrieval เมื่อชุดเอกสารใหญ่เกินกว่าจะส่งทุกครั้ง เปลี่ยนแปลงบ่อย หรือจำเป็นต้องติดตามแหล่งที่มาระดับเอกสาร แยกวิเคราะห์และทำดัชนีเอกสาร ดึงชุดที่เกี่ยวข้องขนาดเล็ก และแนบตัวระบุแหล่งข้อมูลกับคำตอบ Retrieval ยังต้องประเมินผล: คำตอบที่ลื่นไหลอาจอ้างอิงส่วนที่ไม่เกี่ยวข้อง รักษาตัวกรองการเข้าถึงไว้ในคำค้น retrieval และทดสอบคำถามที่ไม่มีคำตอบในชุดข้อมูล สำหรับเอกสารเล็กและคงที่ การแนบบริบทโดยตรงอาจเป็นจุดเริ่มที่ง่ายกว่า
จะเพิ่มการสตรีมโดยไม่แสดงผลลัพธ์ที่แตกหรือทำให้เข้าใจผิดได้อย่างไร? มองการสตรีมเป็นฟีเจอร์การขนส่งแยกต่างหาก ไม่ใช่การสลับค่า stream: false เพียงบรรทัดเดียว ยืนยันรูปแบบสตรีมของโมเดลที่เลือก ให้แบ็กเอนด์ถ่ายทอดอีเวนต์ และจัดการชิ้นส่วนบางส่วน การยกเลิก การหมดเวลา และการสูญเสียการเชื่อมต่อใน UI ทำเครื่องหมายคำตอบที่ถูกขัดจังหวะว่าไม่สมบูรณ์และให้ผู้ใช้ลองใหม่อย่างมีเจตนา หลีกเลี่ยงการแสดงข้อความสตรีมเป็น HTML ที่เชื่อถือได้ ทดสอบบนเส้นทางโฮสติ้งที่เผยแพร่แล้ว เพราะตัวกลางอาจบัฟเฟอร์สตรีมที่ดูเหมือนทำงานได้ในเครื่อง
นโยบาย fallback ควรตรวจอะไรบ้างก่อนสลับไปโมเดลอื่น? กำหนดความล้มเหลวใดที่สมเหตุผลต่อการลองใหม่หรือ fallback จากนั้นตรวจว่าโมเดลทางเลือกนั้นรองรับเอ็นด์พอยต์เดียวกัน คำสั่งเดียวกัน สคีมาของเครื่องมือ และรูปแบบเอาต์พุตเดียวกัน รักษาขอบเขตการลองใหม่ และหลีกเลี่ยงการเปลี่ยนโมเดลอย่างเงียบๆ สำหรับเวิร์กโฟลว์ที่ต้องการพฤติกรรมสม่ำเสมอ ประเมิน fallback ด้วยพรอมป์ต์ที่เป็นตัวแทน รวมถึงกรณีปฏิเสธและเอาต์พุตผิดรูป หากเอาต์พุตของโมเดลกระตุ้นการกระทำภายนอก ป้องกันการกระทำนั้นด้วยการยืนยันแยกต่างหากหรือกฎ idempotency เพื่อไม่ให้การลองใหม่สร้างผลซ้ำ
หลักฐานใดที่ทีมควรรวบรวมก่อนเลื่อนฟีเจอร์ AI จากระยะทดลองไปใช้งานประจำ? เก็บชุดการประเมินแบบมีเวอร์ชันพร้อมพฤติกรรมที่คาดหวัง การกำหนดค่าโมเดลและพรอมป์ต์ เมทาดาทาคำขอที่ทำการปิดข้อมูล และบันทึกกรณีล้มเหลว กำหนดเกณฑ์การยอมรับสำหรับความถูกต้องเชิงข้อเท็จจริง รูปทรงการตอบสนอง ระยะเวลา และขอบเขตการเข้าถึง เปรียบเทียบผลลัพธ์หลังการเปลี่ยนโมเดลหรือพรอมป์ต์ สำหรับอินพุตที่อ่อนไหว ให้ตัดสินใจว่าข้อมูลใดสามารถส่งและเก็บไว้ได้ก่อนเปิดใช้งานฟีเจอร์ นี่เป็นข้อเสนอแนะด้านวิศวกรรม ไม่ใช่คำอ้างว่า Lovable หรือ CometAPI รับประกันผลลัพธ์ตามกฎระเบียบใดๆ
Conclusion: Is Lovable Worth Using? Lovable ทำให้การแปลงไอเดียเป็นแอปที่ใช้งานได้จริงง่ายขึ้น เครื่องมือแบบฟูลสแต็กและการผสานภายนอกช่วยให้ตรวจสอบแนวคิดผลิตภัณฑ์ได้อย่างรวดเร็ว CometAPI เพิ่มเส้นทางที่ยืดหยุ่นสำหรับการอนุมานโมเดลในเวิร์กโฟลว์แชต การเขียน การวิเคราะห์ และ AI อื่นๆ
เริ่มจากแอปขนาดเล็กที่ปลอดภัย ทดสอบการเชื่อมต่อ CometAPI ทบทวนโค้ดที่สร้าง และขยายต่อเมื่อประสบการณ์หลักพิสูจน์แล้วว่าเชื่อถือได้
สร้างผู้ช่วย AI ด้วย Lovable และ CometAPI - CometAPI
