ລະຫັດ AI ມີລັກສະນະແນວໃດ? [ວິດີໂອ ແລະ ແບບທົດສອບ]

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

ບົດຮຽນຫຼັກ:

ການກວດສອບບໍລິບົດ: ຖ້າຄຳສັບຂອງໂດເມນ, ຮູບຮ່າງຂໍ້ມູນ ແລະ ຂໍ້ຈຳກັດບໍ່ໄດ້ສະທ້ອນໃຫ້ເຫັນ, ໃຫ້ຖືວ່າມັນມີຄວາມສ່ຽງ.

ຂັດເງົາຫຼາຍເກີນໄປ: ເອກະສານທີ່ຫຼາຍເກີນໄປ, ໂຄງສ້າງທີ່ເປັນເອກະພາບ, ແລະຊື່ທີ່ບໍ່ມີປະໂຫຍດສາມາດເປັນສັນຍານຂອງການສ້າງແບບທົ່ວໄປໄດ້.

ລະບຽບວິໄນຂອງຂໍ້ຜິດພາດ: ລະວັງການກວດພົບຂໍ້ຍົກເວັ້ນຢ່າງກວ້າງຂວາງ, ຄວາມລົ້ມເຫຼວທີ່ຖືກກືນກິນ, ແລະ ການບັນທຶກທີ່ບໍ່ຊັດເຈນ.

ການຕັດແບບ Abstraction: ລຶບຕົວຊ່ວຍ ແລະ ຊັ້ນຂໍ້ມູນທີ່ສາມາດຄາດເດົາໄດ້ຈົນກວ່າຈະເຫຼືອພຽງແຕ່ລຸ້ນທີ່ຖືກຕ້ອງທີ່ນ້ອຍທີ່ສຸດເທົ່ານັ້ນ.

ການທົດສອບຄວາມເປັນຈິງ: ເພີ່ມການເຊື່ອມໂຍງ ແລະ ການທົດສອບກໍລະນີຂອບ; ພວກມັນເປີດເຜີຍສົມມຸດຕິຖານ “ໂລກທີ່ສະອາດ” ຢ່າງວ່ອງໄວ.

ການຂຽນໂປຣແກຣມດ້ວຍ AI ມີຢູ່ທົ່ວທຸກແຫ່ງໃນປັດຈຸບັນ (ການສຳຫຼວດນັກພັດທະນາ Stack Overflow 2025; GitHub Octoverse (28 ຕຸລາ 2025)). ບາງຄັ້ງມັນກໍ່ດີເລີດ ແລະ ຊ່ວຍປະຢັດເວລາໃຫ້ທ່ານໄດ້ໃນຕອນບ່າຍ. ບາງຄັ້ງມັນກໍ່... ປັບປຸງໃຫ້ດີຂຶ້ນຢ່າງໜ້າສົງໄສ, ເປັນເລື່ອງທຳມະດາເລັກນ້ອຍ, ຫຼື ມັນ "ເຮັດວຽກ" ຈົນກວ່າຈະມີຄົນຄລິກປຸ່ມດຽວທີ່ບໍ່ມີໃຜທົດສອບ 🙃. ນັ້ນນຳໄປສູ່ຄຳຖາມທີ່ຜູ້ຄົນຍົກຂຶ້ນມາໃນການທົບທວນລະຫັດ, ການສຳພາດ ແລະ DM ສ່ວນຕົວ:

ລະຫັດ AI ມັກຈະມີລັກສະນະແນວໃດ

ຄຳຕອບໂດຍກົງແມ່ນ: ມັນສາມາດເບິ່ງຄືກັບຫຍັງກໍໄດ້. ແຕ່ມີຮູບແບບ - ສັນຍານອ່ອນໆ, ບໍ່ແມ່ນຫຼັກຖານໃນສານ. ລອງຄິດເບິ່ງຄືກັບການຄາດເດົາວ່າເຄັກມາຈາກຮ້ານເຂົ້າຈີ່ ຫຼື ເຮືອນຄົວຂອງໃຜຜູ້ໜຶ່ງ. ນ້ຳຕານເຄືອບອາດຈະສົມບູນແບບເກີນໄປ, ແຕ່ຮ້ານເຂົ້າຈີ່ຢູ່ເຮືອນບາງຄົນກໍ່ແຊບຫຼາຍ. ຄວາມຮູ້ສຶກຄືກັນ.

ຂ້າງລຸ່ມນີ້ແມ່ນຄູ່ມືປະຕິບັດສຳລັບການຮັບຮູ້ລາຍນິ້ວມື AI ທົ່ວໄປ, ການເຂົ້າໃຈວ່າເປັນຫຍັງພວກມັນຈຶ່ງເກີດຂຶ້ນ, ແລະ - ທີ່ສຳຄັນ - ວິທີການປ່ຽນລະຫັດທີ່ສ້າງຂຶ້ນໂດຍ AI ເປັນລະຫັດທີ່ທ່ານຈະໄວ້ວາງໃຈໃນການຜະລິດ ✅.

🔗 AI ຄາດຄະເນແນວໂນ້ມແນວໃດ?
ອະທິບາຍການຮຽນຮູ້ຮູບແບບ, ສັນຍານ ແລະ ການຄາດຄະເນໃນການນຳໃຊ້ຕົວຈິງ.

🔗 AI ກວດຫາຄວາມຜິດປົກກະຕິໄດ້ແນວໃດ?
ກວມເອົາວິທີການກວດຫາຄ່າຜິດປົກກະຕິ ແລະ ແອັບພລິເຄຊັນທາງທຸລະກິດທົ່ວໄປ.

🔗 AI ໃຊ້ນ້ໍາຫຼາຍປານໃດ?
ແບ່ງແຍກຜົນກະທົບຕໍ່ການໃຊ້ນໍ້າ ແລະ ການຝຶກອົບຮົມໃນສູນຂໍ້ມູນ.

🔗 ຄວາມລຳອຽງຂອງ AI ແມ່ນຫຍັງ?
ກຳນົດແຫຼ່ງທີ່ມາຂອງອະຄະຕິ, ອັນຕະລາຍ ແລະ ວິທີການປະຕິບັດໄດ້ເພື່ອຫຼຸດຜ່ອນຄວາມລຳອຽງ.

1) ກ່ອນອື່ນໝົດ, ຄົນເຮົາໝາຍຄວາມວ່າແນວໃດເມື່ອເຂົາເຈົ້າເວົ້າວ່າ “ລະຫັດ AI” 🤔

ເມື່ອຄົນສ່ວນໃຫຍ່ເວົ້າວ່າ "ລະຫັດ AI", ເຂົາເຈົ້າມັກຈະໝາຍເຖິງໜຶ່ງໃນນີ້:

• ລະຫັດທີ່ຮ່າງໂດຍຜູ້ຊ່ວຍ AI ຈາກການກະຕຸ້ນ (ຄຸນສົມບັດ, ແກ້ໄຂຂໍ້ຜິດພາດ, ການປັບປຸງໂຄງສ້າງ).

• ລະຫັດຖືກເຕີມເຕັມໂດຍການເຕີມເຕັມອັດຕະໂນມັດ, ບ່ອນທີ່ນັກພັດທະນາໄດ້ກະຕຸ້ນແຕ່ບໍ່ໄດ້ຂຽນຢ່າງຄົບຖ້ວນ.

• ລະຫັດທີ່ຂຽນຄືນໃໝ່ໂດຍ AI ສຳລັບ “ການເຮັດຄວາມສະອາດ,” “ປະສິດທິພາບ,” ຫຼື “ແບບ.”

• ລະຫັດທີ່ເບິ່ງຄືວ່າມັນມາຈາກ AI ເຖິງແມ່ນວ່າມັນຈະບໍ່ແມ່ນກໍຕາມ (ເລື່ອງນີ້ເກີດຂຶ້ນຫຼາຍກວ່າທີ່ຄົນຍອມຮັບ).

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

2) ລະຫັດ AI ມັກຈະມີລັກສະນະແນວໃດ: ຮູບພາບສັ້ນໆບອກໄດ້ 👀

ຂໍໃຫ້ຕອບຫົວຂໍ້ຂ່າວຢ່າງຈະແຈ້ງ: ລະຫັດ AI ມັກຈະມີລັກສະນະແນວໃດ.

ມັນມັກຈະເບິ່ງຄືວ່າລະຫັດທີ່ເປັນ:

• “ປຶ້ມແບບຮຽນເປັນລະບຽບ” ຫຼາຍ - ການຫຍໍ້ໜ້າຢ່າງຕໍ່ເນື່ອງ, ຮູບແບບທີ່ສອດຄ່ອງກັນ, ທຸກຢ່າງສອດຄ່ອງກັນ.

• ຫຼາຍເກີນໄປໃນແບບທີ່ເປັນກາງ - ຄຳເຫັນທີ່ "ເປັນປະໂຫຍດ" ຫຼາຍຢ່າງທີ່ບໍ່ໄດ້ຊ່ວຍຫຍັງຫຼາຍ.

• ໂດຍທົ່ວໄປເກີນໄປ - ສ້າງຂຶ້ນເພື່ອຈັດການກັບສະຖານະການທີ່ຈິນຕະນາການໄວ້ສິບຢ່າງແທນທີ່ຈະເປັນສອງສະຖານະການທີ່ແທ້ຈິງ.

• ມີໂຄງສ້າງຫຼາຍເກີນໄປເລັກນ້ອຍ - ໜ້າທີ່ຊ່ວຍເຫຼືອເພີ່ມເຕີມ, ຊັ້ນເພີ່ມເຕີມ, ຄວາມເປັນນາມທຳເພີ່ມເຕີມ... ເຊັ່ນ: ການຫຸ້ມຫໍ່ສຳລັບການເດີນທາງໃນທ້າຍອາທິດດ້ວຍກະເປົ໋າເດີນທາງສາມໃບ 🧳.

• ພາດກາວຕິດຂອບທີ່ງຸ່ມງ່າມ ທີ່ລະບົບຕົວຈິງສະສົມໄວ້ (ທຸງຄຸນສົມບັດ, ຄວາມແປກປະຫຼາດແບບດັ້ງເດີມ, ຂໍ້ຈຳກັດທີ່ບໍ່ສະດວກ) (Martin Fowler: ປຸ່ມສະຫຼັບຄຸນສົມບັດ).

ແຕ່ຍັງ - ແລະຂ້ອຍຈະສືບຕໍ່ເວົ້າຊ້ຳອີກເພາະມັນມີຄວາມສຳຄັນ - ນັກພັດທະນາມະນຸດສາມາດຂຽນແບບນີ້ໄດ້ຄືກັນ. ບາງທີມບັງຄັບໃຊ້ມັນ. ບາງຄົນກໍ່ເປັນພຽງແຕ່ຄົນແປກປະຫຼາດ. ຂ້ອຍເວົ້າແບບນັ້ນດ້ວຍຄວາມຮັກ 😅.

ສະນັ້ນແທນທີ່ຈະ "ກວດພົບ AI", ມັນດີກວ່າທີ່ຈະຖາມວ່າ: ລະຫັດນີ້ມີລັກສະນະຄືກັບວ່າມັນຖືກຂຽນດ້ວຍສະພາບການທີ່ແທ້ຈິງບໍ? ສະພາບການແມ່ນບ່ອນທີ່ AI ມັກຈະຜິດພາດ.

3) ປ້າຍ “ຮ່ອມພູທີ່ແປກປະຫຼາດ” - ເມື່ອມັນ ເກີນໄປ 😬

ລະຫັດທີ່ສ້າງຂຶ້ນໂດຍ AI ມັກຈະມີ "ຄວາມເງົາງາມ" ທີ່ແນ່ນອນ. ບໍ່ແມ່ນສະເໝີໄປ, ແຕ່ເລື້ອຍໆ.

ສັນຍານທົ່ວໄປ “ສະອາດເກີນໄປ”

• ທຸກໆຟັງຊັນມີ docstring ເຖິງແມ່ນວ່າມັນຈະຊັດເຈນກໍຕາມ.

• ຕົວແປທັງໝົດມີຊື່ທີ່ສຸພາບ ເຊັ່ນ: result, data, items, payload, responseData.

• ຂໍ້ຄວາມຜິດພາດທີ່ສອດຄ່ອງກັນ ເຊິ່ງຟັງຄືກັບຄູ່ມື: "ເກີດຄວາມຜິດພາດໃນຂະນະທີ່ປະມວນຜົນຄຳຮ້ອງຂໍ."

• ຮູບແບບທີ່ເປັນເອກະພາບໃນທົ່ວໂມດູນທີ່ບໍ່ກ່ຽວຂ້ອງກັນ, ຄືກັບທຸກຢ່າງຖືກຂຽນໂດຍບັນນາລັກທີ່ລະມັດລະວັງຄົນດຽວກັນ.

ການແຈກຂອງທີ່ລະອຽດອ່ອນ

ລະຫັດ AI ສາມາດຮູ້ສຶກຄືກັບວ່າມັນຖືກອອກແບບມາສຳລັບການສອນ, ບໍ່ແມ່ນຜະລິດຕະພັນ. ມັນຄືກັບ... ໃສ່ຊຸດເພື່ອທາສີຮົ້ວ. ກິດຈະກຳທີ່ເໝາະສົມຫຼາຍ, ຜິດພາດເລັກນ້ອຍສຳລັບຊຸດ.

4) ລະຫັດ AI ລຸ້ນໃດດີ? ✅

ລອງປ່ຽນເບິ່ງ. ເພາະວ່າເປົ້າໝາຍບໍ່ແມ່ນ "ຈັບ AI," ແຕ່ມັນແມ່ນ "ຄຸນນະພາບຂອງເຮືອ."

ລະຫັດທີ່ຊ່ວຍເຫຼືອດ້ວຍ AI ລຸ້ນ ທີ່ດີ ແມ່ນ:

• ຍຶດຕິດຢູ່ໃນໂດເມນທີ່ແທ້ຈິງຂອງເຈົ້າ (ການຕັ້ງຊື່, ຮູບຮ່າງຂໍ້ມູນຂອງທ່ານ, ຂໍ້ຈຳກັດຂອງເຈົ້າ).

• ສອດຄ່ອງກັບສະຖາປັດຕະຍະກຳຂອງທ່ານ (ຮູບແບບກົງກັບ repo, ບໍ່ແມ່ນແມ່ແບບທົ່ວໄປ).

• ໄດ້ຮັບການທົດສອບຕໍ່ກັບຄວາມສ່ຽງຂອງທ່ານ (ບໍ່ພຽງແຕ່ການທົດສອບຫົວໜ່ວຍເສັ້ນທາງແຫ່ງຄວາມສຸກເທົ່ານັ້ນ) (ວິສະວະກຳຊອບແວທີ່ Google: ການທົດສອບຫົວໜ່ວຍ; ປີຣາມິດການທົດສອບປະຕິບັດ).

• ກວດສອບດ້ວຍຄວາມຕັ້ງໃຈ (ມີຄົນຖາມວ່າ "ເປັນຫຍັງຈຶ່ງເປັນແບບນີ້?" ບໍ່ພຽງແຕ່ "ມັນລວບລວມໄດ້ຫຼືບໍ່") (ການປະຕິບັດດ້ານວິສະວະກຳຂອງ Google: ມາດຕະຖານການທົບທວນລະຫັດ).

• ຕັດລົງມາ ໃຫ້ເຫຼືອແຕ່ສິ່ງທີ່ທ່ານຕ້ອງການ (ຫຼຸດຜ່ອນການຄາດເດົາອະນາຄົດ).

ເວົ້າອີກຢ່າງໜຶ່ງ, ລະຫັດ AI ທີ່ດີເບິ່ງຄືວ່າ... ທີມງານຂອງເຈົ້າຂຽນມັນ. ຫຼືຢ່າງໜ້ອຍ, ທີມງານຂອງເຈົ້າໄດ້ຮັບຮອງເອົາມັນຢ່າງຖືກຕ້ອງ. ຄືກັບໝາກູ້ໄພທີ່ຮູ້ວ່າໂຊຟາຢູ່ໃສ 🐶.

5) ຫໍສະໝຸດຮູບແບບ: ລາຍນິ້ວມື AI ແບບຄລາສສິກ (ແລະເຫດຜົນທີ່ມັນເກີດຂຶ້ນ) 🧩

ນີ້ແມ່ນຮູບແບບທີ່ຂ້ອຍໄດ້ເຫັນຊ້ຳແລ້ວຊ້ຳອີກໃນຖານຂໍ້ມູນລະຫັດທີ່ຊ່ວຍເຫຼືອໂດຍ AI - ລວມທັງຮູບແບບທີ່ຂ້ອຍໄດ້ເຮັດຄວາມສະອາດດ້ວຍຕົນເອງ. ບາງອັນແມ່ນດີ. ບາງອັນກໍ່ອັນຕະລາຍ. ສ່ວນໃຫຍ່ແມ່ນພຽງແຕ່... ສັນຍານ.

ກ) ການກວດສອບຄ່າ null ຫຼາຍເກີນໄປໃນການປ້ອງກັນທຸກບ່ອນ

ທ່ານຈະເຫັນຊັ້ນຕ່າງໆຂອງ:

• ຖ້າ x ບໍ່ມີ: ສົ່ງຄືນ ...

• ລອງ/ຍົກເວັ້ນ ຂໍ້ຍົກເວັ້ນ

• ຄ່າເລີ່ມຕົ້ນສຳຮອງຫຼາຍອັນ

ເຫດຜົນ: AI ພະຍາຍາມຫຼີກລ່ຽງຂໍ້ຜິດພາດໃນເວລາແລ່ນໂດຍທົ່ວໄປ.
ຄວາມສ່ຽງ: ມັນສາມາດຊ່ອນຄວາມລົ້ມເຫຼວທີ່ແທ້ຈິງ ແລະ ເຮັດໃຫ້ການແກ້ໄຂຂໍ້ຜິດພາດຮ້າຍແຮງ.

ຂ) ໜ້າທີ່ຊ່ວຍເຫຼືອທົ່ວໄປທີ່ບໍ່ໄດ້ຮັບຄວາມນິຍົມ

ຄື:

• ຂໍ້ມູນ_ຂະບວນການ()

• ການຮ້ອງຂໍຈັດການ()

• ຢືນຢັນການປ້ອນຂໍ້ມູນ

ເປັນຫຍັງ: ການສ້າງແບບບໍ່ມີຕົວຕົນຮູ້ສຶກວ່າ "ເປັນມືອາຊີບ".
ຄວາມສ່ຽງ: ສຸດທ້າຍເຈົ້າຈະໄດ້ໜ້າທີ່ທີ່ເຮັດທຸກຢ່າງ ແລະ ບໍ່ໄດ້ອະທິບາຍຫຍັງເລີຍ.

ຄ) ຄຳເຫັນທີ່ກ່າວຊ້ຳລະຫັດ

ຕົວຢ່າງພະລັງງານ:

• "ເພີ່ມຂຶ້ນ i ດ້ວຍ 1"

• "ສົ່ງຄຳຕອບຄືນ"

ເຫດຜົນ: AI ໄດ້ຮັບການຝຶກອົບຮົມໃຫ້ເປັນຜູ້ອະທິບາຍ.
ຄວາມສ່ຽງ: ຄຳເຫັນຈະເນົ່າເປື່ອຍໄວ ແລະ ສ້າງສຽງລົບກວນ.

ງ) ຄວາມເລິກຂອງລາຍລະອຽດທີ່ບໍ່ສອດຄ່ອງກັນ

ສ່ວນໜຶ່ງມີລາຍລະອຽດຫຼາຍ, ອີກສ່ວນໜຶ່ງມີລາຍລະອຽດທີ່ບໍ່ຊັດເຈນ.

ເຫດຜົນ: ການເລືອຄານໂຟກັສຢ່າງວ່ອງໄວ... ຫຼື ບໍລິບົດບາງສ່ວນ.
ຄວາມສ່ຽງ: ຈຸດອ່ອນຊ່ອນຢູ່ໃນເຂດທີ່ບໍ່ຊັດເຈນ.

ອ) ໂຄງສ້າງທີ່ສົມມາດຢ່າງໜ້າສົງໄສ

ທຸກສິ່ງທຸກຢ່າງເປັນໄປຕາມໂຄງກະດູກດຽວກັນ, ເຖິງແມ່ນວ່າເຫດຜົນທາງທຸລະກິດບໍ່ຄວນເປັນກໍຕາມ.

ເຫດຜົນ: AI ມັກເຮັດຮູບຊົງທີ່ພິສູດແລ້ວຊ້ຳໆ.
ຄວາມສ່ຽງ: ຄວາມຕ້ອງການບໍ່ສົມມາດ - ພວກມັນມີກ້ອນ, ຄືກັບເຄື່ອງຂອງທີ່ຫຸ້ມຫໍ່ບໍ່ດີ 🍅📦.

6) ຕາຕະລາງປຽບທຽບ - ວິທີການປະເມີນວ່າລະຫັດ AI ມັກຈະມີລັກສະນະແນວໃດ 🧪

ຂ້າງລຸ່ມນີ້ແມ່ນການປຽບທຽບຊຸດເຄື່ອງມືທີ່ໃຊ້ໄດ້ຈິງ. ບໍ່ແມ່ນ "ເຄື່ອງກວດຈັບ AI," ຄ້າຍຄືກັບ ການກວດສອບຄວາມເປັນຈິງຂອງລະຫັດ. ເພາະວ່າວິທີທີ່ດີທີ່ສຸດໃນການລະບຸລະຫັດທີ່ໜ້າສົງໄສແມ່ນການທົດສອບມັນ, ທົບທວນມັນ, ແລະສັງເກດມັນພາຍໃຕ້ຄວາມກົດດັນ.

ແມ່ນແລ້ວ ຖັນ "ລາຄາ" ມັນໂງ່ໜ້ອຍໜຶ່ງ - ເພາະວ່າສ່ວນທີ່ແພງມັກຈະແມ່ນຄວາມສົນໃຈ, ບໍ່ແມ່ນເຄື່ອງມື. ການເອົາໃຈໃສ່ມີຄ່າໃຊ້ຈ່າຍ... ທຸກຢ່າງ 😵💫.

7) ຕົວຊີ້ບອກໂຄງສ້າງໃນລະຫັດທີ່ຊ່ວຍເຫຼືອໂດຍ AI 🧱

ຖ້າທ່ານຕ້ອງການຄຳຕອບທີ່ເລິກເຊິ່ງກວ່າກ່ຽວກັບວ່າລະຫັດ AI ມັກຈະເປັນແນວໃດ, ໃຫ້ຊູມອອກ ແລະ ເບິ່ງໂຄງສ້າງ.

1) ການຕັ້ງຊື່ທີ່ຖືກຕ້ອງທາງດ້ານເຕັກນິກແຕ່ຜິດທາງດ້ານວັດທະນະທໍາ

AI ມັກຈະເລືອກຊື່ທີ່ "ປອດໄພ" ໃນຫຼາຍໆໂຄງການ. ແຕ່ທີມງານພັດທະນາພາສາຂອງຕົນເອງ:

• ເຈົ້າເອີ້ນມັນ ວ່າ AccountId, AI ເອີ້ນມັນ ວ່າ userId.

• ເຈົ້າເອີ້ນມັນວ່າ LedgerEntry, AI ເອີ້ນມັນວ່າ transaction.

• ເຈົ້າເອີ້ນມັນວ່າ FeatureGate, ມັນເອີ້ນມັນວ່າ configFlag.

ບໍ່ມີສິ່ງໃດໃນນີ້ທີ່ "ບໍ່ດີ", ແຕ່ມັນເປັນການບອກໃບ້ວ່າຜູ້ຂຽນບໍ່ໄດ້ອາໄສຢູ່ພາຍໃນໂດເມນຂອງເຈົ້າດົນນານ.

2) ການເຮັດຊ້ຳໂດຍບໍ່ໃຊ້ຄືນ, ຫຼື ການນຳໃຊ້ຄືນໂດຍບໍ່ມີເຫດຜົນ

ບາງຄັ້ງ AI:

• ເຮັດຊ້ຳເຫດຜົນທີ່ຄ້າຍຄືກັນໃນຫຼາຍບ່ອນ ເພາະມັນບໍ່ "ຈື່" ບໍລິບົດ repo ທັງໝົດໃນຄັ້ງດຽວ, ຫຼື

• ບັງຄັບໃຫ້ໃຊ້ຄືນຜ່ານການຖອດລະຫັດທີ່ຊ່ວຍປະຢັດສາມແຖວແຕ່ມີຄ່າໃຊ້ຈ່າຍສາມຊົ່ວໂມງຕໍ່ມາ.

ນັ້ນແມ່ນການແລກປ່ຽນ: ພິມໜ້ອຍລົງດຽວນີ້, ຄິດຫຼາຍຂຶ້ນພາຍຫຼັງ. ແລະຂ້ອຍບໍ່ແນ່ໃຈວ່ານັ້ນເປັນການແລກປ່ຽນທີ່ດີສະເໝີໄປ, ຂ້ອຍຄິດວ່າ... ຂຶ້ນກັບອາທິດ 😮💨.

3) ໂມດູນ "ສົມບູນແບບ" ທີ່ບໍ່ສົນໃຈຂອບເຂດທີ່ແທ້ຈິງ

ທ່ານຈະເຫັນລະຫັດແບ່ງອອກເປັນໂມດູນທີ່ເປັນລະບຽບຮຽບຮ້ອຍ:

• ຕົວກວດສອບຄວາມຖືກຕ້ອງ/

• ການບໍລິການ/

• ຜູ້ຈັດການ/

• ສິ່ງອຳນວຍຄວາມສະດວກ/

ແຕ່ຂອບເຂດອາດຈະບໍ່ກົງກັບຮອຍຕໍ່ຂອງລະບົບຂອງທ່ານ. ມະນຸດມັກຈະສະທ້ອນຈຸດເຈັບປວດຂອງສະຖາປັດຕະຍະກຳ. AI ມັກຈະສະທ້ອນແຜນວາດທີ່ເປັນລະບຽບຮຽບຮ້ອຍ.

8) ການຈັດການຂໍ້ຜິດພາດ - ບ່ອນທີ່ລະຫັດ AI ລື່ນໄຫຼ 🧼

ການຈັດການຂໍ້ຜິດພາດແມ່ນໜຶ່ງໃນບັນຫາໃຫຍ່ທີ່ສຸດ, ເພາະມັນຕ້ອງການ ການວິພາກວິຈານ, ບໍ່ພຽງແຕ່ຄວາມຖືກຕ້ອງເທົ່ານັ້ນ.

ຮູບແບບທີ່ຄວນເບິ່ງ

• ການຈັບຂໍ້ຍົກເວັ້ນທົ່ວໄປ ດ້ວຍການບັນທຶກທີ່ບໍ່ຊັດເຈນ (ເອກະສານ Pylint: bare-except)

• ການກືນກິນຂໍ້ຜິດພາດ ແລະ ການສົ່ງຄືນຄ່າເລີ່ມຕົ້ນ

• ການສົ່ງຄືນ “ຄວາມສຳເລັດ: ບໍ່ຖືກຕ້ອງ” ແທນທີ່ຈະຍົກເອົາຄວາມລົ້ມເຫຼວທີ່ມີຄວາມໝາຍຂຶ້ນມາ

• ລອງຊ້ຳອີກຄັ້ງ ໂດຍບໍ່ມີການ backoff ຫຼືບໍ່ມີການຈຳກັດ (ຫຼື ການຈຳກັດທີ່ຖືກເລືອກຢ່າງແປກປະຫຼາດເຊັ່ນ 3, ເພາະວ່າ 3 ຮູ້ສຶກດີ) (ຄຳແນະນຳຂອງ AWS: ລອງຊ້ຳອີກຄັ້ງດ້ວຍການ backoff; ຫ້ອງສະໝຸດ AWS Builders': ການໝົດເວລາ, ການລອງຊ້ຳ ແລະ ການຖອຍຫຼັງດ້ວຍການ jitter)

ສິ່ງທີ່ດີເບິ່ງຄືວ່າ

• ຄວາມລົ້ມເຫຼວແມ່ນ ສະເພາະ

• ຂໍ້ຜິດພາດສາ ມາດດຳເນີນການໄດ້

• ການບັນທຶກປະກອບມີ ສະພາບການ (ids, inputs, ສະຖານະທີ່ກ່ຽວຂ້ອງ)

• ຂໍ້ມູນທີ່ລະອຽດອ່ອນຈະ ບໍ່ ຖືກຖິ້ມລົງໃນບັນທຶກ (ບາງຄັ້ງ AI ກໍ່ລືມເລື່ອງນີ້ 😬) (ແຜ່ນຫຼອກລວງການບັນທຶກ OWASP; OWASP Top 10 2025: ການບັນທຶກຄວາມປອດໄພ ແລະ ຄວາມລົ້ມເຫຼວຂອງການແຈ້ງເຕືອນ)

ລັກສະນະຂອງມະນຸດຫຼາຍແມ່ນການຂຽນຂໍ້ຄວາມຜິດພາດທີ່ໜ້າລຳຄານເລັກນ້ອຍ. ບໍ່ແມ່ນສະເໝີໄປ, ແຕ່ທ່ານຈະຮູ້ມັນເມື່ອທ່ານເຫັນມັນ. ຂໍ້ຄວາມຜິດພາດຂອງ AI ມັກຈະສະຫງົບຄືກັບແອັບຯສະມາທິ.

9) ກໍລະນີຂອບ ແລະ ຄວາມເປັນຈິງຂອງຜະລິດຕະພັນ - “ຄວາມແຂງແກ່ນທີ່ຂາດຫາຍໄປ” 🧠🪤

ລະບົບຕົວຈິງແມ່ນບໍ່ເປັນລະບຽບ. ຜົນຜະລິດຂອງ AI ມັກຈະຂາດໂຄງສ້າງນັ້ນ.

ຕົວຢ່າງຂອງ “ຄວາມອົດທົນ” ທີ່ທີມມີ:

• ທຸງຄຸນສົມບັດ ແລະ ການເປີດຕົວບາງສ່ວນ (Martin Fowler: ປຸ່ມສະຫຼັບຄຸນສົມບັດ)

• ເຄັດລັບຄວາມເຂົ້າກັນໄດ້ຍ້ອນຫຼັງ

• ການໝົດເວລາຂອງພາກສ່ວນທີສາມທີ່ແປກປະຫຼາດ

• ຂໍ້ມູນເກົ່າທີ່ລະເມີດໂຄງຮ່າງຂອງທ່ານ

• ບັນຫາກ່ຽວກັບຕົວພິມໃຫຍ່, ການເຂົ້າລະຫັດ ຫຼື ທ້ອງຖິ່ນທີ່ບໍ່ສອດຄ່ອງກັນ

• ກົດລະບຽບທາງທຸລະກິດທີ່ຮູ້ສຶກວ່າເປັນໄປຕາມອຳເພີໃຈ ເພາະມັນເປັນໄປຕາມອຳເພີໃຈ

ປັນຍາປະດິດສາມາດຈັດການກັບກໍລະນີຂອບໄດ້ຖ້າທ່ານບອກມັນ, ແຕ່ຖ້າທ່ານບໍ່ໄດ້ລວມເອົາພວກມັນຢ່າງຊັດເຈນ, ມັນມັກຈະສ້າງວິທີແກ້ໄຂ "ໂລກທີ່ສະອາດ". ໂລກທີ່ສະອາດແມ່ນໜ້າຮັກ. ໂລກທີ່ສະອາດກໍ່ບໍ່ມີຢູ່ຈິງເຊັ່ນກັນ.

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

10) ວິທີເຮັດໃຫ້ລະຫັດທີ່ຊ່ວຍດ້ວຍ AI ຮູ້ສຶກຄືກັບມະນຸດ - ແລະທີ່ສຳຄັນກວ່ານັ້ນ, ຕ້ອງເຊື່ອຖືໄດ້ 🛠️✨

ຖ້າທ່ານກຳລັງໃຊ້ AI ເພື່ອຮ່າງລະຫັດ (ແລະຫຼາຍຄົນກໍ່ເຮັດແບບນັ້ນ), ທ່ານສາມາດເຮັດໃຫ້ຜົນຜະລິດດີຂຶ້ນຢ່າງຫຼວງຫຼາຍດ້ວຍນິໄສບາງຢ່າງ.

ກ) ໃສ່ຂໍ້ຈຳກັດຂອງທ່ານໄວ້ທາງໜ້າ

ແທນທີ່ຈະໃຊ້ “ຂຽນຟັງຊັນທີ່…”, ລອງໃຊ້:

• ການປ້ອນຂໍ້ມູນ/ຜົນຜະລິດທີ່ຄາດໄວ້

• ຄວາມຕ້ອງການດ້ານປະສິດທິພາບ

• ນະໂຍບາຍຄວາມຜິດພາດ (ເພີ່ມຂຶ້ນ, ສົ່ງຄືນປະເພດຜົນໄດ້ຮັບ, ບັນທຶກ + ລົ້ມເຫຼວ?)

• ສົນທິສັນຍາການຕັ້ງຊື່

• ຮູບແບບທີ່ມີຢູ່ໃນ repo ຂອງທ່ານ

ຂ) ຂໍການແລກປ່ຽນ, ບໍ່ພຽງແຕ່ວິທີແກ້ໄຂເທົ່ານັ້ນ

ກະຕຸ້ນດ້ວຍ:

• "ໃຫ້ສອງວິທີການ ແລະ ອະທິບາຍການແລກປ່ຽນ."

• "ເຈົ້າຈະຫຼີກລ່ຽງການເຮັດຫຍັງຢູ່ທີ່ນີ້ ແລະ ເປັນຫຍັງ?"

• "ການຜະລິດນີ້ຈະຢຸດຢູ່ໃສ?"

AI ຈະດີກວ່າເມື່ອເຈົ້າບັງຄັບໃຫ້ມັນຄິດໃນຄວາມສ່ຽງ.

ຄ) ເຮັດໃຫ້ມັນລຶບລະຫັດ

ເອົາຈິງເອົາຈັງ. ຖາມ:

• "ກຳຈັດສິ່ງທີ່ບໍ່ຈຳເປັນອອກ."

• "ຕັດອັນນີ້ລົງໃຫ້ເປັນລຸ້ນທີ່ຖືກຕ້ອງທີ່ນ້ອຍທີ່ສຸດ."

• "ສ່ວນໃດແດ່ທີ່ເປັນການຄາດເດົາ?"

AI ມັກຈະເພີ່ມ. ວິສະວະກອນທີ່ຍິ່ງໃຫຍ່ມັກຈະຫັກລົບ.

ງ) ຕື່ມການທົດສອບທີ່ສະທ້ອນເຖິງຄວາມເປັນຈິງ

ບໍ່ພຽງແຕ່:

• "ສົ່ງຄືນຜົນຜະລິດທີ່ຄາດໄວ້"

ແຕ່:

• ການປ້ອນຂໍ້ມູນແປກໆ

• ຊ່ອງຫວ່າງທີ່ຂາດຫາຍໄປ

• ການກະທຳພ້ອມໆກັນ

• ຄວາມລົ້ມເຫຼວບາງສ່ວນ

• ພຶດຕິກຳລະດັບການເຊື່ອມໂຍງ (ວິສະວະກຳຊອບແວທີ່ Google: ການທົດສອບທີ່ໃຫຍ່ກວ່າ; ພີຣາມິດການທົດສອບປະຕິບັດ)

ຖ້າເຈົ້າບໍ່ເຮັດຫຍັງອີກ, ໃຫ້ເຮັດແບບນີ້. ການທົດສອບຄືເຄື່ອງກວດຈັບການຕົວະ, ແລະພວກມັນບໍ່ສົນໃຈວ່າໃຜຂຽນລະຫັດ 😌.

11) ບັນທຶກສະຫຼຸບ + ສະຫຼຸບໂດຍຫຍໍ້ 🎯

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

ສະຫຼຸບໂດຍຫຍໍ້

• ລະຫັດ AI ບໍ່ແມ່ນແບບດຽວ, ແຕ່ມັນມັກຈະມີແນວໂນ້ມທີ່ເປັນລະບຽບຮຽບຮ້ອຍ, ລະອຽດ ແລະ ທົ່ວໄປເກີນໄປ.

• ສັນຍານທີ່ດີທີ່ສຸດແມ່ນວ່າລະຫັດສະທ້ອນໃຫ້ເຫັນເຖິງຂໍ້ຈຳກັດທີ່ແທ້ຈິງ ແລະ ຄວາມເຂັ້ມແຂງຂອງຜະລິດຕະພັນຂອງທ່ານຫຼືບໍ່.

• ຢ່າຫຼົງໄຫຼໃນການກວດຈັບ - ໃຫ້ຫຼົງໄຫຼໃນຄຸນນະພາບ: ການທົດສອບ, ການທົບທວນ, ຄວາມຊັດເຈນ, ແລະ ເຈດຕະນາ (ການປະຕິບັດວິສະວະກຳຂອງ Google: ການທົບທວນລະຫັດ; ວິສະວະກຳຊອບແວທີ່ Google: ການທົດສອບໜ່ວຍ).

• AI ກໍ່ດີໃນຮ່າງທຳອິດ. ແຕ່ມັນບໍ່ດີໃນຮ່າງສຸດທ້າຍ. ນັ້ນແມ່ນເກມທັງໝົດ.

ແລະ ຖ້າມີຄົນພະຍາຍາມເຮັດໃຫ້ເຈົ້າອັບອາຍທີ່ໃຊ້ AI, ເວົ້າແທ້ໆ... ບໍ່ສົນໃຈສຽງລົບກວນນັ້ນ. ພຽງແຕ່ສົ່ງລະຫັດທີ່ແຂງແກ່ນ. ລະຫັດທີ່ແຂງແກ່ນແມ່ນຄວາມຍືດຫຍຸ່ນພຽງຢ່າງດຽວທີ່ຍືນຍົງ 💪🙂.

ຕົວຢ່າງໃນໂລກຕົວຈິງ: ການທົບທວນການແກ້ໄຂຂໍ້ຜິດພາດຂອງການຈ່າຍເງິນທີ່ຮ່າງໂດຍ AI 🛒

ສະຖານະການ

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

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

ນັ້ນແມ່ນບ່ອນທີ່ລະຫັດທີ່ຊ່ວຍດ້ວຍ AI ຕ້ອງການແຮງກົດດັນໃນການຜະລິດ. ບັນຫາບໍ່ແມ່ນວ່າລະຫັດເບິ່ງຄືວ່າ "ຂຽນໂດຍ AI". ບັນຫາແມ່ນວ່າມັນສົມມຸດວ່າໂລກສະອາດບ່ອນທີ່ການໝົດເວລາໝາຍຄວາມວ່າ "ບໍ່ມີຫຍັງເກີດຂຶ້ນ".

ສິ່ງທີ່ຜູ້ຊ່ວຍຕ້ອງການ

ກ່ອນທີ່ຈະຂໍໃຫ້ AI ແກ້ໄຂຂໍ້ຜິດພາດ, ໃຫ້ບອກລາຍລະອຽດຢ່າງລະອຽດກ່ອນ:

• ຜູ້ໃຫ້ບໍລິການຈ່າຍເງິນສາມາດໝົດເວລາໄດ້ຫຼັງຈາກ 8 ວິນາທີ.

• ການໝົດເວລາບໍ່ໄດ້ພິສູດວ່າການສາກໄຟລົ້ມເຫຼວ.

• ການຈ່າຍເງິນແຕ່ລະຄັ້ງມີ orderId ແລະ idempotencyKey ທີ່ເປັນເອກະລັກ.

• repo ທີ່ມີຢູ່ແລ້ວໃຊ້ PaymentAttempt, ບໍ່ແມ່ນການເຮັດທຸລະກໍາ.

• ການຈ່າຍເງິນທີ່ລົ້ມເຫຼວຕ້ອງໄດ້ບັນທຶກໄວ້ດ້ວຍ orderId, providerRequestId ແລະ retryCount.

• ບໍ່ຄວນມີລາຍລະອຽດບັດ ຫຼື ຂໍ້ມູນສ່ວນຕົວປາກົດຢູ່ໃນບັນທຶກ.

• ການແກ້ໄຂຕ້ອງປະກອບມີການທົດສອບສຳລັບການຄລິກຊໍ້າກັນ, ການໝົດເວລາຂອງຜູ້ໃຫ້ບໍລິການ, ແລະ ຄວາມລົ້ມເຫຼວບາງສ່ວນ.

ຕົວຢ່າງຄຳແນະນຳ

ໃຊ້ຮູບແບບການບໍລິການຊຳລະເງິນທີ່ມີຢູ່ແລ້ວເພື່ອແກ້ໄຂຂໍ້ຜິດພາດການຮຽກເກັບເງິນສອງເທື່ອ. ຢ່າສ້າງຊຸດຫໍ່ລອງໃໝ່ທົ່ວໄປ ເວັ້ນເສຍແຕ່ວ່າມັນຈຳເປັນ. ປະຕິບັດຕໍ່ສະຖານະໝົດເວລາຂອງຜູ້ໃຫ້ບໍລິການຊຳລະເງິນເປັນສະຖານະທີ່ບໍ່ຮູ້ຈັກ, ບໍ່ແມ່ນການຈ່າຍເງິນທີ່ລົ້ມເຫຼວ. ໃຊ້ການຕັ້ງຊື່ PaymentAttempt ທີ່ມີຢູ່ແລ້ວ. ເພີ່ມການກວດສອບ idempotency ໂດຍໃຊ້ orderId ແລະ idempotencyKey. ລວມເອົາການທົດສອບສຳລັບ: ການຈ່າຍເງິນທີ່ສຳເລັດຄັ້ງໜຶ່ງ, ໝົດເວລາຕາມດ້ວຍການລອງໃໝ່, ການຄລິກປຸ່ມຊ້ຳກັນ, ຄວາມສຳເລັດຂອງຜູ້ໃຫ້ບໍລິການຫຼັງຈາກໝົດເວລາຂອງລູກຄ້າ, ແລະ providerRequestId ທີ່ຂາດຫາຍໄປ. ຮັກສາວິທີແກ້ໄຂໃຫ້ນ້ອຍທີ່ສຸດເທົ່າທີ່ຈະເປັນໄປໄດ້ ແລະ ອະທິບາຍບ່ອນທີ່ສິ່ງນີ້ຍັງສາມາດລົ້ມເຫຼວໄດ້ໃນການຜະລິດ.

ວິທີການທົດສອບມັນ

ຜູ້ກວດສອບສາມາດດໍາເນີນການກວດສອບງ່າຍໆຫ້າຢ່າງກ່ອນທີ່ຈະອະນຸມັດລະຫັດທີ່ຊ່ວຍເຫຼືອໂດຍ AI:

1. ສົ່ງຄຳຮ້ອງຂໍການຈ່າຍເງິນດຽວກັນສອງຄັ້ງດ້ວຍ idempotencyKey ດຽວກັນ.

2. ຈຳລອງການໝົດເວລາຂອງຜູ້ໃຫ້ບໍລິການບ່ອນທີ່ຜູ້ໃຫ້ບໍລິການຢືນຢັນຄວາມສຳເລັດໃນພາຍຫຼັງ.

3. ຈຳລອງການລອງໃໝ່ຫຼັງຈາກໝົດເວລາ ແລະ ຢືນຢັນວ່າບໍ່ມີການຮຽກເກັບເງິນຄັ້ງທີສອງຖືກສ້າງຂຶ້ນ.

4. ກວດສອບບັນທຶກເພື່ອຊອກຫາຊ່ອງຂໍ້ມູນການດີບັກທີ່ຖືກຕ້ອງໂດຍບໍ່ຮົ່ວໄຫຼຂໍ້ມູນທີ່ລະອຽດອ່ອນ.

5. ຂໍໃຫ້ຜູ້ຂຽນອະທິບາຍວ່າເປັນຫຍັງເຫດຜົນຂອງການລອງໃໝ່ຈຶ່ງຢູ່ໃນຊັ້ນນີ້ແທນທີ່ຈະເປັນໂປຣແກຣມທົ່ວໄປ.

ຮ່າງ AI ທີ່ອ່ອນແອອາດຈະຜ່ານເສັ້ນທາງທີ່ມີຄວາມສຸກໄດ້ ແຕ່ລົ້ມເຫຼວໃນກໍລະນີທີ່ມີການໝົດເວລາຕາມມາດ້ວຍຄວາມສຳເລັດ. ນັ້ນແມ່ນສົມມຸດຕິຖານ "ໂລກທີ່ສະອາດ" ທີ່ປາກົດຢູ່ໃນຮູບແບບການທົດສອບ.

ຜົນໄດ້ຮັບ

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

ຫຼັງຈາກເພີ່ມຂໍ້ຈຳກັດຂອງໂດເມນຂ້າງເທິງ, ຮ່າງທີ່ໄດ້ຮັບການປັບປຸງໄດ້ກວມເອົາທັງ 5 ກໍລະນີທົດສອບ ແລະ ຕ້ອງການຄຳເຫັນໃນການທົບທວນດ້ວຍຕົນເອງໜ້ອຍລົງ: 9 ຄຳເຫັນໃນຮ່າງທຳອິດ ທຽບກັບ 3 ຄຳເຫັນໃນຮ່າງທີ່ມີຂໍ້ຈຳກັດ. ເວລາທົບທວນ ແລະ ແກ້ໄຂທັງໝົດໄດ້ຫຼຸດລົງຈາກປະມານ 55 ນາທີ ເປັນ 32 ນາທີ.

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

ມີຫຍັງຜິດພາດໄດ້ແດ່

ຄວາມຜິດພາດທີ່ອັນຕະລາຍທີ່ສຸດແມ່ນການປ່ອຍໃຫ້ AI ປະຕິບັດຕໍ່ “ການໝົດເວລາ” ເປັນ “ຄວາມລົ້ມເຫຼວ”. ໃນລະບົບການຈ່າຍເງິນ, ການສົ່ງອີເມວ, ແພລດຟອມການຈອງ, ການອັບເດດສິນຄ້າຄົງຄັງ, ແລະວຽກພື້ນຫຼັງ, ການສົມມຸດຕິຖານນັ້ນສາມາດສ້າງການກະທຳທີ່ຊໍ້າຊ້ອນໄດ້.

ບັນຫາທົ່ວໄປອື່ນໆ:

• AI ປະດິດຄຳສັບໃໝ່ເຊັ່ນ: ການເຮັດທຸລະກຳ ເມື່ອ repo ໃຊ້ PaymentAttempt.

• ມັນຈັບຄວາມຜິດພາດທີ່ກວ້າງຂວາງ ແລະ ສົ່ງຄືນຂໍ້ຄວາມທີ່ເປັນມິດ ໃນຂະນະທີ່ເຊື່ອງຄວາມລົ້ມເຫຼວທີ່ຕິດພັນ.

• ມັນເພີ່ມຕົວຊ່ວຍລອງໃໝ່ທີ່ໃຊ້ຄືນໄດ້ທີ່ນັກພັດທະນາຄົນອື່ນໆອາດຈະຄັດລອກໄປໃສ່ສະຖານທີ່ທີ່ການລອງໃໝ່ບໍ່ປອດໄພ.

• ມັນບັນທຶກເນື້ອຫາຫຼາຍເກີນໄປ ແລະ ລວມມີຂໍ້ມູນທີ່ລະອຽດອ່ອນຂອງລູກຄ້າ ຫຼື ການຈ່າຍເງິນໂດຍບັງເອີນ.

• ມັນຂຽນການທົດສອບທີ່ພິສູດວ່າລະຫັດເຮັດວຽກໄດ້ພຽງແຕ່ເມື່ອທຸກໆການເພິ່ງພາອາໄສເຮັດວຽກຢ່າງສົມບູນ.

ເອົາໄປໃຊ້ຕົວຈິງ

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

ຄຳຖາມທີ່ຖືກຖາມເລື້ອຍໆ

ເຈົ້າຈະຮູ້ໄດ້ແນວໃດວ່າລະຫັດຖືກຂຽນໂດຍ AI?

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

ສັນຍານເຕືອນໄພທີ່ໃຫຍ່ທີ່ສຸດໃນການຈັດການຂໍ້ຜິດພາດທີ່ສ້າງຂຶ້ນໂດຍ AI ແມ່ນຫຍັງ?

ໃຫ້ລະວັງການຈັບຂໍ້ຍົກເວັ້ນຢ່າງກວ້າງຂວາງ (ຍົກເວັ້ນ Exception), ຄວາມລົ້ມເຫຼວທີ່ຖືກກືນກິນທີ່ສົ່ງຄືນຄ່າເລີ່ມຕົ້ນຢ່າງງຽບໆ, ແລະການບັນທຶກທີ່ບໍ່ຈະແຈ້ງເຊັ່ນ "ເກີດຄວາມຜິດພາດຂຶ້ນ." ຮູບແບບເຫຼົ່ານີ້ສາມາດເຊື່ອງຂໍ້ຜິດພາດທີ່ແທ້ຈິງ ແລະ ເຮັດໃຫ້ການແກ້ໄຂຂໍ້ຜິດພາດເປັນເລື່ອງທີ່ໜ້າລຳຄານ. ການຈັດການຄວາມຜິດພາດທີ່ເຂັ້ມແຂງແມ່ນມີຄວາມຊັດເຈນ, ສາມາດປະຕິບັດໄດ້, ແລະ ມີບໍລິບົດພຽງພໍ (ID, inputs, state) ໂດຍບໍ່ຕ້ອງຖິ້ມຂໍ້ມູນທີ່ລະອຽດອ່ອນໃສ່ໃນບັນທຶກ. ການປ້ອງກັນຫຼາຍເກີນໄປສາມາດມີຄວາມສ່ຽງເທົ່າກັບການປ້ອງກັນທີ່ບໍ່ເໝາະສົມ.

ເປັນຫຍັງລະຫັດ AI ຈຶ່ງມັກຮູ້ສຶກວ່າຖືກວິສະວະກຳຫຼາຍເກີນໄປ ຫຼື ຖືກສະຫຼຸບຫຼາຍເກີນໄປ?

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

ລະຫັດທີ່ຊ່ວຍເຫຼືອດ້ວຍ AI ທີ່ດີມີລັກສະນະແນວໃດໃນ repo ທີ່ແທ້ຈິງ?

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

ການທົດສອບໃດທີ່ເປີດເຜີຍສົມມຸດຕິຖານ "ໂລກທີ່ສະອາດ" ໄວທີ່ສຸດ?

ການທົດສອບການລວມເຂົ້າ ແລະ ການທົດສອບກໍລະນີຂອບມັກຈະເປີດເຜີຍບັນຫາໄດ້ໄວ ເພາະວ່າຜົນຜະລິດຂອງ AI ມັກຈະສົມມຸດວ່າການປ້ອນຂໍ້ມູນທີ່ດີທີ່ສຸດ ແລະ ການເພິ່ງພາອາໄສທີ່ຄາດເດົາໄດ້. ໃຊ້ການຕິດຕັ້ງທີ່ເນັ້ນໃສ່ໂດເມນ ແລະ ລວມເອົາການປ້ອນຂໍ້ມູນແປກໆ, ຂໍ້ມູນທີ່ຂາດຫາຍໄປ, ຄວາມລົ້ມເຫຼວບາງສ່ວນ, ການໝົດເວລາ, ແລະ ການເຮັດວຽກພ້ອມກັນບ່ອນທີ່ມັນສຳຄັນ. ຖ້າລະຫັດມີພຽງແຕ່ການທົດສອບຫົວໜ່ວຍ happy-path, ມັນສາມາດເບິ່ງໄດ້ຢ່າງຖືກຕ້ອງໃນຂະນະທີ່ຍັງລົ້ມເຫຼວຢູ່ເມື່ອມີຄົນກົດປຸ່ມດຽວທີ່ຍັງບໍ່ໄດ້ທົດສອບໃນການຜະລິດ.

ເປັນຫຍັງຊື່ທີ່ຂຽນດ້ວຍ AI ຈຶ່ງຮູ້ສຶກວ່າ "ຖືກຕ້ອງທາງດ້ານເຕັກນິກແຕ່ຜິດທາງດ້ານວັດທະນະທໍາ"?

AI ມັກເລືອກຊື່ທົ່ວໄປທີ່ປອດໄພ ແລະ ເໝາະສົມກັບຫຼາຍໆໂຄງການ, ແຕ່ທີມງານພັດທະນາພາສາສະເພາະໃນໄລຍະເວລາ. ນັ້ນແມ່ນວິທີທີ່ເຈົ້າຈະພົບກັບຄວາມບໍ່ກົງກັນເຊັ່ນ userId ທຽບກັບ AccountId, ຫຼື transaction ທຽບ ກັບ LedgerEntry, ເຖິງແມ່ນວ່າເຫດຜົນຈະດີກໍຕາມ. ການຫຼົງໄຫຼໃນການຕັ້ງຊື່ນີ້ແມ່ນຕົວຊີ້ບອກວ່າລະຫັດບໍ່ໄດ້ຖືກຂຽນໃນຂະນະທີ່ "ຢູ່ພາຍໃນ" ໂດເມນ ແລະ ຂໍ້ຈຳກັດຂອງເຈົ້າ.

ມັນຄຸ້ມຄ່າບໍທີ່ຈະພະຍາຍາມກວດຫາລະຫັດ AI ໃນການທົບທວນລະຫັດ?

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

ເຈົ້າຈະກະຕຸ້ນ AI ແນວໃດເພື່ອໃຫ້ລະຫັດອອກມາໜ້າເຊື່ອຖືໄດ້ຫຼາຍຂຶ້ນ?

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

ເອກະສານອ້າງອີງ

1. Stack Overflow - ການສຳຫຼວດນັກພັດທະນາ Stack Overflow 2025 - survey.stackoverflow.co

2. GitHub - GitHub Octoverse (28 ຕຸລາ 2025) - github.blog

3. Google - ການປະຕິບັດດ້ານວິສະວະກຳຂອງ Google: ມາດຕະຖານການທົບທວນລະຫັດ - google.github.io

4. Abseil - ວິສະວະກໍາຊອບແວຢູ່ Google: ການທົດສອບຫນ່ວຍງານ - abseil.io

5. Abseil - ວິສະວະກຳຊອບແວທີ່ Google: ການທົບທວນລະຫັດ - abseil.io

6. Abseil - ວິສະວະກໍາຊອບແວຢູ່ Google: ການທົດສອບຂະຫນາດໃຫຍ່ - abseil.io

7. ມາຕິນ ຟາວເລີ - ມາຕິນ ຟາວເລີ: ປຸ່ມສະຫຼັບຄຸນສົມບັດ - martinfowler.com

8. ມາຕິນ ຟາວເລີ - ພີຣາມິດການທົດສອບຕົວຈິງ - martinfowler.com

9. OWASP - ສູດຄິດໄລ່ການສ້າງແບບຈຳລອງໄພຂົ່ມຂູ່ OWASP - cheatsheetseries.owasp.org

10. OWASP - ເອກະສານເຄັດລັບການບັນທຶກ OWASP - cheatsheetseries.owasp.org

11. OWASP - 10 ອັນດັບຕົ້ນໆຂອງ OWASP 2025: ການບັນທຶກຄວາມປອດໄພ ແລະ ຄວາມລົ້ມເຫຼວຂອງການແຈ້ງເຕືອນ - owasp.org

12. ESLint - ເອກະສານ ESLint - eslint.org

13. GitHub Docs - ການສະແກນລະຫັດ GitHub CodeQL - docs.github.com

14. TypeScript - TypeScript: ການກວດສອບປະເພດຄົງທີ່ - www.typescriptlang.org

15. mypy - ເອກະສານ mypy - mypy.readthedocs.io

16. Python - ເອກະສານ Python: ຕົວສ້າງໂປຣໄຟລ໌ Python - docs.python.org

17. pytest - ເອກະສານການຕິດຕັ້ງ pytest - docs.pytest.org

18. Pylint - ເອກະສານ Pylint: ຍົກເວັ້ນ - pylint.pycqa.org

19. Amazon Web Services - ຄຳແນະນຳກ່ຽວກັບ AWS: ລອງໃໝ່ດ້ວຍການຖອນຄືນ - docs.aws.amazon.com

20. Amazon Web Services - ຫ້ອງສະໝຸດ AWS Builders': ການໝົດເວລາ, ການລອງໃໝ່ ແລະ ການຖອຍຫຼັງກັບ jitter - aws.amazon.com

ຊອກຫາ AI ລ່າສຸດໄດ້ທີ່ຮ້ານ AI Assistant ຢ່າງເປັນທາງການ

ກ່ຽວກັບພວກເຮົາ