ຄູ່ມືການใช้งาน Lovable: ສ້າງເວັບແອບພິເຄຊັນທີ່ພ້ອມໃຊ້ງານໄດ້ດ້ວຍການພິມປະໂຫຍດດຽວ ແລະ ຊິ້ງຂໍ້ມູນລົງ GitHub ໄດ້

ເພື່ອນຂ້ອຍຄົນໜຶ່ງທີ່ເປັນທາຍາດຸທະກິດດັ້ງເດີມຢູ່ໄທຊຸບ ເມື່ອປີກາຍນີ້ໄດ້ເສຍເງິນສິບແປດໝືນຊອກຫາ Outsource ເພື່ອເຮັດລະບົບພາຍໃນສຳລັບ "ພະນັກງານຂາຍລາຍງານຄວາມຄືບໜ້າ". ເຮັດຢູ່ສີ່ເດືອນ, ພໍເປີດໃຊ້ງານແລ້ວພະນັກງານຂາຍບອກວ່າໃຊ້ຍາກ, ບໍ່ມີໃຜຕື່ມຂໍ້ມູນເລີຍ.

ເດືອນແລ້ວນີ້ ລາວໄດ້ສົ່ງລິ້ງໜຶ່ງມາໃຫ້ຂ້ອຍ, ບອກວ່າແມ່ນລະບົບທົດແທນທີ່ລາວເຮັດຂຶ້ນມາເອງໃນຕອນບ່າຍດຽວ. ຂ້ອຍກົດເຂົ້າໄປເບິ່ງ, ຕອນໜ້າສະອາດຮຽບຮ້ອຍ, มีລະບົບເຂົ້າສູ່ລະບົບ (Login), ບັນທຶກຂໍ້ມູນໄດ້, ແລະ ພະນັກງານຂາຍກfໃຊ້ແທ້ໆ. ລາວເວົ້າວ່າ: "ຂ້ອຍກໍພຽງແຕ່ພິມສິ່ງທີ່ຂ້ອຍຕ້ອງການລົງໄປ, ມັນກໍສ້າງອອກມາ."

ເຄື່ອງມືນັ້ນກໍຄື Lovable.

Lovable ແມ່ນຫຍັງ

ທາງການໄດ້ໃຫ້ຄຳນຍາມຕົນເອງວ່າ "ແພລດຟອມພັດທະນາ AI ແບບ Full-stack, ສ້າງ, ປັບປຸງ ແລະ ເຜີຍແຜ່ແອັບພລິເຄຊັນເວັບດ້ວຍພາສາທຳມະຊາດ, ຜະລິດໂຄດຕົວຈິງ, ມີຄວາມປອດໄພ ແລະ ການຄຸ້ມຄອງລະດັບວິສາຫະກິດ".

ຖ້າແຍກອອກມາແລ້ວມີສາມຢ່າງຄື: ເຈົ້າເວົ້າ, ມັນຂຽນໂຄດແທ້, ແລະ ໂຄດນັ້ນແມ່ນຂອງເຈົ້າ.

ຂໍ້ທີສາມແມ່ນຈຸດສຳຄັນ. ເຄື່ອງມື No-code ຫຼາຍຢ່າງໃນທ້ອງຕະຫຼາດ ສິ່ງທີ່ສ້າງຂຶ້ນມາແມ່ນຖືກລັອກໄວ້ໃນແພລດຟອມ, ຖ້າຢາກຍ້າຍອອກກໍເທົ່າກັບຕ້ອງຂຽນໃໝ່. ຂັ້ນຕອນທາງການຂອງ Lovable ມີຂັ້ນຕອນ "Sync ໄປຍິ່ງ GitHub" ຢ່າງຈະແຈ້ງ, ເຊິ່ງໝາຍຄວາມວ່າເຈົ້າສາມາດພາໂຄດຂອງເຈົ້າໜີໄປໄດ້ຕະຫຼອດເວລາ.

ມັນສາມາດສ້າງຫຍັງໄດ້ແດ່

ປະເພດແອັບພລິເຄຊັນທີ່ເອກະສານທາງການລະບຸໄວ້ມີຂ້ອນຂ້າງກວ້າງ:

• ຜະລິດຕະພັນ SaaS ແລະ ແດຊບອດທຸລະກິດ (Business Dashboards)
• ແພລດຟອມສຳລັບຜູ້ບໍລິໂພກ ແລະ ເວັບໄຊສັງຄົມ
• ຕະຫຼາດອອນລາຍ ແລະ ເຄື່ອງມືອີຄອມເມີຊ
• ໂຫຼດງານພາຍໃນ ແລະ ລະບົບປະຕິບັດການ
• ເວັບໄຊການຕະຫຼາດ ແລະ Landing Page
• ແພລດຟອມການສຶກສາ ແລະ ເຄື່ອງມືການຮຽນຮູ້
• ເກມເວັບ ແລະ ເນື້ອຫາໂຕ້ຕອບ

ການປະເມີນຂອງຂ້ອຍເອງແມ່ນ: ເຄື່ອງມືພາຍໃນ ແລະ ການກວດສອບ MVP ຖືເປັນຈຸດທີ່ເໝາະສົມທີ່ສຸດ (Sweet Spot). ສິ່ງປະເພດທີ່ "ຄວາມຕ້ອງການຊັດເຈນ, ຜູ້ໃຊ້ບໍ່ຫຼາຍ, ແຕ່ຈ້າງ Outsource ແລ້ວບໍ່ຄຸ້ມຄ່າ", ແມ່ນຕົກຢູ່ໃນຊ່ວງນີ້ພໍດີ.

ວິທີໃຊ້: ຂັ້ນຕອນສີ່ຂັ້ນຕອນຈາກທາງການ

ເອກະສານຂອງ Lovable ໄດ້ອະທິບາຍຂັ້ນຕອນໄວ້ຢ່າງກະທັດຮັດ, ມີພຽງສີ່ຂັ້ນຕອນ:

ຂັ້ນຕອນທີ 1: Describe——ອະທິບາຍສິ່ງທີ່ທ່ານຕ້ອງການດ້ວຍພາສາທຳມະຊາດ

ຂັ້ນຕອນນີ້ເປັນຕົວຊີ້ວັດວ່າຫຼັງຈາກນັ້ນຈະຮາບລື່ນຫຼືບໍ່. ຄືກັນกับการປ້ອນ Prompt ໃຫ້ແຊັດບັອດ, ຍິ່ງເວົ້າລະອຽດຫຼາຍເທົ່າໃດ, ສິ່ງທີ່ອອກມາຜົນລັບກໍຈະຍິ່ງໃກ້ຄຽງກັບສິ່ງທີ່ເຈົ້າຕ້ອງການຫຼາຍເທົ່ານັ້ນ.

ໂຄງສ້າງການອະທິບາຍທີ່ໃຊ້ງານໄດ້ຈິງ:

ຂ້ອຍຕ້ອງການສ້າງລະບົບພາຍໃນ "ພະນັກງານຂາຍລາຍງານຄວາມຄືບໜ້າ".
ຜູ້ໃຊ້: ປະມານ 15 ຄົນ, ຕ້ອງການບັນຊີເຂົ້າສູ່ລະບົບ.
ໜ້າຈໍຫຼັກ: (1) ພະນັກງານຂາຍເຂົ້າສູ່ລະບົບແລ້ວເຫັນລາຍຊື່ລູກຄ້າທີ່ຕົນເອງຮັບຜິດຊອບ (2) ກົດເຂົ້າໄປໃນລູກຄ້າສາມາດເພີ່ມບັນທຶກການເຂົ້າຢ້ຽມຢາມໃໝ່ໄດ້, ຊ່ອງຂໍ້ມູນມີວັນທີ, ວິທີການເຂົ້າຢ້ຽມຢາມ, ສິ່ງທີ່ໄດ້ສົນທະນາກັນ, ຂັ້ນຕອນຕໍ່ໄປ (3) ບັນຊີຫົວໜ້າສາມາດເບິ່ງບັນທຶກຂອງພະນັກງານຂາຍທຸກຄົນໄດ້ ແລະ ສາມາດກັ່ນຕອງຕາມວັນທີ.
ຮູບແບບ: เรียบງ່າຍ, ເນັ້ນຕາຕະລາງເປັນຫຼັກ, ມືຖືຕ້ອງໃຊ້ງານໄດ້.

ເມື່ອທຽບໃສ່ກັບການເວົ້າວ່າ "ຊ່ວຍເຮັດ CRM ໃຫ້ຂ້ອຍແດ່", ການອະທິບາຍແບບນີ້ສາມາດຊ່ວຍປະຢັດເວລາໃນການກັບມາແກ້ໄຂໄປມາໄດ້ຢ່າງຫຼວງຫຼາຍ.

ຂັ້ນຕອນທີ 2: Review and iterate——ເບິ່ງຜົນລັບ, ແກ້ໄຂ, ແລ້ວເບິ່ງໃໝ່

Lovable ຈະສ້າງແອັບພລິເຄຊັນທີ່ສາມາດກົດໃຊ້ງານໄດ້ທັນທີ, ເຈົ້າກົດເບິ່ງແລ້ວຈະຮູ້ເລີຍວ່າຖືກຕ້ອງຫຼືບໍ່. ສ່ວນໃດທີ່ບໍ່ຖືກຕ້ອງກໍສາມາດສັ່ງແກ້ໄຂດ້ວຍການພິມບອກໄດ້ເລີຍ: "ລາຍຊື່ລູກຄ້າຕ້ອງເພີ່ມຊ່ອງ 'ວັນທີຕິດຕໍ່ຫຼ້າສຸດ'", "ຫຼັງຈາກເຂົ້າສູ່ລະບົບໃຫ້ສະແດງບັນທຶກຂອງເດືອນນີ້ເປັນຄ່າເລີ່ມຕົ້ນ".

ຈຸດສຳຄັນໃນການປະຢັດເງິນຢູ່ບ່ອນນີ້: ໃຫ້ແຈ້ງການແກ້ໄຂໃຫ້ໝົດໃນຄັ້ງດຽວ, ຢ່າແກ້ໄຂເທື່ອລະຢ່າງ. ທຸກໆຄັ້ງທີ່ສົ່ງຂໍ້ຄວາມຈະນັບເປັນການ Build 1 ຄັ້ງ, ການລວມການແກ້ໄຂນ້ອຍໆສາມຢ່າງເຂົ້າເປັນຂໍ້ຄວາມດຽວ ຈະເຮັດໃຫ້ຕົ້ນທຶນຕ່າງກັນເຖິງສາມເທົ່າ.

ຂັ້ນຕອນທີ 3: Sync to GitHub——ເຊື່ອມຕໍ່ໂຄດກັບຂັ້ນຕອນການເຮັດວຽກຂອງທ່ານ

ເມື່ອໂຄງຮ່າງຕົ້ນແບບຖືກຕ້ອງແລ້ວ, ໃຫ້ Sync ໄປຍິ່ງ GitHub. ຄວາມໝາຍຂອງຂັ້ນຕອນນີ້ແມ່ນ:

• ເຈົ້າມີລະບົບຄວບຄຸມເວີຊັນ (Version Control) ແລະ ການສຳຮອງຂໍ້ມູນ
• ວິສະວະກອນສາມາດສືບຕໍ່ໃຊ້ Editor ຂອງຕົນເອງໃນການແກ້ໄຂໄດ້ (Cursor, Zed ກໍໄດ້ທັງໝົດ)
• ສามารถເຊື່ອມຕໍ່ CI/CD ແລະ ລະບົບກວດສອບຄວາມປອດໄພຂອງຕົນເອງໄດ້
• ຈະບໍ່ຖືກລັອກຕິດໄວ້ກັບແພລດຟອມ

ຂ້ອຍແນະນຳຢ່າງຍິ່ງວ່າ ທັນທີທີ່ໂຄງການມີຄວາມເປັນທາງການຂຶ້ນມາໜ້ອຍໜຶ່ງ, ຕ້ອງເຮັດຂັ້ນຕອນນີ້ໃຫ້ໄດ້.

ຂັ້ນຕອນທີ 4: Deploy and govern——ການເຜີຍແຜ່ ແລະ ການຄຸ້ມຄອງ

ເຜີຍແຜ່ຕາມມາດຕະຖານຂອງອົງກອນຂອງທ່ານ. Lovable ມີບໍລິການ Cloud Hosting ພາຍໃນຕົວ (ລວມທັງຖານຂໍ້ມູນ, ພື້ນທີ່ຈັດເກັບຂໍ້ມູນ, ແລະ ປະລິມານການໃຊ້ງານ), ຫຼື ທ່ານສາມາດເຊື່ອມຕໍ່ເອງກໍໄດ້.

ການຄິດໄລ່ເຄຣດິດ: ສາມຈຸດປະສົງ, ຢ່າຫຼົງກັນ

ນີ້ແມ່ນຈຸດທີ່ຄົນມັກພາດຫຼາຍທີ່ສຸດ. ເອກະສານທາງການໄດ້ແບ່ງເຄຣດິດອອກເປັນສາມຈຸດປະສົງ:

• Build usage: ການສົ່ງຂໍ້ຄວາມໃນ Lovable ເພື່ອວາງແຜນ, ສ້າງ, ແກ້ໄຂ ຫຼື ອັບເດດແອັບພລິເຄຊັນຂອງທ່ານ
• Cloud usage: ການໂຮສຕິ້ງ (Hosting), ຖານຂໍ້ມູນ, ພື້ນທີ່ຈັດເກັບຂໍ້ມູນ ແລະ ຊັບພະຍາກອນເຄືອຂ່າຍ
• AI gateway usage: ການເອີ້ນໃຊ້ໂມເດວ AI ภายในແອັບພລິເຄຊັນທີ່ທ່ານເຜີຍແຜ່ອອກໄປ

ແຫຼ່ງທີ່ມາຂອງເຄຣດິດກໍແບ່ງເປັນສອງແບບ: ໂຄຕ້າສະເພາະຈຸດປະສົງ (ໂຄຕ້າ Build ຕໍ່ວັນ, ໂຄຕ້າ Cloud ແລະ AI ຕໍ່ເດືອນ, ລະບົບຈະອັບເດດให้อັດຕະໂນມັດ) ແລະ ເຄຣດິດທົ່ວໄປ (ໂຄຕ້າາຍແຜນລາຍເດືອນ, ການຊື້ເພີ່ມ, รางวัล, ສามารถໃຊ້ງານໄດ້ຢ່າງຢືດຢຸ່ນ). ເອກະສານທາງການລະບຸຢ່າງຈະແຈ້ງວ່າ ລະບົບຈະໃຊ້ໂຄຕ້າສະເພາະຈຸດປະສົງກ່ອນ, ແລ້ວຈຶ່ງໃຊ້ເຄຣດິດທົ່ວໄປ, ໂດຍໃຫ້ບຸລິມະສິດຫັກເຄຣດິດທີ່ໝົດອາຍຸໄວທີ່ສຸດກ່ອນ.

ໂຄງສ້າງໂຄຕ້າທີ່ລະບຸໄວ້ໃນເອກະສານທາງການ:

ແຜນການ (Plan)	Build ຕໍ່ວັນ	Cloud ຕໍ່ເດືອນ	AI ຕໍ່ເດືອນ	ราคาຊື້ເພີ່ມຕໍ່ໜ່ວຍ
Free	5 ครั้ง/ວັນ (ສູງສຸດຕໍ່ເດືອນ 30)	20 ເຄຣດິດ	4 ເຄຣດິດ	—
Pro	5 ครั้ง/ວັນ	20 ເຄຣດິດ	4 ເຄຣດິດ	0.30 ໂດລາສະຫະລັດ/ເຄຣດິດ
Business	5 ครั้ง/ວັນ	20 ເຄຣດິດ	4 ເຄຣດິດ	0.60 ໂດລາສະຫະລັດ/ເຄຣດິດ

ການຫັກໂຄຕ້າ Build ຈະຂຶ້ນຢູ່ກັບຄວາມສັບສົນ, ຕົວຢ່າງທີ່ທາງການຍົກຂຶ້ນມາຄື ການແກ້ໄຂນ້ອຍໆປະມານ 0.5 ເຄຣດິດ, ການເພີ່ມຟັງຊັນໃຫຍ່ເຊັ່ນລະບົບເຂົ້າສູ່ລະບົບປະມານ 1.2 ເຄຣດິດ.

ສ່ວນທີ່ມักຈະໝົດໄວທີ່ສຸດແມ່ນ Cloud. ບໍລິການ Hosting ຈະຄິດໄລ່ຕາມການໃຊ້ງານຈິງ ແລະ ບໍ່ໄດ້ລວມຢູ່ໃນຄ່າบริการລາຍເດືອນຂອງແຜນ. ຖ້າແອັບພລິເຄຊັນຂອງທ່ານຖືກໃຊ້ງານຢ່າງໜັກໜ່ວງ, ຫຼື ຖານຂໍ້ມູນມີການຈັດເກັບໄຟລ໌ຈຳນວນຫຼາຍ, ຄ່າໃຊ້ຈ່າຍສ່ວນນີ້ຈະสะสมເພີ່ມຂຶ້ນເລື້ອຍໆ. ກ່ອນທີ່ຈະເຜີຍແຜ່ ໃຫ້ກວດສອບໜ້າ Dashboard ການໃຊ້ງານທຸກຄັ້ງ, ຢ່າລໍຖ້າຈົນກວ່າໃບບິນມາຮອດແລ້ວຈຶ່ງຮູ້ຕົວ.

ເທັກນິກຂັ້ນສູງ: ສີ່ວິທີທີ່ຈະຊ່ວຍຫຼຸດຕົ້ນທຶນລົງເຄິ່ງໜຶ່ງ

1. ວາດພາບກ່ອນແລ້ວຄ่อยລົງມືເຮັດ. ກ່ອນທີ່ຈະລົງມື, ໃຫ້ໃຊ້ເຈ້ຍ ແລະ ປາກກາ ຫຼື Excalidraw ວາດໜ້າຈໍທີ່ທ່ານຕ້ອງການອອກມາກ່ອນ. ຄິດໄລ່ຈຳນວນໜ້າຈໍ ແລະ ຊ່ອງຂໍ້ມູນໃນແຕ່ລະໜ້າຈໍໃຫ້ຊັດເຈນກ່ອນທີ່ຈະເລີ່ມອະທິບາຍ, ເຊິ່ງຈະຊ່ວຍຫຼຸດຜ່ອນການແກ້ໄຂໄປມາໄດ້ຢ່າງຫຼວງຫຼາຍ.

2. ລວມຄຳສັ່ງແກ້ໄຂ. ໄດ້ກ່າວໄປແລ້ວແຕ່ຄວນກ່າວຊ້ຳອີກຄັ້ງ. "ຂະຫຍາຍຫົວຂໍ້ໃຫ້ໃຫຍ່ຂຶ້ນ, ປ່ຽນປຸ່ມເປັນສີຟ້າ, ເພີ່ມປຸ່ມສົ່ງອອກຂໍ້ມູນ" ໃຫ້ຂຽນລວມໄວ້ໃນຂໍ້ຄວາມດຽວ, ຢ່າແຍກເປັນສາມຄັ້ງ.

3. ແບ່ງຟັງຊັນທີ່ສັບສົນອອກເປັນໄລຍະໆ. ສ້າງເວີຊັນພື້ນຖານທີ່ສາມາດໃຊ້ງານໄດ້ກ່ອນ (ລາຍຊື່ + ເພີ່ມຂໍ້ມູນ), ເມື່ອຢືນຢັນແລ້ວວ່າໂຄງສ້າງຂໍ້ມູນຖືກຕ້ອງ, ຈຶ່ງค่อยເພີ່ມລະບົບເຂົ້າສູ່ລະບົບ, ແລ້ວຈຶ່ງค่อยເພີ່ມສິດທິການໃຊ້ງານ. ຖ້າໃຫ້ມັນເຮັດທຸກຢ່າງພ້ອມກັນໃນຄັ້ງດຽວ, ເມື່ອເກີດຂໍ້ຜິດພາດຂຶ້ນມາເຈົ້າຈະບໍ່ຮູ້ເລີຍວ່າສ່ວນໃດເສຍຫາຍ, ແລະ ຕົ້ນທຶນໃນการເລີ່ມຕົ້ນໃຫມ່ແມ່ນສູງທີ່ສຸດ.

4. ໃຊ້ເວີຊັນຟຣີໃນຊ່ວງຕົ້ນແບບ, ຈ່າຍເງິນກໍຕໍ່ເມື່ອໝັ້ນໃຈວ່າຈະເຮັດແທ້. ການໃຊ້ງານ 5 Build ຕໍ່ວັນອາດຈະຟັງເບິ່ງຄືໜ້ອຍ, ແຕ່ຖ້າຄຳອະທິບາຍຂອງທ່ານຊັດເຈນພໍ, 5 ຄັ້ງກໍພຽງພໍທີ່ຈະຊ່ວຍໃຫ້ວຽກກ້າວໜ້າໄປໄດ້ຫຼາຍພໍສົມຄວນ. ໃຫ້ໃຊ້ເວີຊັນຟຣີເພື່ອພິສູດກ່ອນວ່າຄວາມຄິດນີ້ຄຸ້ມຄ່າທີ່ຈະເຮັດຫຼືບໍ່, ແລ້ວຈຶ່ງຕັດສິນໃຈວ່າຈະລົງທຶນເງິນລົງໄປບໍ.

ข้อຄວນລະວັງ: ນັກພັດທະນາໃນໄຕ້ຫວັນ (ຫຼືຜູ້ໃຊ້ທົ່ວໄປ) ກະລຸນາສັງເກດເປັນພິເສດ

ຄວາມປອດໄພດ້ານຂໍ້ມູນບໍ່ສາມາດຝາກໄວ້ກັບ AI ພຽງຢ່າງດຽວ. Lovable ທາງການໄດ້ເນັ້ນຢ້ຳວ່າຜົນຜະລິດມີການຄໍານຶງເຖິງຄວາມປອດໄພ, ແຕ່ໂຄດທີ່ສ້າງໂດຍ AI ອາດຈະຍັງມີບັນຫາເຊັ່ນ ການຕັ້ງຄ່າສິດທິອະນຸຍາດກວ້າງເກີນໄປ, ຂໍ້ມູນນຳເຂົ້າທີ່ບໍ່ໄດ້ຮັບການກວດສອບ. ຕราบໃດທີ່ແອັບພລິເຄຊັນຂອງທ່ານມີການຈັດການຂໍ້ມູນສ່ວນບຸກຄົນ (ລາຍຊື່ລູກຄ້າ, ຂໍ້ມູນພະນັກງານ, ໝາຍເລກບັດປະຈຳຕົວ), ທ່ານມີພັນທະທີ່ຈະຕ້ອງປົກປ້ອງຕາມກົດໝາຍ. ຕ້ອງດຶງໂຄດກັບມາທີ່ GitHub, ໃຫ້ວິສະວະກອນກວດສອບຄວາມປອດໄພຫນຶ່ງຄັ້ງ, ຫຼື ຢ່າງນ້ອຍກໍໃຫ້ກວດສອບດ້ວຍລະບົບອັດຕະໂນມັດ. ນີ້ບໍ່ແມ່ນສິ່ງທີ່ເລືອກໄດ້.

ຢ່າເບິ່ງວ່າມັນເປັນໄມ້ວິເສດທີ່ບໍ່ຈຳເປັນຕ້ອງເຂົ້າໃຈເຕັກໂນໂລຊີ. ມັນຊ່ວຍໃຫ້ຄົນທີ່ຂຽນໂຄດບໍ່ເປັນສາມາດສ້າງສິ່ງຕ່າງໆຂຶ້ນມາໄດ້, ແຕ່ເມື່ອສິ່ງນັ້ນພັງລົງ, ประสิทธิภาพຊ້າລົງ, ການອອກແບບຖານຂໍ້ມູນບໍ່ຖືກຕ້ອງ, ທ່ານກໍຍັງຈຳເປັນຕ້ອງມີຄົນທີ່ມີຄວາມຮູ້ເຂົ້າມາຊ່ວຍ. ຄວາມຄາດຫວັງທີ່ສົມເຫດສົມຜົນແມ່ນ: ມັນຫຼຸດຜ່ອນອຸປະສັກ "ຈາກສູນຫາໜຶ່ງ" ລົງ 90%, ແຕ່ "ຈາກໜຶ່ງຫາຄວາມສະຖຽນ" ຍັງຄົງຕ້ອງການຄວາມຊ່ຽວຊານ.

ຕ້ອງຕິດຕາມຕົ້ນທຶນແບບໄດນາມິກ. ค่าບໍລິການລາຍເດືອນຂອງການສະໝ