AI ສຳພາດຊຸດທີ 15: ຂຸມຄຸກທົ່ວໄປຂອງ Vibe Coding ມີຫຍັງແດ່?

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

ໜຶ່ງ. ຂຸມຄຸກດ້ານຄຸນະພາບລະຫັດ

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

1. ລະຫັດທີ່ຊ້ຳຊ້ອນ ແລະ ບໍ່ໄດ້ໃຊ້: ຫຼັງຈາກການແກ້ໄຂຫຼາຍເທື່ອ, AI ຈະເຫຼືອການຈັດຕັ້ງປະຕິບັດເກົ່າ, ບລັອກລະຫັດທີ່ຖືກສະກັດໄວ້, ການນຳເຂົ້າທີ່ບໍ່ໄດ້ໃຊ້, ເພາະວ່າຄວາມສ່ຽງໃນການລຶບສູງ, ມັນຈຶ່ງເລືອກທີ່ຈະເກັບໄວ້.
2. ການຕັ້ງຊື່ ແລະ ຮູບແບບທີ່ບໍ່ສອດຄ່ອງ: AI ໃນແຕ່ລະຮອບຈະສຸ່ມເອົາຮູບແບບຈາກຂໍ້ມູນການຝຶກ, ຖ້າຜູ້ໃຊ້ງານບໍ່ບັງຄັບໃຊ້ມາດຕະຖານ, ກໍ່ຈະມີການປະສົມ camelCase, underscore, ແລະ ຊ່ອງ.
3. ຂໍ້ຜິດພາດທາງເຫດຜົນທີ່ເຊື່ອງໄວ້: AI ມັກຈະສ້າງລະຫັດທີ່ຖືກຕ້ອງສຳລັບເສັ້ນທາງທົ່ວໄປ, ແຕ່ຂໍ້ມືດ (null, ຄ່າສູງສຸດ, ການທຳງານພ້ອມກັນ) ມັກຖືກລະເລີຍ, ເພາະວ່າຕົວຢ່າງແບບນີ້ໃນຂໍ້ມູນການຝຶກມີໜ້ອຍ.

ສອງ. ຂຸມຄຸກດ້ານການຮັກສາ

ຄວາມໄວໃນການປ່ຽນແປງຂອງ Vibe Coding ແມ່ນໄວຫຼາຍ, ຜູ້ໃຊ້ງານ ແລະ AI ຕ່າງກໍ່ເອົາໃຈໃສ່ວ່າ "ຟັງຊັນປັດຈຸບັນໃຊ້ໄດ້ບໍ່", ເກືອບບໍ່ມີເວລາຂຽນເອກະສານ, ຄຳເຫັນ ຫຼື ປັບປຸງໂຄງສ້າງ. AI ຂາດຄວາມຊົງຈຳໄລຍະຍາວ, ຈະບໍ່ເພີ່ມ docstring ໃຫ້ຟັງຊັນ, ແລະບໍ່ຄຳນຶງເຖິງນັກພັດທະນາຄົນຕໍ່ໄປ. ນອກຈາກນັ້ນ, AI ມັກຈະ "ເຮັດໃຫ້ສຳເລັດຄວາມຕ້ອງການປັດຈຸບັນ", ບາງຄັ້ງອອກແບບໂຄງສ້າງທົ່ວໄປຫຼາຍເກີນ (ຄິດວ່າຜູ້ໃຊ້ຈະຕ້ອງການໃນພາຍຫຼັງ), ບາງຄັ້ງກໍ່ສຳເນົາວາງເພື່ອໃຫ້ໄວ, ເຮັດໃຫ້ລະດັບການສະກັດສັບສົນ. ສະຫຼຸບໄດ້ດັ່ງນີ້:

1. ຂາດເອກະສານ ແລະ ຄຳເຫັນ: AI ປ່ອຍອອກລະຫັດທີ່ "ອະທິບາຍຕົວເອງ" ໂດຍຄ່າເລີ່ມຕົ້ນ, ແຕ່ regex ທີ່ສັບສົນ ຫຼື algorithm ຍາກທີ່ຈະເຂົ້າໃຈ; ຖ້າຜູ້ໃຊ້ບໍ່ຮ້ອງຂໍ, ມັນກໍ່ບໍ່ຂຽນເອກະສານ.
2. ການສະກັດຫຼາຍເກີນ ຫຼື ບໍ່ພຽງພໍ: ບາງຄັ້ງ AI ໃຊ້ຮູບແບບການອອກແບບທົ່ວໄປ (ເຊັ່ນ Factory, Strategy) ເຖິງແມ່ນວ່າບັນຫາງ່າຍດາຍ; ບາງຄັ້ງກໍ່ສຳເນົາບລັອກລະຫັດໂດຍກົງ ເພາະຂີ້ຄ້ານທີ່ຈະສະກັດຟັງຊັນຮ່ວມ.

ສາມ. ຂຸມຄຸກດ້ານຄວາມປອດໄພ

ຂໍ້ມູນການຝຶກຂອງ AI ປະກອບດ້ວຍລະຫັດແຫຼ່ງເປີດຫຼາຍ, ໃນນັ້ນມີຊ່ອງໂຫວ່ທາງປະຫວັດສາດ (ເຊັ່ນ SQL concatenation, hardcoded keys). ໃນ Vibe Coding, ຜູ້ໃຊ້ງານບໍ່ຄ່ອຍຮ້ອງຂໍ "ໃຊ້ parameterized query" ຫຼື "ອ່ານ key ຈາກ environment variable", AI ຈຶ່ງໃຊ້ຮູບແບບທີ່ພົບເຫັນຫຼາຍທີ່ສຸດ (ເຊິ່ງມັກຈະບໍ່ປອດໄພ). ນອກຈາກນັ້ນ, AI ບໍ່ມີຈິດສຳນຶກ "ຮູບແບບໄພຄຸກຄາມ", ຈະບໍ່ກວດສອບການກັ່ນຕອງຂໍ້ມູນນຳເຂົ້າ, ການຈຳກັດສິດອະນຸຍາດຕ່ຳສຸດ, ເພາະມັນສົນໃຈພຽງການນຳໃຊ້ຟັງຊັນ. ສະຫຼຸບໄດ້ດັ່ງນີ້:

1. ຊ່ອງໂຫວ່ Injection: AI ໃຊ້ string concatenation ເພື່ອສ້າງ SQL/command ໂດຍຄ່າເລີ່ມຕົ້ນ, ເພາະວ່າວິທີນີ້ແມ່ນທົ່ວໄປທີ່ສຸດໃນບົດຮຽນງ່າຍໆ.
2. ການ hardcode ຂໍ້ມູນລັບ: ຕົວຢ່າງໃນຂໍ້ມູນການຝຶກມັກຂຽນ API Key ຕາຍ, AI ຈະເລົ່າແບບນັ້ນ.
3. ສິດອະນຸຍາດຫຼາຍເກີນ: AI ເພື່ອຄວາມສະດວກ, ມັກໃຊ້ sudo ຫຼື ເປີດໄຟລ໌ແບບ w+ ໂດຍບໍ່ຄຳນຶງເຖິງສິດອະນຸຍາດທີ່ຈຳເປັນຕ່ຳສຸດ.

ສີ່. ຂຸມຄຸກດ້ານການພັດທະນາຄວາມຕ້ອງການ

Vibe Coding ບໍ່ມີຂອບເຂດທີ່ຊັດເຈນ. ຜູ້ໃຊ້ງານເວົ້າວ່າ "ເພີ່ມຟັງຊັນອີກອັນ", AI ຈະພະຍາຍາມຕອບສະໜອງ, ແຕ່ມັນບໍ່ຮູ້ວ່າອັນໃດ "ຢູ່ນອກຂອບເຂດ". AI ຍັງບໍ່ມີແນວຄິດກ່ຽວກັບຄວາມສຳຄັນ, ອາດຈະຈັດຕັ້ງປະຕິບັດສາມຄຸນສົມບັດເພີ່ມເຕີມພ້ອມກັນ, ເຮັດໃຫ້ຟັງຊັນຫຼັກຖືກປິດບັງ. ພ້ອມກັນນັ້ນ, ແຕ່ລະຄັ້ງທີ່ແກ້ໄຂ bug ໃໝ່, AI ຈະບໍ່ທົບທວນຟັງຊັນເກົ່າ, ມັກເກີດບັນຫາການຖົດຖອຍທີ່ແກ້ A ແຕ່ທຳລາຍ B. ສະຫຼຸບໄດ້ດັ່ງນີ້:

1. ການຂະຫຍາຍຂອບເຂດ: AI ເພື່ອ "ເຮັດໃຫ້ຜູ້ໃຊ້ພໍໃຈ", ຈະເພີ່ມຟັງຊັນທີ່ເບິ່ງຄືວ່າກ່ຽວຂ້ອງແຕ່ບໍ່ຈຳເປັນ (ເຊັ່ນ ເຄື່ອງຄິດໄລ່ເພີ່ມປະຫວັດການໃຊ້ງານ).
2. ການຖົດຖອຍຂອງຄຸນສົມບັດ: AI ເມື່ອແກ້ໄຂ bug ໃດໜຶ່ງ, ເພາະບໍ່ເຂົ້າໃຈໂລຈິກທັງໝົດ, ດັດແປງຟັງຊັນສາທາລະນະ, ເຮັດໃຫ້ຟັງຊັນອື່ນທີ່ອາໄສມັນເຮັດວຽກຜິດປົກກະຕິ.

ຫ້າ. ຂຸມຄຸກດ້ານການຮ່ວມມືຂອງທີມ

ຂະບວນການສົນທະນາຂອງ Vibe Coding ແມ່ນ ການໂຕ້ຕອບສ່ວນຕົວລະຫວ່າງບຸກຄົນ ແລະ AI, ບໍ່ມີເອກະສານສະເພາະ ຫຼື ບັນທຶກການຕັດສິນໃຈອອກແບບທີ່ຖ່າຍທອດໄດ້. ສະມາຊິກທີມແຕກຕ່າງກັນສົນທະນາກັບ AI ແຍກຕ່າງຫາກ, ໄດ້ຮັບລະຫັດທີ່ມີຮູບແບບຕ່າງກັນ, ເມື່ອລວມກັນກໍ່ເກີດຂໍ້ຂັດແຍ່ງຫຼາຍ. ນອກຈາກນັ້ນ, AI ຈະບໍ່ສ້າງ commit message ຫຼື ບັນທຶກການປ່ຽນແປງໂດຍອັດຕະໂນມັດ, ເຫດຜົນຂອງການພັດທະນາລະຫັດຫາຍໄປ, ຜູ້ຮັກສາໃນພາຍຫຼັງຕ້ອງຄາດເດົາເທົ່ານັ້ນ. ສະຫຼຸບໄດ້ດັ່ງນີ້:

1. ການສ້າງທີ່ບໍ່ສາມາດສ້າງຄືນໄດ້: ຄົນຕ່າງກັນ, ເວລາຕ່າງກັນໃຊ້ prompt ດຽວກັນ, AI ຈະສ້າງການຈັດຕັ້ງປະຕິບັດແຕກຕ່າງກັນ (ເພາະຄວາມສຸ່ມໃນການສຳມະນາ).
2. ຂາດການຕິດຕາມການປ່ຽນແປງ: ບໍ່ມີເອກະສານອອກແບບ, ບໍ່ມີ commit message ທີ່ອະທິບາຍວ່າ "ເປັນຫຍັງຈຶ່ງປ່ຽນແບບນີ້", ລະຫັດກາຍເປັນກ່ອງດຳ.