ບົດຄວາມ
ເພດານຂອງການໃຊ້ AI ແມ່ນຄວາມທະເຍີທະຍານຂອງເຈົ້າ: ສີ່ມິຕິ ຄື ຄວາມໄວ ຄວາມສູງ ຄວາມເລິກ ແລະ ຄວາມກວ້າງ
Felix Rieseberg ຫົວໜ້າວິສະວະກອນຂອງ Anthropic ແບ່ງ "ການມີຄວາມທະເຍີທະຍານຫຼາຍຂຶ້ນໃນການໃຊ້ AI" ອອກເປັນສີ່ມິຕິ ຄື ຄວາມໄວ ຄວາມສູງ ຄວາມເລິກ ແລະ ຄວາມກວ້າງ. ບົດຄວາມນີ້ສະຫຼຸບວິທີການ ແລະ ຕົວຢ່າງຂອງລາວ ພ້ອມບັນທຶກການນຳໃຊ້ຈິງຂອງຂ້ອຍເອງ: ສັ່ງງານແບບມຸ່ງເປົ້າໝາຍ ແລ້ວຈັດທີມຜູ້ຊ່ຽວຊານດ້ວຍ Multi-AI Agents ມາກວດທານຂ້າມກັນຈາກຫຼາຍມຸມມອງ ເພື່ອຍົກລະດັບຄຸນນະພາບຂອງວຽກ.
· ອ່ານ 1 ນາທີ
ໃນບົດຄວາມ "How to be more ambitious: A tutorial for humans with models" ຂອງ Felix Rieseberg ຫົວໜ້າວິສະວະກອນຂອງ Anthropic ລາວເລົ່າວ່າ ເມື່ອເຫັນຄົນອື່ນໃຊ້ AI ສ້າງຜົນງານທີ່ໜ້າອັດສະຈັນ ລາວ ແລະ ຄົນອ້ອມຂ້າງມັກມີປະຕິກິລິຍາດຽວກັນວ່າ: "ພວກເຮົາຍັງທະເຍີທະຍານບໍ່ພໍ."
ຄວາມເຂົ້າໃຈຂອງຂ້ອຍແມ່ນ: ເພດານຂອງການໃຊ້ AI ຂອງມະນຸດ ມັກຕິດຢູ່ທີ່ຄວາມທະເຍີທະຍານ ແລະ ຈິນຕະນາການຂອງຕົນເອງ ບໍ່ແມ່ນທີ່ໂມເດວ.
ລາວແບ່ງ "ຄວາມທະເຍີທະຍານ" ອອກເປັນສີ່ມິຕິ:
- ຄວາມໄວ (Speed): ວຽກເດີມ ແຕ່ເຮັດສຳເລັດໃນເວລາທີ່ສັ້ນລົງ.
- ຄວາມສູງ (Altitude): ຍົກລະດັບນາມມະທຳໃຫ້ສູງຂຶ້ນ ແລະ ເບິ່ງຜົນລັບສຸດທ້າຍ ບໍ່ແມ່ນພຽງໜຶ່ງວຽກດ່ຽວ.
- ຄວາມເລິກ (Depth): ເຮັດວຽກຕາມມາດຕະຖານ ເຄື່ອງມື ແລະ ວິທີການຂອງຜູ້ຊ່ຽວຊານຊັ້ນນຳໃນສາຂານັ້ນ.
- ຄວາມກວ້າງ (Range): ກ້າວອອກຈາກສາຂາດຽວ ແລ້ວຫາທາງອອກຂ້າມສາຂາ.
ສະຫຼຸບກ່ອນ: ສັ່ງງານແບບມຸ່ງເປົ້າໝາຍໃຫ້ແມ່ນຍຳ ແລ້ວຈັດທີມຜູ້ຊ່ຽວຊານດ້ວຍ Multi-AI Agents ໃຫ້ຮ່ວມມື ແລະ ກວດທານຂ້າມກັນຈາກຫຼາຍມຸມມອງ ຄຸນນະພາບຂອງວຽກຈຶ່ງຈະຍົກລະດັບຂຶ້ນທັງໝົດ.
ໜຶ່ງ: ຄວາມໄວ ພື້ນຖານທີ່ສຸດ ແລະ ຕິດຂັດໜ້ອຍທີ່ສຸດ#
ວຽກເດີມ ແຕ່ເຮັດສຳເລັດໃນເວລາທີ່ສັ້ນລົງ. Felix ເຫັນວ່າທຸກຄົນຄຸ້ນເຄີຍກັບເລື່ອງນີ້ແລ້ວ ຈຶ່ງຂ້າມໄປໃນບົດຄວາມເລີຍ.
ມຸມມອງຂອງຂ້ອຍ: ຄວາມໄວເປັນຄຸນຄ່າທີ່ເຫັນໄດ້ຕົງທີ່ສຸດຂອງ AI ແຕ່ຖ້າໄລ່ຕາມພຽງຄວາມໄວ ວິທີການຮ່ວມງານກໍບໍ່ປ່ຽນຫຼາຍ. ສາມມິຕິຖັດໄປຕ່າງຫາກທີ່ເຮັດໃຫ້ເກີດຄວາມແຕກຕ່າງແທ້ໆ.
ສອງ: ຄວາມສູງ ຖາມເຖິງ "ເປົ້າໝາຍທີ່ຢູ່ເບື້ອງຫຼັງເປົ້າໝາຍ"#
ຄຳຖາມຫຼັກ: ຜົນລັບຖັດໄປທີ່ຂ້ອຍຕ້ອງການແທ້ໆແມ່ນຫຍັງ? ເປົ້າໝາຍທີ່ຢູ່ເບື້ອງຫຼັງເປົ້າໝາຍນີ້ແມ່ນຫຍັງ?
ຕົວຢ່າງຂອງ Felix:
- ຈາກການແກ້ Crash ໜຶ່ງຈຸດ ໄປສູ່ການເຮັດໃຫ້ App ບໍ່ Crash ອີກ. ກ່ອນນີ້ລາວໃຫ້ Claude ແກ້ Crash ພຽງຈຸດດຽວ ຕໍ່ມາປ່ຽນເປັນຂໍໃຫ້ App ຄົງ Crash ເປັນສູນ. ເພື່ອໃຫ້ເລື່ອງນີ້ເຮັດວຽກຕໍ່ເນື່ອງແບບອັດຕະໂນມັດ ລາວຕ້ອງປັບຂະບວນການຂອງຕົນເອງກ່ອນ: ເຮັດໃຫ້ໄດ້ລາຍງານ Crash ງ່າຍ, ຈັບຄູ່ເວີຊັນຂອງ App ກັບ Git Commit ແລະ ໃຫ້ Claude ໃຊ້ເຄື່ອງ Windows, macOS ແລະ Linux ເພື່ອເຮັດຊ້ຳ ແລະ ກວດສອບການແກ້ໄຂ.
- ການຍົກລະດັບການທົບທວນທຸລະກິດລາຍໄຕມາດ (QBR) ສາມຂັ້ນ:
- ໃຊ້ຂໍ້ມູນດິບໃຫ້ຫຼາຍທີ່ສຸດເທົ່າທີ່ເຮັດໄດ້ ເພື່ອອະທິບາຍວ່າໄຕມາດນີ້ມີຫຍັງປ່ຽນໄປ ເປັນຫຍັງ ແລະ ຄວນເຮັດຫຍັງຕໍ່.
- ຊອກຫາ 3 ການຕັດສິນໃຈທີ່ຮີບດ່ວນທີ່ສຸດ ແລ້ວຂຽນຂໍ້ໂຕ້ແຍ້ງທັງດ້ານເຫັນດີ ແລະ ບໍ່ເຫັນດີຂອງແຕ່ລະຂໍ້.
- ອອກແບບກົນໄກທາງເລືອກທີ່ກວດພົບບັນຫາໄດ້ໄວກວ່າສະໄລລາຍໄຕມາດ ທົດສອບດ້ວຍຂໍ້ມູນຍ້ອນຫຼັງ ແລະ ແລ່ນຄຽງຄູ່ກັບຂະບວນການປັດຈຸບັນໜຶ່ງໄຕມາດ.
ລາວຍັງເຕືອນເລື່ອງຂອບເຂດດ້ວຍວ່າ ໃນປີ 2026 ເປົ້າໝາຍທີ່ຄຸມເຄືອຢ່າງ "Claude ໄປຫາເງິນມາໃຫ້ຂ້ອຍແດ່" ຍັງໃຊ້ບໍ່ໄດ້ ແຕ່ລາວຄາດວ່າລະດັບນາມມະທຳທີ່ໂມເດວຮັບມືໄດ້ຈະສູງຂຶ້ນເລື້ອຍໆ.
ສາມ: ຄວາມເລິກ ຕາມມາດຕະຖານຂອງຜູ້ຊ່ຽວຊານຊັ້ນນຳໃນສາຂານັ້ນ#
ວິທີຂອງ Felix:
- ໃຊ້ເຄື່ອງມືທີ່ອຸດສາຫະກຳນັ້ນໃຊ້ຈິງ. ໂມເດວມັກປ່ຽນພຽງຖ້ອຍຄຳ ບໍ່ໄດ້ປ່ຽນວິທີເຮັດ ແລ້ວໂຍນຕາຕະລາງ Markdown ມາໃຫ້ພໍເປັນພິທີ. ໃຫ້ຢືນຢັນໃຊ້ເຄື່ອງມືວິເຄາະຈິງ ເຊັ່ນ ຖານຂໍ້ມູນ ແລະ ໂມເດວທາງສະຖິຕິ.
- ຕັ້ງເປົ້າໝາຍທີ່ຟັງແລ້ວບໍ່ສົມເຫດສົມຜົນ ແລະ ບອກໂມເດວວ່າແກ້ໄດ້. ຕົວຢ່າງຂອງລາວ: ຫຼັງຈາກຫຼຸດເວລາໂຫຼດເວັບໄຊຈາກ 10 ວິນາທີເຫຼືອ 5 ວິນາທີ ກໍຂໍ 200 ມິນລິວິນາທີ. ເມື່ອໂມເດວຖອຍ ໃຫ້ຢືນຢັນວ່າເຮັດໄດ້.
- ທ້າທາຍສົມມຸດຖານທີ່ຕົນເອງເຊື່ອ. ໃຫ້ຂໍ້ມູນດິບແກ່ໂມເດວ ແລ້ວໃຫ້ກວດຈາກມຸມມອງໂຕ້ແຍ້ງ. ຕົວຢ່າງ: "ພວກເຮົາຄິດວ່າສາເຫດທີ່ຜູ້ໃຊ້ເລີກໃຊ້ແມ່ນຂັ້ນຕອນ onboarding ລອງສ້າງບົດສະຫຼຸບນີ້ຂຶ້ນມາໃໝ່ຈາກຂໍ້ມູນດິບ."
- ສ້າງຄວາມຮູ້ໃໝ່. ສ້າງແບບຈຳລອງຈາກ Logs ຊອກຫາສັນຍານທຳອິດຂອງການເລີກໃຊ້ທີ່ເຈົ້າຍັງບໍ່ຮູ້ ແລ້ວກວດສອບດ້ວຍຂໍ້ມູນທີ່ຍັງບໍ່ເຄີຍເຫັນ.
- ຫາຜູ້ຕັດສິນຈາກພາຍນອກ (Outside Judge). ຢ່າໃຫ້ໂມເດວກວດງານຕົນເອງ. ດີທີ່ສຸດແມ່ນເຊື່ອມເຄື່ອງມືທີ່ໂມເດວແລ່ນໄດ້ເອງ ແລະ ໄດ້ຜົນຕອບກັບທັນທີ.
ຫຼັກການຂຽນ Prompt ຂອງລາວຄື: ສິ່ງທີ່ຂໍແມ່ນ "ສະບັບທີ່ເລິກກວ່າ" ບໍ່ແມ່ນ "ສະບັບທີ່ໃຫຍ່ກວ່າ". ໃຫ້ໂມເດວບອກວ່າມືອາຊີບລະດັບສູງສຸດຈະເຮັດຫຍັງເພີ່ມ ຂໍ້ມູນຕົ້ນທາງທີ່ດິບທີ່ສຸດຢູ່ໃສ ຈະໃຊ້ວິທີການ ແລະ ເຄື່ອງມືຫຍັງ ແລະ ນອກຈາກໂມເດວ ຫຼື ວິຈາລະນະຍານຂອງເຈົ້າແລ້ວ ມີຫຍັງອີກທີ່ພິສູດໄດ້ວ່າຜົນລັບຖືກຕ້ອງ.
ສີ່: ຄວາມກວ້າງ ໃຊ້ກິລິຍາແທນນາມ ແລະ ຕັ້ງທີມຜູ້ຊ່ຽວຊານ#
- ໃຊ້ກິລິຍາແທນນາມ. ແນວຄິດນີ້ Felix ອ້າງມາຈາກປຶ້ມ The Art of Innovation. QBR ບໍ່ແມ່ນ "ສະໄລຊຸດໜຶ່ງ" ແຕ່ແມ່ນ "ພາຍໃນ 30 ນາທີ ຊ່ວຍໃຫ້ຄົນທີ່ຫຍຸ້ງເຂົ້າໃຈເຫດ ແລະ ຜົນ ແລະ ຕັດສິນໃຈທ່າມກາງຄວາມບໍ່ແນ່ນອນ". ເມື່ອນິຍາມເປົ້າໝາຍດ້ວຍກິລິຍາ ກໍຈະເຫັນວ່າຕ້ອງໃຊ້ຄວາມສາມາດຈາກສາຂາໃດແດ່.
- ຕັ້ງທີມ. ຖ້າຈະເຮັດສະໄລທີ່ດີ ໃຫ້ຫານັກວິເຄາະ ນັກຂ່າວ ແລະ ບັນນາທິການ. ຖ້າຈະນຳສະເໜີເທິງເວທີ ເພີ່ມນັກອອກແບບການເຄື່ອນໄຫວ ແລະ ສຽງ. ຖ້າຈະເຮັດການກວດທານແບບໂຕ້ແຍ້ງ ໃຫ້ຫານັກຄົ້ນຄວ້າຈາກບໍລິສັດຂາຍຊອດ (short-selling) ແລະ ນັກບັນຊີນິຕິວິທະຍາ.
- ຢ່າສວມບົດບາດແບບບໍ່ມີຄວາມໝາຍ. ບໍ່ແມ່ນສັ່ງໂມເດວວ່າ "ຂຽນດ້ວຍນ້ຳສຽງຂອງບໍລິສັດ short-selling" ແຕ່ໃຫ້ລົງມືເຮັດຕາມວິທີຄົ້ນຄວ້າຂອງບໍລິສັດ short-selling ໃນສ່ວນໜຶ່ງຂອງວຽກຈິງໆ. ປ່ຽນພຽງນ້ຳສຽງ ຜົນລັບກໍບໍ່ດີຂຶ້ນ.
ເງື່ອນໄຂຄື: ໂມເດວຕ້ອງມີຄອມພິວເຕີທີ່ຕິດຕັ້ງຊອບແວໄດ້ ແລະ ເຂົ້າເຖິງຂໍ້ມູນທີ່ກ່ຽວຂ້ອງໄດ້ ເຊັ່ນ ຜ່ານຕົວເຊື່ອມຕໍ່ MCP.
ຫ້າ: ບັນທຶກການນຳໃຊ້ຂອງຂ້ອຍ ຈາກ "ການສົ່ງຜ່ານຂໍ້ມູນ" ສູ່ "ການບັນລຸເຈດຕະນາ"#
ສ່ວນລຸ່ມນີ້ເປັນສ່ວນຕໍ່ຍອດຂອງຂ້ອຍເອງທີ່ຜະສົມສະຖາປັດຕະຍະກຳຊອບແວເຂົ້າກັບການປະຕິບັດຈິງທາງວິສະວະກຳ ບໍ່ແມ່ນເນື້ອຫາໃນຕົ້ນສະບັບ.
1. Jobs to be Done ແລະ Intent-Based#
- ຢ່າຖາມວ່າ "ເຮັດຫຍັງ" ໃຫ້ຖາມວ່າ "ບັນລຸຫຍັງ". ການອອກແບບບໍ່ຄວນຢຸດແຄ່ pipeline ສົ່ງຜ່ານຂໍ້ມູນແບບຕັ້ງຮັບ ເຊັ່ນ
generate_deck_pdf() ແຕ່ຄວນຍົກລະດັບເປັນເຈດຕະນາຂອງການປ່ຽນສະຖານະ ເຊັ່ນ resolve_leadership_uncertainty_and_commit_budget().
- ນິຍາມ loss function ທີ່ແທ້ຈິງ. ຖ້າຂໍພຽງຊິ້ນງານ ໂມເດວຈະສ້າງຂໍ້ຄວາມກວ່າງເປົ່າທີ່ເບິ່ງສົມບູນແບບ ແຕ່ຖ້າຂໍໃຫ້ແກ້ຄວາມບໍ່ແນ່ນອນຂອງການຕັດສິນໃຈ ໂມເດວ ແລະ Sub-agent ຈຶ່ງຈະເຕີມຊ່ອງໂຫວ່ທາງເຫດຜົນ ແລະ ຂອບເຂດຄວາມສ່ຽງໃຫ້ເອງ.
2. ຕອນສຳຫຼວດໃຫ້ກະຈາຍ ຕອນກວດຮັບໃຫ້ລວມ#
- ຕອນສຳຫຼວດ ກະຈາຍຫາຄວາມເປັນໄປໄດ້ກ່ອນ ແລ້ວຈຶ່ງລວມ.
- ຕອນກວດຮັບ ຢ່າກະຈາຍອີກ. ຫຼີກລ່ຽງຄຳຖາມທີ່ບໍ່ມີຂອບເຂດ ເຊັ່ນ "ເລື່ອງນີ້ເຮັດແບບອື່ນໄດ້ອີກບໍ?" ເພາະຈະໄດ້ແຕ່ຄຳຕອບກວ້າງໆທົ່ວໄປ.
- ຂຽນຂອບເຂດເປົ້າໝາຍ ຂໍ້ຈຳກັດ ແລະ ເຄື່ອງມືກວດສອບທີ່ເປັນວັດຖຸວິໄສໃຫ້ຊັດເຈນ (ສະຄຣິບທົດສອບສະເພາະ ເກນຕົວຊີ້ວັດທຸລະກິດ) ເພື່ອໃຫ້ທີມ Multi-Agent ເຮັດ stress test ພາຍໃນກອບທີ່ໂຟກັສ ແລະ ສົ່ງມອບຜົນງານຄຸນນະພາບສູງ.
ສະຫຼຸບບັນທຶກ#
- ມຸ່ງເປົ້າໝາຍ: ໃຊ້ກິລິຍາແທນນາມ. ສົ່ງມອບຜົນລັບທີ່ແກ້ບັນຫາໄດ້ ບໍ່ແມ່ນຊິ້ນງານທີ່ເຮັດພຽງເພື່ອໃຫ້ພົ້ນໜ້າທີ່.
- ສຳຫຼວດ ແລະ ລວມ: ຕອນສຳຫຼວດກະຈາຍຫາຄວາມເປັນໄປໄດ້ ຕອນກວດຮັບລວມຢ່າງເຂັ້ມງວດເພື່ອກວດຂອບເຂດ.
- ໂຟກັສທີ່ນາມມະທຳ: ເລີ່ມຈາກຄຳຖາມຫຼັກ ແລ້ວຮື້ສ້າງຂະບວນການເຮັດວຽກທັງຊຸດໃໝ່.
- ຄວາມເລິກແບບຜູ້ຊ່ຽວຊານ: ບໍ່ແມ່ນພຽງລຽນແບບນ້ຳສຽງຜູ້ຊ່ຽວຊານ ແຕ່ບັງຄັບໃຫ້ໂມເດວແກ້ບັນຫາດ້ວຍເຄື່ອງມື ແລະ ວິທີການຂອງຜູ້ຊ່ຽວຊານຊັ້ນນຳ.
ຕົ້ນສະບັບ: How to be more ambitious: A tutorial for humans with models (Felix Rieseberg, 2026-10-13)