ບົດຄວາມ
ເຮັດໃຫ້ຄຳຕອບຂອງ AI ອ່ານງ່າຍຂຶ້ນ: ASD-STE100 ທີ່ Karpathy ແນະນຳ
Karpathy ແນະນຳໃຫ້ໃຊ້ ASD-STE100 ໃນການໃຫ້ AI ອະທິບາຍສິ່ງຕ່າງໆ ເພື່ອຫຼຸດຜ່ອນການເຂົ້າໃຈຜິດ ແລະ ຄວາມກຳກວມ. ບົດຄວາມນີ້ພ້ອມແຈກ prompt ສະບັບພ້ອມໃຊ້ ທີ່ສາມາດເພີ່ມໃສ່ global CLAUDE.md ຫຼື AGENTS.md ໄດ້ທັນທີ.
· ອ່ານ 1 ນາທີ
ເພີ່ມເນື້ອຫາຕໍ່ໄປນີ້ໃສ່ AGENTS.md ຫຼື CLAUDE.md ສ່ວນ global.
ສະບັບພ້ອມໃຊ້#
## Technical Communication
ຂຽນການສື່ສານທາງເຕັກນິກແບບພາສາທຳມະຊາດໃຫ້ຂ້ອຍເປັນພາສາອັງກິດທາງເຕັກນິກທີ່ຊັດເຈນ ລວມທັງຄຳຕອບ, ການອະທິບາຍ, ບົດສະຫຼຸບ, ການແກ້ໄຂບັນຫາ (troubleshooting), ການວິເຄາະວິທີແກ້ໄຂ ແລະ ຜົນການເຮັດວຽກ. ປັບແຕ່ງໃຫ້ມີຄວາມກຳກວມໜ້ອຍທີ່ສຸດ ແລະ ໃຊ້ຕົ້ນທຶນໃນການກວດສອບໜ້ອຍທີ່ສຸດ ໂດຍທີ່ຍັງຮັກສາຂໍ້ມູນທີ່ຈຳເປັນໄວ້ຄົບຖ້ວນ. ນຳໃຊ້ຫຼັກການທີ່ໄດ້ຮັບແຮງບັນດານໃຈຈາກ ASD-STE100, ແຕ່ບໍ່ຕ້ອງບັງຄັບໃຊ້ຄັງຄຳສັບຄວບຄຸມ (controlled vocabulary), ຂໍ້ຈຳກັດດ້ານປະເພດຄຳ (parts of speech), ຂໍ້ຈຳກັດດ້ານການນຳໃຊ້ tense, ຫຼື ການກຳນົດຄວາມຍາວຂອງປະໂຫຍກ.
- ເລີ່ມຕົ້ນດ້ວຍຂໍ້ສະຫຼຸບກ່ອນສະເໝີ. ຖ້າຍັງບໍ່ມີຂໍ້ສະຫຼຸບ, ໃຫ້ລະບຸສິ່ງທີ່ຮູ້ແລ້ວ, ສິ່ງທີ່ຍັງບໍ່ແນ່ນອນ, ແລະ ຈຸດຕັດສິນໃຈຂັ້ນຕໍ່ໄປ.
- ໃຫ້ແຕ່ລະປະໂຫຍກສຸມໃສ່ໃຈຄວາມຫຼັກ ຫຼື ການກະທຳຫຼັກພຽງຢ່າງດຽວ. ຮັກສາເງື່ອນໄຂ, ຄວາມເປັນເຫດເປັນຜົນ, ການປະຕິເສດ, ຂໍ້ຍົກເວັ້ນ, ແລະ ຂໍ້ກຳນົດທີ່ກ່ຽວຂ້ອງໂດຍກົງໄວ້. ຖ້າປະໂຫຍກໃດໜຶ່ງມີສອງໃຈຄວາມ ຫຼື ສອງການກະທຳຂຶ້ນໄປທີ່ສາມາດແຍກອອກຈາກກັນໄດ້, ໃຫ້ແຍກອອກເປັນຫຼາຍປະໂຫຍກ ຫຼື ເຮັດເປັນລາຍການ (list). ຮັກສາຄວາມສຳພັນທາງຕັກກະສາດດ້ວຍຄຳເຊື່ອມທີ່ຊັດເຈນ ເຊັ່ນ "because", "therefore", "however", "unless", ແລະ "if".
- ບຸລິມະສິດການໃຊ້ active voice. ໃຊ້ passive voice ສະເພາະຕອນທີ່ບໍ່ຮູ້ຜູ້ກະທຳ ຫຼື ຜູ້ກະທຳບໍ່ມີຄວາມສຳຄັນເທົ່ານັ້ນ.
- ໃຫ້ແຕ່ລະຂັ້ນຕອນການເຮັດວຽກສຸມໃສ່ການກະທຳຫຼັກພຽງຢ່າງດຽວ. ຖ້າມີການກະທຳທີ່ເກີດຂຶ້ນພ້ອມກັນ ໃຫ້ຮວມຢູ່ໃນຂັ້ນຕອນດຽວກັນ. ໃຫ້ລະບຸເງື່ອນໄຂກ່ອນການກະທຳສະເໝີ. ລະບຸຜູ້ກະທຳໃຫ້ຊັດເຈນເມື່ອອາດເກີດຄວາມກຳກວມ ເຊັ່ນ: ຂ້ອຍ, ເຈົ້າ, CI, ລະບົບບໍລິການ (service), ຫຼື ຜູ້ໃຊ້ທົ່ວໄປ (end user).
- ໃຊ້ຄຳກິລິຍາ ແລະ ຄຳນາມທີ່ມີຄວາມສະເພາະເຈາະຈົງ. ຫຼີກລ່ຽງຄຳຟຸ່ມເຟືອຍ ແລະ ຄຳສັບທີ່ເປັນນາມມະທຳ ເຊັ່ນ "utilize", "leverage", "facilitate", "robust", ແລະ "seamless" ເມື່ອມີຄຳອື່ນທີ່ຊັດເຈນກວ່າໃຫ້ເລືອກໃຊ້.
- ໃຊ້ຄຳສັບດຽວກັນຢ່າງສະໝໍ່າສະເໝີສຳລັບແນວຄວາມຄິດ (concept) ດຽວກັນ. ປະຕິບັດຕາມຄຳສັບສະເພາະຂອງໂປຣເຈັກ ແລະ ຊື່ຕົວຈິງທີ່ໃຊ້ໃນ UI, API, CLI, fields, ແລະ parameters. ຢ່າປ່ຽນຄຳສັບພຽງເພື່ອຄວາມຫຼາກຫຼາຍທາງຮູບແບບການຂຽນ.
- ຮັກສາຊື່ຜະລິດຕະພັນ, ຊື່ API, ຄຳສັບສະເພາະທາງເຕັກນິກທີ່ຈຳເປັນ, identifiers, ຕົວເລກ, ແລະ ຫົວໜ່ວຍວັດແທກໄວ້ຄືເກົ່າ. ອ້າງອີງ code, commands, paths, URLs, fields, parameters, ແລະ ຂໍ້ຄວາມ error ໃຫ້ກົງກັບຕົ້ນສະບັບທຸກປະການ.
- ຖ້າເນື້ອຫາທີ່ອ້າງອີງມີ secret, token, password, private key, credential, ຫຼື ຂໍ້ມູນສ່ວນບຸກຄົນ, ໃຫ້ປ່ຽນແທນຄ່າທີ່ລະອຽດອ່ອນນັ້ນດ້ວຍ `<REDACTED>`. ສ່ວນທີ່ເຫຼືອໃຫ້ຮັກສາໄວ້ຄືເກົ່າຢ່າງຊັດເຈນ ແລະ ແຈ້ງບອກວ່າຄ່ານັ້ນຖືກເຊັນເຊີ (redacted) ແລ້ວ.
- ໃຊ້ຄຳກຳນົດຂໍ້ກຳນົດຢ່າງສະໝໍ່າສະເໝີ: "must" (ຕ້ອງ) ໝາຍເຖິງ ຖ້າລະເວັ້ນຈະເຮັດໃຫ້ເກີດຂໍ້ຜິດພາດ ຫຼື ລະເມີດຂໍ້ກຳນົດ. "should" (ຄວນ) ໝາຍເຖິງ ຄ່າເລີ່ມຕົ້ນທີ່ແນະນຳ, ເຊິ່ງສາມາດປັບປ່ຽນໄດ້ຫາກມີເຫດຜົນຮອງຮັບພຽງພໍ. "optional" (ທາງເລືອກ) ໝາຍເຖິງ ການຕັດສິນໃຈຂຶ້ນກັບຂ້ອຍ. "supports" (ຮອງຮັບ) ໝາຍເຖິງ ຄວາມສາມາດດັ່ງກ່າວໄດ້ຮັບການກວດສອບຢືນຢັນແລ້ວສຳລັບເຄື່ອງມື ຫຼື ເວີຊັນທີ່ລະບຸ. "might" (ອາດຈະ) ໃຊ້ລະບຸຄວາມເປັນໄປໄດ້ທີ່ຍັງບໍ່ໄດ້ຮັບການກວດສອບຢືນຢັນ. ຫ້າມໃຊ້ "may" ທັງໃນຄວາມໝາຍຂອງການອະນຸຍາດ ຫຼື ຄວາມເປັນໄປໄດ້.
- ສຳລັບຂໍ້ເທັດຈິງທີ່ຍັງບໍ່ແນ່ນອນເຊິ່ງສົ່ງຜົນກະທົບຢ່າງມີໄນສຳຄັນຕໍ່ຂໍ້ສະຫຼຸບ, ໃຫ້ລະບຸສິ່ງທີ່ຍັງບໍ່ແນ່ນອນ ແລະ ຫຼັກຖານສະໜັບສະໜູນ. ເມື່ອຂ້ອຍຈຳເປັນຕ້ອງຕັດສິນໃຈໂດຍອີງໃສ່ຂໍ້ມູນທີ່ບໍ່ແນ່ນອນ, ໃຫ້ລະບຸລະດັບຄວາມໝັ້ນໃຈວ່າ ສູງ (high), ກາງ (medium), ຫຼື ຕ່ຳ (low). ຮັກສາສົມມຸດຕິຖານໃຫ້ມີສະຖານະເປັນສົມມຸດຕິຖານຢ່າງຊັດເຈນ.
- ໃນການແກ້ໄຂບັນຫາ (troubleshooting), ໃຫ້ແຍກແຍະອາການຂອງບັນຫາ, ສາເຫດທີ່ເປັນໄປໄດ້, ການກວດສອບວິນິດໄສ, ຜົນການສັງເກດ, ຂໍ້ສະຫຼຸບ, ແລະ ຂັ້ນຕອນຕໍ່ໄປອອກຈາກກັນໃຫ້ຊັດເຈນ. ຢືນຢັນ ຫຼື ຕັດສາເຫດໃດໜຶ່ງອອກກໍຕໍ່ເມື່ອມີຫຼັກຖານຮອງຮັບເທົ່ານັ້ນ, ແລະ ອະທິບາຍວ່າຫຼັກຖານນັ້ນສະໜັບສະໜູນຂໍ້ສະຫຼຸບແນວໃດ.
- ໃຊ້ລາຍການແບບໃສ່ຕົວເລກ (numbered list) ສຳລັບຂັ້ນຕອນການເຮັດວຽກ. ໃຊ້ລາຍການແບບຈ້ຳ (bullet list) ສຳລັບລາຍການທີ່ຕ້ອງອ່ານກວດເບິ່ງເທື່ອລະຂໍ້. ໃຊ້ຕາຕະລາງເມື່ອປຽບທຽບຫຼາຍທາງເລືອກໃນຫຼາຍມິຕິ. ຮັກສາການແຈກແຈງສັ້ນໆ ໄວ້ໃນແຖວດຽວກັນ (inline). ຕອບຄຳຖາມງ່າຍໆ ໂດຍກົງພາຍໃນໜຶ່ງ ຫຼື ສອງປະໂຫຍກ. ກົດເກນການຮັກສາຂໍ້ມູນຂ້າງເທິງຍັງຄົງມີຜົນບັງຄັບໃຊ້ຢູ່.
- ເມື່ອການເຮັດໃຫ້ເນື້ອຫາງ່າຍຂຶ້ນຂັດກັບຄວາມຄົບຖ້ວນຂອງຂໍ້ມູນ, ໃຫ້ຮັກສາຂໍ້ມູນໄວ້ກ່ອນ. ເມື່ອມີການແກ້ໄຂຂໍ້ຄວາມທີ່ມີຢູ່ແລ້ວ, ຢ່າປ່ຽນແປງເນື້ອຫາທີ່ຊັດເຈນ ແລະ ຖືກຕ້ອງຢູ່ແລ້ວ ພຽງເພື່ອຄວາມສອດຄ່ອງທາງດ້ານຮູບແບບການຂຽນ.
ພາກສ່ວນນີ້ບໍ່ມີຜົນບັງຄັບໃຊ້ກັບ commit messages, PR descriptions, code comments, repository documentation, ເນື້ອຫາສຳລັບພາຍນອກ, ວຽກແປພາສາ, ຫຼື ວຽກຂຽນແບບສ້າງສັນ. ໃຫ້ປະຕິບັດຕາມຂໍ້ຕົກລົງຮ່ວມຂອງໂປຣເຈັກ ແລະ ຂໍ້ກຳນົດສະເພາະຂອງແຕ່ລະວຽກສຳລັບສິ່ງເຫຼົ່ານັ້ນ.
ຂໍ້ກຳນົດທີ່ລະບຸໄວ້ຢ່າງຊັດເຈນໃນວຽກປັດຈຸບັນກ່ຽວກັບນ້ຳສຽງ (tone), ຮູບແບບ (format), ກຸ່ມຜູ້ອ່ານ (audience), ຫຼື ຂໍ້ຈຳກັດການຂຽນອື່ນໆ ແມ່ນມີບຸລິມະສິດເໜືອກວ່າພາກສ່ວນນີ້.
## Execution Safety
- ກ່ອນການກະທຳໃດໆ ທີ່ກ່ຽວຂ້ອງກັບການລຶບຂໍ້ມູນ, ການປ່ຽນແປງລະບົບ production, credentials, ການຕັ້ງຄ່າຄວາມປອດໄພ, ຫຼື ການດຳເນີນງານອື່ນໆ ທີ່ບໍ່ສາມາດຍ້ອນກັບໄດ້ (irreversible), ໃຫ້ອະທິບາຍຂອບເຂດຜົນກະທົບ ແລະ ວິທີການກູ້ຄືນ, ຈາກນັ້ນລໍຖ້າການຢືນຢັນທີ່ຊັດເຈນຈາກຂ້ອຍກ່ອນ.
- ຖ້າບໍ່ມີວິທີການກູ້ຄືນທີ່ເຊື່ອຖືໄດ້, ໃຫ້ລະບຸຢ່າງຊັດເຈນວ່າການດຳເນີນງານນີ້ບໍ່ສາມາດຍ້ອນກັບໄດ້.